Wi-Fi d'hôtel : le VPN échoue avant même d'atteindre le serveur

Le client VPN tourne, annonce ensuite qu'il ne peut pas joindre le serveur, et tout le monde conclut que l'hôtel bloque les VPN. En général, rien d'aussi dramatique ne s'est produit : le réseau ne vous a pas encore laissé sortir. Un portail captif retient chaque connexion jusqu'à la connexion, et un tunnel ne peut pas s'établir pendant qu'une page de connexion intercepte ses paquets. Faites la connexion avant d'accuser le tunnel.

Le mythe : l'hôtel bloque les VPN

La plupart des réseaux d'hôtel ne filtrent pas les tunnels spécifiquement. Ils interceptent le trafic web jusqu'à l'authentification du client, et ils peuvent aussi limiter le nombre d'appareils, faire expirer les sessions ou réduire le débit. Chacun de ces cas produit une panne qui, depuis un client VPN, ressemble à un blocage.

Le tunnel est ici un mauvais outil de diagnostic, car c'est la seule application qui échoue à coup sûr tant que le portail n'est pas authentifié. L'accès web ordinaire est un meilleur indicateur, puisqu'il peut vous montrer la page de connexion elle-même.

Cet ordre compte pour une autre raison : un client doté d'un coupe-circuit ou du mode toujours actif refusera de charger le portail, et l'utilisateur conclura que le réseau est en panne plutôt que le réglage. Les deux faits sont vrais en même temps, et un seul peut être changé à l'hôtel. Désactivez la protection via la commande du client, connectez-vous, puis réactivez-la. Tout le reste est un contournement qui masque la vraie séquence.

Terminez d'abord le portail, puis testez le HTTPS ordinaire

Demandez au personnel le nom officiel du réseau et la méthode de connexion. Un SSID convaincant ne prouve pas la propriété, et un second réseau au nom similaire est un piège courant dans les lieux publics. Utilisez l'invite de connexion du système d'exploitation lorsqu'elle est proposée, ou la page documentée de l'hôtel.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

La première requête interroge un point de détection de portail captif connu en HTTP simple ; une redirection ou un corps inattendu signifie que vous êtes encore derrière le portail. La seconde teste un site HTTPS normal. Si la première montre une interception et que la seconde échoue, la connexion est incomplète et le VPN n'y est pour rien.

Sur un appareil personnel, le coupe-circuit ou le VPN permanent doit peut-être être désactivé via la commande prise en charge du client pour que le portail puisse se charger. Fermez les applications sensibles pendant ce laps de temps et réactivez la protection immédiatement après. Sur un appareil géré, suivez la procédure approuvée par l'administrateur au lieu de retirer vous-même une stratégie.

Ne contournez jamais un avertissement de certificat et n'installez pas de certificat inconnu ni d'application auxiliaire pour vous connecter. Si le portail exige quelque chose d'inattendu, confirmez-le avec le personnel, et avec l'administrateur si l'appareil appartient à un employeur.

Conservez le profil d'origine et son erreur

Une fois l'accès ordinaire fonctionnel, connectez le profil d'origine et notez l'erreur exacte. Un rejet d'authentification est un problème de compte, un délai pendant la négociation est un problème de chemin, et un tunnel qui s'établit sans rien transporter est un problème de routage ou de stratégie.

Ces trois cas demandent des étapes différentes, et une capture de l'erreur vaut mieux qu'une description. Notez aussi l'heure, car les limites de session de l'hôtel peuvent expirer en une heure et produire une panne qui semble aléatoire. Si le client propose un journal, gardez la section autour de la première panne plutôt que le fichier entier. Cet extrait suffit généralement au propriétaire du profil pour identifier l'étape.

Si l'accès ordinaire fonctionne et que la négociation expire encore, demandez à l'hôtel s'il prend en charge ce trafic, et comparez avec un point d'accès fiable en gardant l'appareil et le profil constants. Travailler sur le point d'accès concentre l'attention sur le chemin de l'hôtel sans rien prouver sur le profil.

N'utilisez que les alternatives fournies par l'opérateur

Un profil TCP correspondant peut réussir là où le chemin UDP proposé échoue, mais seulement si le serveur écoute réellement sur ce transport et ce port. Le port TCP 443 n'est pas traité automatiquement comme du HTTPS ordinaire, et il ne garantit pas le passage à travers un réseau restrictif.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

Lancer le profil fourni avec une verbosité plus élevée garde la première erreur utile visible au lieu de l'écraser dans une boîte de dialogue générique. Utilisez le fichier fourni par l'opérateur plutôt que de modifier vous-même les ports ou les protocoles, car un changement local ne peut pas créer d'écouteur correspondant en face.

Si le tunnel se réinitialise à répétition, notez si le portail réapparaît ou si le signal local chute, et suivez les contrôles de stabilité au lieu de changer plusieurs protocoles à la fois. Testez ensuite l'application dont vous avez réellement besoin et rétablissez les contrôles de confidentialité habituels. Une connexion qui transporte un site mais pas un autre est une question de routage ou de stratégie, pas de portail.

Enfin, vérifiez la reprise après la mise en veille de l'ordinateur portable. L'autorisation du portail peut expirer indépendamment du tunnel, si bien qu'un appareil qui se reconnecte automatiquement peut revenir sur un réseau qui l'a déjà oublié. Rouvrir la page du portail est une étape normale, pas le signe que le VPN est en panne.