Вопросы по сетям на собеседовании DevOps

Сети на собесе эксплуатации это диагностика, а не теория уровней OSI. Чем 502 отличается от 504, почему после смены A-записи часть трафика идёт на старый сервер, откуда десятки тысяч сокетов в TIME_WAIT и почему большие запросы висят, а маленькие проходят.

Что спрашивают

• +TCP: рукопожатие и закрытие, TIME_WAIT, keepalive и прикладные таймауты
• +DNS: TTL и кэш резолверов, search-домены и ndots в кластере, ограничения CNAME на вершине зоны
• +HTTP и TLS: коды шлюза, SNI и выбор сертификата, полная цепочка против листового
• +Балансировка и фильтрация: L4 против L7, proxy_pass и путь запроса, X-Forwarded-For, NAT и публикация портов контейнера

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• TCP/IP и сокеты7
• Балансировка и прокси7
• Фаерволы, NAT, диагностика7
• DNS6
• HTTP и TLS6

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• TCP на практике: TIME_WAIT и таймауты7 вопросов
• DNS: TTL, search-домены, записи6 вопросов
• HTTP-коды прокси и TLS-рукопожатие6 вопросов
• Балансировка L4 и L7, proxy_pass7 вопросов
• Фаерволы, NAT и проблемы MTU7 вопросов

Примеры вопросов с разбором

1. #dvo_net_dns1 / 9
   Переключили A-запись на новый IP, но часть трафика сутки шла на старый сервер. Почему?

   A)Записи распространяются по корневым серверам сутки

   B)Старый сервер отвечал быстрее, и клиенты выбирали его

   C)Смена IP требует перевыпуска сертификата, до этого работает старый маршрут

   D)Резолверы и клиенты держали запись в кэше до истечения TTL

   показать ответ и разбор

   +D)Резолверы и клиенты держали запись в кэше до истечения TTL

   // разбор: TTL записи — это разрешение кэшировать её указанное время: провайдерские резолверы, ОС и рантаймы приложений будут отдавать старый адрес, пока срок не истечёт. Потому переезды планируют заранее: за сутки TTL опускают до 60-300 секунд, переключают запись, ждут, потом возвращают обычное значение. Старый сервер держат живым, пока не иссякнет трафик.

2. #dvo_net_firewall2 / 9
   На сервере curl localhost:8080 отвечает, а с соседней машины — connection refused. С чего начать?

   A)Проверить, на каком адресе слушает сокет, и правила фаервола

   B)Перезапустить сервис: сокет завис в CLOSE_WAIT

   C)Прописать A-запись — без DNS соединение не установится

   D)Поднять лимит открытых файлов у процесса

   показать ответ и разбор

   +A)Проверить, на каком адресе слушает сокет, и правила фаервола

   // разбор: Две частые причины: сервис слушает 127.0.0.1 вместо 0.0.0.0 (тогда снаружи он попросту недоступен) или пакеты режет фаервол либо группа безопасности. Смотрят ss -lptn (адрес в колонке Local Address), затем правила и путь пакета: iptables/nftables на хосте, security group у облака, маршруты между сетями.

3. #dvo_net_http_tls3 / 9
   Прокси отдаёт клиентам то 502, то 504. В чём разница для диагностики?

   A)502 — ошибка клиента, 504 — ошибка сервера приложения

   B)502 отдаёт сам сервис, 504 добавляет балансировщик

   C)502 — обрыв или мусор от апстрима, 504 — молчание

   D)502 про TLS, 504 про исчерпание пула соединений

   показать ответ и разбор

   +C)502 — обрыв или мусор от апстрима, 504 — молчание

   // разбор: 502 Bad Gateway — прокси до апстрима достучался, но получил обрыв или невалидный ответ: приложение упало, воркер умер, апстрим закрыл соединение. 504 Gateway Timeout — апстрим не ответил за отведённое время: висит на запросе к БД, перегружен, залип. Первое ведёт к логам и падениям приложения, второе — к таймаутам, длинным запросам и очередям.

4. #dvo_net_lb4 / 9
   Балансировщик L4 или L7: в чём практическая разница?

   A)L4 разводит соединения, L7 разбирает HTTP

   B)L4 работает внутри сети, L7 — только на границе с интернетом

   C)L4 нужен для TCP, L7 — исключительно для UDP-трафика

   D)L4 умеет ретраи запросов, L7 просто пересылает пакеты

   показать ответ и разбор

   +A)L4 разводит соединения, L7 разбирает HTTP

   // разбор: L4 видит только транспорт: адрес, порт, соединение — он быстрый, дешёвый и умеет балансировать что угодно, включая не-HTTP. L7 терминирует HTTP: маршрутизация по пути и заголовкам, ретраи идемпотентных запросов, канареечные веса, сбор кодов ответа. Плата — процессор на разбор и терминацию TLS, плюс лишний хоп в трассировке.

