Einen Arbeitsplatzrechner hinter NAT ohne Portweiterleitung erreichen
Ein Arbeitsplatzrechner ohne eingehenden Port bleibt über einen Hub, ein Relay oder einen App-Broker erreichbar. Vergleichen Sie, was jedes Design garantiert, bevor Sie eines wählen.
Zwei Endpunkte hinter dem NAT des Providers und ein abgeriegelter Büro-Router lassen keinen eingehenden Port zum Weiterleiten übrig, und der Reflex ist, trotzdem einen anzufordern. Die bessere Frage ist, welche Seite hinauswählen darf und welcher erreichbare Dienst den Verkehr tragen darf. Vier Designs beantworten diese Frage unterschiedlich, und sie scheitern auf unterschiedliche Weise, wenn ein Pfad blockiert wird. Die Wahl zwischen ihnen ist ein Vergleich von Garantien, nicht von Protokollnamen.
Vier Designs, vier verschiedene Versprechen
Die folgende Tabelle ist die Kurzfassung. Lesen Sie die mittlere Spalte als das Versprechen, das Sie prüfen können, und die rechte Spalte als das Versprechen, das niemand gegeben hat.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
Welche Zeile gilt, hängt von der Aufgabe ab und nicht von der Vorliebe. Eine Sitzung für den entfernten Desktop, eine administrative Shell und Zugriff auf ein ganzes privates Subnetz sind drei Anforderungen, die nicht denselben Einstiegspunkt brauchen, auch wenn sie zufällig dieselbe Maschine betreffen.
Ein Hub ändert, wer hinauswählt, nicht was erlaubt ist
Bei einem gerouteten Hub-Design öffnen der entfernte Laptop und der Arbeitsplatzrechner, oder das Standort-Gateway davor, jeweils einen ausgehenden Tunnel zu einem Dienst, den beide erreichen können. Nichts nimmt am Router des Arbeitsplatzrechners eine unaufgeforderte Verbindung an, und genau deshalb übersteht dieses Design NAT und funktioniert auch dann, wenn der Standort keine statische Adresse hat. Der Hub routet den Verkehr dann nach seiner eigenen Richtlinie zwischen den beiden inneren Adressen.
Der Preis ist, dass der Hub existieren muss, von beiden Seiten erreichbar sein muss und von jemandem betrieben werden muss. Die Ausgangsfilterung muss den Transport erlauben, und ein Netz, das ihn blockiert, vereitelt das Design, obwohl keine Portweiterleitung nötig war.
Der feine Punkt ist, dass Erreichbarkeit und Autorisierung getrennte Entscheidungen sind, die an verschiedenen Stellen getroffen werden. Eine Route in ein Präfix sagt nichts darüber, welchen Dienst auf dem Arbeitsplatzrechner die Identität nutzen darf, und eine Firewall-Regel, die den Tunnel erlaubt, sagt nichts darüber, ob sich das Konto anmelden kann. Konfigurieren Sie beides, testen Sie beides, und lassen Sie die Autorisierungsentscheidung bei dem System, dem die Ressource gehört, statt bei der Routing-Tabelle.
Traversierung funktioniert nur, wenn beide Stacks sie umsetzen
Peer-Traversierung ist eine Fähigkeit eines bestimmten Systems, keine Einstellung, die ein VPN verbessert. Interactive Connectivity Establishment sammelt mehrere Kandidatenadressen und testet Paare, bis eines funktioniert: Host-Kandidaten auf lokalen Schnittstellen, server-reflexive Kandidaten aus dem, was ein NAT verrät, und relayte Kandidaten, die auf einem Relay zugeteilt werden. Eine private Adresse allein ist kein Pfad, weil die Gegenseite nicht dorthin routen kann.
Der relayte Fall ist es wert, verstanden zu werden, bevor man ihn verwirft. RFC 8656 beschreibt TURN als ein Protokoll, in dem ein Client einen Server um eine relayte Transportadresse bittet und der Server Verkehr zwischen diesem Client und seinen Peers weiterleitet. Das Relay trägt also die Daten, was sich deutlich von einem Verzeichnis unterscheidet, das nur Endpunkten beim Treffen hilft. Der Austausch der Relay-Adresse mit dem Peer ist ein Koordinationsschritt, den die Anwendung leisten muss.
Was Sie nicht versprechen können, ist ein direkter Pfad. Symmetrisches NAT und manche Unternehmensfirewalls vereiteln das Lochstanzen, und wenn sie es tun, fällt das System entweder auf ein Relay zurück oder scheitert. Sie können auch nicht schließen, dass zwei übersetzte Endpunkte niemals sprechen können; ein unterstützter Stack mit Relay-Rückfall existiert gerade deshalb, weil sie es oft können. Entscheiden Sie, ob Verfügbarkeit oder Direktheit wichtiger ist, und prüfen Sie dann, welchen Pfad die Bereitstellung tatsächlich gewählt hat, statt den günstigen Fall anzunehmen.
Ein Broker ist schmaler als ein Netz
Wenn die Anforderung eine einzige Anwendung ist, kann ein Anwendungsbroker oder eine vom Arbeitsplatzrechner gestartete Rückwärtsverbindung die kleinste Antwort sein. Der Arbeitsplatzrechner wählt nach außen zu einem Broker, der Broker authentifiziert den entfernten Benutzer, und nur diese Anwendungssitzung wird getragen. Es entsteht keine Route in das Subnetz des Arbeitsplatzrechners, sodass eine Kompromittierung der entfernten Sitzung keinen Pfad zu jedem Gerät daneben erbt.
Diese Schmalheit hat einen Preis: Jede zusätzliche Anwendung braucht ihre eigene Integration, und alles, was die Anwendung über ein lokales Netz annimmt, etwa eine Dateifreigabe, die sie auf einem nahen Server öffnet, ist womöglich nicht erreichbar. Broker bündeln außerdem Richtlinie und Protokollierung an einer Stelle, was nützlich ist, bis diese Stelle zum Ausfall wird.
Vergleichen Sie Vertrauensgrenzen, dann testen Sie den Pfad
Ein Hub, der Tunnel beendet, kann den Verkehr lesen, den er routet. Ein Relay kann einen eigenständig geschützten Austausch tragen, wenn die Anwendung Ende zu Ende verschlüsselt, und ein Broker beendet in der Regel die Sitzung, die er präsentiert. Stellen Sie fest, wo der Schutz tatsächlich endet, bevor Sie entscheiden, dass zwei Designs gleichwertig sind, weil beide verschlüsselt sind.
Prüfen Sie dann, was der Arbeitsplatzrechner ausgehend tatsächlich erreicht, denn jedes Design oben hängt davon ab. Führen Sie dies auf dem Arbeitsplatzrechner aus und ersetzen Sie den Hostnamen, den Sie verwenden wollen.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comAkzeptieren Sie das Design erst, wenn die beabsichtigte entfernte Operation unter der erlaubten Identität gelingt, eine nicht genehmigte Identität abgelehnt wird und das Verhalten bei nicht verfügbarem direktem oder relaytem Pfad bekannt und dokumentiert ist. Schließen Sie eine erneute Verbindung und den normalen Startkontext des Arbeitsplatzrechners ein, denn eine Sitzung, die im Büro über das LAN begann, testet nichts, worauf der Fernzugriff angewiesen ist.