Ataques de repetición en protocolos VPN: cómo las soluciones modernas cierran las ventanas para los atacantes

Por qué los ataques de repetición en VPN siguen siendo un problema real incluso en 2026

Qué es un ataque de repetición en pocas palabras

Un ataque de repetición ocurre cuando un atacante intercepta paquetes VPN cifrados e intenta reenviarlos para provocar la repetición de acciones o confundir al sistema. La palabra clave es repetir. No necesita conocer la clave ni romper el cifrado; simplemente copia el tráfico y lo envía de nuevo en el momento adecuado. A veces bastan unos pocos paquetes para provocar duplicaciones de transacciones, autorizaciones falsas o un efecto similar a un DOS.

Y sí, el cifrado por sí solo no protege contra esto. Si el protocolo no lleva un control de los números de secuencia, no usa valores únicos de un solo uso (nonce) y no mantiene una ventana anti-repetición, la repetición será simplemente otro texto cifrado "válido" que la capa de descifrado aceptará sin problemas. No queremos que esto pase.

Por qué una VPN es vulnerable sin anti-repetición

Un protocolo VPN construye una red sobre un medio no fiable: Internet es ruidoso, los paquetes llegan desordenados, algunos se pierden. Para mantener el rendimiento, las implementaciones permiten retransmisiones y paquetes fuera de orden. Esto es un paraíso para un atacante si no hay una lógica estricta que garantice la unicidad de los paquetes. Un paquete repetido puede pasar todas las verificaciones de integridad porque la etiqueta MAC/AEAD sigue siendo válida mientras la clave no haya caducado. El sistema debe responder a esta simple pregunta: ¿he visto ya este texto cifrado o no? Si no puede, hemos perdido.

Los riesgos clásicos incluyen la reaplicación de comandos de control (como cambios en las rutas), repeticiones de solicitudes TLS dentro del túnel, duplicación de transacciones en sistemas poco idempotentes. Además, hay un efecto secundario: mayor carga en la CPU por el exceso de descifrado y comprobación AEAD.

Modelo del atacante en 2026

Hoy en día, el atacante no solo está “en el cable”. Está en la nube, con VPS en la infraestructura principal, usa tarjetas de red programables y es capaz de hacer repeticiones inteligentes con precisión de milisegundos. Los adversarios inyectan duplicados con retrasos variables, se camuflan con fluctuaciones naturales, y sincronizan sus ataques con la rotación de claves. Y sí, a menudo no es un hacker solitario, sino un bot automatizado con miles de flujos simultáneos. ¿Suena sombrío? Un poco. Pero manejable.

Bloques fundamentales de defensa: nonce, números de secuencia y ventana deslizante

Nonce: la sal del cifrado y seguro contra repeticiones

El nonce es un valor de un solo uso que junto con la clave forma un contexto único para el algoritmo AEAD. Si se repite el nonce con la misma clave, la criptografía pierde su seguridad. En VPN, el nonce se construye a partir de contadores, marcas de tiempo, y partes aleatorias y deterministas. Lo esencial es la unicidad, no la simple aleatoriedad. El nonce ideal es impredecible, no se repite entre flujos y está sincronizado con el ciclo de vida de las claves.

Los AEAD modernos (ChaCha20-Poly1305, AES-GCM, AES-GCM-SIV) son sensibles a la repetición de nonce. Una colisión puede revelar la estructura del tráfico e, incluso, comprometer totalmente la confidencialidad. Por eso, las implementaciones VPN no deben fiarse de fuentes externas de tiempo. Se requiere un generador autónomo que garantice crecimiento continuo.

Números de secuencia: un contador que no se puede reiniciar

El número de secuencia es un contador monótono que identifica de forma única cada paquete dentro de una sesión y una clave. Incrementa en uno, no se recicla hasta un rekey, y no depende del reinicio del proceso. Los tamaños típicos son 32, 48 o 64 bits. 32 bits pueden ser tentadores (menos carga), pero implican riesgo de desbordamiento rápido en velocidades de 10 Gbps o superiores. En 2026, consideramos que 64 bits es el mínimo seguro para túneles de alto rendimiento.

