Он умеет анализировать живой трафик и уже записанные дампы, разбивая их на удобные блоки (Ethernet / IP / TCP), как его «большой брат» с графикой, но работает прямо в твоем терминале.

# Установка (Go-based)
go install github.com/gcla/termshark/v2/cmd/termshark@latest

# Запускаем перехват на интерфейсе eth0
termshark -i eth0

* CMD — это аргументы по умолчанию для ENTRYPOINT. Если вы укажете свои аргументы в конце `docker run`, они полностью заменят то, что написано в CMD.
* Pro-tip: На собеседовании скажите, что лучшая практика — использовать их вместе. Например: `ENTRYPOINT ["/usr/bin/nginx"]` и `CMD ["-g", "daemon off;"]`. Это позволяет гибко менять параметры запуска, не ломая логику образа.

1. Каждая инструкция (`RUN`, `COPY`, `ADD`) создает новый слой, который кешируется и занимает место.
2. Copy-on-Write: Если файл меняется в верхнем слое, он копируется из нижнего, что раздувает образ.
3. Безопасность и скорость: Маленький образ (на базе Alpine или Distroless) уменьшает "поверхность атаки" (меньше лишних утилит — меньше дыр) и ускоряет деплой в CI/CD.
Совет: Упомяните Multi-stage builds. Это сразу покажет, что вы умеете собирать оптимизированные образы, оставляя весь "мусор" (компиляторы, исходники) во временных контейнерах.

1. Порты (L4): Проверяем, слушает ли веб-сервер нужный порт (80/443) через `telnet` или `nc -zv`.
2. MTU: Если маленькие пакеты (пинг) проходят, а большие (HTTP-трафик) — нет, проблема в MTU/MSS на пути следования. Пакеты просто дропаются без фрагментации.
3. Firewall: Возможно, ICMP разрешен, а TCP/443 закрыт на внешнем или внутреннем (iptables/nftables) фаерволе.
4. SSL/TLS: Проверяем, не истек ли сертификат. Браузер может блокировать соединение, хотя сервер работает.

Load Average — это очередь процессов, ожидающих выполнения. Если CPU свободен, значит, процессы стоят в очереди Disk I/O (ожидание ввода-вывода).
Что делать: Смотрим колонку %wa (iowait) в top или запускаем iostat -x 1.
Причина: Скорее всего, «умирает» диск, перегружена дисковая полка или база данных делает тяжелый Swapping. Нужно искать процесс, который генерирует максимум чтений/записей через iotop.
Pro-tip: Упомяните, что LA может расти и из-за сетевых задержек (NFS/Samba), если файловая система примонтирована по сети и «отвалилась».

Если ICMP (пинг) летит быстро, проблема на уровнях выше.
DNS: Самая частая причина. Резолвер тормозит, и браузер тратит 5–8 секунд только на то, чтобы узнать IP сайта. Проверяем через dig или nslookup.
MTU/MSS: Если пинг (маленький пакет) проходит, а HTTP (большой пакет) — нет, значит, где-то на пути пакеты дропаются из-за фрагментации. Проверяем пингом с большой нагрузкой: ping -s 1472 -M do 8.8.8.8.
Браузер/Прокси: Проверяем настройки WPAD или наличие «кривых» корпоративных расширений/антивирусов, которые инспектируют трафик.

RAID 10 — это «зеркало страйпов».
Риски: Если вылетит второй диск в той же зеркальной паре — массив рассыплется и данные будут потеряны. Это критическая ситуация.
Действия: * Проверить статус массива через утилиту контроллера (например, perccli или mdadm).
Важно: Перед заменой убедиться, что у нас есть свежий бэкап. Ребилд (восстановление) — это огромная нагрузка на диски, и именно в этот момент чаще всего «сыпется» второй диск в паре.
Менять диск лучше в часы минимальной нагрузки на сервер, чтобы ускорить процесс ребилда и снизить риск отказа остальных дисков.

Техническое решение:
Создаем динамический список для блокировки тех, кто слишком активно стучится на 22 порт.

# Создаем таблицу и цепочку
nft add table inet my_filter
nft add chain inet my_filter input { type filter hook input priority 0 \; }

# Создаем сет для "плохих парней" с таймаутом в 1 час
nft add set inet my_filter blackhole { type ipv4_addr \; flags timeout \; }

