Сеть: TCP/IP, маршрутизация, файрвол

Что отвечать

Клиент шлёт SYN с своим ISN (initial sequence number). Сервер отвечает SYN-ACK: подтверждает клиентский ISN+1 и шлёт свой ISN. Клиент отвечает ACK на серверный ISN+1. После трёх пакетов оба знают начальные seq-номера друг друга, соединение в Established.

Что хотят услышать

Senior должен сказать: - ISN выбирается случайно (не нулём), чтобы избежать предсказуемости и hijacking-атак - в SYN-пакете клиент анонсирует свои опции: MSS, window scale, SACK permitted, timestamp - SYN-ACK от сервера тоже несёт его опции; финальный выбор - пересечение - после handshake начинается slow start: cwnd растёт от initial congestion window (10 сегментов на современном Linux) экспоненциально до ssthresh - при потере SYN - экспоненциальный backoff retry (1s, 2s, 4s...), управляется `net.ipv4.tcp_syn_retries`

Подводные камни

• ✗ Сказать что handshake это 3 RTT - нет, это 1 RTT (3 пакета, но клиент может слать данные с третьим ACK через TCP Fast Open)
• ✗ Забыть про опции в SYN - это важно для понимания tuning'а
• ✗ Перепутать SYN-flood защиту с SYN cookies - SYN cookies генерируют серверный ISN из хеша 4-tuple+secret, чтобы не держать half-open state

Follow-up

• ? Что такое TCP Fast Open и почему он не получил массового распространения?
• ? Как работают SYN cookies? Почему их включают только при атаке, а не дефолтом?
• ? Какие данные несёт SYN-ACK кроме подтверждения ISN?

Что отвечать

TIME_WAIT - состояние сокета на стороне инициатора закрытия после финального ACK. Длится `2*MSL` (Maximum Segment Lifetime) = 60s на Linux. Нужен чтобы поздние сегменты не попали в новое соединение с теми же `(src_ip, src_port, dst_ip, dst_port)` и чтобы FIN от пира гарантированно дошёл (можно переслать финальный ACK).

Что хотят услышать

Senior должен: - объяснить кто инициирует close - тот и оказывается в TIME_WAIT; на load-balancer'ах часто закрывают backend'ы, и LB страдает - назвать тюнинг: `tcp_tw_reuse=1` для исходящих, `SO_REUSEADDR` для bind LISTEN-сокета после рестарта, `ip_local_port_range` для расширения пула эфемерных портов - сказать что `tcp_tw_recycle` был выпилен в Linux 4.12 - он ломал NAT-сетки, потому что использовал timestamps - назвать симптом: `EADDRINUSE` при попытке bind на тот же порт, или исчерпание эфемерных портов на client-side

Подводные камни

• ✗ Сказать что MSL = 30s всегда - на разных ОС разный, на Linux 60s для 2*MSL зашиты в код
• ✗ Думать что `SO_REUSEADDR` решает client-side проблему - нет, он про bind() в LISTEN, не про исходящие соединения
• ✗ Рекомендовать `tcp_tw_recycle` - выпилен и опасен

Follow-up

• ? В какой именно момент сокет переходит в TIME_WAIT - после первого FIN или после финального ACK?
• ? Почему `tcp_tw_recycle` ломает NAT? Что с timestamps?
• ? Как Kubernetes/Istio-mesh страдают от TIME_WAIT и что с этим делают?

Что отвечать

MTU (Maximum Transmission Unit) - максимальный размер IP-пакета, который интерфейс готов отправить одним кадром. На Ethernet - 1500 байт. Если пакет больше - либо фрагментация на стороне отправителя, либо ICMP `Fragmentation needed` от роутера. В IPv6 фрагментация только источником, промежуточные узлы её не делают.

Что хотят услышать

Senior должен: - объяснить PMTUD (Path MTU Discovery): отправитель ставит DF-бит, получает ICMP back, уменьшает MTU; работает плохо если ICMP блокирован файрволом - это «PMTUD black hole» - назвать TCP MSS = MTU - 40 (IP header + TCP header) - для TCP есть отдельный механизм MSS clamping в файрволе - назвать типичный кейс: VPN/VXLAN/GRE-туннель добавляет 50+ байт overhead, и пакеты внутри туннеля должны быть меньше - иначе фрагментация или blackhole - jumbo frames (MTU 9000) - в дата-центрах для эффективности

