Interconectando nubes: VPN Site-to-Site entre AWS y Azure
En este taller vamos a unir dos mundos: una red en Azure y una VPC en AWS mediante una VPN Site-to-Site IKEv2. La idea es sencilla: que una máquina en AWS pueda llegar a una VM en Azure por un túnel cifrado, sin exponer el tráfico a Internet.
Qué vamos a montar
El laboratorio crea una VNet en Azure con su GatewaySubnet, una VPN Gateway, una VPC en AWS con su subnet, una Virtual Private Gateway, una Customer Gateway y una conexión VPN Site-to-Site. Después terminamos la configuración en Azure con una Local Network Gateway y validamos conectividad.
El criterio de aceptación es claro: desde una instancia EC2 en AWS debemos poder llegar al servidor web publicado en una VM de Azure.
Esquema del laboratorio
Antes de tocar botones, conviene tener claro el dibujo: Azure tendrá la red 172.100.0.0/16 y AWS la red 10.10.0.0/16. Entre ambas nubes levantaremos un túnel VPN.
Muy importante: evita solapar rangos IP. Si las redes se pisan, el enrutamiento se vuelve un dolor.
Crear el Resource Group en Azure
Empezamos por Azure. Crea un grupo de recursos dedicado para el laboratorio, por ejemplo vpn-aws-azure-rg. Así puedes borrar todo de golpe cuando termines.
Piensa en el grupo de recursos como la carpeta del laboratorio. Aquí agrupamos todo lo que vamos creando: red, gateway, IP pública, VM y objetos asociados.
Esto tiene dos ventajas: lo tienes ordenado y puedes limpiar el laboratorio completo en un único paso. En entornos reales también ayuda a separar costes, permisos y ciclo de vida.
- Usa una región coherente para todos los recursos de Azure.
- Evita nombres genéricos si vas a repetir el laboratorio varias veces.
- Añade tags si quieres practicar gobierno básico desde el principio.
Resource group: vpn-aws-azure-rg
Region: East US
Crear la VNet y sus subredes
Crea una red virtual llamada vnet-01 con direccionamiento 172.100.0.0/16. Dentro, añade una subred para servidores y otra subred obligatoria para el gateway.
La VNet es la red privada de Azure. Es el equivalente conceptual a la VPC de AWS. Aquí es donde vivirán las máquinas y donde se conectará la VPN Gateway.
La subred GatewaySubnet merece atención especial: Azure la usa para desplegar internamente los recursos de la gateway. No metas VMs ni otros servicios ahí.
- ServerSubnet: para servidores o cargas de prueba.
- GatewaySubnet: reservada para la gateway.
- Deja espacio suficiente si luego quieres crecer o probar más subredes.
- ServerSubnet: 172.100.1.0/24
- GatewaySubnet: 172.100.2.0/27
Ojo con el nombre GatewaySubnet: Azure lo espera así para desplegar la VPN Gateway.
Crear la VPN Gateway en Azure
Con la VNet preparada, crea la VPN Gateway. Usaremos una IP pública nueva, que será el extremo Azure del túnel. Para este laboratorio puedes usar tipo VPN, modo RouteBased y sin BGP.
La VPN Gateway es el punto de entrada y salida del túnel en Azure. Cuando se cree, Azure le asignará una IP pública que AWS usará como extremo remoto.
Este recurso suele tardar varios minutos en desplegarse. Es normal. Mientras se crea, puedes ir preparando la parte de AWS para avanzar el laboratorio.
- Tipo: VPN.
- Modo recomendado para este lab: Route-based.
- SKU: usa uno pequeño si solo estás practicando.
La creación tarda un rato. No desesperes: las VPN Gateway en Azure no son instantáneas.
Crear la VPC y la subnet en AWS
Ahora nos vamos a AWS. Crea una VPC llamada vpc-vpn con rango 10.10.0.0/16 y una subnet 10.10.1.0/24. Esta subnet alojará la instancia EC2 desde la que haremos las pruebas.
Para poder conectarte por SSH a la EC2 necesitarás más adelante un Internet Gateway, pero eso es solo para acceso de administración.
Crear y asociar la Virtual Private Gateway en AWS
Crea una Virtual Private Gateway y asígnala a la VPC. Este recurso será el extremo AWS de la VPN desde el lado de la red privada.
La Virtual Private Gateway es el componente de AWS que se acopla a la VPC para permitir conectividad VPN. Sin asociarla a la VPC, el túnel no tendrá un destino real dentro de AWS.
La Customer Gateway, por otro lado, representa al cliente externo: en este caso, Azure. Por eso ahí usamos la IP pública de la VPN Gateway de Azure.
- Virtual Private Gateway: lado AWS.
- Customer Gateway: representación de Azure en AWS.
- Comprueba bien la IP pública antes de crear la Customer Gateway.
Después crea una Customer Gateway apuntando a la IP pública de la VPN Gateway de Azure.
Crear la conexión VPN Site-to-Site en AWS
Crea la conexión VPN seleccionando la Virtual Private Gateway y la Customer Gateway. En prefijos estáticos, indica la red de Azure que quieres alcanzar desde AWS.
La conexión VPN une la Virtual Private Gateway con la Customer Gateway. AWS genera dos túneles por alta disponibilidad, aunque para este laboratorio configuraremos solo uno.
Cuando uses rutas estáticas, tienes que indicar qué prefijos remotos están detrás del otro extremo. En este caso, el prefijo de Azure.
- Selecciona routing estático para simplificar.
- Indica el rango de Azure que quieres alcanzar.
- Después descarga la configuración generada por AWS.
Red Azure remota: 172.100.1.0/24
Routing: Static
Túnel: IPSec/IKEv2
Descargar la configuración del túnel
Cuando AWS crea la VPN, descarga el fichero de configuración. Usa proveedor genérico. Ese fichero incluye dos túneles; para el laboratorio usaremos el túnel 1.
Este fichero es la pieza que conecta ambos mundos. AWS te da los parámetros que Azure necesita conocer: IP pública del túnel, clave precompartida y parámetros IPsec/IKE.
No copies datos del túnel 2 si vas a configurar el túnel 1. Parece una tontería, pero es un fallo muy habitual.
- Guarda la Pre-Shared Key.
- Anota la IP pública del túnel AWS.
- Comprueba que estás usando IKEv2 si el laboratorio lo requiere.
Anota la IP pública del túnel y la clave precompartida. Esos datos se utilizarán en Azure para cerrar la conexión.
Crear la Local Network Gateway en Azure
De vuelta en Azure, crea una Local Network Gateway. Este objeto representa el extremo remoto, en este caso AWS. Pon la IP pública del túnel de AWS y añade el espacio de direcciones de AWS.
La Local Network Gateway es cómo Azure representa la red remota. En nuestro caso, representa AWS: su IP pública de túnel y sus rangos privados.
Si el address space no coincide con la VPC real de AWS, Azure no sabrá qué tráfico enviar por la VPN. Por eso este paso es crítico.
- Endpoint: IP pública del túnel AWS.
- Address space: rango de la VPC AWS.
- Revisa que no estés usando la IP pública de administración de una EC2.
Address space AWS: 10.10.0.0/16
Endpoint: IP pública del túnel AWS
Finalizar conexión y validar
Crea la conexión desde Azure entre la VPN Gateway y la Local Network Gateway usando la misma PSK del túnel AWS. Tras unos minutos, el estado debería pasar a Connected. En AWS verás levantado el túnel 1.
En este punto ya están creados los dos lados. Solo falta crear la conexión en Azure, pegando la misma PSK que AWS generó para el túnel.
Después revisa el estado en ambos portales. Puede tardar unos minutos en aparecer como conectado.
- Estado en Azure: Connected.
- Estado en AWS: Tunnel 1 UP.
- Prueba tráfico real, no solo estado del portal.
Para probarlo, despliega una EC2 en AWS y una VM en Azure con IIS escuchando en el puerto 80. Desde AWS, lanza ping o curl hacia la IP privada de la VM de Azure. Si responde, el laboratorio está funcionando.
Buenas prácticas y avisos
- No solapes rangos CIDR entre nubes.
- Documenta la PSK, IPs públicas, rangos y rutas.
- Usa BGP en diseños más avanzados o productivos si necesitas rutas dinámicas.
- Revisa NSG, Security Groups, tablas de rutas y firewalls del sistema operativo.
- Borra los recursos cuando termines: VPN Gateway, IP pública, EC2 y gateways pueden generar coste.
Resultado esperado
Una VPN Site-to-Site funcional entre AWS y Azure, con tráfico privado cifrado y conectividad validada entre una instancia EC2 y una VM en Azure.
Volver a portada