Porque é que o portal cativo bloqueia a sua VPN e como voltar a entrar

Numa rede aberta, o seu ponto de acesso não entrega pacotes à internet por si. Um ponto de política mais acima verifica se o dispositivo já está autorizado e, até estar, quase tudo é descartado. O seu cliente VPN lê esse silêncio como um servidor morto. Raramente o diz: o WireGuard repete o aperto de mão para o vazio, o OpenVPN reporta um tempo limite da ligação e o IKEv2 volta como erro 809 sobre um servidor remoto que não responde.

O que o portal controla realmente

Um portal cativo são duas coisas coladas: um ponto de decisão de política e um redirecionador. Quando o dispositivo se associa e obtém um lease DHCP, a rede coloca-o num estado antes da autorização.

Esse estado é um conjunto de regras de firewall. Normalmente permite DNS e permite HTTP ou HTTPS para uma lista curta de anfitriões do portal, e descarta tudo o resto. A lista permitida é o jardim murado, e quase nunca inclui o ponto final da VPN.

Nenhum destes descartes é educado. Os pacotes dirigidos ao servidor VPN são descartados em vez de rejeitados, pelo que o cliente não recebe ICMP unreachable nem TCP reset, apenas a ausência de resposta. Consoante o fabricante, o redirecionador pode responder no porto 80 com um redirecionamento para a página de entrada, enquanto o porto 443 é descartado ou intercetado. Os redirecionamentos são fáceis de detetar porque transportam uma resposta HTTP simples; a interceção no 443 exige um certificado em que o seu navegador se recusará a confiar.

A autorização em si está normalmente ligada ao endereço MAC do dispositivo, por vezes ao IP arrendado, e vive numa tabela de sessões com um temporizador. A entrada cria um registo. A regra de firewall que deixa passar o seu tráfego só existe enquanto esse registo existir, e é por isso que todo o problema volta mais tarde sem nada mudar do seu lado.

Porque é que o aperto de mão da VPN morre antes de começar

Cada protocolo tem o seu transporte, e a firewall antes da autorização quebra cada um de forma diferente. O IKEv2 no Windows e no iOS anda sobre UDP 500 e UDP 4500; um descarte nesses portos aparece como 809, ou como uma falha do tipo resolução de nomes em clientes que reportam as fases em separado. O OpenVPN sobre UDP 1194 fica em estado de ligação até o tempo limite expirar. O OpenVPN sobre TCP 443 é o caso interessante, porque o portal pode concluir o aperto de mão TCP e depois responder com a sua página de redirecionamento, pelo que vê um erro TLS em vez de um tempo limite.

O WireGuard mostra o mecanismo com mais clareza. É só UDP por design, sem alternativa TCP, pelo que uma firewall que descarta UDP desconhecido remove o transporte por completo. O cliente continua a enviar inícios de aperto de mão com um intervalo crescente e reporta um aperto de mão que nunca termina. Nada nessa mensagem menciona Wi-Fi, e nada nela sugere que deva abrir um navegador.

As plataformas tentam notar o estado antes da sua VPN. O Windows vai buscar um URL conhecido para decidir se mostra o aviso de entrada, o Android pede um ponto final que devia responder 204 No Content, e os dispositivos Apple abrem uma pequena janela de rede cativa. Estas sondas funcionam porque o portal responde com um redirecionamento em vez do corpo esperado. O mesmo comportamento explica como um portal pode parecer perfeitamente saudável enquanto o seu túnel está morto: a sonda e o túnel são avaliados por regras diferentes.

O que a expiração da sessão repõe realmente

Os locais expiram sessões por motivos alheios à sua conta VPN: um tempo limite de inatividade, um comprimento máximo de sessão, um novo lease DHCP ou uma nova associação a outro ponto de acesso. Quando o temporizador dispara, o registo na tabela de sessões desaparece e o conjunto de regras antes da autorização volta exatamente como estava no check-in.

Um túnel estabelecido sobrevive muitas vezes o tempo suficiente para parecer saudável. As mensagens de keepalive continuam a sair, e se o cliente as nota depende de como trata o tráfego sem resposta, pelo que a luz de estado pode ficar verde mais um tempo depois de o caminho desaparecer. Depois o túnel cai e cada tentativa de religação falha nos mesmos portos bloqueados.

