SoftEther hinter NAT: direkte Durchquerung oder VPN-Azure-Relay?

Ihr SoftEther-Server steht hinter einem Provider-Router, den Sie nicht ändern können, und Clients verbinden sich trotzdem, also nehmen Sie an, dass ein Relay alles trägt. Ob das stimmt, hängt davon ab, welcher Mechanismus die Arbeit erledigt hat: ein DNS-Name, ein koordinierter UDP-Pfad oder ein ausgehender Tunnel zu einem Relay. Alle drei können einen verbundenen Client erzeugen, und sie scheitern unter unterschiedlichen Bedingungen. Entscheiden Sie, welchen Weg Sie kaufen, bevor Sie Benutzer oder Hubs anfassen.

Drei Mechanismen, drei verschiedene Versprechen

Dynamisches DNS ist Benennung. Es hält einen Hostnamen auf eine wechselnde Adresse gerichtet, damit die Leute aufhören, der Nummer nachzujagen, und es tut nichts anderes. Native NAT-Traversal ist Koordination: zwei SoftEther-Endpunkte tauschen Informationen aus und versuchen, einen nutzbaren UDP-Pfad durch die Übersetzungsgeräte zwischen ihnen zu öffnen. VPN Azure ist ein Relay: Der Server wählt sich zum Dienst aus, und Clients treffen über einen Hostnamen in der Infrastruktur des Relays ein.

Die drei ergänzen sich, statt Versionen einer Funktion zu sein. Ein Deployment kann Benennung nutzen, während seine Verbindung tatsächlich vom Traversal oder vom Relay abhängt.

Entscheiden Sie anhand des Clients und des Netzwerks

Die Wahl beginnt beim Client, denn Traversal existiert nur im nativen SoftEther-Verbindungsmechanismus. OpenVPN, L2TP/IPsec und SSTP-Listener auf demselben Server erben es nicht, obwohl sie einen Host teilen. Schauen Sie, was der Benutzer ausführen wird, und dann, was das Netzwerk zulässt. Ein Unternehmensnetz, das nur TCP 443 erlaubt, drängt Sie zu einem Relay auf diesem Port, während ein Netz, das die für Traversal nötigen UDP-Ports durchlässt, einen direkten Pfad versuchen kann; prüfen Sie beides gegen die tatsächliche Egress-Richtlinie.

Ein manuell erreichbarer Listener ist weiterhin ein legitimes Design, wenn ein Administrator einen veröffentlichen kann, aber es ist ein separates Projekt mit eigener Adressierung und Firewall-Arbeit.

Prüfen Sie, welchen Transport die Sitzung gewählt hat

Der Verbindungsstatus ist die einzige ehrliche Quelle für den benutzten Pfad. Lesen Sie ihn auf dem Server, und lösen Sie den Hostnamen auf, den der Client erhalten hat.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList zeigt, welche Sitzungen verbunden sind, und SessionGet auf einer davon meldet den Verbindungstyp, einschließlich ob die Sitzung über das Relay kam. Ein Eintrag, der auf Relay-Infrastruktur auflöst, sagt Ihnen, dass die Sitzung über einen Dritten läuft, was Sie bestätigen können, indem Sie diese Route in einem Test blockieren. Bei einem nativen Client kann UDP-Beschleunigung den Datenpfad vom Kontrollpfad wegbewegen, sodass eine Beobachtung nicht die ganze Sitzung beschreibt. Ein veralteter dynamischer DNS-Name nach einem Adresswechsel und ein Relay, das antwortet, während die Backend-Route fehlt, sind zwei Fehlermodi, die es wert sind, getrennt getestet zu werden. Notieren Sie, was Sie gemessen haben, nicht was das Design beabsichtigte.

Planen Sie, wovon der gewählte Pfad abhängt

Jeder Pfad trägt eine Abhängigkeit. Ein direktes Traversal kann sich nach einem Netzwerkwechsel oder einem neuen Übersetzungsgerät ändern, während eine Relay-Sitzung ausfällt, wenn der Dienst oder sein erreichbarer Port ausfällt. Verbinden Sie sich aus einem anderen Netz erneut und bestätigen Sie die Serveridentität, die der Client geprüft hat, und behalten Sie den zuvor funktionierenden Pfad im selben Test. Testen Sie dann die private Ressource hinter dem VPN, denn Autorisierung, Hub-Mitgliedschaft, Adresszuweisung und Rückwege bleiben in jedem Fall Ihre Verantwortung.

Notieren Sie Hostname, Protokoll, Funktionseinstellungen und den beobachteten Transport. Genau diese vierteilige Aufzeichnung ermöglicht es der nächsten Person, eine funktionierende Verbindung zu reproduzieren.