OpenVPN ou WireGuard? Decida pela identidade e pelo transporte

Comparar estes dois protocolos só é útil se comparar aquilo que vai realmente operar. O WireGuard identifica os pares por chave pública e transporta o seu protocolo sobre UDP, enquanto o OpenVPN oferece um conjunto mais amplo de formas de autenticação e pode funcionar sobre UDP ou TCP quando o servidor oferece ambas. Essas diferenças moldam o aprovisionamento e a via alternativa muito antes de moldarem o débito. Execute as quatro verificações abaixo por ordem; as duas primeiras decidem normalmente a escolha, e as duas últimas dizem se a decisão estava certa.

Comece pela identidade, não pela lista de cifras

Um par do WireGuard guarda uma chave privada e lista as chaves públicas que consegue alcançar. Um fornecedor pode envolver isto num portal de conta, mas o protocolo em si não tem troca de nome de utilizador e palavra-passe, por isso o ciclo de vida da conta vive naquilo que distribui as chaves. O OpenVPN pode usar certificados, um módulo contra um diretório existente ou um script de verificação, e é por isso que as organizações com um sistema de identidade o preferem muitas vezes. Nenhum dos dois desenhos elimina a pergunta sobre como se remove um dispositivo perdido.

Uma configuração curta não é o mesmo que um aprovisionamento simples. Entregar uma chave privada a várias pessoas torna a remoção posterior ambígua, porque revogá-la remove todas de uma vez. Escreva o mapeamento de pessoa para chave ou certificado antes de escolher, e a decisão sobre o protocolo torna-se muito mais fácil.

Depois veja o que o transporte permite

O protocolo do WireGuard usa UDP. Os serviços OpenVPN podem oferecer perfis UDP e TCP, e numa rede que bloqueia ou degrada UDP essa segunda opção é uma via alternativa prática e não teórica. O servidor tem de suportar o perfil que escolher, e mudar o número da porta não transforma o túnel em HTTPS nem convence uma firewall a permiti-lo.

Transportar TCP dentro de TCP também altera o comportamento em caso de perda, porque as duas camadas repetem e reordenam de forma independente. Um perfil TCP que funciona numa rede restritiva pode continuar a ter mau desempenho numa rede com perdas, e é uma razão para manter os dois perfis disponíveis em vez de declarar um superior.

Depois verifique o encaminhamento e a resolução de nomes

O AllowedIPs do WireGuard mapeia intervalos de endereços para os pares e funciona como uma decisão de encaminhamento dentro do protocolo, e as ferramentas em volta usam esses intervalos quando instalam rotas. O OpenVPN empurra rotas e opções de DNS a partir do servidor. Em ambos os casos o cliente pode subir com a política prevista apenas meio aplicada.

ip route show
ip -6 route show
resolvectl status
wg show

Leia a saída antes de confiar no indicador de ligação. ip route show lista o que o cliente instalou para IPv4, e a variante IPv6 deteta um túnel que transporta apenas uma família. resolvectl status mostra que resolução o cliente vai realmente consultar, e wg show imprime os AllowedIPs que o WireGuard julga possuir. Se a resolução ainda apontar para a rede local enquanto as rotas afirmam cobertura total, o DNS sai fora do túnel.

Depois meça a tarefa que lhe importa

Mantenha o dispositivo, a rede e o destino fixos, e registe os clientes e extremos que utilizou. Se os dois serviços saem em cidades diferentes ou correm em hardware diferente, diga-o, porque então o resultado descreve esses serviços e não os protocolos.

iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20

Execute os dois comandos duas vezes, uma por cada par de perfis, na mesma rede e no mesmo dispositivo. iperf3 dá um número de débito, e mtr dá o caminho e onde surgem perdas, algo que um único número de descarga não consegue mostrar. Um número de descarga também perde o que uma chamada nota: latência acrescida, jitter e quanto demora uma reconexão. Registe isso em separado, porque um protocolo que ganha em débito pode perder na tarefa que executa de facto.

Numa ligação gerida, a compatibilidade, o apoio e o esforço de renovação podem pesar mais do que uma pequena diferença na medição. Numa saída pessoal, o registo e a jurisdição do operador contam mais do que o rótulo do protocolo. Ambos os protocolos podem transportar uma boa ligação; o serviço e a sua configuração decidem o que obtém.

Anote o par de perfis antes de testar

Escolha um perfil por protocolo antes de medir e anote o que cada um deve fazer: apenas sub-redes privadas, ou todo o tráfego com uma saída específica. Um teste que compara um perfil de túnel dividido com um de túnel completo mede os perfis, não os protocolos. Coloque o nome do cliente, a versão do cliente e a localização da saída na mesma nota.

Depois execute a mesma tarefa em ambos, na mesma rede, na mesma sessão. Se um não conseguir ligar-se de todo, essa falha é o resultado e pertence ao registo com o motivo. Guarde o registo junto da documentação do serviço para que a pessoa seguinte compare o mesmo par em vez de recomeçar.