Pourquoi route -interface n’atteint pas un hôte hors du lien

route accepte le nom de l’interface Wi-Fi, se termine sans se plaindre, et l’hôte reste injoignable. Rien n’est corrompu ; la relation dans la route est simplement fausse : un indicateur d’interface dit sur quel lien se trouve une destination, pas quel routeur doit recevoir le trafic d’une destination qui se trouve ailleurs. La commande réussit parce qu’elle est syntaxiquement valide, pas parce qu’elle décrit un chemin qui fonctionne.

Cette distinction décide si une exception de route à côté d’un VPN fonctionnera ou semblera seulement plausible.

L’interface est la sortie, le prochain saut est la remise

Sur un Mac dont l’adresse est 192.168.50.20 et dont le routeur est à 192.168.50.1, une autre machine sur le même lien est joignable directement. La trame est adressée à cette machine et posée sur le fil. Aucun routeur n’intervient, et une route limitée à l’interface exprime exactement cela. Changez l’extrémité distante pour un hôte dans un autre bâtiment et la même commande cesse d’avoir un sens. Le Mac n’a pas d’adresse de deuxième couche à poser sur le fil, donc l’indicateur d’interface n’a rien à décrire.

Une destination hors du lien est différente. Le Mac ne peut pas poser sur le fil une trame adressée à un hôte qu’il n’atteint pas à la deuxième couche ; il remet le paquet à un routeur qui le peut. La route a donc besoin d’une passerelle, et la passerelle elle-même doit être joignable sur le lien raccordé.

Utiliser l’indicateur d’interface pour une destination hors du lien dit à macOS de traiter cette destination comme si elle était sur le fil. Le noyau échoue alors à résoudre une adresse de deuxième couche pour elle, et le paquet est abandonné sans rien d’utile dans l’erreur.

Ce que l’indicateur d’interface affirme réellement

La référence de routes d’Apple définit la forme interface pour les destinations directement joignables sans intermédiaire. C’est une affirmation sur le modèle de lien, pas une préférence sur l’adaptateur à utiliser. Atteindre un hôte internet par Wi-Fi exige toujours un routeur sur ce lien Wi-Fi, et la route doit le nommer.

La portée d’interface est un attribut distinct. Elle associe une route à une interface particulière pour des décisions de portée comme l’adresse source applicable, mais elle ne crée pas de joignabilité pour une destination que l’interface ne peut pas atteindre seule. Les deux attributs répondent à des questions différentes.

C’est pourquoi une commande peut être acceptée, apparaître dans la table et néanmoins échouer. Le noyau ne valide pas votre intention ; il enregistre ce que vous avez affirmé, et l’affirmation était que la destination est sur le lien. Un succès silencieux suivi d’un abandon silencieux est le résultat attendu, pas un défaut. Relisez l’affirmation avant de blâmer le réseau.

La route dont a besoin une destination hors du lien

Pour un chemin approuvé vers une adresse de documentation comme 198.51.100.25 via le routeur LAN, la relation voulue est une destination, un prochain saut de 192.168.50.1 et l’interface LAN qui atteint ce prochain saut. L’interface est induite par la recherche du prochain saut plutôt qu’imposée par la commande de route.

Sur macOS, l’inspection en lecture seule est route -n get 198.51.100.25. Lisez ensemble les lignes de passerelle et d’interface et vérifiez que la passerelle est une adresse que le Mac peut réellement atteindre. Une passerelle sur un autre sous-réseau, ou qui a disparu depuis le dernier changement de réseau, produit une route qui semble correcte et ne transmet rien.

Ne codez pas en0 en dur dans une instruction durable. Les noms d’interface changent avec les adaptateurs, les stations d’accueil et les clients VPN, et une route qui nomme le mauvais échoue d’une manière facile à confondre avec une panne réseau plus large.

Lisez le choix actuel avant de le remplacer

Avant d’ajouter quoi que ce soit, examinez ce que le système a déjà choisi et pourquoi. Cette sortie vous dit si le trafic passe par le tunnel, par le routeur LAN ou nulle part, et vous donne une base de comparaison après le changement. Sans elle, vous ne pouvez pas savoir si la nouvelle route a pris effet.

Vérifiez ensuite la famille d’adresses. Une route ajoutée pour IPv4 ne fait rien pour une destination IPv6, et un service qui résout vers les deux familles peut sembler joignable par intermittence. La table de routage et le résolveur répondent à des questions différentes, et les deux doivent s’accorder avec le chemin voulu.

Enfin, rappelez-vous qu’une route est une sélection, pas une autorisation. Un profil VPN géré ou un filtre client peut encore interdire le chemin direct même lorsque la table le désigne, donc testez avec l’application réelle plutôt que de supposer qu’une entrée réussie dans la table met fin à l’enquête.

Les tunnels et la politique changent la forme

Les interfaces point à point sont leur propre cas. Un tunnel peut porter une route sans adresse de passerelle de style Ethernet, et ce n’est pas automatiquement faux. Appliquez le modèle de lien réel de l’interface au lieu d’étendre un exemple Wi-Fi à chaque entrée de table que vous voyez.

Pour les demandes de changement, notez la destination, le chemin réseau approuvé, la passerelle et l’interface actuelles, et qui est censé maintenir l’exception. Le propriétaire compte parce qu’une route ponctuelle tapée à l’invite n’est pas une politique, et la prochaine reconnexion l’effacera.

Si l’exigence est d’atteindre cet hôte pendant que le VPN est actif, la réponse honnête est généralement une route d’hôte spécifique via le routeur local, installée par le gestionnaire réseau qui possède l’interface. Si l’exigence est d’atteindre n’importe quoi directement, l’exigence elle-même a besoin d’une revue de politique avant d’avoir besoin d’une commande de route.