Network Admin

Почему ss показывает тысячи соединений, а netstat - другую картину На одном сервере можно запустить:

ss -ant

и получить тысячи TCP-соединений, а затем: netstat -ant и увидеть совсем другое количество. Это не обязательно означает, что один из инструментов врёт. ss работает через современный интерфейс ядра Linux - NETLINK_INET_DIAG.

Ядро отдаёт ему информацию о сокетах напрямую, поэтому ss может получать состояние соединений без перебора /proc и без старого механизма netstat.

netstat из пакета net-tools - устаревший инструмент. Его возможности и способ получения данных отличаются, а часть информации может отображаться иначе. Особенно заметна разница на серверах с большим количеством ephemeral connections и быстро меняющимся состоянием TCP. Для диагностики лучше смотреть не просто количество строк:

ss -s

а разбивку состояний:

ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c

Например:

ESTAB      18420
TIME-WAIT   7312
SYN-RECV    428

И отдельно проверить конкретный listener: ss -lntp Важный момент: TIME-WAIT, SYN-RECV, ESTAB и listening sockets - это разные состояния kernel socket state. Поэтому простое сравнение «сколько строк показывает утилита» может давать совершенно разные выводы. ss сегодня является основным инструментом для анализа TCP/UDP-сокетов в Linux, а netstat в новых системах обычно оставляют только ради совместимости со старыми привычками и скриптами. N.A.

Один VLAN может проходить через несколько коммутаторов без единого L3-интерфейса VLAN не привязан к конкретному коммутатору. Если между устройствами настроен trunk, один и тот же broadcast domain может растянуться через несколько физических узлов. Например:

PC ── SW1 ══ SW2 ══ SW3 ── Server
      VLAN 30   VLAN 30   VLAN 30

На trunk-портах кадр VLAN 30 идёт с тегом 802.1Q. Проверка на Linux:

ip -d link show eth0.30

На Cisco:

show interfaces trunk
show vlan id 30

При этом шлюз VLAN может находиться вообще на другом устройстве:

PC → SW1 → SW2 → SW3 → Router
                         VLAN 30

Коммутаторы между ними работают только на L2 и не принимают решение о маршрутизации. Но есть важный нюанс: чем дальше растянут L2-домен, тем больше устройств получают его broadcast и unknown-unicast traffic. Поэтому проблема иногда выглядит как «сеть внезапно стала шумной», хотя IP-маршрутизация при этом вообще не менялась. N.A.

Ping 1 мс не всегда означает, что сеть работает быстро (но почему?) Можно получить RTT в 1–2 мс и при этом иметь очень плохую передачу данных. ping проверяет только время прохождения ICMP-пакета туда и обратно.

Он почти ничего не говорит о том, сколько пакетов реально теряется, насколько забит канал и что происходит с TCP при передаче.

Например, при потере даже небольшого процента TCP-пакетов скорость может резко просесть. Потерянный сегмент приходится передавать заново, а TCP дополнительно уменьшает congestion window. В итоге:

RTT = 2 ms
packet loss = 1%

может оказаться намного хуже для TCP, чем:

RTT = 50 ms
packet loss = 0%

Проверять нужно не только задержку:

ping -c 100 <server-ip>

но и реальные потери при передаче:

iperf3 -c <server-ip> -t 30

А на Linux посмотреть retransmissions:

ss -ti

Если в выводе растёт retrans, проблема уже не в том, что «ping маленький». Низкий RTT показывает, насколько быстро пакет возвращается. Он не показывает, насколько хорошо сеть передаёт поток данных. N.A.

АЙТИШНИКИ БЕСПЛАТНОЕ ОБУЧЕНИЕ Проект «Terminal» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков: • Практические курсы и задания • Книги и статьи известных авторов • Полезные инструменты и ресурсы • IT-новости и инсайды Обучение по всем направлениям: SQL, Python, ML, Frontend, PHP, C++, Go, Git, Linux, QA, Java, Vibe-coding, InfoSec и др. ⌨️ подписаться

Почему TCP-порт 443 - это не обязательно один TCP-порт? Когда говорят «сервер слушает 443 порт», легко представить один socket, который принимает все HTTPS-соединения. Но TCP идентифицирует соединение не только по порту назначения. Для него важна комбинация:

