VPN bajo el microscopio: cómo realmente viajan los paquetes en el túnel y dónde se pierden los bytes

Qué es lo que realmente hace el VPN con los paquetes

El camino del paquete IP sin VPN

Empecemos por lo simple. Imagina que tienes un paquete IP normal desde tu laptop hasta un servidor. Este recibe la dirección MAC local del gateway, llega al router del proveedor, hace un par de saltos y se entrega tranquilamente al destinatario. Mínima magia, pura enrutación. Sin envolturas extras, solo el encabezado original IPv4 o IPv6, más el encabezado de transporte TCP o UDP, y la carga útil. Simple y efectivo.

Ahora míralo desde la perspectiva de un switch: el frame llega, la tabla L2 indica el puerto, el frame sale. A nivel L3 el router consulta la tabla de enrutamiento, actualiza el TTL, y posiblemente fragmenta si el MTU es demasiado pequeño. Y ya está. Así vives hasta que necesitas un canal seguro o acceso a una red remota. Entonces aparece el VPN y comienza a reempaquetar ese mismo paquete IP como una matrioska.

El camino del paquete IP a través del túnel

Con VPN la cosa se pone más divertida. Tu paquete IP original ya no va directo a Internet. El cliente lo encapsula en un paquete nuevo: añade un encabezado IP exterior (hacia el servidor VPN), encima un UDP o ESP, y a veces un encabezado adicional del protocolo del túnel. El paquete interno se convierte en la "carga útil". Está cifrado y oculto, como una carta dentro de un sobre que a su vez va dentro de otro más opaco.

En la salida, el servidor VPN quita esta capa exterior, verifica la autenticación, descifra y saca del túnel el paquete IP interno original. Este tiene una segunda oportunidad para pasar por el internet habitual, pero ya en nombre del nodo del servidor o mediante enrutamiento a la red corporativa. ¿Costoso? Sí. Pero seguro y manejable, si calculas bien el overhead y el MTU.

Transporte vs túnel: dónde está la frontera

Recuerda esta regla simple. Transporte es cómo enviamos los paquetes (UDP, TCP, QUIC), y túnel es cómo los empaquetamos y dónde los desempaquetamos. Algunos VPN usan UDP como transporte (WireGuard, OpenVPN-UDP), otros su propio protocolo a nivel IP (ESP en IPsec). Pero ambos hacen lo mismo: encapsulan tu paquete IP original en uno externo.

Nos interesa la frontera técnica: entre la carga útil interna y el transporte externo. Ahí nace el overhead. Ahí se rompe el PMTUD. Ahí aparece la latencia por cifrado. Vamos a analizar esa línea de corte, capa por capa, para entender por qué los paquetes se fragmentan de repente y las conexiones TCP se ralentizan aunque tengas 1 Gbps contratado.

Dónde se esconde la criptografía

El cifrado está entre el paquete interno y el transporte externo. En IPsec ESP es el texto cifrado sobre el paquete interno más campos propios de ESP y ICV. En WireGuard se cifra solo la parte útil del Data Message, mientras los encabezados UDP y IP externo quedan visibles. En OpenVPN se cifra el contenido del protocolo propio sobre UDP o TCP, frecuentemente con HMAC y opcionalmente TLS para el canal de control.

Un punto clave: la criptografía impone alineación, añade etiquetas de autenticidad (usualmente 16 bytes) y puede requerir IV o nonce. Estos bytes no desaparecen; aumentan el tamaño de cada paquete. Por eso hay que reducir el MTU en la interfaz túnel o limitar el MSS para conexiones TCP internas, para evitar que los paquetes se fragmenten y se pierdan en la eterna danza de la fragmentación.

Encapsulación por capas: muñecas anidadas

IP externo e interno

La imagen mínima es esta: el paquete IP interno lo genera la aplicación y luego el cliente VPN lo coloca dentro de un contenedor externo. Este contenedor es un nuevo encabezado IP dirigido al servidor del túnel. Así que ahora tenemos dos IPs: la interna indica el destino dentro de la lógica segura, la externa indica cómo llegar al concentrador VPN. En Wireshark se ven dos niveles de IP, pero el interno suele estar oculto hasta que descifres el tráfico en el endpoint.

