Network engineer: вопросы на собеседовании

На собеседовании network engineer редко выигрывает тот, кто первым назвал возможную причину. Сильнее выглядит кандидат, который фиксирует симптом, рисует путь пакета, выбирает точку наблюдения и последовательно исключает гипотезы. Сеть может доставить SYN, потерять ответ из-за policy routing, разрешить TCP-соединение и всё равно вернуть HTTP 500 из-за недоступной базы. Поэтому ответ должен различать слои, направления трафика и факты с каждой стороны границы. Интервьюер оценивает не число названных команд, а связь вывода команды с исходным симптомом и следующим проверяемым шагом.

Метод диагностики: путь, направление, доказательство

Начните с точного условия. Кто не может подключиться, к какому имени и адресу, с какого сегмента, когда началось и что изменилось? «Сервис недоступен» слишком широко: DNS может вернуть старый IP, SYN может не дойти до VIP, балансировщик может выбрать backend, а приложение — упасть после подключения к базе. Зафиксируйте контрольный успешный клиент: сравнение часто быстрее показывает различие маршрута, политики или резолвера.

Нарисуйте прямой и обратный путь. Для каждого перехода отметьте интерфейс, VRF, VLAN, next hop, NAT, firewall и точку терминации TCP. Stateful-устройство оценивает сессию в обоих направлениях, поэтому одного traceroute от клиента недостаточно. Если SYN-ACK возвращается через другую границу, нужно знать, поддерживают ли устройства state sync или асимметричный режим; без такой поддержки сессия может быть отброшена.

Измерение должно отличать отсутствие пакета от неправильного пакета. Снимок на входе firewall показывает, пришёл ли SYN; снимок на выходе — прошёл ли он после NAT и policy. Синхронизированное время и одинаковый фильтр позволяют сопоставить события. Счётчик правила, route lookup и ARP/ND cache дополняют pcap, но не заменяют его: увеличение общего deny не доказывает, что отброшен нужный flow.

L2: ARP, ND, VLAN и петли

Если IPv4-хост считает адрес локальным, он ищет MAC через ARP; IPv6 использует Neighbor Discovery. Отсутствие ответа требует проверить не один «канальный слой», а набор согласованных параметров: маску или prefix length, VLAN на обоих портах, access/trunk mode, allowed VLAN, native VLAN и запись ARP/ND. Неверная маска заставляет хост искать локального соседа там, где нужен gateway; фильтрация VLAN не пропустит broadcast или multicast запроса.

Два порта одного коммутатора могут не обмениваться кадрами, если назначены в разные VLAN или нужный тег не разрешён на trunk. Сверяйте конфигурацию на обеих сторонах линка: одинаковое слово trunk не гарантирует одинаковый список VLAN и native VLAN. MAC address table показывает, где коммутатор реально изучил адрес. Постоянное перемещение MAC между портами может указывать на петлю или неверную агрегацию.

Конкретный риск появляется, когда в одном broadcast domain добавляют второй L2 path между теми же коммутаторами без корректного STP или LACP. Broadcast и unknown unicast начинают циркулировать, MAC-таблица флапает, управление становится нестабильным. Резервный routed link в другой подсети не создаёт такую же L2-петлю, поэтому на интервью важно назвать топологию, а не просто сказать «резервирование опасно».

На каждом шаге произносите наблюдаемый факт: «ARP request выходит из access-порта, но не виден на trunk». Это сильнее фразы «проблема где-то в VLAN», потому что задаёт следующую точку проверки.

L3 и stateful path: BGP, ECMP, NAT

Если BGP-сосед анонсирует префикс, это ещё не означает, что маршрут выбран best path и установлен в FIB. Сравните атрибуты с конкурирующими путями, route policy, RPKI/фильтры и достижимость next hop. Затем проверьте таблицу нужного VRF. Longest prefix match действует внутри уже выбранной таблицы; policy routing может отправить пакет в другую таблицу, где более специфичного маршрута нет.