El verificador en el receptor mantiene una estructura para comprobaciones rápidas: si ha visto un paquete con ese número, si está dentro de la ventana aceptable de desincronización y si no interfiere con posiciones ya confirmadas. El reto es hacerlo rápido y con bajo consumo de memoria.

Ventana anti-repetición: ventana deslizante en lugar de sincronización perfecta

Las redes no son perfectas y los paquetes llegan “escalonados”. La ventana anti-repetición permite aceptar algunos paquetes “antiguos” no vistos y rechazar repeticiones claras. Básicamente, es una matriz de bits que marca números recibidos dentro de una ventana de tamaño N. Si llega un número máximo nuevo, la ventana se desplaza. Un truco simple y brillante.

El tamaño de la ventana es un compromiso. Si es muy pequeña, habrá falsos rechazos por jitter. Si es muy grande, crecen la memoria y el tiempo de comprobación. Ajustes típicos: 64, 128, 512, 1024, 4096, 8192. Para 5G/LTE y Wi-Fi con mucho reordenamiento, 1024 o más; para centros de datos estables, con 128–512 basta.

Implementación en IPsec: ESP, AH y IKEv2

ESP: contadores de 64 bits y AEAD por defecto

ESP se ha vuelto el estándar de facto para túneles corporativos. Los perfiles modernos exigen AEAD (AES-GCM, ChaCha20-Poly1305), por lo que el manejo adecuado de nonce y secuencia es clave. En 2026 usamos números de secuencia extendidos (ESN) con espacio de 64 bits: 32 bits superiores extienden lógicamente el contador, 32 inferiores van en el encabezado. Esto elimina el riesgo de desbordamientos en sesiones largas y altas velocidades.

En el receptor, ESP guarda la ventana y el bitmap de números recibidos, verifica MAC y secuencia antes de descifrar la carga útil. La repetición se descarta inmediatamente. Una gran ventaja es que la anti-repetición en ESP se procesa a nivel del núcleo, rápido y predecible.

Anti-repetición en núcleos Linux y BSD

Linux y FreeBSD usan máscaras de bits y operaciones amigables con hardware para verificar repeticiones en tiempo O(1). El tamaño de ventana se configura vía sysctl y políticas de Security Association. Curiosamente, para no gastar ciclos en cada paquete, las implementaciones cachean el "límite superior" y mantienen un conjunto compacto de palabras para la ventana, alcanzando decenas de millones de paquetes por segundo con eBPF.

En producción, suelen activar ventanas extendidas para acceso móvil (512–2048) y reducirlas para backends en centros de datos (128–256). El error común es desactivar la anti-repetición “durante diagnósticos” y luego olvidarse de volver a activarla. Nunca hagas eso.

IKEv2: gestión de claves, rekey y SPI

IKEv2 es responsable del establecimiento de SA, rotación de claves y parámetros de protección. En el rekey es importante que la nueva SA arranque antes de agotar el rango de secuencia de la antigua. Los fabricantes suelen solapar las ventanas de vida 30–60 segundos. Los identificadores SPI ayudan a separar SA y encaminar tráfico a la política correcta. Desde el punto de vista de la repetición, IKEv2 protege el signaling (HDR, SK, nonce para el intercambio) y previene repeticiones de control con sus propios contadores y timeouts.

Un detalle extra son los aspectos DoS. Ante un pico de repeticiones, el núcleo no debe saturar la CPU con verificaciones MAC. Por eso es clave filtrar temprano por secuencia y ventana antes del descifrado completo. Las mejores implementaciones lo hacen así.

WireGuard: minimalismo, criptografía fuerte y marcas temporales

Esquema NoiseIK y construcción que detiene repeticiones

