Pourquoi une route VPN large casse quelques sites publics

La plupart des pages se chargent, deux ou trois expirent, et le navigateur accuse la connexion. Les sites qui échouent ont un point commun que les autres n'ont pas : leurs adresses résolues tombent dans un préfixe installé par le VPN. Une route assez large pour couvrir une plage publique capturera un trafic que le tunnel n'était pas censé transporter, et le symptôme ressemble à un problème de site plutôt qu'à une décision de routage.

Résolvez le nom qui échoue, puis regardez la table de routage plutôt que le navigateur.

Comparez l'adresse, pas le nom du site

Recherchez l'adresse que le client a réellement essayée, puis vérifiez quelle route y correspond. Une destination dans 45.61.20.10 tombe sous 45.0.0.0/8 si ce préfixe est présent, même si le site lui-même n'a rien à voir avec le tunnel. Comparer l'adresse qui échoue aux préfixes installés est un problème de soustraction, pas une devinette.

Windows peut répondre aux deux moitiés directement, et une recherche montre quelle interface et quel saut suivant ont remporté la sélection. Résolvez le nom deux fois si le site renvoie plusieurs adresses. Notez chacune avec la route qui correspondait. Des adresses différentes peuvent donner des réponses différentes, et une seule d'entre elles est peut-être le cas qui échoue.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Lisez le préfixe correspondant le plus spécifique, pas la première ligne qui semble familière. Une route présente dans la table ne prouve pas qu'elle a remporté la recherche ; c'est la correspondance la plus longue qui le fait. Deux préfixes peuvent correspondre à une adresse, et un seul reçoit le paquet. Le perdant reste dans la table et paraît tout aussi réel dans une liste.

Notez le préfixe, son interface et l'adresse résolue. Ces trois valeurs constituent tout le diagnostic.

Trouvez qui a installé la route

Les routes viennent de quatre endroits : le profil VPN natif, une stratégie de gestion, un script de connexion ou un tout autre client. Supprimer l'entrée active peut confirmer sa pertinence, mais la connexion suivante la recrée à partir de la configuration enregistrée, c'est donc la source qu'il faut changer.

Vérifiez d'abord la liste des routes du profil, puis la stratégie de gestion, puis tout script exécuté à la connexion. Cet ordre correspond à la fréquence à laquelle chacun se révèle responsable. Il limite aussi le changement à une couche au lieu de trois.

Lisez attentivement le comportement natif basé sur les classes

Les profils Windows natifs ont un paramètre documenté, NativeProfile/DisableClassBasedDefaultRoute, qui contrôle une route automatique déduite de l'adresse de l'interface. Une adresse de profil commençant par 45 peut produire une entrée 45.0.0.0/8 avec ce comportement, et c'est ainsi qu'une seule adresse publique capture toute une plage de classe A.

Le nom de la propriété invite à une lecture erronée : la mettre à true désactive l'inférence, et false l'active. Ce n'est pas non plus le même objet qu'une route par défaut, et elle ne gouverne pas les clients tiers qui installent leurs propres préfixes.

Si l'inférence est la cause démontrée, corrigez le profil via son propriétaire de gestion et fournissez explicitement les préfixes privés prévus. Si un script a ajouté l'entrée, réparez le script. Remplacer une route large inexpliquée par une autre change le symptôme sans répondre à la question.

Réparez la source, puis revérifiez les deux chemins

Après le changement, reconnectez-vous et répétez la recherche pour un site public qui échoue et pour une ressource qui doit passer par le tunnel. Le premier devrait maintenant se résoudre vers l'interface physique, et le second devrait toujours sélectionner le VPN. Ne vous arrêtez pas au premier succès ; une correction qui casse aussi l'accès privé a échangé une panne contre une autre.

Examinez en même temps le plan d'adressage du serveur. Un pool qui chevauche l'espace public provoque ce type de problème encore et encore. Une plage choisie volontairement par l'opérateur mérite une autre conversation, pas une renumérotation automatique.

Augmenter le MTU ou vider le DNS ne corrigera pas un préfixe qui dirige encore cette adresse vers le tunnel. Testez d'abord la sélection, puis le chemin.