Este doble IP es la esencia de los términos «modo túnel» y «modo transporte» en IPsec. En modo túnel tienes un encabezado IP nuevo completo y el interno está totalmente oculto. En modo transporte solo se cifra la carga útil, y el IP externo es el original. Para rutas corporativas y acceso remoto se usa preferentemente modo túnel.

UDP o TCP como sobre para el túnel

Muchas veces los túneles usan UDP como transporte. ¿Por qué? Es más simple y estable para atravesar NAT, tiene menos overhead por control de congestión y menos latencia por pérdidas. WireGuard usa justamente esto: UDP sobre IP externo, con paquete cifrado dentro. OpenVPN en modo UDP es similar. OpenVPN en TCP es otro cuento: un "VPN dentro de TCP" que funciona con proxies estrictos, pero provoca el famoso colapso TCP-over-TCP — dos controles de congestión que chocan y generan latencia.

Cuando se usa ESP (protocolo 50 a nivel IP), puede no haber UDP externo. Pero en la práctica se ve mucho NAT-T: ESP encapsulado en UDP puerto 4500 para engañar al NAT. Esto añade 12 bytes (UDP 8 + 4 bytes Non-ESP Marker) y pasa sin problemas por routers caseros y equipos del proveedor.

Marcado por protocolo: ESP, GRE, L2TP

En el nivel externo se reconoce el túnel por el protocolo. ESP es número 50, AH 51, GRE 47, L2TP usa UDP puerto 1701, WireGuard suele UDP 51820 (pero se cambia para camuflar), OpenVPN UDP 1194 por defecto y TCP 443 para conservadores. Estos números son clave para filtros tcpdump, Wireshark y políticas de firewall.

La marca ayuda a identificar qué vemos: si es esp, es IPsec; si gre, hay otro IP o protocolo L3 encima; si udp.port==51820, probablemente WireGuard. Un dato curioso: algunos proveedores en 2026 intensificaron el DPI en UDP con patrones anómalos, por eso VPN basados en QUIC ganan fuerza y algunos esconden el túnel en tráfico HTTP/3. Pero eso ya es camuflaje a nivel transporte.

Fragmentación y reensamblado

La encapsulación aumenta el tamaño del paquete. Si supera el MTU del enlace, el router fragmenta o envía ICMP "Fragmentation Needed" si está activado el DF. En VPN muchas veces vemos fragmentación invisible en paquetes externos y pérdidas que afectan el rendimiento. Cada fragmento es trabajo extra y riesgo de reinicios o timeouts en TCP.

La estrategia correcta: calcular anticipadamente el tamaño final y reducir el MTU en el túnel. O limitar el MSS para sesiones TCP (reduciendo el tamaño del segmento para que entre en el MTU con margen para las capas). En 2026, la mayoría de redes de proveedores siguen con MTU 1500, así que calcular MSS entre 1360 y 1380 para IPsec NAT-T no es snobismo, es pura necesidad práctica.

Encabezados y su estructura: de bits al significado

IPv4 e IPv6: campos críticos para VPN

En IPv4 importan: Total Length, Identification, Flags (DF, MF), Fragment Offset, TTL, Protocol, Header Checksum. DF indica "no fragmentar" y el ICMP Tipo 3 Código 4 avisa cuando el MTU es menor. En IPv6 cambian los mecanismos: no hay checksum en el encabezado, la fragmentación la hace el emisor y los routers no fragmentan. Por eso PMTUD es vital en IPv6, o el túnel falla con paquetes grandes.

Otro detalle: Traffic Class y Flow Label. Afectan QoS y el comportamiento en redes con prioridad. En túneles VPN el IP externo puede transportar un QoS y el interno otro, lo que hace importante la copia de DSCP. Muchos admins en 2026 copian el DSCP interno al externo en IPsec para mantener la prioridad en voz y video.

