Les clients du LAN ignorent le VPN du routeur tant que le routage par politiques n'est pas actif

Le routeur atteint Internet par son tunnel, tandis qu'un portable derrière lui annonce toujours l'adresse du FAI. Ajouter des règles d'acceptation ne change rien, et cet échec est instructif : le filtrage répond si un paquet peut passer, pas où il va. Le choix de l'interface a déjà été fait par une consultation de routage qui ignore tout de votre liste de clients. Corrigez la consultation et le pare-feu cesse d'être le suspect.

Une règle de filtrage ne peut pas choisir une interface

Le flux de paquets sur un routeur Linux exécute d'abord la décision de routage, puis le crochet de transfert. Au moment où une règle correspond au périphérique de tunnel sortant, le noyau a déjà décidé que le tunnel est la sortie. Si la table principale préfère encore la route par défaut de la WAN, le paquet part vers le FAI et la règle d'acceptation que vous venez d'écrire ne le voit jamais. Ce seul fait d'ordre explique pourquoi une page de nouvelles règles de pare-feu ne change rien.

L'exemple ci-dessous utilise un LAN de 192.168.8.0/24 sur br-lan, un périphérique de tunnel tun0 et un décodeur à 192.168.8.23 qui devrait emprunter le tunnel.

Lisez la consultation avant de modifier des règles

Demandez au noyau de résoudre une route pour ce client. La réponse indique le périphérique de sortie et l'adresse source qui serait choisie, tout ce qu'il faut pour confirmer le diagnostic. Si la réponse nomme le périphérique WAN, le paquet n'a jamais eu la moindre chance d'atteindre votre règle.

ip -4 route get 198.51.100.7 from 192.168.8.23

Répétez la requête pour un client qui doit rester sur le chemin ordinaire. Quand les deux réponses nomment le même périphérique, aucune politique par source n'est encore en jeu, et la correction relève du routage plutôt que du filtrage.

Associez une table aux clients que vous voulez couvrir

Le routage par politiques insère une consultation de règles avant la table principale. Construisez une table dont la route par défaut est le tunnel, puis liez cette table à un sélecteur : une interface d'entrée, une adresse source ou une marque de pare-feu. Les priorités décident de l'ordre, et la table principale se trouve très bas dans la liste, à 32766, si bien qu'une règle à numéro faible est consultée d'abord. Les sélecteurs d'interface couvrent chaque client du pont ; les sélecteurs d'adresse couvrent une machine.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

Les interfaces du micrologiciel exposent souvent les mêmes objets qu'une page de routage par politiques ou de politique VPN. Une liste d'appareils y est plus facile à maintenir que des règles écrites à la main et survit généralement aux mises à jour qui changent la syntaxe des règles.

Choisissez le sélecteur à dessein. Une règle d'interface est courte et pérenne, mais elle capte aussi le trafic de gestion du routeur lui-même qui arrive sur ce pont. Une règle de source est exacte et demande une modification dès que la liste d'appareils change. Notez le choix, car la prochaine personne qui demandera pourquoi un appareil se comporte différemment en aura besoin.

Gardez les destinations locales hors du tunnel

Une table neuve ne connaît que les routes que vous y mettez. Le préfixe du LAN manque, donc le trafic de l'imprimante et du NAS suivrait la route par défaut du tunnel et disparaîtrait. Une route throw termine la consultation dans cette table et rend la décision à la table principale.

ip -4 route add throw 192.168.8.0/24 table 200

Sautez cette route et les partages locaux cassent, et la session de gestion du routeur lui-même peut disparaître si le sélecteur est plus large que prévu. Réglez ensuite la question de la source : les paquets du tunnel qui portent encore des adresses du LAN ont besoin que l'autre côté connaisse un chemin de retour, tandis que le masquerading sur le tunnel supprime cette exigence et supprime aussi l'identité du client que l'autre côté verrait.

Les règles et routes ajoutées à l'exécution disparaissent après un redémarrage ou une mise à jour du micrologiciel. Ajoutez-les au mécanisme de démarrage du routeur, redémarrez une fois et retestez depuis le client : son adresse publique, un second client qui doit rester sur la WAN et les compteurs du tunnel lors d'une nouvelle connexion.