Separe os inicios de sesión do portal Wi-Fi dos do VPN
Dous sistemas distintos piden o mesmo: iniciar sesión. O portal controla o acceso local; o VPN, o acceso a unha rede privada. Pregunte en cada xanela quen pode verificar de verdade ese segredo.
Dous sistemas distintos pídenlle iniciar sesión antes de chegar a algo útil nunha rede pública: o Wi-Fi do local e a súa pasarela VPN. Parécense na pantalla e autorizan cousas completamente distintas. O portal decide se este dispositivo pode usar a rede local; o VPN decide se vostede pode chegar a unha rede privada noutro sitio. Mantéño separados facendo unha pregunta a cada xanela: quen pode verificar de verdade este segredo? O que segue é a lista de comprobación que aplico en hoteis, aeroportos e sedes de congresos, incluídos os puntos onde deixo de escribir.
Asigne cada inicio de sesión ao servizo que o comproba
Unha soa conexión de hotel pode implicar catro comprobacións separadas, e só algunhas queren a súa intervención. Póñaas en orde primeiro, porque a pantalla raramente di a que etapa pertence.
| 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 |
As redes 802.1X, comúns en oficinas e universidades, difuminan as dúas primeiras filas. Alí o inicio de sesión Wi-Fi é en si mesmo unha comprobación de identidade contra un servidor RADIUS, e o cliente pode presentar unha identidade de enrutamento mentres a conta real viaxa dentro do intercambio cifrado. Aínda así, a comprobación trata de unirse á rede; non autoriza o túnel, e a pasarela VPN non a acepta como proba de nada.
A orde importa máis que as etiquetas. Os portais cautivos existen porque o acceso pode concederse despois da asociación, e por iso un local pode entregar a páxina a un provedor especializado. O RFC 8952 da IETF trata o portal como un compoñente propio, así que un dominio descoñecido é un motivo para verificar, non unha proba de fraude por si mesmo. Compare o dominio coas instrucións escritas do local e os campos coa táboa.
Comprobe que pode pedir un portal
Os campos do portal tratan do dereito de acceso, non da identidade: número de cuarto, apelido da reserva, código de vale, o código impreso na funda da chave, un correo para un pase temporal, a aceptación de termos. O local xa sabe quen reservou o cuarto, así que pode cotexar eses datos sen aprender nada que lle permitise actuar como vostede noutro sitio.
Calquera cousa máis alá desa lista merece unha pausa. Unha páxina de punto de acceso non pode verificar o seu contrasinal de dominio, e tampouco pode verificar o seu código dun só uso do VPN, un código de recuperación ou unha clave privada, e non ten motivo para querelos. A única excepción lexítima é unha rede xestionada por unha organización: un SSID de convidados de oficina ou un Wi-Fi de congreso poden remitilo ao provedor de identidade que xa usa para o traballo. Segue sendo distinguible: o host de inicio de sesión é o seu diario, a pantalla de consentimento nomea o seu tenant e o fluxo ábrese nunha pestana visible do navegador.
O correo de mercadotecnia é aparte: un alias de viaxe satisface o campo sen entregar a súa identidade laboral.
Comprobe que o cliente VPN quere as súas propias credenciais
O cliente pide exactamente aquilo para o que está configurado o seu perfil, así que a xanela esperada é unha propiedade do perfil e non da rede na que estea. Os perfís de certificado adoitan mostrar unha elección de perfil e logo conectarse en silencio. Os perfís de usuario e contrasinal piden ambos, a miúdo cun código dun só uso. Os perfís SSO abren o seu navegador cara ao provedor de identidade e volven cun token. WireGuard é distinto outra vez: autentica dispositivos con clave pública e non ten inicio de sesión de usuario, así que unha xanela que ofrece usuario e contrasinal de WireGuard non describe WireGuard.
Lea o perfil antes de viaxar. En OpenVPN, auth-user-pass dille que se espera unha petición de contrasinal, mentres que cert, key ou pkcs12 significa que un certificado debería facer o traballo. Se un perfil que normalmente conecta sen petición pide de súpeto un contrasinal, sospeite dun perfil que non puido cargar o seu certificado ou que recorreu a outro método. Unha petición non é unha invitación a escribir o seu contrasinal de traballo en calquera xanela que apareza.
Ningún cliente VPN lexítimo pide o número de cuarto, o vale do portal ou a frase de contrasinal do Wi-Fi como entrada de autenticación. Cando iso ocorre, ou o cliente non é o que di ser, ou un portal cautivo intercepta o tráfico antes de que se forme o túnel e vostede está lendo unha páxina HTML deseñada para parecer un inicio de sesión.
Détase nestas cinco condicións
Estes son os puntos onde me deteño en lugar de seguir cunha solución alternativa plausible. Cada un é barato de comprobar e caro de equivocar.
- Aparece un aviso de certificado ou TLS no portal ou na páxina SSO. Non o pase facendo clic para chegar á rede.
- A páxina pide un segredo que só a pasarela VPN ou o provedor de identidade poden verificar: contrasinal de dominio, código dun só uso, código de recuperación, clave privada.
- O dominio non coincide coas instrucións impresas do local nin co host de inicio de sesión que a súa organización documenta para os seus propios servizos.
- Pídenlle instalar un certificado raíz, un perfil de configuración ou unha aplicación auxiliar que non procede da xestión dos seus dispositivos.
- Chega unha aprobación MFA que vostede non iniciou, ou o cliente VPN pide credenciais do hotel.
A alternativa non é outro contrasinal. Use un punto de acceso do teléfono, pregunte na recepción o nome exacto da rede e o método de acceso, e avise da páxina a quen xestione a rede ou ao seu servizo de TI. Nada diso esixe probar unha credencial contra unha páxina que non pode atribuír.
Atribúa un fallo á etapa correcta
Unha vez superadas ambas as etapas, os fallos seguen ocorrendo, e o erro adoita nomear a etapa se se le en orde: asociación, asignación de enderezo, autorización do portal, establecemento do túnel e despois o recurso interno. Cambiar un contrasinal do VPN porque un código do portal caducou perde tempo e deixa o problema real no seu sitio.
Unhas poucas probas separan as etapas. Tras o inicio de sesión do portal, solicite unha páxina HTTPS pública corrente. Se no seu lugar volve o portal, a autorización nunca se completou nesa capa. Se o cliente VPN informa de que non pode alcanzar a pasarela, o problema está por baixo do túnel: a sesión do portal, a resolución de nomes ou unha rede que bloquea o porto. Se o túnel se levanta e falla un nome de host interno, a resolución de nomes ou a política dentro da rede privada é o sospeitoso máis probable.
As sesións do portal tamén caducan con independencia do túnel. Cando o local revoga o acceso, unha conexión VPN establecida cae aínda que as súas credenciais nunca fosen incorrectas. Volva autorizar o portal, logo reconecte o VPN e deixe que renegocie. Rotar o contrasinal do VPN entón non arranxa nada e pode deixalo fóra.
Dea cada segredo só ao sistema que pode verificalo, e trate unha petición que non encaixa coa táboa como un sinal de stop e non como un paso que hai que sortear. Se ambas as etapas pasan e o túnel segue negándose, capture o erro exacto do cliente antes de cambiar calquera credencial.