Linux EHOSTUNREACH з OpenVPN: який наступний хоп не вдався?

EHOSTUNREACH є локальним рішенням так само часто, як і віддаленою невдачею. Ядро може відкинути пакет через те, що маршрут каже: пункт призначення недосяжний, через те, що Ethernet-хоп ніколи не відповів, або через те, що здалеку по шляху надійшов звіт ICMP host-unreachable. Кожне джерело живе в іншій таблиці чи кеші, і кожне виправляється в іншому місці. Прочитайте вибраний маршрут і стан наступного хопу, перш ніж чіпати шифри чи перевстановлювати тунель.

Виберіть адресу та namespace, які клієнт справді використовує

Почніть із закріплення пункту призначення та мережевого namespace, який спричинив помилку. VPN-клієнт може працювати у власному namespace, а пошук із типового звертається до іншої таблиці маршрутизації з іншими правилами політики.

Пошук повинен використовувати той самий source, mark і контекст таблиці, що й застосунок, який зазнає невдачі, інакше він може відповісти на питання, якого ніхто не ставив. Для ілюстративного peer IPv4 перевірки лише для читання такі:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

Результат з адміністративної оболонки доводить лише те, що зробила б ця оболонка. Якщо клієнт встановлює firewall mark або прив'язується до VRF, повторіть пошук із відповідним mark чи всередині VRF і порівняйте вибраний маршрут і наступний хоп. Перша адреса, яку слід підтвердити, — це адреса peer у профілі, а не кластер чи сервіс, який називає користувач.

Явний недосяжний маршрут відкидає пакет локально

Маршрут типу unreachable — це навмисна локальна відповідь. Він каже ядру відкинути пакет і повернути відправникові EHOSTUNREACH, тому помилка з'являється миттєво і без жодного трафіку, що залишає машину. Хтось або якась автоматизація навмисно поставили цей маршрут туди.

Типи маршрутів не взаємозамінні. blackhole відкидає пакет без помилки для відправника, prohibit повертає EACCES, а unreachable повертає EHOSTUNREACH. VPN-помічник, який під час повторного підключення встановлює sink-маршрут, може тому створити сплеск помилок host-unreachable, що зникають після підняття тунелю, тоді як маршрут blackhole натомість дав би тихі тайм-аути.

Перш ніж звинувачувати віддалений кінець, пошукайте тип у всіх таблицях. Правило, що вибирає таблицю, так само важливе, як маршрут у ній, а маршрут, доданий до головної таблиці, не допоможе клієнтові, чиє правило політики надсилає трафік денде.

Мертвий сусід створює ту саму помилку в Ethernet

Коли вибраний маршрут використовує on-link шлюз, доставці потрібна розв'язана адреса канального рівня. Ядро надсилає ARP або сусідський запит IPv6, і якщо відповідь не надходить, пакет неможливо обрамити. Надсилання тоді не вдається з EHOSTUNREACH, хоча сам маршрут чинний.

Таблиця сусідів називає етап. INCOMPLETE означає, що розв'язання ще триває, FAILED означає, що остання спроба не отримала відповіді, а REACHABLE або STALE означає, що ядро має придатну адресу. Запис FAILED для VPN-шлюзу — це локальна проблема доставки, а не доказ про дальній бік тунелю.

Читайте запис для фактичного наступного хопу, а не для віддаленої інтернет-адреси. Віддалена адреса зазвичай досягається через маршрутизатор, тому не матиме власного ARP-запису; просити його — це категоріальна помилка, яка змушує людей шукати відсутній запис, якого ніколи не мало існувати.

Віддалені звіти й асинхронні помилки UDP

EHOSTUNREACH може надходити і ззовні. Маршрутизатор, який не може переслати пакет, може надіслати ICMP host unreachable, і ядро передає цей звіт сокету, що володіє потоком. У такому разі маршрут і сусід у порядку, а невдача належить хопу за межами локальної мережі.

UDP ускладнює визначення причини. Помилка, яку повертає пізніший виклик send або receive, може стосуватися попередньої дейтаграми, тож адреса й час виклику, що зазнав невдачі, можуть не збігатися з пакетом, який спричинив звіт. Підключений UDP-сокет отримує помилку один раз, а непідключений може ніколи її не побачити.

Тому час є частиною доказів. Занотуйте, коли з'явилася помилка, яку адресу peer використав сокет і чи тунель щойно перепідключився. Сплеск одразу після зміни маршруту вказує на локальну таблицю; поодинока помилка через кілька хвилин стабільного потоку вказує на звіт із шляху.

Розділіть рівні, перш ніж змінювати криптографію

Помилку класифікують три питання. Чи ядро вибрало маршрут, що відкидає призначення? Чи воно вибрало чинний маршрут, але не змогло розв'язати наступний хоп? Чи звіт надійшов з-за меж локальної мережі? Лише третій випадок може стосуватися дальнього кінця тунелю, і навіть тоді він не стосується шифрування.

Проблеми автентифікації та узгодження виявляються як власні помилки після того, як транспорт досягає peer. Зміна шифру або перевстановлення клієнта не виправить локальний недосяжний маршрут і знищить докази маршруту й сусіда, потрібні для справжньої причини.

Запишіть призначення, namespace, вибрану таблицю, наступний хоп, стан сусіда й час помилки перед першою зміною. Повторіть той самий пошук після виправлення; маршрут, що тепер указує на тунель, і запис сусіда, що тепер розв'язується, — сильніший доказ, ніж успішний ping до не пов'язаної адреси.