Почему netstat лжёт: как ss показывает реальную картину с сокетами

В современном Linux часто применяются инструменты для мониторинга сетевых соединений.

Несмотря на свою популярность, утилита netstat уже не всегда предоставляет точную информацию о состоянии сокетов.

Неточное отображение состояний с netstat

Netstat долгое время был основным инструментом для вывода информации о сетевых соединениях, но его алгоритмы и подходы к сбору статистики имеют ограничения:

⏺Netstat опирается на данные из /proc, которые могут не отражать динамическое изменение состояния сокетов. В результате он часто показывает устаревшую информацию, например, “мертвые” или заброшенные сокеты, которые уже не участвуют в активной передаче.

⏺При анализе состояний, таких как FIN_WAIT2, netstat может некорректно интерпретировать “зависшие” соединения. Это может ввести администратора в заблуждение относительно истинной загрузки и стабильности системы.

Преимущества ss: точные и детальные данные

Современный инструмент ss (socket statistics) из пакета iproute2 разработан для замены netstat и предоставляет гораздо более подробную и актуальную информацию о сетевых сокетах.

Он способен отсеивать “мертвые” соединения, корректно отображать переходные состояния и использовать расширенные опции для фильтрации и диагностики.

Например, чтобы увидеть информацию о TCP-сокетах, можно воспользоваться командой:

ss -tan

Здесь ключи означают:
• -t – вывести только TCP-соединения,
• -a – показать все (слушающие и установленные),
• -n – вывод номеров портов в числовом виде.

Если вам нужно проверить, какие сокеты находятся в “FIN_WAIT2” состоянии, команда ss покажет их корректно, благодаря более точной сборке данных из ядра:

ss -tan state fin-wait-2

Особенно полезна опция -K. Этот параметр позволяет отправлять запросы к ядру для получения более глубокого анализа по каждому сокету – например, чтобы определить, какие “зависшие” сокеты реально не используются.

Это даёт возможность отфильтровать ложные сигналы и сконцентрироваться на проблемных соединениях. Пример использования:

ss -K state established

Эта команда попытается “убить” (удалить) неактивные или ошибочные соединения, предоставляя отчёт о том, какие сокеты останутся в системе после вмешательства. Такой уровень контроля невозможен с netstat.

🎉Linux исполнилось 34 года

25 августа 2025 года Linux отметила 34-летие.

В 1991 году студент Хельсинкского университета Линус Торвальдс создал ядро «для хобби», а сегодня оно управляет миллиардами устройств — от смартфонов до суперкомпьютеров, от МКС до марсоходов.

Первый пост Торвальдса в группе comp.os.minix остался в истории: он писал, что делает ОС «просто ради интереса» и не обещает многого. Через несколько месяцев Linux уже могла запускать bash и gcc.

Сегодня проект поддерживают тысячи разработчиков по всему миру. Только в 2024 году на разработку ядра ушло $6,8 млн, а в июле 2025 года вышло Linux 6.16 под кодовым названием Baby Opossum Posse.

⏺Торвальдс уверяет: формального плана преемственности нет и не нужно — сообщество само найдёт «следующего великодушного повелителя».

SSH Multiplexing и ControlMaster

Быстрее подключение к серверу без лишних рукопожатий

По умолчанию каждый вызов ssh открывает новый TCP-сокет, проходит ключевое рукопожатие, обмен алгоритмами, аутентификацию. Это безопасно, но затратно по времени.

Multiplexing решает проблему: первая сессия открывает основной канал (master), а все остальные используют его.

Для этого в OpenSSH есть опции ControlMaster, ControlPath и ControlPersist.

Настройка

1️⃣ Создаём папку под сокеты:

mkdir -p ~/.ssh/sockets
chmod 700 ~/.ssh/sockets

2️⃣ Добавляем в ~/.ssh/config:

Host myserver
    HostName 192.168.1.10
    User admin
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h:%p
    ControlPersist 10m

Проверка в реальной работе

Первый запуск (идёт полная авторизация):

time ssh myserver exit

Обычно ~0.4–0.6 сек.

Второй запуск (через мастер-сессию):

time ssh myserver exit

Результат: 0.02 сек. Почти мгновенно.

То же с scp:

scp test.txt myserver:/tmp/

Файл начинает копироваться без задержки.

LVM snapshots: быстрые бэкапы и откаты

LVM (Logical Volume Manager) позволяет работать с томами гибче, чем с обычными разделами.

Одна из ключевых возможностей — снапшоты: копия состояния тома в определённый момент времени.

Это полезно для бэкапов и экспериментов: можно сохранить снимок, обновить систему или базу, и при ошибке — откатиться.

Практика

1️⃣Проверяем тома