WireGuard está basado en NoiseIK: un handshake rápido, criptografía estricta (Curve25519, ChaCha20-Poly1305, BLAKE2s) y código conciso. El protocolo transmite datos en mensajes cortos cifrados con contadores y marcas que evitan repetir mensajes viejos. No hay “cien opciones”, hay disciplina rígida en nonce y rotación de claves.

Cada paquete incluye un contador de un solo uso para AEAD. Repetirlo sin la clave es imposible, y un número repetido será filtrado por el receptor. Esta sencillez hace la implementación más auditable y resistente a errores lógicos.

Ventana deslizante en el receptor y límites prácticos

WireGuard usa un mapa de bits de 8192 posiciones por defecto en Linux, cubriendo bien escenarios con mucho reorden. Si llega un paquete con contador bajo el límite inferior, se descarta. Si está dentro y el bit ya está marcado, también se descarta. Si es un nuevo máximo, la ventana se desplaza y el mapa se actualiza. Todo rápido y estricto.

En entornos móviles ruidosos, la ventana 8192 es un salvavidas. Pero tiene su contra: en ataques masivos con repeticiones dentro de la ventana, el bitmap puede saturarse. Por eso es crucial tener protección contra sobrecarga: limitación por tasa antes del descifrado, prioridad a paquetes de handshake y listas negras.

Rotación de claves y márgenes de seguridad

WireGuard cambia claves con frecuencia, típicamente tras dos minutos de inactividad o por volumen de tráfico. Esto reduce la ventana para criptoanálisis y minimiza riesgos por colisiones en nonce. En producción aplicamos límites agresivos por gigabytes y temporizadores suaves. La idea clave es: cuanto más corta la vida útil de la clave, menos problema la repetición del nonce. Pero abusar también es malo: handshakes frecuentes aumentan carga y a veces afectan la estabilidad móvil.

OpenVPN y otras VPN basadas en TLS: donde domina AEAD y timeouts

Transporte TLS: AEAD y protección contra repeticiones a nivel de sesión

OpenVPN usa TLS para control y puede cifrar datos sobre UDP o TCP. Los perfiles modernos emplean TLS 1.3, donde AEAD y la unicidad de nonce son gestionados rigurosamente. Las repeticiones de registros TLS son poco probables porque TLS controla la secuencia y números de registro, pero dentro del canal de datos VPN sigue siendo necesaria la gestión propia de la secuencia, ya que reconexiones, reinicios y multiplexación UDP pueden romper la semántica de “una sesión grande”.

OpenVPN con data channel offload (DCO) al núcleo es mucho más rápido y estricto en anti-repetición, ya que la crítica desde user space desaparece. Los números de secuencia y la ventana para paquetes de datos son esenciales.

UDP vs TCP: cómo evitar congelar la aplicación

OpenVPN sobre UDP es preferible para anti-repetición, porque controlamos retransmisiones y ordenación. Sobre TCP aparece el efecto “TCP sobre TCP”: duplicados y reordenamientos se esconden en transporte, pero en fallos acumulan retrasos y picos. La práctica en 2026 es: para acceso móvil e híbrido, UDP con AEAD, temporizadores estrictos y ventana adecuada; para aplicaciones legacy, TCP con límites cautelosos, registro y SLOs específicos de latencia.

Gestión del canal y casos límite

La repetición de paquetes de control (como reinicios de temporizador o renegociaciones) puede causar inestabilidad en la sesión. Por eso OpenVPN mantiene contadores propios para mensajes de control y rechaza registros antiguos. Configuraciones de timeout y anti-reconexión adecuadas evitan los molestos “parpadeos” del túnel en pérdidas breves.

QUIC y VPN de nueva generación: rápido, adaptable y consciente

Por qué la industria mira a QUIC

QUIC trajo a las capas de transporte un circuito criptográfico integrado, flujos independientes, convergencia rápida y, sobre todo, manejo inteligente de pérdidas y reordenamientos. Ya se usa en túneles corporativos: sobre QUIC es más sencillo construir multipath, gestionar temporizadores, aceptar out-of-order y filtrar repeticiones en tramas cifradas. En 2026 crece el número de soluciones "VPN-over-QUIC" con anti-repetición en núcleo.