UDP y TCP: números de servicio y efectos invisibles

El encabezado UDP es simple: puerto origen, puerto destino, longitud, checksum — 8 bytes. Mínimo overhead, ideal para túneles. TCP es más complejo: 20 bytes base más opciones (MSS, SACK, timestamps). Un TCP interno con MSS 1460 funciona bien en Ethernet puro, pero en túnel queda justo. Por eso introdicimos MSS Clamping — reducimos el MSS en paquetes SYN a la fuerza.

Con TCP hay un problema sutil llamado "colapso TCP-over-TCP". El TCP externo (por ejemplo OpenVPN sobre TCP) y el interno reaccionan a pérdidas y latencias por separado. Resultado: latencia alta, jitter y tráfico "pegajoso" bajo carga. No es mito. Mejor evitar TCP sobre TCP salvo necesidad extrema.

ESP: SPI, Secuencia, IV, Padding, ICV

El paquete ESP incluye encabezado ESP (SPI 4 bytes, Número de secuencia 4 bytes), datos cifrados (IP interno y transporte), trailer ESP (relleno, longitud de relleno, siguiente encabezado) y datos de autenticación ESP (ICV, usualmente 16 bytes para GCM). Con AES-GCM a menudo hay IV explícito de 8 bytes y etiqueta de autenticidad de 16 bytes. NAT-T añade UDP 8 bytes y Non-ESP Marker 4 bytes, aumentando el tamaño.

En modo túnel IPsec añade otro encabezado IP externo (20 bytes para IPv4, 40 para IPv6). El padding depende del alineamiento del cifrado en bloques y puede consumir varios bytes por paquete. Conclusión: ESP tiene constantes estables y parte variable. En cálculos reales se asumen 50–70 bytes overhead para IPv4 con NAT-T y 70–90 bytes para IPv6 para no fallar.

OpenVPN y WireGuard: diferencias a nivel paquete

OpenVPN sobre UDP añade un encabezado pequeño, HMAC y, según configuración, IV/nonce. Normalmente el overhead ronda 36–60 bytes más IP y UDP externos. En modo TCP se suma encabezado TCP y envoltorio TLS en el canal de control, mejorando estabilidad en redes exigentes pero penalizando latencia y rendimiento con pérdidas.

WireGuard es minimalista. El Data Message incluye encabezado interno (destinatario, contador) y carga cifrada con etiqueta Poly1305 de 16 bytes. En práctica, vemos unos 32 bytes de encabezado WG sobre 8 bytes UDP y 20/40 bytes IP, o sea entre 60 y 80 bytes por paquete. No es perfecto, pero es predecible y rápido, especialmente en hardware con aceleración ChaCha20-Poly1305.

Overhead sencillo: el costo del túnel

Fórmula básica y ejemplos

Overhead es la suma de todos encabezados externos y bytes de servicio criptográfico añadidos al paquete interno. La fórmula aproximada: Overhead = IP externa + Transporte externo (UDP/TCP) + Encabezado túnel (ESP, WG, OpenVPN, GRE...) + Etiqueta criptográfica + Padding/IV/nonce + Alineación. Parece complicado, pero es aritmética simple.

Ejemplo. Un segmento TCP interno con payload de 1400 bytes. Túnel IPsec NAT-T con AES-GCM: IPv4 externo 20 bytes, UDP 8, Non-ESP Marker 4, encabezado ESP 8, IV 8, ICV 16 y padding 2–6 bytes. Total unos 66–70 bytes. Así que el paquete final queda en unos 1470 bytes. En enlaces con MTU 1500 cabe, pero al límite. Cualquier opción TCP o IPv6 puede desequilibrar la balanza y causar fragmentación.

IPsec ESP: transporte y túnel, NAT-T y cálculo

En modo transporte IPsec no añade IP externa, ahorrando 20/40 bytes. Pero para acceso remoto suele usarse modo túnel. Allí se añade IP externa y el overhead es notable: IPv4 ESP sin NAT-T suele ser 42–60 bytes, con NAT-T 54–74 bytes según campos y padding. Para IPv6 suman otros 20 bytes por encabezado IP más largo.