5. #dvo_net_tcpip5 / 9
   Метрики шлём по UDP, платежи — по TCP. Что даёт TCP, чего нет у UDP?

   A)Шифрование канала и проверку целостности данных

   B)Подтверждения, повторы и порядок доставки

   C)Меньшую задержку за счёт отсутствия рукопожатия

   D)Гарантию, что сервер обработал сообщение

   показать ответ и разбор

   +B)Подтверждения, повторы и порядок доставки

   // разбор: TCP — соединение с подтверждениями: потерянный сегмент переотправят, порядок восстановят, скорость подстроят под сеть. Платой идут рукопожатие, состояние на обеих сторонах и задержки на восстановление после потерь. UDP просто шлёт датаграммы: годится для метрик и телеметрии, где свежесть важнее полноты. Ни тот ни другой сами по себе не шифруют и не отвечают за обработку на прикладном уровне.

6. #dvo_net_dns6 / 9
   Из пода запрос к api.partner.com резолвится с задержкой, в tcpdump видно пять неудачных запросов подряд. Причина?

   A)kube-dns отвечает только на внутренние имена, внешние идут по таймауту

   B)ndots:5 в resolv.conf: имя сначала перебирается по search-доменам

   C)IPv6 отключён, и резолвер ждёт таймаут на AAAA

   D)У пода нет своего резолвера, запросы идут через API-сервер

   показать ответ и разбор

   +B)ndots:5 в resolv.conf: имя сначала перебирается по search-доменам

   // разбор: В кластере resolv.conf пода содержит options ndots:5: имя, где меньше пяти точек, считается неполным, и резолвер сначала перебирает search-домены — namespace.svc.cluster.local, svc.cluster.local, cluster.local. Для внешних имён это лишние отказы перед правильным ответом. Лечится точкой в конце имени (api.partner.com.) или своим dnsConfig с меньшим ndots.

7. #dvo_net_firewall7 / 9
   На хосте включён ufw и порт 5432 закрыт, но контейнер с публикацией -p 5432:5432 доступен из интернета. Почему?

   A)ufw применяет правила лишь после перезагрузки хоста

   B)Порт публикуется на localhost, а видимость даёт NAT провайдера

   C)Контейнер работает в своём сетевом namespace, где правил хоста нет

   D)Docker пишет свои правила DNAT, и трафик минует цепочку INPUT

   показать ответ и разбор

   +D)Docker пишет свои правила DNAT, и трафик минует цепочку INPUT

   // разбор: Публикация порта — это правило DNAT в таблице nat, добавленное демоном Docker. Пакет проходит PREROUTING, попадает в FORWARD (цепочку DOCKER), а до INPUT, где живут правила ufw, дело не доходит. Потому «закрытый» фаерволом порт снаружи открыт. Лечится публикацией на конкретный адрес (-p 127.0.0.1:5432:5432), правилами в DOCKER-USER или отключением iptables у демона.

8. #dvo_net_http_tls8 / 9
   На одном IP живут десятки HTTPS-сайтов с разными сертификатами. Как сервер понимает, какой сертификат отдать?

   A)По заголовку Host из первого HTTP-запроса

   B)По записи PTR обратной зоны для адреса клиента

   C)По отдельному порту, выделенному каждому домену

   D)По расширению SNI в ClientHello, до шифрования

   показать ответ и разбор

   +D)По расширению SNI в ClientHello, до шифрования

   // разбор: Заголовок Host едет уже внутри зашифрованного соединения, а сертификат нужен раньше — потому имя хоста клиент кладёт в SNI открытым текстом в ClientHello. Сервер выбирает по нему сертификат и виртуальный хост. Отсюда два следствия: имя сайта видно наблюдателю в сети, а клиент без поддержки SNI получит сертификат по умолчанию и ошибку имени.

9. #dvo_net_lb9 / 9
   Запрос на /api/users/42 доходит до бэкенда как /api/users/42, хотя ждали /users/42. Что в конфиге?

   location /api/ {
     proxy_pass http://backend;
   }

   A)Нужен rewrite: proxy_pass префикс не трогает

   B)Имя backend резолвится в апстрим-блок, который сохраняет путь

   C)В proxy_pass нет завершающего слэша — URI уходит целиком

   D)location задан без знака ^~, потому префикс не отсекается

   показать ответ и разбор

   +C)В proxy_pass нет завершающего слэша — URI уходит целиком

   // разбор: Если в proxy_pass указан путь (хотя бы одиночный слэш), nginx заменяет им совпавшую часть location: с http://backend/ на бэкенд уйдёт /users/42. Без пути адрес считается «как есть», и запрос уходит с исходным URI. Отсюда классика: добавили слэш — сломали маршруты, убрали — получили дублирующийся префикс.

Частые вопросы

• Чем 502 отличается от 504?

  502 означает, что прокси достучался до апстрима, но получил обрыв или невалидный ответ. 504 означает, что апстрим не ответил за отведённое время. Первое ведёт в логи упавшего приложения, второе в разбор долгих запросов и очередей.

• Что спрашивают про TLS?

  Как сервер выбирает сертификат при десятке сайтов на одном адресе (расширение SNI), почему сайт открывается в браузере, но падает в curl (неполная цепочка), и как устроено автопродление и мониторинг срока действия.