Por que o portal cativo bloquea a túa VPN e como volver iniciar sesión

Nunha rede aberta, o teu punto de acceso non entrega paquetes a internet sen máis. Un punto de política augas arriba comproba se o teu dispositivo xa está autorizado, e ata que o estea, case todo se descarta. O teu cliente VPN le ese silencio como un servidor morto. Raramente o di: WireGuard reintenta unha aperta de mans no baleiro, OpenVPN informa dun tempo de espera de conexión, e IKEv2 volve co erro 809 sobre un servidor remoto que non responde.

Que controla realmente o portal

Un portal cativo son dúas cousas pegadas: un punto de decisión de política e un redireccionador. Cando o teu dispositivo se asocia e obtén unha concesión DHCP, a rede colócate nun estado previo á autorización.

Ese estado é un conxunto de regras de devasas. Normalmente permite DNS e permite HTTP ou HTTPS cara a unha lista curta de servidores do portal, e descarta todo o demais. A lista permitida é o xardín amurallado, e case nunca inclúe un extremo de VPN.

Ningún deses descartes é amable. Os paquetes dirixidos a un servidor VPN descártanse en lugar de rexeitarse, así que o cliente non recibe nin ICMP unreachable nin un reset de TCP, só a ausencia de resposta. Segundo o fabricante, o redireccionador pode responder ao porto 80 cunha redirección á páxina de inicio de sesión mentres o porto 443 se descarta ou se intercepta. As redireccións son fáciles de detectar porque levan unha resposta HTTP simple; a interceptación no 443 necesita un certificado no que o teu navegador se negará a confiar.

A autorización en si adoita estar ligada ao enderezo MAC do dispositivo, ás veces á IP concedida, e vive nunha táboa de sesións cun temporizador. Iniciar sesión crea unha entrada. A regra de devasas que deixa pasar o teu tráfico só existe mentres existe esa entrada, e por iso todo o problema volve máis tarde sen que cambie nada pola túa parte.

Por que a aperta de mans da VPN morre antes de comezar

Cada protocolo ten o seu propio transporte, e a devasa previa á autorización rompe cada un de forma distinta. IKEv2 en Windows e iOS vai sobre UDP 500 e UDP 4500; un descarte neses portos maniféstase como 809, ou como un fallo de estilo de resolución de nomes en clientes que informan das etapas por separado. OpenVPN sobre UDP 1194 queda en estado de conexión ata que expira o seu tempo de espera. OpenVPN sobre TCP 443 é o caso interesante, porque o portal pode completar a aperta de mans TCP e despois responder coa súa páxina de redirección, así que ves un erro TLS en lugar dun tempo de espera.

WireGuard mostra o mecanismo con máis claridade. É só UDP por deseño, sen alternativa TCP, así que unha devasa que descarta UDP descoñecido elimina o transporte por completo. O cliente segue enviando inicios de aperta de mans cun retroceso crecente e informa dunha aperta de mans que nunca se completa. Nada nesa mensaxe menciona o Wi-Fi, e nada nela suxire que debas abrir un navegador.

As plataformas intentan notar o estado antes que a túa VPN. Windows solicita un URL coñecido para decidir se mostra a súa notificación de inicio de sesión, Android pide un extremo que debería responder 204 No Content, e os dispositivos Apple abren unha pequena ventá de rede cativa. Esas sondas funcionan porque o portal responde cunha redirección en lugar do corpo esperado. O mesmo comportamento explica como un portal pode parecer perfectamente san mentres o teu túnel está morto: a sonda e o túnel xúlganse con regras distintas.

Que reinicia realmente unha caducidade de sesión

Os locais caducan sesións por motivos alleos á túa conta de VPN: un tempo de inactividade, unha duración máxima de sesión, unha nova concesión DHCP ou unha reasociación a outro punto de acceso. Cando salta o temporizador, a entrada da táboa de sesións desaparece e o conxunto de regras previo á autorización volve exactamente como estaba no rexistro.

Un túnel establecido adoita sobrevivir o suficiente para parecer san. As mensaxes de mantemento seguen saíndo, e se o cliente o nota depende de como trate o tráfico sen resposta, así que a luz de estado pode quedar verde un intre despois de que o camiño desapareza. Logo o túnel cae e cada intento de reconexión falla nos mesmos portos bloqueados.

Nese punto, o erro do cliente diche en que etapa estás, se o les con atención:

