Doppeltes NAT und Ihr VPN: Der Client funktioniert, der Server nicht

Ihr Router steht hinter einem anderen Router, die WAN-Adresse ist privat, und der VPN-Client verbindet sich trotzdem. Diese Kombination überrascht Leute, die erwarten, dass doppeltes NAT Tunnel zerstört, aber genau ausgehende Verbindungen bewältigt die Übersetzung am besten. Einen VPN-Server hinter denselben zwei Ebenen zu betreiben, ist der Fall, der gewöhnlich scheitert. Zeichnen Sie die Richtung der Verbindung auf, bevor Sie etwas ändern.

Zeichnen Sie zuerst die Richtung der Verbindung auf

Öffnen Sie die Statusseite des inneren Routers, notieren Sie seine WAN-Adresse und vergleichen Sie sie mit der Adresse, die Ihnen ein öffentlicher Dienst meldet. Wenn beide abweichen, sitzt mindestens ein Übersetzer zwischen Ihrem Router und dem Internet. Wenn die WAN-Adresse in 100.64.0.0/10 fällt, gehört der äußere Übersetzer wahrscheinlich Ihrem Anbieter, und Sie kontrollieren ihn nicht. Diese beiden Tatsachen entscheiden, welcher der späteren Schritte überhaupt funktionieren kann.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

Doppeltes NAT ist nicht doppeltes VPN. Übersetzung schreibt Adressen und Ports um; sie fügt keinen zweiten verschlüsselten Tunnel hinzu und verschlüsselt nichts. Die beiden Ideen auseinanderzuhalten ist wichtig, weil die Lösungen völlig verschieden sind und eine davon ein Gespräch mit Ihrem Anbieter statt einer Einstellungsseite erfordert.

Ausgehend: Der Client fragt, die Übersetzer bilden ab

Ein ausgehender Tunnel beginnt mit einem Paket von Ihrem Rechner, sodass jeder Übersetzer eine Abbildung anlegen und die Antwort wieder hereinlassen kann. Das Protokoll, der Port und die Leerlauf-Timer entscheiden, ob diese Abbildung lange genug überlebt, um nützlich zu sein. Die meisten Consumer-Router erledigen das ganz ohne Konfiguration.

Die Fehler, die tatsächlich auftreten, betreffen meist Zeitüberschreitungen und Protokollunterstützung statt die Anzahl der Router. Ein Tunnel, der nach ein paar Minuten Stille abfällt, ist eine ablaufende Abbildung, und ein Keepalive ist die übliche Antwort. IPsec hat standardisierte NAT-Traversal-Erweiterungen, die Behauptung, es könne keine Übersetzung überqueren, ist schlicht falsch. Wenn der Tunnel gar nicht zustande kommt, schauen Sie auf den Endpunkt und die Zugangsdaten, bevor Sie die Topologie beschuldigen.

wg show
ping -c3 10.8.0.1

Hören Sie auf, wenn der ausgehende Tunnel aus einem Netz funktioniert und aus einem anderen nicht. Dieser Vergleich betrifft die Netze, nicht die Zahl der Router.

Eingehend: Weiterleitung deckt nur Geräte ab, die Ihnen gehören

Einen Server zu betreiben ist die Gegenrichtung: Eine neue Verbindung kommt aus dem Internet und muss Ihren Rechner durch jede Ebene erreichen. Eine Portweiterleitungsregel am inneren Router hilft nur, wenn der äußere Übersetzer diesen Datenverkehr ebenfalls zu Ihnen bringt. Die lokale Regel zu wiederholen verschafft keine Kontrolle über die Geräte des Anbieters.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Vergleichen Sie die WAN-Adresse des inneren Routers mit der öffentlichen Adresse, die Sie beobachtet haben, und notieren Sie, woher jeder Wert stammt. Ist die WAN-Adresse privat oder im gemeinsam genutzten Bereich, führt die äußere Ebene eine Übersetzung aus, die Sie nicht konfigurieren können. Fragen Sie den Anbieter, welche eingehende Erreichbarkeit er unterstützt, bevor Sie einen Abend mit Regeln verbringen, die nicht wirksam werden können. Einen Router zu entfernen oder eine Firewall pauschal abzuschalten ist keine Diagnose und ein schlechter Tausch für einen offenen Port.

Hören Sie auf, wenn die äußere Ebene dem Anbieter gehört und nicht weiterleitet. Dann sind die unterstützten Antworten eine andere Zugangsmethode oder ein Relay, nicht noch eine Regel auf Ihrer Seite.

Testen Sie eine Variable nach der anderen

Ändern Sie pro Test eine Sache und notieren Sie das Ergebnis, denn ein Pfad mit doppeltem NAT hat mehr Variablen als einer mit einem Router. Halten Sie Profil und Gerät fest und vergleichen Sie dann ein anderes Zugangsnetz. Notieren Sie, ob die Aushandlung scheitert, ob die Sitzung nach Leerlauf abfällt oder ob nur private Ziele scheitern. Diese drei Beobachtungen deuten auf drei verschiedene Ebenen hin.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Überlappende private Subnetze sind eine separate Falle, die keine Menge an Übersetzung behebt. Wenn Ihr Heimnetz und das entfernte Netz denselben Bereich verwenden, entsteht ein Routenkonflikt, egal wie viele Übersetzer dazwischen sitzen. Eine Seite neu zu nummerieren ist die einzige dauerhafte Antwort.

Das entfernte Gateway verdient dieselbe Aufmerksamkeit, denn seine Weiterleitungsregeln und Rückwege können das fehlende Teil sein. Ein Tunnel, der sich authentifiziert, kann trotzdem keinen nutzbaren Anwendungspfad haben, und dieser Fehler sieht von der Clientseite identisch aus. Der Rundgang endet, wenn Sie sagen können, welche Richtung scheitert und welche Ebene dafür zuständig ist.