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.

Схожі статті