NAT entscheidet, welche Quelladresse Ihr VPN-Server tatsächlich sieht

Sie stellen sich vor, dass der VPN-Server die Adresse Ihres Laptops aus dem Paket liest und in ein Protokoll schreibt. Was er liest, ist das, was der letzte NAT-Hop in den äußeren Header eingetragen hat, und auf einem als Hotspot genutzten Telefon ist das oft eine Adresse, die sich Hunderte andere Teilnehmer teilen. Die eigene Adresse Ihres Rechners 192.168.x.x überquert in diesem Header nie das Internet, und die Tunneladresse vergibt der Server erst, nachdem die Verbindung bereits steht. Wenn ein Serverprotokoll und ip addr auf dem Laptop also nicht übereinstimmen, ist keines von beiden falsch; sie beschreiben verschiedene Schichten einer Sitzung.

Drei Adressen, und nur eine steht im Protokoll

Die Verwirrung entsteht daraus, dass drei Adressen zu einer verschmolzen werden. Jede hat einen anderen Eigentümer, lebt in einem anderen Header und erreicht den Server auf einem anderen Weg.

Nur die mittlere Zeile ist zum Verbindungszeitpunkt unbekannt. Der Server schreibt sie je nach Daemon in seine Peer-Tabelle, Statusdatei oder Flow-Log: WireGuard nennt sie den Endpunkt, eine OpenVPN-Statusdatei bezeichnet sie als Real Address, und strongSwan meldet sie als Remote-Host der IKE_SA. Dieser Wert wird bei jedem Paket von einer anderen Quelle erneuert, ändert sich also, ohne dass irgendjemand etwas neu startet.

Die untere Zeile ist das, was Menschen fälschlich als Identitätsaussage lesen. Sie markiert einen Platz in der Serverkonfiguration, keine Person, denn der Server hat sie aus seinem eigenen Pool gewählt. Zwei Nutzer können an verschiedenen Tagen dieselbe Tunneladresse erhalten, und einer kann zwei davon von zwei Geräten halten.

Warum sich das protokollierte Tupel ändert, während der Tunnel steht

Adressübersetzung ist eine Tabelle mit Timer, keine dauerhafte Bindung. Ein Heimrouter hält sein UDP-Mapping noch eine Weile nach dem letzten Paket, ein Carriergateway recycelt Ports nach eigenem Zeitplan, und ein Telefon, das von Wi-Fi auf LTE wechselt, kommt mit einer völlig anderen Quelle zurück. Die Linux-conntrack-Standardwerte sind hier ein nützlicher Maßstab: nf_conntrack_udp_timeout beträgt 30 Sekunden und die Streaming-Variante 120, sodass ein ruhiger Tunnel sein Mapping verlieren kann, lange bevor der Nutzer es bemerkt.

Der Tunnel überlebt, weil das Protokoll den Peer authentifiziert, nicht die Adresse. WireGuard ist nach dem Handshake zustandslos, sodass jedes authentifizierte Paket den gespeicherten Endpunkt aktualisiert und eine Neubindung beim nächsten Paket heilt; dafür gibt es persistent-keepalive = 25, um das Mapping bei Leerlauf warm zu halten. Das --float von OpenVPN erledigt dasselbe und lässt einen authentifizierten Client von einer neuen Adresse und einem neuen Port fortsetzen. Bei 2.4- und 2.5-Builds, in denen float standardmäßig aus ist, setzt eine Neubindung die Sitzung zurück, und der Client verbindet sich neu.

IPsec erreicht das mit mehr beweglichen Teilen. IKEv2 erkennt die Übersetzung, indem es die Quell- und Ziel-Hashes in den NAT-Erkennungs-Payloads vergleicht, wechselt zur UDP-4500-Kapselung und folgt Keepalives zum neuen Tupel. Wenn Keepalives blockiert werden, bleibt die SA auf dem Papier bestehen, während der Verkehr in eine Richtung still zum Erliegen kommt.

Was der Server zuordnen kann und was nicht

