Distinguez les connexions au portail Wi-Fi des connexions VPN

Deux systèmes différents vous demandent de vous connecter avant d’atteindre quoi que ce soit d’utile sur un réseau public : le Wi-Fi du lieu et votre passerelle VPN. Ils se ressemblent à l’écran et autorisent des choses totalement différentes. Le portail décide si cet appareil peut utiliser le réseau local ; le VPN décide si vous pouvez atteindre un réseau privé ailleurs. Je les garde séparés en posant une question à chaque fenêtre : qui peut réellement vérifier ce secret ? Voici la liste de contrôle que j’applique dans les hôtels, les aéroports et les centres de conférence, y compris les points où j’arrête de taper.

Associez chaque connexion au service qui la contrôle

Une seule connexion d’hôtel peut impliquer quatre contrôles distincts, et seuls certains attendent une saisie de votre part. Mettez-les d’abord dans l’ordre, car l’écran indique rarement à quel stade il appartient.

Les réseaux 802.1X, courants dans les bureaux et les universités, brouillent les deux premières lignes. Là, la connexion Wi-Fi est elle-même un contrôle d’identité auprès d’un serveur RADIUS, et le client peut présenter une identité de routage tandis que le compte réel voyage à l’intérieur de l’échange chiffré. Même alors, le contrôle porte sur l’adhésion au réseau ; il n’autorise pas le tunnel, et la passerelle VPN ne l’accepte pas comme preuve de quoi que ce soit.

L’ordre compte plus que les étiquettes. Les portails captifs existent parce que l’accès peut être accordé après l’association, ce qui permet à un lieu de confier la page à un prestataire spécialisé. Le RFC 8952 de l’IETF traite le portail comme un composant à part entière, donc un domaine inconnu est une raison de vérifier, pas une preuve de fraude en soi. Comparez le domaine aux instructions écrites du lieu, et les champs au tableau.

Vérifiez ce qu’un portail est autorisé à demander

Les champs du portail relèvent du droit d’accès, pas de l’identité : numéro de chambre, nom de la réservation, code de bon, code imprimé sur la pochette de clé, e-mail pour un laissez-passer temporaire, acceptation des conditions. Le lieu sait déjà qui a réservé la chambre, il peut donc recouper ces informations sans apprendre quoi que ce soit qui lui permettrait d’agir comme vous ailleurs.

Tout ce qui dépasse cette liste mérite une pause. Une page de point d’accès ne peut pas vérifier votre mot de passe de domaine, et elle ne peut pas non plus vérifier votre code à usage unique VPN, un code de récupération ou une clé privée, et elle n’a aucune raison de les vouloir. La seule exception légitime est un réseau géré par une organisation : un SSID invité de bureau ou un Wi-Fi de conférence peut vous renvoyer vers le fournisseur d’identité que vous utilisez déjà pour le travail. Cela reste distinguable : l’hôte de connexion est le vôtre au quotidien, l’écran de consentement nomme votre tenant, et le flux s’ouvre dans un onglet de navigateur visible.

L’e-mail marketing est à part : un alias de voyage satisfait le champ sans livrer votre identité professionnelle.

Vérifiez que le client VPN veut ses propres identifiants

Le client demande exactement ce pour quoi son profil est configuré, donc la fenêtre attendue est une propriété du profil et non du réseau sur lequel vous vous trouvez. Les profils de certificat affichent généralement un choix de profil puis se connectent silencieusement. Les profils nom d’utilisateur et mot de passe demandent les deux, souvent avec un code à usage unique. Les profils SSO ouvrent votre navigateur vers le fournisseur d’identité et reviennent avec un jeton. WireGuard est encore différent : il authentifie les appareils par clé publique et n’a pas de connexion utilisateur, donc une fenêtre proposant un nom d’utilisateur et un mot de passe WireGuard ne décrit pas WireGuard.

Lisez le profil avant de voyager. Dans OpenVPN, auth-user-pass vous indique qu’une demande de mot de passe est attendue, tandis que cert, key ou pkcs12 signifie qu’un certificat doit faire le travail. Si un profil qui se connecte normalement sans demande réclame soudain un mot de passe, soupçonnez un profil qui n’a pas pu charger son certificat ou est retombé sur une autre méthode. Une demande n’est pas une invitation à taper votre mot de passe professionnel dans n’importe quelle fenêtre apparue.

Aucun client VPN légitime ne demande le numéro de chambre, le bon du portail ou la phrase secrète du Wi-Fi comme entrée d’authentification. Quand cela arrive, soit le client n’est pas ce qu’il prétend être, soit un portail captif intercepte le trafic avant que le tunnel se forme et vous lisez une page HTML habillée comme une connexion.

Arrêtez-vous à ces cinq conditions

Ce sont les points où je m’arrête plutôt que de continuer avec un contournement plausible. Chacun est bon marché à vérifier et coûteux à rater.

1. Un avertissement de certificat ou TLS apparaît sur le portail ou sur la page SSO. Ne le franchissez pas en cliquant pour atteindre le réseau.
2. La page demande un secret que seul la passerelle VPN ou le fournisseur d'identité peut vérifier : mot de passe de domaine, code à usage unique, code de récupération, clé privée.
3. Le domaine ne correspond pas aux instructions imprimées du lieu ni à l'hôte de connexion que votre organisation documente pour ses propres services.
4. On vous demande d'installer un certificat racine, un profil de configuration ou une application d'assistance qui ne vient pas de votre gestion des appareils.
5. Une approbation MFA arrive que vous n'avez pas lancée, ou le client VPN demande des identifiants d'hôtel.

Le repli n’est pas un autre mot de passe. Utilisez un partage de connexion de téléphone, demandez à la réception le nom exact du réseau et la méthode d’accès, et signalez la page à qui gère le réseau ou à votre service informatique. Rien de tout cela n’exige de tester un identifiant contre une page que vous ne pouvez pas attribuer.

Attribuez une panne au bon stade

Une fois les deux stades passés, des pannes surviennent encore, et l’erreur nomme généralement le stade si vous la lisez dans l’ordre : association, attribution d’adresse, autorisation du portail, établissement du tunnel, puis la ressource interne. Changer un mot de passe VPN parce qu’un code de portail a expiré fait perdre du temps et laisse le vrai problème en place.

Quelques sondes séparent les stades. Après la connexion au portail, demandez une page HTTPS publique ordinaire. Si le portail revient à la place, l’autorisation ne s’est jamais terminée à cette couche. Si le client VPN signale qu’il n’atteint pas la passerelle, le problème se situe sous le tunnel : la session du portail, la résolution de noms ou un réseau qui bloque le port. Si le tunnel monte et qu’un nom d’hôte interne échoue, la résolution de noms ou la politique à l’intérieur du réseau privé est le meilleur suspect.

Les sessions du portail expirent aussi indépendamment du tunnel. Quand le lieu révoque l’accès, une connexion VPN établie tombe alors même que ses identifiants n’ont jamais été faux. Réautorisez le portail, puis reconnectez le VPN et laissez-le renégocier. Faire tourner le mot de passe VPN ensuite ne règle rien et peut vous verrouiller dehors.

Ne donnez chaque secret qu’au système qui peut le vérifier, et traitez une demande qui ne correspond pas au tableau comme un panneau stop plutôt que comme une étape à contourner. Si les deux stades passent et que le tunnel refuse encore, capturez l’erreur exacte du client avant de changer le moindre identifiant.