Диагностика сети: найти первую сломанную границу

Что показывает схема

Диагностика — не набор команд, а последовательное сужение пространства причин. Сначала фиксируется неизменяемый baseline: где, когда, какой командой и с каким точным результатом воспроизведён symptom. Затем каждая граница проверяется собственным evidence. Вывод формулируется как первая подтверждённо failing boundary, а не как догадка «наверное, сеть».

Healthy path показан первым не ради оптимизма. Он задаёт контроль: те же source host, destination и protocol должны выдавать понятную последовательность evidence. Сравнение incident с контрольным прогоном сильнее, чем десять несвязанных screenshots.

Как читать лестницу

• Name resolution: какие адреса и TTL видел этот host в это время.
• Route selection: какой interface/next hop выбрало kernel для конкретного destination.
• Neighbor: может ли host доставить frame следующему hop в локальной link-сети.
• Transport endpoint: что произошло с конкретным address, port и protocol — success, active refusal, timeout или reset.
• TLS identity: удалось ли подтвердить peer и построить secure channel.
• Application result: какой protocol status/content и какой server-side event соответствуют request.

Не каждый инцидент требует всех команд. После доказанной ранней failure последующие layers могут быть недостижимы. Но перескакивать ранние boundaries и затем объявлять root cause по позднему symptom нельзя.

Четыре сценария

1. Healthy baseline создаёт сопоставимый контроль.
2. Name failure останавливает анализ до socket connect и требует exact DNS classification.
3. Transport timeout рассматривается только после проверки address, route и next hop; затем сравниваются captures и firewall/LB evidence.
4. HTTP 503 доказывает, что цепочка дошла до HTTP-speaking component, но owner уточняется по request id и logs.

Предсказание до запуска

Перед каждой командой запишите ожидаемый observable result. Если route отсутствует локально, packet capture на wire должен быть пуст для data packet. Если port actively refuses connection, ожидается быстрый RST, а не долгий silence. Если приходит TLS alert, transport уже прошёл дальше, чем гипотеза «порт закрыт».

Практика на C и Winsock

Диагностический client должен сохранять WSAGetLastError() сразу после failed call и печатать stage, address family, destination tuple и elapsed time. Различайте getaddrinfo result, socket creation failure, connect refusal/timeout, recv()==0 и SOCKET_ERROR. Один текст «server unavailable» уничтожает учебную ценность эксперимента.

На multi-address host логируйте каждую candidate attempt отдельно. Закрывайте failed sockets и не переносите их state на следующий address. Для timeout policy используйте nonblocking I/O и readiness API, а не бесконечный blocking connect без deadline.

Evidence bundle

• source host/interface, synchronized timestamp и exact repro command;
• resolver result и полный destination tuple;
• route/neighbor snapshot до изменения state;
• client WSA results и durations;
• packet capture с описанными filter и capture point;
• request id и совпадающие edge/origin logs для application failures.

Частые ошибки

• Перезапуск до baseline стирает caches, queues и connection state.
• Ping success не доказывает доступность TCP/UDP endpoint; ping failure не доказывает недоступность application.
• Client-side absence packet может быть filter mistake; server-side absence может быть clock/window mismatch.
• HTTP status без headers/request id редко указывает owner.
• Один успешный address candidate не делает все DNS records исправными.

Контрольные вопросы

1. Чем active refusal отличается по evidence от silent timeout?
2. Почему first failing boundary — это не обязательно root cause?
3. Какие данные нужно записать до restart, чтобы incident оставался воспроизводимым?

Источники

• Microsoft Learn — Winsock error codes
• Microsoft Learn — Packet Monitor