Regla práctica: con IPsec NAT-T pon MTU del túnel en 1400–1420 y MSS clamp en 1360–1380. No son números arbitrarios: reflejan la suma típica de encabezados y dejan margen para evitar fragmentación. Siempre testea con ping -M do y paquetes grandes para confirmar que PMTUD no falla en un firewall raro.

WireGuard, OpenVPN UDP y TCP: referencias en bytes

WireGuard suele añadir unos 60 bytes overhead en IPv4, 80 en IPv6. Por eso la recomendación estándar es MTU 1420 en la interfaz wg0, un punto medio ideal. OpenVPN-UDP varía según cifrado y HMAC, generalmente 50–80 bytes extra sobre IP/UDP. Por eso MTU 1400–1450 y MSS clamp 1360–1420 resuelven el 90% de los problemas.

OpenVPN-TCP es otro cantar. Suma 20 bytes TCP (sin opciones) y mecanismos de control de congestión. En canales estrechos o ruidosos TCP sobre TCP sufre. A veces ayuda TCP Fast Open o ajustes cuidadosos de buffers, pero en general es mejor quedarse en UDP y sortear proxies con otras técnicas, incluso QUIC.

GRE, L2TP, VXLAN: comparación breve

GRE suma mínimo 4 bytes en el encabezado base, pero a menudo añade Key y Checksum, total 8–12 bytes más IP externo. Con el IP encapsulado en GRE llegamos a 24–28 bytes sobre IP externo. L2TPv2 opera sobre UDP (8 bytes) y añade 6–12 bytes de encabezado L2TP más PPP, sumando 14–24 bytes antes del cifrado o sobre IPsec.

VXLAN está orientado a encapsulación L2 para data centers: UDP 8 + VXLAN 8 + IP y MAC externas para la capa de enlace. En VPN es raro, pero el principio es igual: cada byte de encabezado reduce el espacio útil. Cuantas más "capas" anidadas, más importa configurar bien el MTU y evitar fragmentos inesperados.

MTU, MSS y velocidad real

Cómo calcular el MTU para tu túnel

El algoritmo es sencillo. 1) Determina el overhead total de tu stack (por ejemplo, 68 bytes para IPsec NAT-T IPv4). 2) Réstalo de 1500 si tu underlay es Ethernet sin jumbo frames. 3) Añade un margen de 10–20 bytes para variaciones (opciones TCP, campos inesperados). 4) Configura ese MTU en la interfaz túnel y verifica con ping DF aumentando el tamaño paulatinamente.

Ejemplo: WireGuard en router doméstico. Calculamos unos 60–64 bytes overhead en IPv4. 1500−64=1436. Redondeamos a 1420 (recomendación general) para garantizarnos margen. Luego ajustamos MSS clamp a 1360–1380 y comprobamos descargas grandes y VoIP. Si desaparecen los "lags" y fragmentos perdidos, estás en casa.

MSS Clamping: cómo domar rápido al TCP

MSS (Maximum Segment Size) es la máxima cantidad de datos TCP en un segmento. Si el túnel recorta MTU hay que reducir MSS para evitar fragmentación. Se hace modificando MSS en paquetes SYN en el borde. Casi todos los gateways modernos y routers SOHO en 2026 hacen esto con dos clics.

Práctico: para MTU 1420 ponemos MSS 1360. Para MTU 1400, MSS 1360 suele funcionar bien, considerando opciones TCP impredecibles. Verifica con tcpdump que el SYN lleva el MSS esperado. Si notas retransmisiones extrañas y picos RTT, baja el MSS 10–20 bytes y prueba otra vez.

Jumbo frames, PMTUD y bit DF

Los jumbo frames (MTU >1500) facilitan la vida, pero no siempre están disponibles. En data centers sí, en internet no mucho. PMTUD debería funcionar perfecto: el emisor ajusta el tamaño al eslabón más pequeño. En realidad, ICMP suele bloquearse y el emisor nunca sabe que un paquete no pasa. Por eso surgen conexiones "colgadas" y parones misteriosos.