Подводные камни

• ✗ Сказать что MTU всегда 1500 - это для Ethernet, на loopback 65536, на VXLAN-overlay 1450
• ✗ Забыть про DF-бит и его роль в PMTUD
• ✗ Не упомянуть MSS clamping - типичный фикс для VPN-проблем

Follow-up

• ? Что такое PMTUD black hole и как с ним бороться?
• ? Как `ping -M do -s 1472 <host>` тестирует MTU? Откуда 1472?
• ? В чём разница между MTU и MSS? Кто их анонсирует и когда?

Что отвечать

curl делает `getaddrinfo("google.com")` через glibc/musl. glibc идёт в NSS (`nsswitch.conf`) - обычно сначала `/etc/hosts`, потом DNS. DNS-запрос летит на nameserver из `/etc/resolv.conf` (на Ubuntu - это systemd-resolved на 127.0.0.53, который форвардит на реальные DNS). Резолвер ходит по DNS-иерархии: root → TLD → авторитативный.

Что хотят услышать

Senior должен назвать: - `getaddrinfo` (а не устаревший `gethostbyname`) и то, что NSS - это плагинная архитектура (LDAP, mDNS, sssd могут стоять перед DNS) - различить stub-resolver (в libc/systemd-resolved) и recursive resolver (8.8.8.8, кэширует ответы) - назвать `/etc/nsswitch.conf` строку `hosts: files dns` - порядок важен, `files` означает `/etc/hosts` - упомянуть `dig` как правильный CLI-инструмент (vs устаревший `nslookup`) - сказать что systemd-resolved на 127.0.0.53 - Ubuntu-only, на RHEL/Debian-stock это прямой `/etc/resolv.conf`

Подводные камни

• ✗ Сказать что curl сразу идёт в DNS - нет, идёт через NSS, и `/etc/hosts` override'ит всё
• ✗ Забыть про glibc cache и про nscd - лет 5 как deprecated, но встречается на legacy системах
• ✗ Не упомянуть что systemd-resolved слушает 127.0.0.53, и `dig` с `127.0.0.1` его не зацепит

Follow-up

• ? Чем отличаются stub-resolver и recursive resolver?
• ? Что такое `nsswitch.conf` и почему `files dns` - это правило по умолчанию?
• ? Как посмотреть кэш systemd-resolved? Как его очистить?

Что отвечать

nftables (с Linux 3.13) - современная замена iptables, ip6tables, arptables, ebtables. Единый синтаксис, единая kernel-подсистема (`nf_tables`), атомарные обновления через netlink (вместо iptables-restore), поддержка sets и maps. На Ubuntu 22+/Debian 12+ это дефолт.

Что хотят услышать

Senior должен: - объяснить что iptables «остался» как wrapper `iptables-nft` - те же команды, но под капотом nf_tables - назвать преимущества: одна команда `nft` для v4+v6+arp+bridge, атомарность правил (либо весь набор применяется, либо ничего), sets для эффективного matching больших списков IP - упомянуть netfilter hooks: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING - это «точки» в pipeline пакета, общие для обеих утилит - сказать что nftables использует BPF под капотом для performance

Подводные камни

• ✗ Сказать что nftables полностью несовместим - нет, есть `iptables-nft` shim для обратной совместимости
• ✗ Перепутать `nftables` (фронтенд) и `nf_tables` (kernel-подсистема)
• ✗ Забыть про существование `firewalld` (RHEL/CentOS frontend) и `ufw` (Ubuntu frontend) - это уровни поверх iptables/nftables

Follow-up

• ? Что такое netfilter hook? Назови все 5 в порядке прохождения пакета.
• ? Чем атомарные обновления в nftables лучше iptables-restore?
• ? Как работают `sets` в nftables и почему они быстрее цепочки правил?

Что отвечать

SNAT (Source NAT) - подменяет source-IP пакета на исходящем интерфейсе, нужен явный target IP. DNAT (Destination NAT) - подменяет dst-IP/port, используется для проброса портов на внутренние сервисы. MASQUERADE - частный случай SNAT, где исходящий IP берётся автоматически с интерфейса (для динамических IP типа домашнего DSL/4G).

