Pourquoi le portail captif bloque votre VPN et comment vous reconnecter

Sur un réseau ouvert, votre point d’accès ne remet pas simplement les paquets à l’internet. Un point de politique en amont vérifie si votre appareil est déjà autorisé, et tant qu’il ne l’est pas, presque tout est écarté. Votre client VPN lit ce silence comme un serveur mort. Il le dit rarement : WireGuard relance une poignée de main dans le vide, OpenVPN signale un délai de connexion dépassé, et IKEv2 revient avec l’erreur 809 au sujet d’un serveur distant qui ne répond pas.

Ce que le portail contrôle réellement

Un portail captif est deux choses agrafées ensemble : un point de décision de politique et un redirectionneur. Quand votre appareil s’associe et prend un bail DHCP, le réseau vous place dans un état antérieur à l’autorisation.

Cet état est un ensemble de règles de pare-feu. Il autorise généralement le DNS et autorise HTTP ou HTTPS vers une courte liste d’hôtes du portail, et il écarte tout le reste. La liste autorisée est le jardin clos, et elle n’inclut presque jamais un point de terminaison VPN.

Aucun de ces rejets n’est poli. Les paquets destinés à un serveur VPN sont écartés plutôt que refusés, si bien que le client ne reçoit ni ICMP unreachable ni TCP reset, seulement l’absence de réponse. Selon le fournisseur, le redirectionneur peut répondre au port 80 par une redirection vers la page de connexion tandis que le port 443 est écarté ou intercepté. Les redirections sont faciles à repérer car elles portent une réponse HTTP simple ; l’interception sur 443 exige un certificat auquel votre navigateur refusera de faire confiance.

L’autorisation elle-même est généralement liée à l’adresse MAC de l’appareil, parfois à l’IP louée, et elle vit dans une table de sessions avec un minuteur. La connexion crée une entrée. La règle de pare-feu qui laisse passer votre trafic n’existe que tant que cette entrée existe, et c’est pourquoi tout le problème revient plus tard sans que rien ne change de votre côté.

Pourquoi la poignée de main du VPN meurt avant de commencer

Chaque protocole a son propre transport, et le pare-feu antérieur à l’autorisation casse chacun différemment. IKEv2 sous Windows et iOS passe par UDP 500 et UDP 4500 ; un rejet sur ces ports se manifeste par 809, ou par un échec de type résolution de noms sur les clients qui rapportent les étapes séparément. OpenVPN sur UDP 1194 reste à l’état de connexion jusqu’à l’expiration de son délai. OpenVPN sur TCP 443 est le cas intéressant, car le portail peut terminer la poignée de main TCP puis répondre avec sa page de redirection, si bien que vous voyez une erreur TLS au lieu d’un délai dépassé.

WireGuard montre le mécanisme le plus clairement. Il est uniquement UDP par conception, sans repli TCP, si bien qu’un pare-feu qui écarte l’UDP inconnu supprime entièrement le transport. Le client continue d’envoyer des initiations de poignée de main avec un retrait croissant et signale une poignée de main qui ne se termine jamais. Rien dans ce message ne mentionne le Wi-Fi, et rien n’y suggère que vous devriez ouvrir un navigateur.

Les plateformes tentent de remarquer l’état avant votre VPN. Windows récupère une URL connue pour décider s’il affiche sa notification de connexion, Android demande un point de terminaison qui devrait répondre 204 No Content, et les appareils Apple ouvrent une petite fenêtre de réseau captif. Ces sondes fonctionnent parce que le portail répond par une redirection au lieu du corps attendu. Le même comportement explique comment un portail peut sembler parfaitement sain alors que votre tunnel est mort : la sonde et le tunnel sont jugés selon des règles différentes.

Ce qu’une expiration de session réinitialise vraiment

Les lieux font expirer les sessions pour des raisons sans rapport avec votre compte VPN : un délai d’inactivité, une durée maximale de session, un nouveau bail DHCP ou une réassociation à un autre point d’accès. Quand le minuteur se déclenche, l’entrée de la table de sessions disparaît et l’ensemble de règles antérieur à l’autorisation revient exactement tel qu’il était à l’arrivée.

Un tunnel établi survit souvent assez longtemps pour paraître sain. Les messages de maintien continuent de sortir, et si le client le remarque dépend de sa façon de traiter le trafic sans réponse, si bien que le voyant d’état peut rester vert un moment après la disparition du chemin. Puis le tunnel tombe et chaque tentative de reconnexion échoue sur les mêmes ports bloqués.

À ce stade, l’erreur du client vous dit à quelle étape vous êtes, si vous la lisez attentivement :

