Linux EHOSTUNREACH met OpenVPN: welke volgende hop is mislukt?

EHOSTUNREACH is even vaak een lokale beslissing als een externe storing. De kernel kan een pakket weigeren omdat een route zegt dat de bestemming onbereikbaar is, omdat de Ethernet-volgende hop nooit antwoordde, of omdat een ICMP host-unreachable-rapport van verderop in het pad aankwam. Elke bron leeft in een andere tabel of cache, en elke bron wordt op een andere plek opgelost. Lees de geselecteerde route en de toestand van de volgende hop voordat u cijfers aanraakt of de tunnel opnieuw installeert.

Kies het adres en de namespace die de client daadwerkelijk gebruikt

Begin met het vastzetten van de bestemming en de netwerk-namespace die de fout veroorzaakte. Een VPN-client kan in zijn eigen namespace draaien, en een opzoeking vanuit de standaard-namespace raadpleegt een andere routingtabel met andere beleidsregels.

De opzoeking moet dezelfde bron-, mark- en tabelcontext gebruiken als de toepassing die faalt, anders beantwoordt zij misschien een vraag die niemand stelde. Voor een illustratieve IPv4-peer zijn de alleen-lezen-controles:

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

Een resultaat uit een administratieve shell bewijst alleen wat die shell zou doen. Als de client een firewallmark instelt of aan een VRF bindt, herhaal de opzoeking met de overeenkomende mark of binnen de VRF, en vergelijk de geselecteerde route en de volgende hop. Het eerste adres dat bevestigd moet worden is het peeradres in het profiel, niet het cluster of de dienst die de gebruiker noemt.

Een expliciete onbereikbare route weigert het pakket lokaal

Een route van het type unreachable is een bewust lokaal antwoord. Zij vertelt de kernel het pakket weg te gooien en EHOSTUNREACH aan de afzender terug te geven, daarom verschijnt de fout onmiddellijk en zonder verkeer dat de machine verlaat. Iemand, of een of andere automatisering, heeft die route daar met opzet neergezet.

De routetypen zijn niet uitwisselbaar. Blackhole gooit het pakket weg zonder fout aan de afzender, prohibit geeft EACCES terug, en unreachable geeft EHOSTUNREACH terug. Een VPN-hulp die tijdens het opnieuw verbinden een sink-route installeert, kan daarom een uitbarsting host-unreachable-fouten veroorzaken die verdwijnen zodra de tunnel staat, terwijl een blackhole-route juist stille time-outs zou geven.

Doorzoek alle tabellen op het type voordat u het verre uiteinde de schuld geeft. De regel die de tabel kiest, is net zo belangrijk als de route erin, en een route die aan de hoofdtabel is toegevoegd, helpt een client niet wiens beleidsregel zijn verkeer elders heen stuurt.

Een dode buur geeft dezelfde fout op Ethernet

Wanneer de geselecteerde route een on-link gateway gebruikt, heeft de aflevering een opgelost linklaagadres nodig. De kernel stuurt een ARP- of IPv6-buuropzoeking, en als er geen antwoord komt kan het pakket niet worden ingekaderd. Het verzenden mislukt dan met EHOSTUNREACH, ook al is de route zelf geldig.

De buurtabel noemt de fase. INCOMPLETE betekent dat een resolutie nog loopt, FAILED betekent dat de laatste poging geen antwoord kreeg, en REACHABLE of STALE betekent dat de kernel een bruikbaar adres heeft. Een FAILED-vermelding voor de VPN-gateway is een lokaal afleveringsprobleem, geen bewijs over de verre kant van de tunnel.

Lees de vermelding voor de werkelijke volgende hop, niet voor het verre internetadres. Een ver adres wordt meestal via een router bereikt, dus het heeft geen eigen ARP-record; erom vragen is een categoriefout die mensen laat zoeken naar een ontbrekende vermelding die er nooit had moeten zijn.

Externe rapporten en asynchrone UDP-fouten

EHOSTUNREACH kan ook van buiten komen. Een router die het pakket niet kan doorsturen, kan ICMP host unreachable sturen, en de kernel geeft dat rapport door aan de socket die de stroom bezit. In dat geval zijn de route en de buur in orde, en hoort de fout bij een hop voorbij het lokale netwerk.

UDP maakt toeschrijving lastiger. Een fout die door een latere verzend- of ontvangstaanroep wordt teruggegeven, kan betrekking hebben op een eerder datagram, dus het adres en de tijd van de falende aanroep passen misschien niet bij het pakket dat het rapport veroorzaakte. Een verbonden UDP-socket ontvangt de fout één keer, en een niet-verbonden socket ziet hem misschien nooit.

Daarom hoort timing bij het bewijs. Noteer wanneer de fout verscheen, welk peeradres de socket gebruikte, en of de tunnel net opnieuw verbonden was. Een uitbarsting direct na een routewijziging wijst op de lokale tabel; een enkele fout minuten in een stabiele stroom wijst op een padrapport.

Scheid de lagen voordat u de crypto wijzigt

Drie vragen classificeren de fout. Koos de kernel een route die de bestemming weigert? Koos hij een geldige route maar slaagde hij er niet in de volgende hop op te lossen? Of kwam er een rapport van voorbij het lokale netwerk? Alleen het derde geval kan het verre uiteinde van de tunnel betreffen, en zelfs dan niet de versleuteling.

Problemen met authenticatie en onderhandeling komen als hun eigen fouten naar voren nadat het transport de peer bereikt. Een cijfer wijzigen of de client opnieuw installeren kan een lokale unreachable-route niet repareren, en het vernietigt het route- en buurbewijs dat u voor de werkelijke oorzaak nodig zou hebben.

Registreer bestemming, namespace, geselecteerde tabel, volgende hop, buurstatus en fouttijd vóór de eerste wijziging. Voer dezelfde opzoeking opnieuw uit na de correctie; een route die nu naar de tunnel wijst en een buurvermelding die nu wordt opgelost, zijn sterker bewijs dan een geslaagde ping naar een ongerelateerd adres.