La clave de buenas implementaciones es la separación clara de IDs de flujo, paquetes y claves de cifrado, más un rekey definido. Así, repetir un texto cifrado sin la clave actual y sin espacio numérico válido no tiene chance.

El peligro del 0-RTT: dónde está el límite del compromiso

0-RTT en TLS 1.3 y QUIC acelera la conexión, pero tiene semántica “repetible” para datos tempranos. En contexto VPN limitamos 0-RTT solo a operaciones idempotentes y seguras o lo desactivamos por completo. Si lo activas, agrega protecciones explícitas en aplicación: tokens, marcadores de un solo uso, deduplicación. Y sí, en logs debe ser visible para que el SOC diferencie repeticiones de picos por latencia.

Ajustes para redes reales

QUIC permite gestionar con flexibilidad ventanas, control de congestión y timers ACK. Para no confundir pérdidas con ataques, separamos umbrales: una ventana anti-repetición y otra permisiva para jitter de transporte. Además, aplicamos heurísticas: picos cortos de reorden no cambian la política, pero repeticiones masivas "del mundo viejo" disparan límites por tasa y bloqueos en el borde.

Práctica: cómo configuramos anti-repetición en producción

Tamaño de ventana según perfiles

La receta es sencilla pero efectiva. Para canales estables Data Center a Data Center usamos 128–256. Para red global con varios proveedores y satélite, 1024–4096. Para acceso móvil con roaming activo, 4096–8192. La validación es clave: los protocolos de diagnóstico deben mostrar claramente la frecuencia de reorden y porcentaje de rechazos por repetición. Si la tasa fluctúa por encima de 0,1–0,5 %, la ventana es muy pequeña; amplíala y revisa carga CPU.

Tambièn considera MTU y frecuencia de fragmentación. Con fragmentos, la probabilidad de reorder y repetición aumenta. Ideal evitar fragmentación en IPsec, aumentar MSS en túneles y configurar rutas DF-friendly.

Descarga en NIC, aceleradores hardware y XDP

Ventanas grandes son más económicas si parte de la lógica está cerca de la tarjeta de red. XDP y filtros eBPF pueden descartar repeticiones obvias antes de que pase toda la pila, ahorrando CPU. Los aceleradores hardware no resuelven por sí solos el replay, pero permiten mantener AEAD compacto a gigabits sin problemas. Lo importante es no confiar en “NIC inteligente” como única defensa. La fiabilidad está en mecanismos simples y claros dentro del núcleo.

Se recomienda almacenar el bitset de ventana en estructuras cache-friendly: palabras de 128 o 256 bits y memoria alineada. Incluso este detalle mejora el rendimiento un 10–15 % en nodos cargados.

Monitoreo, alertas y SLO

Monitorizamos porcentaje de drops por repetición, profundidad de ventana (frecuencia de nuevos máximos), distribución del reorder, latencia de rekey, frecuencia de handshakes, CPU en descifrado. SLO para túneles corporativos: drops por repetición bajo 0,1–0,2 % en picos, rekey en menos de 500 ms, ausencia de colisiones nonce. Alertas para aumentos súbitos de repeticiones de un solo AS, saturación de ventana y degradación con tráfico estable.

Errores típicos y anti-patrones

Desincronización de contadores y "mezcla" de sesiones

Problema clásico: reiniciar el daemon sin guardar estado cuidadosamente. El contador se reinicia, el receptor ve números “viejos” y descarta todo. Se soluciona guardando estado SA y contadores en memoria persistente o haciendo un rekey rápido con derivación de nuevo SPI. Otro anti-patrón es usar pools comunes de nonce entre flujos. No se debe hacer.

“Mezclar” sesiones al migrar IP o cambiar transporte sin rekey también es mala idea. Una nueva sesión debe usar nueva clave y numeración. Si no, tú mismo abres la puerta a repeticiones.

NAT, rutas asimétricas y falsas alarmas