src IP + src port + dst IP + dst port

Например, сервер слушает:

10.0.0.10:443

А клиенты создают:

10.0.1.20:49152 → 10.0.0.10:443
10.0.1.21:49153 → 10.0.0.10:443
10.0.1.22:49154 → 10.0.0.10:443

Все три соединения приходят на один :443, но TCP воспринимает их как разные соединения. И именно поэтому веб-сервер может одновременно обслуживать тысячи клиентов через один порт. Но есть ещё интереснее. Один и тот же порт 443 могут одновременно слушать несколько процессов, если используется SO_REUSEPORT. Например:

ss -lntp | grep :443

несколько worker-процессов могут иметь собственные listening sockets на одном IP:443. Ядро само распределяет новые соединения между ними.

При этом уже установленное соединение не прыгает между процессами: выбранный socket становится владельцем конкретного TCP-потока.

Поэтому фраза «порт 443 занят веб-сервером» на практике скрывает сразу несколько уровней: 443 - номер порта IP:443 - endpoint 4-tuple - конкретное TCP-соединение socket - объект, через который процесс работает с этим соединением Именно поэтому один:443 способен обслуживать огромное количество независимых TCP-соединений одновременно. N.A.

📂 Почему Linux иногда отбрасывает корректный пакет из-за rp_filter Ситуация выглядит странно: маршрут до сервера есть, интерфейс поднят, tcpdump показывает входящие пакеты, но соединение не устанавливается. Одна из причин - Reverse Path Filtering. 1️⃣Что происходит Linux получает пакет от 10.20.30.50 на eth1 и проверяет, через какой интерфейс он сам отправил бы трафик обратно к 10.20.30.50. Если маршрут указывает на eth0, а пакет пришёл через eth1, ядро может решить, что источник подозрительный, и отбросить пакет. Проверить настройку:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter

2️⃣Почему это часто ломается Особенно заметно при: • нескольких uplink • ECMP • Policy-Based Routing • VRF • асимметричной маршрутизации • балансировщиках и firewall-кластерах Например:

Internet → eth1 → server
server → eth0 → Internet

Маршрутизация работает, но обратный путь отличается от входящего. 3️⃣Как увидеть проблему Сначала смотрим, куда ядро отправит ответ:

ip route get 10.20.30.50

Затем проверяем фактический входящий трафик:

tcpdump -ni eth1 host 10.20.30.50

Если пакет виден на интерфейсе, но приложение его не получает, стоит проверить фильтрацию на уровне ядра. 4️⃣Какие значения бывают

rp_filter=0 — проверка отключена

rp_filter=1 — strict mode, обратный маршрут должен совпадать с входящим интерфейсом

rp_filter=2 — loose mode, достаточно существования маршрута до источника

Для сложной маршрутизации strict mode часто становится источником трудноуловимых проблем. 5️⃣Что важно проверить перед изменением

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter

И обязательно смотреть не только all, но и параметры конкретного интерфейса - итоговое поведение зависит от них. N.A.

Default route из нескольких источников На маршрутизаторе одновременно живут default route из BGP, OSPF и static.

Все протоколы говорят, что выход есть, но трафик стабильно уходит через один uplink.

Смотреть только show ip route мало. Сначала интересно понять, что именно BGP считает лучшим кандидатом:

show ip bgp 0.0.0.0

А затем сравнить это с тем, что OSPF держит у себя:

show ip ospf rib 0.0.0.0

Здесь уже может выясниться, что оба протокола имеют рабочий default, но в общую RIB попадает только один. Дальше можно проверить конкретный поток:

show ip cef exact-route <src> <dst>

И увидеть, через какой интерфейс и next-hop он реально будет отправлен. Самый интересный случай - когда выбранный маршрут не устанавливается в FIB из-за проблем с recursive next-hop, и forwarding продолжает использовать другой доступный путь.

show ip cef 0.0.0.0 internal

👀 Получается несколько независимых решений: BGP выбирает свой best path, OSPF - свой, RIB выбирает источник, а FIB в итоге решает, куда уйдёт пакет. Именно на стыке этих уровней и появляются самые неприятные сюрпризы.

