Gerouteter VPN-Client erreicht den Server, aber nicht die LAN-Hosts

Der Tunnel kommt hoch, der Client pingt den VPN-Server, und eine Freigabe auf einer Maschine einen Hop weiter antwortet nie. Nichts in der Client-Konfiguration erklärt das, denn die Anfrage hat den Client tatsächlich verlassen und ist tatsächlich angekommen. Gescheitert ist der Rückweg, und das gescheiterte Gerät ist meist das LAN-Gateway und nicht der VPN-Host. Die Verfolgung des Antwortpakets erklärt die ganze Klasse von Symptomen.

Folgen Sie der Antwort, nicht der Anfrage

Der VPN-Server entschlüsselt das Client-Paket und leitet es mit der Client-Adresse weiterhin im Quellfeld ins LAN. Der Zielhost antwortet an diese Adresse, und nun entscheidet seine eigene Routing-Tabelle alles. Sein Standard-Gateway weiß nichts vom Tunnel-Pool, also verlässt die Antwort das Netz in Richtung Internetanbieter und wird irgendwo auf diesem Weg verworfen.

Beim Client ist das Symptom ein stilles Zeitlimit: keine Ablehnung, kein Reset, einfach nichts. Das Durchsuchen einer Freigabe hängt, ein Ping meldet keine Antwort, und die Server-Logs sehen gesund aus, weil der Server seine Arbeit getan hat.

Legen Sie die Rückroute dorthin, wo die Hosts nachsehen

Jeder LAN-Host fragt sein Standard-Gateway, also ist das Gateway das einzige Gerät, das wissen muss, wo der Tunnel-Pool liegt. Tragen Sie dort eine statische Route ein, und jeder Host erbt den richtigen Weg, ohne angefasst zu werden.

Wenn das Gateway seine eigene Adresse als DHCP-Option verteilt, verteilen Sie die Route auf diesem Weg, damit neue Maschinen sie automatisch übernehmen. Andernfalls lebt die Route in einer Konfigurationsdatei und verschwindet beim nächsten Neuaufbau.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Warum Source NAT das Problem zu beheben scheint

Das Maskieren des Client-Pools hinter der Adresse des VPN-Servers beseitigt das Problem, indem es die Client-Adresse aus dem Paket entfernt. Antworten kommen dann zum Server zurück, der bereits weiß, wie er den Tunnel erreicht, und alles funktioniert. Der Preis ist, dass interne Hosts nicht mehr sehen können, wer der Client ist, und jede Verbindung so aussieht, als käme sie von einer einzigen Maschine.

Dieser Tausch ist manchmal richtig, etwa wenn ein Gerät eines Herstellers keine statische Route erhalten kann. Machen Sie die Regel nicht breiter als den aktuellen Pool, denn eine für ein /24 geschriebene Regel passt nicht mehr, sobald der Pool auf ein /16 umnummeriert wird, und das erste Anzeichen ist ein Schwung neuer Clients, die sich verbinden und nichts erreichen.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Der Cloud-Weg braucht drei Einstellungen

In einer VPC kehrt dieselbe Lücke in anderer Form zurück, weil das Subnetz überhaupt keine Route für den Client-Bereich hat. Die Routentabelle braucht einen Eintrag für den Tunnel-Pool, der auf die Netzwerkschnittstelle der Instanz zeigt, und an der Schnittstelle muss die Quell- und Zielprüfung aus sein, damit die Plattform Pakete annimmt, deren Quelle nicht ihre eigene Adresse ist. Sicherheitsgruppen und Netzwerk-ACLs müssen den Pool außerdem in beide Richtungen zulassen.

Jede Auslassung erzeugt einen eigenen Teilfehler. Lassen Sie den Eintrag in der Routentabelle weg, und private Instanzen antworten in ein Subnetz, das die Antwort nicht zurück in den Pool tragen kann. Bleibt die Prüfung aktiv, verwirft die Plattform die Antwort, nachdem die Instanz sie bereits gesendet hat. Ohne die Regel der Sicherheitsgruppe kommt die Anfrage selbst nie an, und der Client sieht das Zeitlimit eine Schicht früher.

Führen Sie die Prüfungen in dieser Reihenfolge aus

Bestätigen Sie Weiterleitung und Filterrichtlinie, bevor Sie das Routing beschuldigen, denn ein Host, der nicht weiterleitet, scheitert auf dieselbe stille Weise. Lesen Sie dann die wirksame Einstellung für den Rückweg an der Schnittstelle, die den Tunnel trägt, da ein strenger Filter Antworten verwerfen kann, die aus einer unerwarteten Richtung kommen.

Schließen Sie mit einem Mitschnitt am LAN-Host ab, während der Client ihn pingt. Eine Anfrage, die ohne passende Antwort ankommt, beweist den Rückweg, und eine Anfrage, die nie ankommt, verschiebt den Fehler zurück zum Server oder zum Tunnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Die Quell- und Zielprüfung ist dokumentiert in der Anleitung für elastische Netzwerkschnittstellen. Setzen Sie sie an der Schnittstelle, die den Tunnelverkehr tatsächlich trägt, nicht an einem unbeteiligten Adapter derselben Instanz.