Túneles VPN e IPsec

1) Por qué IPsec y cuándo es apropiado

• Site-to-Site: on-prem ↔ cloud, cloud ↔ cloud, DC ↔ DC.
• VPN del cliente: acceso de administración, jump-host, break-glass.
• Backhaul/Transit: хабы и spoke-VPC/VNet (hub-and-spoke).
• IPsec es adecuado cuando se necesita una pila estándar, interoperable, aceleración de hardware (AES-NI/DPDK/ASIC), políticas de cifrado estrictas y compatibilidad con hierro de red.

2) Conceptos básicos (resumen rápido)

IKEv2 (Fase 1) - Negociación de parámetros/autenticación (RSA/ECDSA/PSK), creación de IKE SA.
IPsec ESP (Fase 2): cifrado de tráfico, Child SA (SA para prefijos/interfaces específicos).
PFS - ephemerality (grupo Diffie-Hellman) para cada niño SA.
NAT-T (UDP/4500) es una encapsulación ESP si hay NAT en el camino.
DPD - Dead Peer Detection, reemplazo de un SA roto.
Rekey/Reauth: actualiza las claves antes de que expiren (lifetime/bytes).

• IKE: 'AES-256-GCM' o'AES-256-CBC + SHA-256 ', DH' group 14/19/20 '(2048-bit MODP o ECP).
• ESP: 'AES-GCM-256' (AEAD), PFS por los mismos grupos.
• Lifetimes: IKE 8-24 h, Child 30-60 min o por volumen de tráfico (por ejemplo, 1-4 GB).

3) Topologías y tipos de túneles

3. 1 Route-based (preferiblemente)

Interfaz virtual (VTI) en cada lado; las rutas/protocolos dinámicos (BGP/OSPF) llevan prefijos. Es más fácil escalar y segmentar, mejor para overlapping CIDR (con políticas NAT).

3. 2 Policy-based (selectores de tráfico)

Listas de «istochnik↔naznacheniye» en SA. Adecuado para S2S simples sin enrutamiento dinámico; más difícil con muchos prefijos.

3. 3 GRE-over-IPsec / VXLAN-over-IPsec

Encapsulación L3/L2 encima de un canal cifrado: multiprotocol, conveniente para BGP (llevar keepalive) y para casos donde se necesita multicast/ESMR en underlay.

4) Segmentación, enrutamiento y tolerancia a fallas

BGP sobre VTI/GRE: intercambio de prefijos, MED/LocalPref/communities para prioridades, protección máxima prefix.
ECMP/Active-Active: par de túneles en paralelo (diferentes proveedores/RR).
Active-Passive: túnel de respaldo con AD/LocalPref más alto, DPD acelera la conmutación.
Split-tunnel: sólo prefijos corporativos a través de VPN; Internet - local (reducción de retrasos/costo).
CIDR superpuestos: las políticas NAT en los bordes o subred proxy, si es posible, rediseño del direccionamiento.

5) MTU, MSS y rendimiento

IPsec/NAT-T overhead: −~60 -80 bytes por paquete. Coloque la MTU 1436-1460 para VTI/túneles.
MSS-clamp: para TCP, exponga 'MSS = 1350-1380' (depende de underlay) para eliminar la fragmentación.
Habilite PMTUD y lógica ICMP «Fragmentation Needed».
El hardware offload/fast-path (DPDK, AES-NI, ASIC) reduce significativamente la carga en la CPU.

6) Fiabilidad y seguridad de las llaves

PFS es obligatorio; Rekey antes de la expiración 70-80% lifetime.
Autenticación: si es posible, certificados ECDSA de CA corporativa (o cloud-CA), PSK - sólo temporalmente y con alta entropía.
CRL/OCSP o la duración corta de los certificados.
Registros de autenticación y alertas cuando se repiten IKE fallidos.

7) Nubes y características de los proveedores

