VPN-Gateway braucht IP-Weiterleitung: was zu prüfen ist
Ein Gateway kann auf seiner eigenen Adresse antworten und dabei nichts zwischen den Schnittstellen weitergeben. Prüfen Sie die Weiterleitung je Adressfamilie und dann den Rückweg.
Ihr Client kann die Adresse des Gateways anpingen, während jede Ressource dahinter unerreichbar bleibt. Dieses Beobachtungspaar beschreibt einen Host, der mit Ihnen spricht, und einen Router, der nicht routet – zwei verschiedene Rollen auf derselben Maschine. Die Weiterleitung ist der Schalter dazwischen.
Die beiden Rollen sind unabhängig, und das gilt auch für die beiden Adressfamilien.
Auf die eigene Adresse zu antworten beweist nichts
Wenn ein Paket an das Gateway selbst adressiert ist, verbraucht der lokale Stack es, und es findet keine Weiterleitungsentscheidung statt. Deshalb sagt Ihnen ein erfolgreicher Ping auf die Tunneladresse oder eine Verwaltungsschnittstelle, dass der Daemon lebt und der Tunnel steht, während er nichts über Verkehr aussagt, der für ein Netz hinter der Box bestimmt ist. Der Kernel zieht seinen Weiterleitungspfad nur für Pakete heran, die nicht an ihn adressiert sind.
Lesen Sie die Anforderung als Rolle, nicht als Einstellung: Dieser Host muss Pakete zwischen zwei Schnittstellen bewegen. Ein Laptop, der nur ein entferntes Netz erreichen muss, übernimmt diese Rolle nie, ein Site-to-Site-Endpunkt immer. Diese Lesart erklärt, warum eine funktionierende Client-Konfiguration versagt, wenn sie auf ein Gateway verschoben wird.
Derselbe Satz gilt für die Firewall vor der Weiterleitungsentscheidung, die ihre eigene Richtlinie dazu hat, was weitergeleitet werden darf.
Prüfen Sie jede Adressfamilie getrennt
IPv4-Weiterleitung ist ein Schalter, und IPv6-Weiterleitung ist ein anderer mit eigenem Verhalten je Schnittstelle. Den ersten einzuschalten sagt nichts über den zweiten, und ein Dual-Stack-Client kann die Hälfte eines Netzes erreichen, während der Rest dunkel bleibt. Zwei Clients unterschiedlicher Familien können sich daher über dasselbe Gateway uneinig sein. Fragen Sie, welche Familie der fehlerhafte Client verwendet hat, bevor Sie eine der beiden Einstellungen ändern. Bestätigen Sie beide, bevor Sie schließen, dass das Routing-Design falsch ist.
sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40
Bei vielen Distributionen wurde der Wert, den Sie zur Laufzeit lesen, von einem Dienst oder einer Konfigurationsdatei dort abgelegt, sodass eine Änderung per Einmalbefehl beim Neustart verschwinden kann. Finden Sie die Datei, der die Einstellung gehört, bevor Sie den Laufzeitwert bearbeiten.
Weiterleitung ist eine von vier Anforderungen
Ein funktionierender weitergeleiteter Fluss braucht vier Dinge gleichzeitig: Der Client muss wissen, dass das Ziel hinter dem Tunnel liegt, das Gateway muss eine Route weiter haben, Antworten müssen einen Rückweg haben, und die Firewall muss den Verkehr zulassen. Quellübersetzung gehört als Option und nicht als Regel zu diesem Entwurf, weil ein privates geroutetes Netz mit symmetrischen Pfaden sie nicht braucht und ein asymmetrisches sie meistens braucht. Jedes der vier scheitert unabhängig, weshalb die Reparatur eines einzelnen das Symptom selten verschiebt. Schreiben Sie alle vier auf, bevor Sie eines davon ändern.
Cloud-Plattformen fügen einen fünften Gesichtspunkt hinzu. Manche erzwingen Quell- und Zielprüfungen auf Instanzen, wodurch weitergeleitete Pakete verworfen werden, unabhängig davon, wie der Kernel des Gasts konfiguriert ist. Die eigene Netzwerkdokumentation der Plattform ist dort maßgeblich, nicht die sysctl-Ausgabe in der VM.
Testen Sie vom Client, nicht vom Gateway
Ein Test in der Shell des Gateways selbst durchläuft keinen Teil des Weiterleitungspfads, den Sie gerade aktiviert haben. Erzeugen Sie den Verkehr von dem Client, der das Problem hat, und bestätigen Sie, dass er etwas hinter dem Gateway erreicht statt das Gateway selbst. Das ist der einzige Test, der die Rolle ausübt, die Sie geändert haben.
Halten Sie Listener-Regeln und Weiterleitungsregeln im Kopf und im Änderungsprotokoll getrennt. Das Öffnen des VPN-Ports lässt Clients zum Dienst herein; es gewährt ihnen nichts im Netz dahinter, und in einer Firewall-Liste, die über Jahre gewachsen ist, sehen beide gleich aus.
Wenn Pakete ankommen und der Dienst den Benutzer dann ablehnt, haben Sie die Netzwerkebene verlassen. Fahren Sie mit der Anwendungsautorisierung fort, statt die Weiterleitungsrichtlinie erneut zu erweitern.