Ce qu’une table de routage VPN vous dit et ce qu’elle ne peut pas dire

Vous vous connectez, lancez une liste de routes et voyez un sous-réseau dont vous n’avez jamais entendu parler pointer vers le tunnel. Cette ligne affirme une chose avec précision et plusieurs autres pas du tout. Elle consigne comment cette machine transférera les paquets vers ce préfixe, rien sur les hôtes qui existent là-bas, et rien sur ce que votre compte peut atteindre. La lire correctement prend une minute ; la lire comme un inventaire prend bien plus longtemps à désapprendre.

Lisez la table comme des instructions locales

Une route est une instruction de transfert tenue par le noyau local : pour ce préfixe, utilisez cette interface et ce prochain saut. La longueur du préfixe décide de la précision de l’instruction, et la correspondance la plus longue l’emporte. Rien dans cette règle ne mentionne les autorisations, l’état du service ni la topologie distante.

Les règles de politique peuvent intervenir avant que la table soit consultée, et c’est pourquoi une route peut exister sans être celle qu’utilise un paquet donné. Lisez les règles à côté de la table, puis demandez au noyau quel chemin il choisirait pour une destination précise. La réponse pour une adresse vaut plus qu’une page de préfixes, et c’est la seule réponse qui reflète les marques, les espaces de noms et les liaisons d’interface que le client a appliqués.

Un préfixe large n’est pas un catalogue

Un /16 routé par le tunnel ne signifie pas seize mille hôtes joignables, et une route par défaut signifie encore moins. Le serveur décide qui répond, le pare-feu décide ce qui est permis et le compte décide ce qui est autorisé.

Une table étroite a le piège inverse : un préfixe absent peut signifier que la destination est joignable par un autre chemin, ou simplement qu’elle n’est pas routée du tout. Ces deux cas se ressemblent jusqu’à ce que vous les testiez. Comparez la table à la ressource que l’on vous a dit d’utiliser, pas à vos attentes de ce qu’un VPN devrait contenir.

D’où viennent les entrées

Les routes arrivent d’au moins quatre endroits : le fichier de configuration, le serveur qui pousse une route pendant l’établissement de la connexion, un gestionnaire de réseau qui possède l’interface, et une personne qui tape une commande pendant un incident. Chacun a une durée de vie différente et un propriétaire différent.

Celle tapée pendant une panne est celle qui disparaît au redémarrage et n’apparaît dans la documentation de personne. Une route poussée par le serveur change quand le serveur change, ce qui explique qu’un nouveau préfixe inexpliqué apparaisse souvent après une mise à jour de la passerelle plutôt qu’après un changement du client. Le manuel ip-route documente la syntaxe de la table et des champs si vous devez lire les indicateurs.

Vérifiez la route par rapport au contrat de service

La comparaison utile est entre la table et le service qui vous a été promis : nom, portée des adresses, port et propriétaire. Écrivez ces quatre éléments à côté du préfixe et les écarts deviennent visibles.

ip route show table all dev tun0
ip route get 10.20.5.9
ip rule show

Si le préfixe est présent et que le service échoue toujours, la table a fait son travail et le problème est ailleurs : résolution de noms, un pare-feu de l’autre côté, ou un compte sans le bon groupe. Si le préfixe manque, la question est de savoir qui aurait dû le fournir, pas ce qu’il faut taper. L’une ou l’autre réponse nomme une équipe à qui demander ensuite, et c’est la seule sortie utile de la lecture d’une table de routage. Notez ce nom avant de fermer le terminal.

Consignez l’avant et l’après de tout changement, avec la date et l’interface. Une table de routage est un instantané d’un moment sur une machine, et elle ne devient une preuve que lorsque quelqu’un a noté quand elle a été prise.