Уже доступно! Исследование Telegram 2025 — ключевые инсайты года 
NetworkAdmin.ru
Открыть в Telegram
Авторский блог про сетевое и системное администрирование. Сайт: networkadmin.ru Реклама: @dad_admin Биржа: https://telega.in/c/networkadminru
Больше4 715
Подписчики
-524 часа
-107 дней
-930 день
Загрузка данных...
Похожие каналы
Облако тегов
Входящие и исходящие упоминания
---
---
---
---
---
---
Привлечение подписчиков
июнь '26
июнь '26
+34
в 4 каналах
май '26
+27
в 0 каналах
Get PRO
апрель '26
+25
в 0 каналах
Get PRO
март '26
+19
в 0 каналах
Get PRO
февраль '26
+30
в 0 каналах
Get PRO
январь '26
+89
в 5 каналах
Get PRO
декабрь '25
+152
в 12 каналах
Get PRO
ноябрь '25
+114
в 2 каналах
Get PRO
октябрь '25
+123
в 7 каналах
Get PRO
сентябрь '25
+181
в 15 каналах
Get PRO
август '25
+19
в 0 каналах
Get PRO
июль '25
+95
в 11 каналах
Get PRO
июнь '25
+70
в 5 каналах
Get PRO
май '25
+72
в 1 каналах
Get PRO
апрель '25
+560
в 24 каналах
Get PRO
март '25
+127
в 6 каналах
Get PRO
февраль '25
+205
в 8 каналах
Get PRO
январь '25
+409
в 19 каналах
Get PRO
декабрь '24
+69
в 0 каналах
Get PRO
ноябрь '24
+88
в 1 каналах
Get PRO
октябрь '24
+598
в 8 каналах
Get PRO
сентябрь '24
+1 046
в 26 каналах
Get PRO
август '24
+1 013
в 24 каналах
Get PRO
июль '24
+311
в 7 каналах
Get PRO
июнь '240
в 1 каналах
Get PRO
май '240
в 0 каналах
Get PRO
апрель '240
в 0 каналах
Get PRO
март '240
в 0 каналах
Get PRO
февраль '240
в 0 каналах
Get PRO
январь '24
+472
в 3 каналах
| Дата | Привлечение подписчиков | Упоминания | Каналы | |
| 24 июня | 0 | |||
| 23 июня | +2 | |||
| 22 июня | 0 | |||
| 21 июня | 0 | |||
| 20 июня | +1 | |||
| 19 июня | 0 | |||
| 18 июня | +1 | |||
| 17 июня | +2 | |||
| 16 июня | 0 | |||
| 15 июня | 0 | |||
| 14 июня | 0 | |||
| 13 июня | 0 | |||
| 12 июня | 0 | |||
| 11 июня | +1 | |||
| 10 июня | +1 | |||
| 09 июня | +1 | |||
| 08 июня | 0 | |||
| 07 июня | +1 | |||
| 06 июня | +1 | |||
| 05 июня | +2 | |||
| 04 июня | 0 | |||
| 03 июня | +2 | |||
| 02 июня | +8 | |||
| 01 июня | +11 |
Посты канала
ℹ️ DISM и SFC: базовая реанимация windows без переустановки
Когда windows начинает вести себя странно, не всегда нужно сразу переустанавливать систему. Симптомы могут быть разные:
не открываются системные компоненты;
падают службы;
не ставятся обновления;
появляются ошибки DLL;
ломаются стандартные приложения;
система загружается, но работает нестабильно.
В таких случаях полезно вспомнить про два штатных инструмента: DISM и SFC. Они не делают магию и не чинят все подряд, но часто помогают восстановить поврежденные системные файлы и компонентное хранилище виндовс.
▪️ SFC проверяет целостность системных файлов. Запускать нужно из cmd или PowerShell от администратора:
sfc /scannow
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:1 /LimitAccessD: - смонтированный ISO
install.wim - образ установки
:1 - индекс редакции внутри WIM
/LimitAccess - не ходить в Windows Update
Индекс можно посмотреть так:
DISM /Get-WimInfo /WimFile:D:\sources\install.wim| 2 |  А вот это уже пахнет на настоящему дорого
#юмор
🧑💻 NetworkAdmin | 690 |
| 3 | Определите свой уровень Python за 2 минуты 🐍
Пройдите тест из 5 вопросов, и проверьте свои знания в Python.
А после теста вас ждёт ещё больше ценных материалов и полезной информации для дальнейшего роста. Идеально для начинающих и тех, кто хочет освежить свои знания.
Не откладывай развитие — переходи по ссылке, прямо сейчас и проверь себя! 🔥 | 665 |
| 4 | 🔎 mtr: диагностика сети
Если сеть начинает лагать, то обычно первым делом запускают:
ping 8.8.8.8
Потом:
traceroute 8.8.8.8
ping показывает задержку и потери до конечного узла. traceroute показывает маршрут. А mtr объединяет оба подхода в одном инструменте. По сути, mtr - это живая диагностика маршрута: он постоянно отправляет пакеты и показывает статистику по каждому hop`у.
▪️ Установка:
apt install mtr
или:
yum install mtr
Запуск:
mtr 8.8.8.8
▪️ В интерфейсе видно:
через какие узлы идет маршрут;
где растет задержка;
на каком hop’е появляются потери;
как меняется картина во времени.
▪️ Для разовой проверки удобен report-режим:
mtr -rw 8.8.8.8
-r - report mode
-w - широкий вывод, чтобы не резались имена хостов
Можно указать число пакетов:
mtr -rw -c 100 8.8.8.8
Это уже полезнее, чем скриншот после 5 секунд наблюдения.
▪️ Главное правило чтения mtr:
Потери на промежуточном hop’е не всегда означают проблему. Многие маршрутизаторы специально ограничивают ответы на ICMP/TTL exceeded. Поэтому если на одном промежуточном узле видно 50% loss, а дальше и до конечного хоста потерь нет - скорее всего, это не авария. Проблема становится реальной, когда потери продолжаются на всех следующих hop’ах, включая конечный адрес. Пример:
hop 5: 30% loss
hop 6: 30% loss
hop 7: 30% loss
target: 30% loss
Вот это уже похоже на реальную потерю по пути. А если так:
hop 5: 80% loss
hop 6: 0% loss
target: 0% loss
то, скорее всего, просто сам hop не любит отвечать на диагностические пакеты.
▪️ Полезные варианты:
mtr -4 networkadmin.ru # только IPv4.
mtr -6 networkadmin.ru # только IPv6.
mtr -T networkadmin.ru # TCP-режим, полезно, когда ICMP фильтруется.
mtr -u networkadmin.ru # UDP-режим
mtr показывает сетевую картину с вашей точки. Если проблема плавающая или зависит от обратного маршрута, одного запуска может быть мало.
Лучше запускать проверку с двух сторон, если есть такая возможность: от клиента к серверу и от сервера к клиенту.
#linux #network
🧑💻 NetworkAdmin | 538 |
| 5 | Магия Lovable: как создавать готовые интерфейсы с помощью одного запроса.
Бесплатный урок курса «Вайб-кодинг: создание цифровых продуктов с ИИ»
Lovable может за минуты собрать экран, который выглядит как почти готовый интерфейс. Но результат зависит не от «магии нейросети», а от того, насколько точно вы ставите задачу. Один расплывчатый запрос даст случайный макет, а правильно собранный системный промпт — понятную структуру, единый стиль и экран, который уже можно показывать команде, заказчику или использовать для проверки идеи.
На открытом уроке 2 июля в 20:00 разберём, как формулировать задачи для Lovable, чтобы получать предсказуемый результат с первой попытки. Поговорим о структуре системного промпта, ключевых словах, которые помогают превратить текст в качественный интерфейс, и способах доработки результата через встроенный редактор и повторные запросы. Отдельно обсудим, как управлять компонентами, просить нейросеть переиспользовать элементы и сохранять единый визуальный стиль.
Урок не для тех, кто ждёт, что Lovable «сам всё поймёт», не готов уточнять задачу и хочет получать качественный интерфейс без структуры, контекста и итераций.
👉 Записаться: https://otus.pw/uKsN/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576 | 612 |
| 6 | 🌀 Почему "процесс жив" не означает "сервис работает"
Одна из частых ошибок в мониторинге - считать сервис рабочим только потому, что его процесс запущен.
systemctl status myapp
показывает active (running), PID есть, порт вроде слушается - значит все хорошо? Не всегда.
Процесс может быть живым, но сам сервис уже фактически не работает:
завис на подключении к базе;
потерял доступ к Redis или очереди;
перестал обрабатывать запросы;
отвечает только частью функционала;
уперся в пул соединений;
ловит deadlock внутри приложения;
слушает порт, но возвращает 500.
Поэтому нормальная проверка должна отвечать не на вопрос: "процесс существует?" А на вопрос: "сервис реально выполняет свою задачу?"
▪️ Самый простой пример - HTTP health check:
curl -fsS http://127.0.0.1:8080/health
Если endpoint возвращает 200 OK, уже лучше, чем просто проверять PID. Но и здесь есть нюанс.
Плохой health check: /health -> 200 OK просто потому что приложение запустилось.
▪️ Хороший health check проверяет зависимости:
доступна ли база;
работает ли очередь;
можно ли читать конфиг;
не закончились ли critical ресурсы;
готов ли сервис принимать трафик;
В кубере это разделяют на разные проверки:
liveness - процесс жив или его надо перезапустить;
readiness - можно ли отправлять на него трафик;
startup - успел ли сервис нормально подняться.
Эту же логику полезно применять и без k8s. Например:
curl -fsS http://127.0.0.1:8080/ready
/ready может возвращать ошибку, если приложение живо, но база недоступна. В таком состоянии сервис лучше не убивать, но и трафик на него отправлять не надо.
▪️ Для обычного linux-сервера можно использовать health check в связке с systemd, HAProxy, Nginx, keepalived или внешним мониторингом. Пример проверки в скрипте:
#!/usr/bin/env bash
if curl -fsS http://127.0.0.1:8080/health >/dev/null; then
echo "OK"
exit 0
else
echo "FAIL"
exit 1
fi
Такой скрипт уже можно подключать к мониторингу или балансировщику.
#linux #monitoring
🧑💻 NetworkAdmin | 632 |
| 7 | 🚀 Две премьеры PT NGFW в одном эфире
29 июня в 11:00 команда PT NGFW впервые покажет новую индустриальную модель PT NGFW 905i и подробно разберет релиз 1.11 с одной из самых ожидаемых функций — удаленным доступом для пользователей.
Но главное — вместо презентаций будут реальные демонстрации.
Мы покажем новую модель в лаборатории, проведем для нее стресс-испытания в условиях, приближенных к реальным заводским (поджарим в прямом эфире), разберем архитектуру удаленного доступа и расскажем, какие инженерные задачи пришлось решить команде разработки.
В программе:
🔹 первая демонстрация новой индустриальной платформы PT NGFW 905i;
🔹 удаленный доступ: архитектура, сценарии применения и особенности реализации;
🔹 новые возможности релиза 1.11;
🔹 новые возможности администрирования и промышленной эксплуатации;
🔹 живая демонстрация вместо слайдов.
Если давно ждали релиз, хотели увидеть новую индустриальную платформу или просто любите хорошие инженерные разборы, — этот вебинар пропускать нельзя. Запасайтесь попкорном 🍿
➡️ Регистрируйтесь и узнайте о новых возможностях PT NGFW первыми. | 652 |
| 8 | 🛡 Как защитить скрипт от повторного запуска
Одна из классических проблем в автоматизации: скрипт еще не успел завершиться, а cron, systemd timer или админ руками запускает его снова. В итоге получаем неприятные эффекты: два бэкапа пишут в один каталог, две задачи одновременно чистят одни и те же файлы, несколько копий скрипта дергают API, повторный запуск ломает промежуточное состояние, база получает дубли или конфликтующие операции и т.д. Чтобы этого избежать, удобно использовать flock.
flock - это утилита для работы с файловыми блокировками. Идея простая: перед запуском скрипт пытается взять lock-файл. Если блокировка уже занята, значит другая копия скрипта еще работает.
▪️ Самый простой вариант:
flock -n /tmp/myjob.lock /opt/scripts/myjob.sh
/tmp/myjob.lock - файл блокировки
-n - не ждать освобождения lock, а сразу завершиться
/opt/scripts/myjob.sh - команда, которую нужно выполнить
Если первый запуск еще работает, второй просто не стартует.
▪️ Для cron это выглядит так:
*/5 * * * * flock -n /tmp/backup.lock /opt/scripts/backup.sh
`
Теперь даже если бэкап длится дольше 5 минут, новая копия не запустится поверх старой.
▪️ Можно добавить логирование:
flock -n /tmp/backup.lock /opt/scripts/backup.sh || echo "backup already running"
▪️ Но часто удобнее встроить flock прямо в сам скрипт:
#!/usr/bin/env bash
set -euo pipefail
LOCK_FILE="/tmp/myjob.lock"
exec 200>"$LOCK_FILE"
flock -n 200 || {
echo "script already running"
exit 1
}
echo "start job"
# основная логика скрипта
sleep 30
echo "done"
exec 200>"$LOCK_FILE" открывает lock-файл на файловом дескрипторе 200
flock -n 200 пытается взять блокировку
если блокировка занята - скрипт завершается
пока скрипт работает, дескриптор открыт и lock удерживается
После завершения процесса блокировка освобождается автоматически.
▪️ Где хранить lock-файл? Для временных задач часто используют:
/tmp/myjob.lock
Для системных сервисов лучше:
/run/myjob.lock
/run обычно живет в tmpfs и очищается после перезагрузки. Это удобно для runtime-блокировок.
▪️ Есть и режим ожидания:
flock /tmp/myjob.lock /opt/scripts/myjob.sh
В этом случае второй запуск будет ждать, пока первый освободит lock.
Можно задать таймаут ожидания:
flock -w 60 /tmp/myjob.lock /opt/scripts/myjob.sh
Так команда подождет до 60 секунд и завершится, если блокировка не освободится.
#bash #flock
🧑💻 NetworkAdmin | 820 |
| 9 | Тест:Как хорошо вы знаете Ansible?⚡️
👉Что такое плейбук?
a) Список серверов для управления контрольной нодой Ansible
b) Список задач и настроек для конфигурирования хостов
c) Специальный плагин Ansible для подключения к удаленным серверам по SSH
d) Название внутренней архитектуры Ansible
5 вопросов по Ansible ждут вас внутри бота👇
👉 ПРОВЕРИТЬ СВОИ ЗНАНИЯ | 615 |
| 10 |  Смотря какой fabric
Смотря сколько details
#юмор
🧑💻 NetworkAdmin | 1 269 |
| 11 | 💿 LVM RAID на практике: RAID1, замена диска и проверка целостности
LVM умеет не только создавать обычные логические тома, но и собирать RAID-массивы. Это удобно, когда хочется управлять дисками, томами и отказоустойчивостью в одном месте, без отдельного mdadm.
Ниже будет шпаргалка по созданию LVM RAID1, замене вылетевшего диска и включению проверки целостности через DM Integrity.
Создаем RAID1 из двух дисков:
apt install lvm2
pvcreate /dev/sdb /dev/sdc
vgcreate vgroup /dev/sdb /dev/sdc
lvcreate --type raid1 -l 100%FREE -n lvraid1 vgroup
Проверяем тип сегмента:
lvs -o+segtype
Создаем файловую систему и монтируем том:
mkfs.ext4 /dev/vgroup/lvraid1
mkdir /mnt/lvraid1
mount /dev/vgroup/lvraid1 /mnt/lvraid1
Смотрим итоговую структуру: lsblk
Теперь можно записать данные и дождаться полной синхронизации:
cp -r /var/log/* /mnt/lvraid1/
Если после этого отключить один из дисков, данные останутся доступны. RAID1 продолжит работать в degraded-состоянии.
Проверить статус можно так:
lvs -a -o name,devices vgroup
Если один диск пропал, в выводе появится устройство со статусом [unknown].
Допустим, вместо старого диска в системе появился новый /dev/sdd.
Добавляем его в VG:
pvcreate /dev/sdd
vgextend vgroup /dev/sdd
Удаляем пропавший диск из volume group:
vgreduce --removemissing vgroup --force
Проверяем, что [unknown] исчез:
lvs -a -o name,devices vgroup
Теперь восстанавливаем RAID и добавляем новый диск в зеркало:
lvconvert --repair vgroup/lvraid1
lvconvert -m1 vgroup/lvraid1 /dev/sdd
На вопросы LVM отвечаем утвердительно. Наблюдать за синхронизацией можно так:
lvs -a -o name,devices vgroup
lvs -o+segtype
В итоге диск заменен, данные на месте, система продолжает работать.
Это один из плюсов LVM RAID: замена диска проходит достаточно логично и без остановки сервера, если железо позволяет hot-swap.
▪️ Еще одна интересная возможность LVM RAID - конвертация уровней RAID на лету. Например, можно начать с RAID1 на двух дисках, а потом добавить еще два диска и прийти к RAID10. Правда, прямой конвертации из RAID1 в RAID10 нет: обычно это делается через промежуточные этапы. Примерная схема:
pvcreate /dev/sdc /dev/sde
vgextend vgroup /dev/sdc /dev/sde
lvconvert --type raid5_n vgroup/lvraid1
lvresize -l5118 vgroup/lvraid1
lvconvert --stripes 1 vgroup/lvraid1
lvconvert --stripes 2 vgroup/lvraid1
lvconvert --type raid10 vgroup/lvraid1
lvconvert --type raid10 vgroup/lvraid1
Размер в lvresize нужно подбирать под конкретный LV. LVM в процессе обычно сам подсказывает, что ему нужно: где не хватает места, где конвертация идет в несколько этапов, и какой промежуточный тип требуется. Если RAID10 создается с нуля, все намного проще. Добавляем 4 диска в VG и создаем LV:
lvcreate --type raid10 -l 100%FREE -n lvraid10 vgroup
▪️ Самая интересная часть - DM Integrity. LVM RAID может проверять целостность данных с помощью контрольных сумм. Это позволяет обнаруживать повреждения и пытаться восстановить данные из другой копии в составе RAID. Включить integrity можно сразу при создании LV:
lvcreate --type raid1 --raidintegrity y -L 9G -n lvraid1 vgroup
Важный момент: под метаданные integrity нужно свободное место. Если указать 100%FREE, можно получить ошибку, потому что LVM не сможет выделить место под служебные данные. Если в VG есть свободное место, integrity можно добавить к уже существующему RAID-томy:
lvconvert --raidintegrity y vgroup/lvraid1
При чтении данных будет проверяться контрольная сумма. Если она не совпадет с сохраненной, LVM попытается восстановить данные из другой копии RAID.
Для каждого диска в составе такого LV создаются дополнительные служебные тома под integrity metadata. Статистику ошибок можно смотреть так:
lvs -o+integritymismatches vgroup/lvraid1_rimage_0_imeta
Нужная колонка: IntegMismatches
Также события по DM Integrity будут попадать в системный лог, например: /var/log/syslog
#lvm #raid
🧑💻 NetworkAdmin | 900 |
| 12 | ❗️ lsof: кто держит файл, порт или точку монтирования
Иногда нужно ответить на очень простой вопрос: кто это держит? Файл удалили, а место не освободилось. Порт занят, но непонятно кем. Диск не размонтируется, потому что "device is busy". Во всех этих случаях помогает lsof - утилита, которая показывает открытые файлы. В linux почти все является файлом: обычные файлы, сокеты, сетевые соединения, устройства, точки монтирования. Поэтому lsof умеет находить очень много полезного.
▪️ Установка:
apt install lsof
#или
yum install lsof```
▪️ Кто держит конкретный файл
lsof /var/log/app.log
Так можно увидеть процесс, PID и пользователя, который открыл файл. Особенно полезно, когда файл уже удалили, но место на диске не вернулось:
lsof | grep deleted
или аккуратнее:
lsof +L1
Это покажет открытые файлы, у которых уже нет ссылок в файловой системе.
Типичный виновник - сервис, который продолжает писать в старый лог после удаления или неудачной ротации.
▪️ Кто слушает порт. Например, нужно понять, кто занял 8080:
lsof -i :8080
Для TCP:
lsof -iTCP:8080 -sTCP:LISTEN
В выводе будет видно имя процесса, PID и пользователь. Это удобно, когда сервис не стартует с ошибкой вроде: address already in use
▪️ Кто держит точку монтирования. Допустим, не получается размонтировать диск:
umount /mnt/backup
А в ответ: target is busy
Смотрим, кто держит файлы внутри:
lsof +D /mnt/backup
После этого можно понять, какой процесс мешает размонтированию: shell с текущей директорией внутри mount point, backup-скрипт, rsync, база или зависший процесс.
▪️ Кто держит сетевые соединения. Показать все сетевые соединения:
lsof -i
Только TCP:
lsof -iTCP
Только UDP:
lsof -iUDP
Это не всегда замена ss, но часто удобно, когда нужно быстро связать соединение с процессом.
▪️ Что полезно запомнить:
lsof /path/to/file
lsof -i :PORT
lsof -iTCP:PORT -sTCP:LISTEN
lsof +D /mount/path
lsof +L1
#linux #lsof
🧑💻 NetworkAdmin | 810 |
| 13 | 🦖 Reverse Path Filtering: защита или источник странных сетевых багов
Иногда сеть вроде настроена правильно, маршруты есть, интерфейсы подняты, а пакеты все равно куда-то пропадают. Особенно часто это всплывает на серверах с несколькими интерфейсами, policy routing, VPN, асимметричной маршрутизацией или в роли роутера. Одна из причин - Reverse Path Filtering (rp_filter). Это механизм в linux, который проверяет: если пакет пришел с какого-то IP, а мы захотели бы отправить ответ до этого IP через другой интерфейс - не выглядит ли это подозрительно? Если выглядит - пакет может быть отброшен.
▪️ Зачем это вообще нужно:
защита от IP spoofing;
базовая проверка правдоподобности маршрута;
уменьшение шансов принять пакет с поддельным source IP.
То есть идея хорошая: пакет пришел не с той стороны, откуда ядро ожидало бы обратный маршрут - значит, что-то не так. Но на практике именно здесь начинаются странности.
▪️ Где rp_filter часто ломает жизнь:
multihomed-серверы с несколькими uplink;
VPN и туннели;
policy based routing;
асимметричные маршруты;
NAT-сценарии;
Kubernetes / overlay-сети;
Linux в роли маршрутизатора
▪️ Типичная ситуация:
• пакет приходит через eth1;
• ядро считает, что обратный путь до source IP должен идти через eth0;
• rp_filter решает, что пакет подозрительный;
• пакет молча дропается
Снаружи это выглядит очень неприятно: ping иногда работает, иногда нет; сервис доступен только с части адресов; VPN поднимается, но трафик странно теряется; один интерфейс живой, а ответы уходят не туда; tcpdump показывает входящий пакет, но приложение его не видит.
▪️ Проверить можно так:
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter
Обычно значения такие:
0 - выключено
1 - strict mode
2 - loose mode
▪️ Что важно понимать:
strict mode хорош для простых хостов с одной понятной маршрутизацией. Но в сложной сетевой схеме он легко становится источником магических багов. Часто более безопасный компромисс - это loose mode:
sysctl -w net.ipv4.conf.all.rp_filter=2
sysctl -w net.ipv4.conf.default.rp_filter=2
Или точечно для интерфейса:
sysctl -w net.ipv4.conf.eth1.rp_filter=2
Полностью отключают обычно только там, где точно понимают, зачем это нужно.
#linux #network
🧑💻 NetworkAdmin | 908 |
| 14 | ❓ Кто жрет канал прямо сейчас
Когда сервер или рабочая машина внезапно начинают “тупить по сети”, первый вопрос обычно очень приземленный: кто именно сейчас жрет канал? Для такой быстрой диагностики есть две простые и очень полезные утилиты: iftop и nethogs. Обе показывают сетевую активность в реальном времени, но делают это по-разному.
iftop - показывает трафик между хостами
nethogs - показывает трафик по процессам
Именно в этом их главное различие.
▪️ iftop - кто с кем говорит. iftop похож на top, только для сети. Он показывает, какие IP-адреса и соединения прямо сейчас генерируют трафик, и в каких объемах.
Установка:
apt install iftop
Запуск:
iftop -i eth0
Что удобно в iftop:
• сразу видно самые тяжелые соединения;
• можно понять, идет ли трафик наружу или внутрь;
• удобно ловить внезапные бэкапы, репликации, выгрузки и подозрительные соединения.
Типичные находки:
сервер льет бэкап в удаленное хранилище;
кто-то качает большой файл по SCP;
приложение внезапно активно общается с внешним API;
контейнер или VM начали активно ходить в сеть.
Но здесь важно помнить: iftop показывает не процессы, а именно сетевые потоки между адресами.
▪️ nethogs - какой процесс виноват. Если нужен ответ не куда идет трафик, а какой процесс его генерирует, тогда удобнее nethogs.
Установка:
apt install nethogs
Запуск:
nethogs eth0
Теперь уже видно, сколько трафика потребляет конкретный процесс:
rsync
curl
docker
python
apt
любой другой живой процесс
Это особенно полезно, когда на хосте много сервисов, и по одним только IP трудно понять, кто виноват.
▪️ Когда что использовать
iftop - если нужно быстро понять: с какими IP идет обмен, какие соединения самые тяжелые, куда вообще уходит канал
nethogs - если нужно понять: какой процесс грузит сеть, кто именно качает или отдает данные, какой сервис стал шумным
⚠️ Важно
Обе утилиты обычно требуют root-права, иначе картина может быть неполной.
И еще: если трафик очень кратковременный, его легко не поймать. В таких случаях лучше смотреть несколько минут, а не пару секунд.
#linux #network
🧑💻 NetworkAdmin | 1 256 |
| 15 |  Заказал с алика видеокарту, это не обман?
#юмор
🧑💻 NetworkAdmin | 1 508 |
| 16 | 💚 Anycast простыми словами: где используется и зачем нужен
Обычно IP-адрес ассоциируется с одним конкретным сервером. Но в случае с Anycast один и тот же IP может быть объявлен сразу из нескольких точек сети. Идея простая: у разных серверов один и тот же IP-адрес, а трафик уходит туда, куда маршрут ближе с точки зрения сети. То есть клиент обращается к одному и тому же адресу, но реально попадает не обязательно на один и тот же физический сервер, а на ближайший или наиболее предпочтительный узел.
Где это удобно:
DNS-сервисы
CDN
DDoS-защита
глобальные edge-сервисы
публичные API
распределенные точки входа
Самый известный пример - публичные DNS. Когда вы отправляете запрос на 1.1.1.1 или 8.8.8.8, за этим IP обычно стоит не один сервер, а целая сеть узлов в разных регионах.
▪️Что это дает:
• меньше задержка. Пользователь попадает на ближайшую точку, а не тянется через полмира.
• лучше отказоустойчивость. Если один узел пропал, маршрутизация просто уводит трафик на другой.
• проще масштабирование. Можно добавлять новые точки присутствия, не меняя IP для клиентов.
• распределение нагрузки на уровне сети. Трафик естественным образом разъезжается по разным площадкам.
▪️ Как это выглядит по-простому:
есть 3 дата-центра - в Германии, Нидерландах и Польше. Во всех трех анонсируется один и тот же IP. Пользователь из Берлина, скорее всего, попадет в немецкий узел. Пользователь из Амстердама - в нидерландский. А если немецкий узел исчезнет из маршрутизации, трафик может уйти в ближайший оставшийся.
▪️ Почему это не магия:
Anycast сам по себе не знает, где лучше по задержке для приложения. Он опирается на маршрутизацию, обычно через BGP.
А значит ближайший - это не всегда географически ближайший, а тот, который сеть считает лучшим маршрутом.
▪️ Где часто путаются:
• думают, что Anycast - это обычный балансировщик. Не совсем. Балансировка тут происходит на уровне маршрутов, а не L7/L4-логики.
• считают, что клиент всегда попадет в один и тот же DC. Не обязательно. При изменении маршрутов путь может поменяться.
• пытаются использовать Anycast там, где нужна жесткая session affinity. Для stateful-сервисов это уже сложнее, потому что маршрут может измениться.
▪️ Где Anycast особенно хорош:
DNS;
stateless UDP-сервисы;
edge reverse proxy;
глобальные точки входа;
анти-DDoS платформы.
#network #anycast
🧑💻 NetworkAdmin | 1 386 |
| 17 | 🔎 xargs на практике
Когда в shell нужно обработать много файлов, хостов или строк, первый импульс обычно такой: написать for-цикл. Рабочий подход, но не всегда самый быстрый и удобный. Во многих таких задачах лучше использовать xargs - утилиту, которая берет поток данных из stdin и превращает его в аргументы для другой команды.
Проще говоря: нашли список объектов -> передали их в xargs -> массово обработали одной командой
▪️ Самый базовый пример:
cat hosts.txt | xargs ping -c 1
Но тут сразу важный нюанс: далеко не каждая команда умеет принимать много аргументов в таком виде. Поэтому на практике чаще используют -I или -n.
Например, пинговать хосты по одному:
cat hosts.txt | xargs -n1 ping -c 1
Здесь -n1 говорит: передавать по одному аргументу на запуск.
▪️ Полезный сценарий - массовая работа с файлами:
find /var/log -name "*.gz" | xargs rm -f
Но тут уже есть подводный камень: пробелы в именах файлов.
Безопасный вариант:
find /var/log -name "*.gz" -print0 | xargs -0 rm -f
Связка -print0 и xargs -0 - это почти обязательная привычка, если работаете с файлами.
▪️ Где xargs особенно хорош:
удаление и перемещение больших списков файлов;
массовый grep, chmod, chown;
обработка списков IP, URL, доменов;
запуск команд по данным из файла;
параллельное выполнение задач.
Например, проверить доступность списка хостов:
cat hosts.txt | xargs -n1 -P4 ping -c 1
-n1 - один хост на запуск
-P4 - до 4 процессов параллельно
Вот здесь xargs уже реально ускоряет работу. Особенно на больших списках, где последовательная обработка была бы слишком долгой.
▪️ Еще полезные примеры. Искать строку во множестве файлов:
find /etc -type f -name "*.conf" -print0 | xargs -0 grep -H "listen"
Или массово смотреть размер файлов:
find /backup -type f -print0 | xargs -0 du -h
Когда нужен шаблон с явной подстановкой, используют -I:
cat users.txt | xargs -I{} id {}
Здесь {} - место, куда подставляется значение из stdin.
▪️ Что полезно запомнить:
-n1 - по одному аргументу за запуск
-P4 - параллелить выполнение
-0 - безопасно работать с пробелами и спецсимволами
-I{} - явная подстановка значения в команду
#linux #xargs
🧑💻 NetworkAdmin | 1 113 |
| 18 | Колледж Президентской академии приглашает льготные категории граждан на бесплатную программу повышения квалификации «Специалист по безопасности в информационных системах».
По итогам обучения выдаётся удостоверение о повышении квалификации Президентской академии.
Это ваш шанс систематизировать знания и получить практические навыки, востребованные на рынке труда.
В результате обучения вы:
✔Освоите основы информационной безопасности: познакомитесь с ключевыми понятиями, классификацией угроз и нормативно‑правовой базой в сфере защиты информации, а также изучите международные стандарты и рекомендации.
✔Изучите методы и инструменты защиты данных: механизмы контроля доступа и разграничения полномочий, средства идентификации и аутентификации пользователей, способы защиты информации ограниченного доступа (без сведений, составляющих гостайну) — в т. ч. с применением криптографических средств.
✔Получите практические знания о криптографических методах защиты информации и их применении для обеспечения безопасности данных.
Обучение будет проходить с 7 по 30 сентября.
Формат: дистанционно.
👉Подать заявку можно до 17 августа включительно по ссылке https://trudvsem.ru/educational-programs/card?id=4c2df77b-b487-459a-8d24-72e711e477b2
Для помощи в оформлении заявки обращайтесь по телефону +7 905 724 3953
Будем рады видеть вас среди участников! | 957 |
| 19 |  Всегда на шаг впереди 😎
#юмор
🧑💻 NetworkAdmin | 1 653 |
| 20 | ❓ Что происходит на перегруженном TCP-сервере
Когда TCP-сервер начинает захлебываться под нагрузкой, проблема не всегда в CPU, памяти или плохом приложении. Иногда упирается сам механизм приема новых соединений. Чтобы понять, что происходит, полезно знать три вещи: SYN flood, backlog и somaxconn
▪️ Как выглядит обычное TCP-подключение:
клиент отправляет SYN
сервер отвечает SYN-ACK
клиент присылает ACK
соединение считается установленным
Но между "клиент постучался" и "приложение приняло соединение" есть очереди ядра.
▪️ Что может пойти не так:
SYN flood. Сервер получает огромное количество SYN, но рукопожатие не завершается. Это может быть атака, кривой балансировщик, сетевые потери или просто всплеск нагрузки. В итоге очередь полуоткрытых соединений заполняется, и новые клиенты начинают теряться.
backlog. Когда приложение вызывает listen(), оно указывает размер очереди ожидающих подключений.
Если приложение не успевает быстро принимать новые соединения через accept(), очередь переполняется.
Тогда часть клиентов начинает видеть: таймауты, connection refused, повторные SYN, странные задержки на подключении.
somaxconn. Это системный лимит ядра на максимальный backlog. Даже если приложение просит большую очередь, ядро все равно ограничит ее значением net.core.somaxconn.
Посмотреть можно так:
sysctl net.core.somaxconn
А заодно часто смотрят:
sysctl net.ipv4.tcp_max_syn_backlog
Первый параметр влияет на очередь установленных, но еще не принятых приложением соединений. Второй на очередь полуоткрытых SYN.
▪️ Что происходит на перегруженном сервере на практике:
приложение медленно вызывает accept()
очередь backlog заполняется
новые подключения начинают отваливаться
если сверху еще идет SYN flood, ситуация усугубляется
снаружи кажется, что сервер то работает, то нет
▪️ Как смотреть симптомы:
ss -lnt
netstat -s | grep -i listen
dmesg | grep -i syn
▪️ Что обычно помогает:
увеличить somaxconn;
проверить backlog самого приложения;
поднять tcp_max_syn_backlog;
включить или проверить SYN cookies;
разбираться, почему приложение медленно принимает соединения;
выносить защиту от flood на firewall/LB;
Например:
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
Но увеличение очередей не лечит корень проблемы. Если приложение не успевает обрабатывать подключения, вы просто делаете буфер больше. Это даст время, но не бесконечную защиту. Хорошая диагностика здесь начинается с простого вопроса: сервер не справляется с валидной нагрузкой или его забивают незавершенными SYN? Потому что снаружи это выглядит одинаково: TCP-порт открыт, а подключиться нормально уже нельзя.
#tcp #network
🧑💻 NetworkAdmin | 1 425 |
