¿OpenVPN o WireGuard? Decida desde la identidad y el transporte

Comparar estos dos protocolos solo sirve si compara lo que realmente va a operar. WireGuard identifica a los pares por clave pública y transporta su protocolo sobre UDP, mientras que OpenVPN ofrece un conjunto más amplio de formas de autenticación y puede funcionar sobre UDP o TCP cuando el servidor ofrece ambas. Esas diferencias moldean el aprovisionamiento y la vía alternativa mucho antes de moldear el rendimiento. Ejecute las cuatro comprobaciones siguientes en orden; las dos primeras suelen decidir la elección, y las dos últimas dicen si la decisión fue correcta.

Empiece por la identidad, no por la lista de cifrados

Un par de WireGuard guarda una clave privada y enumera las claves públicas a las que puede llegar. Un proveedor puede envolver eso con un portal de cuenta, pero el protocolo en sí no tiene intercambio de usuario y contraseña, así que el ciclo de vida de la cuenta vive en lo que distribuye las claves. OpenVPN puede usar certificados, un complemento contra un directorio existente o un script de verificación, y por eso las organizaciones con un sistema de identidad suelen preferirlo. Ninguno de los dos diseños elimina la pregunta de cómo se retira un dispositivo perdido.

Una configuración corta no es lo mismo que un aprovisionamiento simple. Entregar una clave privada a varias personas hace ambigua la retirada posterior, porque revocarla las retira a todas a la vez. Escriba la correspondencia de persona a clave o certificado antes de elegir, y la decisión sobre el protocolo se vuelve mucho más fácil.

Luego mire qué permite el transporte

El protocolo de WireGuard usa UDP. Los servicios OpenVPN pueden ofrecer perfiles UDP y TCP, y en una red que bloquea o degrada UDP esa segunda opción es una vía alternativa práctica y no teórica. El servidor tiene que admitir el perfil que elija, y cambiar el número de puerto no convierte el túnel en HTTPS ni convence a un cortafuegos de que lo permita.

Llevar TCP dentro de TCP también cambia el comportamiento ante pérdidas, porque ambas capas reintentan y reordenan de forma independiente. Un perfil TCP que funciona en una red restrictiva puede rendir mal en una red con pérdidas, y esa es una razón para mantener disponibles ambos perfiles en lugar de declarar uno superior.

Luego compruebe el enrutamiento y la resolución de nombres

AllowedIPs de WireGuard asigna rangos de direcciones a los pares y actúa como una decisión de enrutamiento dentro del protocolo, y las herramientas del entorno usan esos rangos cuando instalan rutas. OpenVPN empuja rutas y opciones de DNS desde el servidor. En ambos casos el cliente puede levantarse mientras la política prevista solo se aplica a medias.

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

Lea la salida antes de confiar en el indicador de conectado. ip route show enumera lo que el cliente instaló para IPv4, y la variante IPv6 detecta un túnel que solo transporta una familia. resolvectl status muestra qué resolución consultará realmente el cliente, y wg show imprime las AllowedIPs que WireGuard cree poseer. Si el resolutor sigue apuntando a la red local mientras las rutas afirman cobertura total, el DNS sale fuera del túnel.

Luego mida la tarea que le importa

Mantenga sin cambios el dispositivo, la red y el destino, y anote los clientes y extremos que utilizó. Si los dos servicios salen en ciudades distintas o corren en hardware distinto, dígalo, porque entonces el resultado describe esos servicios y no los protocolos.

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

Ejecute ambos comandos dos veces, una por cada par de perfiles, en la misma red y el mismo dispositivo. iperf3 da una cifra de rendimiento, y mtr da la ruta y dónde aparecen las pérdidas, algo que una sola cifra de descarga no puede mostrar. Una cifra de descarga también pasa por alto lo que nota una llamada: latencia añadida, fluctuación y cuánto tarda una reconexión. Anótelo por separado, porque un protocolo que gana en rendimiento puede perder en la tarea que usted ejecuta de verdad.

En una conexión gestionada, la compatibilidad, el soporte y el esfuerzo de renovación pueden pesar más que una pequeña diferencia en la medición. En una salida personal, el registro y la jurisdicción del operador importan más que la etiqueta del protocolo. Ambos protocolos pueden transportar una buena conexión; el servicio y su configuración deciden lo que obtiene.

Anote el par de perfiles antes de probar

Elija un perfil por protocolo antes de medir y anote qué se supone que debe hacer cada uno: solo subredes privadas, o todo el tráfico con una salida concreta. Una prueba que compara un perfil de túnel dividido con uno de túnel completo mide los perfiles, no los protocolos. Ponga el nombre del cliente, la versión del cliente y la ubicación de salida en la misma nota.

Luego ejecute la misma tarea en ambos, en la misma red, en la misma sesión. Si uno no consigue conectarse en absoluto, ese fallo es el resultado y pertenece al registro con el motivo. Guarde el registro junto a la documentación del servicio para que la siguiente persona compare el mismo par en lugar de empezar de nuevo.