VPN Windows ou Cisco Secure Client : laquelle est la bonne ?
Une marque ne nomme pas un protocole : Windows propose plusieurs types natifs et le client Cisco transporte des profils pour plus d’un mode. Lisez le profil.
Pour la même passerelle arrivent deux consignes : connectez-vous avec le VPN Windows ou installez le client Cisco. Aucune des deux ne nomme l’échange que la passerelle attend, car Windows expose plusieurs types de connexion natifs et le client de l’éditeur transporte des profils pour plus d’un mode. Les deux étiquettes décrivent un logiciel, tandis que la passerelle négocie protocole, authentification et politique. La réponse se trouve dans le profil, et elle se lit sans se connecter.
L’étiquette nomme un logiciel, pas un échange
Une marque et un système d’exploitation sont deux faits différents, et aucun des deux ne choisit un format de fil. Windows fournit un ensemble de types natifs, et le client Cisco fournit un moteur de profils capable de piloter SSL ou IPsec/IKEv2. Confondre les deux produit des tableaux qui comparent des entreprises au lieu de comparer des échanges.
Le tableau ci-dessous remplace la question du produit par trois emplacements de lecture et le champ que chacun contient. Notez ces champs, et l’ambiguïté disparaît :
| Where to read it | Field name to record | What a mismatch looks like |
|---|---|---|
| Native Windows profile | TunnelType and AuthenticationMethod from Get-VpnConnection | The client offers IKEv2 while the gateway answers only on an SSL port |
| Vendor client profile | SSL or IPsec/IKEv2 mode, plus the client and headend version pair | The imported profile negotiates a mode this headend does not serve |
| Gateway configuration | Protocol, authentication policy and the certificate the headend presents | The client authenticates and then drops, because policy expects another method |
La référence des types de VPN Windows publiée par Microsoft liste IKEv2 et SSTP parmi les types natifs, ce qui écarte l’idée qu’un profil natif signifie PPTP. La documentation des profils de Cisco décrit à la fois le mode SSL et le mode IPsec/IKEv2 avec la politique de concentrateur correspondante. Chaque éditeur propose plusieurs options, donc aucun nom n’identifie un seul protocole.
Ce que les types natifs mettent sur le fil
IKEv2 négocie des associations de sécurité sur UDP et transporte le trafic à l’intérieur d’IPsec, ce qui en fait un pair des autres implémentations IKEv2 et non une conception propre à Microsoft. SSTP encapsule PPP dans une session HTTPS, il traverse donc des proxys que IKEv2 ne peut pas franchir et ressemble à TLS sur le fil sans être un protocole VPN TLS. Ces deux faits expliquent l’essentiel d’un ticket qui signale que le tunnel fonctionne sur un réseau et échoue sur un autre.
L2TP avec IPsec et l’ancienne entrée PPTP figurent dans la même liste déroulante, et leur présence n’y dit rien du support serveur. Une liste déroulante est un menu de ce que le système peut tenter, pas une déclaration de capacités de la passerelle. La lire comme une liste de prise en charge, c’est ainsi que commence une chasse aux identifiants de deux heures.
Les champs qui comptent dans un profil natif sont le type de connexion, la méthode d’authentification et l’identité du serveur. Le mauvais type échoue à une étape différente d’un mauvais mot de passe, et cette différence est l’indice qui vaut la peine d’être suivi.
Ce qu’un client d’éditeur ajoute : des profils, pas un protocole
Le client Cisco est un conteneur de profils. Un mode SSL et un mode IPsec/IKEv2 diffèrent par l’échange, les attentes de port et le texte d’erreur, et le profil importé choisit entre les deux. Installer le client ne prouve donc rien sur l’accessibilité.
Les versions sont appariées pour une raison. Les fonctions, les flux d’authentification et les contrôles de posture se négocient entre le client et le concentrateur, si bien qu’un ancien client face à un concentrateur neuf peut échouer d’une manière qui se lit comme une panne réseau. Cet appariement appartient à la définition de connexion, pas à une note de mise à jour.
Un profil exporté depuis une autre organisation correspond rarement au concentrateur local, et l’importer peut laisser le client proposer un mode que la passerelle ne sert pas. Lisez d’abord le mode dans le profil, puis comparez-le au protocole et à la politique d’authentification configurés sur la passerelle. Ce n’est qu’après leur accord que le réseau devient suspect. Cet ordre épargne une capture de paquets qui aurait montré une session TLS saine pointée vers le mauvais service.
Lisez le profil local avant de changer quoi que ce soit
Sous Windows, la configuration native se lit sans composer, et la sortie nomme directement le type et la méthode d’authentification. Comparez ces valeurs avec ce que le propriétaire de la passerelle dit que le concentrateur accepte. Si le type contredit le ticket, corrigez d’abord le ticket, car c’est moins cher que de réinstaller un client qui n’avait jamais tort.
Ces quatre commandes couvrent le profil, ses routes, la tentative de connexion et l’accessibilité du port. Exécutez-les dans cet ordre sur une machine où le profil est déjà installé :
Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443Le test de port est celui que l’on surinterprète. Un écouteur TCP 443 qui sert une page de connexion et un autre qui termine IKEv2 se ressemblent de l’extérieur, car le port est un emplacement et non un protocole.
Écrivez le résultat en trois champs, client, mode et passerelle, et gardez-les à côté du ticket. Tout ce qui est plus court laisse la personne suivante redécouvrir la même ambiguïté.