# Добавляем правило: если более 5 попыток за минуту — в бан
nft add rule inet my_filter input tcp dport 22 meter flood { ip saddr timeout 1m limit rate over 5/minute } add @blackhole { ip saddr } drop

# Дропаем всех, кто в блэкхоле
nft insert rule inet my_filter input ip saddr @blackhole drop

* Плюсы: Огромное количество настроек, поддержка аппаратного ускорения в большинстве роутеров, работа на сетевом уровне (Layer 3).
* Минусы: Чудовищно сложная настройка (IKEv2, Phase 1, Phase 2, политики шифрования). Код IPsec в ядре Linux — это десятки тысяч строк, в которых до сих пор находят дыры.
* Кейс: Соединить два офиса на оборудовании Cisco/Mikrotik/Juniper.

* Плюсы: Скорость (быстрее IPsec и OpenVPN в разы), простота (всего ~4000 строк кода — легко проверить на баги), мгновенное соединение.
* Минусы: Работает только по UDP (может блокироваться суровыми провайдерами), по умолчанию не имеет динамического управления IP (но это решается обертками типа Tailscale или Netmaker).
* Кейс: Удаленный доступ для сотрудников, связь микросервисов, личный VPN.

# Посмотреть статус пиров и объем переданного трафика
sudo wg show

# Проверить наличие интерфейса и его параметры
ip address show wg0

# Статус соединений
sudo swanctl --list-sas
# ИЛИ (для старых версий)
sudo ipsec statusall

# Проверить политики безопасности в ядре
ip xfrm policy

Модель OSI — это карта для поиска неисправностей.
L1 (Физический): Горит ли линк на сетевухе? Не перебит ли кабель?
L2 (Канальный): Видим ли мы MAC-адрес соседа? Работают ли VLAN-ы? (Инструмент: `arp -a`).
L3 (Сетевой): Здесь живут IP и **Ping (ICMP)**. Маршрутизация пакетов между сетями.
L4 (Транспортный): Порты! TCP (с гарантией доставки) и UDP (быстро, но без гарантии).
L7 (Прикладной): Здесь живет HTTPS, DNS, SSH.
Суть: Если не работает сайт (L7), сначала проверь пинг (L3) и линк (L1). Идем снизу вверх.

Это процесс установления надежного соединения. Состоит из трех шагов:
1. SYN: Клиент шлет запрос «Привет, давай свяжемся, мой номер (Sequence Number) — X».
2. SYN-ACK: Сервер отвечает «Привет! Я согласен. Твой номер X подтверждаю, мой номер — Y».
3. ACK: Клиент говорит «Ок, твой Y подтверждаю, погнали данные!».
Зачем: Это гарантирует, что обе стороны готовы к передаче, и позволяет синхронизировать номера пакетов, чтобы данные пришли в правильном порядке.

* BGP (Border Gateway Protocol) — это протокол обмена маршрутами между Автономными Системами (AS). Весь интернет — это лоскутное одеяло из AS.
* Суть проблемы: В BGP нет встроенной проверки доверия. Если крупный провайдер (или злоумышленник) случайно анонсирует, что «самый короткий путь к серверам Google лежит через меня» (BGP Hijacking), весь мировой трафик пойдет туда и «умрет».
* Пример: Именно из-за ошибок в BGP-конфигурациях случались глобальные сбои у Facebook и WhatsApp, когда они буквально «исчезали» из глобальной таблицы маршрутизации.

Мы переходим на XDP (eXpress Data Path). Это база для современного сетевого админа. XDP позволяет запускать eBPF-код прямо в контексте драйвера сетевой карты, до того, как ядро вообще начнет создавать структуру `sk_buff`.

Под капотом: Пакет перехватывается на уровне RX-очереди. Мы можем либо пробросить его дальше (XDP_PASS), либо мгновенно аннигилировать (XDP_DROP), либо отправить обратно (XDP_TX). Это дает нам производительность, близкую к DPDK, но без необходимости писать драйверы в пользовательском пространстве и терять интеграцию с ОС.

# 1. Устанавливаем xdp-tools (стандарт для современных дистрибутивов)
# 2. Вешаем фильтр, который будет дропать всё, что не соответствует нашим ACL
# на уровне драйвера (native mode) или программно (skb mode)