AWS: AWS Managed VPN (policy-based/route-based), TGW (Transit Gateway), VGW/CGW. Para Perfomance/Scale - Direct Connect + IPsec como un respaldo.
GCP: Cloud VPN (Classic/HA), Cloud Router (BGP); для throughput — Interconnect.
Azure: VPN Gateway (Policy/Route-based), VNet-to-VNet, ExpressRoute para L2/L3 de soldadura.
Private Endpoints/Privatelink: el tráfico a PaaS se conduce mejor a través de interfaces privadas en lugar de NAT egress.

8) Kubernetes y servicio de mesh

Los nodos K8s dentro de redes privadas; Pod CIDR no debe «salir» a sitios remotos - enrutar Node CIDR y proxy servicios a través de las puertas de enlace de ingress/egress.
Istio/Linkerd mTLS sobre IPsec - dominios de confianza individuales.
Control Egress: prohibición de la salida directa del pod a Internet (NetworkPolicy), permiso para VTI/VPN.

9) Monitoreo y registros

Túnel-SLA: latency, jitter, packet loss, up/down estados SA.
BGP: vecinos, prefijos, contadores flap.
Registros IKE/ESP: eventos auténticos, rekey, DPD.
Exportación a Prometheus (vía snmp_exporter/telegraf), alertas en churn SA y degradación RTT/PLR.
Los tracks/logs de aplicaciones marcan 'site = onprem' cloud ',' vpn = tunnel-X 'para correlación.

10) Trablshuting (lista de verificación)

1. Firewalls: permitidos UDP/500, UDP/4500, protocolo 50 (ESP) a lo largo de la ruta (o sólo 4.500 en NAT-T).
2. El reloj/NTP es sincronizado - de lo contrario IKE cae debido a los tiempos/certificados.
3. Los parámetros IKE/ESP son los mismos: cifrados, DH, lifetimes, selectores.
4. NAT-T está habilitado si hay NAT.
5. DPD y rekey: no demasiado agresivos, pero tampoco perezosos (DPD 10-15s, rekey ~ 70% lifetime).
6. MTU/MSS: presione MSS, compruebe ICMP «need fragmentation».
7. BGP: filtros/comunidades/AS-path, no hay «blackhole» debido a wrong next-hop.
8. Registros: IKE SA ¿establecido? Child SA created? ¿El SPI está cambiando? ¿Hay errores de respuesta?

11) Confecciones (referencias, abreviado)

11. 1 strongSwan (route-based VTI + IKEv2)

ini
/etc/ipsec. conf conn s2s keyexchange=ikev2 auto=start left=%defaultroute leftid=@onprem. example leftsubnet=0. 0. 0. 0/0 leftauth=pubkey leftcert=onprem. crt right=203. 0. 113. 10 rightid=@cloud. example rightsubnet=0. 0. 0. 0/0 rightauth=pubkey ike=aes256gcm16-prfsha256-ecp256!
esp=aes256gcm16-ecp256!
dpdaction=restart dpddelay=15s ikelifetime=12h lifetime=45m installpolicy=no      # route-based через VTI

bash ip tunnel add vti0 local 198. 51. 100. 10 remote 203. 0. 113. 10 mode vti ip link set vti0 up mtu 1436 ip addr add 169. 254. 10. 1/30 dev vti0 ip route add 10. 20. 0. 0/16 dev vti0

11. 2 VyOS (BGP sobre VTI, clamp MSS)

bash set interfaces vti vti0 address '169. 254. 10. 1/30'
set interfaces vti vti0 mtu '1436'
set protocols bgp 65010 neighbor 169. 254. 10. 2 remote-as '65020'
set protocols bgp 65010 neighbor 169. 254. 10. 2 timers holdtime '9'
set firewall options mss-clamp interface-type 'all'
set firewall options mss-clamp mss '1360'

11. 3 Cisco IOS (IKEv2/IPsec profile)

