PiVPN-Handshake funktioniert, Seiten hängen: MASQUERADE prüfen

Ihr Telefon zeigt den Tunnel als verbunden, der Client meldet eine private Adresse, und die erste Seite hängt trotzdem mitten im Laden. Diese Kombination schickt die meisten Leute in die Verschlüsselungseinstellungen und zu CPU-Temperaturen, wo tatsächlich nichts kaputt ist. Der Tunnel kam hoch, die Aushandlung war also abgeschlossen; gescheitert ist der Schritt danach, wenn der Server versucht, Client-Pakete ins Internet zu übergeben. Gehen Sie denselben Weg, den diese Pakete nehmen, und die Diskrepanz ist meist in einer Zeile der NAT-Tabelle sichtbar.

Beginnen Sie damit, was der Client erreicht und was nicht

Laden Sie vom verbundenen Client eine Seite, die im öffentlichen Internet liegt, und notieren Sie, ob sie sofort scheitert oder auf halbem Weg hängt. Öffnen Sie dann eine Ressource auf der eigenen privaten Adresse des VPN-Servers und vergleichen Sie die beiden Ergebnisse.

Eine Tunneladresse, die auf Pings antwortet, während öffentliche Seiten in ein Zeitlimit laufen, ist das Kennzeichen eines Weiterleitungs- oder Übersetzungsproblems, nicht eines kaputten Handshakes. Das Statusfenster des Clients selbst kann beides nicht unterscheiden, weil es nur weiß, dass der Steuerkanal steht. Prüfen Sie auf dem Server die Tunnel-Schnittstelle mit ip -br addr show tun0 und bestätigen Sie, dass die dem Client zugewiesene Adresse im konfigurierten Pool liegt. Wenn Pool und Client-Adresse nicht übereinstimmen, beheben Sie das zuerst, denn jede Regel weiter unten passt auf den Pool.

Fragen Sie als Nächstes den Server, welche Schnittstelle er für eine öffentliche Adresse nutzen würde. ip route get 203.0.113.9 gibt das gewählte Gerät und die Quelle in seiner ersten Zeile aus. Notieren Sie den Gerätenamen, denn genau dieser Wert muss in der NAT-Regel stehen.

Lesen Sie die Regel, die entscheidet, ob Pakete hinausgehen

MASQUERADE schreibt ein Paket nur dann um, wenn es die in der Regel genannte Schnittstelle verlässt. Eine Regel, die auf ein kabelgebundenes Gerät beschränkt ist, tut nichts für Verkehr, der über WLAN hinausgeht, und das Paket behält seine private Quelladresse bis zum übergeordneten Router. Dieser Router hat keine Route zurück zu Ihrem Tunnel-Pool, also verwirft er die Antwort, und der Client sieht eine Verbindung, die sich öffnet und dann stirbt. Das Symptom skaliert damit, wie viel von der Seite ankommt, bevor die erste Antwort nötig ist.

Listen Sie die laufende Tabelle auf und lesen Sie die Spalte der Ausgangsschnittstelle, statt nur nach dem Wort MASQUERADE zu suchen. Die Ausgabe der Hinzufügen-Form ist leichter zu vergleichen als eine formatierte Liste:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Auf einem Raspberry Pi, der früher Ethernet und jetzt WLAN nutzt, ist der veraltete Name fast immer die ganze Geschichte. Der Installer hielt fest, welches Gerät bei der Einrichtung vorhanden war, und das gespeicherte Regelset spielt es bei jedem Start erneut ab. Vergleichen Sie das Gerät aus der Routensuche mit dem in der Regel, bevor Sie etwas anderes ändern. Stimmen sie überein, ist die Schnittstelle nicht Ihr Problem, und Sie sollten zu den Zählern im letzten Abschnitt wechseln. Weichen sie ab, ist die Korrektur eine Änderung von einem Wort in der Persistenzdatei.

Korrigieren Sie das gespeicherte Regelset, nicht nur das laufende

Nur die laufende Tabelle zu bearbeiten hält bis zum nächsten Neustart, und das ist genau lange genug, um Sie zu überzeugen, dass das Problem gelöst ist. Die Regeln, die beim Start zurückkommen, liegen in einer Datei, die ein Firewall-Persistenzpaket neu lädt. Auf Debian-basierten Pi-Images ist diese Datei normalerweise /etc/iptables/rules.v4.

Machen Sie eine Kopie, bevor Sie sie anfassen, und ersetzen Sie dann die Ausgangsschnittstelle in der MASQUERADE-Zeile durch das notierte Gerät, zum Beispiel -o wlan0 statt -o eth0. Lassen Sie den Quellbereich, wie er ist, es sei denn, Ihr Client-Pool hat sich geändert. Laden Sie neu und bestätigen Sie, dass die Regel jetzt das richtige Gerät nennt:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Zwei benachbarte Einstellungen vergisst man leicht. sysctl net.ipv4.ip_forward muss 1 melden, und der übergeordnete Router darf private Quelladressen nicht selbst filtern.

Beweisen Sie, dass die Regel greift, und isolieren Sie dann, was noch langsam ist

Zähler sind der einzige ehrliche Beweis, dass eine Regel getroffen hat. Führen Sie die ausführliche Auflistung aus, starten Sie einen Download auf dem Client und führen Sie sie erneut aus. Die Paket- und Byte-Spalten neben Ihrer Regel sollten steigen, und eine Regel, die bei null bleibt, trifft weiterhin nicht. Bewegen sich die Zähler, scheitern die Seiten aber weiter, vergleichen Sie den Quellbereich mit dem tatsächlichen Pool mit grep -n "^server " /etc/openvpn/server.conf. Bewegen sie sich und laden die Seiten, ist der Durchsatz aber schlecht, ist die Übersetzung erledigt und das verbleibende Problem liegt woanders.

Vergleichen Sie zwei Übertragungen vom selben Client, eine zu einem Host im lokalen Netz und eine durch den Tunnel zu demselben Host. Langsam in beiden Fällen deutet auf den Uplink oder die WLAN-Strecke des Pi hin, nicht auf das VPN. Langsam nur durch den Tunnel deutet auf MTU und Wiederholungen hin, die Sie mit ip -s link show tun0 untersuchen können, bevor Sie irgendeine Krypto-Einstellung ändern.

Um das Experiment rückgängig zu machen, stellen Sie die Kopie wieder her und laden sie erneut, dann bestätigen Sie, dass die ursprüngliche Regel und ihre Zähler zurück sind. Schreiben Sie das Ausgangsgerät und den Neuladebefehl in die Servernotizen, denn die nächste Uplink-Änderung entdeckt dieselbe Diskrepanz neu. Eine Regel, die das falsche Gerät nennt, bleibt unsichtbar, bis der Verkehr sie braucht.