Le Wi-Fi invité continue d’utiliser la route principale : donnez-lui sa propre sortie

Vous avez créé un réseau invité, ajouté une route pour celui-ci, et les invités sortent toujours par votre connexion Internet normale. Le tunnel est actif, le LAN principal fonctionne, et les appareils invités annoncent une adresse dans la plage que vous avez attribuée, donc rien ne semble cassé. Ce qui manque généralement n’est pas une route mais un sélecteur : le routeur décide du chemin avant de considérer par quelle interface le paquet est arrivé, et à moins que quelque chose ne corresponde explicitement au trafic invité, ce trafic hérite de la valeur par défaut. Le correctif est un segment, une règle de politique et un chemin de retour, dans cet ordre.

Le symptôme : les invités sortent toujours par le WAN

L’indice est l’adresse de sortie. Un appareil invité qui atteint Internet par le tunnel annoncera l’adresse du fournisseur du tunnel, et celui qui a hérité de la route par défaut annoncera votre connexion normale. Comparez côte à côte un appareil invité et un appareil du LAN principal, car le cas intéressant est lorsqu’ils diffèrent de ce que vous avez configuré et concordent entre eux.

Le second indice est l’absence de tout trafic sur l’interface du tunnel pendant que les invités naviguent. Si les compteurs ne bougent pas, la politique n’a jamais été appliquée, et ajuster le tunnel lui-même ne peut pas aider.

Étape 1 : un vrai segment, pas seulement un nom

Un nom de SSID ne crée pas d’isolation. Vérifiez que le réseau invité se termine sur sa propre interface, VLAN ou pont, et que la plage d’adresses diffère du LAN de confiance. Sur de nombreux points d’accès grand public, le SSID invité est ponté dans le même segment que tout le reste, ce qui rend le reste de ce travail impossible tant que ce n’est pas corrigé.

Confirmez ensuite la plage invitée et son serveur DHCP, et gardez les paramètres de résolution associés à ce segment plutôt qu’au routeur entier. Un sous-réseau invité qui n’existe que comme commentaire dans une règle de pare-feu n’est pas un segment, et le routeur n’aura aucune interface à comparer.

Ne pontez pas les invités dans le LAN principal pour faciliter la configuration du VPN. Cela échange l’isolation que vous vouliez contre un raccourci de routage, et c’est la raison habituelle pour laquelle un réseau invité finit avec accès à l’imprimante et au NAS.

Étape 2 : sélectionnez le tunnel par source

Les tables de routage sont choisies par destination, donc une règle qui dit « envoyez 0.0.0.0/0 vers le tunnel » s’applique à tout le monde. Le routage par politique ajoute une seconde dimension : sélectionner la table par adresse source. Sur un routeur sous Linux, c’est une règle supplémentaire plus une table dédiée, et l’ordre compte car la première règle correspondante l’emporte :

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

Cette dernière commande répond directement à la question : quelle interface cette source utilisera pour cette destination. Exécutez-la avant et après le changement et vous saurez si la politique a pris effet sans toucher à un navigateur.

La plupart des firmwares de routeur expriment la même chose sous forme de règle d’interface ou de sélection de passerelle basée sur la source. Quelle que soit la syntaxe de votre plateforme, le principe est identique : faites correspondre l’interface d’entrée ou le préfixe source, puis remplacez la route pour cette correspondance uniquement. Une règle basée sur la destination ne peut pas distinguer un invité d’un appareil du foyer.

Étape 3 : le chemin de retour et la traduction

Un paquet qui sort par le tunnel doit revenir. Soit le pair du tunnel connaît une route de retour vers le préfixe invité, soit le routeur traduit la source invitée en l’adresse du tunnel. Choisissez l’une et notez-la, car les modes de défaillance diffèrent : une route de retour manquante donne une connexion qui s’établit et ne répond jamais, tandis qu’une traduction manquante ne produit souvent rien du tout.

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

Si vous choisissez la traduction, rappelez-vous que le pair ne voit plus qu’une seule adresse pour tous les invités, donc toute politique par client à l’extrémité distante disparaît. Si vous conservez plutôt les adresses, les deux extrémités ont besoin du préfixe invité dans leur routage et leur politique, ce qui demande plus de travail et est plus prévisible.

IPv6 a besoin de sa propre règle. Une politique écrite pour IPv4 ne couvre pas l’autre famille, et un appareil invité avec IPv6 fonctionnel l’utilisera volontiers pendant que votre chemin IPv4 soigneusement routé reste inactif. Routez les deux familles ou désactivez IPv6 sur le segment invité, mais ne supposez pas que la règle combinée que vous avez écrite couvre ce que l’appareil fait réellement. Testez avec un client qui a les deux familles activées, car c’est le cas que la conception doit supporter. Un ordinateur portable qui préfère IPv6 paraît correct lors d’un test IPv4 uniquement et fuit lors du test réel.

Testez l’isolation, pas seulement la navigation

La navigation prouve que la sortie a changé. Elle ne prouve pas que le segment est isolé, et l’isolation est la raison d’être du réseau invité. Depuis un appareil invité, essayez d’atteindre l’interface d’administration du routeur, un hôte du LAN de confiance et un service qui devrait être refusé ; les trois devraient échouer, et l’échec devrait être une décision de politique plutôt qu’un délai que personne ne peut expliquer.

Testez ensuite un appareil du LAN principal et confirmez que sa sortie n’a pas changé. C’est la régression que cette conception cause le plus souvent : une règle large destinée aux invités, appliquée à toutes les interfaces parce que la correspondance a été écrite sur la destination.

Enfin, décidez de ce qui se passe lorsque le tunnel est en panne. Les invités n’ont soit aucun accès à Internet, soit un basculement vers un chemin que vous approuvez, et laisser cela indécis signifie un retour silencieux à la connexion normale, ce qui est exactement la fuite que la politique invitée devait empêcher. La recette de routage du trafic Internet parcourt la même sélection de chemin pour un routeur basé sur pfSense.

Le DNS provenant du routeur est le cas qui surprend les gens en dernier. Si les invités utilisent le routeur comme résolveur, les requêtes du routeur lui-même suivent la route du routeur plutôt que la règle invitée, donc les recherches peuvent sortir par la connexion normale alors que le trafic applicatif ne le fait pas. Gardez le segment, le résolveur et la politique de défaillance dans une seule note, et la personne suivante pourra vérifier les trois sans redériver la conception.