Échec général lors du ping d'une adresse LAN avec le client VPN actif

Une route d'hôte, une adresse, et le ping échoue immédiatement avec General failure au lieu que la requête n'expire. Cette distinction, c'est tout le diagnostic. Une expiration signifie que le paquet est parti et que quelque chose l'a ignoré. Échec général signifie que Windows n'a pas pu remettre le paquet à la moindre interface dès le départ.

Ainsi, quand la table de routage semble parfaite et que l'erreur reste Échec général, le blocage se produit sous la décision de routage, et le client du fournisseur est ce qui opère à cet endroit.

Lisez l'erreur avant la table de routage

Windows renvoie cette erreur lorsqu'il ne trouve aucune interface pour envoyer, et il ne dit rien de ce que la destination aurait fait du paquet. La joignabilité, les pare-feu de l'autre extrémité et la disponibilité du service sont toutes des questions en aval que vous n'avez pas encore atteintes.

La configuration classique pour ce cas est une route d'hôte qui dirige une seule adresse LAN vers la passerelle physique afin qu'elle contourne le tunnel. route add l'accepte, route print l'affiche, et le ping échoue toujours, parce que le pilote de filtre a déjà décidé que le paquet n'a pas le droit de sortir.

Avant d'accepter cette explication, confirmez que la route est réellement sélectionnée : vérifiez l'index d'interface et la métrique, et assurez-vous que l'entrée n'est pas périmée après une reconnexion. Une route qui pointe vers une interface qui n'existe plus produit une erreur similaire pour une raison bien moins intéressante.

Trois couches, trois propriétaires différents

La couche qui gagne est celle qui s'exécute en dernier, et ces trois ne sont pas dans l'ordre que la plupart des gens supposent.

La couche intermédiaire explique pourquoi une route peut être à la fois correcte et inutile. Les clients des fournisseurs installent un filtre et des règles de pare-feu pour que le trafic hors du tunnel soit abandonné, et c'est le même mécanisme qui met en œuvre leur coupure d'urgence. Rien dans la table de routage ne participe à cette décision.

La troisième couche explique un rapport étrange qui revient régulièrement : le sous-réseau local est injoignable même après la déconnexion du client. Le service tourne encore et le filtre est toujours installé, donc ne pas être connecté n'est pas la même chose que ne pas filtrer. Quittez le client au lieu de simplement le déconnecter avant de conclure quoi que ce soit.

Ce qu'il faut essayer, dans l'ordre

Commencez par retirer les fonctions peu coûteuses à retirer et faciles à rétablir. La découverte du LAN, parfois appelée invisibilité sur le LAN, bloque le trafic vers les plages d'adresses privées afin que la machine reste cachée de ses voisins. Les imprimantes, les serveurs de fichiers locaux et le routeur lui-même disparaissent derrière ce commutateur. Les fonctions de protection contre les menaces qui filtrent le DNS installent leurs propres crochets et seraient à l'origine de ruptures de joignabilité locale à peu près de la même manière.

Désactivez les deux, quittez complètement le client, puis testez l'adresse. Cette séquence sépare une fonction qui bloque le trafic d'un tunnel qui le route mal, et elle prend deux minutes au lieu d'un après-midi de routes statiques.

ping 192.168.1.50
tracert -d 192.168.1.50
route print -4

Si l'adresse répond une fois les fonctions désactivées, vous avez une décision de politique et non une panne : choisissez entre laisser la fonction désactivée, ajouter une exception, ou accepter que la machine reste invisible sur le réseau local.

Utilisez l'exception du client, de façon étroite

Quand une fonction doit rester active, le tunnel divisé propre au client est l'échappatoire prise en charge. Gardez l'exception aussi petite que l'exigence le permet, ce qui signifie généralement une adresse d'hôte pour un serveur ou un préfixe pour un seul segment. Une règle couvrant toute une plage privée est un trou permanent que personne ne se souviendra d'avoir ajouté et que personne n'osera retirer.

Vérifiez ensuite d'abord par l'adresse, puis par le nom. Si l'adresse répond avec un premier saut sur la passerelle physique, l'exception fonctionne. Si le nom échoue encore, vous êtes passé au DNS, car le résolveur du tunnel ne connaît pas la zone locale et aucun changement de routage ne le lui apprendra.

Conservez la route ou l'exception, pas les deux, avec une note indiquant laquelle fait le travail. Deux mécanismes qui se chevauchent se masquent l'un l'autre, et la prochaine personne qui déboguer cette machine en retirera un et ne verra aucun changement.

Quand le client est l'obstacle

Certaines versions filtrent le trafic d'une manière qu'aucune route statique ni exception de client ne peut vaincre. Quand c'est le constat, les options honnêtes sont d'attendre la fonction de contournement ou de se connecter avec un client OpenVPN simple en utilisant le profil du fournisseur lui-même, ce que recommandait la réponse du support de l'éditeur dans le rapport d'origine.

Comprenez le compromis avant de faire cette substitution. Un profil simple se comporte comme n'importe quel tunnel ordinaire : il installe ses routes et ne restructure pas le reste de la pile, si bien qu'une route d'hôte étroite se comporte encore comme vous l'attendez. Ce que vous perdez, c'est tout ce que le client de marque a mis en œuvre autour du tunnel, y compris la coupure d'urgence et le filtrage DNS, et cela doit être reproduit volontairement ou accepté comme absent.

Quoi que vous choisissiez, notez quelle couche possédait le blocage. Un paquet qui n'a jamais quitté la machine est le résultat d'un filtre, et aucun changement de routage ne peut réparer un filtre.