Testez un point d'accès avant de laisser des identifiants professionnels s'en approcher

Le point d'accès distribue une adresse avant de distribuer l'internet, et la confiance se décide dans cet écart. L'appareil s'associe, demande une adresse, puis chaque requête sortante est interceptée jusqu'à ce qu'un portail dise que la session est autorisée. Ce mécanisme explique pourquoi une page peut sembler se charger alors qu'aucune connexion réelle n'existe. Testez l'écart avec quelque chose d'inoffensif avant qu'un identifiant professionnel ne le touche.

Ce que le point d'accès fait à votre première requête

L'association donne un lien à l'appareil, et le DHCP lui donne une adresse, une passerelle et généralement un serveur DNS appartenant au lieu. Jusqu'à ce que l'autorisation soit terminée, la passerelle supprime ou redirige le trafic sortant, et beaucoup de portails répondent au DNS pour chaque nom avec leur propre adresse. Voilà pourquoi une résolution semble réussir : la réponse est le portail, pas le site demandé. Le réseau se comporte comme prévu ; il n'est simplement pas encore l'internet.

La première requête HTTP reçoit normalement une redirection vers le portail, que le système d'exploitation peut ouvrir pour vous. HTTPS ne peut pas être redirigé ainsi, donc il échoue ou reste bloqué, et le navigateur affiche une erreur de certificat ou un délai dépassé. La différence est diagnostique : une redirection HTTP est le portail qui parle, tandis qu'un échec TLS vers un hôte sans rapport est autre chose. Un jardin clos, où quelques domaines sont laissés passer pour le paiement ou la connexion, produit un troisième schéma.

Confirmez le réseau avant de vous connecter

Confirmez le SSID et la méthode de connexion avec le lieu par un canal qui n'est pas le réseau lui-même. Un portail qui demande un mot de passe d'entreprise, un numéro de carte et une adresse e-mail fait trois choses différentes, et seules les deux dernières sont ordinaires pour un accès invité. Préférez l'invitation du système d'exploitation pour le portail captif, qui détecte la redirection via un point de terminaison connu au lieu de faire confiance à n'importe quelle page qui apparaît. Si le lieu ne peut pas décrire son propre portail, c'est une raison d'attendre et non d'improviser.

Un avertissement de certificat pendant la connexion au portail n'est pas une étape à passer d'un clic. Le portail n'a pas besoin d'imiter un hôte sans rapport pour vous authentifier.

Faites la plus petite vérification qui prouve l'accès

Terminez l'autorisation légitime, puis demandez une page HTTPS publique ordinaire que vous n'avez pas chargée auparavant, afin que la réponse ne puisse pas venir du cache. Notez ce qui a réellement échoué si cela échoue : une résolution de nom, un délai de connexion, une erreur de certificat ou un refus de service. Ces quatre-là appartiennent à des couches différentes, et les écrire empêche la personne suivante de retester au feeling. Ensuite, connectez le VPN prévu et demandez une ressource qui l'exige.

Gardez le test petit. Un téléchargement de test de débit sur un accès limité répond à une question que personne n'a posée et peut coûter de l'argent à l'utilisateur. Une réponse avec des en-têtes suffit à établir l'accessibilité, et elle ne tire pas des mégaoctets par un lien facturé au gigaoctet.

Si l'accès ordinaire fonctionne et que le tunnel non, c'est une enquête différente de celle d'un réseau qui n'a jamais autorisé. Gardez les deux résultats séparés au lieu de changer plusieurs réglages de confidentialité à la fois.

Gardez le travail privé hors de la comparaison

Chaque application de l'appareil est un observateur potentiel, et un portail captif est le moment où toutes tentent de joindre leurs serveurs. Fermez celles que vous pouvez, et traitez un appareil géré toujours actif comme une question de politique et non de technique : utilisez la méthode approuvée pour la comparaison au lieu de retirer la protection qui le rend géré. Si l'appareil interdit totalement le trafic hors du tunnel, faites la vérification sur un autre appareil non sensible. Le but de l'exercice est d'apprendre sur le réseau sans lui exposer d'identifiants.

Ne capturez pas le trafic d'autres personnes pour diagnostiquer le lieu, et gardez toute capture de diagnostic dans les limites de votre appareil et de votre session. Vérifiez les champs d'adresse et d'identifiant avant de joindre une capture à un ticket, car le réseau du lieu n'est pas votre armoire à preuves.

Décidez de ce que le résultat vous permet

Trois issues sont possibles : un accès complet avec un tunnel fonctionnel, un accès au portail seulement avec un tunnel défaillant, ou aucun accès. Chacune a une étape suivante différente, et la valeur du test est de savoir dans laquelle vous êtes avant de changer des réglages. L'accès complet signifie que le travail peut continuer par le tunnel ; l'accès au portail seulement suggère que le port ou le protocole du tunnel est bloqué, donc un autre transport ou réseau est la réponse ; aucun accès signifie que le lieu ne peut pas prendre en charge la tâche aujourd'hui. Un appareil qui n'essaie jamais qu'un seul protocole ne peut pas les distinguer.

Notez le SSID, l'issue et l'heure, pour que la personne suivante au même endroit parte de preuves. Le guide des réseaux captifs d'Apple décrit le comportement de détection derrière l'invitation, et c'est la partie qui vaut la peine d'être comprise avant de blâmer le VPN.