O TCP 443 ajuda mesmo? Só se o servidor escutar nessa porta

O TCP 443 é uma alternativa com uma condição prévia, não um disfarce que enfia um túnel por qualquer filtro. Ajuda quando o operador já publica um ouvinte TCP nessa porta e o caminho tolera uma conexão que fica aberta durante horas. Falha, normalmente como tempo limite, quando falta uma das duas coisas, e o tempo limite raramente diz qual. Decidir se deve mudar exige três perguntas, e só uma delas trata do número da porta.

Um número de porta não é uma promessa de transporte

Uma porta nomeia um extremo; o TCP transforma-a num fluxo ordenado de bytes; OpenVPN decide o que viaja dentro desse fluxo. Um servidor web no mesmo número usa uma disposição de aplicação completamente diferente, por isso partilhar a porta 443 faz os dois parecerem iguais para um filtro e nada mais. O número é uma pista que um filtro lê, não uma propriedade que mude o que os pacotes contêm. Tratá-los como o mesmo porque partilham uma porta é o erro por trás da maior parte da confusão aqui.

Os equipamentos intermédios raramente tomam uma decisão simples de permitir ou negar sobre uma porta. Muitos inspecionam os primeiros bytes, alguns fixam um destino e outros reiniciam ligações que ficam abertas demasiado tempo. É por isso que o mesmo perfil pode funcionar numa rede e expirar noutra, e por isso vale a pena testar a alternativa como opção suportada em vez de confiar nela como promessa. Quando um filtro examina o tráfego, o número da porta é apenas a primeira coisa que olha.

Confirme o ouvinte antes de tocar no perfil

O servidor tem de estar configurado para TCP nessa porta, e o perfil do cliente tem de pedir o mesmo transporte. Reescrever um perfil UDP para pedir TCP não cria o ouvinte, e o tempo limite resultante não se distingue de uma firewall que descarta a porta. Descarregue o perfil TCP do próprio operador quando existir, porque alguns serviços publicam um extremo e definições de identidade separados para cada transporte. Editar à mão serve para um teste controlado e é uma má forma de adivinhar a configuração pretendida pelo fornecedor.

Os dois lados dessa correspondência aparecem na configuração, e as opções de ligação do projeto OpenVPN documentam as duas formas. O par mínimo tem este aspeto:

# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443

Três condições decidem se a alternativa compensa

A primeira condição é que o operador ofereça o transporte sequer; sem isso, nada mais importa. A segunda é que o caminho mantenha viva uma sessão de longa duração, já que algumas redes reiniciam ligações que ficam abertas em vez de bloquear a porta por completo. A terceira é se a alternativa é uma exceção deliberada ou um remendo que esconde uma avaria que não corrigiu.

Cada condição tem uma verificação barata. Uma falha em qualquer delas vê-se da mesma forma do lado do cliente:

Antes de comparar transportes, conclua qualquer início de sessão num portal cativo. Uma rede que não admitiu o seu dispositivo bloqueia ambos os transportes, e então a comparação mede o portal e não o túnel. Inicie sessão, confirme que a navegação normal funciona e só depois comece o teste.

O custo que aceita: TCP dentro de TCP

O TCP reenvia os segmentos perdidos e preserva a sua ordem. Quando uma aplicação que também usa TCP corre dentro de um túnel TCP, duas camadas de recuperação reagem à mesma perda, e é essa interação que faz o túnel parecer lento num caminho com perdas. O sintoma é atraso e jitter em vez de uma falha limpa, o que facilita culpar o extremo remoto. Meça a partir do cliente com ambos os transportes antes de tirar conclusões.

O UDP evita este aninhamento, e é a razão principal pela qual os operadores o preferem e só oferecem TCP como alternativa. Uma ligação TCP estável continua a ser mais útil do que uma UDP inalcançável, por isso a comparação é entre dois custos reais e não entre uma opção boa e uma má. Mantenha o dispositivo e a rede de acesso sem alterações enquanto compara, ou o resultado descreverá a variável errada.

Algumas funcionalidades do cliente estão documentadas apenas para um transporte, por isso um perfil alternativo pode deixar cair em silêncio um comportamento de que dependia. Leia o requisito de transporte da opção antes de tratar o perfil TCP como uma simples troca.

Avarias que outro transporte não toca

Um certificado expirado continua a precisar de uma verificação do relógio ou de uma renovação, e uma conta recusada continua a precisar das credenciais corretas. Mantenha as verificações de identidade do servidor fornecidas pelo operador, porque um número de porta familiar não autentica ninguém. Uma porta que responde diz apenas que algo está a escutar.

Se o túnel subir e os destinos continuarem a falhar, o problema restante é o encaminhamento ou a resolução de nomes após a ligação, não o transporte. Siga esse caminho em vez de andar às voltas pelas portas, porque é assim que se perde uma tarde. O perfil diz que transporte experimentar; nunca diz por que falhou o caminho UDP.