Что хотят услышать

Senior должен: - различить SNAT и MASQUERADE: SNAT с фиксированным IP быстрее (не надо смотреть IP интерфейса каждый раз), но требует статичный IP - объяснить что под капотом NAT работает через conntrack - kernel хранит таблицу `(src, dst, port) -> (translated)` и восстанавливает обратное преобразование на ответных пакетах - назвать `nf_conntrack_max` и проблему его исчерпания на больших нагрузках (типичный SRE-инцидент) - привести примеры: SNAT на gateway-роутере для домашней сети в интернет; DNAT - на load-balancer'е (например, KubeProxy в iptables-режиме делает DNAT на pod-IP)

Подводные камни

• ✗ Перепутать SNAT и DNAT по направлению - SNAT всегда меняет SOURCE, DNAT всегда меняет DESTINATION, неважно куда пакет идёт
• ✗ Не упомянуть conntrack - без него NAT невозможен
• ✗ Думать что MASQUERADE работает быстрее SNAT - наоборот, MASQUERADE делает лишний lookup IP интерфейса каждый раз

Follow-up

• ? Что произойдёт когда `nf_conntrack_max` исчерпан?
• ? Как Kubernetes реализует Service через iptables DNAT?
• ? Что такое hairpin NAT и зачем он нужен?

Что отвечать

По таблице маршрутизации: ищется самый длинный префикс (longest prefix match), который покрывает destination IP. Если ничего не найдено - default route (`0.0.0.0/0`). Linux поддерживает несколько таблиц через **policy routing**: правило (`ip rule`) выбирает таблицу на основе source IP, fwmark, входящего интерфейса.

Что хотят услышать

Senior должен: - объяснить longest prefix match и почему `/32` route перебивает `/24` - назвать порядок: правила (`ip rule list`) → таблицы (`ip route show table N`) → кэш (`ip route get <dst>` показывает финальное решение) - привести пример policy routing: два провайдера, маршрут зависит от source IP (`ip rule add from 10.0.1.0/24 table isp_a`) - упомянуть `ip route get <dst> from <src>` как главную команду диагностики «почему пакет ушёл не туда»

Подводные камни

• ✗ Сказать что просто берётся «следующая запись в таблице» - нет, только самый длинный префикс
• ✗ Забыть про policy routing: на одноинтерфейсной машине его нет, но как только два uplinka - обязательно
• ✗ Не знать про `ip route get` - главный debug-инструмент

Follow-up

• ? Что показывает `ip route get 8.8.8.8 from 10.0.1.5`?
• ? Зачем нужны таблицы `local` и `main` в `ip rule`?
• ? Что такое VRF и чем оно отличается от policy routing?

Что отвечать

`ss -tlnp` - первое: проверь что процесс реально слушает порт на нужном интерфейсе. Если нет - проблема в сервисе/конфиге, tcpdump не нужен. Если порт открыт но connect не работает - `tcpdump -i any port N` чтобы увидеть приходят ли SYN-пакеты, и отвечает ли сервер.

Что хотят услышать

Senior должен: - показать workflow troubleshooting: layer за layer'ом, от низкого к высокому (interface up → IP назначен → маршрут есть → firewall пропускает → процесс слушает → отвечает) - назвать `ss -s` для summary connections, `ss -tnp` для активных TCP, `-l` для LISTEN - упомянуть что `ss` читает напрямую через netlink (быстрее netstat, который парсит `/proc/net/tcp`) - tcpdump для подтверждения «пакеты вообще доходят», но не как first-step diagnostic

Подводные камни

• ✗ Сразу прыгать в tcpdump без проверки `ss` - обычно причина инцидента уже видна в `ss`
• ✗ Использовать `netstat` вместо `ss` - netstat deprecated 10+ лет
• ✗ Забыть про `-p` (показать процесс) - без него непонятно кто держит порт

Follow-up

• ? Что покажет `ss -i` (с информацией о congestion window, RTT)?
• ? Как tcpdump-фильтр `tcp[tcpflags] & tcp-syn != 0` найдёт только SYN-пакеты?
• ? Чем `tcpdump -i any` отличается от `tcpdump -i eth0`?