proto udp ou tcp-client: qual o seu servidor ouve?

Um perfil que funcionava no mês passado agora expira, e alguém sugere trocar proto udp por proto tcp-client. Às vezes é o passo certo, e às vezes produz um cliente que se liga a uma porta onde nada escuta, porque o servidor nunca foi configurado para o outro transporte. A diretiva descreve como o seu lado fala; não pode criar um ouvinte do outro lado. Leia o perfil e o servidor juntos antes de alterar qualquer um deles.

Leia o transporte que a conexão selecionada usa

Um perfil pode conter várias entradas remote, e cada uma pode indicar o seu próprio transporte. O cliente percorre-as em ordem, por isso a linha que vê primeiro não é necessariamente a que se aplica.

Encontre a entrada que está realmente a ser tentada e depois leia o seu transporte. A ordem importa, porque o cliente não passa à seguinte em silêncio. Algumas compilações só tentam a entrada seguinte depois de um tempo limite, por isso uma alternativa funcional no fim do ficheiro é alcançada segundos mais tarde do que espera. Observe no registo qual o endpoint que está a ser tentado em vez de presumir que a primeira linha ganhou.

Se o ficheiro tiver uma linha proto perto do topo e várias entradas remote por baixo, essa linha é o valor predefinido para qualquer remote que não a substitua. Uma edição local do valor predefinido não faz nada por uma entrada remote que indica o seu próprio transporte.

grep -nE '^(remote|proto)\b' client.ovpn

UDP e TCP não são um ajuste de velocidade

O UDP envia datagramas sem construir um fluxo ordenado, por isso o tráfego do próprio túnel não é envolvido num segundo transporte fiável. O TCP dá-lhe um caminho através de redes que descartam ou bloqueiam UDP, ao custo de uma retransmissão aninhada que pode fazer uma ligação com perdas parecer pior.

É uma troca de alcançabilidade, não uma classificação universal. A escolha certa é a que a rede à frente do cliente permite. Um caminho que descarta UDP na porta VPN nunca vai negociar, por melhor que o perfil esteja escrito. Teste o caminho e depois escolha o transporte.

Escolher entre eles apenas com base numa medição é um erro, porque a resposta depende do que a rede à sua frente permite. Um hotel ou um proxy corporativo pode permitir TCP de saída na 443 e mais nada, e é por isso que os fornecedores oferecem essa variante. Continua a ser uma ligação OpenVPN nessa porta, não uma sessão HTTPS, mesmo que o número da porta seja o conhecido.

O que tcp-client significa realmente

A diretiva do lado do cliente nomeia a extremidade que inicia uma ligação TCP. O lado do servidor usa a sua própria forma de escuta, e copiar a palavra do cliente para uma configuração de servidor produz um ouvinte que espera ser chamado, não um que aceita.

Coincidir significa que as duas extremidades concordam quanto ao transporte, não que partilham a mesma cadeia.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Pergunte ao servidor em que está a escutar antes de presumir que o perfil está errado. Um ouvinte UDP não aparece numa lista de sockets TCP, e o contrário também é verdade, por isso veja a vista específica do protocolo em vez de uma genérica.

Quando o perfil é importado mas nunca liga

Um perfil importado que expira imediatamente falha normalmente antes de qualquer autenticação. O pacote vai para uma porta sem ouvinte, ou a rede descarta-o em silêncio.

Teste o caminho da forma mais simples possível: ligue-se ao mesmo host e à mesma porta com o transporte que o perfil afirma, a partir da mesma rede do cliente que falha.

Se um teste UDP não obtiver nada e um teste TCP ligar, o servidor está a oferecer o outro transporte e o perfil está simplesmente desatualizado. Se nenhum responder, o problema está acima da escolha do transporte e nenhuma edição do perfil o corrigirá. Distinguir estes dois casos demora um minuto e poupa uma hora de depuração de certificados que nunca foi relevante.

Registe o transporte que funciona

Quando uma combinação funcionar, registe-a com o servidor, a porta e o protocolo, e anote de que rede foi testada.

Caso contrário, a próxima pessoa que encontrar um tempo limite repetirá a mesma experiência na direção oposta e talvez altere um servidor que estava bem.

Se o fornecedor publicar ambas as variantes, guarde ambos os ficheiros e etiquete-os segundo a rede a que se adequam. Dois perfis com nomes claros evitam a mistura acidental de um transporte de cliente com um ouvinte de servidor que nunca foi configurado para ele.