Vous ouvrez la liste des VPN, choisissez l’autre entrée enregistrée et attendez un basculement propre : une nouvelle adresse de sortie et tout le reste inchangé. C’est l’hypothèse à abandonner en premier. Sur macOS, un VPN enregistré est un service réseau complet et non un préréglage, donc changer de service peut modifier en même temps le routage, le DNS et l’authentification. La barre de menus indique quel service est actif ; elle ne dit pas si le tunnel en dessous correspond à ce que vous vouliez.

La liste enregistrée n’est pas un sélecteur de profils

Chaque entrée de Réglages Système > Réseau est un service à part, avec sa propre adresse de serveur, son compte, sa méthode d’authentification, ses serveurs DNS et des options comme Envoyer tout le trafic via la connexion VPN. Les versions plus anciennes tiennent la même liste dans les Préférences Système. Deux entrées peuvent pointer vers le même nom d’hôte et se comporter différemment, parce que le protocole ou l’extension du client décide de la façon dont le tunnel est construit.

Les clients tiers tiennent des listes séparées. Tunnelblick lit les configurations dans son propre dossier, WireGuard garde sa propre liste de tunnels, et OpenVPN Connect stocke les profils dans l’application. Certains enregistrent une configuration auprès du système ; d’autres gardent tout dans l’application et n’apparaissent jamais dans la liste intégrée. « Basculer vers celle qui est enregistrée » signifie donc des actions différentes selon l’application qui possède le profil.

scutil --nc list imprime les services VPN enregistrés dans la configuration du système, avec les noms entre guillemets. Utilisez ces noms exacts lorsque vous scriptez un basculement, et ne partez pas du principe que la liste couvre tous les tunnels tiers.

Ce qu’un basculement change réellement

Quatre choses bougent ensemble quand le service actif change. La route par défaut suit le nouveau tunnel si ce service envoie tout le trafic ; la liste des résolveurs passe aux serveurs DNS que le service précise ; les nouvelles connexions prennent l’adresse du nouveau tunnel comme source ; et les identifiants en jeu appartiennent au nouveau service. Une configuration native et un profil d’application ne sont pas interchangeables, même lorsque les deux aboutissent à la même passerelle.

What you assumeWhat the system does
Same server name means same tunnelProtocol, certificate and account are per service
All traffic follows the active VPNOnly when Send all traffic over VPN is on
DNS switches with the VPNOnly if that service defines DNS servers
Disconnect ends the connectionOn Demand or a management profile can reconnect
Open sessions survive the switchTCP sessions tied to the old address stall

La partie DNS prend les gens au dépourvu. macOS maintient un ordre de résolveurs, et scutil --dns montre quels résolveurs sont utilisés et sur quelle interface. Un service VPN sans serveurs DNS configurés peut laisser le résolveur Wi-Fi répondre, si bien que vous obtenez une nouvelle adresse publique avec l’ancien comportement DNS et concluez que le basculement n’a fonctionné qu’à moitié.

Pourquoi l’ancienne configuration revient

Si vous vous déconnectez et que le même service se reconnecte un instant plus tard, regardez d’abord On Demand. Une règle de connexion à la demande peut faire revenir un service quand une application résout un domaine correspondant, et un profil de gestion peut imposer la même règle. Supprimer l’entrée y remédie rarement : une configuration installée par profil revient généralement à la prochaine actualisation du profil, et une configuration manuelle peut laisser son mot de passe dans le trousseau tandis que le service a disparu.

Démarrer un second service n’arrête pas toujours le premier. Selon le client et le protocole, vous pouvez vous retrouver avec deux tunnels et deux jeux de routes, et c’est l’ordre des services et la spécificité des routes qui décident lequel porte le trafic, pas l’icône sur laquelle vous avez cliqué en dernier. Vérifiez les interfaces avant de supposer qu’un basculement a eu lieu.

Vérifiez le tunnel, pas la coche

Passez par la vue du système lui-même avant de toucher aux réglages.scutil --nc status "Name" indique ce que le système croit ;ifconfig montre si une interface utun a une adresse ;netstat -rn -f inet montre où pointe la route par défaut ;scutil --dns montre le résolveur réellement utilisé. Ouvrez ensuite une connexion neuve et confirmez l’adresse de sortie, car une page déjà connectée peut encore utiliser une socket liée à l’ancien tunnel.

Si le DNS répond encore depuis le réseau local, comparez les serveurs configurés du service avec la liste des résolveurs. Si la route par défaut pointe encore vers l’interface physique, le service est en tunnel divisé ou n’est pas complètement connecté. Les deux sont des résultats de configuration, pas la preuve d’un client défaillant.

Un ordre de basculement sans surprises

  1. Notez le service actuel et si un profil le gère.
  2. Déconnectez-le d’abord quand les deux tunnels ne peuvent pas coexister.
  3. Connectez la cible et attendez Connecté, pas Connexion.
  4. Vérifiez la route par défaut, la liste des résolveurs et une adresse de sortie neuve.
  5. Redémarrez les applications qui gardent des sessions longues.

Gardez l’ancienne entrée jusqu’à ce que la nouvelle passe ces vérifications, et donnez à chaque entrée un nom distinct ; des libellés identiques rendent la prochaine panne plus difficile à attribuer. L’aide du Mac d’Apple décrit le côté natif à Configurer une connexion VPN sur le Mac, qui est la référence à consulter avant de modifier une configuration gérée.

Si la sélection revient en arrière, traitez-la d’abord comme une politique ou On Demand. Confirmez qui possède la configuration et si elle est réglée pour se connecter automatiquement, puis décidez si vous changez de service ou si vous vous battez contre un profil.

Articles similaires