Si controlas ambos extremos, activa PMTUD y no bloquees ICMP Tipo 3 Código 4. Si no, toma el control: MTU conservadora, MSS clamp y pruebas explícitas de ping con DF. Entiendo que es aburrido, pero funciona y ahorra horas de troubleshooting.

Presets prácticos para 2026

El mercado reduce todo a esta lista corta: WireGuard IPv4 — MTU 1420, MSS 1360; IPsec NAT-T IPv4 — MTU 1400–1420, MSS 1360–1380; OpenVPN-UDP — MTU 1400–1450, MSS 1360–1420; IPv6 en ese stack resta otros 20 bytes. Y no olvides el jitter: jitter bajo constante suele ser más importante que subir MTU 20–30 bytes.

En 2026 muchos proveedores aplican QoS Per-Hop Behavior en troncos y VPN corporativos ya copian DSCP del IP interno al externo. Si la voz suena más clara tras esa copia, no te sorprendas. Los paquetes finalmente tienen el nivel de prioridad que merecen.

Práctica: capturas y análisis en Wireshark

Filtros para tcpdump y Wireshark

¿Filtros rápidos? Para IPsec: esp o udp port 4500 (NAT-T), más isakmp en udp 500 para IKEv2. Para WireGuard: udp port 51820 (o tu custom). Para OpenVPN-UDP: udp port 1194. Para L2TP: udp port 1701. Para GRE: ip proto 47. Por IP: filtro host para el IP del servidor VPN, para no saturar con tráfico del entorno.

Receta: en cliente tcpdump -ni eth0 udp port 51820 y host X.X.X.X — mostrará solo WireGuard hacia ese nodo. En servidor, revisa interfaces externas para pérdidas y el túnel (wg0, tun0, ipsecX) para comparar sentidos. Diferencias en contadores indican dónde hay pérdidas o problemas con PMTUD.

Leemos campos de paquetes manualmente

En Wireshark expande paquete ESP. ¿Ves SPI y Secuencia? SPI identifica qué SA tiene el paquete. Secuencia incrementa con cada paquete — marcador útil de pérdidas y duplicados. En WireGuard fíjate en Counter — contador monotónico que evita repeticiones y ordena paquetes. OpenVPN tiene encabezados más simples pero distingue Key ID y tipo de mensaje.

Chequea IP externa: TTL, bit DF, tamaño. IP interna suele estar oculta, pero en hosts finales verás desempaquetado en la interfaz del túnel. Si ves fragmentación externa busca quién rompe el MTU. Si crecen errores ICV revisa claves, desincronización o daños en ruta. Lógica simple que ahorra horas.

Depuración de MTU y fragmentos: trucos rápidos

El comando ping -M do -s 1472 8.8.8.8 (Linux) ayuda a determinar el tamaño máximo sin fragmentación para ruta externa con MTU 1500 (1472 bytes de payload + 28 de IP+ICMP). Para túneles revisa con ping interno entre direcciones internas. Si hay pérdidas con paquetes grandes, baja MTU o MSS. Simple. Efectivo.

Otro truco: activa logs de "Fragmentation needed" en router o firewall. Si aparecen picos, PMTUD falla. Facilita temporalmente la vida con MSS clamp TCP y luego encuentra dónde se bloquean ICMP. A veces es un ACL olvidado que lleva años bloqueando todo y ahora entorpece.

Dumps seguros y anonimización de datos sensibles

Captura en interfaz externa si quieres ocultar IPs y puertos internos. El tráfico externo está cifrado, no revelas contenido. Pero recuerda: metadatos quedan visibles — quién, a dónde, cuándo. Si compartes dumps con terceros, recorta pcap por IP y tiempo y usa anonimización en Wireshark (Reemplazar MAC/IP).

En 2026 las políticas "privacy by design" para debugging son norma. Guarda dumps poco tiempo, cifra archivos y borra claves tras cerrar incidentes. Añade README cortos con filtros, versión cliente, MTU. Un mes después te lo agradecerás.

