Tunnel steht, kein Internet: Wo die Weiterleitung endet

Authentifizierung und ein funktionierender Tunnel bedeuten keinen Internet-Ausgang. Verfolgen Sie eine Anfrage durch Quelladressierung, Weiterleitung und Antwortpfad.

Der Client verbindet sich, der Tunnel trägt Pings zum Gateway, und dahinter antwortet nichts. Dieser Zustand ist normal für ein Gateway, das nie mehr als Zugang zu geschützten Netzen bieten sollte, und er ist ein Fehler für eines, das als Volltunnel-Ausgang beworben wird. Bevor Sie Regeln ändern, prüfen Sie, welcher Dienst zugesagt wurde. Verfolgen Sie dann eine einzelne öffentliche Anfrage durch die vier Stellen, an denen sie stoppen kann. Eine Anfrage und ein Paketmitschnitt klären mehr als eine Seite voller Vermutungen.

Prüfen, ob Internet-Ausgang je das Design war

Ein Split-Tunneling-Profil leitet nur die geschützten Subnetze in das VPN, sodass öffentliches Surfen über die lokale Verbindung läuft und das Gateway nie berührt. Ein Volltunnel-Profil installiert eine Standardroute in den Tunnel, wodurch das Gateway für den gesamten Pfad verantwortlich ist. Beides sind legitime Designs, und ihre Verwechslung erzeugt einen Fehlerbericht, wo keiner ist. Lesen Sie die angekündigten Routen des Clients, bevor Sie irgendetwas anderes testen, denn die Routentabelle beantwortet die Frage, die das Ticket meist falsch stellt.

Was der Client installiert, ist nicht immer das, was das Profil beabsichtigt. Eine gepushte Route kann von einer lokalen Route mit niedrigerer Metrik überschrieben werden, und ein Client, der seine LAN-Route behält und zugleich eine Standardroute hinzufügt, verhält sich für dieses Subnetz wie ein Split-Tunnel.

Eine einzelne öffentliche Anfrage verfolgen

Wählen Sie ein einziges Ziel und verfolgen Sie es vom Client nach außen. Prüfen Sie auf dem Client, ob das Paket tatsächlich den Tunnel wählt und welche lokale Adresse es als Quelle verwendet. Prüfen Sie dann das Gateway: Kommt das Paket an, und verlässt es die öffentliche Schnittstelle. Jede dieser Antworten schließt eine ganze Ursachenkategorie aus.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Sieht das Gateway das Paket nie, sind die Client-Route oder die Tunnelauswahl falsch. Kommt es an und geht nicht hinaus, liegt das Problem am Gateway, und die verbleibenden drei Prüfungen greifen.

Weiterleitung, Route und Übersetzung prüfen

Die Weiterleitungsanleitung, die mit strongSwan ausgeliefert wird, gilt für ein Gateway jedes Tunneltyps: Der Kernel muss Pakete zwischen Schnittstellen bewegen dürfen, und eine nutzbare Route muss ins Internet zeigen. Die Firewall-Richtlinie muss den Verkehr dann erlauben, und die Quelladresse muss eine sein, die die öffentliche Seite beantworten kann. Eine private Client-Adresse, die unverändert ins Internet weitergeleitet wird, erhält nie eine Antwort.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Quellübersetzung ist das übliche fehlende Stück. Mit ihr schreibt das Gateway die Client-Quelle auf seine öffentliche Adresse um und verfolgt den Fluss; ohne sie hat die Antwort keinen Weg zurück. Cloud-Plattformen fügen eine zweite Grenze hinzu, an der die Routentabelle oder Sicherheitsgruppe der Instanz Verkehr verwerfen kann, den die Gast-Firewall erlaubt. Diese Grenze ist leicht zu übersehen, weil das Gastsystem von innen korrekt konfiguriert aussieht.

Reverse-Path-Filterung kann bei einer asymmetrischen Konfiguration auch gültige Pakete verwerfen. Lesen Sie den Zähler dieser Regel, statt anzunehmen, dass sie in Ordnung ist, denn eine strenge Einstellung an der öffentlichen Schnittstelle weist Verkehr ab, der über einen anderen Pfad ankommt, als die Routentabelle vorhersagt.

Antwortpfad und Resolver sind zwei verschiedene Antworten

Achten Sie ebenso auf die Antwort wie auf die Anfrage. Geht die Anfrage übersetzt hinaus und kehrt die Antwort in den übersetzten Fluss zurück, funktioniert die Weiterleitung auch dann, wenn die Anwendung weiterhin scheitert, und die nächste Untersuchung gehört zur Anwendung oder zu DNS.

Eine Seite, die einen HTTP-Fehler zurückgibt, beweist, dass die Internet-Weiterleitung funktioniert. Ein Name, der sich nicht auflösen lässt, während der Adresszugriff funktioniert, ist ein Resolver-Problem, kein NAT-Problem.

Testen Sie nach einer engen Korrektur den Client erneut sowie jede absichtlich eingeschränkte private Ressource. Internetzugang zu gewähren darf den Zugang nicht still auf jedes am Gateway hängende Netz erweitern.

Ähnliche Artikel