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 прави приписването по-трудно. Грешка, върната от по-късно извикване за изпращане или получаване, може да се отнася до по-ранна датаграма, така че адресът и времето на неуспешното извикване може да не съвпадат с пакета, който е задействал доклада. Свързан UDP сокет получава грешката веднъж, а несвързан сокет може изобщо да не я види.

Затова времето принадлежи към доказателствата. Отбележете кога се появи грешката, кой адрес на партньора е използвал сокетът и дали тунелът току-що се е свързал отново. Вълна веднага след промяна на маршрута сочи към локалната таблица; единична грешка минути след стабилен поток сочи към доклад за пътя.

Разделете слоевете, преди да променяте крипто

Три въпроса класифицират грешката. Ядрото избра ли маршрут, който отхвърля дестинацията? Избра ли валиден маршрут, но не успя да разреши следващия хоп? Или доклад пристигна отвъд локалната мрежа? Само третият случай може да замеси далечния край на тунела и дори тогава не замесва криптирането.

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

Запишете дестинацията, пространството от имена, избраната таблица, следващия хоп, състоянието на съседа и времето на грешката преди първата промяна. Изпълнете същото търсене отново след поправката; маршрут, който сега сочи към тунела, и запис за съсед, който сега се разрешава, са по-силно доказателство от успешен ping към несвързан адрес.