Isolation des clients Wi-Fi face à l’accès local par VPN : qu’est-ce qui vous bloque

Mettez deux téléphones sur le même SSID invité : aucun ne voit l’autre, pourtant les deux accèdent à internet. Ajoutez un client VPN sur l’un d’eux et l’imprimante à trois mètres reste invisible, tandis qu’un serveur sur un autre continent répond aux ping. Rien n’est cassé dans le tunnel ; deux décisions d’accès distinctes entrent en jeu, et une seule concerne le routage. Le point d’accès décide si les clients sans fil peuvent se parler, et le client VPN décide quelles destinations sortent par le tunnel. Confondre les deux produit des heures de changements de configuration inutiles.

Les deux portes sont indépendantes

L’isolation des clients est une décision de commutation. Le point d’accès accepte une trame d’une station associée, regarde la destination, remarque que la destination est une autre station du même pont et la rejette. L’adresse IP de la station n’entre pas dans cette décision, et le VPN non plus.

Le routage est une autre décision, prise sur le client. La table de routage du VPN décide si un paquet vers 192.168.1.50 entre dans le tunnel ou sort par l’interface Wi-Fi. Si le paquet sort par Wi-Fi et que le point d’accès isole les clients, il meurt au point d’accès. Si le paquet entre dans le tunnel, le point d’accès ne voit jamais la destination d’origine et ne peut rien isoler.

Ce que l’isolation bloque sur un point d’accès typique

Les fabricants le livrent sous plusieurs noms : isolation des clients, isolation d’AP, isolation de stations ou un réseau invité qui l’implique. Dans OpenWrt, l’option par interface est isolate dans la configuration sans fil, comme décrit dans la documentation sans fil, et un SSID invité reçoit généralement son propre pont et sa zone de pare-feu. L’effet est que les trames unicast entre clients ne sont pas pontées, donc un ping, une connexion SMB ou un travail d’impression vers un voisin échoue même si les deux appareils affichent un signal complet.

Les protocoles de découverte souffrent en premier et le plus visiblement. mDNS pour les imprimantes et les appareils multimédias passe en multicast vers 224.0.0.251, SSDP utilise 239.255.255.250, et le fait que ces trames traversent le pont dépend du fabricant et de l’activation de la conversion multicast vers unicast. Un appareil absent d’une liste est une preuve plus faible qu’une connexion directe échouée vers une adresse connue.

Ce que le VPN change et ce qu’il ne peut pas changer

Un tunnel complet prend la route par défaut, donc les sous-réseaux locaux ne sont atteints que si le client conserve une route plus spécifique pour eux. Les tunnels fractionnés font l’inverse et préservent l’accès local par conception. Aucun des deux réglages ne peut forcer un point d’accès isolant à transmettre une trame entre deux de ses clients, c’est pourquoi autoriser le trafic local dans le client VPN est nécessaire mais pas suffisant.

Le cas inverse est tout aussi courant. Le point d’accès autorise le trafic entre pairs, le client VPN exclut le sous-réseau local du tunnel, et l’imprimante ne répond toujours pas parce que le pare-feu de l’hôte traite le réseau Wi-Fi comme public. Trois couches, trois valeurs par défaut différentes, et seule la route est visible dans la plupart des journaux VPN.

Déterminez quelle porte est fermée

Commencez par un test qui retire le VPN de l’équation : connectez deux appareils ordinaires au même SSID et essayez de joindre l’un depuis l’autre par adresse. Si cela échoue, le point d’accès isole et aucun réglage VPN ne le corrigera. Si cela réussit, passez au client et exécutez ip route get 192.168.1.50 sous Linux ou Find-NetRoute -RemoteIPAddress 192.168.1.50 sous Windows ; la sortie nomme l’interface que le paquet utilisera.

Quand la route pointe vers l’interface Wi-Fi, le paquet sort non chiffré et la question devient de savoir si le point d’accès et le pare-feu de l’hôte l’autorisent. Quand la route pointe vers le tunnel, la destination est envoyée au serveur VPN, ce qui est faux pour un appareil du même réseau local et signifie généralement que la liste autorisée du tunnel est trop large.

Une connexion directe au port de l’imprimante est un meilleur test qu’une liste de découverte. nc -vz 192.168.1.50 9100 sous Linux ou Test-NetConnection 192.168.1.50 -Port 9100 dans PowerShell vous dit si l’adresse est joignable, avant qu’un appairage au niveau applicatif n’entre dans la discussion.

Choisissez la correction adaptée au réseau où vous êtes

Sur un réseau d’hôtel ou invité, l’isolation est délibérée et vous ne devriez pas chercher à la contourner. Traitez l’appareil local comme injoignable, utilisez le VPN pour atteindre un hôte capable d’imprimer ou de partager, et cessez de traiter le SSID comme un réseau local.

Chez vous, désactiver l’isolation sur le SSID principal est raisonnable quand les appareils sont les vôtres, tandis que le SSID invité reste isolé. Le réglage vit dans la configuration sans fil du point d’accès, et il y appartient plutôt que dans des exceptions de pare-feu sur chaque client.

Au bureau, supposez que le point d’accès, le VLAN et le pare-feu de l’hôte sont tous intentionnels. Escaladez avec les résultats des tests au lieu de demander la désactivation de l’isolation, car un réseau qui sépare les clients protège généralement quelque chose.

Vérifiez l’application, pas seulement le ping

Un ping réussi prouve le chemin, pas le service. Les imprimantes acceptent souvent du 9100 brut ou de l’IPP sur 631 mais refusent la découverte, et un partage de fichiers exige 445 plus une résolution de noms fonctionnelle. Confirmez le port utilisé par l’application, puis réessayez la tâche réelle sur l’appareil.

Gardez les deux couches séparées dans vos notes : ce que le réseau Wi-Fi permet et ce que le VPN route. La prochaine fois qu’un appareil disparaît d’une liste, cette séparation vous dira où regarder en premier.