Linux EHOSTUNREACH mit OpenVPN: Welcher nächste Hop ist fehlgeschlagen?

EHOSTUNREACH ist ebenso oft eine lokale Entscheidung wie eine entfernte Störung. Der Kernel kann ein Paket zurückweisen, weil eine Route das Ziel als unerreichbar meldet, weil der Ethernet-Next-Hop nie geantwortet hat oder weil eine ICMP-Host-Unreachable-Meldung von weiter hinten im Pfad eingetroffen ist. Jede Ursache lebt in einer anderen Tabelle oder einem anderen Cache, und jede wird an einer anderen Stelle behoben. Lies die ausgewählte Route und den Zustand des nächsten Hops, bevor du Chiffren anfasst oder den Tunnel neu installierst.

Adresse und Namespace bestimmen, die der Client tatsächlich nutzt

Beginne damit, das Ziel und den Netzwerk-Namespace festzunageln, in dem der Fehler entstanden ist. Ein VPN-Client kann in einem eigenen Namespace laufen, und eine Abfrage aus dem Standard-Namespace zieht eine andere Routing-Tabelle mit anderen Policy-Regeln heran.

Die Abfrage muss denselben Quell-, Mark- und Tabellenkontext wie die fehlschlagende Anwendung verwenden, sonst beantwortet sie vielleicht eine Frage, die niemand gestellt hat. Für einen illustrativen IPv4-Peer sind die schreibgeschützten Prüfungen:

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

Ein Ergebnis aus einer administrativen Shell beweist nur, was diese Shell tun würde. Wenn der Client eine Firewall-Mark setzt oder an ein VRF bindet, wiederhole die Abfrage mit der passenden Mark oder innerhalb des VRF und vergleiche die ausgewählte Route und den nächsten Hop. Die erste zu bestätigende Adresse ist die Peer-Adresse im Profil, nicht der Cluster oder Dienst, den der Nutzer nennt.

Eine explizite Unreachable-Route weist das Paket lokal zurück

Eine Route vom Typ unreachable ist eine bewusste lokale Antwort. Sie sagt dem Kernel, das Paket zu verwerfen und EHOSTUNREACH an den Absender zurückzugeben, weshalb der Fehler sofort und ohne abgehenden Verkehr erscheint. Jemand oder eine Automatisierung hat diese Route absichtlich dort eingetragen.

Die Routentypen sind nicht austauschbar. Blackhole verwirft das Paket ohne Fehler an den Absender, prohibit liefert EACCES und unreachable liefert EHOSTUNREACH. Ein VPN-Helfer, der während der Wiederverbindung eine Sink-Route installiert, kann daher einen Schwall von Host-Unreachable-Fehlern erzeugen, die verschwinden, sobald der Tunnel steht, während eine Blackhole-Route stattdessen stille Timeouts erzeugen würde.

Durchsuche alle Tabellen nach dem Typ, bevor du das entfernte Ende beschuldigst. Die Regel, die die Tabelle auswählt, zählt ebenso viel wie die Route darin, und eine zur Haupttabelle hinzugefügte Route hilft einem Client nicht, dessen Policy-Regel seinen Verkehr woandershin schickt.

Ein toter Nachbar erzeugt auf Ethernet denselben Fehler

Wenn die ausgewählte Route ein On-Link-Gateway verwendet, braucht die Zustellung eine aufgelöste Link-Layer-Adresse. Der Kernel sendet eine ARP- oder IPv6-Neighbor-Solicitation, und wenn keine Antwort eintrifft, kann das Paket nicht gerahmt werden. Der Sendevorgang schlägt dann mit EHOSTUNREACH fehl, obwohl die Route selbst gültig ist.

Die Nachbartabelle benennt die Phase. INCOMPLETE bedeutet, dass eine Auflösung noch läuft, FAILED bedeutet, dass der letzte Versuch keine Antwort erhielt, und REACHABLE oder STALE bedeutet, dass der Kernel eine nutzbare Adresse hat. Ein FAILED-Eintrag für das VPN-Gateway ist ein lokales Zustellproblem, kein Beweis über die ferne Seite des Tunnels.

Lies den Eintrag für den tatsächlichen nächsten Hop, nicht für die entfernte Internetadresse. Eine entfernte Adresse wird normalerweise über einen Router erreicht und hat daher keinen eigenen ARP-Eintrag; danach zu fragen ist ein Kategorienfehler, der Leute nach einem fehlenden Eintrag suchen lässt, den es nie geben sollte.

Entfernte Meldungen und asynchrone UDP-Fehler

EHOSTUNREACH kann auch von außen kommen. Ein Router, der das Paket nicht weiterleiten kann, sendet möglicherweise ICMP Host Unreachable, und der Kernel reicht diese Meldung an den Socket weiter, dem der Flow gehört. In diesem Fall sind Route und Nachbar in Ordnung, und der Fehler gehört zu einem Hop jenseits des lokalen Netzes.

UDP erschwert die Zuordnung. Ein Fehler, der von einem späteren Sende- oder Empfangsaufruf zurückgegeben wird, kann sich auf ein früheres Datagramm beziehen, sodass Adresse und Zeit des fehlschlagenden Aufrufs nicht zu dem Paket passen müssen, das die Meldung ausgelöst hat. Ein verbundener UDP-Socket erhält den Fehler einmal, und ein nicht verbundener Socket sieht ihn möglicherweise nie.

Darum gehört der Zeitpunkt in die Beweise. Notiere, wann der Fehler auftrat, welche Peer-Adresse der Socket verwendete und ob der Tunnel gerade neu verbunden wurde. Ein Schwall direkt nach einer Routenänderung deutet auf die lokale Tabelle; ein einzelner Fehler Minuten nach Beginn eines stabilen Flows deutet auf eine Pfadmeldung.

Trenne die Schichten, bevor du die Kryptografie änderst

Drei Fragen klassifizieren den Fehler. Hat der Kernel eine Route gewählt, die das Ziel zurückweist? Hat er eine gültige Route gewählt, aber den nächsten Hop nicht aufgelöst? Oder kam eine Meldung von jenseits des lokalen Netzes? Nur der dritte Fall kann das ferne Ende des Tunnels betreffen, und selbst dann nicht die Verschlüsselung.

Authentifizierungs- und Aushandlungsprobleme zeigen sich als eigene Fehler, nachdem der Transport den Peer erreicht. Eine Chiffre zu ändern oder den Client neu zu installieren kann eine lokale Unreachable-Route nicht beheben, und es zerstört die Routen- und Nachbar-Beweise, die du für die eigentliche Ursache bräuchtest.

Erfasse Ziel, Namespace, ausgewählte Tabelle, nächsten Hop, Nachbarzustand und Fehlerzeitpunkt vor der ersten Änderung. Führe dieselbe Abfrage nach der Behebung erneut aus; eine Route, die jetzt auf den Tunnel zeigt, und ein Nachbareintrag, der sich jetzt auflöst, sind ein stärkerer Beweis als ein erfolgreicher Ping an eine unbeteiligte Adresse.