Ping — не доказательство: проверьте путь между двумя площадками

Ping со шлюза ничего не говорит о сервисе. Пройдите путь от реального клиента, используйте протокол приложения и воспроизведите размер или имя, которое даёт сбой.

Туннель поднят, шлюзы отвечают друг другу, а пользователи на одной площадке всё равно не могут открыть общую папку на другой. Кто-то пингует со шлюза, получает ответ и объявляет сеть здоровой. Этот ответ прошёл между двумя устройствами, которые никогда не были проблемой. Полезный тест начинается на хосте, которому нужен сервис, использует протокол, который использует приложение, и воспроизводит условие, в котором оно даёт сбой. Всё остальное — зелёный свет для пути, по которому никто не идёт.

Начните с клиента, которому нужен сервис

Запишите четыре вещи перед любой проверкой: адрес клиента, адрес назначения, имя хоста и порт приложения. Затем подтвердите, что сервис работает локально на своей площадке, с соседнего хоста. Без этой базовой линии вы не отличите сломанный туннель от сломанного сервиса, а половина таких заявок — второй случай.

Попробуйте задокументированное имя хоста и, где сервис это позволяет, прямую проверку адреса того же порта. Неудачный поиск имени и недостижимый разрешённый адрес ведут разными путями. Если вы заменяете имя хоста на IP, не отключайте проверку подлинности HTTPS ради работоспособности; предупреждение о сертификате — это информация, а не препятствие.

Пройдите путь на каждом крае

Прочитайте маршрут, который выбирает клиент, затем маршрут, который выбирает шлюз для этого назначения, затем счётчики или ограниченный захват на каждом крае. Вы ищете два факта: дошёл ли запрос до удалённой локальной сети и вернулся ли ответ. Счётчики интерфейсов включают все остальные потоки, поэтому сопоставляйте по точной метке времени и паре адресов, а не по форме графика. Захват на неправильном крае хуже отсутствия, потому что выглядит как доказательство.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

Используйте протокол, который использует приложение

ICMP — слабая проверка. Его можно фильтровать, ограничивать по скорости или обрабатывать другой политикой, чем сервис, из-за чего и успех, и неудача становятся двусмысленными. Проверяйте реальный порт и, где можете, реальное рукопожатие протокола.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

Завершённое рукопожатие TCP доказывает доступность и политику для этого порта. Оно не доказывает, что приложение работает: аутентификация, загрузка или конкретный вызов API всё ещё могут отказать. Проверяйте операцию, которую пользователи действительно выполняют, используя безвредный эквивалент вместо многократной отправки реальной транзакции.

Воспроизведите условие, в котором происходит сбой

Сбои, появляющиеся только при больших передачах, — это проблема размера, а не связности. Отправьте большой пакет с установленным битом don't-fragment и посмотрите, где он останавливается. Если маленький запрос проходит, а большой зависает, MTU туннеля и обработка MSS на шлюзах — следующие подозреваемые.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

Если сбой только в одной подсети, смотрите селекторы трафика, анонсы маршрутов и обратный шлюз этой подсети. Если сбой только по имени хоста, идите по DNS, включая то, какой резолвер использовал клиент и виден ли удалённый вид с этой площадки. Три разных сбоя, три разных исправления, и тест ping не различает ни одного из них.

После исправления повторите тот же тест

Запустите заново того же клиента, назначение, порт и полезную нагрузку. Затем переподключитесь или проверьте резервный путь, если он предусмотрен проектом, потому что исправление, работающее только пока жива исходная копия туннеля, не проверено. Держите тест привязанным к реальному источнику, реальному назначению и реальной операции, а не к одному зелёному индикатору на панели.

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

Похожие статьи