Pruebe un punto de acceso antes de acercarle credenciales de trabajo

El punto de acceso entrega una dirección antes de entregar internet, y la confianza se decide en ese hueco. El dispositivo se asocia, pide una dirección y entonces cada petición saliente queda interceptada hasta que un portal dice que la sesión está autorizada. Ese mecanismo explica por qué una página puede parecer que carga mientras no existe ninguna conexión real. Pruebe el hueco con algo inofensivo antes de que lo toque cualquier credencial de trabajo.

Qué hace el punto de acceso con su primera petición

La asociación da al dispositivo un enlace, y DHCP le da una dirección, una puerta de enlace y normalmente un servidor DNS propiedad del local. Hasta que se completa la autorización, la puerta de enlace descarta o redirige el tráfico saliente, y muchos portales responden al DNS de cada nombre con su propia dirección. Por eso una consulta parece tener éxito: la respuesta es el portal, no el sitio que pidió. La red se comporta como fue diseñada; simplemente todavía no es internet.

La primera petición HTTP recibe normalmente una redirección al portal, que el sistema operativo puede abrir por usted. HTTPS no se puede redirigir así, de modo que falla o se cuelga, y el navegador muestra un error de certificado o un tiempo de espera agotado. La diferencia es diagnóstica: una redirección HTTP es el portal hablando, mientras que un fallo de TLS hacia un host no relacionado es otra cosa. Un jardín amurallado, donde se dejan pasar unos pocos dominios para pago o inicio de sesión, produce un tercer patrón.

Confirme la red antes de iniciar sesión

Confirme el SSID y el método de inicio de sesión con el local por un canal que no sea la propia red. Un portal que pide una contraseña corporativa, un número de tarjeta y una dirección de correo hace tres cosas distintas, y solo las dos últimas son habituales para el acceso de invitados. Prefiera el aviso de portal cautivo del sistema operativo, que detecta la redirección mediante un extremo conocido en lugar de confiar en cualquier página que aparezca. Si el local no puede describir su propio portal, es un motivo para esperar y no para improvisar.

Una advertencia de certificado durante el inicio de sesión en el portal no es un paso que se salte con un clic. El portal no necesita hacerse pasar por un host no relacionado para autenticarle.

Haga la comprobación más pequeña que demuestre acceso

Complete la autorización legítima, luego solicite una página HTTPS pública corriente que no haya cargado antes, para que la respuesta no pueda venir de la caché. Anote qué falló realmente si falla: una consulta de nombre, un tiempo de espera de conexión, un error de certificado o un rechazo del servicio. Esos cuatro pertenecen a capas distintas, y anotarlos evita que la siguiente persona vuelva a probar a ciegas. Después conecte la VPN prevista y solicite un recurso que la requiera.

Mantenga la prueba pequeña. Una descarga de test de velocidad en acceso con límites responde a una pregunta que nadie hizo y puede costarle dinero al usuario. Una respuesta con encabezados basta para establecer la alcanzabilidad, y no arrastra megabytes por un enlace que factura por gigabyte.

Si el acceso corriente funciona y el túnel no, es una investigación distinta de la de una red que nunca autorizó. Mantenga los dos resultados separados en lugar de cambiar varios ajustes de privacidad a la vez.

Mantenga el trabajo privado fuera de la comparación

Cada aplicación del dispositivo es un observador potencial, y un portal cautivo es el momento en que todas intentan llegar a sus servidores. Cierre las que pueda, y trate un dispositivo gestionado siempre activo como una cuestión de política y no técnica: use el método aprobado para la comparación en lugar de quitar la protección que lo hace gestionado. Si el dispositivo prohíbe por completo el tráfico fuera del túnel, haga la comprobación en otro dispositivo no sensible. El sentido del ejercicio es aprender sobre la red sin exponerle credenciales.

No capture el tráfico de otras personas para diagnosticar el local, y mantenga cualquier captura de diagnóstico dentro de su propio dispositivo y sesión. Revise los campos de dirección e identificador antes de adjuntar una captura a un ticket, porque la red del local no es su armario de pruebas.

Decida qué le permite hacer el resultado

Son posibles tres resultados: acceso completo con un túnel que funciona, acceso solo al portal con un túnel que falla, o ningún acceso. Cada uno tiene un siguiente paso distinto, y el valor de la prueba es saber en cuál está antes de cambiar ajustes. Acceso completo significa que el trabajo puede seguir por el túnel; acceso solo al portal sugiere que el puerto o el protocolo del túnel está bloqueado, así que la respuesta es otro transporte u otra red; ningún acceso significa que el local hoy no puede soportar la tarea. Un dispositivo que solo prueba un protocolo no puede distinguirlos.

Anote el SSID, el resultado y la hora, para que la siguiente persona en el mismo local empiece con pruebas. La guía de redes cautivas de Apple describe el comportamiento de detección detrás del aviso, que es la parte que merece entenderse antes de culpar a la VPN.