Mit OpenVPN verbunden, aber nichts lädt: ein Rundgang vom Client aus

Der Tunnel steht und der Browser dreht sich weiter. Arbeiten Sie sich vom Client nach außen: zwei Mitschnitte, ein Kernel-Schalter, das echte Ausgangsinterface, dann DNS.

Das Client-Fenster zeigt Connected, die Tunneladresse ist da, und der Browser dreht sich weiter. Diese Kombination ist normal, denn ein erfolgreicher Handshake beweist nur, dass der Tunnel aufgebaut wurde; er sagt nichts darüber, ob der Server Ihre Pakete weiterleitet, ihre Quelle umschreibt oder Ihre DNS-Anfragen beantwortet. Der Fehler, den die meisten machen, ist, zuerst die Serverkonfiguration zu öffnen. Arbeiten Sie sich stattdessen vom Client nach außen, denn jeder Schritt unten sagt Ihnen, ob der nächste überhaupt einer Prüfung wert ist.

Beim Client beginnen und nach außen arbeiten

Führen Sie drei Tests in dieser Reihenfolge aus und notieren Sie, wo der erste scheitert. Pingen Sie die Tunneladresse des Servers an, was beweist, dass der Tunnel selbst Verkehr trägt. Pingen Sie eine öffentliche Adresse per Nummer an, was Weiterleitung und Übersetzung beweist, ohne Namensauflösung einzubeziehen. Versuchen Sie dann, einen Hostnamen aufzulösen, was der einzige Test ist, der DNS beansprucht. Jedes Ergebnis nimmt eine ganze Schicht aus dem Verdacht.

Springen Sie nicht zum dritten Test, weil ein Browser sich schneller anfühlt. Ein fehlgeschlagener Seitenaufruf deckt alle drei Schichten auf einmal ab, und genau dort fangen Leute an und bauen dann einen funktionierenden Tunnel neu. Eine scheiternde Seite sagt Ihnen nicht, welche der drei Schichten kaputt ist.

Zwei Mitschnitte zeigen, wo die Pakete stoppen

Während vom Client ein Ping an eine öffentliche Adresse läuft, nehmen Sie einen Mitschnitt am Tunnel-Interface und einen am Uplink auf, der das Internet erreichen soll. Lassen Sie beide gleichzeitig laufen, damit die Zeitstempel zusammenpassen.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Erscheinen die Anfragen am Tunnel und nie am Uplink, hat der Server sie zwischen Tunnel und Kabel verworfen, und die Ursache ist Weiterleitung oder die Forward-Policy der Firewall, nicht NAT. Erscheinen sie an beiden, hat der Server seinen Teil getan und die Antwort fehlt weiter draußen, was auf Übersetzung, einen Upstream-Filter oder eine Einschränkung des Anbieters deutet.

Holen Sie den Namen des Uplinks aus der Routingtabelle, nicht aus einem Tutorial. Cloud-Images und umbenannte Adapter passen selten zum Beispiel-Interface einer Anleitung, und ein Mitschnitt auf dem falschen Gerät sieht genau aus wie ein Server, der nicht weiterleitet:

ip -4 route get 9.9.9.9

Das Feld dev in dieser Ausgabe ist der Name, den die NAT-Regel später braucht, also behalten Sie ihn.

Weiterleitung ist ein Kernel-Schalter und eine Firewall-Policy

Der Kernel muss überhaupt bereit sein weiterzuleiten. Lesen Sie den aktuellen Wert und machen Sie die Einstellung dann dauerhaft, statt sie nur in den laufenden Kernel zu schreiben:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Weiterleitung ist nur die Hälfte. Auf einem Host mit UFW wird die Forward-Policy in /etc/default/ufw gesetzt und muss ACCEPT sein, bevor ein Reload wirkt. Ein Standard-Drop auf dem Forward-Pfad lässt den Handshake völlig gesund, verwirft aber still jedes Paket, das den Tunnel verlassen will, und genau das ist das Symptom, mit dem Sie angefangen haben.

Hosts, die nftables direkt verwalten, haben dieselbe Frage in anderer Syntax. Beobachten Sie die Zähler der Forward-Kette, während ein Client-Test läuft, denn eine Kette, die konsultiert wird, und eine, die verwirft, sehen in einer Konfigurationsdatei gleich aus.

Benennen Sie das echte Ausgangsinterface in der NAT-Regel

Quellübersetzung gehört auf das Interface, das den Host tatsächlich verlässt, mit dem Pool, den der Server ausgibt. Beide Hälften dieser Regel müssen die Realität beschreiben, und keine ist optional.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Der klassische Fehler ist eine aus einer Anleitung kopierte Regel, die -o eth0 sagt, auf einer Maschine, deren Adapter anders heißt. Die Regel wird ohne Warnung installiert, passt auf nichts, und der Client hat weiterhin kein Internet. Der Pool ist die andere Hälfte desselben Fehlers: Wenn der Server 10.44.0.0/24 ausgibt und die Regel 10.8.0.0/24 deckt, wird nie etwas passen.

Achten Sie auf die Zähler, statt dem Regeltext zu vertrauen. Die Auflistung meldet Pakete pro Regel, und eine Regel, die nie passt, bleibt bei null, so korrekt sie auch aussieht. Geben Sie ihr eine Minute echten Client-Verkehr, bevor Sie etwas in diese Zahl hineinlesen:

iptables -t nat -L POSTROUTING -v -n

Ein Paketzähler von null nach einem echten Client-Test bedeutet, dass der Treffer falsch ist, nicht dass der Tunnel kaputt ist. Sobald er passt, speichern Sie das Regelset, damit es einen Neustart überlebt; eine Korrektur, die nur in Ihrer Shell-Historie lebt, verschwindet beim ersten Neustart.

Ist der Server auch eine Cloud-NAT-Instanz, hat die Plattform ein Wort mitzureden. Eine Instanz, die Adressen übersetzt, braucht meist die deaktivierte Quell- und Zielprüfung, wo der Anbieter diese Einstellung anbietet, und der VPN-Port selbst muss von außen erreichbar sein.

DNS ist der zweite Fehler hinter dem ersten

Ping per Adresse funktioniert, während Namen scheitern, ist ein Resolver-Problem, und es hat seine eigene Ursache. Ein Client, der seinen lokalen Resolver behält, schickt diese Anfragen in einen vollen Tunnel und wartet auf eine Antwort, die nie kommt, weil der lokale Resolver jetzt auf der falschen Seite der Route liegt.

Schieben Sie einen Resolver vom Server, damit der Client weiß, wo er fragen soll. Zwei Einträge geben dem Client einen Rückfall, falls der erste nicht erreichbar ist, und beide sollten Resolver sein, die der Tunnel tatsächlich zulässt.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows-Clients fallen dann trotzdem auf den lokalen Resolver zurück, und genau das soll block-outside-dns verhindern, auf Kosten von Namen, die nur das lokale Netz auflösen kann. Linux-Clients mit systemd-resolved ignorieren einen geschobenen Resolver oft, solange kein Skript ihn installiert, prüfen Sie also resolvectl status für das Tunnelgerät, bevor Sie schließen, dass der Push ignoriert wurde.

Beenden Sie den Rundgang so, wie ein Nutzer ihn erlebt. Laden Sie eine echte Seite vom Client, bestätigen Sie die Adresse, von der sie ausgeht, starten Sie den Server neu, verbinden Sie sich erneut und wiederholen Sie die drei Tests. Nur dieser zweite Durchlauf beweist, dass die gespeicherten Regeln, die Firewall-Policy und der geschobene Resolver alle zusammen überlebt haben.

Ähnliche Artikel