Criptografía y seguridad a nivel paquete

Autenticación y protección contra repeticiones

Cada paquete protegido pasa chequeo de integridad y autenticidad. En IPsec ESP el contador SeqNum y ventana antiprolongación previenen rejuegos. En WireGuard la pareja monógama de claves y contador hacen lo mismo. Desincronización de contadores obliga a descartar paquetes, por eso monitorea "Replay errors" para detectar problemas o reinicios sin rekey.

Identificación de Security Association (SPI en IPsec) indica qué clave usar y cómo verificar etiquetas. Las claves se renuevan (rekey) por tiempo o volumen. Si el rekey tarda, sube riesgo de usar nonces repetidos. Controla timers. En buenos logs el cambio de claves es suave y breve, como cambiar marchas sin tirones.

GCM vs ChaCha20-Poly1305

AES-GCM es estándar de facto en IPsec y TLS gracias a aceleradores hardware (AES-NI, extensiones criptográficas ARMv8). Es rápido y bien paralelo. ChaCha20-Poly1305 brilla donde no hay AES acelerado y se desea rendimiento predecible en todas plataformas, lo que explica su uso en WireGuard. Ambos ofrecen AEAD: cifrado y autenticación en un solo paso.

Respecto a latencias, ChaCha20 tiende a ser lineal y estable sin caídas raras, incluso en routers ARM económicos. AES-GCM marca récords en servidores con hardware. En 2026 los híbridos son raros, pero ya hay experimentos post-cuánticos en el intercambio de claves (IKEv2 y TLS 1.3) — útil saberlo, aunque aún no impacta en cada paquete, sino en el handshake.

PFS, rekey y timers de vida de claves

Perfect Forward Secrecy significa que el compromiso de claves a largo plazo no expone sesiones anteriores. A nivel paquete no se nota, pero PFS obliga a cambiar claves de sesión periódicamente. La vida de las SA tiene límite en tiempo y volumen. En logs se ve como un cambio planeado de SPI y reinicio de contadores. Si los timers son largos, sube el riesgo de reuse de nonces.

En práctica, para túneles con mucha carga se hace rekey cada 30–60 minutos o tras 1–2 GB de tráfico según riesgo. Timers cortos implican más handshakes y overhead, pero mejor higiene criptográfica. Encuentra tu balance y monitorea bien.

Metadatos y filtraciones de patrones

Aunque el contenido se cifra, los metadatos asoman: IP de origen y destino, puertos, tamaños de paquetes, intervalos. DPI aprende a identificar "estilo" WireGuard o OpenVPN con estadísticas de tamaño y frecuencia de keepalive. La lucha está en enmascarar el tráfico: transporte QUIC, puertos variables, padding, mimetizar perfil HTTP/3.

Desde el punto de vista de ingeniería, la mejor defensa es la diversidad. Rekey regular, tamaño variable de keepalive, ausencia de anomalías como tamaños perfectamente fijos. Es como un disfraz: cuanto más natural te mueves en la multitud, menos chances de que el guardia DPI te detecte.

Optimización y casos 2026

Router doméstico y WireGuard: ganancia rápida

Caso: router ARM doméstico con ISP a 500 Mbps. Montamos WireGuard, ponemos MTU 1420, activamos flow offload y fq_codel en colas, MSS clamp 1360. Resultado: 400–480 Mbps VPN full duplex con latencia agregada de 2–4 ms. Nada exótico, solo configuración cuidada. Streaming 4K va sin problemas por ese túnel.

Agrega monitoreo: cada 5 min iperf3 por 2–3 segundos, logs de RTT con pings a varias regiones, contadores de drop en interfaz. Tras una semana tendrás un mapa vivo de calidad de canal y baseline claro. Cuando lleguen caídas "vespertinas", lo notarás y evitarás discutir a ciegas con el proveedor.

IPsec corporativo con NAT-T: MTU vs realidad

