Un appareil via un VPN du routeur exige trois règles, pas un interrupteur

Sur un VPN du routeur, il n’y a pas d’interrupteur par appareil ; l’interrupteur que vous cherchez est un raccourci qui écrit des règles de routage par politique à votre place. Dès qu’un portable, une plage de ports, une liste d’adresses ou un segment LAN doit passer par le tunnel pendant que tout le reste reste sur le WAN, vous construisez une route de politique, vous n’activez pas une fonction. Le travail comporte trois pièces mobiles, et chacune échoue différemment : une table marquée sans route ressemble au silence, une marque appliquée dans la mauvaise chaîne donne l’impression que rien ne s’est passé, et une règle NAT manquante ressemble à un tunnel qui se connecte et ne transporte rien. Deux autres pièces manquent parce qu’elles n’apparaissent jamais dans la règle mangle : le DNS et l’IPv6.

Le mythe : le tunnel est un réglage du client

Un client VPN côté routeur fait bien une chose brutale : il met 0.0.0.0/0 dans la table de routage principale et le pointe vers le tunnel. WireGuard le déduit d’AllowedIPs, OpenVPN d’un redirect-gateway poussé, et les deux changent le chemin de chaque hôte derrière le routeur. Resserrer AllowedIPs ou ajouter route-nopull change ce que le client installe. Cela ne change pas à qui s’applique l’installation, car le client ne voit jamais d’appareils. Il ne voit que des paquets.

Choisir par source ou par destination est une décision de routage, donc cela relève de la couche de politique du routeur : une règle mangle plus une seconde table sur RouterOS, un MARK plus une ip rule sur OpenWrt ou DD-WRT, ou une règle de pare-feu dont la passerelle est le tunnel sur pfSense. La recette de client WireGuard de Netgate est celle à lire avant de deviner, car sur cette plateforme la passerelle de la règle, l’affectation d’interface et l’entrée NAT sortante doivent toutes s’accorder avant qu’un seul client n’utilise le tunnel.

La seconde moitié du mythe, c’est le second routeur. Acheter une boîte de plus ou déplacer l’appareil sur un SSID invité fonctionne souvent, et la raison n’est pas le matériel : cela place l’appareil sur son propre sous-réseau, ce qui vous donne le sélecteur de source que le micrologiciel comprend déjà. Si vous pouvez définir ce segment sur le routeur que vous possédez, la boîte supplémentaire résout un problème que vous n’aviez pas.

Première pièce : un tunnel qui n’est pas la route par défaut

Sur RouterOS, ajoutez le client sans route par défaut et donnez au tunnel sa propre table. La première route est la route par défaut marquée ; la seconde est la moitié de l’échec.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

La route unreachable est la raison pour laquelle une table marquée bat une liste d’exceptions dans la table principale. Quand le tunnel tombe, les paquets marqués reçoivent un unreachable immédiat au lieu de retomber discrètement sur le WAN, si bien que la panne apparaît dans le message d’erreur de l’application et non sur une page de géolocalisation consultée une heure plus tard.

RouterOS 7 sépare ce que 6.x gardait ensemble : vous déclarez la table avec /routing table add name=vpn fib, puis vous y faites référence par son nom sur la route et dans la règle mangle. Un extrait 6.x qui pose routing-mark en ligne sans définir la table se charge proprement et ne correspond à rien. L’autre classique, ce sont deux moitiés 0.0.0.0/1, ou deux routes par défaut à la même distance dans une table : le noyau en choisit une, et le comportement peut changer après un redémarrage.

Deuxième pièce : marquer avant la consultation de route

Le sélecteur décide quels paquets entrent dans cette table. RouterOS commence généralement par une liste d’adresses pour la politique de destination, ou par une adresse source pour la politique d’appareil :

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Le micrologiciel Linux fait de même avec une marque netfilter et une règle qui dirige les paquets marqués vers une table que vous avez remplie :

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

La chaîne n’est pas un choix de style. Quand un paquet atteint FORWARD, la consultation de route a déjà eu lieu, donc un MARK ou un DROP à cet endroit ne peut que réécrire ou jeter. La marque doit tomber dans PREROUTING pour le trafic transmis et dans OUTPUT pour le trafic que le routeur origine, car c’est là que vivent le DNS, le NTP et les vérifications de mise à jour du routeur. C’est ce chemin de sortie qui explique d’ordinaire qu’une installation entièrement tunnélisée réponde encore depuis le résolveur du FAI lors d’un test de fuite.