Nesse momento o erro do cliente diz-lhe em que fase está, se o ler com atenção:

Um detalhe engana as pessoas: quando a sessão está ligada a um endereço MAC, recarregar a página de entrada pode não ajudar. Tem de largar a associação e voltar a juntar-se, para que o portal veja uma nova tentativa de autorização em vez de uma expirada.

Entre primeiro, depois levante o túnel

A ordem que funciona é: autorize o dispositivo, prove o caminho, inicie a VPN, prove o túnel e depois reponha o seu bloqueio habitual. Esse último passo é importante porque o estado temporário de que precisa para chegar ao portal é exatamente o estado que um interruptor de emergência existe para impedir.

Um cliente de ambiente de trabalho com a opção de bloquear fora do túnel tem de ser pausado para a página do portal carregar, e deve manter as aplicações sensíveis fechadas nessa janela fora do túnel; é o único intervalo em que o tráfego local sai sem proteção. Um dispositivo gerido sempre ligado deve usar o procedimento publicado pelo proprietário em vez de ser você a remover a política. Se o portal mostrar um aviso de certificado, pare: aceitá-lo encaminha a sessão pelo proxy de interceção do local, e esse proxy pode ler tudo o que envia. No Android, o bloqueio sob VPN sempre ligada trava o tráfego antes de o túnel subir, e algumas compilações não conseguem excluir o fluxo do portal; se a sua não consegue, use o acesso alternativo do local ou outro dispositivo em vez de deixar o bloqueio desligado. As regras on-demand da Apple podem ser escritas para recusar o túnel até uma sonda ter sucesso, e é esse o comportamento que quer em redes de hotel.

Verifique pela ordem com as ferramentas que já tem. Antes do túnel, corra a sonda com cabeçalhos e corpo ambos visíveis, e veja se o transporte da VPN recebe alguma 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 autorização, um portal normal dá uma de duas respostas: um 302 cujo Location aponta para a página de entrada, ou um 200 com um corpo HTML que é a página do portal. Anote qual recebeu. Um redirecionamento antes da entrada não é uma falha; é o portal a dizer-lhe para onde ir. Depois de o portal reportar sucesso, repita o comando e espere um 200 cujo corpo é a palavra literal Success. É essa cadeia que torna a sonda significativa. Se o anfitrião responde normalmente antes de alguma vez ter entrado, não há portal de interceção nesta rede. Na captura, um descarte antes da autorização são pacotes de saída dos quais nada volta, enquanto um caminho que funciona mostra uma resposta ao mesmo fluxo em cerca de um segundo. Ligue-se e depois repita a captura.

Se o túnel continuar a falhar depois de o portal dizer sim

O sucesso da entrada não é o mesmo que transporte permitido. Muitos locais permitem o portal e a navegação normal mas bloqueiam o UDP por completo, o que deixa o WireGuard e o OpenVPN sobre UDP avariados e o TCP 443 a funcionar. Se o TCP 443 passa e o UDP não, é a política do local e não um cliente mal configurado por si, por isso mude de transporte ou aceite o limite e siga. Se uma religação continuar a falhar depois disso, guarde o erro exato; ele nomeia a fase em que está preso.

Outras falhas vivem no dispositivo. Uma sessão ainda ligada a um MAC antigo, um segundo adaptador Wi-Fi com o seu próprio lease, ou um cliente que guardou a exceção de certificado do portal podem cada um continuar a falhar depois de uma reautorização limpa. Largue a associação, autorize de novo e tente uma vez antes de tocar nas definições do cliente. RFC 8952 vale a leitura se quiser a arquitetura por trás dos componentes que observa.

Se o próprio portal recusar autorizar, o problema está na conta ou na atribuição do dispositivo e nenhuma definição de VPN o corrige. Mudar o país de saída da VPN não repõe o estado de acesso local do local; essa tabela está ligada ao seu dispositivo, não ao servidor que escolhe. Pergunte ao operador do local e dê-lhe tempo, porque a tabela de sessões é o que ele vai olhar.

Antes da próxima viagem anote três coisas: a página do portal como passo zero, o passo de pausar o bloqueio para cada dispositivo que leva, e um transporte de recurso que tenha testado a sério. Quando um túnel que funcionava dez minutos antes parar outra vez, trate-o como uma autorização expirada e verifique o portal de novo antes de tocar no perfil da VPN.