Proveu un punt d'accés abans de deixar-hi a prop credencials de feina
Un portal intercepta el DNS i redirigeix HTTP abans d'autoritzar res. Feu una comprovació HTTPS nova, després proveu el túnel i manteniu els inicis de sessió de feina fora.
El punt d'accés dona una adreça abans de donar internet, i la confiança es decideix en aquesta escletxa. El dispositiu s'associa, demana una adreça, i llavors cada petició de sortida s'intercepta fins que un portal diu que la sessió està autoritzada. Aquest mecanisme explica per què una pàgina pot semblar que carrega mentre no hi ha cap connexió real. Proveu l'escletxa amb una cosa innòcua abans que cap credencial de feina la toqui.
Què fa el punt d'accés amb la vostra primera petició
L'associació dona un enllaç al dispositiu, i el DHCP li dona una adreça, una passarel·la i normalment un servidor DNS propietat del local. Fins que l'autorització no es completa, la passarel·la descarta o redirigeix el trànsit de sortida, i molts portals responen al DNS de cada nom amb la seva pròpia adreça. Per això una consulta sembla reeixir: la resposta és el portal, no el lloc que heu demanat. La xarxa es comporta tal com està dissenyada; simplement encara no és internet.
La primera petició HTTP normalment rep una redirecció al portal, que el sistema operatiu pot obrir per vosaltres. HTTPS no es pot redirigir així, de manera que o falla o s'encalla, i el navegador mostra un error de certificat o un temps d'espera esgotat. La diferència és diagnòstica: una redirecció HTTP és el portal que parla, mentre que una fallada TLS cap a un amfitrió no relacionat és una altra cosa. Un jardí emmurallat, on es deixen passar uns quants dominis per pagament o inici de sessió, produeix un tercer patró.
Confirmeu la xarxa abans d'iniciar sessió
Confirmeu l'SSID i el mètode d'inici de sessió amb el local per un canal que no sigui la mateixa xarxa. Un portal que demana una contrasenya corporativa, un número de targeta i una adreça de correu fa tres coses diferents, i només les dues últimes són habituals per a l'accés de convidats. Preferiu l'avís de portal captiu del sistema operatiu, que detecta la redirecció mitjançant un punt final conegut en lloc de confiar en qualsevol pàgina que aparegui. Si el local no pot descriure el seu propi portal, és un motiu per esperar i no per improvisar.
Un avís de certificat durant l'inici de sessió al portal no és un pas per saltar-se amb un clic. El portal no necessita fer-se passar per un amfitrió no relacionat per autenticar-vos.
Feu la comprovació més petita que demostri accés
Completeu l'autorització legítima, després demaneu una pàgina HTTPS pública corrent que no hàgiu carregat abans, perquè la resposta no pugui venir de la memòria cau. Anoteu què ha fallat realment si falla: una consulta de nom, un temps d'espera de connexió, un error de certificat o un refús del servei. Aquests quatre pertanyen a capes diferents, i anotar-los evita que la persona següent torni a provar a cegues. Després connecteu la VPN prevista i demaneu un recurs que la requereixi.
Mantingueu la prova petita. Una descàrrega de test de velocitat en accés amb límits respon una pregunta que ningú no ha fet i pot costar diners a l'usuari. Una resposta amb capçaleres n'hi ha prou per establir l'abastabilitat, i no baixa megabytes per un enllaç que factura per gigabyte.
Si l'accés corrent funciona i el túnel no, és una investigació diferent de la d'una xarxa que mai no ha autoritzat. Mantingueu els dos resultats separats en lloc de canviar diversos paràmetres de privadesa alhora.
Mantingueu la feina privada fora de la comparació
Cada aplicació del dispositiu és un observador potencial, i un portal captiu és el moment en què totes intenten arribar als seus servidors. Tanqueu les que pugueu, i tracteu un dispositiu gestionat sempre actiu com una qüestió de política i no tècnica: feu servir el mètode aprovat per a la comparació en lloc de treure la protecció que el fa gestionat. Si el dispositiu prohibeix del tot el trànsit fora del túnel, feu la comprovació en un altre dispositiu no sensible. El sentit de l'exercici és aprendre sobre la xarxa sense exposar-hi credencials.
No captureu el trànsit d'altres persones per diagnosticar el local, i mantingueu qualsevol captura de diagnòstic dins del vostre dispositiu i la vostra sessió. Reviseu els camps d'adreça i d'identificador abans d'adjuntar una captura a un tiquet, perquè la xarxa del local no és el vostre armari de proves.
Decidiu què us permet fer el resultat
Són possibles tres resultats: accés complet amb un túnel que funciona, accés només al portal amb un túnel que falla, o cap accés. Cadascun té un pas següent diferent, i el valor de la prova és saber en quin sou abans de canviar paràmetres. Accés complet vol dir que la feina pot continuar pel túnel; accés només al portal suggereix que el port o el protocol del túnel està bloquejat, així que la resposta és un altre transport o xarxa; cap accés vol dir que el local avui no pot suportar la tasca. Un dispositiu que només prova mai un protocol no pot distingir-los.
Anoteu l'SSID, el resultat i l'hora, perquè la persona següent al mateix local comenci amb proves. El guia de xarxes captives d'Apple descriu el comportament de detecció darrere de l'avís, que és la part que val la pena entendre abans de culpar la VPN.