Routeur LAN et client VPN : deux appareils, deux tables de routage

Deux appareils transfèrent le paquet et chacun tient sa propre table. Le routeur LAN sait que le préfixe distant appartient au client VPN, et le client VPN sait comment joindre ce préfixe par son tunnel. Configurez seulement la première table et le paquet arrive sur une machine qui n’a aucune route correspondante, puis il repart par la route par défaut. C’est toute la panne, et vu du LAN cela ressemble à une boucle de routage, parce que c’en est presque une.

Dessinez les deux sauts avant de toucher à une route

Prenez une disposition illustrative : hôtes du LAN sur 192.168.50.0/24, le routeur ordinaire sur 192.168.50.1, un client dédié sur 192.168.50.15, et un LAN distant sur 10.60.0.0/24 joignable uniquement par le tunnel que détient ce client. Aucune des deux plages privées ne chevauche l’autre, et le tunnel a son propre plan d’adressage.

Les deux plages privées comptent parce qu’elles décident quel appareil peut répondre. Le côté distant verra le paquet arriver depuis l’adresse de tunnel du client, et sa réponse doit trouver un chemin de retour vers 192.168.50.0/24. Si seul le sens sortant est configuré, la requête peut fonctionner tandis que la réponse disparaît.

Étape 1 : pointez le routeur vers le client, pas vers le tunnel

Sur le routeur LAN, ajoutez une route de destination dont le saut suivant est l’adresse LAN du client :

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Cet enregistrement dit « livrez-le à la machine qui sait faire du tunnel ». Il ne dit rien sur la façon dont le tunnel est construit et ne remplace pas la route propre du client. Sur un routeur géré, l’équivalent vit dans la page des routes statiques de l’appareil ; sur un routeur Linux, il appartient à la configuration de l’interface qui possède le LAN, pas à un shell que vous fermerez.

Vérifiez la réponse de la seconde commande. Si elle indique le client comme gateway et l’interface LAN comme device, le premier saut est correct et le travail restant se trouve sur l’autre machine.

Étape 2 : donnez au client sa propre route côté tunnel

Le client reçoit maintenant un paquet pour 10.60.0.0/24 et consulte sa propre table. Si sa configuration de tunnel a installé une route pour ce préfixe, le paquet continue chiffré. Sinon, le paquet correspond à la route par défaut ordinaire et repart vers 192.168.50.1, qui le renvoie au client.

Regardez avant d’ajouter quoi que ce soit :

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Une route de préfixe absente dans toutes les tables est la trouvaille que vous cherchez. Ajoutez-la par la configuration propre du tunnel, pour que la prochaine reconnexion la réinstalle ; une ip route add manuelle disparaît avec la session et fait revenir la panne au moment le plus gênant. Le saut suivant est l’interface de tunnel ou l’adresse que le VPN attribue comme pair, selon le client, et l’adresse du pair devrait venir du profil actuel plutôt que d’une note ancienne.

La boucle, quand elle survient, n’est pas infinie en pratique : le TTL baisse à chaque passage et le paquet meurt avec un message de temps dépassé. C’est pourquoi un traceroute répété peut suggérer un cycle alors qu’un client qui ne transfère simplement pas laisse tomber le même paquet en silence.

Étape 3 : autorisez le transfert et choisissez la route de retour

Recevoir et transférer sont des permissions différentes. net.ipv4.ip_forward=1 sur le client autorise le transit au niveau du noyau, et une règle de pare-feu doit encore l’autoriser entre l’interface LAN et le tunnel. Une règle qui autorise l’accès à la page d’administration du client n’autorisera pas le transit vers le LAN distant, et la distinction est facile à manquer quand le même hôte répond aux pings en local.

Le côté distant a le problème miroir. Il doit savoir que 192.168.50.0/24 est joignable par ce client authentifié. Avec OpenVPN cela signifie généralement une route par client poussée par la configuration du serveur, ou un fichier propre au client sur le serveur qui déclare le LAN derrière le client. Sans cela, le LAN distant soit rejette la réponse, soit l’envoie vers sa propre passerelle par défaut, c’est-à-dire Internet.

La traduction de source est l’alternative quand le préfixe du LAN ne peut pas être annoncé. Une règle de masquerade ciblée sur le client réécrit la source vers l’adresse du tunnel, et les réponses reviennent alors naturellement. Elle masque aussi quel hôte du LAN a fait la requête, et elle ne permet pas à elle seule au côté distant d’initier des connexions vers l’intérieur. Choisissez ce compromis délibérément plutôt que d’ajouter un masquerade global et de découvrir l’effet secondaire plus tard.

Étape 4 : rendez les deux décisions persistantes, puis testez le vrai chemin

Chaque route a un propriétaire, et le propriétaire est la configuration qui se régénère au démarrage ou à la reconnexion. Sur le routeur, cela peut être une entrée de route statique ; sur le client, cela peut être le profil VPN, NetworkManager ou systemd-networkd. Vérifiez en reconnectant le tunnel et en redémarrant le client, puis relisez la table au lieu de faire confiance à la modification.

Gardez intacte la route par défaut qui porte la connexion extérieure du tunnel. La remplacer pour « simplifier » l’installation casse le chemin chiffré avant que le moindre trafic intérieur puisse l’utiliser, et le symptôme est un tunnel qui ne se rétablit jamais après le changement.

Testez depuis un hôte LAN ordinaire, pas depuis le client, car une requête émise sur le client n’exerce jamais le premier saut du routeur. Récupérez un service qui n’existe que sur le LAN distant et confirmez le corps de la réponse, puis regardez les compteurs ou les journaux du client pour voir le transit se produire. Un traceroute intérieur qui montre des sauts privés prouve le transfert, pas le chiffrement : le chemin extérieur est une observation séparée, et seuls les compteurs de l’interface du tunnel montrent ce qui en est sorti.