cisco crypto ikev2 proposal P1 encryption aes-gcm-256 integrity null group 19
!
crypto ikev2 policy P1 proposal P1
!
crypto ikev2 keyring KR peer CLOUD address 203. 0. 113. 10 pre-shared-key very-long-psk
!
crypto ikev2 profile IKEV2-PROF match address local 198. 51. 100. 10 authentication local pre-share authentication remote pre-share keyring local KR
!
crypto ipsec transform-set ESP-GCM esp-gcm 256 mode transport
!
crypto ipsec profile IPSEC-PROF set transform-set ESP-GCM set ikev2-profile IKEV2-PROF
!
interface Tunnel10 ip address 169. 254. 10. 1 255. 255. 255. 252 tunnel source 198. 51. 100. 10 tunnel destination 203. 0. 113. 10 tunnel protection ipsec profile IPSEC-PROF ip tcp adjust-mss 1360

12) Políticas y cumplimiento

Los cifrados criptográficos y las listas de cifrados permitidos están centralizados (security baseline).
Rotación de llaves/sres con recordatorios y automatización.
Registros de auditoría IKE/IPsec en Almacenamiento sin cambios (WORM/Object Lock).
Segmentación: dominios VRF/VR para prod/stage/dev y contorno de tarjetas (PCI DSS).

13) Especificidad de iGaming/finanzas

Residencia de datos: el tráfico con eventos PII/de pago pasa por IPsec sólo dentro de las jurisdicciones permitidas (enrutamiento VRF/etiquetas).
PSP/KYC: si el acceso da conexión privada - use; de lo contrario es un proxy egress con mTLS/HMAC, allowlist FQDN.
Registros de transacciones: registro paralelo (en la nube y on-prem) a través de IPsec/Privatelink; registros inmutables.
SLO «rutas de dinero»: túneles/rutas individuales con prioridad y mayor monitoreo.

14) Antipattern

PSK para siempre, una frase secreta «común».
Policy-based con muchos prefijos - «ad admin» (mejor que VTI + BGP).
Ignorar MTU/MSS → fragmentación, tiempos ocultos, 3xx/5xx «sin razón».
Un túnel sin reserva; un proveedor.
La ausencia de NTP/clock-sync → caídas espontáneas de IKE.
Cifrados «predeterminados» (grupos obsoletos/MD5/SHA1).
No hay alertas en flap SA/BGP y crecimiento de RTT/PLR.

15) Lista de comprobación prod

• IKEv2 + AES-GCM + PFS (grupo 14/19/20), lifetimes convenidos, rekey ~ 70%.
• VTI/GRE, BGP con filtros/comunidades, ECMP o hot-standby.
• NAT-T está habilitado (si es necesario), abierto UDP/500/4500, ESP en el camino.
• MTU 1436-1460, MSS clamp 1350-1380, PMTUD está activo.
• DPD 10-15s, respuesta Dead Peer y reinstalación rápida de SA.
• Vigilancia de SA/BGP/RTT/PLR; registros IKE/ESP en una colección centralizada.
• Rotación automática de Sert/Keys, TTL corto, OCSP/CRL, alertas.
• Segmentación (VRF), split-tunnel, política de «deny-by-default».
• Los gateways en la nube (AWS/GCP/Azure) están probados en carga real.
• Runbook documentado 'y Feilover y extensiones de canal.

16) TL; DR

Construya IPsec (VTI/GRE) basado en ruta con IKEv2 + AES-GCM + PFS, enrutamiento BGP dinámico, reserva en dos enlaces independientes y MTU/MSS correcto. Habilite NAT-T, DPD y rekey regular, supervise SA/BGP/RTT/PLR, almacene los registros de autenticación. En las nubes, utilice las gateways managed y PrivateLink; en Kubernetes - no «arrastre» el Pod CIDR a través de una VPN. Para iGaming, mantenga las jurisdicciones y el circuito de pagos aislados, con SLO y auditoría más estrictos.