Pont local SoftEther ou SecureNAT : lequel activer

Ouvrez SoftEther Manager, et la première vraie décision concernant un hub n'est pas une case à cocher, c'est une question de topologie. Un pont local rattache ce hub à un adaptateur physique et laisse le segment existant fournir l'adressage, tandis que SecureNAT donne au hub son propre routeur virtuel, son NAT et son DHCP. Choisir entre les deux change l'origine des adresses et l'équipement qui répond pour elles. Activer les deux en espérant que l'un gagne, c'est ainsi qu'un laboratoire qui fonctionne devient un fil de support.

Partez du hub que vous modifiez réellement

Manager affiche une arborescence de serveurs et de hubs, et il est facile de configurer le hub par défaut alors que les clients se connectent à un autre, portant un nom différent. Cliquez sur le hub, lisez son nom et confirmez que les sessions listées en dessous sont bien les clients que vous cherchez à servir. Ce seul contrôle évite l'essentiel de la confusion qui sera ensuite imputée au protocole.

Décidez ensuite de ce dont le client a besoin depuis l'extrémité distante. Un comportement Ethernet partagé avec diffusion et services LAN oriente vers un pont, un accès privé routé vers une petite plage d'adresses oriente vers SecureNAT, et une sortie internet est une décision de routage que l'une comme l'autre disposition peut mal porter.

Écrivez la réponse avant de cliquer quoi que ce soit, car les deux réglages ne sont pas interchangeables et revenir en arrière prend plus de temps que décider. Deux minutes d'écriture économisent une heure de reconnexions.

Ce qu'un pont local fait à l'adressage

Un pont local relie le hub à un adaptateur physique, si bien que le hub fait partie de ce segment Ethernet. Les clients reçoivent des adresses de ce qui sert déjà le segment, et leur passerelle est le routeur du segment. Du point de vue du client, il a rejoint le LAN du bureau, avec toute l'accessibilité et toute l'exposition que cela implique.

Cela signifie aussi que le pont a besoin d'un vrai adaptateur avec la prise en charge de pilote adéquate et que l'administrateur doit être autorisé à étendre ce segment. Une connexion VPN prouve l'authentification, pas le droit de placer un hôte sur un VLAN de production. Vérifiez que le nom du pilote correspond à l'adaptateur visé, car ponter le mauvais port fait tomber un segment rapidement. Si la liste des adaptateurs est vide ou si le pont signale un échec, la réponse tient généralement au pilote ou aux privilèges plutôt qu'à la cryptographie.

Lisez la table des ponts en ligne de commande quand l'arborescence graphique est ambiguë. La sortie nomme l'adaptateur, ce que l'arborescence ne fait pas toujours.

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

Une liste de ponts vide avec des sessions connectées est une image utile : les clients sont à l'intérieur du hub virtuel et rien ne l'étend encore à un segment.

Ce que SecureNAT ajoute et ce qu'il masque

SecureNAT donne au hub un routeur virtuel, une fonction NAT et un service DHCP, le tout à l'intérieur du processus SoftEther. Les clients reçoivent des adresses de la plage DHCP virtuelle, le routeur virtuel répond pour la passerelle par défaut et le trafic qui doit sortir est traduit. Aucun adaptateur physique n'intervient, c'est pourquoi cela fonctionne sur un hôte à une seule carte réseau et sans configuration de commutateur.

Le prix à payer est que les adresses virtuelles appartiennent au hub et à rien d'autre. Une machine du LAN du bureau ne peut pas router vers l'adresse SecureNAT d'un client sans aide, et tout ce qui journalise les adresses source voit l'adresse traduite de l'hôte SoftEther. Si vos règles d'accès ou votre piste d'audit dépendent de l'adresse réelle du client, c'est un changement de conception et non un détail. Cela décide aussi si une règle d'adresse source verra un jour le client.

C'est aussi un serveur DHCP. L'exécuter sur un segment qui en possède déjà un, ou ponter ce segment en même temps, produit deux répondeurs et des baux imprévisibles. Le manuel traite les deux fonctions comme des choix distincts précisément pour cette raison.

Inspectez ce que le hub sert en ce moment avant d'activer quoi que ce soit d'autre. Chaque commande imprime l'état actuel et non l'état souhaité.

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

Activer l'un sans casser l'autre

Choisissez la disposition, activez-la et laissez l'autre désactivée. Un hub avec un pont et avec SecureNAT tous deux actifs est un hub à deux réponses possibles à la même question, et le client croira celle qui arrive en premier. Lorsque vous migrez de l'une à l'autre, désactivez l'ancienne fonction et reconnectez le client au lieu de supposer que le nouveau réglage s'applique à une session existante.

Ordonnez le changement pour que le pool de clients ne chevauche pas la plage du LAN. Les sous-réseaux qui se chevauchent sont la deuxième cause la plus fréquente d'un tunnel qui se connecte puis n'atteint plus rien, et ils sont invisibles tant que vous ne comparez pas les deux plans d'adressage côte à côte.

Reconnectez ensuite depuis le client et lisez ce qu'il a reçu, car la vision du hub sur la session n'est pas celle du client sur son propre réseau. Une reconnexion est le seul moyen fiable de forcer un nouveau bail.

Vérifiez la passerelle et le résolveur sur le client

Une authentification réussie vous dit que les identifiants fonctionnent et que le hub a accepté la session. Elle ne dit rien de la capacité du client à atteindre quoi que ce soit, car cela dépend de l'adresse, du masque, de la passerelle et du serveur DNS qui lui ont été fournis. Lisez ces quatre valeurs sur le client avant de toucher de nouveau à un réglage serveur.

Sous Windows, le détail de l'adaptateur affiche le bail et le résolveur, et la table de routage indique si le tunnel est réellement le chemin par défaut.

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

Sur un client Linux, les mêmes informations viennent des fichiers d'adresses, de routes et de résolveur. La route par défaut est la valeur qui décide si le trafic sort ou non par le tunnel. Si la passerelle pointe vers le routeur du bureau alors que le tunnel attend de porter le trafic, la topologie est pontée de nom et cassée en pratique. Corrigez d'abord la source des adresses, retestez l'application, et seulement ensuite envisagez de changer l'autre mode.