Saut suivant d’une route VPN : pourquoi la passerelle doit être joignable localement

Une route vers un réseau VPN porte deux adresses faciles à confondre : le préfixe de destination que le paquet cherche à atteindre et le saut suivant qui le rapproche d’un cran. Sur un hôte de LAN, ce saut suivant doit être un routeur que vous pouvez réellement joindre sur le même lien. L’adresse VPN distante n’est pas un saut suivant, si bien ajustée soit-elle à la destination que vous avez en tête.

Ce guide couvre le cas ordinaire : un ordinateur portable sur 192.168.20.0/24, une passerelle VPN dont l’adresse LAN est 192.168.20.5 et un réseau distant 10.70.0.0/24 derrière cette passerelle. Toutes les commandes ci-dessous supposent que vous êtes sur l’ordinateur portable, sauf indication contraire.

Deux adresses, une route

L’entrée visée est 10.70.0.0/24 via 192.168.20.5. Le préfixe indique où va le paquet ; l’adresse via indique qui le porte jusque-là. Le noyau refuse d’installer une route dont il ne peut pas joindre la passerelle par l’interface que vous nommez, et ce refus est tout l’intérêt : un saut suivant qui a besoin du tunnel pour être joignable ne peut pas être le saut suivant qui construit le tunnel.

Le premier contrôle n’est donc pas « la passerelle répond-elle » mais « la passerelle est-elle sur ce lien ». Le sous-réseau propre de l’ordinateur portable, son entrée ARP ou de voisin, et l’interface de la route doivent tous concorder. Une adresse qui n’existe qu’à l’intérieur de 10.70.0.0/24 peut être la destination d’une seconde route, jamais l’adresse via de la première.

Ce que le saut suivant impose à la passerelle

Installer la route sur l’ordinateur portable ne décide que de la première remise. La passerelle a ensuite besoin de son propre chemin : transfert activé, une route de tunnel pour 10.70.0.0/24 et toute politique d’accès qui régit qui peut l’utiliser. Sous Linux, c’est net.ipv4.ip_forward=1 plus une route de tunnel ; un pare-feu devant elle a besoin d’une règle qui autorise le flux transféré.

La direction du retour est la partie que les gens oublient. Le côté distant doit avoir une route de retour vers 192.168.20.0/24, ou la conception doit traduire la source de l’ordinateur portable en quelque chose que le côté distant connaît. Un ping qui fonctionne depuis la passerelle prouve que la passerelle atteint le réseau distant ; il ne dit rien sur la survie des paquets de l’ordinateur portable au voyage de retour.

Vérifiez la recherche depuis l’hôte qui envoie

Demandez au noyau quel saut suivant il choisirait, et lisez l’interface dans la réponse :

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Si la recherche signale la passerelle et l’interface LAN, le premier tronçon est configuré comme prévu. Si elle signale le périphérique de tunnel, quelque chose de plus haut dans la table est plus spécifique et l’emporte. Si la route refuse de s’installer, le noyau vous dit que la passerelle est injoignable, et ce message est plus utile que n’importe quelle capture de paquets.

Répétez ensuite le test depuis le bon endroit. Une requête créée sur la passerelle utilise l’adresse source propre de la passerelle, ce qui peut masquer une route de retour manquante ou une politique qui n’autorise que certaines sources. Le manuel d’ip-route sépare la destination, la passerelle et la dérogation onlink, et la dérogation mérite d’être comprise avant d’être utilisée.

N’utilisez pas onlink pour simuler la joignabilité

onlink dit au noyau de sauter le contrôle de joignabilité d’une passerelle et d’y envoyer quand même. Il ne crée pas de chemin, ne résout pas l’ARP d’une adresse absente et ne fait pas répondre un routeur distant sur votre segment Ethernet. Il est légitime pour des passerelles qui répondent mais ne se trouvent pas dans un sous-réseau connecté, et c’est un piège lorsqu’il sert à faire taire une erreur que vous n’avez pas expliquée.

Si la route ne s’installe qu’avec onlink, la question suivante est pourquoi la passerelle n’est pas là où vous croyez. Un mauvais VLAN, une seconde adresse sur la mauvaise interface ou une faute de frappe dans le dernier octet produisent tous cela, et chacun d’eux casse aussi le chemin de retour dès que le trafic commence à circuler.

Les tunnels point à point ne sont pas Ethernet

Un périphérique de tunnel ne fait pas d’ARP et n’a souvent pas de sous-réseau de voisins digne de ce nom. Ses routes ressemblent souvent à 10.70.0.0/24 dev tun0, sans aucun via, car le pair est l’unique autre extrémité. Copier une adresse via de style LAN dans cette table produit une route que le noyau peut rejeter ou, pire, qui pointe vers une adresse à laquelle le pair ne répond jamais.

Gardez les deux modèles séparés dans le guide : une route LAN a une passerelle joignable, une route de tunnel a une interface et un pair. WireGuard, OpenVPN et IPsec exposent tous des formes légèrement différentes, alors notez la forme que vous avez réellement utilisée au lieu de généraliser depuis un seul hôte.

Ajouter, confirmer, revenir en arrière

Le changement tient en trois commandes et un contrôle, et il devrait être écrit dans cet ordre :

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Confirmez le chemin, confirmez une destination, puis gardez la ligne de suppression prête au cas où le changement rendrait l’hôte injoignable d’une manière que vous n’aviez pas prévue. Si la route doit survivre à un redémarrage, placez-la dans la configuration réseau de l’hôte plutôt que dans un profil de shell, et testez le redémarrage avant de vous y fier. Une route qui n’existe que dans le shell qui l’a ajoutée est une route que vous déboguerez deux fois.