Linux EHOSTUNREACH s OpenVPN: který další hop selhal?

EHOSTUNREACH je místní rozhodnutí stejně často jako vzdálená porucha. Jádro může paket odmítnout, protože trasa říká, že cíl je nedostupný, protože další ethernetový hop nikdy neodpověděl, nebo protože dorazila zpráva ICMP host-unreachable z dálky po cestě. Každý zdroj žije v jiné tabulce nebo mezipaměti a každý se opravuje na jiném místě. Přečtěte si vybranou trasu a stav dalšího hopu, než se dotknete šifer nebo přeinstalujete tunel.

Zvolte adresu a namespace, které klient skutečně používá

Začněte tím, že zafixujete cíl a síťový namespace, který chybu vyvolal. VPN klient může běžet ve vlastním namespace a dotaz z výchozího namespace konzultuje jinou směrovací tabulku s jinými pravidly zásad.

Dotaz musí použít stejný kontext zdroje, značky a tabulky jako selhávající aplikace, jinak může odpovědět na otázku, kterou nikdo nepoložil. Pro ilustrativní IPv4 peer jsou kontroly pouze pro čtení tyto:

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

Výsledek z administrativní shellu dokazuje jen to, co by udělal tento shell. Pokud klient nastavuje značku firewallu nebo se váže na VRF, zopakujte dotaz s odpovídající značkou nebo uvnitř VRF a porovnejte vybranou trasu a další hop. První adresa k potvrzení je adresa peeru v profilu, ne cluster nebo služba, kterou uživatel uvádí.

Explicitní nedostupná trasa odmítá paket lokálně

Trasa typu unreachable je záměrná místní odpověď. Říká jádru, aby paket zahodilo a vrátilo EHOSTUNREACH odesílateli, a proto se chyba objeví okamžitě a bez jakéhokoli provozu, který by opustil stroj. Někdo nebo nějaká automatizace tu trasu umístil záměrně.

Typy tras nejsou zaměnitelné. Blackhole zahodí paket bez chyby odesílateli, prohibit vrací EACCES a unreachable vrací EHOSTUNREACH. VPN pomocník, který během opětovného připojení instaluje sink trasu, proto může vytvořit nápor chyb host-unreachable, které zmizí, jakmile tunel naskočí, zatímco blackhole trasa by místo toho vytvořila tichá časová omezení.

Prohledejte všechny tabulky na typ, než obviníte vzdálený konec. Pravidlo, které tabulku vybírá, je stejně důležité jako trasa v ní, a trasa přidaná do hlavní tabulky nepomůže klientovi, jehož pravidlo zásad posílá jeho provoz jinam.

Mrtvý soused vytváří na Ethernetu stejnou chybu

Když vybraná trasa používá on-link bránu, doručení potřebuje přeloženou adresu linkové vrstvy. Jádro pošle ARP nebo IPv6 žádost o souseda, a pokud nedorazí odpověď, paket nelze zarámovat. Odeslání pak selže s EHOSTUNREACH, i když je trasa sama platná.

Tabulka sousedů pojmenovává fázi. INCOMPLETE znamená, že překlad stále probíhá, FAILED znamená, že poslední pokus nedostal odpověď, a REACHABLE nebo STALE znamená, že jádro má použitelnou adresu. Záznam FAILED pro VPN bránu je místní problém doručení, ne důkaz o vzdálené straně tunelu.

Čtěte záznam pro skutečný další hop, ne pro vzdálenou internetovou adresu. Vzdálená adresa se obvykle dosahuje přes router, takže nebude mít vlastní ARP záznam; ptát se na něj je kategorijní chyba, která posílá lidi hledat chybějící záznam, který nikdy neměl existovat.

Vzdálené zprávy a asynchronní chyby UDP

EHOSTUNREACH může dorazit i zvenčí. Router, který nemůže paket předat, může poslat ICMP host unreachable, a jádro tuto zprávu předá socketu, kterému patří tok. V tom případě jsou trasa i soused v pořádku a porucha patří hopu za místní sítí.

UDP činí přiřazení obtížnějším. Chyba vrácená pozdějším voláním send nebo receive se může vztahovat k dřívějšímu datagramu, takže adresa a čas selhávajícího volání nemusí odpovídat paketu, který zprávu vyvolal. Připojený UDP socket obdrží chybu jednou a nepřipojený socket ji nemusí nikdy vidět.

Proto čas patří do důkazů. Poznamenejte, kdy se chyba objevila, kterou adresu peeru socket použil a zda se tunel právě znovu připojil. Nápor hned po změně trasy ukazuje na místní tabulku; ojedinělá chyba minuty po stabilním toku ukazuje na zprávu o cestě.

Oddělte vrstvy, než změníte kryptografii

Tři otázky klasifikují chybu. Zvolilo jádro trasu, která odmítá cíl? Zvolilo platnou trasu, ale nepodařilo se mu přeložit další hop? Nebo dorazila zpráva zpoza místní sítě? Pouze třetí případ může zahrnout vzdálený konec tunelu, a ani tehdy nezahrnuje šifrování.

Problémy s autentizací a vyjednáváním se projeví jako vlastní chyby poté, co transport dosáhne peeru. Změna šifry nebo přeinstalace klienta nemůže opravit místní trasu unreachable a zničí důkazy o trase a sousedovi, které byste potřebovali pro skutečnou příčinu.

Před první změnou zaznamenejte cíl, namespace, vybranou tabulku, další hop, stav souseda a čas chyby. Po opravě spusťte stejný dotaz znovu; trasa, která nyní ukazuje na tunel, a záznam souseda, který se nyní překládá, jsou silnějším důkazem než úspěšný ping na nesouvisející adresu.