Copier le /32 du tunnel n’achemine pas le sous-réseau du bureau
L’adresse que le VPN remet à votre adaptateur décrit la liaison, pas la destination. Ajoutez le préfixe de la ressource au profil et laissez la route par défaut tranquille.
Le VPN se connecte, l’interface affiche une adresse avec un masque de trente-deux bits, et le serveur du bureau reste injoignable. L’étape suivante consiste souvent à réutiliser ce masque dans une route, en supposant que l’interface décrit ce que le tunnel peut atteindre. Ce n’est pas le cas. Cette adresse décrit l’extrémité locale d’une liaison point à point, et la destination qui vous intéresse se trouve dans un autre préfixe de l’autre côté.
Deux choses différentes sont confondues : l’adresse que le tunnel vous a donnée, et le réseau auquel vous voulez accéder par son intermédiaire.
Deux adresses, deux rôles
Sur un tunnel point à point, l’adresse du client est souvent une adresse d’hôte unique, car il y a exactement un pair à l’autre extrémité de la liaison. Il n’y a ni segment partagé ni ARP, donc un masque qui paraîtrait absurde sur Ethernet est ici parfaitement normal.
Le préfixe de destination est un fait sur le réseau du bureau, pas sur le tunnel. Si vous avez besoin d’un serveur, la route est une route d’hôte pour ce serveur. Si vous avez besoin de tout le sous-réseau du bureau, la route est le sous-réseau. Aucune des deux réponses ne se lit sur l’interface, et en choisir une parce qu’elle apparaissait à côté de l’adresse du tunnel, c’est ainsi qu’une configuration qui fonctionne se casse.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
Cette troisième ligne est l’endroit où l’optimisme devient une panne. Acheminer toute une plage privée dans un tunnel qui ne dessert qu’un seul site pousse du trafic sans rapport vers un chemin qui ne peut pas le livrer, et les échecs qui en résultent ressemblent à un VPN cassé plutôt qu’à une route trop large.
Choisissez le préfixe à partir de l’exigence
Écrivez l’exigence sous forme de phrase avant de toucher à un profil : quels hôtes doivent être joignables, et quel est le préfixe le plus étroit qui les couvre ? Un seul serveur est une route d’hôte. Un sous-réseau est une route de sous-réseau. Une plage de sous-réseaux est un résumé, et un résumé est une promesse que chaque adresse à l’intérieur est joignable, ce qui est rarement vrai.
Vérifiez ensuite le nombre par rapport à ce que le bureau utilise réellement. Copier un préfixe depuis un message de chat sans le confirmer avec le plan d’adressage du site, c’est ainsi qu’une route finit par pointer vers un sous-réseau que personne ne possède.
Rappelez-vous aussi qu’une route est un chemin, pas une autorisation. La passerelle décide toujours si votre client peut utiliser la destination, et un service peut encore vous refuser. Installer correctement la route fait arriver le paquet et ne répond rien sur l’autorisation.
Ajoutez au profil, ne le remplacez jamais
Les routes d’un profil NetworkManager sont une propriété à valeurs multiples, et la différence entre définir et ajouter tient à un caractère. Utilisez la forme avec plus pour ajouter une entrée et conserver tout ce qui est déjà enregistré.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"Sans le plus, l’affectation remplace toute la liste. Sur un profil qui porte déjà plusieurs préfixes, cela supprime silencieusement ceux qui fonctionnaient, et le symptôme arrive plus tard sous la forme d’un service autrefois joignable depuis ce portable.
Utilisez l’UUID plutôt que le nom. Les noms sont dupliqués après les restaurations, et la connexion que vous modifiez n’est peut-être pas celle qui porte votre trafic. Vérifiez d’abord s’il existe déjà une entrée identique, car ajouter un doublon est désordonné même lorsque c’est inoffensif.
La référence des propriétés de route documente la destination, le prochain saut facultatif, la métrique et la syntaxe des attributs pour la version installée. Lisez-la avant d’ajouter un prochain saut, car sa nécessité dépend de l’intégration et de la topologie, et la deviner à partir de la première adresse d’une liste d’interfaces n’est pas une méthode.
La route par défaut et le DNS sont des décisions distinctes
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
Les routes automatiques sont l’autre chose qu’il ne faut pas déranger à la légère. Les supprimer pour résoudre une entrée manquante peut en retirer plusieurs qui fonctionnent, et la personne qui l’a suggéré regardait généralement un autre profil avec d’autres push.
Le DNS a son propre chemin et ses propres défaillances. Un nom qui se résout vers la bonne adresse via le mauvais résolveur, ou un résolveur qui ne peut pas répondre pour la zone privée, ressemblera à un problème de routage alors que la route est parfaite. Testez l’adresse et le nom séparément, puis décidez quelle couche a réellement échoué.
Vérifiez ce qui a été appliqué
Une modification enregistrée n’est pas une modification appliquée. Reconnectez-vous via le cycle de vie pris en charge du gestionnaire, puis regardez la route réelle vers la destination visée et les règles de politique qui décident quelle table est consultée.
Si le préfixe est présent et que la connexion échoue toujours, vous êtes passé à un autre problème : sélection de l’adresse source, route de retour à l’extrémité distante, ou service qui refuse votre client. Chacun d’eux est un meilleur endroit où regarder que le profil que vous avez déjà corrigé.