📘 DevOps-инженер: от основ до продакшена — новый курс на Mentorix Пишете код, но деплой и прод — чёрный ящик? Курс про инженерию эксплуатации: от первого сервера до автоматизированной CI/CD-инфраструктуры, которая держит нагрузку и не падает. ⚙️ Стек: Docker, Kubernetes, Ansible, Terraform, CI/CD, Prometheus + Grafana, логи ELK 🧩 Задания с автопроверкой + лабы в настоящем терминале 💻 Финальный проект в портфолио 🎓 Сертификат · доступ навсегда 🏷 −35% по промокоду DEVOPS35 — только 48 часов 13 990 ₽ → 9 094 ₽ ➜ Забрать курс со скидкой ━━━━━━━━━━━━━━ 🎁 А ещё на платформе — бесплатные курсы: Языки программирования ⚡ Golang — основы языка 🦀 Rust — основы языка 🐍 Основы Python Инфраструктура и DevOps 🖥 Основы DevOps 🐳 Docker: первые шаги 🔧 Git для начинающих Базы данных • SQL с нуля • MongoDB с нуля 📚 Все бесплатные курсы Mentorix

Cross-zone traffic и неожиданный latency Сервис вроде бы находится в одной VPC, но запросы между двумя компонентами внезапно становятся заметно медленнее. Особенно часто это всплывает после масштабирования: backend поднялся в другой зоне, а клиент продолжил ходить к нему через балансировщик или другой региональный компонент. Посмотреть, куда реально уходит соединение:

ss -tnp

Если адреса backend’ов принадлежат разным зонам, следующий вопрос - действительно ли трафик идёт напрямую между ними.

traceroute -T -p 443 <backend-ip>

Но одного маршрута мало. Интереснее сравнить latency до backend’ов в разных зонах:

mtr -T -P 443 <backend-ip>

Иногда разница небольшая на одном запросе, но начинает сильно влиять на p95/p99, когда сервис делает несколько последовательных обращений к другим компонентам.

Ещё неприятнее, когда frontend находится в одной зоне, application - в другой, а database - снова в первой. Один пользовательский запрос превращается в несколько cross-zone переходов.

⚡️В итоге проблема может выглядеть как “медленный backend”, хотя приложение просто постоянно гоняет данные между зонами. При масштабировании такие вещи легко пропустить, если смотреть только на CPU, RPS и средний latency. N.A.

netdev_budget и обработка большого потока пакетов При большом PPS сервер может начать терять пакеты, хотя канал ещё далеко не забит. Один из интересных параметров здесь - netdev_budget: сколько пакетов kernel может обработать за один проход NAPI. Посмотреть текущее значение:

sysctl net.core.netdev_budget

Если входящий поток постоянно превышает этот лимит, обработка переносится на следующие проходы. В результате растут очереди и latency, а CPU может выглядеть вполне нормально. Посмотреть, есть ли проблема именно на уровне softnet:

cat /proc/net/softnet_stat

Особенно интересны drops и количество обработанных пакетов. Если счётчики начинают быстро расти, проблема уже ближе к обработке пакетов ядром, а не к приложению. Ещё один параметр связан со временем, которое kernel готов потратить на один такой проход:

sysctl net.core.netdev_budget_usecs

И вот здесь начинается интересный баланс: слишком маленький budget может оставить пакеты ждать следующего прохода, а слишком большой - позволить сетевой обработке надолго занять CPU и повлиять на остальные задачи. На загруженном сервере поэтому полезно смотреть не только bandwidth, но и PPS, softirq, softnet drops и NAPI budget. N.A.

Один backend получает почти весь трафик

На графике LB всё выглядит подозрительно: три backend’а работают, healthcheck зелёный, но один получает 80–90% запросов.

Проверять сам алгоритм балансировки недостаточно. В L4 балансировке решение часто принимается для соединения, а не для каждого запроса. Для начала можно посмотреть распределение TCP-сессий на backend’ах:

ss -Htn state established '( sport = :443 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr

