Webserver verschwindet, sobald der VPN-Client sich verbindet

Ein Dienst, der in dem Moment verschwindet, in dem ein VPN-Client sich verbindet, wird meist nicht blockiert, sondern antwortet über die falsche Schnittstelle. Die Anfrage kommt auf der physischen Netzwerkkarte an, der Daemon schreibt eine Antwort, und die Routing-Tabelle übergibt diese Antwort an den Tunnel, da der Tunnel die Standardroute übernommen hat. Der entfernte Client sieht nie eine Antwort auf eine Verbindung, die er geöffnet hat, also wartet er und meldet dann eine Zeitüberschreitung. Keine Firewall-Regel ist irgendwo in dieser Kette beteiligt.

Das Symptom: Anfragen hinein, Antworten zur falschen Tür hinaus

Der Hinweis ist eine eingehende Verbindung, die scheitert, während alles andere auf dem Host funktioniert. Ein weiteres Indiz ist ein Host, der aus dem LAN erreichbar ist, aber nicht aus dem Internet, oder einer, der funktioniert, bis der Tunnel sich neu verbindet, und dann aufhört. In jedem Fall verhielt sich die Hinrichtung richtig und die Rückrichtung nicht, was auf Routing-Asymmetrie und nicht auf eine Policy hindeutet.

Bestätigen Sie es, indem Sie beobachten, wohin die Antwort geht, nicht indem Sie beobachten, wie die Anfrage ankommt.

Zeichnen Sie gleichzeitig auf der physischen Schnittstelle und auf dem Tunnelgerät auf. Erscheint die Anfrage auf der physischen Schnittstelle und die Antwort auf dem Tunnel, ist die Diagnose abgeschlossen. Eine Antwort, die nirgends erscheint, bedeutet, dass der Dienst die Verbindung nie angenommen hat, was eine eigene Untersuchung mit eigener Ursache ist.

Zwei Standardrouten und eine Routing-Entscheidung

Ein Client, der eine Standardroute installiert, fügt einen zweiten Eintrag mit einer besseren Metrik als das LAN-Gateway hinzu. Manche Clients installieren stattdessen zwei Halbbereichsrouten, die denselben Raum spezifischer abdecken und die Suche auf dieselbe Weise gewinnen. Beide Techniken lassen gewöhnliche ausgehende Pakete die Tunnelschnittstelle wählen.

Diese Wahl wird allein vom Ziel bestimmt. Der Kernel fragt nicht, woher ein Paket kam, es sei denn, eine Policy-Regel weist ihn dazu an. Also wird die Antwort an eine öffentliche Client-Adresse dem Tunnel übergeben, dessen Gegenstelle ein Paket mit einer Quelladresse erhält, die sie nicht besitzt, und es verwirft oder irgendwohin Nutzloses weiterleitet. Unter Linux kann strikte Reverse-Path-Filterung auch die ursprüngliche Anfrage verwerfen, bevor Ihr Dienst sie überhaupt sieht, was von außen identisch aussieht. Beide Symptome stammen aus derselben fehlenden Verknüpfung zwischen einem eingehenden Fluss und seiner Antwort.

Der Tunnel verhält sich durchweg korrekt. Ihm wurde gesagt, die Standardroute zu tragen, und genau das tut er.

Reparieren Sie den Rückweg, ohne den Tunnel zu brechen

Es gibt drei dauerhafte Formen der Reparatur, und die Wahl hängt davon ab, wie viel des eigenen Verkehrs des Hosts im Tunnel bleiben soll. Das Ziel oder den Port des Dienstes auszunehmen ist die kleinste Änderung. Policy-Routing nach Quelle oder Markierung ist die präziseste. Quellübersetzung ist die gröbste und die am leichtesten zu erklärende zwei Jahre später.

Wählen Sie danach, was der Host leisten muss, nicht danach, welches Snippet Sie zuerst gefunden haben.

Das Ausnehmen eines Ziels passt zu einem Dienst mit stabiler öffentlicher Adresse, und den Daemon an die physische Adresse statt an jede Adresse zu binden macht diese Ausnahme sicherer. Eine Policy-Regel, die eine Tabelle nach Quelle auswählt, hält die eigenen Verbindungen des Hosts im Tunnel, während sie die Antworten des Dienstes über das WAN-Gateway zurückschickt. Das Maskieren von Antworten auf die WAN-Schnittstelle erreicht denselben Weg um den Preis, die Adresse des Clients aus den Dienstprotokollen zu verbergen. Ein Ad-hoc-Wechsel der Standardroute ist eine Diagnose und keine Konfiguration, weil der Client bei jeder Neuverbindung die Routen neu schreibt.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Wenn der Host auch für ein LAN hinter sich routet

Einen Hop weiter außerhalb kehrt dieselbe Asymmetrie mit mehr beweglichen Teilen zurück. Verkehr erreicht den Router aus dem Internet, wird an ein internes Gerät weitergeleitet, und der einzige Weg dieses Geräts zurück ist der Tunnel, sodass die Antwort den ursprünglichen Client von der Adresse des Anbieters selbst erreicht. Die Verbindungsverfolgung trifft dann auf eine Antwort für einen Fluss, dessen Beginn sie nicht gesehen hat, und verwirft sie. Der Client sieht in der Zwischenzeit überhaupt nichts.

Zwei Änderungen beheben es: Zielübersetzung, damit die eingehende Verbindung das interne Gerät erreicht, und Quellübersetzung, damit die Antwort dieses Geräts so aussieht, als käme sie vom Router selbst.

In der Router-Firmware ist der übliche Ausdruck eine Policy-Regel, die die Portweiterleitung an die WAN-Seite bindet, während der eigene Verkehr des Routers durch den Tunnel läuft. Ohne Quellübersetzung ist diese Antwort an den externen Client adressiert, und das interne Gerät hat einfach keine Route dorthin. Testen Sie drei Dinge getrennt, weil sie aus verschiedenen Gründen scheitern: eine von außen ankommende Verbindung, eine, die der Host selbst beginnt, und eine Namensauflösung.