Separe los inicios de sesión del portal Wi-Fi de los del VPN
Dos sistemas distintos piden lo mismo: iniciar sesión. El portal controla el acceso local; el VPN, el acceso a una red privada. Pregunte en cada ventana quién puede verificar de verdad ese secreto.
Dos sistemas distintos le piden iniciar sesión antes de llegar a algo útil en una red pública: el Wi-Fi del local y su puerta de enlace VPN. Se parecen en pantalla y autorizan cosas completamente distintas. El portal decide si este dispositivo puede usar la red local; el VPN decide si usted puede llegar a una red privada en otro sitio. Los mantengo separados haciendo una pregunta a cada ventana: ¿quién puede verificar de verdad este secreto? Lo que sigue es la lista de comprobación que aplico en hoteles, aeropuertos y sedes de congresos, incluidos los puntos donde dejo de escribir.
Asigne cada inicio de sesión al servicio que lo comprueba
Una sola conexión de hotel puede implicar cuatro comprobaciones separadas, y solo algunas quieren su intervención. Póngalas en orden primero, porque la pantalla rara vez dice a qué etapa pertenece.
| 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 |
Las redes 802.1X, comunes en oficinas y universidades, difuminan las dos primeras filas. Allí el inicio de sesión Wi-Fi es en sí mismo una comprobación de identidad contra un servidor RADIUS, y el cliente puede presentar una identidad de enrutamiento mientras la cuenta real viaja dentro del intercambio cifrado. Aun así, la comprobación trata de unirse a la red; no autoriza el túnel, y la puerta de enlace VPN no la acepta como prueba de nada.
El orden importa más que las etiquetas. Los portales cautivos existen porque el acceso puede concederse después de la asociación, y por eso un local puede entregar la página a un proveedor especializado. El RFC 8952 de la IETF trata el portal como un componente propio, así que un dominio desconocido es un motivo para verificar, no una prueba de fraude por sí mismo. Compare el dominio con las instrucciones escritas del local y los campos con la tabla.
Compruebe qué puede pedir un portal
Los campos del portal tratan del derecho de acceso, no de la identidad: número de habitación, apellido de la reserva, código de vale, el código impreso en la funda de la llave, un correo para un pase temporal, la aceptación de términos. El local ya sabe quién reservó la habitación, así que puede cotejar esos datos sin aprender nada que le permitiera actuar como usted en otro sitio.
Cualquier cosa más allá de esa lista merece una pausa. Una página de punto de acceso no puede verificar su contraseña de dominio, y tampoco puede verificar su código de un solo uso del VPN, un código de recuperación o una clave privada, y no tiene motivo para quererlos. La única excepción legítima es una red gestionada por una organización: un SSID de invitados de oficina o un Wi-Fi de congreso pueden remitirle al proveedor de identidad que ya usa para el trabajo. Sigue siendo distinguible: el host de inicio de sesión es el suyo diario, la pantalla de consentimiento nombra a su tenant y el flujo se abre en una pestaña visible del navegador.
El correo de marketing es aparte: un alias de viaje satisface el campo sin entregar su identidad laboral.
Compruebe que el cliente VPN quiere sus propias credenciales
El cliente pide exactamente aquello para lo que está configurado su perfil, así que la ventana esperada es una propiedad del perfil y no de la red en la que esté. Los perfiles de certificado suelen mostrar una elección de perfil y luego conectarse en silencio. Los perfiles de usuario y contraseña piden ambos, a menudo con un código de un solo uso. Los perfiles SSO abren su navegador hacia el proveedor de identidad y vuelven con un token. WireGuard es distinto otra vez: autentica dispositivos con clave pública y no tiene inicio de sesión de usuario, así que una ventana que ofrece usuario y contraseña de WireGuard no describe WireGuard.
Lea el perfil antes de viajar. En OpenVPN, auth-user-pass le dice que se espera una petición de contraseña, mientras que cert, key o pkcs12 significa que un certificado debería hacer el trabajo. Si un perfil que normalmente conecta sin petición pide de repente una contraseña, sospeche de un perfil que no pudo cargar su certificado o que recurrió a otro método. Una petición no es una invitación a escribir su contraseña de trabajo en cualquier ventana que aparezca.
Ningún cliente VPN legítimo pide el número de habitación, el vale del portal o la frase de contraseña del Wi-Fi como entrada de autenticación. Cuando eso ocurre, o el cliente no es lo que dice ser, o un portal cautivo intercepta el tráfico antes de que se forme el túnel y usted está leyendo una página HTML diseñada para parecer un inicio de sesión.
Deténgase en estas cinco condiciones
Estos son los puntos donde me detengo en lugar de seguir con una solución alternativa plausible. Cada uno es barato de comprobar y caro de equivocar.
- Aparece un aviso de certificado o TLS en el portal o en la página SSO. No lo pase haciendo clic para llegar a la red.
- La página pide un secreto que solo la puerta de enlace VPN o el proveedor de identidad pueden verificar: contraseña de dominio, código de un solo uso, código de recuperación, clave privada.
- El dominio no coincide con las instrucciones impresas del local ni con el host de inicio de sesión que su organización documenta para sus propios servicios.
- Le piden instalar un certificado raíz, un perfil de configuración o una aplicación auxiliar que no procede de la gestión de sus dispositivos.
- Llega una aprobación MFA que usted no inició, o el cliente VPN pide credenciales del hotel.
La alternativa no es otra contraseña. Use un punto de acceso del teléfono, pregunte en recepción el nombre exacto de la red y el método de acceso, y avise de la página a quien gestione la red o a su servicio de TI. Nada de eso exige probar una credencial contra una página que no puede atribuir.
Atribuya un fallo a la etapa correcta
Una vez superadas ambas etapas, los fallos siguen ocurriendo, y el error suele nombrar la etapa si se lee en orden: asociación, asignación de dirección, autorización del portal, establecimiento del túnel y después el recurso interno. Cambiar una contraseña del VPN porque un código del portal caducó pierde tiempo y deja el problema real en su sitio.
Unas pocas pruebas separan las etapas. Tras el inicio de sesión del portal, solicite una página HTTPS pública corriente. Si en su lugar vuelve el portal, la autorización nunca se completó en esa capa. Si el cliente VPN informa de que no puede alcanzar la puerta de enlace, el problema está por debajo del túnel: la sesión del portal, la resolución de nombres o una red que bloquea el puerto. Si el túnel se levanta y falla un nombre de host interno, la resolución de nombres o la política dentro de la red privada es el sospechoso más probable.
Las sesiones del portal también caducan con independencia del túnel. Cuando el local revoca el acceso, una conexión VPN establecida cae aunque sus credenciales nunca fueran incorrectas. Vuelva a autorizar el portal, luego reconecte el VPN y deje que renegocie. Rotar la contraseña del VPN entonces no arregla nada y puede dejarle fuera.
Dé cada secreto solo al sistema que puede verificarlo, y trate una petición que no encaja con la tabla como una señal de stop y no como un paso que hay que sortear. Si ambas etapas pasan y el túnel sigue negándose, capture el error exacto del cliente antes de cambiar cualquier credencial.