Если перекос уже здесь, проблема появилась до уровня HTTP. Дальше интересно посмотреть, как LB выбирает backend для разных потоков. При ECMP или L4 hashing одинаковые параметры потока могут постоянно попадать в один и тот же bucket.

ipvsadm -Ln --stats

Для IPVS здесь хорошо видны реальные counters по backend’ам, а не только состояние healthcheck. Ещё одна ловушка - connection reuse. Несколько тысяч HTTP-запросов могут ехать внутри небольшого количества долгоживущих TCP-соединений.

ss -Htn state established | awk '{print $4}' | sort | uniq -c | sort -nr | head

Поэтому RPS между backend’ами может отличаться в разы даже при идеально работающем алгоритме распределения соединений. Если используется persistence, sticky sessions или hash по source IP, перекос становится ещё сильнее: несколько крупных клиентов фактически могут “забрать” один backend целиком. И тогда проблема выглядит как сломанный балансировщик, хотя LB честно выполняет выбранную ему стратегию. N.A.

RIB vs FIB: маршрут существует, но пакет идёт иначе Маршрут есть в RIB, но пакет всё равно уходит не туда. Особенно неприятно это становится после изменений BGP, ECMP или policy routing. В Linux полезно сразу смотреть не только таблицу маршрутов, а конкретное решение forwarding для нужного адреса:

ip route get <ip> from <source-ip>

Здесь уже учитываются source address и выбранная таблица маршрутизации. Результат может отличаться от того, что вы видите обычным ip route. Для нескольких routing tables:

ip rule

Потому что маршрут в main может быть абсолютно правильным, но пакет до неё вообще не дойдёт. А дальше начинается интересное: control plane может считать маршрут лучшим, а dataplane уже использовать другую запись. На сетевом оборудовании это удобно проверять отдельно:

show ip route <prefix>
show ip cef <destination>

Первая команда показывает решение routing process, вторая - что реально установлено в forwarding table.

Если между ними есть расхождение, искать проблему уже нужно не в самом маршруте, а в процессе установки маршрутов в FIB, ECMP, next-hop resolution или policy routing.

Именно поэтому “маршрут есть” ещё не означает, что пакет пойдёт по этому маршруту. N.A.

Как поймать внезапный ARP-resolve timeout Когда «всё работает… но периодически что-то замирает», очень часто виноват ARP.

Хост просто не может быстро получить MAC адрес - и весь трафик встаёт на паузу. Особенно больно это бьёт по VoIP, SSH и интерактивным сервисам.

Обычно такие таймауты не видны в обычных логах, поэтому отлавливать их нужно вручную. 1️⃣Проверяем, как часто хост делает ARP-запросы Если сосед «теряется», хост начнёт усиленно спрашивать его MAC. Linux:

tcpdump -ni eth0 arp

Если видишь 2–3 повторяющихся ARP Requests подряд → проблема. Cisco:

debug arp

или

show arp

Если запись в ARP-таблице часто «флапает», это ненормально. 2️⃣Смотрим, что происходит в момент задержки Отслеживаем, пропадают ли ответы:

tcpdump -ni eth0 "arp or icmp"

Если ping висит, а в дампе есть ARP Requests без ARP Reply → таймаут найден. 3️⃣Проверяем ARP-таблицу на переполнения и expiry Если ARP-таблица забилась или записи слишком быстро удаляются → будут постоянные timeouts. Linux:

ip -s neigh

Подозрительные признаки: • состояние FAILED • резкий рост timeouts • записи часто переходят FAILED → REACHABLE → FAILED 4️⃣Проверяем ARP кэш на коммутаторе Иногда виноват L2 — коммутатор забывает MAC или шлёт фреймы не туда. Cisco:

show mac address-table dynamic | include <MAC>

Если MAC постоянно пропадает → проблема на сегменте. N.A.

Разбор странных MTU-проблем через PMTUD

Пинг проходит, TCP-соединение устанавливается, но большие файлы не скачиваются, HTTPS периодически зависает, а часть API-запросов просто уходит в таймаут.

Во многих случаях причина оказывается не в самом MTU, а в том, что Path MTU Discovery (PMTUD) перестал работать где-то по пути. Проверить, какой максимальный размер пакета реально проходит без фрагментации, можно так:

