Routeur en mode client VPN : pourquoi les appareils du LAN disparaissent

Croire que le mode client lui-même tue l'accès au LAN conduit les gens dans le mauvais menu de réglages, et les causes réelles sont généralement au nombre de deux. Le tunnel ne supprime pas le pont LAN et n'empêche pas les clients filaires et sans fil de communiquer entre eux. Ce qui casse l'accès local est soit une fonction d'inspection située dans le chemin de transfert du routeur, soit une plage d'adresses LAN qui a bougé lorsque le micrologiciel l'a fait. Les deux produisent la même plainte, et aucune n'est corrigée en réinstallant le profil VPN.

Le mythe, et ce que le mode client change vraiment

Le mode client ajoute une interface de tunnel et une route par défaut qui passe par elle, puis transfère le trafic LAN dans ce tunnel. Le pont entre les ports filaires et les radios sans fil reste intact, tout comme la commutation locale. Ce qui change, c'est la stratégie : quel trafic est transféré, où il est traduit et quel résolveur les clients reçoivent.

Cette distinction compte parce qu'un LAN cassé signifie généralement qu'une de ces trois stratégies a changé, pas que le routeur a cessé d'être un commutateur. Un routeur qui répond encore à sa propre page d'administration prouve que l'interface LAN est vivante. Un routeur qui ne répond à rien du tout a un autre problème, comme une adresse LAN changée ou un client sur le mauvais sous-réseau.

Le premier geste utile est donc de trouver quelle couche s'est cassée, pas de changer celle que vous soupçonnez.

Testez trois cibles avant de toucher à un réglage

Depuis un client filaire, testez trois cibles séparément et notez chaque résultat : l'adresse LAN du routeur lui-même, un autre appareil sur le même commutateur par IP, et quelque chose accessible uniquement par le tunnel. Faites-le dans cet ordre, car chaque résultat élimine une couche différente. Utilisez des adresses plutôt que des noms au premier passage, car un échec de nom mêle le DNS à une question de connectivité.

Le schéma des réponses est le diagnostic. Un routeur qui répond alors que les appareils locaux ne répondent pas pointe vers la commutation locale ou une fonction de filtrage plutôt que vers le routage. Les appareils locaux qui répondent alors que le côté tunnel ne répond pas pointent vers la route du tunnel ou le pare-feu distant. Tout répond par adresse alors que les noms échouent est une question de résolveur, et aucune modification de route ne réglera cela.

Gardez le tableau à côté des résultats de test. Il transforme une plainte vague en une ligne sur laquelle agir.

La couche de sécurité à l'intérieur du chemin de transfert

Les routeurs grand public embarquent de plus en plus une fonction d'inspection qui surveille le trafic transféré, et elle s'exécute dans le même chemin qui transporte les paquets du LAN vers le tunnel. Quand cette inspection ne peut pas classer le trafic du tunnel, le transfert peut se bloquer alors que le tunnel lui-même reste actif et que le routeur signale une connexion saine. Rien dans le journal VPN ne le montre, parce que le VPN s'est bien connecté.

Le diagnostic est une expérience contrôlée, pas un changement permanent. Notez le réglage actuel, désactivez la fonction pendant un test, remontez le tunnel et testez un seul hôte local par adresse. Le transfert qui revient est la preuve qu'il vous fallait, et le compromis devient alors une décision plutôt qu'une supposition. Si rien ne change, réactivez-la immédiatement et passez à la cause d'adressage.

Laisser une fonction de sécurité payante désactivée pour qu'un tunnel continue de fonctionner est un compromis à faire délibérément et à noter. Il vaut aussi la peine de demander si le tunnel appartient à un autre appareil, car un routeur qui doit tout inspecter et un routeur qui doit tout transférer sont deux métiers différents.

La deuxième cause : la plage LAN a bougé

Les mises à jour du micrologiciel réinitialisent régulièrement l'adresse LAN à la valeur par défaut du fabricant, et certains routeurs ont un commutateur de mode explicite qui décide si le LAN conserve une plage privée ou en hérite de l'équipement amont. Un client qui attend 192.168.8.x peut se retrouver sur 10.64.0.x, et une session SSH vers un hôte expire alors que le tunnel est parfaitement sain.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Lisez le préfixe et la passerelle depuis le bail avant d'ouvrir la page du routeur. Les deux premières commandes montrent ce que le client a réellement reçu, et la troisième montre quelle interface le client utiliserait pour une adresse locale, et c'est ainsi qu'une route résiduelle ou un sous-réseau obsolète se révèle. Comparez ensuite avec la page LAN et le mode dans lequel se trouve le routeur.

Si la plage ne peut pas revenir, mettez à jour chaque objet qui la nomme : réservations DHCP, toute route statique vers l'ancien sous-réseau et chaque règle de pare-feu qui porte le préfixe précédent. Une plage qui entre en collision avec le sous-réseau distant du tunnel est la variante la plus déplaisante, car les appareils locaux restent joignables tandis que les destinations distantes sont silencieusement mal routées vers le LAN.

Reconnectez et retestez dans l'ordre des paquets

Après l'un ou l'autre changement, reconnectez le tunnel et répétez les tests dans l'ordre des paquets : routeur, hôte local, hôte distant, puis noms, puis l'application. Tester l'application en premier masque quelle couche est encore cassée, et une nouvelle tentative du navigateur sur un nom en cache peut ressembler à une panne de routage.

Notez la version du micrologiciel, le préfixe LAN et l'état de la fonction d'inspection à côté du profil VPN. Les trois sont une configuration que la prochaine mise à jour peut écraser, et deux lignes de notes épargnent l'heure que vous venez de passer.