Wat een virtuele hub van SoftEther werkelijk verbindt

De virtuele hub van SoftEther is een lidmaatschapsgrens binnen één server, geen locatie. Sessies die zich bij de hub aansluiten, bereiken wat de hub is aangesloten, en sessies op een andere hub niet, zelfs wanneer beide zich bij dezelfde server authenticeren. Daarom kan een geslaagde aanmelding een client alsnog op het verkeerde netwerk plaatsen. De hub als een virtuele switch lezen, maakt duidelijk wat hij doet en wat hij aan bridging, routing en cascadesconfiguratie overlaat.

Een hub is een lidmaatschapsgrens

Eén server kan meerdere hubs hosten, elk met eigen gebruikers, sessies en beleid. De authenticatie stelt vast wie de sessie is, terwijl de hub beslist bij welk virtueel netwerk die sessie hoort. Twee hubs op één host gedragen zich dus als twee afzonderlijke switches die toevallig hardware delen. Niets aan een geslaagde aanmelding betekent dat de sessie is geland waar u het wilde.

Gebruik de door de operator gedocumenteerde hubnaam in plaats van een naam uit een schermafbeelding. Een client die zich bij de verkeerde hub aansluit, bereikt met geldige inloggegevens een ander netwerk, wat een configuratiebevinding is en geen beveiligingsincident. Bewaar de hubnaam en het doel ervan in de notities van het verbindingsprofiel.

Het beheer is op dezelfde manier afgebakend. Een hubbeheerder beheert die hub, terwijl de serverbeheerder het proces, de luisteraars en elke hub op de host beheert.

De aansluitingen bepalen wat erachter ligt

Een hub verbindt op zichzelf sessies met elkaar. Iets anders bereiken hangt af van hoe de hub is aangesloten: een lokale bridge naar een fysieke interface, een virtuele router of een cascade naar een andere server. Elke aansluiting draagt eigen doorstuurregels en eigen storingswijzen. Aannemen dat een hub internettoegang biedt, is de meest voorkomende fout over het product.

SecureNAT is de ingebouwde optie, geïmplementeerd met een virtuele router en een virtuele DHCP-dienst in de server. Het is handig voor een laboratorium en onhandig voor alles wat voorspelbare adressering of beleid nodig heeft. Een lokale bridge zet de hub op een echt segment, dat het schakelen, DHCP en broadcastgedrag van dat segment erft.

Een cascade verbindt twee servers zodat sessies op de ene hub op de andere kunnen verschijnen. Het is een hub-naar-hub-relatie, dus beide uiteinden hebben compatibel beleid en een werkend pad tussen hen nodig.

Lees sessies en beleid apart

De weergaven van sessies, MAC-adressen en IP-adressen beschrijven hoe het virtuele netwerk er nu uitziet. Het zijn waarnemingen, geen rechten. Een sessie die in de lijst zichtbaar is, is daarmee niet gerechtigd tot elke dienst die de hub kan bereiken, en het omgekeerde geldt ook.

Vergelijk de sessielijst met het beleid dat ervoor zou moeten gelden. Een apparaat met een adres buiten het bedoelde bereik betekent meestal DHCP van elders of een handmatig geconfigureerde client. Een MAC-adres dat tussen sessies verschuift, betekent een gemigreerd apparaat of twee apparaten die één identiteit delen. Beide zijn een blik waard, en geen van beide wordt door de tabel alleen bewezen.

Op de server meldt vpncmd hetzelfde beeld vanuit het oogpunt van de host. Vergelijk die uitvoer met de eigen weergave van de client wanneer de twee het oneens zijn.

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

Behandel hubbeheer als een eigen rol in plaats van als een clientrecht. Het delegeren van één hub zou de luisteraars of het proces dat elke andere hub host, niet moeten overdragen.

Controleer de client na het aansluiten

Aan de clientzijde bewijst een opgezette sessie alleen dat authenticatie en de hubnaam zijn geaccepteerd. Bevestig het adres, de route en de naamresolutie afzonderlijk, want elk daarvan kan mislukken nadat de hub de sessie heeft geaccepteerd.

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

De adressenlijst laat zien of de adapter een lease van de bedoelde bron heeft gekregen. De routevraag laat zien welke interface een privébestemming zou dragen, en de resolvervraag laat zien of DNS de sessie volgde. Een hub die pakketten doorstuurt terwijl DNS nog naar het lokale netwerk wijst, levert de klassieke half werkende verbinding.

Test de toepassing in plaats van de verbinding. Een intranetpagina die laadt, is sterker bewijs dan een adapter met een plausibel adres.