VPN Pi multi-routeurs : mettez chaque route sur l'appareil qui décide

Placer une box Wi-Fi derrière le Pi transforme une décision de routage en quatre, et le plan casse quand les quatre sont prises sur un seul appareil. La première question n'est pas quelle route ajouter. C'est de savoir si la nouvelle box fait pont ou route, car cette réponse décide combien de sous-réseaux existent et quels appareils doivent en apprendre l'existence. Choisissez d'abord le modèle de raccordement ; chaque route en découle.

Pont ou routage : le choix qui fixe le nombre

Un pont place les nouveaux clients sur le même sous-réseau que le Pi sert déjà. Un sous-réseau, une autorité DHCP et aucun relais à router. C'est l'arrangement le plus simple et le bon quand un réseau client séparé n'a jamais été une exigence. Une liaison routée est une autre conception : la box garde son propre sous-réseau, et ce préfixe doit être porté partout où va le trafic.

Le reste de ce plan garde le routeur en aval et préserve les adresses source des clients. La cible est un réseau VPN privé, pas une sortie internet complète. Écrivez le modèle avant les adresses, car la liste ci-dessous n'est qu'un exemple de raccordement routé.

client subnet       10.41.0.0/24
client gateway      10.41.0.1
router-to-Pi link   192.168.71.2
Pi on that link     192.168.71.1
private target      10.72.9.0/24

Qui décide quoi

Chaque appareil prend une décision, et aucun ne peut prendre celle d'un autre à sa place. Le Pi a besoin de deux entrées, pas d'une, et le chemin de retour est celui que les gens oublient. Le trafic transféré atteint correctement le réseau privé puis meurt au retour, parce que le Pi n'a aucune idée d'où vit 10.41.0.0/24. Cela ressemble à un problème de pare-feu et c'est en réalité une route manquante.

Le côté distant a aussi besoin de sa propre route. Si le service à l'autre bout ne sait pas que 10.41.0.0/24 est joignable par votre tunnel, les réponses s'arrêtent au premier saut qui n'a pas de réponse. Ajoutez les deux directions avant de lire les filtres de paquets.

Les sauts suivants viennent du raccordement

Un saut suivant doit être une adresse sur un réseau que l'appareil peut réellement atteindre. L'adresse publique du pair VPN n'est pas le saut suivant d'un sous-réseau privé, et le réseau de service distant n'est pas du tout un saut suivant. Une route vers une passerelle injoignable paraît correcte dans une liste et jette chaque paquet. Vérifiez que la passerelle répond avant d'accuser la destination.

Gardez le pair VPN externe du Pi joignable par sa propre route de sous-couche. Cette entrée est distincte des routes de charge utile, et les mélanger donne un tunnel qui ne peut pas se rétablir après un changement de chemin.

La documentation des routes statiques clarifie la distinction entre destination et passerelle, même si chaque plateforme nomme ses menus différemment. Lisez la documentation de l'appareil devant vous plutôt que de copier l'écran d'un autre fournisseur. Les commandes ci-dessous montrent la forme des entrées sous Linux.

# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1

Ce que la traduction fait à la source

Si le routeur en aval traduit déjà ses clients vers l'adresse de transit, le Pi voit une seule source traduite au lieu de l'adresse propre de chaque client. C'est une conception différente de celle qui préserve la source ci-dessus. Elle change la politique fondée sur la source, la journalisation et le côté qui peut initier les connexions. Les deux conceptions fonctionnent ; elles répondent à des questions différentes.

Quand un service VPN en amont refuse de router le préfixe client vers l'arrière, une traduction étroite à la sortie du tunnel du Pi peut être un contournement légitime. Ce n'est pas la preuve que la route manquante était inutile. Notez quelle adresse le réseau distant voit réellement et quel chemin de retour en résulte.

La sélection de route, l'autorisation de transfert et la traduction de source restent trois tâches distinctes. Vider une chaîne NAT partagée ou autoriser chaque interface parce qu'un client filaire fonctionne est la façon dont un test qui marche devient un redirecteur ouvert.

Le prouver depuis une machine cliente

Envoyez une requête depuis une machine du LAN en aval, puis suivez sa source à l'aller et au retour. Un ping émis par le Pi n'exerce jamais la route de retour en aval, c'est pourquoi un ping réussi prouve moins qu'il n'y paraît. Ajoutez un second test depuis un client filaire sur le LAN propre du Pi pour que les deux chemins puissent être comparés. Répétez les deux après avoir redémarré l'un ou l'autre appareil.

Les routes ajoutées à la main et les traductions qui n'ont jamais été persistées disparaissent ensemble. La paire ressemble alors à une nouvelle panne plutôt qu'à un travail inachevé.

Enregistrez le modèle de raccordement avec les routes, le service privé autorisé et toute traduction dans une seule note. C'est cette note qui empêche la personne suivante de traiter le placement sans fil comme une question de politique de routage.