Comment diagnostiquer un VPN connecté sans accès LAN

Le tunnel peut être établi alors que routage, policies ou DNS empêchent encore l’accès aux ressources.

Étapes

Commencez par relever l’adresse attribuée au client VPN et les routes installées. Testez ensuite une adresse IP du LAN afin d’écarter le DNS. Vérifiez que le préfixe interne est envoyé dans le tunnel, qu’une policy autorise le flux et que le réseau LAN possède un chemin retour vers le pool VPN. Si le réseau local du client utilise le même sous-réseau que le site distant, traitez d’abord ce chevauchement.

Commandes utiles

route print

tracert 192.168.1.1

Confirmer où le trafic VPN se perd

Utilisez route print ou l’équivalent du système client pour confirmer la route, puis tracert/traceroute avec prudence pour observer le chemin. Côté firewall, consultez les logs de session ou réalisez une capture filtrée sur l’IP du client et la ressource LAN. La présence du paquet à l’aller puis l’absence de retour oriente vers la route retour, la policy ou le firewall de la destination.

À retenir

Le statut connecté ne valide ni le routage ni les droits d’accès. Un split tunnel mal défini peut oublier le réseau interne, un NAT peut masquer le pool VPN et un sous-réseau local identique au LAN distant peut envoyer le trafic vers la mauvaise interface. Tester uniquement un nom DNS peut aussi faire croire à une panne réseau alors que l’accès par IP fonctionne.

FAQ — VPN connecté sans accès LAN

Pourquoi le VPN est-il connecté mais le serveur interne inaccessible ?

Le tunnel peut être établi alors qu’une route, une policy, le chemin retour ou un chevauchement de sous-réseaux bloque encore le trafic.

Pourquoi faut-il tester par IP avant le DNS ?

Un test par IP permet de distinguer un problème de connectivité d’un problème de résolution de noms.

Que vérifier en cas de sous-réseau identique des deux côtés ?

Le poste peut préférer son réseau local au tunnel ; il faut traiter le chevauchement par le plan d’adressage ou une solution adaptée à l’architecture VPN.