VPN Site-to-Site para sucursales: IPSec vs WireGuard vs IKEv2 adaptado a la realidad rusa

Introducción: por qué este tema es relevante y qué aprenderás

En 2026, la VPN Site-to-Site para sucursales se ha vuelto el tejido fundamental de la red corporativa. Oficinas, centros de datos, nubes y ubicaciones remotas necesitan un canal seguro sobre un internet impredecible y operadores de capa 3. ¿Por qué esto es especialmente importante ahora en Rusia? Debido a la variabilidad en el enrutamiento, filtrados intermitentes y DPI, diversidad de proveedores, necesidad de import substitution y aumento de la protección de datos personales y secretos comerciales. Esta guía compara tres enfoques efectivos para VPN corporativas S2S: IPSec, WireGuard e IKEv2 (como conjunto IKEv2+IPSec), enfocándose en la práctica: arquitecturas, perfiles criptográficos, alta disponibilidad, rendimiento, operación, errores típicos y casos reales.

Qué obtendrás: criterios claros para elegir el protocolo acorde a tu topología y requisitos regulatorios, instrucciones paso a paso para desplegar, listas de verificación para auditar la preparación, recomendaciones sobre MTU, NAT-T, BGP sobre VPN, además de un marco para TCO y evaluación de riesgos. Evitamos la teoría académica y nos centramos en lo que funciona en las condiciones rusas hoy.

Conceptos básicos: fundamentos (para principiantes)

Qué es una VPN Site-to-Site

VPN Site-to-Site conecta dos o más redes a nivel IP, permitiendo que los hosts de la sucursal A accedan a recursos de la sucursal B como si estuvieran en una misma red local o mediante un núcleo enrutado. El túnel encapsula y cifra los paquetes sobre internet público o canal de capa 3.

Elementos clave

• Transporte: UDP o TCP sobre IP. IPSec usa ESP y con frecuencia UDP 500/4500 (NAT-T). WireGuard usa UDP (por defecto 51820, configurable).
• Criptografía: conjunto de cifrados, autenticación, PFS, KDF. Se prioriza AEAD (AES-GCM, ChaCha20-Poly1305) para rendimiento y simplicidad.
• Gestión de claves: IKEv2 para IPSec; en WireGuard, claves estáticas o gestores, rotación periódica integrada.
• Enrutamiento: rutas estáticas o protocolos dinámicos (BGP, OSPF) dentro del túnel.
• Confiabilidad: DPD, keepalive, monitoreo SLA, canales de respaldo, clusters HA.

Qué son IPSec, WireGuard e IKEv2

• IPSec: stack de protocolos de red (ESP/AH), con cifrado y autenticación. Flexible, maduro, soportado por la mayoría de routers y firewalls. Normalmente gestionado con IKEv2.
• WireGuard: protocolo VPN moderno basado en Noise (NoiseIK), solo UDP, minimalista, rápido y sencillo de configurar.
• IKEv2: protocolo de establecimiento de claves y parámetros de seguridad para IPSec. En contextos corporativos «IKEv2» suele referirse a «IPSec con IKEv2».

Realidad rusa

• DPI y rutas inestables: el tráfico UDP puede degradar ocasionalmente; es crítico tener respaldo, parámetros flexibles de NAT-T y canales fallback.
• Regulaciones: para proteger datos personales e infraestructuras críticas — medidas organizativas y técnicas; a veces se requieren soluciones certificadas o criptografía GOST.
• Import substitution: se prefieren stacks open-source (StrongSwan, VyOS, FRR) y proveedores rusos, manteniendo compatibilidad vía protocolos estándar.

Profundizando: aspectos avanzados

Seguridad: perfiles criptográficos y rotación de claves

