SoftEther Local Bridge oder SecureNAT: Was man einschaltet

Öffnen Sie den SoftEther Manager, und die erste echte Entscheidung zu einem Hub ist kein Kontrollkästchen, sondern eine Topologiefrage. Eine lokale Brücke bindet den Hub an einen physischen Adapter und lässt das bestehende Segment die Adressierung liefern, während SecureNAT dem Hub einen eigenen virtuellen Router, NAT und DHCP gibt. Die Wahl dazwischen ändert, woher die Adressen kommen und welches Gerät für sie antwortet. Beides einzuschalten und zu hoffen, dass eines gewinnt, ist der Weg, auf dem aus einem funktionierenden Labor ein Support-Thread wird.

Beginnen Sie bei dem Hub, den Sie wirklich bearbeiten

Der Manager zeigt einen Baum aus Servern und Hubs, und es ist leicht, den Standard-Hub zu konfigurieren, während sich Clients mit einem anders benannten verbinden. Klicken Sie den Hub an, lesen Sie seinen Namen und bestätigen Sie, dass die darunter gelisteten Sitzungen die Clients sind, die Sie bedienen wollen. Diese eine Prüfung verhindert den größten Teil der Verwirrung, die später dem Protokoll angelastet wird.

Danach entscheiden Sie, was der Client von der Gegenseite braucht. Gemeinsames Ethernet-Verhalten mit Broadcast und LAN-Diensten deutet auf eine Brücke, gerouteter privater Zugang zu einem kleinen Adressbereich auf SecureNAT, und ein Internetausgang ist eine Routingentscheidung, die beide Anordnungen schlecht tragen können.

Schreiben Sie die Antwort auf, bevor Sie irgendetwas anklicken, denn die beiden Einstellungen sind nicht austauschbar und das Rückgängigmachen dauert länger als die Entscheidung. Zwei Minuten Schreiben sparen eine Stunde Neuverbinden.

Was eine lokale Brücke mit der Adressierung macht

Eine lokale Brücke verbindet den Hub mit einem physischen Adapter, sodass der Hub Teil dieses Ethernet-Segments wird. Clients erhalten Adressen von dem, was das Segment bereits bedient, und ihr Gateway ist der Router des Segments. Aus Sicht des Clients ist er dem Büro-LAN beigetreten, mit aller Erreichbarkeit und aller Angriffsfläche, die das mit sich bringt.

Das bedeutet auch, dass die Brücke einen echten Adapter mit passender Treiberunterstützung braucht und dass der Administrator berechtigt sein muss, dieses Segment zu erweitern. Eine VPN-Anmeldung beweist Authentifizierung, nicht das Recht, einen Host in ein Produktions-VLAN zu stellen. Prüfen Sie, ob der Treibername zum beabsichtigten Adapter passt, denn das Brücken des falschen Ports legt ein Segment schnell lahm. Ist die Adapterliste leer oder meldet die Brücke einen Fehler, liegt die Ursache meist bei Treiber oder Berechtigungen und nicht bei der Kryptografie.

Lesen Sie die Brückentabelle auf der Kommandozeile, wenn der grafische Baum uneindeutig ist. Die Ausgabe nennt den Adapter, was der Baum nicht immer tut.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

Eine leere Brückenliste bei verbundenen Sitzungen ist ein nützliches Bild: Die Clients sind im virtuellen Hub, und noch dehnt nichts ihn auf ein Segment aus.

Was SecureNAT hinzufügt und was es verbirgt

SecureNAT gibt dem Hub einen virtuellen Router, eine NAT-Funktion und einen DHCP-Dienst, alles innerhalb des SoftEther-Prozesses. Clients bekommen Adressen aus dem virtuellen DHCP-Bereich, der virtuelle Router antwortet für das Standard-Gateway, und Verkehr, der hinaus muss, wird übersetzt. Kein physischer Adapter ist beteiligt, weshalb es auf einem Host mit einer einzigen Netzwerkkarte und ohne Switch-Konfiguration funktioniert.

Der Preis ist, dass die virtuellen Adressen dem Hub gehören und sonst nichts. Ein Rechner im Büro-LAN kann ohne Hilfe nicht zur SecureNAT-Adresse eines Clients routen, und alles, was Quelladressen protokolliert, sieht die übersetzte Adresse des SoftEther-Hosts. Hängt Ihre Zugriffsregel oder Ihr Audit-Trail an der echten Adresse des Clients, ist das eine Designänderung und kein Detail. Es entscheidet auch, ob eine Quelladressregel den Client überhaupt je sieht.

Er ist außerdem ein DHCP-Server. Ihn in einem Segment laufen zu lassen, das bereits einen hat, oder dieses Segment gleichzeitig zu brücken, erzeugt zwei Antwortgeber und unvorhersehbare Leases. Das Handbuch behandelt die beiden Funktionen genau deshalb als getrennte Entscheidungen.

Prüfen Sie, was der Hub gerade bedient, bevor Sie etwas anderes aktivieren. Jeder Befehl gibt den aktuellen Zustand aus, nicht den beabsichtigten.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Eines einschalten, ohne das andere zu brechen

Wählen Sie die Anordnung, aktivieren Sie sie und lassen Sie die andere aus. Ein Hub mit Brücke und mit SecureNAT gleichzeitig ist ein Hub mit zwei möglichen Antworten auf dieselbe Frage, und der Client glaubt der, die zuerst eintrifft. Wenn Sie von einem auf das andere umstellen, deaktivieren Sie die alte Funktion und verbinden den Client neu, statt anzunehmen, dass die neue Einstellung auf eine bestehende Sitzung wirkt.

Ordnen Sie die Änderung so, dass der Client-Pool den LAN-Bereich nicht überlappt. Überlappende Subnetze sind die zweithäufigste Ursache für einen Tunnel, der sich verbindet und dann nichts erreicht, und sie sind unsichtbar, bis Sie beide Adresspläne nebeneinander vergleichen.

Verbinden Sie dann vom Client neu und lesen Sie, was er erhalten hat, denn die Sicht des Hubs auf die Sitzung ist nicht die Sicht des Clients auf sein eigenes Netz. Ein Neuverbinden ist der einzige verlässliche Weg, eine frische Lease zu erzwingen.

Prüfen Sie Gateway und Resolver auf dem Client

Eine erfolgreiche Authentifizierung sagt Ihnen, dass die Anmeldedaten funktionieren und der Hub die Sitzung akzeptiert hat. Sie sagt nichts darüber, ob der Client irgendetwas erreicht, denn das hängt von Adresse, Maske, Gateway und DNS-Server ab, die er erhalten hat. Lesen Sie diese vier Werte auf dem Client, bevor Sie wieder eine Servereinstellung anfassen.

Unter Windows zeigen die Adapterdetails die Lease und den Resolver, und die Routentabelle zeigt, ob der Tunnel tatsächlich der Standardpfad ist.

ipconfig /all
route print -4
nslookup intranet.corp.internal

Auf einem Linux-Client stammen dieselben Angaben aus den Dateien für Adressen, Routen und Resolver. Die Standardroute ist der Wert, der entscheidet, ob Verkehr überhaupt durch den Tunnel geht. Zeigt das Gateway auf den Büro-Router, während der Tunnel den Verkehr tragen soll, ist die Topologie dem Namen nach gebrückt und in der Praxis gebrochen. Beheben Sie zuerst die Adressquelle, testen Sie dann die Anwendung erneut, und erwägen Sie erst danach, den anderen Modus zu ändern.