VPN hinter NAT, das Sie nicht konfigurieren können: Was trotzdem funktioniert
Ohne Portweiterleitung hat ein eingehendes Paket kein Ziel. Hole Punching, UPnP und Relays ändern das, aber nur bei bestimmtem NAT-Verhalten.
Jeder Tunnelendpunkt braucht eine Adresse und einen Port, die die Gegenseite erreichen kann, und ein Router, den Sie nicht administrieren, ist der übliche Grund, warum diese Anforderung scheitert. Interessant ist nicht, dass es Tricks gibt, sondern dass jeder von einer Eigenschaft einer Mapping-Tabelle abhängt, die Sie vom Client aus nicht sehen. Zwei dieser Eigenschaften entscheiden fast alles: wie ein Mapping entsteht und ob es Pakete von einer Adresse annimmt, die die Innenseite nie kontaktiert hat. Sortieren Sie die Umgebung nach diesen Eigenschaften, und die Workarounds sind kein Folklore mehr.
Die Mapping-Tabelle entscheidet alles
Network Address Translation führt eine Tabelle, in der eine interne Adresse und ein Port gegen eine öffentliche Adresse und einen Port eingetragen sind. Antworten, die zu einem Eintrag passen, werden zurückübersetzt, und ein von außen eintreffendes Paket ohne passenden Eintrag hat überhaupt kein Ziel. Dieses eine Verhalten erklärt, warum ein Listener hinter dem Router aus dem Internet nicht erreichbar ist. Es erklärt auch, warum das erste Paket in jeder Richtung von innen stammen muss.
Betrachten Sie die Tabelle aus Sicht des Routers, und die Workarounds werden offensichtlich: Entweder legt etwas einen dauerhaften Eintrag an, oder es legt einen vorübergehenden an und hält ihn frisch, oder der Verkehr nimmt diesen Weg gar nicht. Der Rest dieses Artikels sind diese drei Fälle der Reihe nach. Nichts hier hängt von einer Herstellerfunktion ab, die über das hinausgeht, was die Tabelle aufzeichnet.
Was der Rendezvous-Dienst kann und was nicht
UDP-Hole-Punching nutzt den ausgehenden Eintrag als vorübergehende Öffnung, statt den Filter zu überwinden. Beide Peers kontaktieren einen Rendezvous-Dienst, der jeden öffentlichen Endpunkt erfährt und der anderen Seite deren Endpunkt zurückmeldet. Dann senden beide aufeinander zu, und jedes ausgehende Paket legt den Eintrag an oder frischt ihn auf, der die Antwort hereinlässt. Die Reihenfolge ist es, die es funktionieren lässt, und die Reihenfolge ist auch das, was es zerbrechlich macht: Ein Peer, der sendet, bevor die Gegenseite ihren Eintrag angelegt hat, wird einfach verworfen, während ein erneuter Versuch einen Moment später gelingt. Der Dienst selbst trägt keinen VPN-Verkehr, sein einziger Hebel ist also das Timing, das er koordiniert.
Das Mapping-Verhalten entscheidet den Rest, und RFC 4787 nennt die drei Formen: endpunktunabhängig, adressabhängig und adress- und portabhängig. Bei der letzten ändert sich der Port, den ein Peer anvisieren muss, mit jedem Ziel, sodass Vorhersage nicht mehr verlässlich ist. Dort stößt die Technik an ihre Grenzen, denn Carrier-Grade-NAT und eine strikte Unternehmensfirewall entfernen beide die Vorhersagbarkeit, die das Verfahren braucht, und noch so viele Wiederholungen bringen sie nicht zurück.
Keepalives, Neustarts und der Endpunkt, der sich bewegt
Ein durchgestoßener Pfad ist ein Fluss und kein Listener, also muss alles, was darauf läuft, Veränderungen überstehen. Es muss das Mapping mit periodischem Verkehr am Leben halten, bemerken, wenn sich der öffentliche Endpunkt verschiebt, und sich nach einem Routerneustart oder einer neuen Adresszuweisung neu aufbauen. Mesh-VPN-Produkte legen diese Logik in ihre eigene Steuerungsebene, während ein einfacher Server sie Ihnen überlässt. Keepalives helfen nur, solange dasselbe Mapping überlebt, und sie kosten Akku auf einem mobilen Client, weshalb ein aggressives Intervall nicht kostenlos ist.
Ein Laptop, der eine Stunde schläft, kommt meist auf einem anderen öffentlichen Endpunkt zurück. Alles, was den Pfad wiederherstellt, muss erneut von innen laufen, was dieselbe Anforderung zurück an den Client gibt.
Drei Wege um eine fehlende Weiterleitung herum
Der erste Weg bittet den Router, den Eintrag selbst anzulegen, über UPnP IGD, NAT-PMP oder PCP, wenn die Funktion vorhanden und eingeschaltet ist. Der zweite übergibt den Verkehr einem Relay mit öffentlicher Adresse, was immer funktioniert und immer Bandbreite plus eine andere Vertrauensgrenze kostet. Der dritte kehrt die Richtung um: Der interne Host öffnet einen ausgehenden Tunnel zu einem öffentlichen Server, und alles andere reist darin mit.
[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24
Ein Relay-Endpunkt macht diesen Handel in der Clientkonfiguration sichtbar, wo der Endpunkt ein Relay ist und nicht die eigene Adresse eines Peers. Persistentes Keepalive hält das Mapping warm, und die erlaubten Präfixe entscheiden, was der Client darüber senden darf. Ein Reverse-Tunnel vom internen Host ist dieselbe Idee mit einem anderen Eigentümer und braucht überhaupt keine NAT-Änderung. Jeder der drei beseitigt die Anforderung an eingehenden Verkehr, ohne eine Firewall zu überwinden, die unaufgeforderten Verkehr konstruktionsbedingt blockiert, weil der Verkehr trotzdem innen beginnt.
Passen Sie den Workaround dem an, der den Router besitzt
Wenn Sie den Router administrieren, ist eine statische UDP-Weiterleitung leichter zu prüfen als jedes Punching-Verfahren und scheitert auf Arten, die Sie sehen. Wenn nicht, finden Sie heraus, ob der Hersteller ein Relay oder eine gehostete Steuerungsebene anbietet und ob die Richtlinie deren Nutzung erlauben würde. Ist keines verfügbar, bleiben ein Reverse-Tunnel oder die Einsicht, dass der Endpunkt von außen nicht erreichbar ist. Festzuhalten, welchen Weg Sie genutzt haben, ist wichtiger, als es klingt, denn die Optionen unterscheiden sich darin, wer den Verkehr beobachten kann und was geschieht, wenn ein Dritter etwas ändert.
Notieren Sie, ob der Pfad, bei dem Sie gelandet sind, direkt oder über ein Relay verlief, denn diese eine Tatsache sagt sowohl Latenz als auch Fehlerverhalten voraus. RFC 4787 bleibt die Referenz für das Mapping-Verhalten darunter, und seinen Mapping-Abschnitt zu lesen ist schneller, als drei Workarounds nacheinander zu testen. Die Tabelle kümmert nicht, welche Option Sie gewählt haben; sie hält nur fest, was das nächste Paket tun darf.