Comment choisir un client VPN pour Mac adapté à la passerelle que vous avez déjà

Six applications VPN pour Mac apparaissent sur une page de téléchargement et aucune ne dit laquelle la passerelle de votre employeur acceptera. Ce n'est pas un manque dans la boutique ; c'est un manque dans la transmission. Un VPN SSL est une famille de produits, pas un protocole, donc deux passerelles avec des écrans de connexion identiques peuvent exiger des clients différents. Voici l'ordre que j'utilise quand on me confie un Mac et une adresse de serveur : établir ce que parle la passerelle, choisir le client qui y correspond, puis vérifier les routes et le DNS avant de confier du travail au tunnel.

Commencez par la passerelle, pas par la boutique d'applications

L'application tourne sur votre Mac, mais autre chose doit accepter la connexion et accorder l'accès : une passerelle avec un exploitant, une adresse, des réglages compatibles et un moyen de vous autoriser. Un client gratuit peut être un bon logiciel et n'apporter rien de tout cela. L'accès professionnel, une passerelle domestique et une sortie internet commerciale sont trois points de départ différents qui partagent par hasard une même page de téléchargement.

Avant d'installer ou de remplacer quoi que ce soit, obtenez quatre réponses de celui qui exploite le service :

• Mode d'accès : portail web, accès à des applications choisies ou tunnel réseau complet. Cela décide si vous avez besoin d'un client.

• Famille de passerelle et version prise en charge : le produit, le service activé et une version de client qui prend encore en charge votre version de macOS et votre matériel Mac.

• Authentification : mot de passe plus MFA, connexion dans le navigateur, certificat d'appareil ou contrôle de posture. Un client dépourvu du flux approuvé se connectera puis sera refusé.

• Propriété : la source de téléchargement ou de gestion de confiance, le profil prévu et qui l'assure en cas de panne.

La propriété est le point que les gens sautent. Sur un Mac géré, le profil arrive souvent par le système de gestion de l'organisation, et une configuration faite à la main peut être remplacée au prochain contrôle. Demandez si l'on attend de vous que vous installiez quelque chose vous-même avant de chercher une application tierce.

VPN SSL est une étiquette de famille, pas un protocole

TLS peut protéger une connexion tandis qu'un échange propre au produit, à l'intérieur, gère la connexion, l'attribution des sessions et le trafic du tunnel. C'est cet échange interne qu'un client doit implémenter. Un navigateur qui atteint la page de connexion HTTPS de la passerelle prouve la chaîne de certificats et le serveur web ; il ne prouve pas qu'une application VPN sans rapport peut construire un tunnel vers la même machine.

OpenConnect est l'exemple le plus clair que je connaisse. Sa documentation du projet liste des modes de protocole distincts pour différentes familles de passerelles et sépare l'interopérabilité du support officiel de l'éditeur. Si chaque VPN SSL parlait un seul protocole, ces modes seraient inutiles.

Un profil OpenVPN a la même limite dans l'autre sens : c'est un format d'import pour un déploiement compatible OpenVPN. Partager TLS comme brique ne le transforme pas en fichier de configuration pour une passerelle d'entreprise quelconque. C'est pourquoi une connexion navigateur qui fonctionne est un faux positif : l'accès au portail peut réussir alors qu'aucun tunnel n'existe, et un tunnel monté peut ensuite être refusé par un contrôle de posture.

Faites correspondre le client à ce que parle la passerelle

Une fois la famille connue, le choix se resserre vite. C'est la correspondance que je vérifie en premier, et la dernière colonne compte plus que n'importe quelle note d'application.

Deux lignes méritent un avertissement. Le client macOS intégré est une véritable implémentation IKEv2, pas un client SSL VPN générique : un service conçu pour lui exige le bon profil, l'identité de serveur attendue et des identifiants, et sur une machine gérée ce profil peut être verrouillé. OpenConnect couvre plusieurs protocoles d'éditeurs depuis un seul binaire, mais son propre projet ne revendique pas le support de l'éditeur ; l'analyse d'hôte, des règles de tunnel partagé poussées par la passerelle ou un flux SSO particulier peuvent n'exister que dans le client de l'éditeur.