• IPSec/IKEv2: suites recomendadas en 2026 — AES-GCM-128/256, con PFS (DH Grupo 14 o 19+), autenticación con certificados (RSA-3072 o ECDSA P-256/P-384). Duración: IKE SA 8-24 horas, Child SA 1-4 horas; rekey anticipado.
• WireGuard: ChaCha20-Poly1305, Curve25519, HKDF; rotación de claves basada en temporizadores y normas operativas; almacenamiento de claves privadas en HSM o con acceso protegido.

Rendimiento y latencia

• Latencias: IPSec ESP con hardware AES-NI ofrece latencias predecibles; WireGuard suele ganar con paquetes pequeños y alta concurrencia por su pila simplificada y compacta.
• Overhead: IPSec ESP añade 50–80 bytes por paquete según configuración; WireGuard unos 32–60 bytes. Afecta MTU y la necesidad de clamping MSS.
• Throughput: en CPU x86 con AES-NI un núcleo puede 1–3 Gbps IPSec AES-GCM optimizado; WireGuard en misma CPU suele llegar a 2–4 Gbps. Depende de offload NIC, IRQ pinning y NUMA.

Confiabilidad y alta disponibilidad

• DPD/Keepalive: para IPSec — DPD 10–15 seg, reintentos 3–5; para WireGuard — persistent keepalive 15–25 seg cuando hay NAT.
• Redundancia: dos proveedores independientes por sitio, varios túneles (active-active con ECMP o active-standby), VRRP/Keepalived en nodos frontera, BGP dentro de túneles.
• DPI/bloqueos: se prefiere UDP, pero ante riesgo de bloqueos mantener perfil paralelo SSTP o obfuscación TCP para acceso de emergencia a servicios críticos.

Diseño de red

• Full-tunnel vs split-tunnel: usualmente en sucursales se usa split-tunnel: VPN lleva solo prefijos corporativos; el tráfico a internet se queda local para ahorrar ancho de banda.
• Espacio de direcciones: evitar solapamientos RFC1918 entre sucursales; planear bloques /24 o /23 por sitio y reservar IP para servicios de gestión.
• Enrutamiento dinámico: BGP con MED/LocalPref para elegir mejor canal; OSPF en perímetros cerrados; evitar redistribuciones complejas entre VRF.

Práctica 1: arquitecturas Site-to-Site para distintas necesidades

Arquitectura A: Hub-and-Spoke

El hub central (datacenter o nube) conecta decenas de sucursales. Ventajas: control simplificado, punto único de seguridad, análisis integral. Desventajas: riesgo SPOF, carga en núcleo, escalabilidad compleja sin ECMP ni clusters.

• IPSec/IKEv2: esquema maduro con StrongSwan/VyOS o gateways hardware. Recomendado BGP en cada spoke, anuncio de prefijos sucursales en hub vía dos túneles independientes.
• WireGuard: configuración más fácil de automatizar para decenas de spokes gracias a la simplicidad de configs y plantillas. Imprescindible control de claves e inventario CMDB.

Arquitectura B: Malla parcial

Sucursales críticas conectadas directamente entre sí además del hub. Ventajas: camino más corto, menor latencia. Desventajas: crecimiento cuadrático de túneles, requiere auto-orquestadores.

Arquitectura C: Dual-hub Active-Active

Dos hubs en ubicaciones diferentes, ECMP o multipath BGP, balanceo de sesiones. Detalle: enrutamiento simétrico o session stickiness. IPSec usa SA separadas por camino; WireGuard varios peers con prioridades distintas.

Elección del protocolo según contexto

• Compatibilidad máxima con hardware: IPSec/IKEv2.
• Simplicidad y rapidez: WireGuard.
• Requisitos de certificación: IPSec con stacks probados o soluciones GOST-VPN.

Lista de verificación de arquitectura

• Dos proveedores independientes en el hub y sucursales críticas.
• Plan MTU: 1400–1420 para interfaz VPN, MSS clamp 1360–1380.
• BGP dentro de VPN, filtrado de prefijos, bloqueo «0/0» desde sucursales.
• Respaldo de gestión: OOB o módem LTE con túnel de emergencia.

