Le VPN intégré de Windows n’atteint pas une passerelle SSL d’éditeur : pourquoi

Windows embarque quatre types de tunnel, et une passerelle SSL d’éditeur n’en fait pas partie. Pointez quand même un profil intégré vers une telle passerelle et la connexion échoue avant la demande d’identifiants, généralement avec un message indiquant que le système local a mis fin à la connexion. Ce texte est un signal d’incompatibilité, pas un diagnostic. Le type de profil et le client qui possède le protocole doivent concorder, et l’un des deux manque.

Quatre types et une boîte de dialogue

Chaque profil enregistré porte un type de tunnel. Le client intégré accepte PPTP, L2TP, IKEv2 et SSTP, plus un mode automatique qui les essaie dans l’ordre. Il n’existe aucune entrée SSL VPN générique, et aucun moyen d’en ajouter une via la boîte de dialogue. Une passerelle d’éditeur parle son propre protocole applicatif sur TLS, que seul le client de cet éditeur implémente.

La liste est à une commande, et elle vaut la peine d’être exécutée avant toute autre recherche de panne car elle prend une seconde et écarte toute une classe d’hypothèses fausses :

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

Si le profil indique SSTP et que la passerelle n’est pas un serveur RRAS, l’incompatibilité est déjà établie. Aucun travail sur les certificats ou le pare-feu ne la change.

SSTP et le TLS d’éditeur se ressemblent sur le port 443

SSTP encapsule une session PPP dans TLS et passe sur TCP 443. Dans la pile Microsoft, c’est RRAS qui la termine, en présentant un certificat de serveur que le client valide. Une appliance Fortinet, Citrix ou Pulse termine aussi TLS sur le 443, et son portail s’ouvre dans n’importe quel navigateur sans plainte.

Ce test dans le navigateur prouve l’accessibilité, pas la compatibilité. Le protocole de session derrière le portail appartient à l’éditeur, et le client intégré n’en a aucune implémentation. Savoir si l’éditeur fournit son propre client vous dit à quelle moitié de l’incompatibilité vous avez affaire.

La confusion inverse existe aussi. Un profil configuré en SSTP face à un vrai serveur RRAS peut échouer à la validation du certificat alors que le portail va bien, et c’est un problème de certificat, pas de protocole.

Des erreurs qui apparaissent avant qu’un tunnel existe

Les codes de la série 800 sont signalés avant qu’un tunnel soit établi, c’est pourquoi les règles de pare-feu les déplacent rarement. L’erreur 812 est une stratégie côté serveur qui rejette la méthode d’authentification proposée par le client. Les autres de la plage viennent du gestionnaire de connexions local et non du réseau.

Activez le traçage avant de reconstruire quoi que ce soit. Le traçage nomme l’étape qui échoue, et un nom d’étape vaut mieux que le texte de la boîte de dialogue :

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

Les traces atterrissent dans le répertoire de traçage et y restent jusqu’à ce que vous les effaciez, donc désactivez le traçage ensuite au lieu de le laisser tourner des semaines.

Un profil connecté peut encore tout casser

Un profil qui se connecte puis casse la navigation, un partage local ou un moteur de conteneurs a un problème de routage, pas un problème de tunnel. La passerelle par défaut a migré vers le tunnel, donc chaque destination passe maintenant par un pair qui ne la route peut-être pas.

Deux réglages décident de cela. L’un est la propriété de split tunneling du profil. L’autre est l’option par adaptateur d’utiliser la passerelle par défaut sur le réseau distant, qui se trouve dans les paramètres IPv4 avancés.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

Activer le split tunneling sans ajouter de routes produit un tunnel qui se connecte et n’atteint rien. Le désactiver sans vérifier le DNS produit des noms internes qui se résolvent en réponses publiques, car le suffixe et les serveurs propres à l’adaptateur ne sont pas utilisés.

Vérifiez la plomberie, puis le type

Travaillez dans cet ordre, et arrêtez-vous quand une étape échoue au lieu de tout ajuster en même temps :

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

La première commande sépare l’accessibilité du protocole. La deuxième confirme ce que le profil prétend être. La table de routage montre si le tunnel a capturé la route par défaut. La commande de numérotation rapporte l’erreur propre au gestionnaire de connexions, souvent plus claire que la boîte de dialogue.

Notez le type de tunnel, le produit de la passerelle et l’erreur exacte dans le ticket. La personne suivante sait alors en une minute s’il s’agit d’une incompatibilité de protocole, d’une défaillance de certificat ou d’une décision de routage, au lieu de partir de « le VPN ne marche pas ».