La politique d’appareil exige une correspondance qui ne dérive pas. Réservez l’adresse dans le DHCP, ou faites correspondre une interface pour un segment dédié ; une adresse qui passe ensuite sur un autre appareil applique silencieusement le tunnel au mauvais client. Un pont par SSID avec son propre sous-réseau est la version plus durable de la même idée, et il donne aux règles IPv6 un endroit où vivre.

Troisième pièce : NAT, DNS et l’exception du LAN

Le trafic qui sort par le tunnel a besoin d’une adresse source à laquelle le côté distant répondra. Limitez la traduction à l’interface du tunnel : out-interface=VPN_NAME sur RouterOS, -o tun0 sous Linux, une entrée NAT sortante correspondante sur pfSense. Une règle masquerade sans cette portée réécrit du trafic que vous vouliez laisser tranquille, et le symptôme est que l’appareil non tunnélisé perd son adresse publique.

L’exception du LAN provoque plus de fils de support que le tunnel lui-même. Si la table marquée ne contient qu’une route par défaut, une destination imprimante ou NAS depuis l’appareil sélectionné correspond à cette route par défaut et disparaît dans le tunnel. Ajoutez la route LAN à la même table, ou excluez le sous-réseau local dans le sélecteur ; les deux fonctionnent, et l’exclusion est plus facile à garder correcte quand vous ajouterez des VLAN plus tard.

Le DNS prend un chemin séparé. Les requêtes que le routeur transmet proviennent du routeur et suivent OUTPUT, pas la marque de transmission, si bien qu’un portable entièrement tunnélisé peut encore résoudre via le FAI. Pointez les clients vers un résolveur joignable par le tunnel, ou marquez le trafic du port 53 du routeur lui-même, puis vérifiez l’adresse résolue au lieu de supposer que la réponse a voyagé avec la requête web.

Quand la règle correspond mais que l’application utilise encore le WAN

Les listes de destinations vieillissent mal. Un nom se résout en une adresse absente de la liste, donc la requête prend le WAN alors que chaque test effectué contre l’adresse listée fonctionnait. Rafraîchissez la liste depuis le même résolveur que le client, et préférez un sélecteur basé sur la source quand vous voulez vraiment tout le trafic d’un appareil.

IPv6 est le contournement silencieux. L’appareil possède une seconde famille d’adresses avec sa propre route par défaut et son propre jeu de règles, et ne faire correspondre que l’adresse IPv4 est une demi-politique. Appliquez le même sélecteur à ip6tables ou à l’équivalent nftables, ou désactivez IPv6 sur ce segment délibérément plutôt que par accident.

Les connexions établies comptent aussi. Une entrée conntrack créée avant la modification suit l’ancien chemin jusqu’à expiration, donc un navigateur resté ouvert pendant l’édition ressemble exactement à une règle qui n’a jamais été appliquée. Ouvrez une nouvelle connexion, ou videz l’état, avant de juger la politique.

Vérifiez avec deux appareils et un redémarrage

Testez l’appareil qui doit passer par le tunnel et celui qui ne doit pas, et comparez le second saut plutôt qu’un chiffre de débit. Un traceroute depuis chacun montre au second saut soit la passerelle du tunnel, soit celle du FAI ; si les deux se ressemblent, la marque ou la table ne fait pas ce que dit la règle. Utilisez de nouvelles connexions pour le test.

Puis redémarrez. L’ordre de démarrage est l’endroit où une politique qui marche devient cassée, car le client doit être actif avant que la route unreachable soit installée, et un instantané enregistré qui restaure l’ancien jeu de règles écrasera votre table. Vérifiez que chaque règle figure dans la configuration enregistrée et que la route par défaut marquée existe après le démarrage, pas seulement après que vous l’avez tapée.

Si quelque chose échoue, retirez d’abord la marque et voyez si le trafic normal revient, puis retirez la table. Cet ordre vous dit si vous poursuivez un problème de routage ou de pare-feu, et il laisse le foyer avec une imprimante qui fonctionne pendant que vous terminez le travail.