Práctica 2: IPSec/IKEv2 — teoría, configuración paso a paso, optimización

Perfil criptográfico

• Fase 1 (IKEv2): AES-GCM-256, PRF SHA-256, DH Grupo 19 (ECDH P-256), duración 8h, reautenticación habilitada.
• Fase 2 (Child SA): AES-GCM-256, PFS Grupo 19, duración 1–2h, ventana anti-repetición 64–128.
• Autenticación: certificados X.509, CRL/OCSP o certificados de corta duración (90–180 días) con rotación automática.

Instrucciones paso a paso (lógica universal)

1. Preparación de direccionamiento: fija redes locales y remotas, evita solapamientos. Define excepciones NAT.
2. PKI: crea CA interna, emite certificados para cada gateway, configura políticas de Key Usage y SAN con FQDN/IP.
3. Parámetros IKE: define cifrados, duraciones, DPD 10s. Si hay CG-NAT en proveedor sucursal, activa NAT-T.
4. Parámetros IPSec: ESP en modo transporte o túnel (normalmente túnel), PFS activado, rekey anticipado (ejemplo: 10% antes de expirar).
5. Enrutamiento: rutas estáticas inicialmente, luego BGP usando direcciones de túneles para vecino.
6. MTU/MSS: MTU 1400, MSS clamp 1360 para TCP en interfaz LAN.
7. Monitoreo: exportar métricas a Prometheus/Influx, alertas por caída SA y aumento retransmisiones.

Ajustes finos para redes rusas

• NAT-T agresivo: en NAT variable y keepalives perdidos — aumentar frecuencia DPD, reducir intervalos rekey.
• Duplicación de puertos: puertos UDP alternativos con DPI; algunos dispositivos admiten puertos no estándar.
• Failover: dos túneles paralelos a IPs distintas de hub, ECMP o prioridad por SLA.

Marco de implementación de IPSec

• Piloto en 1–3 sucursales, carga hasta 200 Mbps, recopilación de métricas.
• Auditoría de MTU/MSS/Fragmentación y ajustes.
• Implementación de BGP, reducir estáticas donde sea posible.
• Activar logging de eventos de seguridad, pruebas de incidentes (caída, compromiso de clave, rotación CA).

Práctica 3: WireGuard — inicio rápido, operación, seguridad

Por qué WireGuard

Operación estable sobre UDP, código mínimo, alta velocidad, configuraciones simples. Ideal para despliegues masivos en sucursales con Linux/RouterOS/VyOS y gateways x86.

Instrucciones paso a paso

1. Claves: genera pares para cada nodo. Guarda claves privadas centralizadamente con control de acceso.
2. Interfaz: crea wg0 con direcciones en subred separada para túnel (ejemplo: 10.10.0.0/24).
3. Peers: en hub agrega peers de todas sucursales, en sucursales agrega peer de hub. Ajusta lista permitida a subredes necesarias.
4. Keepalive: activa persistent-keepalive 20–25 seg, especialmente tras NAT.
5. Rutas: configura estáticas o BGP sobre FRR en interfaz wg.
6. MTU/MSS: MTU 1420, MSS clamp 1380 como punto de partida.

Seguridad en WireGuard

• Control de claves: inventario CMDB, política de rotación (cada 90–180 días) y revocación ante incidentes.
• Acceso mínimo: limita AllowedIPs a subredes reales, evita 0.0.0.0/0 si no hay full-tunnel.
• Filtrado: en firewall sistema filtra UDP entrante al puerto WG, listas blancas por origen si es posible.

Optimización de rendimiento

• CPU pinning para interrupciones NIC y hilos wg en núcleos NUMA locales.
• Configuraciones GRO/LRO, RPS/RFS en Linux; monitoreo de drops con ethtool -S.
• Túneles paralelos para altas velocidades, ECMP en enrutamiento.

Lista de verificación WireGuard

