Le Wi-Fi passe par le VPN du routeur. Et les ports filaires ?

Le portable en Wi-Fi affiche l’adresse de sortie du VPN, et le poste filaire de la pièce voisine affiche celle du fournisseur d’accès. Les deux sont branchés sur le même routeur, donc la différence ne vient pas de la configuration du VPN. Elle vient de l’interface, du VLAN ou de la politique que le trafic a réellement traversés. La couverture est une propriété de chaque chemin, pas une propriété du boîtier.

Comparer les deux clients côte à côte trouve la différence plus vite que la lecture des règles du routeur.

Deux chemins vers le même routeur

Un routeur doté d’un client VPN peut diriger le trafic d’un pont, d’un VLAN ou d’une liste de ports et laisser le reste sur le WAN. C’est une conception normale, et c’est pourquoi un test sans fil réussi ne prouve que le chemin sans fil. Un commutateur administrable peut aussi placer une prise murale sur un segment différent de celui du point d’accès, sans que personne touche au routeur. Les politiques fondées sur les ports sont les plus faciles à manquer, car le port semble faire partie du même réseau local.

Même matériel, autre politique. Le boîtier physique n’est pas la frontière que vous croyez.

Comparez la passerelle que chaque client utilise vraiment

Sur l’appareil filaire, relevez l’interface active, son adresse et sa passerelle par défaut. Sur une machine où le Wi-Fi et l’Ethernet sont tous deux actifs, la métrique de routage décide qui l’emporte, et ce n’est souvent pas celle que vous attendez. Comparez cette passerelle avec celle qu’a utilisée le client sans fil, et vérifiez à quel réseau du routeur appartient le port du commutateur. La recette de client WireGuard de pfSense montre comment un seul routeur peut posséder un tunnel tout en laissant les autres interfaces tranquilles.

Si les deux passerelles diffèrent, vous avez la réponse avant de toucher à une seule règle de pare-feu.

Comparez le DNS et l’IPv6 séparément

Un client filaire dont le résolveur est configuré à la main peut contourner entièrement la politique DNS du routeur, même quand son trafic est correctement dirigé. L’IPv6 est l’autre moitié : un tunnel qui ne gère que l’IPv4 peut laisser le trafic IPv6 sur le chemin natif. Testez une résolution de nom et une destination IPv6 depuis l’appareil filaire, pas seulement un contrôle d’adresse IPv4. Utilisez une requête que seul le résolveur du routeur pourrait traiter, comme un nom d’hôte interne.

Chacune de ces comparaisons est distincte, et chacune peut échouer de son côté.

Comparez ce qui se passe quand le tunnel tombe

Si la conception exige un accès uniquement par VPN, arrêtez le tunnel et testez le client filaire avec un trafic inoffensif. Un appareil filaire qui retombe sur le WAN normal reste en ligne mais rate la route prévue, ce qui ressemble à un succès pour quiconque ne vérifie que la connectivité. Le client sans fil peut se comporter autrement, et cette différence est la comparaison qui vaut la peine.

Le comportement en cas de panne fait partie de la couverture, ce n’est pas un cas limite qui vient après.

Attribuez le résultat à la bonne couche

Un client VPN au niveau de l’appareil ou un proxy de navigateur sur la machine filaire peut changer l’adresse de sortie mesurée indépendamment du routeur. Notez quelles couches étaient actives pendant le test, sinon un changement d’adresse réussi est attribué à la mauvaise passerelle. La même prudence vaut pour un résultat en cache antérieur au changement.

Testez un trafic neuf, notez les couches et écrivez le segment et l’interface. C’est cette trace qui rend la comparaison suivante utile au lieu d’une nouvelle supposition.