Portail captif et blocage VPN : lequel bouge en premier
Le portail de l’hôtel veut du trafic avant que le tunnel existe ; le VPN bloque jusqu’à ce que le tunnel soit monté. Comparez les deux ordres et ce que chacun expose dans l’intervalle.
Le portail de l’hôtel veut un navigateur avant de laisser passer le moindre trafic. Votre VPN refuse de laisser passer du trafic avant que son tunnel soit monté. Chaque côté attend l’autre, et les deux se comportent exactement comme configuré. Seuls deux ordres brisent ce blocage, et ils diffèrent par ce qu’ils exposent tant que l’intervalle reste ouvert. Choisissez-en un délibérément au lieu de toucher au réglage qui fait charger le navigateur.
Deux ordres, dont un seul fonctionne
Soit le réseau vous admet d’abord et le tunnel arrive ensuite, soit vous ouvrez une exception étroite pour le portail puis rétablissez le blocage. Les deux sont légitimes. Ce qui n’est pas légitime, c’est de désactiver le blocage et d’oublier de le remettre.
| Order | What it costs | When it fails |
|---|---|---|
| Admit, then connect | Nothing extra; the block stays on | The client cannot reach the portal with the tunnel down |
| Exception, then restore | A timed window of direct access | The window is left open, or scoped too broadly |
Les deux ordres ne se valent pas dans toutes les situations. Un appareil géré avec un processus d’admission imposé a une réponse, et un ordinateur portable personnel sur le Wi-Fi d’un hôtel en a une autre. La comparaison porte sur ce à quoi chaque option renonce.
Commencez par savoir lequel votre client et votre politique d’appareil prennent réellement en charge.
Option A : admettre le réseau, puis connecter le tunnel
Confirmez le nom du réseau attendu, puis utilisez l’invite de connexion du système d’exploitation ou le flux de portail captif pris en charge par le client. Sur iPhone et iPad, fermer la feuille de connexion peut soit couper l’association, soit la conserver avec un avertissement indiquant que le réseau n’a pas d’accès internet, et ce sont des points de départ différents. Terminez d’abord l’étape d’admission, puis montez le tunnel. Cet ordre garde le blocage intact pendant toute la durée où le tunnel est abaissé.
Le piège est qu’un portail qui autorise l’accès à internet n’a pas authentifié votre compte VPN. Le tunnel doit quand même se connecter ensuite, et il peut échouer pour ses propres raisons. L’admission et l’authentification sont deux événements distincts que les gens fusionnent en un seul.
Si l’admission expire sans cesse, notez si le portail redemande, si le réseau tombe, ou si seul le VPN échoue.
Option B : une exception de connexion étroite, puis le rétablissement du blocage
L’alternative consiste à autoriser le trafic du portail pendant que le blocage reste en vigueur pour le reste, à vous connecter, puis à retirer l’exception. L’exception doit être étroite : une destination ou une plage d’adresses, pour la durée de la connexion, avec le blocage rétabli immédiatement après. Une fenêtre temporaire large est la façon dont une connexion de deux minutes devient un après-midi de trafic non protégé.
Sachez ce que votre client implémente réellement. OpenVPN Connect sur macOS documente la détection de portail captif séparément de son option qui bloque l’accès à internet pendant que le VPN est en pause ou se reconnecte. Détecter un portail et autoriser son trafic sont des tâches liées, pas des promesses interchangeables.
Sur un appareil géré, suivez le processus d’admission configuré plutôt que d’inventer une exception.
Ce que l’intervalle expose, et à qui
La partie intéressante du blocage n’est pas l’onglet du navigateur devant vous. C’est tout le reste qui commence à utiliser le réseau à l’instant où la connectivité apparaît : courrier, synchronisation des photos, vérifications de mises à jour, un client de messagerie instantanée qui se reconnecte, un agent de sauvegarde qui reprend.
Une fenêtre de navigateur silencieuse ne vous dit rien de tout cela. Fermez ou mettez en pause le travail sensible avant tout intervalle d’accès direct autorisé, et vérifiez ce qui démarre à l’ouverture de session. Sous Android, le VPN toujours actif associé au blocage des connexions hors du VPN est le contrôle pertinent, et une exception de route arbitraire ne remplace pas sa compréhension.
C’est le seul endroit où l’ancien conseil sur les fenêtres d’accès temporaires tient encore. L’inquiétude était juste, même là où le mécanisme ne l’était pas.
Comment choisir et comment le confirmer
Choisissez l’option A lorsque l’appareil ou le client prend en charge un vrai flux de portail, car elle garde le blocage intact d’un bout à l’autre. Choisissez l’option B lorsque le portail n’est atteignable par aucun autre moyen, et traitez l’exception comme un changement limité dans le temps avec un responsable.
Confirmez ensuite l’enchaînement plutôt que le résultat :
curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'Terminez l’admission, établissez le profil prévu, rétablissez tout contrôle de blocage modifié temporairement, puis faites une nouvelle requête inoffensive et confirmez qu’elle suit le tunnel. Une requête qui réussit parce que le blocage est encore désactivé ne prouve rien sur le tunnel.
Changer la sortie du VPN ne renouvellera pas une session d’hôtel expirée. Ce sont des événements différents, et les confondre vous envoie chercher au mauvais endroit.