Cuánto sobrevive de un circuito al encapsulamiento VPN y si tus usuarios caben. Sobrecarga por paquete según los RFC: WireGuard, IPsec, OpenVPN, SSTP.
En un enlace IPv4 de 1500 bytes. La sobrecarga es por paquete e incluye la cabecera IP externa, así que el caudal útil sube con una MTU mayor.
| Protocolo y cifrado | Por paquete | Caudal útil | MTU del túnel | Efectivo |
|---|---|---|---|---|
| WireGuard VPN | 60 bytes | 96,00 % | 1440 bytes | 96,0 Mbps |
| OpenVPN (AEAD, AES-GCM) | 52 bytes | 96,53 % | 1448 bytes | 96,5 Mbps |
| IPsec ESP (AES-GCM) | 57 bytes | 96,20 % | 1443 bytes | 96,2 Mbps |
| IPsec ESP (AES-CBC + HMAC-SHA-256) | 77 bytes | 94,87 % | 1423 bytes | 94,9 Mbps |
| OpenVPN (CBC + HMAC-SHA-256) | 100 bytes | 93,33 % | 1400 bytes | 93,3 Mbps |
| L2TP/IPsec (AES-CBC + HMAC-SHA-256) | 99 bytes | 93,40 % | 1401 bytes | 93,4 Mbps |
| SSTP (PPP sobre TLS, AES-GCM) | 75 bytes | 95,00 % | 1425 bytes | 95,0 Mbps |
Las cifras son el coste de encapsulamiento por paquete con la MTU completa, tomado de la especificación de cada protocolo. El caudal real también está limitado por el rendimiento de cifrado y la tasa de paquetes de la pasarela, por las pérdidas del trayecto y por la proporción de tu tráfico que alcanza paquetes de tamaño máximo.
También podrías encontrar útiles estas calculadoras
MTU efectiva y TCP MSS con la sobrecarga real
Cuánta velocidad necesitas y cuánto tarda una transferencia
Calcula el producto ancho de banda-retardo y la ventana TCP necesaria
Calcula la latencia de red: retardos de propagación, transmisión y proceso
Una VPN no ralentiza un enlace en un porcentaje impreciso. Añade un número fijo de bytes a cada paquete, y esos bytes salen del mismo circuito que tu tráfico. En un enlace Ethernet de 1500 bytes, WireGuard sobre IPv4 gasta 60 de cada 1500 bytes en encapsulamiento, así que el 96 % del circuito transporta tráfico del túnel y el 4 % transporta cabeceras. Introduce el caudal de tu circuito y el número de personas que lo usan, y esta calculadora te da el caudal entregado, el déficit y el circuito que necesitarías para cubrir la demanda que realmente tienes.
Todo protocolo de tunelización envuelve tu paquete en cabeceras propias: una cabecera IP externa para encaminar el túnel, una cabecera de transporte cuando el protocolo usa una, la cabecera del propio protocolo y lo que añada el cifrado: un vector de inicialización, relleno de bloque y una etiqueta de autenticación. Al sumarlo todo obtienes el coste por paquete. Réstalo de la MTU del enlace y lo que queda es el paquete del túnel que cabe en una trama. La fracción del circuito que hace trabajo útil, el caudal útil, es esa carga útil dividida por la MTU. El cifrado importa más que el nombre del protocolo: OpenVPN con AES-GCM cuesta 52 bytes por paquete, y el mismo OpenVPN con AES-CBC y HMAC-SHA-256 cuesta 100.
Caudal útil y ancho de banda entregado
Trabaja hacia atrás desde la demanda que esperas: la calculadora indica el caudal de circuito necesario para entregar una cantidad dada de tráfico de usuario por un túnel dado, que siempre es mayor que el propio tráfico.
Compara cada protocolo y cifrado con tu propia MTU, uno al lado del otro, en bytes y en Mbps entregados, en lugar de confiar en una clasificación que da por supuesto el enlace de otra persona.
Cuando una sede de 500 Mbps registra 466 Mbps por el túnel y nada está roto, esto muestra los 34 Mbps que faltan como el coste de cabeceras que son.
Sube la MTU y observa cómo se mueve el caudal útil. En un enlace de centro de datos donde hay 9000 bytes disponibles, el mismo túnel desperdicia una fracción de lo que desperdicia con 1500.
Lo que ve un concentrador VPN es la concurrencia, no la plantilla total. Introduce la cifra simultánea y el caudal por usuario para obtener el número de sesiones que el circuito admite de verdad.
El mismo túnel que cuesta el 4 % de un enlace de 1500 bytes cuesta el 0,7 % de un enlace de tramas jumbo de 9000 bytes, porque el número de cabeceras es fijo y la carga útil no. Cualquier porcentaje único que se cite para un protocolo está dando por supuesta una MTU.
Los cifrados AEAD llevan una etiqueta de autenticación y ni HMAC aparte ni IV en el medio. Un cifrado CBC con HMAC aparte lleva un IV, relleno de bloque en el peor caso y un resumen completo. Entre esos dos, el coste por paquete de OpenVPN casi se duplica.
Una cabecera IPv6 externa ocupa 40 bytes donde IPv4 ocupa 20. Por eso WireGuard deja 1440 bytes en un enlace IPv4 y 1420 en IPv6, y por eso wg-quick usa 1420 por defecto: la cifra segura en ambos.
Saber que obtienes 466 Mbps de un circuito de 500 Mbps no te dice si caben 100 personas a 4,8 Mbps cada una. No caben, y sí habrían cabido en el circuito sin túnel. Esa diferencia es la razón de calcular esto antes de contratar ancho de banda.
Una pasarela VPN suele estar limitada por paquetes por segundo, no por megabits. Los paquetes pequeños multiplican a la vez el coste por paquete y el trabajo por paquete, así que un enlace lleno de paquetes cortos puede saturar una pasarela muy por debajo de su caudal nominal.
Con una MTU de 1500 bytes sobre IPv4, el coste de encapsulamiento por paquete es de 52 bytes para OpenVPN con AES-GCM, 57 para IPsec ESP con AES-GCM, 60 para WireGuard, 75 para SSTP, 77 para IPsec ESP con AES-CBC y HMAC-SHA-256, 99 para L2TP/IPsec y 100 para OpenVPN con AES-CBC y HMAC-SHA-256. Como proporción del circuito eso es el 3,5 % en el caso más barato y el 6,7 % en el más caro. Esas cifras suponen paquetes de tamaño máximo; un flujo de paquetes pequeños paga el mismo coste de cabeceras sobre mucha menos carga útil, así que la pérdida efectiva es mayor.
OpenVPN configurado con un cifrado AEAD, con 52 bytes por paquete sobre IPv4: ocho bytes menos que los 60 de WireGuard. En la práctica WireGuard suele ser el protocolo más rápido porque corre en el núcleo y su criptografía es económica, pero esa es una ventaja de CPU y de latencia, no de recuento de bytes. Sobrecarga y velocidad son preguntas distintas, y solo la sobrecarga es una cifra fija y calculable.
Porque IKEv2 no es un protocolo del plano de datos. El RFC 7296 lo describe como «un componente de IPsec que se usa para realizar autenticación mutua y establecer y mantener asociaciones de seguridad»: negocia claves y después ESP transporta el tráfico. Así que el coste por paquete de un túnel IKEv2/IPsec es simplemente el coste de ESP, y elegir IKEv2 no te dice nada sobre ancho de banda. Lo que sí cambia la cifra es la suite de cifrado de ESP, y por eso esta calculadora lista IPsec por cifrado y no por método de intercambio de claves.
Sí, 8 bytes por paquete en IPsec. El ESP nativo no lleva ninguna cabecera de transporte: el RFC 4303 especifica que la cabecera anterior a ESP lleva el número de protocolo 50, así que ESP va directamente dentro de IP. Cuando un túnel tiene que atravesar NAT, el RFC 3948 encapsula ese paquete ESP dentro de una cabecera UDP estándar para que el traductor tenga puertos con los que trabajar. Esos son los 8 bytes extra. WireGuard, OpenVPN y SSTP ya corren sobre UDP o TCP, así que el recorrido de NAT no les cuesta nada más.
Por dos razones, y solo una es de ancho de banda. Una cabecera TCP ocupa 20 bytes frente a los 8 de UDP, así que cada paquete carga 12 bytes más. El problema mayor es de comportamiento: pasar TCP dentro de un túnel TCP significa dos bucles independientes de retransmisión y control de congestión apilados uno sobre otro, de modo que un solo paquete perdido en la conexión externa detiene la interna mientras ambas se repliegan. Usa transporte TCP solo donde UDP esté bloqueado.
Divide el caudal entregado por el caudal por usuario, no el caudal del circuito por el caudal por usuario. Un circuito de 500 Mbps con OpenVPN y AES-CBC entrega unos 466 Mbps, así que a 5 Mbps por usuario admite 93 sesiones simultáneas en lugar de 100. La distinción importa sobre todo cerca del límite: una demanda que cabe en el circuito pero no en el túnel es un déficit causado enteramente por el encapsulamiento, y una MTU mayor o un cifrado más ligero lo resolverán sin más ancho de banda.
La reducen como proporción del circuito, porque el coste de cabeceras es por paquete y una trama de 9000 bytes transporta seis veces la carga útil de una de 1500. Los 60 bytes de WireGuard son el 4 % de un enlace de 1500 bytes y el 0,67 % de uno de 9000. La pega es que todos los dispositivos del trayecto tienen que coincidir en la MTU mayor, lo cual es realista dentro de un centro de datos y en general no lo es a través de la internet pública.