Какой опыт работы с сетевыми протоколами и стеком

Что проверяют

Сможете ли вы разобрать сетевую проблему по слоям, а не перезапускать всё подряд. Типичное продолжение: «что происходит, когда вы открываете адрес в браузере» или «сервис недоступен из пода, ваши действия».

Как отвечать

Пройдите по стеку снизу вверх и на каждом уровне назовите, что настраивали и чем диагностировали:

• L2 и L3: ARP, адресация и CIDR, маршруты (ip route), MTU. Неверный MTU в туннелях и оверлейных сетях даёт зависания на крупных пакетах при работающем ping;
• L4: TCP с рукопожатием, окнами и состояниями TIME_WAIT и CLOSE_WAIT; UDP для DNS, метрик и QUIC. Смотреть через ss -tanp;
• DNS: записи A, AAAA, CNAME, MX, TXT, SRV, TTL и кэширование, dig +trace. В Kubernetes это CoreDNS и ndots:5 в resolv.conf пода, из-за которого короткие имена порождают лишние запросы;
• TLS: цепочка сертификатов, SNI, срок действия, проверка через openssl s_client -connect host:443 -servername host;
• HTTP: версии 1.1, 2 и 3 поверх QUIC, keep-alive, что означают 502 и 504 на балансировщике;
• контейнеры и Kubernetes: bridge и NAT в Docker, CNI-плагины вроде Calico и Cilium, Service через iptables или IPVS, Ingress, NetworkPolicy.

Затем один реальный разбор инцидента: симптом, какие команды запускали, где оказалась причина. Рабочий набор: curl -v, tcpdump, mtr, ss, dig. Пример должен быть вашим. Если крупных инцидентов не было, расскажите про стенд, где сами сломали MTU или DNS и нашли причину.

Где спотыкаются

Говорят «сеть работает, ping проходит». ICMP ничего не сообщает о доступности нужного TCP-порта и о правилах фильтрации на нём.

Путают CLOSE_WAIT и TIME_WAIT. Тысячи соединений в CLOSE_WAIT означают, что приложение не закрывает сокеты, это ошибка в коде, а не в настройках ядра.

Лечат любые сетевые сбои увеличением таймаутов или ещё одним балансировщиком, так и не найдя причину.