VPN-Clients verbinden, aber kein Internet: drei fehlende Teile

Der Client bekommt eine Adresse, der Server beantwortet Pings, und jede Seite läuft trotzdem in einen Timeout. Die meisten beginnen an diesem Punkt, das Clientprofil zu bearbeiten, was meist vergeudete Mühe ist: Sobald der Tunnel steht, muss sich der Server wie ein Router verhalten. Drei Bedingungen müssen gleichzeitig gelten, bevor ein Paket hinausgeht und eine Antwort zurückkommt, und das Symptom ist identisch, welche auch immer fehlt.

Warum ein funktionierender Tunnel trotzdem keinen Weg nach draußen hat

Der Kernel muss Pakete zwischen Schnittstellen weiterleiten, was bei den meisten Linux-Distributionen standardmäßig aus ist. Der Verkehr muss auf eine Adresse übersetzt werden, die die Außenwelt beantworten kann, es sei denn, jeder Upstream-Router kennt bereits die Rückroute zum Tunnel-Subnetz. Der Forward-Pfad der Firewall muss den Verkehr in beide Richtungen zulassen, einschließlich der Antworten.

Jedes davon lässt sich unabhängig beheben, und genau das ist die Falle. Weiterleitung ohne Übersetzungsregel lässt Pakete mit privater Quelle und ohne Rückweg hinausgehen. Übersetzung ohne Forward-Regel lässt den Kernel das Paket einen Schritt später verwerfen.

Testen Sie also die drei Schichten statt den Client, und ändern Sie jeweils nur eine, damit das Ergebnis etwas aussagt.

Weiterleitung ist ein Kernel-Schalter, den Sie dauerhaft setzen müssen

Prüfen Sie den aktuellen Wert, bevor Sie ihn ändern, setzen Sie ihn dann und bestätigen Sie, dass die Änderung wirksam wurde.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Der erste Befehl zeigt den aktuellen Wert, der zweite setzt ihn zur Laufzeit, und der dritte beweist, dass das Schreiben funktioniert hat. Der Laufzeitwert verschwindet beim nächsten Neustart, weshalb eine funktionierende Sitzung nach Wartungsarbeiten ohne jede Konfigurationsänderung brechen kann.

Machen Sie ihn dauerhaft in einer Datei unter /etc/sysctl.d/, und wenden Sie dann diese Datei an, statt neu zu starten, um es herauszufinden. Unter FreeBSD ist das Äquivalent net.inet.ip.forwarding, mit gateway_enable=YES in rc.conf für die Dauerhaftigkeit. Ein Gerät, das Weiterleitung als deaktiviert meldet, erklärt eine ganze Klasse von Meldungen „Pakete kommen an, und nichts kommt zurück“. Prüfen Sie die Einstellung auch nach jedem Upgrade, denn ein neu gebauter Kernel oder ein ausgetauschtes Geräteabbild kann sie zurücksetzen, ohne es jemandem zu sagen.

Wählen Sie Masquerade oder eine feste Übersetzungsadresse

Bei einer dynamischen Außenadresse ist Masquerading die einfachste korrekte Form. Nennen Sie das Tunnel-Subnetz als Quelle und die Außenschnittstelle als Ausgang.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Bei einer statischen öffentlichen Adresse ist die Quellübersetzung auf genau diese Adresse vorhersehbarer und leichter zu prüfen.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Die zweite Form birgt eine Wartungsfalle: eine fest codierte Adresse, die sich später ändert, hält den Tunnel am Laufen, während der Internetzugang still aufhört. Verwenden Sie entweder Masquerade oder aktualisieren Sie die Regel, wann immer der Anbieter Sie verschiebt. Auch die Schnittstelle zählt, denn ein Router, der seinen eigenen Upstream-Tunnel teilt, muss über diesen Tunnel übersetzen und nicht über das physische WAN.

Die Filtertabelle ist das dritte Tor

Weiterleitung und Übersetzung können beide korrekt sein, während das Paket trotzdem in der Filtertabelle stirbt. ufw ist ein häufiger Übeltäter: Seine Forward-Policy wird als DROP ausgeliefert, und der Rest des Setups kann vollkommen korrekt aussehen, während diese eine Einstellung den Verkehr abtötet. Sie anzuheben ist eine bewusste Sicherheitsentscheidung und kein Kontrollkästchen.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Die erste Regel erlaubt neuen Verkehr vom Tunnel nach draußen, und die zweite erlaubt nur Antworten zurück. Verengen Sie beide auf das Tunnel-Subnetz und das beabsichtigte Ziel, denn eine pauschale Freigabe an der Tunnelschnittstelle macht das VPN zu einem offenen Ausgangspunkt für jeden, der sich authentifizieren kann.

Ein gebrückter Tunnel braucht eine andere Antwort. Die Adresse gehört zur Brücke, nicht zum physischen Port, daher entfernt das Versklaven der Schnittstelle die Adresse, die sie zuvor hatte, und der Host wirkt unerreichbar, bis die Brücke selbst eine erhält, was dhclient br0 liefern kann. Dieser Fehler sieht wie ein VPN-Problem aus und ist ein Problem der zweiten Schicht. Prüfen Sie die eigene Adresse der Brücke, bevor Sie die Firewall anfassen, denn eine Filteränderung kann einen Host nicht reparieren, der keine Adresse zum Senden mehr hat.

Wo Sie nachsehen, wenn eine Seite nie lädt

Pingen Sie die Tunneladresse des Servers, um zu beweisen, dass der Tunnel existiert. Führen Sie dann einen Traceroute vom Client zu einer öffentlichen Adresse aus und lesen Sie, wo er stoppt: Am Server kommt das Paket an, wird aber nicht weitergeleitet oder übersetzt; hinter dem Server liegt das Problem upstream und außerhalb Ihrer Hände.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Der erste Befehl beweist, dass der Tunnel Verkehr bis zum Server selbst trägt, und der zweite zeigt, wie weit ein Paket nach draußen kommt. Eine Spur, die an der Tunneladresse endet, deutet auf Weiterleitung oder Übersetzung am Server hin, während eine Spur, die einen Hop später stoppt, auf den Anbieter oder die Rückroute des Upstream-Routers deutet.

Beobachten Sie am Server die Außenschnittstelle, während ein Client eine Seite lädt. Verkehr, der mit einer privaten Quelladresse hinausgeht, bedeutet, dass die Übersetzung fehlt, und gar keine Antwort bedeutet, dass der Forward-Pfad oder die Upstream-Rückroute ihn verwirft.

Wenn entfernte Clients auch Hosts im LAN des Servers erreichen müssen, denken Sie daran, dass das LAN eine Rückroute zum Tunnel-Subnetz braucht. Das ist Routing und nicht Übersetzung, und es ist der Schritt, der am häufigsten vergessen wird, nachdem der Internetweg endlich funktioniert.