Linux EHOSTUNREACH с OpenVPN: какой следующий хоп не сработал?

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

Выберите адрес и пространство имён, которые клиент действительно использует

Начните с фиксации пункта назначения и сетевого пространства имён, которые породили ошибку. VPN-клиент может работать в собственном пространстве имён, а поиск из пространства по умолчанию обращается к другой таблице маршрутизации с другими правилами политики.

Поиск должен использовать тот же контекст источника, метки и таблицы, что и сбойное приложение, иначе он может ответить на вопрос, которого никто не задавал. Для иллюстративного 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

Результат из административной оболочки доказывает лишь то, что сделала бы эта оболочка. Если клиент ставит метку брандмауэра или привязывается к VRF, повторите поиск с соответствующей меткой или внутри VRF и сравните выбранный маршрут и следующий хоп. Первый адрес, который нужно подтвердить, — это адрес пира в профиле, а не кластер или сервис, который называет пользователь.

Явный недоступный маршрут отклоняет пакет локально

Маршрут типа unreachable — это намеренный локальный ответ. Он велит ядру отбросить пакет и вернуть EHOSTUNREACH отправителю, поэтому ошибка появляется мгновенно и без какого-либо трафика, покидающего машину. Кто-то или какая-то автоматизация намеренно поместил этот маршрут туда.

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

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

Мёртвый сосед даёт ту же ошибку в Ethernet

Когда выбранный маршрут использует шлюз на канале, для доставки нужен разрешённый адрес канального уровня. Ядро отправляет ARP- или IPv6-запрос соседа, и если ответ не приходит, пакет нельзя кадрировать. Тогда отправка завершается с EHOSTUNREACH, хотя сам маршрут действителен.

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

Читайте запись для фактического следующего хопа, а не для удалённого интернет-адреса. До удалённого адреса обычно добираются через маршрутизатор, поэтому у него не будет собственной ARP-записи; просить её — категориальная ошибка, которая отправляет людей искать отсутствующую запись, которой никогда не должно было быть.

Удалённые отчёты и асинхронные ошибки UDP

EHOSTUNREACH может прийти и снаружи. Маршрутизатор, который не может переслать пакет, может отправить ICMP host unreachable, и ядро передаёт этот отчёт сокету, владеющему потоком. В этом случае маршрут и сосед в порядке, а сбой относится к хопу за пределами локальной сети.

UDP усложняет атрибуцию. Ошибка, возвращённая более поздним вызовом send или receive, может относиться к более ранней датаграмме, поэтому адрес и время сбойного вызова могут не совпадать с пакетом, вызвавшим отчёт. Соединённый UDP-сокет получает ошибку один раз, а несоединённый может никогда её не увидеть.

Поэтому время входит в доказательства. Отметьте, когда появилась ошибка, какой адрес пира использовал сокет и не переподключался ли туннель только что. Всплеск сразу после смены маршрута указывает на локальную таблицу; одиночная ошибка через несколько минут стабильного потока указывает на отчёт о пути.

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

Три вопроса классифицируют ошибку. Выбрало ли ядро маршрут, который отвергает пункт назначения? Выбрало ли оно действительный маршрут, но не смогло разрешить следующий хоп? Или пришёл отчёт из-за пределов локальной сети? Только третий случай может затрагивать дальний конец туннеля, и даже тогда он не затрагивает шифрование.

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

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