lvdisplay

Находим имя LV, например vg0/data.

2️⃣ Создаём снапшот

lvcreate -L 5G -s -n data_snap /dev/vg0/data

• -L 5G — размер для изменений (чем больше активность, тем больше нужно).
• -s — создаём снапшот.
• -n — имя снапшота.

3️⃣ Монтируем снапшот

mkdir /mnt/snap
mount /dev/vg0/data_snap /mnt/snap

Теперь можно сделать копию файлов без остановки сервиса.

4️⃣ Откат к снапшоту
Если после обновлений что-то пошло не так:

umount /dev/vg0/data
lvconvert --merge /dev/vg0/data_snap
reboot

После перезагрузки том вернётся к состоянию снапшота.

5️⃣ Удаление снапшота
Когда копия больше не нужна:

lvremove /dev/vg0/data_snap

RAID уровня выше 5

Почему админы выбирают RAID10 или ZFS вместо RAID6

RAID5 и RAID6 долгое время считались «золотым стандартом» для балансировки между надёжностью и экономией диска.

Но с ростом объёмов накопителей и нагрузок они стали проблемными.

Минусы RAID6 при больших дисках:

1️⃣Восстановление после сбоя (rebuild) может занимать сутки и больше. Всё это время массив работает медленнее и под угрозой.
2️⃣ Чем больше диски, тем выше шанс ошибки чтения (URE) во время rebuild. В худшем случае массив падает целиком.
3️⃣ Запись требует вычисления чётности, что сильно режет IOPS.

Почему выбирают RAID10: RAID10 сочетает зеркалирование и страйпинг. Это даёт простую архитектуру и высокую скорость.

При отказе диска нужно восстановить только одну половину пары, поэтому rebuild проходит заметно быстрее.

Почему выбирают ZFS

ZFS идёт дальше классического RAID:

⏺каждая операция проверяется контрольной суммой, что защищает от silent data corruption;
⏺встроены снапшоты и репликация;
⏺пулы расширяются гибко, без жёстких ограничений железного RAID-контроллера;
⏺RAIDZ позволяет балансировать между избыточностью и ёмкостью, при этом сохраняя контроль над целостностью.

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое Memory Overcommit в Linux и какие риски с ним связаны?

✅Ответ: Memory Overcommit — это возможность ядра Linux разрешать процессам выделять больше виртуальной памяти, чем физически доступно в системе.

Это удобно для серверов с большим количеством приложений, которые не используют всю выделенную память одновременно, но создает риск, что при внезапной нагрузке система столкнется с нехваткой памяти. В таких случаях срабатывает oom-killer, завершая процессы для освобождения ресурсов.

LVM snapshots: пример с PostgreSQL

В прошлый раз я показал, как снапшоты LVM позволяют быстро «замораживать» состояние тома. 

Теперь разберём практическое применение — резервное копирование PostgreSQL без остановки сервиса.

Снапшоты работают по принципу copy-on-write: при изменении данных в оригинальном томе старая версия сохраняется в снапшоте.

⏺Чтобы результат был хорошим, нужно принудительно записать все буферы базы на диск.

sudo -u postgres psql -c "CHECKPOINT;"
sync

Шаги бэкапа

1️⃣Создать снапшот:

lvcreate -L 2G -s -n pgdata_snap /dev/vg0/pgdata

2G — примерный размер под изменения на время копирования.

2️⃣ Смонтировать снапшот:

mkdir /mnt/pgsnap
mount /dev/vg0/pgdata_snap /mnt/pgsnap

3️⃣ Скопировать файлы:

rsync -a /mnt/pgsnap/ /backup/pgdata-$(date +%F)/

4️⃣ Очистить:

umount /mnt/pgsnap
lvremove /dev/vg0/pgdata_snap

SSH к Cisco без пароля: настройка через RSA-ключи

SSH-аутентификация по ключам давно стала стандартом в Linux/Unix-мире, а Cisco IOS (и NX-OS) поддерживает её ещё с начала 2000-х.

Основное преимущество ключей перед паролями:

⏺невозможно перебрать брутфорсом (если ключ длинный),
⏺админ не хранит пароли в заметках/Excel,
⏺удобно централизованно управлять доступом: добавил или удалил ключ в pubkey-chain — и доступ сразу появился/пропал.

У каждого пользователя есть пара ключей: приватный (хранится у него) и публичный (копируется на устройство).

При подключении клиент доказывает владение приватным ключом, а Cisco сравнивает это с публичным — если совпадает, вход разрешён.

В отличие от классической схемы логин+пароль, тут нет ввода секретов в консоль, поэтому утечка через keylogger или сниффинг невозможна (при условии, что приватный ключ защищён паролем).

Практика

