Un seul service VPN peut-il couvrir des postes Windows, Mac et Linux ?

Trois portables dans une même équipe, trois menus VPN différents et un ticket qui dit que la connexion fonctionne partout sauf sur le Mac. Le plan derrière ces clients peut être identique même lorsque les menus ne le sont pas. Ce qui doit concorder est plus étroit que ne le supposent la plupart des déploiements : une identité de passerelle, un type de justificatif, un jeu de routes et une politique de résolution. Écrivez ces quatre points avant que quiconque exporte un profil, et le travail de plateforme devient une liste de contrôle au lieu d'une enquête.

Commencez par le contrat d'accès, pas par le fichier client

Le contrat d'accès tient en cinq lignes qu'un relecteur peut vérifier sans ouvrir une console fournisseur. Il nomme les préfixes privés qui doivent être joignables, les noms internes qui doivent être résolus, le résolveur qui y répond, le trafic autorisé à rester sur le chemin local et le certificat de passerelle que le client doit s'attendre à voir. Tout le reste du déploiement est une traduction de ces lignes dans un format de fichier.

Un exemple de bureau rend la forme concrète : des serveurs d'applications dans 10.60.0.0/16, des noms privés sous corp.example, un résolveur interne à 10.61.0.53 et la navigation ordinaire laissée sur le chemin que l'appareil utilise déjà. Ce dernier point est une décision de politique et non un défaut du client, et plusieurs clients enverront tout par le tunnel si personne ne dit le contraire. Consignez le contrat avec une date et un responsable, car c'est cet enregistrement qui vous dira plus tard si le tunnel a changé ou si la politique a changé.

Choisissez un protocole et une paire d'authentification que vous pouvez défendre

IKEv2 avec authentification de passerelle par certificat et EAP pour l'utilisateur est le choix habituel lorsque les trois plateformes doivent fonctionner sans logiciel supplémentaire, car Windows, macOS et NetworkManager embarquent chacun un client IKEv2. Le problème est que prendre en charge IKEv2 décrit une étiquette, pas un ensemble de fonctions. Les méthodes EAP, les clés adossées au matériel, l'association certificat-compte et la reconnexion automatique sont implémentées plateforme par plateforme. Une combinaison qui fonctionne sur deux des trois est assez courante pour qu'on la suppose jusqu'à ce qu'elle soit testée.

Testez la paire sur chaque plateforme cible avant d'écrire le guide de déploiement, pas après. Une passerelle offrant à la fois EAP-MSCHAPv2 et EAP-TLS vous laisse une marge de repli, à condition que ce repli soit documenté comme pris en charge et non découvert pendant un incident. Deux chemins pris en charge sont une assurance bon marché ; un troisième chemin non documenté est un futur ticket.

Quand aucune paire ne couvre les trois clients, les options honnêtes sont d'ajouter un client, d'ajouter un profil de passerelle ou de réduire la liste des plateformes prises en charge. Désactiver la validation des certificats sur la plateforme qui se plaint le plus fort n'en fait pas partie. Ce changement transforme un écart de compatibilité en risque d'interception, et aucune étape ultérieure du déploiement ne le répare.

Construisez un artefact par plateforme à partir du contrat

Windows prend un profil VPNv2, fourni par MDM ou créé localement avec Add-VpnConnection et sa charge XML. Les points qui font mal sont la portée et la confiance. Un profil de portée appareil et un profil de portée utilisateur s'installent dans des magasins différents, donc le certificat dont le client a besoin doit se trouver dans le magasin correspondant à la portée choisie. Un mauvais appariement produit un profil qui s'importe proprement puis échoue à la première connexion.

macOS prend un profil de configuration avec la charge VPN gérée, signé et poussé par MDM ou installé à la main pour un pilote. L'identité et la chaîne CA voyagent comme des charges séparées, ce qui explique qu'un profil puisse s'installer sans plainte et néanmoins échouer au moment de la connexion. Vérifiez la liste des charges, pas seulement le résultat de l'installation.

Linux dépend du moteur derrière NetworkManager, et strongSwan ainsi que le greffon NetworkManager sont des paquets distincts. Les propriétés de connexion sont propres au greffon et non des clés VPN génériques, donc une clé copiée d'un autre greffon est souvent enregistrée sans erreur puis échoue à l'activation. Construisez la connexion sur une image propre pour confirmer que le greffon est présent là où elle s'exécutera réellement.

Les trois artefacts diffèrent de format, mais chacun encode les mêmes cinq lignes du contrat. C'est le test pour savoir si un artefact est terminé : chaque ligne est représentée quelque part, et rien d'extra n'a été inventé en chemin.

Vérifiez routes, résolveur et reconnexion sur un compte propre

Connecté n'est pas le test d'acceptation. Sous Windows, Get-VpnConnection montre le profil et route print montre si le préfixe privé a atterri sur l'interface du tunnel. Sous macOS, scutil --nc list confirme le service actif tandis que scutil --dns montre l'ordre des résolveurs que le système utilisera réellement.

Sous Linux, nmcli connection show --active prouve que la connexion est montée et resolvectl status montre le DNS par lien. Un résolveur présent dans le fichier de connexion mais absent de la sortie par lien signifie que le DNS fractionné n'est pas appliqué. C'est la différence entre des noms qui se résolvent et des noms qui se résolvent par le tunnel, et cela change quelle équipe de support possède l'étape suivante. Comparez la sortie par lien avant et après la montée de la connexion, pas seulement après.

Exécutez toute la vérification avec un compte neuf, sans justificatifs en cache et sans certificat installé par un administrateur. Répétez-la ensuite après une mise en veille et une reprise, puis encore une fois après avoir forcé une nouvelle saisie des justificatifs. Ces deux transitions font apparaître la plupart des échecs de reconnexion qu'une première connexion ne montre jamais.

Versionnez le paquet et gardez un chemin de retour arrière

Étiquetez chaque paquet de plateforme avec la révision de contrat qu'il met en œuvre, et notez les versions de client et de passerelle avec lesquelles vous l'avez accepté. Quand le comportement change après une mise à jour du client, l'étiquette pointe vers un contrat à retester plutôt que vers un fichier à deviner.

Gardez le paquet précédent de chaque plateforme récupérable et écrivez sa commande de suppression à côté. La désinstallation d'un profil VPN n'est pas l'image miroir de son installation sous Windows, macOS ou Linux, et les différences apparaissent au pire moment. Répétez la suppression une fois sur un appareil de rechange pour que l'archive devienne un plan plutôt qu'un espoir.