Caso: sucursales en IPsec (IKEv2, AES-GCM), NAT-T inevitable. Al inicio quejas de "RDP lento y Zoom raro". Primera causa: fragmentación episódica de paquetes externos y bloqueo de ICMP. Solución: MTU 1400, MSS clamp 1360, permitimos ICMP Tipo 3 Código 4 en perímetro, activamos copia DSCP para EF (voz). En un par de horas los gráficos se estabilizaron y la voz dejó de sonar entrecortada.

Toque final: balance de túneles en dos proveedores y health-check con BFD. A nivel de paquetes sólo mantuvimos tamaños y prioridades estables, no intentamos "arreglar" apps. A veces lo genial es pura ingeniería aburrida.

OpenVPN en la nube y colapso TCP: cómo sobrevivir

Caso: OpenVPN sobre TCP en segmento cloud con proxy. Pérdidas 0.2–0.5%, pero RTT varía 20–40 ms. TCP interno y externo reaccionan juntos, formando ondas estacionarias. App web sufre. Solución temporal: aumentar ventana TCP, activar BBRv2 en canal externo, eliminar refresco TLS innecesario. A largo plazo: pasar a UDP o QUIC si la política lo permite.

Paralelamente usa truco lógico: baja MTU y MSS para reducir retransmisiones de paquetes grandes. No es cura total, pero sin eso todo tratamiento es perder tiempo. Y sí, prueba puertos alternativos y camuflaje HTTP/3, los DPI modernos son sorprendentemente tolerantes con QUIC en 2026.

SASE, VPN QUIC y tendencias 2026

En 2026 crece la cuota de soluciones SASE y SDP: cliente conecta al PoP más cercano y luego el tráfico viaja por troncal privada con priorización. A nivel paquete suelen verse transportes QUIC con encapsulación y cifrado encima. Esto permite sortear proxys corporativos y ahorrar en excepciones complicadas.

Otra tendencia: aceleradores hardware en el borde: SmartNIC con offload IPsec, eBPF/XDP para procesamiento veloz, ARMv9 con SVE2 que ofrece ChaCha20 estable en routers de sucursal. Híbridos post-cuánticos para IKEv2 y TLS 1.3 están en piloto, pero es cercana realidad. El mundo se prepara para las claves del futuro, y es apasionante.

Checklist para diagnóstico de túnel a nivel paquetes

Síntomas y pruebas rápidas

Síntoma: páginas cargan a tirones, video se traba, RDP está "goma". Test 1: ping DF y fuerza bruta de tamaño — encontramos umbral seguro. Test 2: tcpdump en interfaz externa — buscamos fragmentos y pérdidas. Test 3: revisamos MSS en SYN y confirmamos clamp activo. Test 4: chequeamos contadores de replay e ICV errores en IPsec/WG.

Si tras clamp y MTU correcto no cambia, busca jitter o problemas QoS con proveedor. Test simple es iperf3 a distintos puertos y DSCP para evaluar estabilidad. A veces cambiar último proveedor mágicamente arregla todo. La vida.

Mapa de soluciones durante el análisis

Las soluciones son escalonadas: 1) Afina overhead y baja MTU del túnel 80–100 bytes bajo 1500 con margen. 2) Activa MSS clamp. 3) Restaura ICMP "Fragmentation Needed" en perímetro. 4) Cambia a transporte UDP si es necesario. 5) Ajusta priorización en voz y flujos interactivos. 6) Controla rekey y actualiza clientes.

Si nada ayuda, investiga DPI y proxy. Tal vez tu tráfico es tratado como "sospechoso" y limitado. Prueba encapsulado QUIC o cambiar puerto a 443/UDP abre puertas. No es evasión, es hipótesis.

Comandos para distintos OS

Linux: ip link set dev wg0 mtu 1420; iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu; tcpdump -ni eth0 udp port 51820. Windows: netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent y configurar MTU en adaptador VPN vía GUI o PowerShell; captura con pktmon o Wireshark.

BSD y pfSense: en interfaz WireGuard/OpenVPN hay campos MTU y MSS. No olvides activar scrub en pf para normalizar y permitir tipos ICMP necesarios. En routers con offload hardware verifica que cifrado no caiga a software por opciones exóticas. Un flag demás resta cientos de megabits.

