L'ordre des services de macOS ne contrôle pas vos routes VPN

Quelque chose échoue sur un site web, un collègue se souvient que l'ordre des services existe, et le Wi-Fi est traîné au-dessus de l'Ethernet. Rien ne change, car cette liste n'a jamais décidé où va une destination VPN. Apple donne la priorité aux connexions VPN sur les connexions ordinaires et les tient hors de ce réordonnancement, si bien que le réglage répond à une question plus étroite que celle posée. La panne a besoin de la route sélectionnée et du résolveur, pas d'un nouveau classement.

Ce que l'ordre des services change, et ce qu'il ne touche jamais

« Définir l'ordre des services » se trouve dans Réglages Système, Réseau, dans le menu Action, et classe les connexions ordinaires lorsque deux ou plus sont actives. Ce classement choisit le service principal, qui fournit la route par défaut et une partie du comportement du résolveur. C'est un départage entre pairs, pas un interrupteur pour des destinations privées derrière un tunnel. Un portable avec Wi-Fi et un adaptateur Ethernet USB l'utilise pour répondre à une question sensée, et cette question ne porte pas sur le tunnel.

Un profil VPN porte des routes incluses, des destinations exclues et parfois des règles par application, et celles-ci décident de ce qui entre dans le tunnel ; le menu d'ordre ne les modifie pas. C'est pourquoi un profil en tunnel divisé peut laisser le trafic public dehors tandis que le VPN surclasse encore toutes les interfaces physiques. Faire glisser le Wi-Fi en haut ne rend pas une plage privée joignable et n'arrête pas une destination que le profil inclut déjà. La liste déplace des interfaces ; le profil déplace des préfixes. Apple documente la priorité sur sa page sur l'ordre des services réseau, qui vaut une lecture avant de tout réorganiser.

Lisez la route que la machine a réellement choisie

Demandez à la machine où va une adresse précise avec route get 10.20.4.10, puis répétez pour IPv6 avec route -n get -inet6 2001:db8::10. Les deux familles sont des décisions distinctes, donc une route IPv4 qui fonctionne ne dit rien de la v6, et un sous-réseau directement connecté ou un préfixe plus spécifique l'emporte de toute façon sur l'étiquette générale de connexion, ce qui est exactement pourquoi l'étiquette continue d'induire les gens en erreur.

Si la sortie nomme l'interface du tunnel, le profil a capté la destination et l'ordre n'a aucune importance. Si elle nomme l'interface physique, le profil ne l'a pas fait, et aucun glissement ne changera la table des préfixes. Les deux sorties nomment aussi l'adresse source que la machine utiliserait, et c'est le champ à citer quand vous comparez deux exécutions. Enregistrez la sortie avant de changer quoi que ce soit, car c'est la seule preuve qu'il vous restera ensuite.

Le DNS résout par nom, pas par interface

Des résolveurs limités et propres à un domaine signifient que la réponse peut différer par nom plutôt que par interface. scutil --dns affiche la configuration de résolveur que le système utilise réellement, entrées limitées comprises. L'ordre des services influence le service qui fournit le résolveur par défaut, mais une portée propre à un nom peut l'emporter malgré tout.

C'est pourquoi un ping vers une adresse peut fonctionner alors que le nom d'hôte échoue, ou l'inverse. Lisez les deux sorties avant de désigner un coupable.

Modifiez le profil, puis relisez les deux sorties

Quand une politique de destination doit changer, le propriétaire est le profil VPN : routes incluses, routes exclues et toutes les règles de tunnel divisé que le fournisseur prend en charge. Changer d'interfaces ne fait que déplacer le débat. Sur un Mac géré à distance, enregistrez d'abord l'état réseau actuel, car perdre le tunnel sur une machine inaccessible est un déplacement, pas un retour en arrière.

Reproduisez la panne, lisez la route, lisez le résolveur, changez une seule chose, puis relisez les deux mêmes sorties. Mélanger plusieurs services et profils à la fois laisse une machine que personne ne peut expliquer, y compris la personne qui l'a réparée. Le test est terminé quand les deux sorties concordent avec le changement voulu. Si elles divergent encore, le profil et la machine décrivent deux politiques différentes, et c'est le profil qu'il faut changer.