SoftEther derrière NAT : traversée directe ou relais VPN Azure ?

Votre serveur SoftEther se trouve derrière un routeur du fournisseur que vous ne pouvez pas modifier, et les clients se connectent quand même, vous supposez donc qu’un relais porte tout. Que ce soit vrai dépend du mécanisme qui a fait le travail : un nom DNS, un chemin UDP coordonné ou un tunnel sortant vers un relais. Les trois peuvent produire un client connecté, et ils échouent dans des conditions différentes. Décidez quel chemin vous achetez avant de toucher aux utilisateurs ou aux hubs.

Trois mécanismes, trois promesses différentes

Le DNS dynamique est du nommage. Il maintient un nom d’hôte pointé vers une adresse changeante pour que les gens arrêtent de courir après le numéro, et il ne fait rien d’autre. La traversée NAT native est de la coordination : deux extrémités SoftEther échangent des informations et tentent d’ouvrir un chemin UDP utilisable à travers les dispositifs de traduction entre elles. VPN Azure est un relais : le serveur se connecte vers le service, et les clients arrivent via un nom d’hôte sur l’infrastructure du relais.

Les trois sont complémentaires plutôt que des versions d’une même fonction. Un déploiement peut utiliser le nommage alors que sa connexion dépend en réalité de la traversée ou du relais.

Décidez à partir du client et du réseau

Le choix commence par le client, car la traversée n’existe que dans le mécanisme de connexion natif de SoftEther. OpenVPN, L2TP/IPsec et les écouteurs SSTP du même serveur n’en héritent pas, même s’ils partagent un hôte. Regardez ce que l’utilisateur exécutera, puis ce que le réseau permet. Un réseau d’entreprise qui n’autorise que TCP 443 vous pousse vers un relais sur ce port, tandis qu’un réseau qui laisse passer les ports UDP nécessaires à la traversée peut tenter un chemin direct ; confirmez les deux face à la politique de sortie réelle.

Un écouteur joignable manuellement reste une conception légitime quand un administrateur peut en publier un, mais c’est un projet distinct avec son propre adressage et son travail de pare-feu.

Confirmez quel transport la session a choisi

L’état de la connexion est la seule source honnête du chemin utilisé. Lisez-le sur le serveur et résolvez le nom d’hôte donné au client.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList montre quelles sessions sont connectées, et SessionGet sur l’une d’elles indique le type de connexion, y compris si la session est arrivée par le relais. Un enregistrement qui résout vers l’infrastructure du relais vous dit que la session passe par un tiers, ce que vous pouvez confirmer en bloquant cette route lors d’un test. Avec un client natif, l’accélération UDP peut éloigner le chemin de données du chemin de contrôle, donc une observation ne décrit pas toute la session. Un nom DNS dynamique périmé après un changement d’adresse, et un relais qui répond alors que la route vers le backend manque, sont deux modes de défaillance qui méritent d’être testés séparément. Notez ce que vous avez mesuré, pas ce que la conception prévoyait.

Planifiez ce dont dépend le chemin choisi

Chaque chemin porte une dépendance. Une traversée directe peut changer après une transition réseau ou un nouveau dispositif de traduction, tandis qu’une session de relais échoue quand le service ou son port joignable échoue. Reconnectez-vous depuis un autre réseau et confirmez l’identité du serveur vérifiée par le client, en gardant le chemin qui fonctionnait auparavant dans le même test. Testez ensuite la ressource privée derrière le VPN, car l’autorisation, l’appartenance au hub, l’attribution d’adresses et les routes de retour restent votre responsabilité dans tous les cas.

Notez le nom d’hôte, le protocole, les réglages de la fonction et le transport observé. C’est cet enregistrement en quatre parties qui permet à la personne suivante de reproduire une connexion qui fonctionne.