Adresse peer PPP ou extrémité VPN : laquelle va dans via

Une seule ligne sur une interface PPP tranche l’essentiel du débat de routage sur une machine VPN : l’adresse interne et le peer imprimé à côté. Lisez cette paire comme un minuscule sous-réseau et vous chercherez une passerelle qui n’existe pas. Lisez-la comme les deux extrémités d’un seul lien et le prochain saut devient évident. La comparaison ici porte sur ces deux lectures, car chaque table construite ensuite hérite de celle que vous avez choisie. Rien de l’extrémité VPN externe n’est décidé par l’une ou l’autre.

Deux lectures d’une même ligne d’interface

Prenez une session où l’interface rapporte inet 10.64.3.9 peer 10.64.3.1/32. La lecture en sous-réseau traite 10.64.3.9 comme un hôte isolé sur un îlot /32, puis cherche un routeur pour atteindre quoi que ce soit au-delà. Comme la seule autre adresse du lien est le peer, cette lecture finit par proposer 10.64.3.9 lui-même comme passerelle, ce qui est circulaire.

La lecture en extrémité est celle qui est documentée. Sur une interface point à point, peer nomme l’extrémité distante de ce lien unique, donc 10.64.3.1 est le prochain saut utilisable et 10.64.3.9 n’est jamais qu’une adresse source.

Cette différence régit ce qui peut figurer dans via. Y écrire l’adresse locale produit une route que le noyau ne peut pas résoudre vers un voisin, si bien que l’entrée échoue à la validation ou engloutit le trafic tout en paraissant parfaitement saine dans un listing. Le peer fonctionne parce qu’il est une destination réelle sur le lien. Les deux lectures s’accordent sur l’extrémité VPN externe, qui est une identité entièrement séparée : on l’atteint par l’underlay, pas par le tunnel qu’il termine.

Ce que la session a déjà installé

Avant d’écrire la moindre table personnelle, imprimez ce qui est venu avec le lien. Une intégration PPP prise en charge installe généralement une route de périphérique et une route de peer lors de la mise en place de la session, et ces deux entrées encodent déjà la bonne lecture.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Une route de périphérique comme 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 ne porte aucune passerelle parce que l’interface elle-même est le chemin. Une route qui nomme le peer avec via est un autre objet, avec une autre durée de vie, et elle disparaît quand la session tombe. Copier l’une ou l’autre forme dans une table persistante sans vérifier comment elle est réinstallée est la raison habituelle pour laquelle un tunnel qui fonctionnait perd sa route après une reconnexion.

Comparez les deux listages plutôt que de vous fier à la mémoire. Si la route du peer existe dans main mais que votre table supplémentaire est vide, vous avez appris quelque chose que la ligne d’adresse ne vous avait jamais dit.

Une règle et une table sont deux décisions distinctes

Choisir une table et la remplir sont des étapes indépendantes, et la comparaison compte ici parce que les deux sont souvent confondues en débogage. Une règle qui envoie le trafic marqué vers la table 100 ne fait rien si la table 100 n’a pas de route correspondante, et une table bien remplie est inatteignable si aucune règle ne pointe vers elle.

Une demi-route par défaut n’est pas une route par défaut. Un seul 0.0.0.0/1 couvre la moitié basse de l’espace IPv4, donc une politique qui veut tout capturer a aussi besoin du 128.0.0.0/1 correspondant, ou d’une véritable default. Lire une configuration qui fonctionne et copier l’une des deux moitiés, c’est ainsi que les gens finissent avec une boucle de routage qui ne casse que sur certaines destinations.

Laissez des exceptions délibérées pour les adresses qui doivent rester sur le LAN, et décidez de ce qui se passe quand la recherche ne trouve rien dans la table choisie. Une route de repli explicite est plus facile à raisonner qu’une table vide, qui renvoie un résultat inatteignable et fait paraître l’application cassée plutôt que mal routée.

Posez à la recherche la question que pose votre application

ip route get résout un chemin ; ip route show liste les entrées stockées, et les deux peuvent diverger sans qu’aucune soit fausse. Incluez le contexte de source, car les règles fondées sur la source ne correspondent que lorsque la recherche transporte une source.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

La première commande pose la question depuis l’hôte. La seconde ajoute une interface d’entrée, ce qui est plus proche de ce que vit le trafic transféré, et la réponse pointe souvent vers une autre table. Aucune des destinations n’est un service de test en direct ; 198.51.100.23 est une adresse de documentation, remplacez-la donc par un hôte que vous êtes autorisé à sonder.

Même une recherche correcte ne prouve qu’un chemin a été choisi. Elle ne dit rien sur le fait que l’autre côté accepte le trafic ni sur la possibilité que la réponse revienne par le même raisonnement.

Où la comparaison s’inverse

Le trafic de l’hôte et le trafic transféré ne prennent pas seulement des recherches différentes ; ils rencontrent des filtres différents au retour. Linux applique la validation de chemin inverse en retenant le plus strict des réglages de toutes les interfaces et de l’interface réceptrice, si bien que changer la valeur d’une interface peut n’avoir aucun effet visible. Le routage fondé sur les marques ajoute la relation src_valid_mark, où la marque doit correspondre pour qu’une source soit jugée valide.

Si les réponses disparaissent alors que le routage sortant semble correct, lisez les valeurs effectives avant d’y toucher, et ne les changez qu’avec une raison de politique énoncée.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Choisissez entre les deux conceptions sur preuve : si l’application se lie à l’adresse PPP, une règle de source plus une table contenant la route du peer suffisent. Si la machine transfère pour un LAN derrière elle, il faut en plus que le contexte d’entrée et le chemin de retour s’accordent. Quand ils ne s’accordent pas, corrigez la propriété de la route plutôt que d’assouplir la validation pour toute la machine.