OpenVPN ou WireGuard? Decida desde a identidade e o transporte
As claves, os fluxos de inicio de sesión e o transporte só por UDP moldean a escolla moito antes que o rendemento. Faga catro comprobacións e manteña a medición honesta.
Comparar estes dous protocolos só serve se compara o que realmente vai operar. WireGuard identifica os pares por clave pública e transporta o seu protocolo sobre UDP, mentres que OpenVPN ofrece un conxunto máis amplo de formas de autenticación e pode funcionar sobre UDP ou TCP cando o servidor ofrece ambas. Esas diferenzas moldean o aprovisionamento e a vía alternativa moito antes de moldear o rendemento. Execute as catro comprobacións seguintes en orde; as dúas primeiras adoitan decidir a escolla, e as dúas últimas din se a decisión foi correcta.
Comece pola identidade, non pola lista de cifrados
Un par de WireGuard garda unha clave privada e enumera as claves públicas ás que pode chegar. Un provedor pode envolver iso cun portal de conta, pero o protocolo en si non ten intercambio de usuario e contrasinal, así que o ciclo de vida da conta vive no que distribúe as claves. OpenVPN pode usar certificados, un complemento contra un directorio existente ou un script de verificación, e por iso as organizacións cun sistema de identidade adoitan preferilo. Ningún dos dous deseños elimina a pregunta de como se retira un dispositivo perdido.
| Decision | OpenVPN | WireGuard |
|---|---|---|
| Identity | Certificates, plugins or scripts against an existing directory | One private key per peer, public keys listed for the peers it may reach |
| Transport | UDP or TCP profiles when the server offers both | UDP only in the native protocol |
| Routing and DNS | Server pushes routes and DNS options | AllowedIPs maps ranges to peers, and tooling installs the routes |
| Where it usually breaks | Profile mismatch, expired certificate, failing plugin | Blocked UDP, wrong AllowedIPs, key not installed |
Unha configuración curta non é o mesmo que un aprovisionamento simple. Entregar unha clave privada a varias persoas fai ambigua a retirada posterior, porque revocala retíraas todas á vez. Escriba a correspondencia de persoa a clave ou certificado antes de escoller, e a decisión sobre o protocolo vólvese moito máis doada.
Despois mire que permite o transporte
O protocolo de WireGuard usa UDP. Os servizos OpenVPN poden ofrecer perfís UDP e TCP, e nunha rede que bloquea ou degrada UDP esa segunda opción é unha vía alternativa práctica e non teórica. O servidor ten que admitir o perfil que escolla, e cambiar o número de porto non converte o túnel en HTTPS nin convence un cortalumes de que o permita.
Levar TCP dentro de TCP tamén cambia o comportamento ante perdas, porque ambas as capas reintentan e reordenan de forma independente. Un perfil TCP que funciona nunha rede restritiva pode render mal nunha rede con perdas, e esa é unha razón para manter dispoñibles ambos os perfís en lugar de declarar un superior.
Despois comprobe o encamiñamento e a resolución de nomes
AllowedIPs de WireGuard asigna rangos de enderezos aos pares e actúa como unha decisión de encamiñamento dentro do protocolo, e as ferramentas da contorna usan eses rangos cando instalan rutas. OpenVPN empurra rutas e opcións de DNS desde o servidor. En ambos os casos o cliente pode levantarse mentres a política prevista só se aplica á metade.
ip route show
ip -6 route show
resolvectl status
wg showLea a saída antes de confiar no indicador de conectado. ip route show enumera o que o cliente instalou para IPv4, e a variante IPv6 detecta un túnel que só transporta unha familia. resolvectl status mostra que resolución consultará realmente o cliente, e wg show imprime as AllowedIPs que WireGuard cre poses. Se o resolutor segue apuntando á rede local mentres as rutas afirman cobertura total, o DNS sae fóra do túnel.
Despois mida a tarefa que lle importa
Manteña sen cambios o dispositivo, a rede e o destino, e anote os clientes e extremos que utilizou. Se os dous servizos saen en cidades distintas ou corren en hardware distinto, dígao, porque entón o resultado describe eses servizos e non os protocolos.
iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20Execute ambos os comandos dúas veces, unha por cada par de perfís, na mesma rede e no mesmo dispositivo. iperf3 dá unha cifra de rendemento, e mtr dá a ruta e onde aparecen as perdas, algo que unha soa cifra de descarga non pode mostrar. Unha cifra de descarga tamén pasa por alto o que nota unha chamada: latencia engadida, fluctuación e canto tarda unha reconexión. Anóteo por separado, porque un protocolo que gaña en rendemento pode perder na tarefa que vostede executa de verdade.
Nunha conexión xestionada, a compatibilidade, o soporte e o esforzo de renovación poden pesar máis que unha pequena diferenza na medición. Nunha saída persoal, o rexistro e a xurisdición do operador importan máis que a etiqueta do protocolo. Ambos os protocolos poden transportar unha boa conexión; o servizo e a súa configuración deciden o que obtén.
Anote o par de perfís antes de probar
Escolla un perfil por protocolo antes de medir e anote que se supón que debe facer cada un: só subredes privadas, ou todo o tráfico cunha saída concreta. Unha proba que compara un perfil de túnel dividido cun de túnel completo mide os perfís, non os protocolos. Poña o nome do cliente, a versión do cliente e a localización da saída na mesma nota.
Despois execute a mesma tarefa en ambos, na mesma rede, na mesma sesión. Se un non consegue conectarse en absoluto, ese fallo é o resultado e pertence ao rexistro co motivo. Garde o rexistro xunto á documentación do servizo para que a seguinte persoa compare o mesmo par en lugar de comezar de novo.