Un port dans le champ d’adresse du VPN Windows ne fonctionne qu’avec SSTP

Un serveur VPN répond sur TCP 10443, le client intégré de Windows dispose des bons identifiants, et la connexion échoue quand même après une pause qui ressemble à un délai d’expiration DNS. La cause est généralement le champ d’adresse : taper vpn.example.com:10443 dans Nom du serveur ou adresse fait lire à Windows toute la chaîne comme un nom d’hôte, car cette case n’est pas une saisie host:port générale. Qu’un port puisse y être exprimé du tout dépend du type de tunnel utilisé par le profil, et seul un des quatre types traite la valeur comme quelque chose qu’il peut analyser.

Pourquoi le champ d’adresse n’est pas une case host:port

La propriété de profil derrière ce champ est ServerAddress, et chaque type de tunnel décide de ce qu’il fait de la chaîne. Trois d’entre eux n’ont aucun paramètre de port à remplir, donc deux-points et un nombre ne sont que des caractères dans un nom qui ne sera jamais résolu. Le quatrième passe par HTTPS, où un port fait partie de l’URL, donc la valeur doit être écrite sous une forme qui s’analyse comme telle.

C’est pourquoi l’échec ressemble à une résolution de nom plutôt qu’à une connexion refusée. Il n’y a pas de mauvais port à signaler, seulement un nom d’hôte qui n’existe pas, et l’erreur arrive après que le résolveur a abandonné. Avant de toucher au serveur, vérifiez quel type de tunnel le profil prétend utiliser.

Les trois types à port fixe

PPTP se connecte à TCP 1723 puis transporte le tunnel en GRE, protocole IP 47. L2TP/IPsec utilise UDP 1701 pour le tunnel et UDP 500 plus 4500 pour IPsec, 4500 étant le port de traversée NAT. IKEv2 utilise aussi UDP 500 et 4500. Aucun de ces profils n’expose de champ de port nulle part dans l’interface, et aucun ne négociera un port non standard.

Un serveur à l’écoute sur un port personnalisé est donc inaccessible à ces profils, quelle que soit la façon dont l’adresse est écrite. Les réponses pratiques sont étroites : publier le port standard sur le serveur, ou traduire le port standard vers le personnalisé sur le routeur qui le précède. Les deux laissent le profil client intact, ce qui vaut beaucoup lorsque le profil est déployé par stratégie plutôt que tapé à la main.

SSTP a besoin d’une URL, pas d’un nom

SSTP est l’exception car il s’exécute dans une session TLS. Le champ doit s’analyser comme une URL : d’abord le schéma https://, puis l’hôte, puis deux-points et le port. Sans le schéma, Windows continue de traiter la valeur comme un simple nom et la connexion échoue avant tout échange TLS.

La raison pour laquelle cela surprend, c’est que le port par défaut accepte le nom d’hôte nu. Un profil qui n’a jamais eu besoin d’un port personnalisé n’enseigne jamais la règle, et la première personne qui en ajoute un le découvre en échouant. Après avoir enregistré, relisez la valeur stockée au lieu de faire confiance à la boîte de dialogue :

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress montre exactement ce qui a été stocké. Si elle se lit comme un nom d’hôte nu contenant deux-points, le profil n’a jamais reçu d’URL et aucun nombre de nouvelles tentatives ne corrigera cela.

La syntaxe constructeur qui se colle dans la même case

Certaines passerelles documentent des conventions supplémentaires pour ce champ, comme un realm ajouté après le port ou des paramètres de requête qui modifient la gestion des certificats. Elles sont comprises par le serveur de ce constructeur et, dans certaines versions, par son propre client. Elles ne font pas partie du format de profil Windows, et les coller dans un profil intégré produit généralement le même échec silencieux de nom.

Traitez un paramètre qui désactive la validation des certificats comme un avertissement plutôt que comme une correction. Si un profil ne se connecte qu’avec ce paramètre, le certificat ne correspond pas au nom utilisé, et la réparation correcte se fait sur la passerelle, pas dans le client. Un realm après le port a la même propriété : il ne fait quelque chose que si le serveur en face l’attend.

Prouvez le port, puis lisez l’étape qui échoue

Confirmez que quelque chose accepte TCP sur ce port depuis le réseau du client avant de blâmer le profil :

Test-NetConnection vpn.example.com -Port 10443

Le succès prouve un écouteur, pas SSTP. Un serveur web, un proxy inverse ou un répartiteur de charge peuvent terminer la poignée de main TCP et toujours ne pas parler SSTP, donc un test vert avec un VPN rouge est une combinaison réelle. Comparez le sujet du certificat au nom du profil et consultez le journal RasClient dans les versions qui le fournissent, car il enregistre l’étape qui a échoué au lieu d’un délai d’expiration générique.

Envisagez ensuite l’option qui supprime le problème au lieu de le documenter : rediriger TCP 443 depuis l’extérieur vers 10443 sur le serveur VPN. Le client utilise alors le profil par défaut sans aucun port, ce qui est généralement l’arrangement le plus propre pour un parc géré et laisse le port personnalisé comme détail interne.