Диагностика сети
Послойная методика «сайт тормозит», проверка портов и связности, захват tcpdump, а также основы DHCP, VLAN, ICMP и прокси для диагностики.
8 вопросов
JuniorТеорияОчень частоЧто проверяет ping и почему неудачный ping не доказывает, что хост лежит?
Что проверяет ping и почему неудачный ping не доказывает, что хост лежит?
ping шлёт ICMP echo-request и ждёт ответы, поэтому проверяет достижимость на уровне IP и RTT, а не то, поднят ли TCP-сервис. Неудачный ping не доказывает, что хост лежит: файрволы и security groups часто отбрасывают или ограничивают ICMP, тогда как TCP-порты открыты, так что хост может отвечать на curl, но не на ping.
Типичные ошибки
- ✗Читать неудачный
pingкак доказательство, что хост лежит, когда ICMP просто фильтруется - ✗Думать, что успешный
pingдоказывает, что TCP-сервис слушает - ✗Считать, что ICMP и TCP всегда разрешены или заблокированы вместе
Уточняющие вопросы
- →Как подтвердить, что хост жив, когда ICMP фильтруется на всём пути?
- →Почему многие security groups ограничивают ICMP, а не блокируют его полностью?
MiddleДебаггингОчень частоПосле миграции запросы идут на старый хост. Поставьте диагноз по выводу DNS.
После миграции запросы идут на старый хост. Поставьте диагноз по выводу DNS.
Рекурсивный resolver возвращает старую запись 10.20.4.9 с большим остатком TTL, тогда как авторитетный сервер уже отвечает 10.20.4.11 — значит это устаревший кэш, а не маршрутизация или приложение. Чиним сейчас: сбросить кэш resolver или переждать TTL; на будущее — снижать TTL записи перед миграцией.
Типичные ошибки
- ✗Винить авторитетный сервер, когда он уже возвращает верную запись
- ✗Игнорировать большой TTL, из-за которого устаревший ответ живёт в resolver
- ✗Хвататься за маршрутизацию или конфиг приложения раньше сравнения resolver и авторитетного
Уточняющие вопросы
- →Почему прямой запрос к авторитетному серверу обходит устаревший ответ?
- →Как снижение TTL перед изменением сокращает окно распространения?
JuniorТеорияЧастоКак диагностировать недоступный сервис, проходя по сетевым уровням?
Как диагностировать недоступный сервис, проходя по сетевым уровням?
Идём по стеку снизу вверх, по одному уровню: link (интерфейс поднят?), IP (адрес и подсеть), маршрутизация (шлюз, ip route), DNS (имя разрешается?), транспорт (порт открыт?), затем приложение (отвечает, смотрим логи). Изоляция каждого уровня показывает, где обрыв, вместо гадания.
Типичные ошибки
- ✗Сразу лезть в приложение, не исключив DNS, маршрутизацию или порт
- ✗Считать, что успешный
pingдоказывает исправность всех нижних уровней и порта - ✗Менять несколько вещей разом, так и не узнав, какой уровень был сломан
Уточняющие вопросы
- →Почему при неудачном соединении по имени сначала проверяют DNS, а потом TCP-порт?
- →Как изоляция по одному уровню ускоряет поиск корневой причины?
MiddleДебаггингЧастоПриложение постепенно перестаёт принимать соединения. ss показывает это — в чём дело?
Приложение постепенно перестаёт принимать соединения. ss показывает это — в чём дело?
Сокеты копятся в CLOSE_WAIT на собственном :8080 приложения: пир прислал FIN, а приложение так и не вызвало close(), чтобы отправить свой FIN. Это баг приложения — оно течёт сокетами и дескрипторами, пока не упрётся в лимит fd и не перестанет принимать. Много TIME_WAIT, наоборот, нормально на закрывшем первым.
Типичные ошибки
- ✗Путать
CLOSE_WAIT(локальное приложение не закрыло) сTIME_WAIT(нормально) - ✗Считать это тюнингом ядра, а не отсутствующим
close()в приложении - ✗Поднимать
ulimitна fd, маскируя утечку, которая всё равно растёт
Уточняющие вопросы
- →Почему большое число
TIME_WAITобычно нормально на стороне, закрывшей первой? - →Как найти путь кода, текущий сокетами, по списку fd?
MiddleДебаггингЧастоКлиенты не могут достучаться до сервиса. По захвату назовите причину и следующий шаг.
Клиенты не могут достучаться до сервиса. По захвату назовите причину и следующий шаг.
SYN переотправляется, а SYN-ACK и RST не приходят — значит пакет молча отбрасывается: firewall или security group блокирует 8443, либо ничего не слушает и пакет теряется. Пришедший RST означал бы слушателя, который отказывает. Дальше: проверить правила firewall/security-group и ss -ltn на сервере.
Типичные ошибки
- ✗Читать переотправленные SYN как RST (отказ), а не как молчаливый drop
- ✗Винить DNS, когда имя уже разрешилось в адрес
- ✗Не различать отсутствие ответа (drop) и RST (слушает, но отказывает)
Уточняющие вопросы
- →Как выглядел бы захват, если бы сервер отправил RST вместо этого?
- →Почему отброшенный SYN даёт зависание, а RST — мгновенный отказ?
JuniorТеорияИногдаХост загрузился без IP (или с адресом 169.254.x.x) — что такое DHCP и обмен DORA?
Хост загрузился без IP (или с адресом 169.254.x.x) — что такое DHCP и обмен DORA?
DHCP выдаёт IP-конфигурацию. Клиент без аренды выполняет обмен DORA — broadcast DISCOVER, сервер OFFER, клиент REQUEST, сервер ACK — арендуя адрес плюс шлюз, DNS и маску подсети. Самоназначенный адрес 169.254.x.x значит, что DORA не получил ответа: нет доступного сервера или сломан DHCP relay.
Типичные ошибки
- ✗Путать порядок или направление DORA — инициирует клиент через DISCOVER
- ✗Читать самоназначенный адрес
169.254.x.xкак валидную рабочую аренду - ✗Забывать, что для DHCP через границу подсети нужен relay (ip-helper)
Уточняющие вопросы
- →Почему DHCP между подсетями требует relay-агента или
ip helper-address? - →О чём говорит адрес
169.254.x.xв сравнении с полным отсутствием адреса?
MiddleТеорияИногдаПочему round-robin DNS не является настоящим балансировщиком нагрузки?
Почему round-robin DNS не является настоящим балансировщиком нагрузки?
Round-robin DNS возвращает прокрученный список A-записей, раскидывая запросы поровну — но это не настоящий балансировщик. У него нет health-check: мёртвый IP в ротации, пока запись не удалят и не истечёт TTL. Он не знает нагрузку, а кэш клиентов и resolver делает раздачу неровной. Настоящей балансировке нужен L4/L7-балансировщик с health-check.
Типичные ошибки
- ✗Считать, что round-robin DNS делает health-check и убирает мёртвые бэкенды
- ✗Думать, что DNS возвращает лишь один адрес и не может прокручивать набор записей
- ✗Игнорировать кэш клиентов и resolver, из-за которого раздел неровный
Уточняющие вопросы
- →Как долго мёртвый IP может получать трафик после удаления из записи?
- →Как health-check L4- или L7-балансировщика улучшает round-robin DNS?
MiddleДебаггингРедкоSSH работает, но большие передачи временами зависают. Поставьте диагноз по пробам ниже.
SSH работает, но большие передачи временами зависают. Поставьте диагноз по пробам ниже.
Мелкие запросы проходят, а большие передачи зависают, и ping -M do -s 1472 падает с mtu=1400 — это чёрная дыра PMTU. VPN снизил path MTU до 1400; пакеты с DF отбрасываются, но ICMP fragmentation needed отфильтрован, так что отправитель не узнаёт и застревает. Чиним: разрешить этот ICMP или зажать TCP MSS под PMTU.
Типичные ошибки
- ✗Читать чистый мелкий
pingкак доказательство исправности всего пути - ✗Винить случайную потерю, когда роняются лишь большие пакеты с флагом DF
- ✗Упускать, что отфильтрованный ICMP
fragmentation neededи создаёт чёрную дыру
Уточняющие вопросы
- →Почему мелкие запросы проходят, а зависают только большие передачи?
- →Как зажатие TCP MSS избавляет от зависимости от прохождения ICMP?