• UDP accesible en puerto elegido desde ambos lados.
• Persistent keepalive configurado para nodos detrás de NAT.
• MTU 1420 y MSS clamp 1380 validados con trazas y pruebas.
• Logs y métricas recolectados (wg show, exportación a Prometheus).

Práctica 4: IKEv2 en empresa — certificados, MDM, escenarios híbridos

Por qué IKEv2

Estándar, bien soportado por gateways hardware y software, cómodo para entornos mixtos (Windows, iOS, Android, Linux). En S2S suele ser IPSec gestionado por IKEv2, pero en empresas híbridas la misma PKI sirve tanto para S2S como para acceso remoto de empleados.

Enfoque paso a paso

1. PKI y políticas: crea plantillas de certificados para gateways, activa Extended Key Usage para IPsec IKE.
2. Perfiles IKE: define conjuntos de cifrados y grupos DH; activa MOBIKE si hay escenarios móviles.
3. Separación de roles: certificados S2S separados de VPN usuario; fuerte rotación y auditoría.
4. Integración MDM: publica perfiles IKEv2 para clientes si se necesita modo híbrido con acceso remoto.

Consejos prácticos

• CRL/OCSP: si OCSP no está disponible, usa certificados de duración corta; mantén CRL localmente.
• Escalabilidad: evita un CA único para todos los dominios; divide en CA intermedias por perímetros.

Práctica 5: NAT, MTU, DPI — cómo no perder paquetes

Diagnóstico MTU

1. Ejecuta PMTUD con flag DF y aumento gradual del tamaño para asegurar paso estable.
2. Configura MTU en túnel 20–80 bytes menor al máximo.
3. Aplica MSS clamp en interfaces frontera para TCP.

CG-NAT y UDP inestable

• Aumentar frecuencia de keepalives; duplicar túneles hacia diferentes puertos.
• Con degradación crónica, perfil de respaldo vía TCP (SSTP u OpenVPN TCP) para servicios críticos, no para S2S principal.

DPI

• Mantener perfil de tráfico legítimo, usar puertos estándar cuando sea posible.
• Separar canales de gestión y datos para no perder control.

Práctica 6: Enrutamiento y HA — BGP sobre VPN

Por qué BGP

El enrutamiento estático escala mal. BGP ofrece control de rutas, rápida recuperación y comportamiento predecible en multi-hub. Naturalmente encaja sobre S2S como transporte.

Paso a paso

1. Direcciones loopback: configura loopbacks en cada gateway y úsalas para vecinos BGP vía túnel.
2. Filtros: anuncia solo tus prefijos; filtra externos en hub.
3. Políticas: MED/LocalPref para priorizar hubs; prepend para rutas de emergencia.
4. Failover: timers rápidos (hello 3s, hold 9s) si red estable o BFD si disponible.

HA en gateways

• VRRP/Keepalived en par de gateways en sucursal.
• Sincronización de configuraciones; acceso a CA de respaldo.
• Considerar asimetría de enrutamiento, particularidad de firewalls stateful.

Práctica 7: Observabilidad, operación, SLO

Métricas

• Disponibilidad del túnel: uptime SA o peer wg, RTO, jitter.
• Throughput: p95/p99, errores y drops en interfaces.
• Seguridad: autenticaciones fallidas, frecuencia rekey, dinámica sospechosa de rutas.

Alertas

• SLO: 99.9% disponibilidad de tráfico intersucursal; alerta en caída bajo umbral sobre ventana móvil.
• Tiempos de recuperación: MTTR hasta 5 minutos por sucursal si hay canal de respaldo.

Procedimientos operativos

• Rotación trimestral de claves y certificados.
• Pruebas DR: falla proveedor, compromiso de clave, caída de gateway.
• Inventario: registro actualizado de sucursales, prefijos, claves, contactos de proveedores.

Errores típicos: qué NO hacer