ping -M do -s 1472 <ip>

Если пакет не проходит, постепенно уменьшайте размер. Это позволяет быстро найти реальный MTU на маршруте. Полезно посмотреть и сам маршрут пакетов.

tracepath <ip>

В отличие от обычного traceroute, tracepath умеет определять PMTU и показывает, где он изменился. Если используется TCP, можно проверить MSS, который стороны согласовали при установке соединения.

tcpdump -i <iface> 'tcp[tcpflags] & tcp-syn != 0'

Иногда именно здесь видно, что MSS неожиданно уменьшился или вообще не соответствует ожидаемому MTU. Ещё один частый сценарий - ICMP Fragmentation Needed где-то фильтруется firewall’ом. В итоге PMTUD перестаёт работать, а соединение начинает “зависать” только на больших пакетах. 🔥Поэтому симптомы могут быть очень разными: открывается главная страница сайта, но не загружаются изображения, работает SSH, но зависает SCP, API отвечает на маленькие запросы и молчит на больших. Когда проблема проявляется настолько выборочно, проверка PMTUD обычно экономит часы поиска “неисправной сети”. N.A.

Firewall rule ordering: почему одно правило ломает всё ниже Добавили всего одно правило в firewall - и часть сервисов перестала работать.

При этом сами правила выглядят правильными, а нужные allow вообще присутствуют в конфигурации.

Во многих firewall обработка идёт сверху вниз, и первое совпавшее правило завершает проверку. Всё, что находится ниже, уже не участвует.

iptables -L INPUT --line-numbers -n -v

Сразу видно порядок правил и счётчики срабатываний. Нередко оказывается, что трафик вообще не доходит до нужного ACCEPT. Если используется nftables, полезнее смотреть итоговый ruleset, а не отдельные таблицы.

nft list ruleset

Так проще заметить цепочки, jump’ы и правила, которые перехватывают трафик раньше ожидаемого. Когда причина всё ещё неочевидна, помогает трассировка обработки пакета.

nft monitor trace

Она показывает, через какие цепочки проходит пакет и на каком именно правиле обработка заканчивается. Ещё один полезный приём - посмотреть, какое правило действительно набирает счётчики.

iptables -L -v -n

Иногда именно здесь выясняется, что проблема не в “неправильном” правиле, а в том, что до нужного правила пакет никогда не доходит. В больших конфигурациях порядок правил зачастую важнее их содержания. Одно слишком общее DROP, REJECT или широкое условие в начале цепочки способно незаметно перечеркнуть десятки корректных правил ниже. N.A.

PrivateLink / VPC Peering: скрытые ограничения

Две VPC связаны, маршруты настроены, Security Groups выглядят правильно, но часть сервисов всё равно не может обмениваться трафиком.

Похожая картина возникает, когда путают возможности VPC Peering и PrivateLink - внешне они решают похожую задачу, но работают совершенно по-разному. Если используется Peering, сначала стоит убедиться, что маршрут действительно существует.

ip route

Но даже при корректной маршрутизации может оказаться, что нужная сеть недоступна из-за отсутствия transitive routing. Через Peering нельзя “пройти транзитом” в третью VPC - каждая связь строится напрямую. Если используется PrivateLink, полезно проверить, к какому Endpoint вообще подключён сервис.

aws ec2 describe-vpc-endpoints

Здесь часто выясняется, что доступ есть только к опубликованному сервису, а не ко всей сети. PrivateLink вообще не предназначен для полноценного сетевого взаимодействия между VPC. Ещё один момент - DNS.

dig <service-endpoint>

При отключённом Private DNS часть клиентов продолжает обращаться по публичному имени, даже находясь внутри VPC, и диагностика начинает выглядеть очень запутанной. В итоге обе технологии соединяют VPC, но с разной логикой: VPC Peering даёт сетевую связность между подсетями без транзитной маршрутизации, а PrivateLink публикует конкретный сервис, вообще не открывая доступ к остальной сети. Именно из-за этого ограничения чаще всего всплывают уже в проде, а не на этапе настройки. N.A.