Un detalle engana a xente: cando a sesión está ligada a un enderezo MAC, recargar a páxina de inicio de sesión pode non axudar. Tes que romper a asociación e unirte de novo para que o portal vexa un novo intento de autorización en lugar dun caducado.

Primeiro inicia sesión, despois levanta o túnel

A orde que funciona é: autoriza o dispositivo, demostra o camiño, arrinca a VPN, demostra o túnel e logo restaura o teu bloqueo habitual. Ese último paso importa porque o estado temporal que necesitas para chegar ao portal é exactamente o estado que un interruptor de seguridade existe para impedir.

Un cliente de escritorio coa opción de bloquear fóra do túnel ten que pausarse para que cargue a páxina do portal, e deberías manter pechadas as aplicacións sensibles durante esa ventá fóra do túnel; é o único intervalo no que o tráfico local sae sen protección. Un dispositivo xestionado sempre acendido debería usar o procedemento que publicou o seu propietario en lugar de que ti elimines a política. Se o portal mostra un aviso de certificado, detente: aceptalo encamiña a túa sesión polo proxy de interceptación do local, e ese proxy pode ler todo o que envías. En Android, o bloqueo con VPN sempre activa bloquea o tráfico antes de que o túnel estea levantado, e algunhas compilacións non poden eximir o fluxo do portal; se a túa non pode, usa o acceso alternativo do local ou outro dispositivo en lugar de deixar o bloqueo desactivado. As regras de Apple baixo demanda pódense escribir para rexeitar o túnel ata que unha sonda teña éxito, que é o comportamento que queres en redes de hotel.

Verifica en orde coas ferramentas que xa tes. Antes do túnel, executa a sonda coas cabeceiras e o corpo ambos visibles, e observa se o teu transporte VPN recibe algunha resposta:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Antes da autorización, un portal normal dá unha de dúas respostas: un 302 cuxo Location apunta á páxina de inicio de sesión, ou un 200 cun corpo HTML que é a páxina do portal. Anota cal recibiches. Unha redirección non é un fallo antes de iniciar sesión; é o portal dicíndoche a onde ir. Despois de que o portal informe de éxito, repite o comando e espera un 200 cuxo corpo sexa a palabra literal Success. Esa cadea é o que fai significativa a sonda. Se o servidor responde con normalidade antes de que teñas iniciado sesión, nesta rede non hai portal de interceptación. Na captura, un descarte previo á autorización son paquetes saíntes dos que non volve nada, mentres que un camiño que funciona mostra unha resposta ao mesmo fluxo en cousa dun segundo. Conéctate e logo repite a captura.

Se o túnel segue fallando despois de que o portal diga si

O éxito do inicio de sesión non é o mesmo que un transporte permitido. Moitos locais permiten o portal e a navegación normal mentres bloquean UDP por completo, o que deixa WireGuard e OpenVPN sobre UDP rotos e TCP 443 funcionando. Se TCP 443 pasa e UDP non, iso é política do local e non un cliente que configurases mal, así que cambia de transporte ou acepta o límite e segue. Se unha reconexión segue fallando despois diso, garda o erro exacto; nomea a etapa na que estás atascado.

Outros fallos viven no dispositivo. Unha sesión aínda ligada a unha MAC antiga, un segundo adaptador Wi-Fi coa súa propia concesión, ou un cliente que memorizou a excepción de certificado do portal poden seguir fallando tras unha reautorización limpa. Rompe a asociación, volve autorizar e reintenta unha vez antes de tocar a configuración do cliente. RFC 8952 paga a pena lelo se queres a arquitectura que hai detrás dos compoñentes que estás vixiando.

Se o propio portal se nega a autorizar, o problema é da conta ou da asignación do dispositivo e ningunha configuración de VPN o arranxará. Cambiar o país de saída da VPN non reinicia o estado de acceso local do local; esa táboa está ligada ao teu dispositivo, non ao servidor que escollas. Pregunta ao operador do local e dálle tempo, porque a táboa de sesións é o que vai mirar.

Antes da túa próxima viaxe, anota tres cousas: a páxina do portal como paso cero, o paso de pausar o bloqueo para cada dispositivo que leves, e unha alternativa de transporte que probases de verdade. Cando un túnel que funcionaba hai dez minutos volva pararse, trátao como unha autorización caducada e volve comprobar o portal antes de tocar o perfil da VPN.