• Usar RFC1918 iguales en distintas sucursales: causa asimetría y hairpin. Planifica el espacio de direcciones con anticipación.
• Falta de MSS clamp: fragmentación y timeouts TCP impredecibles.
• Perfiles de cifrado débiles: cifrados obsoletos (3DES, CBC sin AEAD), sin PFS.
• Un CA único para todos los perímetros: riesgo de efecto dominó en incidente.
• Monitoreo post-mortem: implementa métricas y alertas antes de escalar.
• Failover sin pruebas: hay túneles de respaldo pero timers, BGP y exclusiones NAT sin testear.
• Un solo enlace crítico: un proveedor en nodo crítico es camino seguro a caídas.

Herramientas y recursos: qué usar

Stacks de software

• IPSec/IKEv2: StrongSwan, Libreswan, VyOS, pfSense; sistemas de red con aceleración hardware AES-NI.
• WireGuard: integrado en núcleo Linux; soportado en Windows, BSD, RouterOS 7, VyOS.
• Enrutamiento dinámico: FRR (BGP/OSPF), BFD si se soporta, keepalived/VRRP para HA.

Monitoreo y testing

• Prometheus, VictoriaMetrics, Grafana para dashboards.
• iperf3 para throughput y jitter, hping para MTU/DF.
• Captura de paquetes en bordes (tcpdump) con filtros para ESP/puertos UDP.

Gestión de configuraciones

• Enfoque GitOps: guarda plantillas de túneles y políticas BGP en repositorio.
• Ansible para despliegue masivo; secretos en Vault.

Inicio rápido para pilotos

Para implementaciones piloto y POC donde velocidad y flexibilidad de pago importan en Rusia, vpn.how ofrece un servidor VPN personal con IP dedicada (no compartida) que soporta WireGuard, OpenVPN, IKEv2, L2TP y SSTP — puedes elegir protocolo según red. Servidores en Moscú, San Petersburgo, Ámsterdam, Frankfurt, Londres, Nueva York, San José, Chicago, Singapur, Sídney, Madrid, Helsinki, Estocolmo, Varsovia, Copenhague, Stavanger. Acepta tarjetas rusas (Tinkoff, Ozon), SBP y USDT/BTC. Tarifas desde 490 ₽ por día y 2490 ₽ mensual con descuentos por periodo largo; arranque automático en 5 minutos tras pago y sin logs para validar hipótesis rápido sin trámites largos. Para entornos productivos grandes recomienda infraestructura propia o soluciones compatibles con GOST.

Casos y resultados: ejemplos reales de uso

Caso 1: cadena minorista, 120 sucursales

Contexto: dos vitrinas de datos, ERP y cajas. Solución: Hub-and-Spoke con IPSec/IKEv2, dos hubs (Moscú, SPb), BGP sobre túneles. Parámetros: AES-GCM-256, DH19, Child SA 90 min, DPD 10s. Resultado: disponibilidad 99.94% trimestral, p95 throughput 250 Mbps por sucursal, MTTR 4 min en fallo gracias a failover BFD+BGP. Insight: MSS clamp 1360 eliminó 80% de incidentes por fragmentación en 2 semanas.

Caso 2: logística, flujos troncales hasta 3 Gbps

Contexto: intercambio de telemetría y video entre hub y 8 sitios. Solución: WireGuard con ECMP, dos proveedores por lado, BGP FRR. Resultado: hasta 6 Gbps con túneles paralelos, latencias 10–15% menores que piloto IPSec, operación sencilla. Insight: IRQ pinning y desactivación de offload extra en NIC dieron +20% throughput.

Caso 3: Fintech, políticas estrictas

Contexto: segmentación y auditorías, multicloud. Solución: IPSec/IKEv2 con PKI fuerte, certificados cortos, CAs separados para PROD/NON-PROD, procedimientos escrow. Resultado: auditoría exitosa, rotación automática cada 90 días, cero incidentes en un año. Insight: registro centralizado de túneles y claves con revisión obligatoria redujo errores operativos en 60%.

