Ping не е доказателство: проверете пътя между два сайта

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.

Подобни статии