SoftEther VPN Azure : un chemin relayé, pas un port ouvert

Votre serveur se trouve derrière un routeur que vous ne pouvez pas configurer, aussi le plan évident de rediriger un port n’est pas disponible. VPN Azure existe précisément pour cette situation, et il la résout en inversant le sens de la première connexion : le serveur se connecte vers un relais, et les clients atteignent le relais au lieu du serveur. Comprendre cette inversion explique à la fois ce que le service corrige et chaque limite que vous rencontrerez ensuite.

Ce qui change dans le chemin

Avec un écouteur classique, un client ouvre une connexion TCP vers une adresse publique que votre routeur transmet au serveur. Avec le relais, le serveur maintient une connexion sortante vers l’infrastructure du relais, et le relais accepte les connexions des clients et transmet leur charge utile au serveur en attente. Aucun port entrant n’est ouvert, aucune adresse statique n’est requise, et le routeur reste intact. Du point de vue du pare-feu, le serveur est un client sortant ordinaire, et c’est pourquoi les réseaux restrictifs l’autorisent.

Le relais attribue à ce serveur un nom sur son propre domaine, et les clients sont configurés pour s’y connecter.

Ce nom appartient au service de relais, qui n’est pas une Microsoft Azure VPN Gateway même si les deux portent un nom en Azure. Les traiter comme interchangeables produit une configuration qui ne peut pas fonctionner.

Quels protocoles survivent au relais

Le relais transporte le protocole SoftEther, et le projet documente SSTP comme option client, ce qui est utile car Windows fournit un client SSTP. Il ne devient pas pour autant un transport générique pour chaque écouteur de l’hôte : un écouteur OpenVPN, un répondeur IPsec et un service L2TP ont chacun besoin de leur propre point de terminaison joignable, et aucun d’eux n’est transporté par le relais simplement parce que le serveur SoftEther est connecté.

Les profils clients pointent donc vers le nom du relais plutôt que vers l’adresse du serveur, et un profil existant conçu pour une connexion directe ne fonctionnera pas tel quel. Consultez la liste des clients pris en charge pour la version que vous exploitez avant de concevoir autour d’un protocole que le relais ne transporte pas.

Ce que le relais ne fait pas pour vous

Le relais est un transport. Il ne crée ni utilisateurs, ni concentrateurs virtuels, ni politiques d’accès, ni routes, et il ne sait rien des réseaux privés derrière votre serveur. Si des clients distants doivent atteindre un sous-réseau LAN, le serveur a toujours besoin de la configuration de pont ou de routage, du chemin de retour et de la politique de pare-feu qui la rendent possible. Les plans d’adressage qui se chevauchent aux deux extrémités sont eux aussi invisibles pour le relais et restent votre problème à résoudre.

Les paramètres de sécurité pris en charge sont également à choisir par vous. La documentation du projet contient des exemples de plates-formes plus anciennes, et copier des paramètres de chiffrement ou de certificat hérités d’une ancienne capture d’écran est un bon moyen de construire un tunnel que personne ne peut auditer. Utilisez les recommandations actuelles pour la version que vous exploitez.

La validation des certificats et l’authentification des utilisateurs restent de la responsabilité du serveur, et le relais ne remplace jamais l’une ou l’autre.

Exploitez-le comme une dépendance

La disponibilité comprend désormais un tiers. Quand le relais est injoignable, les clients ne peuvent pas se connecter quelle que soit la santé de votre serveur, et la panne ressemble de l’extérieur à un problème de client. Surveillez le chemin du relais séparément de la santé du serveur, et gardez un plan de repli documenté, comme un écouteur direct sur une autre adresse, pour le jour où cela comptera.

La latence suit la géographie du relais plutôt que la proximité de vos utilisateurs, ce qui mérite d’être mesuré avant de promettre des performances interactives par son intermédiaire.

Vérifiez l’identité du serveur puis un véritable chemin applicatif, pas seulement une bannière de connexion réussie, et contrôlez si la ressource dont vous avez besoin est joignable sur la famille d’adresses que le relais transporte. Notez le nom du relais, le protocole utilisé et le plan de repli, car ces trois faits répondent à la plupart des questions futures sur ce lien.