Separeu els inicis de sessió del portal Wi-Fi dels del VPN
Dos sistemes diferents us demanen iniciar sessió: la Wi-Fi de l’espai i la vostra passarel·la VPN. A la pantalla semblen iguals i autoritzen coses ben diferents. Pregunteu a cada finestra: qui pot verificar realment aquest secret?
Dos sistemes diferents us demanen iniciar sessió abans d’arribar a res útil en una xarxa pública: la Wi-Fi de l’espai i la vostra passarel·la VPN. A la pantalla semblen iguals i autoritzen coses completament diferents. El portal decideix si aquest dispositiu pot usar la xarxa local; el VPN decideix si podeu arribar a una xarxa privada en un altre lloc. Els mantinc separats fent una pregunta a cada finestra: qui pot verificar realment aquest secret? El que segueix és la llista de comprovació que faig en hotels, aeroports i recintes de conferències, incloent-hi els punts on deixo d’escriure.
Mapa cada inici de sessió al servei que el comprova
Una única connexió d’hotel pot implicar quatre comprovacions separades, i només algunes volen la vostra entrada. Poseu-les en ordre primer, perquè la pantalla poques vegades diu a quina etapa pertany.
| Stage | Who checks it | What you give it | What it proves |
|---|---|---|---|
| Wi-Fi association | The access point | WPA2 passphrase or 802.1X credentials | That the device may join this SSID |
| Portal authorization | The venue or its portal provider | Room number, booking name, voucher, email or access code | That a guest may use local access |
| VPN authentication | Your gateway or identity provider | Client certificate, password, one-time code or SSO approval | That the user or device may enter the private network |
| Application login | Each internal service | That service's own account | That you may use that service |
Les xarxes 802.1X, habituals en oficines i universitats, difuminen les dues primeres files. Allà l’inici de sessió Wi-Fi és en si mateix una comprovació d’identitat contra un servidor RADIUS, i el client pot presentar una identitat d’encaminament mentre el compte real viatja dins de l’intercanvi xifrat. Fins i tot llavors la comprovació tracta d’unir-se a la xarxa; no autoritza el túnel, i la passarel·la VPN no l’accepta com a prova de res.
L’ordre importa més que les etiquetes. Els portals captius existeixen perquè l’accés es pot concedir després de l’associació, i per això un espai pot lliurar la pàgina a un proveïdor especialitzat. El RFC 8952 de l’IETF tracta el portal com un component propi, així que un domini desconegut és un motiu per verificar, no una prova de frau per si mateix. Comproveu el domini amb les instruccions escrites de l’espai, i els camps amb la taula.
Comproveu què pot demanar un portal
Els camps del portal tracten del dret d’accés, no de la identitat: número d’habitació, cognom de la reserva, codi de val, el codi imprès a la funda de la clau, un correu per a un passi temporal, acceptació dels termes. L’espai ja sap qui ha reservat l’habitació, així que pot fer coincidir aquestes dades sense aprendre res que li permeti actuar com a vosaltres en un altre lloc.
Qualsevol cosa més enllà d’aquesta llista mereix una pausa. Una pàgina de punt d’accés no pot verificar la vostra contrasenya de domini, ni pot verificar el vostre codi d’un sol ús del VPN, un codi de recuperació o una clau privada, i no té cap motiu per voler-los. L’única excepció legítima és una xarxa gestionada per una organització: un SSID de convidats d’oficina o una Wi-Fi de conferència us poden portar al proveïdor d’identitat que ja feu servir per a la feina. Encara es pot distingir: l’amfitrió d’inici de sessió és el vostre de cada dia, la pantalla de consentiment anomena el vostre tenant, i el flux s’obre en una pestanya visible del navegador.
El correu de màrqueting és a part: un àlies de viatge satisfà el camp sense lliurar la vostra identitat laboral.
Comproveu que el client VPN vol les seves pròpies credencials
El client demana exactament allò per a què està configurat el seu perfil, així que la finestra esperada és una propietat del perfil i no de la xarxa on us trobeu. Els perfils de certificat solen mostrar una tria de perfil i després connectar-se en silenci. Els perfils d’usuari i contrasenya demanen tots dos, sovint amb un codi d’un sol ús. Els perfils SSO obren el navegador cap al proveïdor d’identitat i tornen amb un testimoni. WireGuard és diferent una altra vegada: autentica dispositius amb clau pública i no té inici de sessió d’usuari, així que una finestra que ofereix usuari i contrasenya de WireGuard no descriu WireGuard.
Llegiu el perfil abans de viatjar. A OpenVPN, auth-user-pass us diu que s’espera una petició de contrasenya, mentre que cert, key o pkcs12 vol dir que un certificat hauria de fer la feina. Si un perfil que normalment es connecta sense cap petició demana sobtadament una contrasenya, sospiteu d’un perfil que no ha pogut carregar el certificat o ha recorregut a un altre mètode. Una petició no és una invitació a escriure la contrasenya de la feina a qualsevol finestra que hagi aparegut.
Cap client VPN legítim no demana el número d’habitació, el val del portal o la contrasenya de la Wi-Fi com a entrada d’autenticació. Quan passa això, o el client no és el que diu ser, o un portal captiu intercepta el trànsit abans que es formi el túnel i esteu llegint una pàgina HTML dissenyada per semblar un inici de sessió.
Atureu-vos en aquestes cinc condicions
Aquests són els punts on m’aturo en lloc de continuar amb una solució alternativa versemblant. Cadascun és barat de comprovar i car d’equivocar.
- Apareix un avís de certificat o TLS al portal o a la pàgina SSO. No el passeu clicant per arribar a la xarxa.
- La pàgina demana un secret que només la passarel·la VPN o el proveïdor d'identitat poden verificar: contrasenya de domini, codi d'un sol ús, codi de recuperació, clau privada.
- El domini no coincideix amb les instruccions impreses de l'espai ni amb l'amfitrió d'inici de sessió que la vostra organització documenta per als seus serveis.
- Us demanen d'instal·lar un certificat arrel, un perfil de configuració o una aplicació auxiliar que no prové de la gestió dels vostres dispositius.
- Arriba una aprovació MFA que no heu iniciat, o el client VPN demana credencials de l'hotel.
L’alternativa no és una contrasenya diferent. Feu servir el punt d’accés del telèfon, pregunteu a la recepció el nom exacte de la xarxa i el mètode d’accés, i informeu de la pàgina a qui gestiona la xarxa o al vostre servei d’IT. Res d’això no requereix provar una credencial contra una pàgina que no podeu atribuir.
Atribuïu una fallada a l’etapa correcta
Un cop passades totes dues etapes, les fallades encara passen, i l’error sol nomenar l’etapa si la llegiu en ordre: associació, assignació d’adreça, autorització del portal, establiment del túnel, i després el recurs intern. Canviar una contrasenya del VPN perquè un codi del portal ha caducat perd temps i deixa el problema real al seu lloc.
Unes quantes proves separen les etapes. Després de l’inici de sessió al portal, demaneu una pàgina HTTPS pública corrent. Si en lloc d’això torna el portal, l’autorització mai es va completar en aquella capa. Si el client VPN informa que no pot arribar a la passarel·la, el problema és sota el túnel: la sessió del portal, la resolució de noms o una xarxa que bloqueja el port. Si el túnel s’aixeca i un nom d’amfitrió intern falla, la resolució de noms o la política dins de la xarxa privada és el sospitós més probable.
Les sessions del portal també caduquen independentment del túnel. Quan l’espai revoca l’accés, una connexió VPN establerta cau encara que les seves credencials mai fossin incorrectes. Torneu a autoritzar el portal, després reconnecteu el VPN i deixeu que torni a negociar. Rotar la contrasenya del VPN llavors no arregla res i us pot deixar fora.
Doneu cada secret només al sistema que el pot verificar, i tracteu una petició que no encaixa amb la taula com un senyal d’aturada i no com un pas a evitar. Si totes dues etapes passen i el túnel encara refusa, captureu l’error exacte del client abans de canviar cap credencial.