xdp-loader load eth0 ./drop_malicious_traffic.o --mode native

# 3. Мониторим статистику прохождения пакетов через eBPF-карты
bpftool map dump name xdp_stats_map

# Пример простейшего правила для xdp-filter (современная замена многим задачам iptables)
xdp-filter load eth0 -p ipv6 --ip 2001:db8:dead:beef::/64 -a drop

Экономия ресурсов CPU. Пока

тратит циклы на разбор каждого заголовка, XDP просто «срезает» ненужное на входе. Это единственный способ держать аптайм, когда на твой ARM-кластер прилетает «привет» от ботнета в пару терабит.

Переходим на связку iproute2 (`ip`) и **iproute2-ss** (`ss`).
Под капотом: Старый `netstat` читает информацию из `/proc/net/`, что при большом количестве соединений превращается в пытку для CPU и диска. Современная утилита `ss` (Socket Statistics) использует механизм Netlink, запрашивая данные напрямую у ядра. Это в десятки раз быстрее и точнее, особенно когда у тебя тысячи IPv6-соединений.

# 1. Вместо 'ifconfig' — смотрим адреса и статистику ошибок на интерфейсе
ip -c -s link show eth0
ip -6 addr # Только IPv6, только хардкор

# 2. Вместо 'netstat -tulpn' — ищем, кто слушает порты
# -l (listening), -n (numeric), -p (process), -t (tcp), -4/6 (family)
ss -ltnp4

# 3. Киллер-фича: ищем все соединения от конкретного IP, которые тупят
ss -o state established '( dport = :http or sport = :http )'

# 4. Мониторим изменения в сети в реальном времени (кто поднял интерфейс, кто упал)
ip monitor

Для личного спокойствия. Когда сервер под нагрузкой «приляжет», старый `netstat` может просто зависнуть, пытаясь распарсить `/proc`. `ss` выдаст результат мгновенно, позволив тебе быстро найти и отстрелить проблемный процесс.

1. Проверка порта: Не надо гадать, закрыл ли порт фаервол в «цифровой крепости».
2. Трассировка: Сразу показывает маршрут до цели.
3. Диагностика: Выдает детальную инфу, почему пакет не дошел.

# Просто проверить, открыт ли порт веб-сервера
tnc 192.168.1.50 -Port 443

# Сделать проверку и сразу увидеть маршрут (TraceRoute)
tnc google.com -TraceRoute

# Проверить только ICMP (старый добрый пинг, но с нормальным объектом на выходе)
tnc 8.8.8.8 -InformationLevel Detailed

1. Скорость: Она берет информацию напрямую из недр ядра (через tcp_diag), а не сканирует файлы в /proc, что критично на серверах с тысячами соединений.
2. Детализация: Она показывает гораздо больше внутренней информации о TCP-стеке, включая таймеры и параметры заторов.
3. Фильтры: Ты можешь искать соединения не просто через grep, а используя встроенные фильтры по состояниям или портам.

# Показать все слушающие TCP и UDP порты с именами процессов
ss -tulpn

# Показать только установленные соединения (Established)
ss -t state established

# Найти все соединения с конкретным IP
ss dst 192.168.1.50

1. Приложение поднимает локальный SOCKS5-прокси на вашем компьютере.
2. Весь трафик мессенджера упаковывается в WebSocket-соединение.
3. Провайдер видит это как обычный HTTPS-трафик к домену web.telegram.org (веб-версии мессенджера), которую обычно не трогают, чтобы не ломать работу браузерных версий.

* Rust внутри: Приложение весит всего 6 мегабайт и почти не ест ресурсы системы.
* Автоматизация: Программа сама определяет нужный дата-центр Telegram по IP-адресу назначения и направляет трафик на правильный эндпоинт.
* DNS-защита: При запуске софт меняет DNS на 1.1.1.1 (Cloudflare), чтобы обойти блокировки на уровне имен.
* Чистый Open Source: Весь исходный код доступен на GitHub, можно проверить лично, что ваши ключи никуда не улетают.

1. Скачиваешь бинарник из раздела Releases на GitHub проекта tglock.
2. Запускаешь приложение. Оно само пропишет нужные настройки в системе.
3. В настройках Telegram (Продвинутые настройки -> Тип соединения) убеждаешься, что выбран пункт Использовать системные настройки прокси или вручную указываешь SOCKS5 (localhost и порт, который выдаст программа).

