Por que um perfil OpenVPN funciona em casa mas falha num hotel

O Wi-Fi do escritório e um quarto de hotel podem dar ao mesmo portátil duas redes muito diferentes, e o perfil no meio não sabe nada disso. O que funciona em casa pressupõe um uplink permissivo, resolução de nomes a funcionar e uma sub-rede local que não colide com nada do que o túnel transporta. Cada uma destas suposições pode falhar em separado.

A forma útil de depurar isto é tratar a rede como quatro factos separados e depois testá-los por ordem. Adivinhar o perfil primeiro costuma produzir uma alteração que não corrige nada e obscurece as provas.

Quatro factos de rede mudam entre locais

O primeiro facto é se a rede local o deixa sair de todo. Um portal cativo admite um dispositivo numa página de início de sessão e bloqueia tudo o resto até essa página estar concluída, o que significa que o túnel não pode arrancar, por mais correto que seja o perfil.

O segundo é a resolução de nomes. Um portal que interceta DNS responde a cada consulta com o seu próprio endereço, pelo que o nome de anfitrião da VPN é resolvido para o portal e o cliente tenta construir um túnel para uma página web.

O terceiro é a filtragem de transporte. As redes que querem permitir apenas a navegação deixam passar TCP 443 para destinos arbitrários e descartam quase tudo o resto, incluindo UDP.

O quarto é o endereçamento. A sub-rede local pode sobrepor-se a uma rede atrás do túnel, ou o uplink pode não oferecer qualquer caminho IPv4 utilizável.

Resolução de nomes e o portal cativo

Substitua o nome de anfitrião no perfil pelo endereço numérico do servidor e tente novamente. Se o IP liga e o nome não, a culpa é da resolução, e o perfil em si está bem.

Abra um navegador e tente uma página HTTP normal antes de tocar na VPN. Um redirecionamento para uma página de início de sessão significa que o portal ainda está pendente; conclua-o e volte a ligar. Muitos hotéis também expiram a sessão ao fim de algumas horas, o que parece uma desconexão a meio do dia e não um problema de início de sessão.

Se o endereço numérico também falhar, a resolução não é a explicação, por isso passe ao transporte. Guarde o endereço que testou, porque diz à verificação seguinte se os pacotes chegaram a sair da máquina.

Filtragem de transporte: primeiro UDP, TCP 443 como alternativa

Um fluxo OpenVPN sobre UDP 1194 não se parece com nada que uma firewall de hotel reconheça, por isso é descartado sem erro. O cliente tenta novamente até o seu tempo limite expirar, e o utilizador vê uma ligação que nunca se estabelece em vez de uma recusa. As firewalls que se comportam assim raramente registam o descarte num local visível. A ausência de recusa é ela própria a pista.

TCP 443 é a alternativa fiável porque a rede não o consegue distinguir de um HTTPS normal. Use o perfil TCP do operador quando existir, pois o servidor também tem de escutar nesse transporte e porta; alterar apenas o cliente produz outro tipo de falha. Se não existir perfil TCP, pergunte ao operador em vez de inventar um editando a porta. O lado do servidor tem de concordar, e uma divergência volta a parecer um problema de firewall.

Espere um custo de desempenho. TCP dentro de TCP amplifica as retransmissões num link com perdas, pelo que um túnel TCP que funciona pode ainda parecer lento numa rede de hotel congestionada. É uma troca por alcance, não um defeito a perseguir.

Colisões de endereços e uplinks sem IPv4

Um túnel pode estabelecer-se e não transportar nada. Quando a LAN local e uma rede remota partilham um prefixo como 192.168.1.0/24, o cliente considera o anfitrião remoto diretamente ligado e envia o pacote para a ligação local em vez do túnel. O sintoma é uma ligação bem-sucedida com uma sub-rede inalcançável, que se lê facilmente como um problema de rota do lado do servidor.

A correção permanente é mover a LAN remota para um intervalo privado pouco comum. Escolher um intervalo que ninguém usa em casa, como 10.42.0.0/24, evita o problema para cada local futuro em vez de apenas um. O contorno local é evitar esse hotel, hotspot ou router, o que não é correção nenhuma.

Os uplinks móveis acrescentam duas variantes. O NAT de nível de operador significa que as ligações de entrada não chegam, o que importa se aloja um servidor mas não para um cliente de saída. Um APN configurado apenas com IPv6 e tradução NAT64 pode fazer falhar um cliente que exige um caminho IPv4 real, e o remédio habitual é mudar o protocolo do APN para IPv4 ou pilha dupla.

Sintomas depois de o túnel estar levantado

Um túnel que liga e depois fica silencioso costuma ser um problema de keepalive ou de MTU, não de porta bloqueada. Uma ligação que cai após um número fixo de minutos aponta para um temporizador de keepalive ou de renegociação. Configure o cliente para sondar o seu par e reiniciar quando as respostas param, e teste um MTU de túnel menor se os ping funcionam enquanto as transferências grandes encravam.

Antes de pedir ajuda, anote três coisas: o endereço que tentou e se respondeu, o transporte e a porta que usou, e a sub-rede local da rede que falhou. Juntas, separam a resolução de nomes da filtragem de transporte e de uma colisão de endereços, e são essas as causas que sobrevivem ao contacto com as provas.