Réseau local injoignable lorsque le VPN est connecté ? Quatre vérifications

Le tunnel monte, l’intranet apparaît et l’imprimante cesse de répondre. Rien n’a échoué sur le réseau local ; le client a changé le chemin qu’il utilise pour les adresses qu’il ne considère plus comme locales. Parcourez les quatre vérifications ci-dessous dans l’ordre et arrêtez-vous quand l’une produit une divergence concrète, car le même symptôme a quatre causes courantes et une seule se corrige en modifiant le VPN.

D’abord, regardez la table de routage que le client a installée

Ouvrez la table de routage du client tant que le VPN est connecté. Sous Linux, utilisez ip route, sous Windows route print ou Get-NetRoute, et sous macOS netstat -rn. Vous cherchez une route par défaut à travers le tunnel et ce qu’il est advenu de la route par défaut physique.

Un client en tunnel complet ajoute souvent deux demi-routes par défaut, 0.0.0.0/1 et 128.0.0.0/1, au lieu de remplacer 0.0.0.0/0. La route par défaut d’origine reste visible mais perd toutes les recherches, ce qui explique que la table paraisse intacte alors que tout le trafic hors du sous-réseau se déplace. Si le client VPN propose une option de tunnel divisé et que la politique l’autorise, c’est la réparation la plus propre.

Si le tunnel doit rester la route par défaut, épinglez plutôt le sous-réseau local. Sous Linux, la route nomme l’interface physique et la passerelle ; sous Windows, ajoutez -p pour la rendre persistante et lisez le numéro d’interface dans route print plutôt que de le deviner :

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Une route épinglée ne tient que tant que l’adresse qu’elle nomme reste la même. Un portable qui renumérote son adaptateur Wi-Fi à chaque connexion brisera de nouveau la règle, alors vérifiez l’adresse de l’interface avant de conclure que la réparation a échoué.

Deuxièmement, confirmez que l’adresse était locale dès le départ

Si la destination se trouve dans le sous-réseau connecté, la route par défaut du tunnel ne s’applique jamais et le VPN n’est pas la cause. Une imprimante en 192.168.1.40 sur un client en 192.168.1.0/24 utilise la route connectée ; si cette adresse échoue, regardez l’appareil, le commutateur ou le pare-feu du client plutôt que le VPN.

Le cas qui trompe les gens est une adresse publique pour un serveur local. Depuis le réseau local, joindre l’adresse WAN du routeur et revenir exige du NAT en épingle à cheveux, et beaucoup de routeurs ne l’implémentent tout simplement pas pour les redirections de port. Testez l’adresse privée à côté de la publique. Si la privée fonctionne et la publique non, le VPN n’a fait que révéler une limitation de NAT déjà présente.

Un nom d’hôte aggrave les choses. Si le nom local se résout désormais vers l’adresse publique, le client continuera d’essayer le chemin qui ne peut pas revenir. Utilisez l’adresse privée pour le test, puis corrigez le nom au lieu d’ajouter une autre redirection de port.

Troisièmement, voyez qui répond aux noms maintenant

Un résolveur d’entreprise connaît l’intranet et généralement rien d’un nom d’hôte NAS, du nom Bonjour d’une imprimante ou de l’alias local d’un routeur. Quand le VPN pousse ses serveurs DNS, ces noms cessent de se résoudre même si leurs adresses restent joignables. Interrogez le nom directement et comparez la réponse à l’adresse que vous savez détenue par l’appareil.

Sous Linux, resolvectl query nas.local montre quel résolveur a répondu. Sous Windows, nslookup nas.local nomme le serveur, et ipconfig /all montre l’ordre des résolveurs. Si le suffixe local est désormais traité par le résolveur d’entreprise, redirigez ce suffixe vers le résolveur local ou utilisez l’adresse IP de l’appareil.

La découverte est une couche distincte. mDNS et la diffusion ne traversent pas un tunnel routé, si bien qu’un appareil peut être joignable par adresse alors que son nom reste invisible. Un réflecteur ou une entrée DNS locale règle cela ; une route non.

Quatrièmement, vérifiez si l’autre machine est aussi sur un VPN

Quand la machine que vous voulez joindre exécute aussi un client VPN, votre session peut arriver pendant que sa réponse sort par l’autre tunnel. Cela produit une connexion qui s’établit puis se bloque, ou une tentative RDP et SSH qui expire sans aucune erreur de votre côté. Vérifiez la table de routage de l’autre hôte et son chemin par défaut avant d’accuser votre client.

Vérifiez aussi l’adresse sur laquelle le service écoute. Un écouteur lié uniquement à l’adresse du tunnel accepte les connexions venant du VPN et les refuse depuis le réseau local, même quand le routage est parfait. C’est une configuration de service, pas un chemin réseau, et c’est courant sur les interfaces de gestion verrouillées sur l’adresse du VPN.

Gardez un chemin de gestion qui ne dépend pas du tunnel : une route statique nommant votre réseau source, une autre interface reliée au réseau local ou une console qui contourne entièrement le tunnel. Concevoir ce chemin après la chute de la session est bien plus difficile que de l’ajouter avant la prochaine connexion.

Appliquez la réparation qui correspond à la vérification qui a échoué

Si la table de routage a montré une capture en demi-par-défaut, choisissez le tunnel divisé quand la politique le permet et une route locale épinglée quand elle ne le permet pas. Si l’adresse s’est révélée publique, basculez le test et le nom vers l’adresse privée. Si le résolveur a changé de mains, limitez le suffixe local ou utilisez l’adresse. Si l’autre hôte est tunnelisé, corrigez son chemin de retour ou sa liaison d’écoute.

Changez une chose, puis répétez la même vérification. Une route ajoutée pour le mauvais sous-réseau, un suffixe de résolveur avec une faute de frappe et une route épinglée sur une interface qui se renumérote ressemblent tous à la panne d’origine. La répétition est ce qui distingue une réparation d’une coïncidence.

Notez la route, l’adresse et le résolveur qui fonctionnaient pendant que le VPN était connecté. La prochaine reconnexion changera au moins l’un d’eux, et la note transforme la prochaine panne en une courte comparaison plutôt qu’en une nouvelle enquête.