Was ein virtueller Hub von SoftEther tatsächlich verbindet

SoftEthers virtueller Hub ist eine Mitgliedschaftsgrenze innerhalb eines Servers, kein Standort. Sitzungen, die dem Hub beitreten, erreichen das, woran der Hub angebunden ist, und Sitzungen an einem anderen Hub nicht, selbst wenn sich beide am selben Server authentifizieren. Deshalb kann eine erfolgreiche Anmeldung einen Client trotzdem ins falsche Netz bringen. Den Hub als virtuellen Switch zu lesen, macht klar, was er leistet und was er Bridging, Routing und Kaskadenkonfiguration überlässt.

Ein Hub ist eine Mitgliedschaftsgrenze

Ein Server kann mehrere Hubs hosten, jeder mit eigenen Benutzern, Sitzungen und Richtlinien. Die Authentifizierung legt fest, wer die Sitzung ist, während der Hub entscheidet, welchem virtuellen Netzwerk diese Sitzung beitritt. Zwei Hubs auf einem Host verhalten sich daher wie zwei getrennte Switches, die zufällig Hardware teilen. Nichts an einer erfolgreichen Anmeldung besagt, dass die Sitzung dort gelandet ist, wo Sie es wollten.

Verwenden Sie den vom Betreiber dokumentierten Hub-Namen statt eines Namens aus einem Screenshot. Ein Client, der dem falschen Hub beitritt, erreicht mit gültigen Zugangsdaten ein anderes Netz, was ein Konfigurationsbefund und kein Sicherheitsverstoß ist. Halten Sie Hub-Namen und Zweck in den Notizen des Verbindungsprofils fest.

Die Administration ist genauso abgegrenzt. Ein Hub-Administrator verwaltet diesen Hub, während der Server-Administrator den Prozess, die Listener und jeden Hub auf dem Host verwaltet.

Anbindungen entscheiden, was dahinter liegt

Ein Hub verbindet für sich genommen Sitzungen miteinander. Alles Weitere zu erreichen hängt davon ab, wie der Hub angebunden ist: eine lokale Bridge zu einer physischen Schnittstelle, ein virtueller Router oder eine Kaskade zu einem anderen Server. Jede Anbindung bringt eigene Weiterleitungsregeln und eigene Fehlermodi mit. Anzunehmen, ein Hub biete Internetzugang, ist der häufigste Irrtum über das Produkt.

SecureNAT ist die eingebaute Option, umgesetzt mit einem virtuellen Router und einem virtuellen DHCP-Dienst innerhalb des Servers. Sie ist für ein Labor praktisch und für alles unbequem, was vorhersagbare Adressierung oder Richtlinien braucht. Eine lokale Bridge setzt den Hub auf ein echtes Segment, das Switching, DHCP und Broadcast-Verhalten dieses Segments erbt.

Eine Kaskade verbindet zwei Server, sodass Sitzungen am einen Hub am anderen erscheinen können. Das ist eine Hub-zu-Hub-Beziehung, also brauchen beide Seiten eine kompatible Richtlinie und einen funktionierenden Pfad zwischen sich.

Sitzungen und Richtlinie getrennt lesen

Ansichten für Sitzungen, MAC-Adressen und IP-Adressen beschreiben, wie das virtuelle Netz gerade aussieht. Sie sind Beobachtungen, keine Berechtigungen. Eine in der Liste sichtbare Sitzung ist damit nicht zu jedem Dienst berechtigt, den der Hub erreicht, und umgekehrt gilt dasselbe.

Vergleichen Sie die Sitzungsliste mit der Richtlinie, die dafür gelten sollte. Ein Gerät mit einer Adresse außerhalb des vorgesehenen Bereichs bedeutet meist DHCP von woanders oder einen manuell konfigurierten Client. Eine MAC-Adresse, die zwischen Sitzungen wandert, bedeutet ein migriertes Gerät oder zwei Geräte, die eine Identität teilen. Beides ist einen Blick wert, und keines ist durch die Tabelle allein bewiesen.

Auf dem Server meldet vpncmd dasselbe Bild aus Sicht des Hosts. Vergleichen Sie diese Ausgabe mit der eigenen Sicht des Clients, wann immer die beiden nicht übereinstimmen.

vpncmd localhost /SERVER /CMD SessionList
vpncmd localhost /SERVER /CMD HubList

Behandeln Sie die Hub-Administration als eigene Rolle statt als Client-Berechtigung. Die Delegation eines Hubs sollte nicht die Listener oder den Prozess übergeben, der jeden anderen Hub hostet.

Prüfen Sie den Client nach dem Beitritt

Auf Clientseite beweist eine aufgebaute Sitzung nur, dass Authentifizierung und Hub-Name akzeptiert wurden. Bestätigen Sie Adresse, Route und Namensauflösung getrennt, denn jedes davon kann fehlschlagen, nachdem der Hub die Sitzung akzeptiert hat.

ip -brief address show
ip route get 10.20.30.41
resolvectl query host.internal

Die Adressliste zeigt, ob der Adapter eine Lease von der vorgesehenen Quelle erhalten hat. Die Routenabfrage zeigt, welche Schnittstelle ein privates Ziel tragen würde, und die Resolver-Abfrage zeigt, ob DNS der Sitzung gefolgt ist. Ein Hub, der Pakete weiterleitet, während DNS noch auf das lokale Netz zeigt, erzeugt die klassische halb funktionierende Verbindung.

Testen Sie die Anwendung statt der Verbindung. Eine Intranetseite, die lädt, ist stärkerer Beweis als ein Adapter mit plausibler Adresse.