1. Видно потери на каждом этапе: Если пакеты пропадают на втором хопе — виноват твой роутер или провайдер. Если на последнем — проблема на целевом сервере.
2. Отслеживание джиттера: Ты видишь не просто средний пинг, а то, как он скачет в реальном времени.
3. Отчеты для провайдера: Можно запустить mtr в режиме отчета и отправить его техподдержке как неопровержимое доказательство их лагов.

# Запустить интерактивно (самый частый вариант)
mtr google.com

# Выдать отчет за 10 циклов проверки (удобно для пересылки)
mtr -rw -c 10 8.8.8.8

Чтобы не гадать. mtr сразу показывает, является ли задержка разовой аномалией или это стабильная проблема конкретного узла в сети. В 2026-м сеть стала сложнее, и такие инструменты — твой основной радар.

В 2026 году стандарт де-факто — это утилита `ss` (Socket Statistics). Она общается напрямую с ядром через Netlink, поэтому работает молниеносно даже на серверах с десятками тысяч открытых соединений.

# Классика: показать все слушающие порты (TCP/UDP) с процессами
ss -tulnp

# Найти все established соединения на 443 порт (считаем клиентов)
ss -tan state established '( sport = :443 )'

# Показать сводную статистику по сокетам (кто съел лимиты)
ss -s

При DDoS-атаке или мощном всплеске трафика `netstat` может просто зависнуть, пытаясь прочитать статус тысяч сокетов. `ss` отдаст вам результат мгновенно, позволив быстро заблокировать проблемные IP через iptables/nftables.

Привычки — это хорошо, но ИТ не стоит на месте. Переучиваем мышечную память на две буквы `ss`.

Как делать правильно:
1. Default Deny: Последнее правило всегда `Drop All`. Разрешено только то, что явно описано выше.
2. Формат комментария: `[Дата] - [Кто запросил/Номер тикета] - [Причина]`.
* Пример: "2026-04-03 - Ticket#1024 - Доступ вендору CRM к базе данных. Удалить 01.05.26"
3. Группировка: Разделяйте правила на смысловые блоки: Management, Internal, DMZ, Outbound.

Давайте напишем код для RouterOS, который проверяет время последнего рукопожатия и выключает пир, если его не было слишком долго.

:local maxIdleDays 30;
/interface wireguard peers
:foreach peer in=[find] do={
:local lastHandshake [get $peer last-handshake];
:if ([:len $lastHandshake] > 0) do={
:local idleTime ([/system clock get time] - $lastHandshake);
:if ($idleTime > "30d 00:00:00") do={
disable $peer;
:log warning ("Отключен неактивный WireGuard пир");
}
}
}

Для жесточайшей гигиены периметра. Неиспользуемые доступы — главная дыра в безопасности. Если подрядчик уволился, а вы забыли закрыть доступ, этот скрипт подстрахует вашу сеть.

# На управляющем сервере (Ubuntu 24.04 LTS)
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/netbird_management_linux_amd64.tar.gz \
  | tar -xz -C /usr/local/bin

# Используем официальный docker-compose (рекомендуемый путь)
wget https://raw.githubusercontent.com/netbirdio/netbird/main/infrastructure_files/docker-compose.yml
wget https://raw.githubusercontent.com/netbirdio/netbird/main/infrastructure_files/.env.example -O .env

# Правим .env: домен, TURN-сервер, OIDC-провайдер (или отключаем auth для лаборатории)
nano .env

docker compose up -d

# На каждом узле (Linux, Windows, macOS — клиент один и тот же)
curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --management-url https://your-netbird-domain:443 --setup-key YOUR_KEY

# Устанавливаем Cilium с отключённым kube-proxy (k3s / kubeadm)
# При инициализации кластера убираем kube-proxy:
kubeadm init --skip-phases=addon/kube-proxy

# Устанавливаем Cilium через Helm
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443 \
  --set bpf.masquerade=true

# Проверяем что kube-proxy replacement активен
cilium status --verbose | grep -i "kube-proxy"
# KubeProxyReplacement: True

# Смотрим BPF-таблицы сервисов напрямую
cilium service list
cilium bpf lb list

# Мониторинг сетевых событий в реальном времени
cilium monitor --type drop