Comment vérifier qu’un satellite Mesh Wi-Fi passe par le routeur VPN

Un satellite qui répond au même nom Wi-Fi que le routeur de base ne vous dit presque rien sur la destination des paquets de ses clients. Le nœud est une radio et un pont jusqu’à preuve du contraire. Ce qui décide de la sortie, c’est la passerelle par défaut que chaque client reçoit et le mode de transfert du nœud placé devant lui. Faites ces cinq vérifications du client vers l’extérieur, et vous obtiendrez une réponse défendable plutôt qu’une impression tirée d’un test de débit.

Lisez la passerelle que le client a réellement reçue

Sur le client, affichez la table de routage et la table des voisins. La route par défaut nomme l’adresse qui transfère le trafic ; l’entrée voisine nomme la MAC qui possède cette adresse. Utilisez le client, et non la liste d’appareils du routeur, car une liste d’appareils montre des associations, pas des chemins.

ip route show default
ip -6 route show default
ip neigh show

Windows affiche les mêmes faits sous une autre forme : ipconfig /all donne la passerelle par défaut et arp -a donne la MAC. Sous macOS, route -n get default et arp -an couvrent le même terrain.

Comparez cette passerelle à deux adresses que vous connaissez déjà : l’adresse LAN du routeur de base et l’adresse d’administration du satellite. Si la passerelle est l’adresse LAN du routeur, le client est ponté vers le routeur et la politique du routeur pour ce LAN s’applique telle quelle. Si la passerelle est l’adresse du satellite, le satellite route, et le routeur ne voit jamais les paquets du client comme du trafic LAN ; la décision doit se prendre sur le nœud, sinon elle n’a pas lieu.

Confirmez le mode dans lequel le nœud se trouve réellement

Les produits Mesh réutilisent trois mots pour des comportements différents ; faites donc confiance au chemin des paquets plutôt qu’à l’étiquette de l’application. Le mode pont ou point d’accès transfère les trames. Le mode routeur termine un sous-réseau et fait tourner DHCP. Le mode invité place généralement les clients sur un VLAN séparé avec ses propres règles. Un nœud en mode routeur derrière un autre routeur crée un double NAT, et ses clients arrivent au routeur VPN déjà traduits, ce qui ruine une politique basée sur l’adresse source.

Pour fixer la MAC, lisez l’étiquette sur le nœud et comparez-la avec ip neigh. Les fabricants impriment la MAC de base et dérivent les MAC de chaque radio en incrémentant un octet ; le dernier chiffre hexadécimal diffère donc ; comparez le préfixe plutôt que l’adresse entière. Si la MAC de la passerelle appartient à l’interface LAN du routeur, le nœud ne route pas pour ce client.

Prouvez la sortie sur le routeur, pas avec un test de débit

L’état côté routeur est le seul endroit qui montre la traduction. Sur OpenWrt, listez les règles de politique et les tables de routage, puis confirmez que le tunnel a un handshake récent :

ip rule show
ip route show table all | grep default
wg show

Sur pfSense ou OPNsense, les mêmes preuves se trouvent dans pfctl -sr pour les règles, pfctl -ss pour les états actifs, et dans la page d’état WireGuard pour les compteurs de pairs, en suivant la documentation du client WireGuard. Filtrez la table d’états par l’adresse du client. Si l’état montre le client traduit vers l’adresse du tunnel, le trafic est dans le tunnel ; s’il montre l’adresse WAN, il n’y est pas, quoi qu’en dise le badge du tableau de bord.

Une trace de route depuis le client ajoute un fait que la table d’états ne peut pas fournir : le premier saut. Si le premier saut est l’adresse LAN du routeur, le client a atteint le routeur directement. Si c’est l’adresse du nœud suivie d’un autre saut privé, vous êtes sur un segment routé, et ce second saut est l’appareil qui doit porter la politique.

Vérifiez ce que le nœud distribue en plus d’une adresse

Les options DHCP voyagent avec le bail, si bien qu’un nœud qui sert son propre DHCP peut aussi servir son propre DNS et ses propres annonces de routeur IPv6. Un client peut donc sortir par le tunnel tout en envoyant ses requêtes à un résolveur situé sur le nœud, ou récupérer une adresse IPv6 globale que la politique du tunnel ne couvre jamais. Affichez les deux sur le client :

cat /etc/resolv.conf
ip -6 addr show scope global

Si le résolveur est le nœud et que le nœud transmet au routeur, le DNS suit le tunnel. Si le nœud résout localement ou pointe vers le résolveur du FAI, les requêtes sortent hors du tunnel même quand HTTP ne le fait pas. IPv6 mérite le même test : une adresse globale plus une route par défaut qui contourne le tunnel constitue une fuite, et le micrologiciel Mesh laisse souvent IPv6 actif alors que la politique VPN ne couvre qu’IPv4.

Coupez le tunnel exprès, puis notez le résultat

Coupez le tunnel et observez un client associé à ce nœud, pas un client à côté du routeur. ping et un curl à délai court suffisent ; la question est de savoir si le trafic s’arrête ou retombe sur le WAN. Arrêtez le tunnel avec la commande de service du routeur, par exemple wg-quick down wg0 ou l’arrêt du service OpenVPN, et gardez le test court.

Si le client continue de fonctionner, le nœud ou le routeur échoue en mode ouvert pour ce segment, et le mesh a discrètement annulé le kill switch. Rétablissez le tunnel, confirmez que le compteur de handshake a bougé, puis répétez la vérification de la table d’états de la troisième étape.

Notez une ligne par nœud : libellé, SSID, adresse de passerelle, préfixe MAC, sortie confirmée oui ou non, IPv6 couvert et comportement tunnel coupé. L’itinérance est l’endroit où la réponse change, testez donc les pièces que vous utilisez vraiment. Quand une ligne contredit les autres, c’est ce nœud qu’il faut examiner, et la correction revient à l’appareil qui détient la passerelle de cette ligne.