Las rutas asimétricas maximizan el potencial de reorden. Si la ventana es pequeña, caerán paquetes inocentes. En NAT-T hay que poner atención a keepalive y timeouts: un cambio repentino de ruta puede romper el handshake y causar avalancha de repeticiones desde colas viejas. Nuestra práctica es fijar rutas “residentes” para túneles críticos y reservar ventanas 2–4 veces mayores que el pico de reorder observado.

Además, lo obvio pero vital: separa tráfico productivo y de pruebas. Repeticiones en tests que accidentalmente lleguen a producción pueden dañar gráficas y paciencia por horas.

Logs sin contexto

Un log "replay detectado" sin SA, SPI, rango de ventana, par IP y timestamp es casi inútil. En 2026 los logs deben ser estructurados. Si no, el SOC debe adivinar: ataque, sobrecarga o capricho del proveedor móvil. Añade semántica: rechazo por repetición en ventana, abajo del límite inferior o “en época previa de clave”.

Pruebas y simulación de ataques: seguridad sin detalles innecesarios

Herramientas y métodos seguros

Modelamos repeticiones de paquetes legítimos en nuestro laboratorio con claves aisladas y sin acceso a Internet externo. Generamos duplicados controlados, variamos retrasos y medimos respuesta: tasa de drops, carga CPU, comportamiento de ventana, tiempos de recuperación. Nada de experimentos en producción o tráfico ajeno, solo ambientes seguros, éticos y autorizados.

El principio clave: no reproduzcas ataques externos; reproduce tu red. Rutas reales, pérdidas típicas, proveedores comunes. Solo así los resultados son precisos.

Perfiles de carga y chequeo de resistencia

Recopilamos perfiles: canal estable, jitter 5–30 ms, roaming intenso con reorder hasta 3 %, escenario extremo con pérdidas en ráfaga. Para cada uno medimos cuándo empiezan los falsos rechazos sin ataque. Luego introducimos repeticiones aumentando tasa hasta umbrales SLO. Buscamos compromiso humano: mínimos falsos drops con máximos filtros de ataque.

Chequeamos períodos de rekey: los ataques adoran los “bordes”. Si en rotación pierdes hasta 5 % de paquetes por replay, hay que mejorar. Ampliar ventana en rekey suele ayudar, pero solo temporal y bajo monitoreo.

Ingeniería del caos para redes

Cada trimestre lanzamos “shimmy de red”: olas artificiales de reorder, retraso repentino, cambio de ruta. El objetivo es confirmar que la anti-repetición no rompe la experiencia de usuario. Si los usuarios no notan nada, vamos bien. Si lo notan, tomamos nota para mejorar: ventana, timers, umbrales de rekey, rutas.

Tendencias 2026: PQC, telemetría inteligente y eBPF en primera línea

Criptografía post-cuántica y su impacto en anti-repetición

Los algoritmos PQC entran poco a poco en el intercambio de claves: perfiles híbridos IKEv2 y handshakes QUIC con esquemas tipo Kyber. ¿Qué cambia para el replay? Indirectamente, mucho. El handshake es más pesado, ampliando la ventana vulnerable a sobrecargas. La respuesta: prebufferizar y simplificar el rechazo temprano de repeticiones para no gastar recursos en descifrados inútiles durante handshake. Además, planificar rekey agresivo y vigilar colisiones de nonce en grandes volúmenes.

Las normativas también avanzan: compliance exige políticas claras de rekey y unicidad de nonce comprobable. Pide a tu proveedor el algoritmo documentado para generación de nonce y el set de pruebas.

Telemetría: RUM aplicado a VPN

En 2026 muchos trasladan el real user monitoring al mundo de redes: sondeos activos desde clientes, correlación de eventos en la ruta, segmentación de problemas por proveedores. Para replay, esto es oro: permite detectar “garras” de ataque — espigas repetidas en zonas concretas, no globales. Sobre esto se basa la automatización: ventana aumentada en borde, limitación, cambio de ruta. Usuario satisfecho, seguridad intacta.