Caso 4: Industria, proveedores inestables regionales

Contexto: sitios detrás de CG-NAT, degradación UDP intermitente. Solución: WireGuard principal, respaldo con IKEv2/ISAKMP en proveedor alternativo; sitios más problemáticos tienen perfil SSTP solo para gestión. Resultado: caídas reducidas a 0.3% mensual, RTO de 2–3 minutos. Insight: keepalives agresivos y separación de gestión/datos evitaron falsas alertas.

FAQ: 7–10 preguntas profundas

1. ¿Qué elegir para red de 10–20 sucursales con equipo TI limitado?

WireGuard ofrece facilidad y rapidez de despliegue especialmente con hardware x86/VyOS/RouterOS. Para compatibilidad con firewalls heterogéneos y regulaciones elige IPSec/IKEv2.

2. ¿Qué MTU usar por defecto?

Valores iniciales: IPSec 1400, WireGuard 1420, MSS clamp 1360–1380. Luego calibra con PMTUD y análisis de fragmentación.

3. ¿Se pueden mezclar WireGuard e IPSec/IKEv2?

Sí. Se usa WireGuard para tráfico bulk y IPSec/IKEv2 para compatibilidad o respaldo. La clave es enrutamiento coordinado y prioridad BGP.

4. ¿Qué tan seguro es WireGuard sin IKE?

WireGuard es seguro según estándares modernos, usa primitivos robustos. El riesgo está en la disciplina operativa: gestión de claves, limitar AllowedIPs, rotación oportuna.

5. ¿Qué pasa con DPI y bloqueos UDP en Rusia?

Casos puntuales ocurren. Mantén respaldo: puertos alternativos, túnel paralelo por otro proveedor, perfil TCP de emergencia solo para gestión.

6. ¿Cuándo usar BGP y cuándo basta estático?

Hasta 5–7 sucursales sin alta disponibilidad basta estático. Más sucursales, BGP reduce riesgos operativos y acelera recuperación.

7. ¿Cómo planear rendimiento?

Evalúa tráfico pico y p95, reserva 30–50% CPU y uplink, considera offload y NUMA. Para IPSec revisa AES-NI; en WireGuard planifica túneles paralelos para cargas gigabit.

8. ¿Requisitos para datos personales e infraestructuras críticas?

VPN es solo parte. Necesitas medidas organizativas, segmentación, registros y control de accesos. Para certificaciones considera soluciones certificadas o criptografía GOST.

9. ¿Con qué frecuencia rotar claves y certificados?

Práctica común: cada 90–180 días automatizado. Ante incidentes, reemplazo y revocación inmediata.

10. ¿Se puede montar multicast/VoIP sobre VPN?

Sí, pero cuida MTU, jitter y QoS. A menudo prefieres SRTP en perfil separado y priorización en WAN.

Conclusión: resumen y próximos pasos

En la realidad rusa, dos pilares tecnológicos dominan Site-to-Site: IPSec/IKEv2 como estándar universal y WireGuard como herramienta ligera y eficiente. No es una elección binaria: en redes maduras es común un híbrido que selecciona perfil óptimo según sitio y tráfico. La clave del éxito es disciplina: espacio de direcciones bien planeado, BGP sobre túneles, MTU/MSS adecuados, alta disponibilidad en canales y gateways, observabilidad y seguridad regulada. Empieza con piloto: 2–3 sitios, métricas, carga, test de fallos. Ajusta perfiles y escala con GitOps y CMDB. Para POC e hipótesis rápidas, un servidor personal en proveedor como el descrito funciona bien; para producción grandes, considera infraestructura propia o soluciones certificadas. Fundamental: no pospongas la observabilidad ni pruebas DR, y mantén perfiles criptográficos y claves con disciplina férrea. Así el VPN dejará de ser una "caja negra" y se convertirá en la autopista predecible de tu negocio.