При нескольких equal-cost next hops ECMP обычно закрепляет flow по hash из адресов, портов и протокола. Если один next hop теряет пакеты, пострадает только часть соединений, а повтор с другими портами может дать иной результат. Смотрите набор установленных маршрутов, счётчики интерфейсов и конкретную привязку проблемного flow. Общий ping до адреса не гарантирует проверку того же next hop, который выбрало приложение.

NAT проверяют вместе с обратным маршрутом и state. Внешний клиент может доходить до DNAT, но backend отправит ответ к default gateway, минуя firewall, если SNAT не применяется и маршрут источника неизвестен. Внутренний клиент при этом работает по другому пути. Сопоставьте исходные и трансляционные адреса, порядок правил, состояние сессии и route lookup с обеих сторон. Правило permit any any выше deny завершает обработку при первом совпадении; нижний запрет уже не сработает.

Асимметрия допустима только при явной поддержке. Если два firewall синхронизируют state или настроены stateless для конкретного пути, возврат через другой узел может работать. Без state sync и asymmetric support SYN-ACK окажется неизвестной сессией. Поэтому вопрос должен содержать это условие: сама геометрическая асимметрия не является универсальным доказательством отказа.

DNS, TCP, MTU и балансировщик

После миграции пользователь может видеть старый IP из-за разных уровней DNS-кэша. Сначала запросите authoritative server, затем корпоративный resolver и фактический ответ на клиенте. Сверьте TTL до изменения: понизить его после миграции уже поздно для записей, сохранённых со старым значением. Split-horizon DNS также может намеренно давать внутренним и внешним клиентам разные ответы, поэтому сравнивайте имя, resolver и view.

Если SSH устанавливается, а большой файл зависает, проверьте MTU/MSS и Path MTU Discovery. Малый пакет проходит, а фрагментация запрещена; ICMP Packet Too Big фильтруется, и отправитель не уменьшает размер. Packet capture покажет повторные передачи крупных сегментов. MSS clamping может быть временной защитой на туннеле, но корректнее восстановить передачу ICMP и согласовать MTU пути.

Балансировщик может считать backend здоровым, если health check проверяет только открытие TCP-порта. Приложение принимает соединение, затем обращается к недоступной базе и возвращает HTTP 500 пользователям. Исправление — HTTP-проверка готовности, которая проходит критический путь к зависимости с безопасным запросом и отличает liveness от readiness. Простое увеличение TCP timeout не обнаружит отказ базы.

Изменения route policy, ACL или NAT в production начинаются с baseline и точного rollback. Ограничьте область применения одним префиксом или canary-устройством, наблюдайте reachability в обоих направлениях и не полагайтесь только на отсутствие алерта. Сохраните вывод команд до и после, чтобы откат восстанавливал конкретное состояние, а не приблизительную память инженера.

Схема показывает путь проверки от разрешения имени и соседства до stateful-границы, backend и зависимости приложения.

Как отвечать на сетевой кейс на интервью

Сначала повторите условие своими словами и уточните границы: один клиент или сегмент, IPv4 или IPv6, один flow или доля соединений, новое изменение или давняя деградация. Затем нарисуйте путь и выберите безопасный тест, который разделяет две гипотезы. Например, capture до и после firewall полезнее случайного перезапуска BGP-соседства, который уничтожит часть доказательств и расширит влияние.

Хороший ответ включает ожидаемый результат. «Проверю DNS» недостаточно; скажите: «сравню authoritative ответ, корпоративный cache и ответ клиента; если authoritative уже новый, а resolver возвращает старый IP в пределах TTL, причина в кэше». Такая формулировка показывает, что команда знает, как интерпретировать команду, а не просто перечисляет инструменты.

Подготовьте три истории: частичная потеря ECMP, L2-петля после второго пути и зелёный TCP health check при HTTP 500 из-за базы. Сравните требования в вакансиях network engineer и зарплатные ориентиры специализации. В материалах блога HireSeeker можно найти смежные инженерные кейсы. Для каждого примера назовите факт, гипотезу, точку захвата, безопасное изменение и метрику после исправления.