SoftEther VPN Azure: ein Relay-Pfad, kein offener Port
VPN Azure ist ein Relay, zu dem der Server selbst hinauswählt, keine Portweiterleitung. Es hilft hinter NAT, überträgt nur bestimmte Protokolle und fügt eine zu überwachende Abhängigkeit hinzu.
Ihr Server steht hinter einem Router, den Sie nicht konfigurieren können, daher steht der naheliegende Plan, einen Port weiterzuleiten, nicht zur Verfügung. VPN Azure existiert genau für diese Situation, und es löst sie, indem es die Richtung der ersten Verbindung umkehrt: Der Server wählt sich zu einem Relay hinaus, und die Clients erreichen das Relay statt den Server. Wer diese Umkehrung versteht, begreift sowohl, was der Dienst behebt, als auch jede Grenze, auf die Sie später stoßen werden.
Was sich am Pfad ändert
Bei einem herkömmlichen Listener öffnet ein Client eine TCP-Verbindung zu einer öffentlichen Adresse, die Ihr Router an den Server weiterleitet. Beim Relay unterhält der Server eine ausgehende Verbindung zur Relay-Infrastruktur, und das Relay nimmt Client-Verbindungen an und reicht deren Nutzlast an den wartenden Server weiter. Es wird kein eingehender Port geöffnet, keine statische Adresse benötigt, und der Router bleibt unberührt. Aus Sicht der Firewall ist der Server ein gewöhnlicher ausgehender Client, weshalb restriktive Netze ihn zulassen.
Das Relay vergibt jenem Server einen Namen auf seiner eigenen Domain, und die Clients werden so konfiguriert, dass sie sich dorthin verbinden.
Dieser Name gehört zum Relay-Dienst, der kein Microsoft Azure VPN Gateway ist, auch wenn beide Azure irgendetwas heißen. Sie als austauschbar zu behandeln, erzeugt eine Konfiguration, die nicht funktionieren kann.
Welche Protokolle das Relay überstehen
Das Relay transportiert das SoftEther-Protokoll, und das Projekt dokumentiert SSTP als Client-Option, was nützlich ist, weil Windows einen SSTP-Client mitbringt. Es wird jedoch kein allgemeiner Träger für jeden Listener auf dem Host: Ein OpenVPN-Listener, ein IPsec-Responder und ein L2TP-Dienst brauchen jeweils ihren eigenen erreichbaren Endpunkt, und keiner von ihnen wird durch das Relay transportiert, nur weil der SoftEther-Server verbunden ist.
Client-Profile zeigen daher auf den Relay-Namen statt auf die Serveradresse, und ein bestehendes Profil für eine direkte Verbindung funktioniert nicht unverändert. Prüfen Sie die unterstützte Client-Liste für die von Ihnen betriebene Version, bevor Sie um ein Protokoll herum planen, das das Relay nicht trägt.
Was das Relay nicht für Sie erledigt
Das Relay ist ein Transport. Es legt keine Benutzer, virtuellen Hubs, Zugriffsrichtlinien oder Routen an und weiß nichts über die privaten Netze hinter Ihrem Server. Wenn entfernte Clients ein LAN-Subnetz erreichen müssen, braucht der Server weiterhin die Bridge- oder Routing-Konfiguration, den Rückweg und die Firewall-Richtlinie, die das ermöglichen. Überlappende Adresspläne an beiden Enden sind für das Relay ebenfalls unsichtbar und bleiben Ihr Problem.
Auch die unterstützten Sicherheitseinstellungen wählen Sie selbst. Die Projektdokumentation enthält ältere Plattformbeispiele, und veraltete Cipher- oder Zertifikatseinstellungen aus einem alten Screenshot zu kopieren ist ein guter Weg, einen Tunnel zu bauen, den niemand prüfen kann. Verwenden Sie die aktuelle Anleitung für die von Ihnen betriebene Version.
Zertifikatsprüfung und Benutzerauthentifizierung bleiben Aufgabe des Servers, und das Relay ersetzt niemals eines von beiden.
Betreiben Sie es als Abhängigkeit
Die Verfügbarkeit umfasst jetzt einen Dritten. Wenn das Relay nicht erreichbar ist, können Clients sich unabhängig vom Zustand Ihres Servers nicht verbinden, und der Fehler sieht von außen wie ein Client-Problem aus. Überwachen Sie den Relay-Pfad getrennt von der Gesundheit des Servers und halten Sie einen dokumentierten Rückfallweg wie einen direkten Listener auf einer anderen Adresse für den Tag bereit, an dem es darauf ankommt.
Die Latenz folgt der Geografie des Relays statt der Nähe Ihrer Nutzer, was es wert ist, gemessen zu werden, bevor Sie interaktive Leistung darüber versprechen.
Prüfen Sie die Server-Identität und dann einen echten Anwendungspfad, nicht nur ein erfolgreiches Verbindungsbanner, und prüfen Sie, ob die benötigte Ressource über die Adressfamilie erreichbar ist, die das Relay trägt. Notieren Sie Relay-Namen, verwendetes Protokoll und den Rückfallweg, denn diese drei Fakten beantworten die meisten künftigen Fragen zu dieser Verbindung.