1️⃣Включаем SSH на Cisco

conf t
ip domain-name lab.local
crypto key generate rsa modulus 2048
ip ssh version 2

2️⃣Создаём пользователя

username admin privilege 15 secret StrongPass123

3️⃣Подтягиваем публичный ключ
На клиенте:

ssh-keygen -t rsa -b 2048

Копируем содержимое ~/.ssh/id_rsa.pub и добавляем на Cisco:

ip ssh pubkey-chain
  username admin
   key-string
    ssh-rsa AAAAB3... user@host
   exit
 exit

4️⃣Ограничиваем доступ только по ключам

line vty 0 4
 transport input ssh
 login local

Теперь при подключении:

ssh admin@router

пароль не нужен.

Нюансы

⏺Можно завести нескольких пользователей с разными ключами.
⏺При увольнении сотрудника ключ просто удаляется из pubkey-chain → не надо менять общий пароль.
⏺Минимальный размер ключа лучше 2048, а в проде — 4096 бит.
⏺Рекомендовано всегда включать только SSHv2 — SSHv1 давно небезопасен.

NAT64 и DNS64: доступ IPv6-only клиентов к IPv4 ресурсам

В сетях, где используется только IPv6, часто возникает проблема: клиентам нужно обращаться к сервисам, которые ещё доступны только по IPv4. Решение — комбинация NAT64 и DNS64.

DNS64 преобразует A-записи IPv4 в синтетические AAAA-записи IPv6. 

Когда клиент делает запрос к IPv4-хосту, он получает IPv6-адрес, который указывает на NAT64-шлюз.

NAT64 на маршрутизаторе или сервере превращает этот IPv6-трафик обратно в IPv4 и перенаправляет его к целевому серверу. Ответ идёт обратно по тому же пути.

Где применяют:
⏺IPv6-only датацентры или филиалы, где внутренние клиенты не имеют IPv4.
⏺Переходные сценарии при массовой миграции на IPv6.
⏺Обеспечение совместимости с внешними сервисами, которые не поддерживают IPv6.

Пример конфигурации на Cisco IOS:

! Создание NAT64-пула
ipv6 nat64 v6v4-pool POOL1 192.0.2.0 192.0.2.255 prefix-length 96
! Включение NAT64 на интерфейсе
interface GigabitEthernet0/1
ipv6 nat64 enable
! Включение DNS64 на Cisco IOS XE
ipv6 dns64 64:ff9b::/96

На Juniper JunOS это выглядит так:

set security nat64 pool NAT64-POOL address 192.0.2.0/24
set security nat64 interface fe-0/0/0.0
set system services dns dns64 prefix 64:ff9b::/96

И еще советы:
➖Проверяйте, что префикс NAT64 корректно согласован с DNS64.
➖Не все приложения корректно работают через NAT64 (например, некоторые старые FTP-клиенты).
➖Мониторьте нагрузку на NAT64-шлюз, он становится точкой концентрации трафика.

Используя NAT64/DNS64, можно постепенно убирать IPv4 из инфраструктуры без потери совместимости с внешними сервисами.

TCP Tuning для высокой нагрузки

В больших сервисах стандартные сетевые настройки ядра Linux иногда становятся узким местом.

Например, при сотнях тысяч одновременных соединений сервер может «терять» пакеты SYN, а TCP-сессии застревать в TIME_WAIT. Чтобы этого избежать, настраивают несколько параметров через sysctl.

Основные параметры

1️⃣net.core.somaxconn
Определяет максимальное количество ожидающих соединений в очереди listen().

# посмотреть текущее значение
sysctl net.core.somaxconn
# увеличить до 65535
sudo sysctl -w net.core.somaxconn=65535

2️⃣ tcp_max_syn_backlog
Размер очереди незавершённых TCP-соединений (SYN). Важно при пиковых нагрузках.

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096

3️⃣ tcp_fin_timeout
Время удержания соединений в FIN_WAIT2, которое может «засорять» сервер.

sudo sysctl -w net.ipv4.tcp_fin_timeout=15

4️⃣ tcp_tw_reuse и tcp_tw_recycle (внимание: tcp_tw_recycle устарел и опасен для NAT)
Позволяет повторно использовать TIME_WAIT-сессии для новых соединений.

sudo sysctl -w net.ipv4.tcp_tw_reuse=1

Проверка эффекта

➖Посмотреть количество TIME_WAIT-соединений:

ss -s | grep timewait

➖Нагрузить сервер с помощью ab или wrk и сравнить, сколько соединений сервер держит без потерь.

Автоматизация

Чтобы настройки сохранялись после перезагрузки, добавьте их в /etc/sysctl.conf:

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

и примените:

sudo sysctl -p