Imprimante hors ligne quand le VPN se connecte ? Vérifiez la table de routage

Votre ordinateur portable rejoint le VPN d’entreprise et l’imprimante à deux mètres cesse de répondre. Rien n’a changé sur l’imprimante, et le réseau local n’est pas tombé. Ce qui a changé, c’est la table de routage : l’adaptateur du tunnel possède désormais un chemin qui couvre l’adresse de l’imprimante, si bien que ces paquets sortent par le VPN et arrivent sur une passerelle qui n’a aucune idée de l’endroit où se trouve votre réseau plat. Déroulez les quatre vérifications ci-dessous dans l’ordre, et arrêtez-vous à la première qui échoue.

Première étape : prouvez que l’imprimante est toujours joignable sur le LAN

Avant de toucher au routage, confirmez que l’appareil est vivant pour quelque chose qui n’utilise pas le VPN. Demandez à un téléphone du même Wi-Fi d’ouvrir la page web de l’imprimante, ou faites un ping vers l’adresse depuis une autre machine du réseau plat. Si l’imprimante n’y répond pas non plus, le VPN est une coïncidence et la panne tient à l’imprimante, à son association Wi-Fi ou à l’isolation des clients sur le point d’accès.

Si elle répond partout sauf sur cet ordinateur portable, vous avez un problème de routage ou de résolution de noms qui vit sur l’ordinateur portable, et l’étape suivante vous dit lequel des deux c’est.

Deuxième étape : trouvez la route que Windows choisit réellement

Ne lisez pas la table de haut en bas et ne devinez pas. Demandez à Windows quelle entrée il choisit pour l’adresse exacte qui vous intéresse, et récupérez l’index d’interface en même temps.

Find-NetRoute -RemoteIPAddress 192.168.1.50
route print -4
tracert -d 192.168.1.50

Find-NetRoute affiche la route gagnante et son interface, et ce sont les deux faits dont dépend le reste. route print -4 montre les entrées voisines, y compris les deux demi-routes par défaut qu’installent les clients en tunnel complet : 0.0.0.0/1 et 128.0.0.0/1, qui couvrent ensemble tout l’espace IPv4 sans jamais remplacer 0.0.0.0/0. Une /1 est plus longue qu’une /0, mais votre 192.168.1.0/24 l’est encore plus, et c’est pourquoi une route LAN absente compte plus que la prétention du tunnel lui-même.

Deux règles décident de la réponse. Le préfixe correspondant le plus long gagne d’abord, et parmi les entrées de même préfixe, la métrique totale la plus basse gagne, le total combinant la métrique de route et la métrique d’interface. Si l’interface sélectionnée est le tunnel, continuez. Si c’est l’adaptateur physique et que le trafic échoue encore, arrêtez-vous ici : votre problème est la résolution de noms ou la liste d’accès de l’imprimante elle-même, pas la route VPN.

Troisième étape : ajoutez la route la plus étroite qui nomme passerelle et interface

La réparation est une entrée qui pointe l’adresse de l’imprimante vers le routeur local sur l’adaptateur local. Exécutez-la dans une invite élevée et remplacez les valeurs que vous venez de lire.

route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 if 12 -p

La valeur de if est l’index d’interface de l’adaptateur physique. L’omettre est la raison la plus courante pour laquelle la commande semble réussir et ne change rien, car avec deux adaptateurs capables d’atteindre le même saut suivant, Windows est libre de choisir celui que vous ne vouliez pas. L’indicateur -p rend l’entrée persistante, de sorte qu’elle survit à un redémarrage au lieu de mourir avec la session.

Préférez une route d’hôte pour l’appareil unique à une route pour tout le 192.168.1.0/24. Une route de sous-réseau est plus large que nécessaire et elle entre en collision dès que le côté entreprise utilise aussi ce préfixe : un préfixe a alors deux propriétaires, et l’entrée qui gagne décide du réseau auquel vous pouvez réellement accéder.

Dans l’autre sens, si vous avez effacé l’option de passerelle par défaut sur la connexion VPN pour protéger le LAN, les préfixes privés distants cessent aussi d’être résolus. Ajoutez des routes pour ceux-ci via l’interface VPN de la même manière, sinon le tunnel devient un lien qui ne transporte rien.

Quatrième étape : faites survivre l’exception à la prochaine connexion

Beaucoup de clients d’entreprise réinstallent tout leur jeu de routes à chaque connexion et recalculent les métriques d’interface ce faisant, si bien qu’une route qui fonctionnait hier peut être supplantée aujourd’hui. Après reconnexion, répétez Find-NetRoute pour l’imprimante et vérifiez que l’interface correspond toujours à l’adaptateur physique. Si l’entrée a disparu, quelque chose la supprime ; une route persistante ne vous protège pas d’un agent qui balaie la table. Les tâches planifiées qui rajoutent la route après la connexion VPN sont la solution habituelle, et c’est aussi la solution qui casse quand l’index de l’adaptateur change après une station d’accueil ou une mise à jour de pilote.

Surveillez IPv6 séparément. Un client qui ne revendique que la valeur par défaut IPv4 peut laisser la route par défaut IPv6 sur l’adaptateur physique, si bien qu’une imprimante joignable en IPv6 continue de fonctionner alors qu’IPv4 échoue, ou l’inverse. Testez avec ping -4 et ping -6 avant de décider que la table de routage est innocente.

Ce que vous coûte le raccourci local

Toute route qui contourne le tunnel est un trou dans la promesse du tunnel. Le trafic vers cette adresse ne passe plus par la passerelle d’entreprise, ce qui signifie ni inspection, ni journalisation, ni application de politique. Sur un appareil géré, cela peut être un problème de conformité plutôt qu’une préférence, alors demandez s’il existe une exception officielle de tunnel divisé avant d’en ajouter une à la main. Gardez la vôtre aussi étroite que la tâche et aussi brève que la situation le permet.

Si l’imprimante répond après le changement, répétez les quatre vérifications après votre prochaine reconnexion au lieu de supposer que le correctif a tenu. Si elle ne répond pas, capturez la sortie de Find-NetRoute avant et après la connexion ; la différence vous dit si le client a supprimé l’entrée ou seulement reclassé celle-ci.