Pourquoi votre VPN Windows tue l’imprimante locale et comment l’arrêter

Connectez le VPN et l’imprimante disparaît, le partage NAS cesse de s’ouvrir et une session Bureau à distance vers la machine d’à côté expire. Rien n’est cassé. Le client a ajouté une route par défaut et possède désormais chaque destination que l’ordinateur portable peut nommer, y compris celles à trois mètres. C’est tout le mécanisme, et appeler cela une panne du VPN est ce qui transforme une correction d’une ligne en ticket de support.

Lisez d’abord la table de routage

Avant de changer quoi que ce soit, capturez la table IPv4 avec route print -4 et conservez la sortie. Connectez-vous, capturez à nouveau et comparez les lignes 0.0.0.0 : la route par défaut active nomme une interface, et si cette interface est le tunnel, l’impression et la navigation locales sont envoyées d’abord au bureau.

Le numéro d’interface de la deuxième colonne est ce à quoi une route persistante devra se référer plus tard, alors notez-le pendant que le tunnel est actif. C’est aussi la valeur qui change lorsque l’adaptateur est recréé, et c’est pourquoi les routes qui y sont épinglées peuvent survivre discrètement à leur utilité.

Supprimez la route par défaut, de trois façons

Sur un profil Windows intégré, le contrôle est une case à cocher. Ouvrez les propriétés de la connexion, IPv4, puis Avancé, et décochez Use default gateway on remote network ; l’application Paramètres plus récente cache la même boîte de dialogue un niveau plus profond. Depuis une invite élevée, le même changement est un cmdlet :

Set-VpnConnection -Name "Corp" -SplitTunneling $true

Un profil OpenVPN fonctionne différemment, et c’est pourquoi son comportement déroute ceux qui attendent une case à cocher. Sa directive redirect-gateway def1 ne remplace pas du tout la route par défaut ; elle installe deux routes de demi-plage, 0.0.0.0/1 et 128.0.0.0/1, qui ensemble l’emportent sur la route par défaut sans la supprimer. Comme la route par défaut d’origine survit, ajouter un préfixe pointé vers net_gateway ne renvoie que ce préfixe au routeur local. Ce détail explique pourquoi le correctif pour un profil def1 est une route de préfixe et non une case à cocher que personne ne trouve.

Ne rétablissez que ce qui relève du travail

La route par défaut supprimée, le tunnel ne transporte plus rien, donc les préfixes de travail doivent être nommés explicitement. Le cmdlet qui lie un préfixe à la connexion est plus sûr qu’une route persistante, car il n’est installé que pendant que cette connexion est active et ne dépend pas d’un numéro d’interface :

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

L’approche plus ancienne fonctionne toujours et figure toujours dans chaque liste de vérification : route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, avec l’index d’interface et l’adresse de passerelle propres au tunnel. Elle persiste après les redémarrages, ce qui est le but et aussi le danger, car l’index peut appartenir à autre chose au prochain démarrage.

Les métriques décident du reste. Si l’adaptateur physique et celui du tunnel revendiquent une route pour le même préfixe, la métrique la plus basse gagne, et augmenter la métrique du tunnel est un contrôle légitime côté client et non un bricolage.

Quand le serveur décide pour vous

Un client qui ignore votre case à cocher obéit généralement à une stratégie. Les profils Cisco portent un réglage Allow Local LAN Access, et un headend peut pousser une stratégie tunnel-all qui annule ce que le client préférerait ; dans un déploiement en tunnel obligatoire, il n’y a aucun commutateur local à basculer. Lisez le journal du client pour les routes et lignes de stratégie poussées au lieu de revérifier la même boîte de dialogue.

Regardez ensuite la résolution de noms, qui est un commutateur distinct du routage. Un tunnel divisé peut encore recevoir un résolveur interne et un suffixe de recherche, donc un appareil local est joignable par adresse et introuvable par nom tant que le côté DNS n’est pas corrigé aussi.

Les chevauchements sont un autre problème

Si le LAN domestique et le LAN du bureau partagent un préfixe tel que 192.168.0.0/24, aucune route ne peut les distinguer. Chaque paquet de cette plage a un seul résultat de recherche, et le correctif consiste à renuméroter un côté ou à joindre le bureau via une adresse traduite issue du pool. Ajouter des routes plus spécifiques ne fait que déplacer la moitié du réseau qui casse.

Terminez par une vérification plutôt que cinq : connectez-vous, puis lancez tracert vers un hôte interne et un hôte public. Le premier saut devrait différer, et s’il ne diffère pas, la séparation n’est pas en place quoi que le client rapporte. Reconnectez-vous ensuite une fois et répétez, car les routes poussées reviennent à chaque session.