Errores comunes y cómo evitarlos

Clásico: dejar MTU 1500 en túnel, no ajustar MSS y luego asombrarse por fragmentación. Segundo error: bloquear ICMP "por seguridad" y dedicar un mes a "internet lento". Tercero: TCP sobre TCP sin necesidad extrema. Cuarto: ignorar contadores de error ESP y WireGuard que advierten duplicados o daños.

Quinto: no probar con paquetes pequeños y servicios interactivos. El throughput es la mitad; jitter y latencia la otra. Con ambas correctas se siente al instante. Todo clic es fluido, video sin borrones y archivos vuelan.

FAQ: breve y al grano

Cómo calcular rápido MTU para mi VPN si no sé overhead exacto

Toma 1500 y resta 100 bytes para cálculo conservador. Fija MTU 1400 en túnel y MSS 1360. Prueba ping con DF desde 1300 a 1472 para hallar techo. Si pasa todo, sube MTU en pasos de 10 hasta fallo y baja 20–30 para margen. Es método rudo pero efectivo, útil en redes donde ICMP está bloqueado y no hay documentación.

Por qué WireGuard suele ser más rápido que OpenVPN en mismos servidores

Dos motivos. Primero, overhead menor y estable con criptografía predecible ChaCha20-Poly1305. Segundo, diseño del núcleo del protocolo: menos copias, menos cambios de contexto, implementación más simple. En ARM y x86 sin AES-NI WireGuard suele superar OpenVPN 1.5–2 veces en throughput y mantiene RTT más estable bajo carga. Excepciones hay, pero raras.

Cuánto daño hace TCP-over-TCP y cuándo es aceptable

Es dañino donde hay pérdidas y jitter. Dos capas de control congestionado interfieren y latencia crece. Se justifica solo si la política no permite otra y el tráfico va por TCP 443 vía proxy o DPI. En ese caso ayudan buffers bien configurados, BBR en TCP externo y buen caché. Pero si puedes ir a UDP o QUIC, hazlo. No es gusto, es física de red.

Por qué IPsec se corta con archivos grandes aunque ping es pequeño

Probablemente MTU/PMTUD. Ping pequeño son paquetes de 64 bytes, y archivos grandes empujan segmentos casi al límite. Si ICMP "Fragmentation Needed" está bloqueado, el emisor no sabe que debe reducir tamaño y ves timeouts, retransmisiones y cortes. La solución es MTU correcta en túnel, MSS clamping y permitir ICMP necesario. Fácil de verificar con ping DF grande y tcpdump.

Vale la pena copiar DSCP del IP interno al externo en VPN

Sí, si tienes QoS en el camino y quieres que voz, video e interacción tengan prioridad no solo en tu red sino también en el canal hasta el punto de salida. Muchos operadores en 2026 consideran DSCP en el núcleo del transporte. Lo importante es acordar valores y no abusar de EF/CS5 para evitar policing agresivo. Primero piloto, luego despliegue — regla de oro.

Ya es momento de pasarse a algoritmos post-cuánticos en VPN

Para tráfico diario aún es temprano. Schemás post-cuánticos reales aparecen en IKEv2/TLS como híbridos en el handshake. A nivel paquetes no notarás casi diferencia y costes y compatibilidad pueden ser un problema. Pero para datos sensibles con larga vida útil, los pilotos son razonables. Sigue las actualizaciones en tus implementaciones y ten un plan de migración.

Cómo saber si mi red está limitada por VPN y no por el proveedor

Compara benchmarks en mismo canal: iperf3 directo y vía túnel, y mide RTT y jitter con paquetes pequeños. Si la caída de velocidad es más de 30–40% y sube el CPU en cifrado, culpa del stack VPN o ajustes MTU/MSS. Si la caída es igual sin VPN y la latencia crece sin carga, el problema está en la línea del proveedor. Activa monitoreo constante corto para ver resultados en 24 horas.