Le VPN bloque le LAN local sous Windows : route ou stratégie du client ?

Une imprimante, un NAS ou une machine de développement sur votre propre bureau cessent de répondre à l'instant où le VPN professionnel se connecte. Parfois une commande de route règle cela en quelques secondes ; parfois la même route est correcte et les paquets disparaissent quand même, ce qui veut dire que vous êtes face à un autre problème avec un symptôme similaire. La décision se ramène à trois questions, et les poser dans le mauvais ordre est la raison pour laquelle les gens passent une soirée entière à supprimer et à rajouter des routes.

Trois questions avant toute commande

Premièrement : y a-t-il une entrée pour le préfixe local, et pointe-t-elle vers l'adaptateur physique ? Deuxièmement : le client reçoit-il de la passerelle une autorisation ou un refus de réseau local au moment de la connexion ? Troisièmement : avez-vous besoin d'un accès sortant au LAN uniquement, ou quelque chose sur internet doit-il aussi atteindre un service qui tourne sur votre machine ?

La première question sépare une panne de routage d'une panne de filtrage. La deuxième dit si une correction de route est autorisée à fonctionner. La troisième change la réparation : une route corrige le trafic sortant, tandis qu'un service entrant injoignable est généralement un problème de liaison d'écoute et de chemin de retour qu'une route aggrave.

Question un : route, filtre ou nom

Lisez la table avant d'y ajouter quoi que ce soit. L'index d'interface compte, car chaque commande de route ci-dessous y est ancrée :

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Un sous-réseau directement connecté conserve normalement une route sur le lien même quand le tunnel est actif, donc une entrée peut exister et le trafic échouer quand même. Cette combinaison est la signature d'un filtre qui s'exécute après le routage, et c'est le cas où une seconde route plus spécifique ne change absolument rien.

Testez séparément par adresse et par nom. Si ping 192.168.1.50 répond et net view 192.168.1.50 non, la table de routage n'a jamais été le problème : le tunnel a changé le résolveur et le nom local ne se résout plus. Ajouter une route pour cela est du travail perdu.

Question deux : la passerelle autorise-t-elle l'accès au LAN local ?

Un client commercial installe plus que des routes. Il reçoit une stratégie à la connexion, et cette stratégie peut inclure une autorisation explicite de réseau local. Dans les déploiements Cisco IPsec, la stratégie de groupe porte le réglage de tunneling divisé et un indicateur distinct d'accès au LAN local ; la case à cocher du client est une demande que la passerelle peut refuser. Dans AnyConnect, le profil contrôle les listes d'inclusion et d'exclusion du split et la même autorisation. Sous Windows RRAS, les équivalents sont l'option de passerelle par défaut du profil plus les routes statiques que le serveur attribue.

Quand l'indicateur est désactivé, le comportement documenté est que le client bloque le trafic vers le sous-réseau directement connecté même si une route valide et plus spécifique existe. C'est aussi pourquoi des routes que le client ne possède pas peuvent disparaître quelques secondes après que vous les avez ajoutées : le client reconstruit l'état qu'on lui a demandé de construire, il ne se bat pas contre vous.

Le journal du client enregistre la décision à la connexion, et le lire est plus rapide que n'importe quelle expérience sur la machine. Si le journal dit que l'accès local est bloqué, arrêtez-vous : aucune correction en ligne de commande n'y survit, et il ne reste que le changement de stratégie, l'accès à la ressource par le tunnel, ou l'enfermement du client dans une machine virtuelle en laissant l'hôte sur le réseau local.

Question trois : quelle direction vous faut-il ?

Le trafic sortant vers un appareil proche est une question de routage. Pointez le préfixe du LAN vers la passerelle locale avec une métrique assez basse pour battre la route par défaut du tunnel :

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

La seconde forme épingle un seul appareil, ce que vous voulez quand une adresse est toute l'exigence. L'équivalent netsh enregistre la même décision par nom d'interface plutôt que par index :

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Les commandes de route échouent avec Le paramètre est incorrect quand l'adresse et le masque ne concordent pas, par exemple une adresse d'hôte avec un masque /24. Utilisez l'adresse réseau pour une route de sous-réseau et un masque d'hôte pour un seul hôte.

L'entrant est différent. Un serveur VNC ou SSH sur la même machine devient injoignable quand les réponses à une connexion entrante sortent par la passerelle du VPN et ne reviennent jamais. Vérifiez sur quoi le service écoute avant de toucher aux routes :

netstat -ano | findstr :5900

Un écouteur lié à une adresse précise ne répondra pas sur l'autre interface. Le lier à toutes les interfaces est une décision délibérée, prise avec une règle de pare-feu limitée au réseau auquel vous faites confiance. C'est seulement ensuite que la réparation de la route rétablit le chemin de retour.

Appliquez le plus petit changement qui convient

L'autre geste courant est de décocher « Utiliser la passerelle par défaut sur le réseau distant » dans les propriétés avancées d'IPv4. Cela garde le trafic internet local, mais fait deux choses à la fois : le VPN cesse d'être le chemin par défaut, et le client cesse de recevoir des routes pour le réseau distant, y compris multicast. Décochez-le et le LAN distant disparaît, sauf si le serveur pousse les préfixes distants précis dont chaque client a besoin.

Cette asymétrie décide de l'ordre du travail. Si le côté distant doit rester pleinement joignable, poussez les sous-réseaux distants depuis le serveur et laissez la route par défaut locale tranquille. Si vous ne pouvez pas changer le serveur, ajoutez une route persistante vers le préfixe distant via l'adresse que le tunnel a attribuée, et vérifiez avec route print que le préfixe pointe vers l'interface du VPN pendant que la route par défaut pointe toujours vers la passerelle physique.

Confirmez ensuite que la réparation survit à une reconnexion, car les routes non persistantes meurent avec l'adaptateur et un script qui s'exécute après chaque connexion est l'endroit honnête pour elles. Testez un appareil local et une ressource distante dans la même session, déconnectez, reconnectez et testez de nouveau. Si l'appareil local échoue encore alors que la route semble correcte, revenez à la question deux : le client filtre, et la réponse est un changement de stratégie plutôt qu'une seconde route concurrente.