Pourquoi une route VPN n'affiche aucune passerelle dans la sortie de ip route

Les tables de routage sont lues comme cassées chaque fois que la colonne passerelle reste vide, alors que la ligne est généralement complète en elle-même. Le champ via n'apparaît que lorsque le noyau remet le paquet à une adresse de saut suivant ; une route attachée à une interface atteint ses destinations par résolution de couche de liaison ou par un homologue point à point. Lire les colonnes de gauche à droite vous dit dans quel cas vous êtes, et cette lecture devrait avoir lieu avant que quiconque modifie une route par défaut. La plupart des tickets sur une passerelle manquante se terminent sur cette distinction.

Lire une ligne de route colonne par colonne

Chaque entrée commence par la destination et la longueur de son préfixe, puis ajoute des modificateurs dans un vocabulaire fixe : via, dev, proto, scope, src et metric. Une ligne comme 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 est dense mais entièrement spécifiée. Rien n'y manque, et aucune adresse de routeur n'est sous-entendue.

L'absence de via est la partie intéressante. Sans saut suivant, le noyau résout la destination directement sur l'interface nommée, ce qui, pour un tunnel, signifie remettre la trame au périphérique de tunnel et laisser l'encapsulation prendre le relais à partir de là. proto kernel consigne que l'entrée a été installée automatiquement lors de l'attribution d'une adresse, et non saisie par un administrateur. scope link indique que la destination est joignable sur ce lien sans passer par un routeur, et src nomme l'adresse que le noyau préférera comme source pour le trafic correspondant.

Lisez maintenant une route par défaut de la même manière : default via 192.0.2.254 dev eth0 proto static metric 100. Ici, via est présent parce que le paquet a bien besoin d'un saut suivant, et ce saut doit lui-même être joignable sur eth0. Les deux lignes ne sont pas des variantes l'une de l'autre ; elles répondent à des questions différentes sur la destination du trafic.

Deux formes de route que l'on confond

Une route de sous-réseau de tunnel et une route par défaut se ressemblent sur une capture d'écran et se comportent tout à fait différemment. Utilisez le tableau ci-dessous comme aide à la lecture des champs, puis confirmez les chiffres réels sur la machine que vous déboguez plutôt que de faire confiance à un exemple de guide.

Ce que le tableau ne peut pas vous dire, c'est l'intention. Une route directe vers une plage privée à travers un tunnel est une conception délibérée de tunnel fractionné ; la même forme sur un hôte qui devrait tout envoyer par le VPN est un symptôme. L'intention vit dans la configuration qui a produit l'entrée, alors regardez l'outil qui l'a installée avant de conclure que le noyau s'est trompé.

De même, une passerelle manquante n'est pas la permission d'en inventer une. Si une route a réellement besoin d'un saut suivant, ce saut doit être joignable sur l'interface qui le porte, et pour un tunnel point à point l'adresse de l'homologue n'est pas le même objet que l'adresse locale. Traiter l'adresse locale du tunnel comme un routeur Ethernet est un moyen courant de produire une route qui semble correcte et ne transmet rien.

Demandez au noyau quelle ligne il va réellement utiliser

Lire la table n'est pas la même chose qu'effectuer la recherche, car le noyau consulte des règles de politique, plusieurs tables et des entrées en cache avant de répondre. Le verbe qui effectue la vraie recherche est ip route get, et il affiche la route qu'un paquet avec ces propriétés emprunterait.

ip route get 203.0.113.37 from 198.51.100.2 iif tun0

Remplacez par la destination qui vous intéresse vraiment, puis ajoutez from ou iif lorsque le trafic est sélectionné à la source ou transmis, car une recherche locale ordinaire peut choisir un chemin différent de celui d'un client transmis. La réponse nomme l'interface, l'adresse source choisie et tout saut suivant, ce qui est la même information avec laquelle un paquet serait routé à cet instant.

Si la réponse vous surprend, affichez les règles avant de modifier quoi que ce soit : ip -4 rule show les liste par ordre de priorité, et un client VPN qui installe sa propre table ou une règle pour les paquets marqués n'apparaîtra pas du tout dans la table principale. Lister toutes les tables comble cette lacune.

ip -4 route show table all | grep -E 'tun|default'

Vérifiez la couche sous-jacente avant de remplacer la route par défaut

Les paquets du tunnel lui-même doivent atteindre le point de terminaison distant, et ils le font par l'interface physique en utilisant la route qui existait avant la montée du VPN. Remplacer toute la route par défaut sans épingler ce point de terminaison envoie les paquets encapsulés dans le tunnel qu'ils sont censés construire, et la connexion s'effondre. Confirmez d'abord le chemin vers le point de terminaison par une recherche sur sa seule adresse.

Gardez trois choses séparées lorsque vous faites le changement : la route du point de terminaison qui doit rester sur l'interface physique, les plages privées qui devraient entrer dans le tunnel, et la route par défaut qui décide de tout le reste. Séparez-les dans cet ordre, appliquez-en une à la fois et relancez la recherche après chaque étape. Un ping qui échoue ensuite ne prouve pas grand-chose à lui seul, car les permissions, le routage des réponses, le DNS et le service lui-même se situent tous en aval d'une route correcte.

Notez les quatre valeurs que la ligne vous a données avant la modification : destination, saut suivant ou son absence, périphérique et source choisie. Si un changement ultérieur déplace l'une d'elles, vous savez quelle décision a réellement été modifiée, et vous pouvez restaurer une entrée au lieu de deviner toute la table.