VPN-Tunnel verbindet nie: Wo die Pakete tatsächlich stoppen

Ein Tunnel, der nie entsteht, hinterlässt an beiden Enden ein leeres Protokoll. Prüfen Sie, ob GRE, ESP oder UDP 4500 verworfen wird, und erkennen Sie Carrier-NAT, bevor Sie den Server bearbeiten.

Der Client versucht es immer wieder, das Protokoll endet vor dem vollständigen Handshake, und der Server zeichnet überhaupt nichts auf. Dieses Muster weist weg von den Zugangsdaten und hin zum Pfad: Etwas zwischen den beiden Enden weigert sich, das Protokoll zu tragen, das der Tunnel braucht. Bestimmen Sie, wo die Pakete stoppen, bevor Sie eine der beiden Konfigurationen anfassen, denn ein gefiltertes Protokoll und ein falsches Passwort erzeugen in den meisten Clients dieselbe freundliche Fehlermeldung. Die Tests sind nach Kosten geordnet, der günstigste zuerst.

Beweisen Sie, wo der Verkehr stoppt

Zeichnen Sie gleichzeitig auf der ausgehenden Schnittstelle des Clients und auf dem Server auf. Vergleichen Sie, was hinausging, mit dem, was ankam, und notieren Sie, in welcher Richtung der Unterschied auftritt.

Nichts auf dem Server bedeutet, dass der Pfad oder das erste NAT den Verkehr verwirft, während Ankünfte ohne Antworten auf eine Firewall auf dem Server oder eine nicht vorhandene Rückroute deuten. Ein Router, der Tunnel häufig beendet, führt selten ein brauchbares Protokoll, also wird die Aufzeichnung zum Beleg. Notieren Sie Zielport und Protokollnummer, denn beide Fehler sehen in einem Client-Dialog gleich aus.

PPTP stirbt ohne Protokoll 47

PPTP trägt die Steuerung über TCP 1723 und seine Daten in GRE, das IP-Protokoll 47 ist und keine Portnummer. Nur 1723 weiterzuleiten ergibt das klassische Ergebnis: Die Verbindung authentifiziert sich und wird dann still, weil es keine Regel für das Protokoll gibt, das die Nutzlast trägt. Der Client kann das nicht von einem abgelehnten Passwort unterscheiden, deshalb muss die Aufzeichnung vor den Konfigurationsänderungen erfolgen.

Passthrough läuft in die entgegengesetzte Richtung einer eingehenden Weiterleitung, und Firmware verwendet oft genug dieselbe Bezeichnung für beides, um alle zu verwirren. Auf einem Linux-Client kann die lokale Firewall GRE lange vor der Beteiligung des Routers verwerfen, also braucht Protokoll 47 eine eigene Regel, und der conntrack-Helfer muss geladen sein. Ubuntus ufw hält diese Regeln in der before-Datei, weil gewöhnliche Allow-Regeln keine Protokollnummer ausdrücken können. Laden Sie die Firewall danach neu, statt den Rechner neu zu starten.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP und IPsec hinter zwei NATs

L2TP in IPsec braucht UDP 500 für den Schlüsselaustausch, UDP 4500 sobald NAT erkannt wird, und ESP als Protokoll 50. Jedes davon wird unabhängig gefiltert, eine Regel für eines beweist also nichts über die anderen zwei. Zwei Router in Reihe übersetzen jedes Paket zweimal, und die Endpunkte sind sich nicht mehr einig, was ausgehandelt wurde.

Bridgen Sie das äußere Modem, oder schalten Sie NAT am inneren Router ab, damit die öffentliche Adresse das Gerät erreicht, das den Tunnel beendet. Wo beides nicht möglich ist, muss der Tunnel von innerhalb der Doppel-NAT-Grenze aus initiiert werden, statt dort beendet zu werden.

Mobilfunknetze und geteilte Adressen

Eine WAN-Adresse innerhalb von 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 oder 100.64.0.0/10 bedeutet, dass der Router keine öffentliche Adresse hat und keine eingehende Weiterleitung aus dem Internet ihn erreichen kann. Carrier-Grade-NAT filtert zusätzlich Protokolle, die es nicht erwartet, und GRE ist auf Mobilfunkstrecken ein häufiges Opfer. Vergleichen Sie die WAN-Adresse auf dem Router selbst, nicht die Adresse, die eine Auskunftsseite für einen Client dahinter meldet.

Denselben Router an einer Kabelleitung zu betreiben, trennt einen Carrier-Befund mit einem einzigen Test von einem Konfigurationsfehler. Wo der Carrier das Protokoll verweigert, bleiben als Optionen ein anderer Transport auf 443 oder ein von innen initiierter Tunnel.

Lesen Sie die Listener-Liste, bevor Sie Ports schließen

Ein alarmierender Portscan ist oft nur das Funktionspaket, das standardmäßig aktiv ist. Erfassen Sie die Listener, ordnen Sie jedem Socket eine Funktion zu und deaktivieren Sie dann die Funktion, statt den Port zu blockieren, damit die beiden Ansichten nicht auseinanderlaufen.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

SoftEthers Standardwerte sind ein gutes Beispiel: TCP 443, 992 und 5555, wobei die Funktionen L2TP/IPsec und DNS-Tunnel eigene Sockets hinzufügen. Diese Funktionen abzuschalten entfernt die Listener, statt sie zu verstecken, und die Prüfung von einem externen Host sagt Ihnen, ob der Carrier den Port überhaupt durchlässt. Ein Listener, der lokal antwortet, kann weiter oben trotzdem geschlossen sein, also vergleichen Sie die eigene WAN-Adresse des Routers mit dem, was ein externer Dienst meldet.

Ähnliche Artikel