Tu centro de datos llega a sus cargas de trabajo en AWS por una VPN site-to-site que lleva un año funcionando sin ruido. Una noche AWS reemplaza un endpoint de túnel durante un mantenimiento rutinario, y todas las conexiones a la VPC se caen. En el cortafuegos solo se había configurado el túnel 1. El túnel 2 llevaba en DOWN desde el día en que se creó.
En la mayoría de los diagramas una VPN site-to-site es una sola línea. En la práctica son dos túneles IPsec, dos sesiones BGP y un presupuesto de MTU, y las caídas vienen de las partes que esa línea oculta. Este artículo cubre los bloques de IPsec, un ejemplo de AWS, enrutamiento estático frente a BGP, redundancia, MTU y MSS, monitorización y cuándo encaja mejor un enlace dedicado.
VPN site-to-site frente a VPN de acceso remoto
Una VPN site-to-site une dos redes: las pasarelas de cada extremo mantienen los túneles, y los hosts detrás de ellas no necesitan software de VPN. Una VPN de acceso remoto une un solo dispositivo, con un cliente en cada portátil y un usuario que inicia sesión. Si la necesidad real es que las personas lleguen a aplicaciones internas, un proxy con reconocimiento de identidad en una arquitectura zero trust suele encajar mejor que cualquiera de las dos.
Los bloques de IPsec
IKEv2 (RFC 7296) autentica a los pares y negocia las claves. ESP (RFC 4303) cifra el tráfico.
| Pieza | Qué hace | Elección habitual |
|---|---|---|
| IKE SA (fase 1) | Autentica a los pares y protege IKE; UDP 500, o 4500 detrás de NAT | AES-GCM, SHA-2, grupo DH 14, 19 o 20; 8 horas |
| Child SA (fase 2) | Una asociación de seguridad ESP por sentido | AES-GCM; 1 hora, renegociada con antelación |
| ESP | Cifra cada paquete: protocolo IP 50, o UDP 4500 con NAT traversal | Modo túnel |
| Dead peer detection | Comprobaciones de actividad que limpian o reinician un túnel mudo | 30 a 40 segundos |
| Túnel basado en rutas | Una interfaz de túnel que el enrutamiento y BGP pueden usar | Obligatorio para BGP |
IKEv2 normalmente establece la IKE SA y la primera Child SA en cuatro mensajes (IKE_SA_INIT e IKE_AUTH). IKEv1 quedó obsoleto en 2023 con la RFC 9395. En cuanto a algoritmos, la RFC 8247 hace obligatorio implementar el grupo DH 14 y recomienda el grupo 19; los grupos 2, 5, 23 y 24 no deberían usarse, y el grupo 22 no debe usarse.
Dos túneles por conexión: un ejemplo de AWS
Una AWS Site-to-Site VPN conecta tu dispositivo customer gateway con una pasarela del lado de AWS. Según la documentación de AWS sobre opciones de túnel, cada conexión tiene dos túneles, cada uno con su propia IP pública, que terminan en Availability Zones distintas.
AWS reemplaza los endpoints de túnel por parches y por retirada de hardware, un túnel cada vez, así que un dispositivo que usa un solo túnel puede perder la conectividad cada vez que se reemplaza ese endpoint. AWS Health envía un aviso mensual cuando un túnel está caído más de una hora al día.
Cada túnel tiene un /30 interno de 169.254.0.0/16. AWS toma la primera dirección utilizable, tu dispositivo la segunda, y BGP funciona entre ellas. Tu dispositivo inicia IKE salvo que fijes la acción de arranque en start (solo IKEv2). AWS evalúa las propuestas desde el valor más bajo de su lista permitida, sea cual sea el orden en que las envíe tu dispositivo, así que elimina IKEv1, SHA-1 y los grupos DH 2, 5 y 22 a 24 en ambos lados.
| Virtual private gateway | Transit gateway | |
|---|---|---|
| Conecta | Una VPC | Muchas VPC, VPN y Direct Connect |
| Ancho de banda por túnel | 1,25 Gbps | 1,25 Gbps, o 5 Gbps con Large Bandwidth Tunnels |
| ECMP entre túneles | No | Sí, con BGP |
| Rutas BGP desde tu dispositivo | 100 | 1 000 |
| Coste adicional | Ninguno | Cargos de transit gateway |
Define los túneles en código para que los dos sean idénticos. En Terraform, el túnel 1:
resource "aws_vpn_connection" "dc" {
vpn_gateway_id = aws_vpn_gateway.main.id
customer_gateway_id = aws_customer_gateway.dc.id
type = "ipsec.1"
static_routes_only = false
tunnel1_inside_cidr = "169.254.10.0/30"
tunnel1_ike_versions = ["ikev2"]
tunnel1_phase1_encryption_algorithms = ["AES256-GCM-16"]
tunnel1_phase1_integrity_algorithms = ["SHA2-384"]
tunnel1_phase1_dh_group_numbers = [20]
tunnel1_phase2_encryption_algorithms = ["AES256-GCM-16"]
tunnel1_phase2_dh_group_numbers = [20]
tunnel1_dpd_timeout_seconds = 30
tunnel1_dpd_timeout_action = "restart"
tunnel1_startup_action = "start"
# tunnel2_*: the same values with 169.254.10.4/30
}
Enrutamiento estático o BGP
El enrutamiento estático lista tus prefijos en la conexión y deja la conmutación por error a las comprobaciones de estado de tu dispositivo. Con BGP, cada túnel mantiene una sesión eBGP, y las rutas de un túnel caído se retiran cuando su sesión se cae. AWS recomienda BGP siempre que el dispositivo lo admita, y ECMP lo exige. Cuatro reglas:
- Usa ASN privados distintos. El lado de AWS usa 64512 por defecto. Dale a tu sitio su propio ASN privado: 64512 a 65534, o 4200000000 a 4294967294 (RFC 6996).
- Anuncia resúmenes. Una virtual private gateway acepta como máximo 100 rutas de tu dispositivo, un límite fijo.
- Nunca solapes CIDR. La ruta local de la VPC gana a cualquier ruta VPN, incluso a una más específica. Planifica el espacio de direcciones entre sitios, o aplica NAT en un lado.
- Conoce los criterios de desempate. Para el mismo prefijo, una virtual private gateway prefiere Direct Connect, luego las rutas VPN estáticas, luego las rutas BGP; después la ruta AS más corta y luego el MED más bajo.
Sin ECMP, AWS devuelve el tráfico por un túnel cada vez, marcado con MED. La guía de AWS sobre prioridad de rutas recomienda permitir el enrutamiento asimétrico y mantener iguales las rutas AS. Si tu cortafuegos con estado no lo tolera, alarga la ruta AS con prepending en el túnel 2 y baja su local preference; un cambio en la ruta de salida de AWS puede entonces cortar flujos. La configuración de ejemplo de AWS usa un keepalive de 10 segundos y un hold time de 30 segundos, no los 90 segundos que sugiere la RFC 4271.
Diseños de redundancia
Dos túneles cubren los fallos del lado de AWS. Aun así comparten tu dispositivo, tu ISP y tu sitio.
| Diseño | Túneles | Resiste | No resiste |
|---|---|---|---|
| Un dispositivo, un ISP | 2 | Mantenimiento de endpoints de AWS | Fallo del dispositivo o del ISP |
| Dos dispositivos, un ISP | 4 | Fallo o parcheo de un dispositivo | Caída del ISP |
| Dos dispositivos, dos ISP | 4 | Fallo del dispositivo o del ISP | Perder el sitio |
| Dos conexiones, ECMP en transit gateway | 4 o más | Lo mismo, con más ancho de banda | Un flujo por encima del límite de un túnel |
Con dos dispositivos, cada uno tiene su propia conexión VPN y ambos anuncian los mismos prefijos. ECMP asigna cada flujo a un túnel mediante hash, así que cuatro túneles dan unos 5 Gbps en total, pero una sola conexión TCP sigue topando en 1,25 Gbps, y un cortafuegos con estado puede necesitar source NAT para la simetría. Con muchos sitios, la transit gateway se convierte en el hub de una red hub-and-spoke.
MTU y MSS clamping
Cada paquete tunelizado lleva una nueva cabecera IP más la sobrecarga de ESP. AWS admite como máximo una MTU de 1 446 bytes y un MSS TCP de 1 406 bytes, sin Path MTU Discovery y sin jumbo frames. Los valores exactos dependen de tus algoritmos, según las prácticas recomendadas de AWS para customer gateways:
| Cifrado e integridad | NAT-T | MTU del túnel | MSS TCP (IPv4) |
|---|---|---|---|
| AES-GCM-16 | Desactivado | 1446 | 1406 |
| AES-GCM-16 | Activado | 1438 | 1398 |
| AES-CBC, SHA-1 o SHA2-256 | Desactivado | 1438 | 1398 |
| AES-CBC, SHA-1 o SHA2-256 | Activado | 1422 | 1382 |
| AES-CBC, SHA2-512 | Activado | 1406 | 1366 |
Fija la MTU del túnel y limita (clamp) el MSS de los paquetes TCP SYN en ambos sentidos, ya que cada lado anuncia el suyo. En una pasarela Linux:
ip link set dev vti1 mtu 1446
iptables -t mangle -A FORWARD -o vti1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406
iptables -t mangle -A FORWARD -i vti1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406
El síntoma clásico de un valor incorrecto: el ping y SSH funcionan, pero las copias de archivos se cuelgan. La página de requisitos de dispositivos de AWS sugiere 1 399 bytes, que también funciona pero desperdicia unos pocos bytes.
Monitorizar los túneles
- Estado del túnel. CloudWatch publica TunnelState por túnel; en las conexiones BGP, 1 significa que la sesión está establecida. Crea una alarma cuando cualquiera de los túneles baje de 1. TunnelDataIn y TunnelDataOut muestran qué túnel lleva el tráfico.
- Logs. Los logs de Site-to-Site VPN registran estados de IKE, eventos DPD, el estado de BGP y cambios de rutas.
- Tu lado. Vigila el estado de BGP y los prefijos recibidos por túnel. Una sesión establecida con cero prefijos sigue siendo una caída.
Cuando un túnel no levanta, comprueba por capas: IKE SA, IPsec SA, un ping a la dirección interna de AWS y después BGP.
Cuándo pasar a Direct Connect
| Site-to-Site VPN | Direct Connect | |
|---|---|---|
| Ruta | Internet pública, cifrada | Circuito privado en una ubicación de Direct Connect |
| Ancho de banda | 1,25 Gbps por túnel, 5 Gbps con Large Bandwidth Tunnels | De 50 Mbps a 25 Gbps alojado, de 1 a 400 Gbps dedicado |
| SLA | 99,95 % por conexión | Hasta 99,99 % con el modelo de máxima resiliencia |
| Cifrado | IPsec, siempre | Ninguno por defecto; MACsec en puertos dedicados compatibles, o IPsec encima |
Pasa cuando el tráfico es constante en gigabits, la latencia importa o la salida a internet cuesta más que un puerto. Desde septiembre de 2026, las conexiones dedicadas de 10 y 100 Gbps pueden usar una tarifa plana que incluye la transferencia de datos de salida dentro de un nivel. Mantén la VPN como respaldo: una virtual private gateway prefiere las rutas de Direct Connect, así que el tráfico usa los túneles solo cuando falla el circuito. El diagrama de arquitectura de recuperación ante desastres cubre esa planificación.
El diagrama de VPN site-to-site
Contenido del diagrama
- On-premises data center · 10.20.0.0/16 · AS 65010
- Server LAN
- ERP database
- File server
- Edge firewall (customer gateway)
- VPC · eu-west-1
- Virtual private gateway · AS 64512
- Tunnel 1 endpoint
- Tunnel 2 endpoint
- Private subnet · eu-west-1a
- App instance
- Private subnet · eu-west-1b
- to 10.50.0.0/16
- Tunnel 1 · inside 169.254.10.0/30 · BGP .2 ↔ .1
- Tunnel 2 · inside 169.254.10.4/30 · BGP .6 ↔ .5
- 10.20.0.0/16
Cómo leerlo:
- A la izquierda, el centro de datos: 10.20.0.0/16 en el AS 65010. La LAN envía el tráfico de la VPC al cortafuegos de borde, el dispositivo customer gateway.
- Dos túneles llegan a dos endpoints de la virtual private gateway, cada uno con su /30 interno y su sesión BGP. Ambos están activos; AWS elige el túnel de vuelta.
- A la derecha, la VPC: 10.50.0.0/16, con subredes privadas en dos Availability Zones y una ruta propagada a 10.20.0.0/16.
- El bloque Markdown lista los ajustes que deben coincidir en ambos túneles.
- Las notas de abajo dicen qué cubren dos túneles (reemplazos de endpoints) y qué no (un cortafuegos, un ISP).
Dibujar con claridad diagramas de VPN site-to-site
- Etiqueta ambos extremos con CIDR, ASN e IP pública. La mayoría de los tickets de VPN empiezan por uno de ellos.
- Dibuja ambos túneles con sus /30 internos y sus pares BGP, e indica cuál se prefiere y por qué.
- Pon los ajustes compartidos en un solo cuadro: versión de IKE, algoritmos, grupo DH, tiempos de vida, MTU y MSS.
- Muestra los puntos únicos de fallo, como un solo dispositivo o un solo ISP.
- Deja fuera las claves precompartidas, los detalles internos del ISP y las listas de hosts.
El diagrama de topología de red cubre el lado de la oficina; el diagrama de VPC de AWS cubre las subredes y las tablas de rutas.
Constrúyelo en Archboard
- Inicia sesión con Google o GitHub y crea un diagrama.
- Añade un Marco del paquete Básico para el centro de datos, con su CIDR y su ASN como nombre. Dentro, añade una Subred con dos nodos Servidor y un Cortafuegos, todos del paquete Red.
- Añade una VPC del paquete Red. Dentro, añade un Marco para la virtual private gateway con dos nodos Enrutador, y dos Subred privadas con una Instancia de cómputo del paquete Nube en cada una.
- Dibuja los túneles desde el cortafuegos hasta los endpoints con flechas en ambos extremos, etiquetados con el /30 interno y los pares BGP. Añade conexiones de la LAN al cortafuegos y de la pasarela a las subredes.
- Añade un bloque Markdown del paquete Básico entre los túneles para los ajustes compartidos, y notas de Texto.
Si la VPN está definida en Terraform, la herramienta gratuita de Terraform a diagrama te da un primer borrador; consulta también los diagramas de red.
El ejemplo usa 14 nodos de diagrama, dentro del plan Free.
Preguntas frecuentes
¿Qué debe mostrar un diagrama de VPN site-to-site? Las dos redes con sus CIDR, la IP pública y el ASN de cada pasarela, las direcciones internas de cada túnel, el enrutamiento y los ajustes que ambos lados deben compartir.
¿Por qué una AWS Site-to-Site VPN tiene dos túneles? Cada conexión tiene dos túneles hacia endpoints en Availability Zones distintas. AWS los mantiene de uno en uno, así que con ambos configurados el tráfico se desplaza en lugar de detenerse.
¿Debo usar enrutamiento estático o BGP sobre IPsec? BGP, siempre que tu dispositivo lo admita. Retira automáticamente las rutas de un túnel caído y es obligatorio para ECMP. El enrutamiento estático es para dispositivos sin BGP.
¿Qué MTU y MSS debo usar en una VPN de AWS? Como máximo 1 446 y 1 406 bytes, con AES-GCM y sin NAT traversal. Los cifrados CBC y NAT-T necesitan valores menores de la tabla de AWS.
¿Cuándo debo usar Direct Connect en lugar de una VPN? Cuando el tráfico es constante en gigabits, la latencia debe ser predecible o necesitas un SLA de hasta 99,99 %. Mantén la VPN como respaldo cifrado.