Классика 🤵‍♂️ N.A.

Издательский дом «Новые отраслевые медиа» собрал для вас лучшие каналы из сферы искусственного интеллекта и интернет-технологий, которые помогают своим подписчикам быть в курсе всех важных профессиональных новостей. Здесь - всё про ключевых игроков отрасли, государственное регулирование, инсайды и кейсы от отраслевых лидеров. ✅Серверная - канал об индустрии дата-центров: технологиях, инфраструктуре, облачных решениях, энергоэффективности и применении ЦОД в ключевых отраслях экономики. ✅Робосфера - канал об индустрии робототехники: технологии и тренды. Промышленные и сервисные роботы, коботы, автоматизация, ИИ, машинное зрение, автономные системы. ✅AI для бизнеса - всё об AI-решениях для бизнеса: внедрение, автоматизация, корпоративный ИИ, агенты. ✅ТехноРитейл - канал о производстве и продаже бытовой техники и электроники в России: бренды, e-com, маркетинг, retail tech. Подписывайтесь, и эти каналы смогут изменить вашу жизнь к лучшему! Реклама. Харламов А.Е. ИНН 712803816807. erid: 2W5zFJYj47T

Linux bridge против OVS: где какой подход нужен Оба варианта могут связать виртуальные интерфейсы и дать машинам сеть, но используются они обычно в разных сценариях. Linux bridge - это простой L2-коммутатор внутри ядра Linux. Его часто хватает для обычных серверов, небольших виртуализаций и контейнерных сетей.

bridge link

Можно посмотреть, какие интерфейсы подключены к bridge и как они себя ведут. Например, обычная схема с KVM выглядит так: VM подключается через tap-интерфейс, а bridge отправляет её трафик дальше в физическую сеть.

bridge vlan show

Но когда инфраструктура становится сложнее, появляются ограничения: нет удобного управления потоками, сложнее строить динамические политики и автоматизировать изменения. Тут появляется Open vSwitch.

ovs-vsctl show

OVS работает как программный коммутатор, но уже с ориентацией на большие виртуальные среды: OpenStack, SDN, сложные overlay-сети. Например, можно управлять потоками напрямую через OpenFlow:

ovs-ofctl dump-flows <bridge>

И видеть не просто подключённые интерфейсы, а правила, по которым реально принимаются решения о пересылке пакетов. Ещё один важный момент - масштабирование. Linux bridge отлично работает, пока сеть относительно статичная. OVS удобнее там, где нужно постоянно менять топологию, подключать новые сегменты и централизованно управлять политиками. N.A.

Основные причины ошибки «SSH Connection Refused» Ошибка «SSH Connection Refused» возникает, когда удаленный сервер отклоняет запрос на соединение. Это может быть вызвано различными причинами, от отсутствия клиента или сервера SSH до неправильных настроек. Вот основные причины и их решения: 1️⃣SSH-клиент не установлен Если на локальной машине отсутствует SSH-клиент, подключение к серверу невозможно. Проверьте, установлен ли SSH-клиент, командой:

ssh

Если команда не найдена, установите SSH-клиент: Для Ubuntu/Debian:

sudo apt install openssh-client

Для CentOS/RHEL:

sudo yum install openssh-client

2️⃣ SSH-сервер не установлен на удаленном хосте Чтобы принимать соединения, на сервере должен быть установлен SSH-демон. Проверьте это, выполнив команду:

ssh localhost

Если появляется сообщение «Connection refused», установите сервер OpenSSH: Для Ubuntu/Debian:

sudo apt install openssh-server

Для CentOS/RHEL:

sudo yum install openssh-server

3️⃣ Неверные учетные данные или IP-адрес Часто ошибка вызвана неправильным вводом имени пользователя, пароля или IP-адреса. Убедитесь, что данные верны, и проверьте, какой порт используется сервером: grep Port /etc/ssh/sshd_config 4️⃣ Служба SSH не работает Если служба SSH не запущена, сервер не сможет принимать соединения. Проверьте её статус:

sudo service ssh status

Если служба не активна, запустите её:

sudo systemctl start sshd
sudo systemctl enable sshd

N.A.