Un détail trompe les gens : quand la session est liée à une adresse MAC, recharger la page de connexion peut ne pas aider. Vous devez abandonner l’association et vous joindre de nouveau pour que le portail voie une nouvelle tentative d’autorisation au lieu d’une tentative expirée.

Connectez-vous d’abord, puis montez le tunnel

L’ordre qui fonctionne est : autoriser l’appareil, prouver le chemin, démarrer le VPN, prouver le tunnel, puis rétablir votre blocage habituel. Cette dernière étape compte car l’état temporaire dont vous avez besoin pour atteindre le portail est exactement l’état qu’un commutateur d’arrêt d’urgence existe pour empêcher.

Un client de bureau doté de l’option de blocage hors tunnel doit être mis en pause pour que la page du portail se charge, et vous devriez garder les applications sensibles fermées pendant cette fenêtre hors tunnel ; c’est le seul intervalle où le trafic local sort sans protection. Un appareil géré toujours actif devrait utiliser la procédure publiée par son propriétaire plutôt que de vous laisser retirer la politique. Si le portail présente un avertissement de certificat, arrêtez : l’accepter achemine votre session par le proxy d’interception du lieu, et ce proxy peut lire tout ce que vous envoyez. Sous Android, le verrouillage avec VPN toujours actif bloque le trafic avant que le tunnel ne soit monté, et certaines versions ne peuvent pas exempter le flux du portail ; si la vôtre ne le peut pas, utilisez l’accès alternatif du lieu ou un autre appareil au lieu de laisser le verrouillage désactivé. Les règles Apple à la demande peuvent être écrites pour refuser le tunnel jusqu’à ce qu’une sonde réussisse, ce qui est le comportement que vous voulez sur les réseaux d’hôtel.

Vérifiez dans l’ordre avec les outils que vous avez déjà. Avant le tunnel, lancez la sonde avec les en-têtes et le corps tous deux visibles, et regardez si votre transport VPN reçoit la moindre réponse :

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Avant l’autorisation, un portail normal donne l’une de deux réponses : un 302 dont le Location pointe vers la page de connexion, ou un 200 avec un corps HTML qui est la page du portail. Notez laquelle vous avez reçue. Une redirection n’est pas un échec avant la connexion ; c’est le portail qui vous dit où aller. Après que le portail signale le succès, répétez la commande et attendez un 200 dont le corps est le mot littéral Success. C’est cette chaîne qui rend la sonde significative. Si l’hôte répond normalement avant que vous ne vous soyez jamais connecté, il n’y a pas de portail d’interception sur ce réseau. Dans la capture, un rejet antérieur à l’autorisation est constitué de paquets sortants dont rien ne revient, tandis qu’un chemin qui fonctionne montre une réponse au même flux en une seconde environ. Connectez-vous, puis répétez la capture.

Si le tunnel échoue encore après que le portail a dit oui

Le succès de la connexion n’est pas la même chose qu’un transport autorisé. Beaucoup de lieux autorisent le portail et la navigation ordinaire tout en bloquant l’UDP purement et simplement, ce qui laisse WireGuard et OpenVPN sur UDP cassés et TCP 443 fonctionnel. Si TCP 443 passe et pas l’UDP, c’est la politique du lieu et non un client que vous auriez mal configuré, donc changez de transport ou acceptez la limite et passez à la suite. Si une reconnexion échoue encore après cela, conservez l’erreur exacte ; elle nomme l’étape où vous êtes bloqué.

D’autres défaillances vivent sur l’appareil. Une session encore liée à une ancienne MAC, un second adaptateur Wi-Fi avec son propre bail, ou un client qui a mis en cache l’exception de certificat du portail peuvent chacun continuer d’échouer après une réautorisation propre. Abandonnez l’association, réautorisez et réessayez une fois avant de toucher aux réglages du client. RFC 8952 vaut la lecture si vous voulez l’architecture derrière les composants que vous observez.

Si le portail lui-même refuse d’autoriser, le problème vient du compte ou de l’attribution de l’appareil et aucun réglage VPN ne le corrigera. Changer le pays de sortie du VPN ne réinitialise pas l’état d’accès local du lieu ; cette table est liée à votre appareil, pas au serveur que vous choisissez. Demandez à l’exploitant du lieu et laissez-lui du temps, car c’est la table des sessions qu’il regardera.

Avant votre prochain voyage, notez trois choses : la page du portail comme étape zéro, l’étape de mise en pause du blocage pour chaque appareil que vous emportez, et un transport de repli que vous avez réellement testé. Quand un tunnel qui fonctionnait il y a dix minutes s’arrête de nouveau, traitez-le comme une autorisation expirée et revérifiez le portail avant de toucher au profil VPN.