WireGuard a la même forme. Le service fournit les pairs, le client fournit le tunnel, et un profil OpenVPN n'est pas un substitut. Une subtilité macOS : le client de l'App Store garde ses tunnels dans une extension réseau, donc wg show depuis les outils Homebrew peut ne rien signaler alors que l'interface est active. Vérifiez plutôt avec les routes et le trafic.

Configurez, puis vérifiez dans un ordre fixe

Installez un client et un profil, et notez ce que vous avez changé. Avant de vous connecter, capturez une référence pour voir ce que le tunnel modifie :

scutil --nc list
networksetup -listallnetworkservices
netstat -rn | grep -E "^default|utun"
scutil --dns

Connectez-vous avec le profil fourni et répétez les mêmes commandes. En tunnel complet, la route par défaut doit pointer vers une interface utun ; en tunnel partagé, seuls les préfixes internes doivent être routés et votre sortie publique doit sembler inchangée. Le DNS est la moitié qui reste souvent cassée : scutil --dns liste les résolveurs dans l'ordre où le système les utilisera, et un résolveur interne placé sous un résolveur public enverra les noms internes au mauvais serveur.

Pour un service OpenVPN, Tunnelblick est un client raisonnable et gratuit, et son propre guide est direct sur la moitié manquante : il ne fournit pas de service VPN. Double-cliquez sur le .ovpn qu'on vous a donné, laissez Tunnelblick l'installer, et vérifiez la version par rapport à votre version de macOS avant de vous y fier.

Pour une passerelle d'éditeur, je teste souvent avec OpenConnect depuis la ligne de commande :

brew install openconnect
sudo openconnect --protocol=anyconnect --user=you vpn.example.com

L'outil imprime le certificat reçu et attend avant de faire confiance à une chaîne inconnue ; cette invite est une fonctionnalité, et épingler avec --servercert pin-sha256:... vaut mieux que d'accepter un avertissement que vous n'avez pas lu. Ctrl-C coupe le tunnel, car un openconnect au premier plan n'a ni coupe-circuit ni logique de reconnexion. C'est bien pour une session de diagnostic et un mauvais choix par défaut pour le travail quotidien.

Quand il n'y a pas de passerelle à qui correspondre

Certaines personnes arrivent avec le problème inverse : pas d'exploitant, pas d'adresse, pas de service. Une application Mac gratuite ne peut pas créer de joignabilité entrante sur un routeur domestique. Si vous voulez votre propre réseau depuis un hôtel, quelqu'un doit exploiter une passerelle à la maison, la maintenir à jour, publier ou résoudre son adresse et décider quels appareils sont joignables.

Si vous voulez une sortie internet différente plutôt qu'un accès à un réseau privé, choisissez le service avant le client. Une liste de profils vide dans un client autonome n'est souvent pas un abonnement gratuit cassé ; il n'y a peut-être ni abonnement ni serveur associé. Gardez aussi les coûts séparés : une licence de client, une offre de service et une passerelle auto-exploitée sont trois achats différents.

Un Mac professionnel ajoute une couche de politique. Une application gratuite peut être mauvaise même quand elle se connecte, car le client approuvé peut imposer des contrôles d'appareil ou un flux d'authentification que l'alternative n'a pas. Demandez une alternative approuvée au lieu de copier des identifiants entre applications sans rapport, et ne traitez pas la désactivation des protections de la plateforme comme un correctif de compatibilité.

Une visionneuse de bureau à distance est aussi un autre produit. Elle vous montre une session sur un autre ordinateur ; elle ne donne pas aux applications locales de votre Mac le chemin réseau qu'offre un tunnel.

Une courte liste de vérification avant la première vraie session

Nommez par écrit la famille de passerelle et le mode d'accès, installez uniquement le client qui y correspond et notez le profil utilisé. Confirmez ensuite trois choses avec du trafic réel : les routes installées par le tunnel, l'ordre des résolveurs et une application interne atteinte par nom et non par IP.

Si quelque chose échoue, changez une variable à la fois : client, profil, flux d'authentification. Un portail qui se charge alors que le tunnel refuse de démarrer sépare un problème de serveur web d'un problème de compatibilité du client. Quand le service professionnel répond et que le chemin public se comporte comme prévu, vous avez un arrangement nommé et pris en charge au lieu d'un tas de suppositions.