OpenVPN funciona em casa mas não numa rede: UDP ou TCP?

O mesmo perfil conecta-se em casa e trava numa rede de hotel, campus ou filial. As credenciais não mudaram, então a variável interessante é o caminho: o que acontece aos pacotes antes de OpenVPN os ler. Comparar quatro causas candidatas na ordem em que podem ser testadas é melhor do que adivinhar sobre certificados. Cada uma deixa um rastro diferente, e é o rastro que as separa.

Qual etapa falhou diz qual comparação importa

O log do cliente já registra até onde você chegou. Uma linha dizendo que a negociação da chave TLS não ocorreu dentro do tempo limite significa que um primeiro pacote saiu e nada utilizável voltou, o que aponta para o caminho. A rejeição de certificado parece totalmente diferente: chega uma resposta, e depois um erro específico de verificação nomeia o motivo. Anote a última linha antes do ciclo de repetição, porque é o valor que você compara entre redes.

Capture durante a nova tentativa, não depois. No cliente, tcpdump -ni any udp port 1194 mostra se alguma resposta volta. Repita na interface WAN de um servidor que você controla, o que revela se esses pacotes chegam ao outro extremo.

Tráfego unilateral é o resultado mais útil disponível aqui, porque transforma uma queixa intermitente numa direção a investigar. Guarde os arquivos de captura, porque o próximo relato do mesmo problema fecha-se mais facilmente com evidência do que com uma descrição.

Filtragem UDP versus porta fechada

Muitas redes de acesso tratam UDP sustentado como suspeito, e alguns ISPs concordam. Uma porta fechada produz o mesmo silêncio do lado do cliente. A diferença é a seletividade: um filtro costuma ser exigente quanto a quais destinos ou portas descarta, enquanto uma porta fechada recusa tudo o que é dirigido a essa porta.

Um perfil TCP na porta 443 é a solução habitual, porque se parece com um fluxo HTTPS comum e passa pela maioria dos portais captive e filtros de saída. Duas condições precisam valer. O servidor deve escutar com proto tcp-server e o cliente deve corresponder com proto tcp-client, e o operador precisa publicar esse endpoint alternativo. Reescrever um perfil UDP funcional para alegar TCP 443 não leva a lugar nenhum quando nada escuta do outro lado.

Porta fechada é problema de configuração, não de censura. Um servidor atrás de um roteador doméstico precisa do encaminhamento da porta UDP, e o firewall do roteador tem de permitir. Quando a porta nunca foi liberada, todo cliente falha na negociação independentemente das credenciais, e a falha segue o servidor em vez da rede.

Protocolos mais antigos saem mal nesse eixo. O PPTP exige TCP 1723 mais GRE, e GRE é o protocolo IP 47, não uma porta, então nenhum encaminhamento de porta comum o expressa.

Quando é o switch que descarta pacotes

Um switch gerenciável pode descartar o túnel de propósito. Alguns modelos HPE e Aruba expõem um controle de proteção contra flood UDP, às vezes rotulado Prevent UDP Blat Attack, na seção de segurança avançada. Uma vez ativo esse controle, um servidor atrás do switch não responde a nada e todo cliente expira do mesmo jeito. Desativá-lo e salvar a configuração em execução é todo o reparo, mas só depois de você estabelecer que o switch está realmente no caminho.

Contraevidência é o que separa um descarte do switch de um bloqueio do provedor. Leia os contadores da interface e o log de proteção contra flood antes de abrir um chamado no ISP. Roteadores domésticos com proteção DoS ou flood falham da mesma forma, e qualquer middlebox com timeout curto de inatividade UDP também. Um handshake que nunca termina sugere descarte, enquanto um túnel que morre após minutos de silêncio sugere o timeout.

Anote cada dispositivo entre o cliente e o servidor antes de mudar um perfil. Uma correção aplicada na camada errada parece certa até a próxima rede. Essa lista também diz ao próximo engenheiro onde olhar sem repetir toda a investigação.

Uma sobreposição de endereços que parece falha de DNS

Uma rede de acesso numerada dentro de 10.0.0.0/8 pode sobrepor-se ao pool do túnel, e o resolver costuma viver dentro desse pool. Quando um laptop recebe um endereço como 10.184.178.50 com máscara /8 no Wi-Fi, todo destino 10.x é local por definição. Pacotes para 10.4.0.1 então vão para a LAN, o túnel fica ativo e a resolução de nomes falha.

ip addr expõe a sobreposição de imediato, e ip route get 10.4.0.1 mostra onde o pacote realmente seria entregue. Como o sintoma visível é uma falha do resolver, esta costuma sobreviver a várias rodadas de mudanças de DNS.

Renumere o pool ou mantenha essa rede de acesso fora do escopo. Nenhuma configuração do lado do cliente recupera de uma sobreposição.

Escolher entre fallback TCP e correção do caminho

Escolha o fallback TCP quando você não controla o caminho e os usuários precisam trabalhar hoje, e aceite seus custos: TCP dentro de TCP comporta-se mal em links com perdas, e o fallback exige um listener que você opera. Escolha a correção do caminho quando o bloqueio está numa infraestrutura sua, porque uma regra de firewall é mais barata que um segundo listener. De qualquer modo, percorra as camadas em ordem: enlace, transporte externo, negociação, roteamento interno. A etapa que falhou naquela rede é o único fato que importa.

Registre o resultado por rede, não por usuário. O próximo relato da mesma falha começa então numa etapa conhecida, em vez de numa teoria sobre certificados. Esse registro também é o que justifica um segundo listener permanente, se algum dia for necessário.