Configurer un VPN sur Mac : choisissez le client adapté à votre profil

Configurez le client que votre opérateur VPN nomme, puis prouvez le tunnel avec la ressource privée dont vous avez réellement besoin. Un Mac peut conserver une configuration VPN native dans Réglages Système, mais un fichier OpenVPN ou WireGuard exige un logiciel qui comprend le format, et ce sont des chemins de configuration différents. Le type d’identifiant détermine comment la connexion échouera, lisez-le donc avant de saisir quoi que ce soit. Jugez le résultat sur ce que renvoie la ressource privée, pas sur l’icône de la barre des menus.

Faites correspondre le client au profil que vous avez reçu

Partez du fichier ou des instructions envoyés par votre opérateur, pas d’une liste de protocoles sur un site de téléchargement. Le formulaire VPN natif de Réglages Système gère certains types ; un profil OpenVPN ou une configuration WireGuard exige une application qui l’analyse. Un Mac géré peut déjà recevoir sa connexion de la gestion des appareils, et ajouter un second profil par-dessus produit un conflit plutôt qu’une configuration. Regardez ce qui existe déjà avant d’installer quoi que ce soit.

La méthode de connexion vient du profil, et c’est généralement l’une des trois : un mot de passe de compte, un certificat client ou une phrase secrète qui déverrouille une clé privée. Un mauvais mot de passe et un certificat rejeté arrêtent tous deux la connexion, mais ils ne se lisent pas de la même façon, et un seul des deux se corrige en réinitialisant un mot de passe de compte. Lisez le rejet avant de changer quoi que ce soit : un certificat expiré ou non approuvé échoue encore après une réinitialisation de mot de passe, alors qu’un mauvais mot de passe échoue aussitôt, dès la première tentative.

Gardez le matériel privé hors des journaux partagés. Une phrase secrète de clé, un certificat client et sa clé n’ont pas leur place dans un fil de discussion avec un collègue, et une capture d’écran de l’éditeur de profils révèle généralement plus que ce que l’expéditeur attend. Si l’opérateur fournit un fichier importable, importez-le au lieu de retaper les valeurs à la main.

Prouvez que cela fonctionne sur la ressource, pas sur l’icône

Un profil professionnel ne route souvent que les destinations du bureau, si bien que l’adresse publique visible pendant la navigation peut rester la même alors que l’application privée fonctionne. Sur un profil de sortie personnel, l’adresse visible de l’extérieur doit changer, et sur un profil professionnel elle ne doit généralement pas. Mesurez cette différence avant de conclure que le tunnel est cassé.

Ouvrez ensuite la ressource dont vous avez réellement besoin : le partage de fichiers, la page d’administration, l’hôte de base de données. Qu’une page d’accueil se charge via le tunnel prouve que le tunnel transporte du trafic, pas qu’il transporte celui que vous visiez. Si le navigateur affiche encore l’adresse d’origine alors que le profil est censé la changer, comparez trois choses : l’application utilisée, la famille d’adresses et la politique de proxy. Un proxy de navigateur ou un chemin IPv6 peut détourner le trafic hors du VPN alors que le tunnel lui-même est sain.

Là où le client expose une table de routage, lisez la route par défaut et la route du tunnel. Cette paire consigne la conception que vous avez réellement déployée.

Quand cela cesse de fonctionner, trouvez la couche qui a cassé

Une configuration qui fonctionnait auparavant a généralement cassé parce que quelque chose s’est ajouté au chemin : un second client VPN, un agent de sécurité, un filtre de contenu, une nouvelle extension réseau. Utilisez les diagnostics propres au produit plutôt que d’effacer des préférences ou de réinitialiser la pile réseau, ce qui est un espoir et non un diagnostic. Rattachez la panne à un événement — veille, changement de Wi-Fi, connexion au portail ou mise à jour du client — et notez si elle se répète. Un déclencheur reproductible appartient au ticket avec l’heure où il s’est produit.

Les noms échouent différemment des routes. Un hôte privé doit être joint par son nom complet documenté, et les noms de bureau courts dépendent d’un résolveur interne plus un domaine de recherche qui n’existe que sur le chemin de l’entreprise. Remplacez ce résolveur par un service DNS public et les noms courts cessent totalement de se résoudre, ce qui ressemble à un tunnel cassé sans en être un.

scutil --dns
dscacheutil -q host -a name intranet.example.com

Dans la sortie de scutil --dns, trouvez le résolveur dont le domaine de recherche correspond à votre domaine d’entreprise et lisez le serveur de noms vers lequel il pointe ; les entrées listées sous la configuration DNS montrent quel résolveur chaque interface fournit. Quand le résolveur d’entreprise n’apparaît que pour une autre interface, ou que le navigateur exécute son propre DNS chiffré, une application résout le nom pendant que tout le reste échoue.

Retirez un profil dont vous n’avez plus besoin par le mécanisme qui l’a installé, car supprimer une entrée locale laisse le compte côté serveur vivant et un client obsolète peut encore revendiquer les mêmes routes. Sur un Mac géré, c’est la procédure de retrait de l’administrateur qui compte. Notez le nom du profil, l’adresse du serveur et la ressource qui fonctionne avant de retirer quoi que ce soit, afin que la reprise ne parte pas de zéro.