Pourquoi certains sites échouent-ils uniquement avec le VPN activé ?

Qu'un seul site échoue alors que tout le reste se charge prouve que le tunnel transporte du trafic, ce qui circonscrit le problème plus que la plupart des gens ne l'imaginent. Trois observations trient le reste : si vous avez reçu une réponse HTTP, si le nom d'hôte s'est résolu en une adresse, et si les petites requêtes passent tandis que les grosses bloquent. Deviner un problème de VPN avant d'avoir ces réponses déplace généralement la panne au lieu de la résoudre.

Traitez les observations dans l'ordre, car un site qui a répondu n'a pas pu aussi échouer à se résoudre. Si rien ne se charge du tout, vous êtes dans la mauvaise branche, et ce sont les contrôles pour connecté mais sans Internet qui s'appliquent.

Laissez le message d'erreur choisir la branche

Un refus, un défi anti-robot ou une page d'erreur signifie que le service a répondu, donc que des paquets ont atteint une application et sont revenus. Cela déplace la question vers la politique d'accès du site, qui peut peser l'adresse de sortie, le compte ou des motifs de requêtes qu'il ne publie pas. Un échec de résolution de noms n'a jamais atteint le site, et l'adresse est la première chose à inspecter. Un délai d'attente se situe entre les deux : quelque chose a été envoyé, et rien ne l'a acquitté.

Les avertissements de certificat relèvent d'une quatrième branche. Ils signifient que la connexion a été servie par quelque chose dont le navigateur n'a pas pu vérifier l'identité, soit un proxy de votre côté, soit une véritable incohérence que vous ne devez pas outrepasser. Traitez cela comme une question de confiance, non de routage.

Un site qui répond n'a pas prouvé que le tunnel est cassé

Quand la réponse est une page de blocage, comparez la même page via une seconde sortie en laissant le navigateur et la machine inchangés. Si le résultat suit l'adresse de sortie, le site traite cette adresse différemment, et aucune configuration client ne le fera changer d'avis. Si le blocage suit plutôt votre navigateur, la cause tient à une extension, un proxy enregistré ou un réglage de résolveur. Deux essais séparent ces explications à bon compte.

Les pannes uniquement liées au navigateur sont assez courantes pour être testées tôt. Une page qui se charge dans un navigateur pris en charge et échoue dans un autre indique un état de profil, un bloqueur de contenu ou un DNS chiffré configuré dans le navigateur lui-même. Les conseils de Chrome sur le DNS sécurisé indiquent où se trouve ce réglage, et le modifier via la commande prévue vaut mieux que réinitialiser l'appareil.

Quand seuls les gros transferts bloquent, regardez la taille des paquets

Une page qui affiche son en-tête puis se bloque a une signature différente d'une page qui ne démarre jamais. De petites réponses peuvent passer tandis qu'une charge utile de taille complète est abandonnée quelque part qui ne peut pas le signaler à l'émetteur, et c'est à cela que ressemble une panne de MTU de chemin vue d'un navigateur. Comparez une requête minuscule et une grosse vers le même hôte avant de théoriser sur le filtrage. La découverte de MTU de chemin est censée apprendre la plus petite taille de lien le long du chemin, et elle dépend de retours ICMP que les réseaux filtrés écartent régulièrement.

Testez cette hypothèse par un balayage de tailles plutôt qu'un seul ping. Une panne qui commence à une taille de charge utile constante est une preuve solide, tandis qu'une panne qui se déplace ne l'est pas.

Confirmez la correction sur la requête qui a échoué

Retestez l'opération d'origine, pas la page d'accueil, car une coquille en cache peut s'afficher alors que l'appel d'API derrière une connexion échoue encore. Les commandes ci-dessous séparent la résolution de noms, une petite requête et une grosse vers le même hôte. Remplacez le nom d'hôte et le chemin par ceux de la requête qui a réellement échoué.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

Si la réponse de dig diffère de celle qu'a utilisée le navigateur, le résolveur est la variable, et le réglage DNS du navigateur est l'endroit à examiner. Si la petite requête renvoie un statut tandis que la grosse bloque, traitez la branche de la taille des paquets. Si les deux expirent, le chemin de sortie et le traitement de cette adresse par le site reviennent sur la table.

Gardez la modification qui a fait réussir la requête d'origine et annulez le reste. Un empilement de changements simultanés sur le navigateur, le résolveur et le client vous empêche de dire lequel comptait.