Ce qu’un hub virtuel SoftEther connecte réellement

Le hub virtuel de SoftEther est une frontière d’appartenance à l’intérieur d’un serveur, pas un emplacement. Les sessions qui rejoignent le hub peuvent atteindre ce à quoi le hub est attaché, et les sessions d’un autre hub ne le peuvent pas, même lorsque les deux s’authentifient auprès du même serveur. C’est pourquoi une connexion réussie peut encore placer un client sur le mauvais réseau. Lire le hub comme un commutateur virtuel clarifie ce qu’il fait et ce qu’il laisse au pontage, au routage et à la configuration en cascade.

Un hub est une frontière d’appartenance

Un serveur peut héberger plusieurs hubs, chacun avec ses propres utilisateurs, sessions et politique. L’authentification établit qui est la session, tandis que le hub décide à quel réseau virtuel cette session se joint. Deux hubs sur un même hôte se comportent donc comme deux commutateurs distincts qui partagent par hasard le même matériel. Rien dans une connexion réussie n’implique que la session a atterri là où vous le vouliez.

Utilisez le nom de hub documenté par l’exploitant plutôt qu’un nom mémorisé depuis une capture d’écran. Un client qui rejoint le mauvais hub atteint un autre réseau avec un identifiant valide, ce qui est une constatation de configuration et non une violation de sécurité. Conservez le nom du hub et son objet dans les notes du profil de connexion.

L’administration est délimitée de la même manière. Un administrateur de hub gère ce hub, tandis que l’administrateur du serveur gère le processus, les écouteurs et chaque hub de l’hôte.

Les attachements décident de ce qui se trouve au-delà

Un hub à lui seul relie les sessions entre elles. Atteindre autre chose dépend de la façon dont le hub est attaché : un pont local vers une interface physique, un routeur virtuel ou une cascade vers un autre serveur. Chaque attachement porte ses propres règles de transfert et ses propres modes de défaillance. Supposer qu’un hub fournit un accès à internet est l’erreur la plus courante à propos du produit.

SecureNAT est l’option intégrée, mise en œuvre avec un routeur virtuel et un service DHCP virtuel à l’intérieur du serveur. Elle est pratique pour un laboratoire et peu commode pour tout ce qui exige un adressage ou une politique prévisibles. Un pont local place le hub sur un segment réel, qui hérite de la commutation, du DHCP et du comportement de diffusion de ce segment.

Une cascade relie deux serveurs afin que les sessions d’un hub puissent apparaître sur l’autre. C’est une relation de hub à hub, donc les deux extrémités ont besoin d’une politique compatible et d’un chemin fonctionnel entre elles.

Lisez les sessions et la politique séparément

Les vues des sessions, des adresses MAC et des adresses IP décrivent l’aspect actuel du réseau virtuel. Ce sont des observations, pas des autorisations. Une session visible dans la liste n’est pas pour autant autorisée à chaque service que le hub peut atteindre, et l’inverse vaut aussi.

Comparez la liste des sessions à la politique qui devrait s’y appliquer. Un appareil dont l’adresse sort de la plage prévue signifie généralement un DHCP venu d’ailleurs ou un client configuré à la main. Une adresse MAC qui se déplace entre les sessions signifie un appareil migré ou deux appareils partageant une identité. Les deux méritent un regard, et aucun n’est prouvé par le tableau seul.

Sur le serveur, vpncmd rapporte la même image du point de vue de l’hôte. Comparez cette sortie à la vue propre du client chaque fois que les deux diffèrent.

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

Traitez l’administration du hub comme un rôle à part plutôt que comme une permission de client. Déléguer un hub ne devrait pas céder les écouteurs ni le processus qui héberge tous les autres hubs.

Vérifiez le client après la jonction

Côté client, une session établie prouve seulement que l’authentification et le nom du hub ont été acceptés. Confirmez l’adresse, la route et la résolution de noms séparément, car chacune peut échouer après que le hub a accepté la session.

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

La liste des adresses montre si l’adaptateur a reçu un bail de la source prévue. La requête de route montre quelle interface porterait une destination privée, et la requête au résolveur montre si le DNS a suivi la session. Un hub qui transfère des paquets alors que le DNS pointe encore vers le réseau local produit la classique connexion à moitié fonctionnelle.

Testez l’application plutôt que la liaison. Une page intranet qui se charge est une preuve plus forte qu’un adaptateur doté d’une adresse plausible.