OpenVPN ou IKEv2: quatro verificações antes de escolher um protocolo

A escolha entre OpenVPN e IKEv2 costuma ser discutida como uma questão de protocolo, e esse enquadramento desperdiça a decisão. O que decide é se o seu servidor e os seus dispositivos suportam o mesmo perfil completo, e se esse perfil resiste à forma como se desloca entre redes. As duas pilhas não se traduzem uma na outra: um ficheiro OVPN não é um perfil IKEv2 com sintaxe diferente. Quatro verificações, feitas por ordem, respondem à pergunta mais depressa do que qualquer tabela de funcionalidades.

Um cliente em falta acaba com a discussão

O Windows e o macOS trazem um cliente IKEv2, por isso um perfil IKEv2 não custa nada extra a implementar ali e herda as opções de aprovisionamento que o sistema operativo já expõe. OpenVPN nas mesmas máquinas significa um cliente de terceiros para instalar, atualizar e suportar, e esse cliente tem de aceitar todas as opções que o perfil usa. Conte as plataformas que tem de cobrir antes de comparar outra coisa, porque uma plataforma sem cliente funcional não é sequer um ponto de comparação.

No Windows, um comando lista os perfis que já existem e mostra de que tipo é cada um. O nome que imprime é o nome que as verificações seguintes usam.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

Um pedido para instalar um cliente é a resposta real para a coluna OpenVPN nessas plataformas, e é uma tarefa de implementação e não uma limitação do protocolo. Nenhuma das disposições elimina verificações de confiança, verificação de identidade ou manutenção. Pergunte como os perfis são distribuídos, como as credenciais são renovadas e como um dispositivo perdido é removido antes de se comprometer. Uma instalação simples ainda pode esconder um processo de recuperação que ninguém quer executar ao fim de semana.

A mobilidade é uma configuração conjunta, não uma promessa do protocolo

O IKEv2 pode usar MOBIKE quando ambas as pontas o suportam e ativam, o que permite ao cliente manter o túnel enquanto o endereço muda. RFC 4555 define a extensão, e a formulação condicional importa: um servidor que ignora a capacidade renegocia em vez disso. O resultado pode parecer idêntico numa transferência de ficheiro e muito diferente numa chamada em direto.

Teste a transição que realmente lhe importa, com algo a correr que possa observar. Deixe ping -t <internal-host> a correr no Windows, ou ping simples noutro sítio, depois passe de Wi-Fi para rede móvel e observe as falhas. Uma falha de MOBIKE aparece como reautenticação completa no registo do cliente, não como uma atualização silenciosa do endereço. O que está a medir é se o túnel sobrevive à mudança, não se o protocolo anuncia suporte.

Os clientes OpenVPN voltam a ligar-se conforme o comportamento da sua plataforma e os temporizadores do perfil, por isso o mesmo teste pode produzir outra forma de interrupção. Compare o acontecimento que importa aos seus utilizadores, não o rótulo no protocolo.

As credenciais pertencem ao serviço, não à pilha

Os certificados e outras formas de início de sessão pertencem ao serviço que termina a ligação. Um pedido de palavra-passe num cliente nada diz sobre compatibilidade com outro, e um perfil que funciona contra outro gateway nada diz sobre este. Mantenha as regras de identidade do servidor intactas enquanto compara as duas pilhas. Mudar de protocolo antes de identificar a falha produz normalmente um segundo perfil incompatível.

Inspecione a credencial que o cliente vai apresentar antes de culpar qualquer protocolo, porque um certificado expirado ou mal emitido falha da mesma forma nos dois. A saída abaixo mostra o sujeito, o emissor e as datas de validade sem ler a chave privada.

openssl x509 -in client.crt -noout -subject -issuer -dates

Para uma ligação da empresa, use o método que a empresa publica e deixe de tratar a comparação como uma experiência. Se estiver a comparar os dois por conta própria, verifique primeiro se ambas as opções terminam num único gateway, porque esse único detalhe decide quanto do seu resultado é sobre o protocolo. Uma rejeição que nomeia a credencial é um problema de credencial, e nenhuma quantidade de mudança de protocolo o repara.

Verifique o que o túnel realmente encaminha

Depois de ligar, confirme que a rota de que precisa existe e que os nomes são resolvidos. Um perfil pensado para recursos internos pode deixar a navegação comum no caminho local de propósito, e isso é uma decisão de política e não uma avaria. O que importa é se os destinos que a sua equipa usa são alcançáveis pelo túnel.

No Windows, dois comandos cobrem a rota e a pesquisa de nomes. Os equivalentes em Linux são ip route show default e resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Um túnel que sobe e não encaminha nada de útil é um resultado comum quando um perfil foi copiado entre serviços, e um teste de conectividade genérico não o mostra porque a interface está ativa. Teste o recurso que os seus utilizadores abrem primeiro, não um endereço público que qualquer caminho alcança. Se o nome resolve para um endereço público enquanto a rota aponta para dentro do túnel, a resposta DNS e a rota pertencem a decisões diferentes e ambas precisam de correção.

Pese a manutenção depois das verificações

Nenhum dos protocolos é mais fácil de manter em abstrato. A manutenção depende de quem opera o gateway, de como os perfis chegam aos dispositivos e da rapidez com que um dispositivo perdido perde o acesso. Um cliente de extremidade simples pode estar à frente de um servidor mais difícil de operar, e o contrário também acontece. Pergunte qual dos dois a sua equipa consegue manter a funcionar depois de a pessoa que o construiu sair.

Escolha a ligação suportada que cobre o trabalho e depois teste-a face ao acesso de que realmente precisa, e não face a uma lista de funcionalidades. Registe em que gateway termina cada opção, porque dois gateways diferentes tornam a comparação tanto sobre rotas como sobre protocolos. Repita as quatro verificações no dispositivo que vai realmente transportar e mantenha o perfil que passa nele.