Finalmente, correlación con métricas de negocio. Si anti-replay atenúa "ruido" pero cae la conversión en app, es una señal. La idempotencia de APIs y protección contra repeticiones a nivel de aplicación deben ir de la mano con la seguridad en red.

eBPF, XDP y red programable

eBPF permite poner un “portón” antes de la pila: una defensa rápida contra repeticiones obvias, muestreo selectivo para análisis y asignación de prioridades. Combinado con offload hardware se sostienen ventanas grandes y se mantiene CPU bajo control. La clave es simplicidad y auditabilidad del código: menos ramas y estados, más predictibilidad bajo carga.

Lista de verificación para implementación: breve y precisa

Políticas y configuraciones básicas

- Activa anti-repetición en todos los túneles. Nunca la desactives en producción. - Usa números de secuencia de 64 bits o equivalentes ESN. - Ajusta ventana según perfil: DC 128–256, WAN 512–2048, móvil 4096–8192. - Planifica rekey anticipado: por tiempo y volumen, con solapamiento de 30–60 segundos. - Evita repeticiones de nonce: contador determinista, sin “azar del SO”.

- Minimiza fragmentación: configura MSS y monitorea MTU. - Separa canales de control y datos cuando sea posible, con límites específicos.

Monitoreo, SLO y alertas

- Métricas: drops por replay, profundidad ventana, latencia rekey, CPU descifrado, distribución reorder. - Alertas: picos de repetición por AS, saturación ventana, degradación con tráfico estable. - Logs: estructurados, con SA, SPI, ventana, timestamp, dirección y época clave. - Dashboards: comparar "antes y después" de cambios de ventana, impacto en latencia y throughput.

Incidentes, auditoría y cumplimiento

- Playbook: aumento rápido de ventana, limitación temporal por tasa, verificación de rutas, rekey forzado. - Auditoría: revisión periódica de generación de nonce, ESN, y coincidencia de configuraciones en extremos. - Cumplimiento: política de rekey, test de unicidad de nonce, reportes de SLO.

Preguntas frecuentes: respuestas breves a dudas incómodas

¿Por qué un ataque de repetición es peligroso si el tráfico está cifrado?

El cifrado no impide que se repita un paquete cifrado. Si el protocolo no verifica unicidad, la repetición puede causar duplicación de acciones, fallos lógicos o sobrecarga. La anti-repetición es tan necesaria como el cifrado y el MAC.

¿Cuál es el tamaño “ideal” de ventana anti-repetición?

Para centros de datos suele ser suficiente 128–256. Para WAN globales, 512–2048. Para móvil y Wi-Fi con roaming activo, 4096–8192. Mide el reorder y sigue los SLO.

¿Se desbordará un contador de 32 bits a altas velocidades?

Sí, rápido. A 10 Gbps y MTU bajo, 32 bits se agotan demasiado pronto. En 2026 consideramos 64 bits (ESN) como mínimo práctico para IPsec y equivalentes en otros protocolos.

¿Es necesario desactivar 0-RTT en VPN?

Si tienes dudas, sí. 0-RTT es “repetible” por definición. Si lo usas, limita a operaciones idempotentes y añade marcadores protectores en la capa de aplicación.

¿Ayuda cambiar a TCP sobre VPN contra replay?

No directamente. TCP oculta reorder, pero no reemplaza anti-repetición. A menudo empeora la latencia en fallos. Para anti-replay es mejor UDP con ventanas adecuadas y AEAD.

¿Qué es más importante: rekey frecuente o ventana grande?

Son palancas distintas. Rekey acorta vida de clave y reduce riesgos con nonce; la ventana gestiona la resistencia a reorder. Lo ideal es un balance: ventana razonable y rekey predecible.

¿Se puede confiar en tarjetas de red “inteligentes”?

Pueden ayudar en rendimiento, pero no deben reemplazar la lógica de seguridad. La anti-repetición debe residir en un circuito auditado en núcleo o protocolo, y el offload solo acelerar.