VPN connecté mais pas d’internet ? Passez les quatre couches

Le client affiche connecté, le navigateur tourne, et chaque site finit en délai d’attente. Cette combinaison est courante et ce n’est pas une contradiction : connecté signifie que le tunnel a négocié, rien de plus. La résolution de noms, le routage et la sortie propre au serveur échouent chacun à leur manière, et chacun a un responsable différent. Parcourez les couches dans l’ordre et arrêtez-vous à la première qui échoue.

Commencez par le réseau d’où vous venez

Coupez le tunnel avec la commande de déconnexion du client, puis essayez deux sites HTTPS sans rapport si la politique le permet. Laissez le travail sensible fermé pendant ce test. Si l’accès ordinaire échoue aussi, le VPN n’est pas le premier suspect.

Regardez la liaison Wi-Fi, le routeur et toute page de portail qui exige une connexion avant de toucher au tunnel. Un kill switch peut bloquer le trafic pendant la déconnexion par conception, alors suivez sa procédure de test documentée au lieu de conclure que le réseau est mort. Un autre réseau de confiance est une comparaison utile, et une nouvelle sortie VPN n’achèvera pas une connexion d’hôtel expirée. Si le réseau ouvert fonctionne et le tunnel non, le réseau est disculpé et la couche suivante vous revient.

Déterminez si la panne est une résolution de noms

Notez le texte de l’erreur, car un échec de résolution, un délai d’attente et un avertissement de certificat pointent chacun ailleurs. Le schéma à repérer tôt est un nom d’hôte que vous n’avez jamais visité qui échoue alors qu’une application avec une session ouverte continue. Ce schéma concerne les nouvelles requêtes, pas le fait que le tunnel transporte des paquets. Une seule requête montre ce que renvoie le résolveur, et elle prend une seconde. Essayez aussi un second nom, pour qu’une réponse en cache ou un enregistrement cassé ne décide pas du diagnostic.

nslookup example.com

Une IP arbitraire dans la barre d’adresse HTTPS n’est pas un test DNS, car le certificat et l’hôte virtuel dépendent généralement du nom. Les noms internes peuvent nécessiter le résolveur de l’organisation plutôt qu’un remplacement public, et un navigateur doté de son propre résolveur sécurisé peut répondre différemment de la requête du système. Là où les deux divergent, le résolveur du navigateur est celui que vit l’utilisateur, et cette distinction appartient au ticket.

Tunnel complet ou sous-réseaux de l’entreprise seulement

Certains profils n’existent que pour atteindre une poignée de sous-réseaux de l’entreprise ; d’autres sont conçus pour tout transporter et ont besoin d’une sortie fonctionnelle derrière eux. Lisez la finalité documentée avant de supposer que le voyant couvre chaque application et chaque famille d’adresses. Un profil de réseau privé peut fonctionner exactement comme prévu tandis que le navigateur, qui n’était jamais censé l’utiliser, échoue encore. Lisez la table de routage sans la modifier, et incluez IPv6, car un chemin IPv4 qui fonctionne ne dit rien de l’autre famille.

Une route plus spécifique peut l’emporter alors que la route par défaut existe encore, c’est pourquoi la table doit être lue et non supposée. Des adaptateurs virtuels concurrents peuvent aussi posséder du trafic que vous attendiez ailleurs, surtout après l’installation et l’oubli d’un second client VPN. Ne supprimez pas la route par défaut à titre d’expérience ; cela transforme un diagnostic en seconde panne.

Un seul site en échec parmi ceux qui fonctionnent est un problème de ce site, et cela prouve aussi que le tunnel transporte du trafic. Les blocages qui n’apparaissent que sur les gros transferts pointent la taille des paquets plutôt que l’accessibilité.

Quand le serveur ne transmet jamais rien

Si chaque destination échoue sur deux appareils et deux réseaux d’accès, le tunnel est monté et la sortie ne transmet pas. Ce couplage sépare une panne côté serveur d’un appareil mal configuré à un seul endroit. Envoyez à l’opérateur les questions de transmission, de NAT et de chemin de retour, pas une capture du voyant.

Ces trois points couvrent la plupart des causes côté serveur, et c’est à l’opérateur d’y répondre. La page de dépannage de la connectivité OpenVPN parcourt les mêmes questions côté serveur, alors transmettez-la avec le ticket. Une capture d’un voyant vert ne répond à aucune d’elles.

Passez le journal du client après connexion au crible des échecs d’application des routes, des paramètres DNS ou de l’adaptateur virtuel. Les erreurs à ce stade désignent l’appareil, pas le serveur. Une erreur qui n’apparaît jamais dans le journal est tout aussi instructive, car elle déplace le soupçon de l’autre côté.

Vérifiez une couche à la fois

Une fois quelque chose modifié, reconnectez-vous et répétez exactement l’application qui a échoué. Une seule page qui se charge prouve moins qu’un chemin reproductible vers les ressources pour lesquelles le profil a été conçu. Deux commandes séparent la résolution de l’accessibilité, et la seconde dépend de l’hôte. Exécutez la ligne curl n’importe où, puis la commande de routes correspondant à l’hôte devant vous.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Si la requête numérique fonctionne et le nom non, restez sur le DNS. Si aucune ne fonctionne, comparez la table de routage à la valeur par défaut attendue du tunnel et vérifiez la famille que vous testez réellement. Si la route est correcte et que la requête meurt encore à la sortie, la question restante revient à l’opérateur, et les preuves que vous avez gardées sont le ticket.