Wi-Fi público e VPN: o que o túnel não cobre

Selo verde, portal satisfeito, navegador funcionando: essa é toda a história visível. O que o selo omite é que a conexão criptografada é transportada justamente pelo enlace sem fio do qual ela deveria protegê-lo. Esse enlace ainda entrega cada pacote, ainda vê o endereço de destino e ainda decide se algo chega. Percorrer o lado do laptop de uma conexão de hotel mostra quais partes o túnel cobre e quais deixa para você.

O enlace de acesso transporta tudo

Um túnel IPsec ESP envolve um pacote interno protegido dentro de um cabeçalho externo que a rede pode rotear, e RFC 4303 seção 3.1.2 expõe essa divisão. O pacote interno é o que o túnel protege. O cabeçalho externo é o que o hotspot lê para encaminhá-lo. Outros projetos encapsulam de forma diferente, mas a pergunta de planejamento é idêntica: qual caminho de acesso transporta esta conexão?

Uma falha de gateway ou um enlace que descarta pacotes interrompe a entrega sem revelar o conteúdo. Mudar para uma cifra mais forte não ajuda nisso, porque a peça que falta é o transporte, não a criptografia. Uma entrega bem-sucedida prova igualmente pouco na direção oposta, já que um caminho que funciona não diz nada sobre o estado de qualquer uma das duas máquinas.

Seu laptop ainda tem suas próprias portas

Entrar em um segmento não confiável muda quem pode alcançar as portas em que sua máquina escuta. Um serviço de compartilhamento de arquivos, um agente de administração remota ou um servidor de desenvolvimento vinculado a todas as interfaces é alcançável por qualquer um naquele segmento, a menos que algo o impeça. O tráfego que nunca entra no túnel não é protegido por ele. Um ouvinte que responde antes de o túnel estar ativo fica exposto exatamente durante essa janela.

O requisito é estreito e merece ser enunciado com precisão: o laptop deve alcançar o endpoint da VPN, e dispositivos não relacionados no hotspot não devem alcançar serviços locais. As regras do firewall do host expressam essa fronteira, e as próprias configurações de compartilhamento da plataforma também expressam parte dela. Uma impressora ou uma etapa do portal é uma exceção delimitada que você adiciona deliberadamente, não uma prova de que todo o hotspot mereça a confiança de uma LAN de escritório.

Algumas organizações também restringem o acesso local enquanto uma conexão de trabalho está ativa, e isso é política, não engenharia. Leia essa política antes de desativar um firewall para fazer um periférico funcionar.

Verifique o que está realmente escutando

Olhe para os sockets e não para a página de configurações, porque a página descreve a intenção e a tabela de sockets descreve a máquina. As duas listas abaixo separam cada socket que escuta daqueles que um vizinho poderia alcançar. Execute-as no segmento não confiável antes de conectar o túnel.

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

O primeiro comando mostra cada socket, e o segundo filtra os que estão vinculados além do loopback. Um serviço em 0.0.0.0 ou :: está disponível em todas as interfaces, inclusive a sem fio, enquanto o mesmo serviço em 127.0.0.1 não é alcançável a partir do segmento de forma alguma. A consulta ao resolvedor confirma qual caminho o nome toma antes de o túnel existir, e é aí que os portais cativos interferem. Repita a lista depois de conectar, porque alguns clientes levantam interfaces que mudam a resposta.

Uma porta que só aparece enquanto o túnel está ativo fica menos exposta, embora ainda valha a pena conhecê-la. Anote a diferença e não a lista absoluta, já que o delta é o que o túnel acrescentou.

Não aceite uma nova identidade no meio da sessão

Uma mudança de rota inesperada, uma reconexão ou um redirecionamento do portal não são permissão para aceitar uma identidade de servidor diferente. Se o cliente relatar divergência de certificado ou de chave, trate isso como uma constatação de identidade e não como uma conectividade a ser contornada. Instalar um certificado raiz sem explicação para fazer um portal funcionar transforma um problema de entrega em problema de confiança. E o problema de confiança sobrevive depois à viagem que o criou.

Use o fluxo de navegador do próprio portal, depois reconecte o túnel e leia no log do cliente qual identidade ele verificou. Uma falha de identidade significa que a contraparte não é quem você esperava, enquanto uma falha de entrega significa que a contraparte nunca respondeu. A primeira é motivo para parar, e a segunda é motivo para tentar outro caminho.

Decida primeiro o comportamento em caso de falha

Aqui se confundem duas funções diferentes. A reconexão tenta restabelecer o serviço, enquanto uma política de bloqueio controla qual tráfego é permitido enquanto o túnel está caído. Nenhuma das duas fornece um enlace sem fio funcional, e nenhuma prova que o endpoint está limpo. Escolha explicitamente: falha fechada para aplicativos que nunca devem usar o caminho local, e permitir navegação comum fora do túnel se isso for aceitável.

Anote a escolha, porque o padrão na maioria dos clientes não é nenhum dos dois, e varia conforme a versão. Depois providencie um caminho de acesso alternativo se a disponibilidade importar, como um hotspot de telefone com seu próprio plano de dados. Um teste de aceitação aceitável tem três resultados separados: o tráfego pretendido usa o túnel verificado, os ouvintes locais não relacionados são inalcançáveis, e uma falha produz o comportamento que você escolheu.