Linux a EHOSTUNREACH s OpenVPN: ktorý ďalší skok zlyhal?

EHOSTUNREACH je rovnako často lokálne rozhodnutie ako vzdialené zlyhanie. Kernel môže paket odmietnuť preto, že trasa označuje cieľ ako nedostupný, pretože ethernetový ďalší skok nikdy neodpovedal, alebo preto, že z ďalej po ceste dorazilo hlásenie ICMP host-unreachable. Každý zdroj žije v inej tabuľke alebo cache a každý sa opravuje na inom mieste. Prečítajte si zvolenú trasu a stav ďalšieho skoku, skôr než sa dotknete šifier alebo preinštalujete tunel.

Určite adresu a namespace, ktoré klient skutočne používa

Začnite tým, že zafixujete cieľ a sieťový namespace, ktorý chybu vyvolal. VPN klient môže bežať vo vlastnom namespace a vyhľadanie z predvoleného namespace použije inú smerovaciu tabuľku s inými pravidlami politiky.

Vyhľadanie musí použiť rovnaký zdroj, mark a kontext tabuľky ako zlyhávajúca aplikácia, inak môže odpovedať na otázku, ktorú nikto nepoložil. Pre ilustračný peer IPv4 sú tieto kontroly len na čítanie:

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ýsledok z administrátorského shellu dokazuje len to, čo by urobil tento shell. Ak klient nastavuje firewall mark alebo sa viaže na VRF, zopakujte vyhľadanie so zodpovedajúcim mark alebo vo vnútri VRF a porovnajte zvolenú trasu a ďalší skok. Prvá adresa, ktorú treba potvrdiť, je adresa peer v profile, nie klaster či služba, ktorú používateľ menovite uvádza.

Výslovná nedostupná trasa odmietne paket lokálne

Trasa typu unreachable je zámerná lokálna odpoveď. Hovorí kernelu, aby paket zahodil a vrátil odosielateľovi EHOSTUNREACH, a preto sa chyba objaví okamžite a bez toho, aby stroj opustil akýkoľvek prenos. Niekto alebo nejaká automatizácia tam tú trasu umiestnili zámerne.

Typy trás nie sú zameniteľné. blackhole paket zahodí bez chyby pre odosielateľa, prohibit vráti EACCES a unreachable vráti EHOSTUNREACH. VPN pomocník, ktorý pri opätovnom pripájaní inštaluje sink trasu, preto môže vyprodukovať nával chýb host-unreachable, ktoré po nadviazaní tunela zmiznú, zatiaľ čo blackhole trasa by namiesto toho spôsobila tiché časové limity.

Pred obviňovaním vzdialeného konca prehľadajte všetky tabuľky podľa typu. Pravidlo, ktoré vyberá tabuľku, je rovnako dôležité ako trasa v nej, a trasa pridaná do hlavnej tabuľky nepomôže klientovi, ktorého pravidlo politiky posiela prevádzku inam.

Mŕtvy sused vytvára na Ethernete rovnakú chybu

Keď zvolená trasa používa on-link bránu, doručenie potrebuje rozlíšenú adresu linkovej vrstvy. Kernel odošle ARP alebo susedskú výzvu IPv6, a ak nepríde odpoveď, paket sa nedá zarámovať. Odoslanie potom zlyhá s EHOSTUNREACH, hoci samotná trasa je platná.

Susedská tabuľka pomenúva fázu. INCOMPLETE znamená, že rozlíšenie stále prebieha, FAILED znamená, že posledný pokus nedostal odpoveď, a REACHABLE alebo STALE znamená, že kernel má použiteľnú adresu. Záznam FAILED pre VPN bránu je lokálny problém doručenia, nie dôkaz o vzdialenej strane tunela.

Čítajte záznam pre skutočný ďalší skok, nie pre vzdialenú internetovú adresu. Vzdialená adresa sa zvyčajne dosahuje cez router, takže nebude mať vlastný ARP záznam; žiadať oň je kategorická chyba, ktorá posiela ľudí hľadať chýbajúci záznam, ktorý nikdy nemal existovať.

Vzdialené hlásenia a asynchrónne chyby UDP

EHOSTUNREACH môže prísť aj zvonku. Router, ktorý paket nevie preposlať, môže poslať ICMP host unreachable a kernel odovzdá toto hlásenie socketu, ktorý vlastní tok. V takom prípade sú trasa a sused v poriadku a zlyhanie patrí skoku za lokálnou sieťou.

UDP sťažuje určenie príčiny. Chyba vrátená neskorším volaním send alebo receive sa môže týkať skoršieho datagramu, takže adresa a čas zlyhávajúceho volania nemusia zodpovedať paketu, ktorý hlásenie vyvolal. Pripojený UDP socket dostane chybu raz a nepripojený socket ju nemusí vidieť vôbec.

Preto čas patrí do dôkazov. Poznamenajte, kedy sa chyba objavila, ktorú adresu peer socket použil a či sa tunel práve znova pripojil. Nával hneď po zmene trasy ukazuje na lokálnu tabuľku; jediná chyba po niekoľkých minútach stabilného toku ukazuje na hlásenie z cesty.

Pred zmenou kryptografie oddeľte vrstvy

Chybu klasifikujú tri otázky. Zvolil kernel trasu, ktorá cieľ odmieta? Zvolil platnú trasu, ale nedokázal rozlíšiť ďalší skok? Alebo dorazilo hlásenie spoza lokálnej siete? Vzdialený koniec tunela môže naznačiť iba tretí prípad, a ani vtedy neukazuje na šifrovanie.

Problémy s autentifikáciou a vyjednávaním sa prejavia vlastnými chybami až po tom, čo transport dosiahne peer. Zmena šifry alebo preinštalovanie klienta neopraví lokálnu nedostupnú trasu a zničí dôkazy o trase a susedovi, ktoré by ste potrebovali na skutočnú príčinu.

Pred prvou zmenou zaznamenajte cieľ, namespace, zvolenú tabuľku, ďalší skok, stav suseda a čas chyby. Po oprave zopakujte rovnaké vyhľadanie; trasa, ktorá teraz ukazuje na tunel, a susedský záznam, ktorý sa teraz rozlíši, sú silnejším dôkazom než úspešný ping na nesúvisiacu adresu.