Der Mythos, den es zu töten gilt, ist, dass Übersetzung Sie vor dem Betreiber verbirgt. Sie ändert das Etikett, nicht die Beobachtung. Ein Gateway hinter Carrier-NAT sieht 100.64.0.0/10-Raum oder eine öffentliche Adresse, die sich viele Teilnehmer teilen, und kann den Fluss dennoch an ein Zertifikatssubjekt, einen öffentlichen WireGuard-Schlüssel, eine zugewiesene Tunneladresse, Byte-Zähler und ein Zeitfenster binden. Nichts davon braucht Ihre LAN-Adresse.

Die Grenzen laufen auch in die andere Richtung. Eine geteilte Adresse in einem Protokoll zeigt auf ein Gateway, nicht auf einen Haushalt; zwei Sitzungen von derselben übersetzten Adresse auf verschiedenen Ports sind verschiedene Geräte; dieselbe Adresse an zwei verschiedenen Tagen können zwei unabhängige Teilnehmer sein, wenn der Port recycelt wurde. Ein Server, der nur Peer-Schlüssel aufzeichnet, kann ohne die Kontodatenbank keinen einem Kunden zuordnen, und ein Server, der nur Adressen aufzeichnet, kann einen Laptop nicht von einem Telefon hinter demselben Router unterscheiden.

Vergleichen Sie beide Enden, statt zu raten

Um zu klären, was passiert ist, zeichnen Sie dieselbe Verbindung an beiden Enden im selben Moment auf und vergleichen Sie das Tupel, nicht die Adresse. Auf dem Client, vor jeder Übersetzung:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Lesen Sie dann den Übersetzungseintrag auf dem Router oder dem CGNAT-Gateway und das, was schließlich am Server ankommt:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Drei Muster erklären die meisten Abweichungen. Der Quellport am Server unterscheidet sich vom lokalen Port, während das Ziel übereinstimmt: gewöhnliche Portübersetzung. Die Quelladresse am Server gehört zu einem ISP-Block, der nicht Ihrer ist: mindestens eine zusätzliche NAT-Schicht. Pakete stoppen nach einer Leerlaufzeit und werden mit einem neuen Port fortgesetzt: Das Mapping ist abgelaufen, kein Routingfehler. Wenn die Zeitstempel mehr als ein oder zwei Sekunden auseinanderliegen, vergleichen Sie zwei verschiedene Versuche.

Wo der Unterschied Dinge kaputt macht

Ausfälle, die wie Serverfehler aussehen, beginnen meist hier. Eine Zugriffsregel, die an Ihre Heimatadresse gebunden ist, scheitert, nachdem sich das ISP-Lease ändert. Eine fail2ban-Regel, die auf eine übersetzte Adresse passt, sperrt alle Teilnehmer hinter diesem Gateway auf einmal. Ein Site-to-Site-Peer mit fester Gegenstelle stellt die Schlüsselerneuerung ein, nachdem sich eine Mobilfunkverbindung ändert. Das Tunnelprotokoll war in Ordnung; die Annahme über das äußere Tupel war es nicht.

Dieselbe Verwirrung zeigt sich auf der Serverseite. Steht die VPN-Box selbst hinter NAT, brauchen Sie eine Portweiterleitung und einen funktionierenden Weiterleitungspfad; der strongSwan-Weiterleitungsleitfaden deckt diesen Fall für IPsec ab. Ein Server, der nur über eine private Adresse erreichbar ist, sieht das übersetzte Tupel seiner Clients nie, und das ist ein anderes Problem als übersetzte Clients.

Arbeiten Sie diese vier Prüfungen der Reihe nach ab und stoppen Sie bei der ersten, die fehlschlägt:

• Zeichnen Sie an beiden Enden gleichzeitig auf; bestätigen Sie, dass Quellport, Zielport und Zeitstempel übereinstimmen.
• Lesen Sie in der Peer-Liste des Servers die Adresse, die er aktuell hält, nicht die erwartete.
• Prüfen Sie die conntrack- oder NAT-Tabelle auf den Eintrag und seine Restlaufzeit.
• Bestätigen Sie, dass die Tunnelinterface-Adresse auf dem Client der vom Server zugewiesenen entspricht, nicht der LAN-Adresse.

Wenn beide Aufzeichnungen beim Tupel übereinstimmen und der Tunnel trotzdem scheitert, ist die Übersetzung nicht Ihr Problem; gehen Sie weiter zum Handshake und zur Routing-Tabelle innerhalb des Tunnels.