Vérifier une route VPN sur macOS : route get sans rien modifier

Un utilisateur atteint l'intranet sur le réseau du bureau et non par le tunnel, tandis que Réglages affiche toujours le VPN comme connecté. Modifier la table de routage à ce moment risque de couper la session distante que vous utilisez pour diagnostiquer. Demandez plutôt au noyau quel chemin il choisirait pour l'hôte qui échoue. L'utilitaire route de macOS possède une opération get qui répond exactement à cela, pour une destination, sans rien changer.

Interrogez l'hôte qui échoue, pas la route par défaut

Une capture de la route par défaut dit très peu sur un Mac moderne, car une destination plus spécifique ou une politique restreinte peut supplanter ce que la route par défaut semble dire. Le tunnel peut être actif, la route par défaut peut sembler correcte et, malgré tout, le seul hôte dont vous avez besoin peut être routé ailleurs. Interrogez l'adresse qui échoue et laissez le noyau nommer le chemin qu'il a choisi.

La forme est route -n get suivie de l'adresse : route -n get 203.0.113.10, où l'adresse de documentation tient lieu de cible. Utilisez la destination autorisée et la famille d'adresses correspondante, car une réponse IPv4 ne dit rien d'une ressource uniquement IPv6. La documentation de l'utilitaire route décrit l'opération get et les champs qu'elle imprime.

Lisez l'interface et la passerelle comme des preuves

Exécutez la requête avant de connecter le VPN, puis de nouveau après, et comparez les lignes d'interface et de passerelle. La différence entre ces deux réponses est ce que le tunnel a réellement changé, et elle est bien plus utile qu'un vidage complet de la table. Si l'interface est identique dans les deux exécutions, la route n'a jamais été le problème et vous pouvez cesser de regarder le routage.

Notez la destination, l'interface, la passerelle et l'heure de la requête avant de conclure. La sortie est une preuve, pas un diagnostic : la même interface peut être correcte pour un hôte et fausse pour un autre lorsqu'un tunneling divisé est en jeu.

Une route correcte n'est pas une requête qui fonctionne

Une route vous dit quelle interface le noyau utiliserait, rien de plus. Le DNS, un pare-feu de l'hôte et l'autorisation de l'application se situent tous au-dessus de cette décision, et la requête peut échouer après la réussite du routage. Conservez le symptôme exact avant de continuer, car « impossible de se connecter » et « se connecte mais renvoie une erreur » sont des enquêtes différentes avec des étapes suivantes différentes. La vue du résolveur et la vue de l'interface complètent la requête de destination au lieu de la remplacer.

Une liste de la table de routage garde sa place : c'est ainsi que vous remarquez une route par défaut inattendue. Une route par défaut ordinaire qui subsiste ne prouve pas que le VPN est inutilisé, car les entrées plus spécifiques l'emportent sur elle.

Gardez le point de terminaison et la ressource séparés

Deux recherches sont en jeu et elles répondent à des questions différentes. Atteindre le point de terminaison est un voyage extérieur à travers le réseau physique. Atteindre l'application se produit à l'intérieur du tunnel, à une adresse qui n'existe que du côté privé. Confondre les deux produit la classique boucle fausse, où le point de terminaison semble être routé par le tunnel qu'il termine. Interrogez les deux adresses séparément, étiquetez chaque résultat, et la confusion disparaît.

Le chevauchement de préfixes est l'autre cas qu'il vaut la peine de connaître. Lorsque les plages locale et distante se chevauchent, c'est la correspondance du préfixe le plus long qui décide, si bien qu'un sous-réseau local chevauchant peut masquer l'adresse distante que vous attendiez. La destination privée semble alors identique à une destination locale, et la correction relève du plan d'adressage plutôt que de la table de routage. La requête get montre quelle interface l'a emporté, et c'est le fait dont vous avez besoin avant de changer quoi que ce soit.

Lisez d'abord, changez ensuite

Gardez route add et route delete hors de la première passe. Sur un Mac que vous administrez à distance, une édition imprudente de la table peut emporter précisément le chemin de retour vers la machine, ne laissant personne capable de terminer le diagnostic. Décidez quelle route est correcte, notez comment annuler la modification, et seulement alors exécutez-la. L'inspection n'a pas une telle queue.

La même prudence s'applique au vidage des caches et au redémarrage des services réseau comme premier geste, car les deux détruisent la preuve que vous alliez lire. Les vérifications en lecture seule sont peu coûteuses, répétables et sûres dans n'importe quel ordre. Faites-en l'étape par défaut, et ne recourez à une modification que lorsque la preuve la désigne.