Unidad 3.6: Conectividad híbrida: VPN, NAT y Cross-Connect

Introducción

Tres de los requisitos de red más difíciles de FinCorp implican cruzar un límite: un enlace cifrado entre sitios desde el centro de datos corporativo hacia la nube durante la migración, una forma para que los servidores de la nube privada descarguen parches y alcancen puntos de acceso de SaaS sin poseer nunca una IP pública, y una ruta privada de baja latencia entre dos de los VDC de FinCorp. La plataforma responde a cada uno con un producto distinto, y los productos no se solapan: un VPN Gateway cifra el tráfico a través de internet público, un NAT Gateway proporciona a los servidores privados solo salida (egreso), y un Private Cross-Connect une VDCs en una LAN privada. Esta unidad establece cuándo se aplica cada producto y sus restricciones innegociables, y luego construye los dos que soportan la migración: un túnel VPN y un NAT Gateway para el egreso privado.

1. Los tres primitivos híbridos y cómo elegirlos

La selección se reduce a una pregunta por cada requisito: ¿está cruzando internet público de forma cifrada, saliendo de una red privada hacia el exterior, o uniendo dos redes privadas de forma privada?

VPN Gateway establece una conexión segura y cifrada de sitio a sitio entre una red en las instalaciones y sus LAN privadas de VDC a través de internet, utilizando túneles IPSec o pares WireGuard. Es la herramienta principal de la migración: conecta un centro de datos corporativo o una oficina sucursal con recursos en la nube durante el período de conmutación y más allá. Sus restricciones definitorias son firmes. La implementación de IPSec es solo IKEv2; IKEv1 no está soportado, por lo que cualquier par heredado configurado para IKEv1 debe ser reconfigurado. La autenticación para IPSec se realiza mediante clave compartida previa (se recomienda una PSK de 32 caracteres). La alta disponibilidad es una opción activo-pasivo que se acopla con la tarifa: al habilitarla, el gateway se ejecuta en modo activo-pasivo, de modo que un túnel redundado asume automáticamente el control en caso de fallo, y ese par de HA presenta una única IP pública, por lo que el par en las instalaciones siempre apunta a una sola dirección. Las direcciones IP del túnel y del gateway son solo IPv4, aunque la carga útil transportada a través del túnel puede ser de doble pila IPv4 e IPv6. No se ofrece BGP; la enrutación es estática, definida por los CIDR de red que se enumeran en cada lado del túnel. El ancho de banda por túnel es de hasta 1 Gbps, y la tarifa establece los límites para las LAN y los túneles.

NAT Gateway es la ruta de salida para cargas de trabajo privadas. Permite que las VM dentro de un VDC alcancen internet sin ninguna interfaz de red pública: el gateway realiza Source NAT, de modo que las VM privadas pueden iniciar conexiones salientes y recibir las respuestas, mientras que las conexiones entrantes iniciadas desde internet se rechazan. Esta es la forma honesta del producto y el punto de confusión más común: NAT Gateway es solo SNAT, sin DNAT y, por lo tanto, sin reenvío de puertos entrantes. Si se necesita tráfico entrante, esa es la función de un balanceador de carga, no de NAT Gateway. Requiere una dirección IPv4 pública reservada (puede llevar varias), soporta hasta seis redes privadas por gateway, y es de alta disponibilidad, ejecutándose en varias zonas de disponibilidad dentro de una región. Sus usos documentados son precisamente los casos de salida de servidores privados: obtener actualizaciones del sistema operativo y del software, alcanzar NTP, permitir que Backup Service alcance VM privadas, y restringir el acceso saliente a puntos finales específicos de confianza.

Private Cross-Connect une múltiples VDC a través de una LAN privada sin exposición pública, para un paso seguro de datos con menor latencia y mejor rendimiento que la enrutación entre ellos a través de internet público. Sus restricciones son categóricas: los VDC participantes deben estar en la misma región y bajo el mismo contrato; no se soportan conexiones entre regiones ni entre contratos. Todas las NIC en todos los VDC conectados deben compartir el mismo rango de IP, una dirección no puede usarse en más de una instancia, y cada LAN puede pertenecer a solo un Cross-Connect. El ancho de banda es comparable al de una NIC privada normal, y la función en sí misma no tiene cargo. Una LAN se conecta a un Cross-Connect configurando el identificador de la conexión en el recurso de la LAN, y un Cross-Connect solo puede eliminarse una vez que se ha desconectado de todas las LAN y VDC. Cuando dos sitios necesitan una línea dedicada proporcionada por un operador en lugar de un enlace VDC a VDC en la misma región, se trata de un servicio de línea dedicada Cloud Connect separado, distinto de Private Cross-Connect; las construcciones de esta unidad utilizan los primitivos de VPN y NAT.

Durante la conmutación de una migración, estos tres cumplen roles complementarios: el VPN Gateway transporta el puente cifrado entre las instalaciones y la nube mientras se trasladan las cargas de trabajo; el NAT Gateway permite que los servidores privados migrados pero aún no públicos alcancen internet para agentes, parches y copias de seguridad; y un Cross-Connect une de forma privada los VDC que deben intercambiar datos dentro de la región. Ninguno sustituye a otro.

Guía de implementación de DCD

Construirá las dos primitivas que soportan la migración de FinCorp: un VPN Gateway con túnel IKEv2 IPSec hacia el centro de datos corporativo, y un NAT Gateway que proporciona a la LAN de aplicaciones privadas solo salida (egreso). Ambas reutilizan el VDC de tres LAN de la Unidad 3.1.

Objetivo de construcción: Aprovisionar un túnel de VPN Gateway; aprovisionar un NAT Gateway para egreso privado.

Requisito previo: reservar direcciones IP públicas primero

Ambas pasarelas consumen una dirección IPv4 pública reservada, y la dirección debe reservarse en la misma ubicación que la pasarela antes de crearla. Utilice la gestión de IP para reservar una dirección IPv4 para el VPN Gateway y otra para el NAT Gateway, en la región donde se encuentra el VDC. Una dirección asignada por DHCP no funcionará; estas pasarelas solo seleccionan direcciones reservadas.

Pasos - VPN Gateway y túnel IPSec (en el Data Center Designer):

1. En la página de VPN Gateways, haga clic en Create VPN Gateway.
2. En Properties, establezca un Nombre, la Location (que coincida con la IP reservada y el VDC) y seleccione la dirección IP Address pública reservada desde el menú desplegable. (La IP y el centro de datos deben estar en la misma ubicación.)
3. En Tier, elija el nivel dimensionado según las necesidades de su LAN y túnel (Standard permite hasta 5 LAN y 10 túneles/peers; Enhanced hasta 10 LAN y 20; Premium hasta 15 LAN y 30). Seleccione la variante de High Availability del nivel para ejecutar en modo activo-pasivo: los túneles redundantes toman el control automáticamente durante una falla, minimizando el tiempo de inactividad, detrás de la única IP de la pasarela.
4. En Protocol, elija IPSec. La versión IKE es IKEv2 por defecto (no hay una opción IKEv1 para seleccionar; esta es la única versión IKE admitida).
5. En LAN Connections, agregue la LAN privada que utilizará la pasarela. Elija una IP privada para la pasarela desde el CIDR de la LAN; el rango recomendado es del .2 al .9, y la dirección no debe estar ya en uso en el VDC. (Nota: un VPN Gateway no puede conectarse a una LAN gestionada directamente por Managed Kubernetes; conecte una LAN de node-pool adicional si ese es su objetivo.)
6. Haga clic en Save. El STATE de la pasarela muestra PROVISIONING y luego AVAILABLE. Puede comenzar a crear el túnel mientras aún está aprovisionándose.
7. En la página de VPN Gateways, haga clic en Create Tunnels para esta pasarela. Introduzca un Name del túnel, el Remote Host (la IP IPv4 pública o FQDN del peer en las instalaciones) y el PSK bajo Authentication (método PSK; use una clave fuerte de 32 caracteres).
8. Establezca la fase Initial Exchange (IKE_SA_INIT): elija un grupo Diffie-Hellman, un algoritmo de cifrado y un algoritmo de integridad de las listas ofrecidas (por ejemplo, grupo DH 16-MODP4096, AES256, SHA256), con una vida útil IKE entre 3600 y 86400 segundos.
9. Establezca la fase Child SA (ESP): elija el grupo Diffie-Hellman, el algoritmo de cifrado y el algoritmo de integridad correspondientes, con una vida útil ESP entre 600 y 14400 segundos.
10. Defina las redes enrutadas: Cloud Network CIDRs (las subredes del lado de IONOS CLOUD permitidas a través del túnel) y Peer Network CIDRs (las subredes en las instalaciones). Estas listas estáticas de CIDR son el enrutamiento; no hay BGP. Guarde el túnel, luego configure el dispositivo en las instalaciones con parámetros idénticos y verifique que el túnel alcance un estado activo.

Pasos - NAT Gateway para egreso privado (en el Data Center Designer):

1. Abra el VDC y confirme que existe una LAN privada que contenga al menos una VM (la LAN de aplicaciones privadas de la Unidad 3.1).
2. Agregue un NAT Gateway al espacio de trabajo y conecte su interfaz (red de origen) a esa LAN privada.
3. Seleccione el NAT Gateway y abra sus Properties en Inspector > Settings. Establezca un Nombre y agregue una dirección IP pública de las direcciones reservadas (una es suficiente; se pueden agregar varias).
4. Cree una regla NAT. Establezca un nombre y un Protocol (TCP, UDP, ICMP o ANY). Para Source > Public IP, seleccione una de las IPs públicas de la pasarela (esto enmascara la dirección de origen saliente). Para Source > Subnet, introduzca la VM privada o subred en notación CIDR (por ejemplo, 10.10.10.0/24). Opcionalmente, restrinja Target > Subnet a destinos externos específicos para permitir el egreso solo a puntos finales de confianza.
5. Establezca la ruta predeterminada de la LAN hacia la pasarela. En las VMs privadas, la tabla de enrutamiento debe enviar el tráfico destinado a Internet a la pasarela NAT: apunte la ruta predeterminada (0.0.0.0/0) hacia ella, o agregue una ruta dedicada por destino externo si una ruta predeterminada no es aceptable. Sin este cambio de enrutamiento, la pasarela existe pero ningún tráfico la utiliza.
6. Si esas VMs privadas necesitan resolución DNS mientras utilizan la ruta predeterminada de NAT, asegúrese de que una regla SNAT cubra UDP, de lo contrario la resolución DNS predeterminada fallará.

Errores comunes:

• Reserve la IP pública estática antes de crear la pasarela; ambas pasarelas seleccionan de direcciones reservadas y una dirección DHCP no puede usarse.
• No busque una opción IKEv1, no existe; el peer debe hablar IKEv2 (o usar WireGuard). Los parámetros de fase 1 y fase 2 deben coincidir exactamente en ambos extremos o el túnel no se establecerá.
• El par VPN HA comparte una IP pública; configure el peer en las instalaciones para apuntar a esa única dirección, no a dos.
• NAT Gateway es solo SNAT: no hay ruta de entrada/DNAT. No intente publicar un servicio a través de ella; use un balanceador de carga para la entrada.
• Aprovechione el NAT Gateway y sus reglas antes de esperar el egreso, luego cambie la ruta predeterminada de la LAN hacia la pasarela; el cambio de enrutamiento es el paso que la gente olvida, y el tráfico nunca sale silenciosamente hasta que se realice.
• Omitir una regla SNAT de UDP rompe el DNS para VMs cuya ruta predeterminada es la pasarela NAT.

Los parámetros del túnel llevan un punto arquitectónico real: las subredes enrutadas son listas estáticas de CIDR en cada lado, no un protocolo dinámico. Una breve vista de API del mismo túnel hace explícita la forma inmutable (los ajustes de fase y los dos arreglos de CIDR son todo el contrato de enrutamiento):

curl -X POST 'https://vpn.de-fra.ionos.com/ipsecgateways/{gatewayId}/tunnels' \
  -H 'Authorization: Bearer <token>' -H 'Content-Type: application/json' \
  --data '{ "properties": {
    "name": "to-fincorp-dc",
    "remoteHost": "vpn.fincorp.example",
    "auth": { "method": "PSK", "psk": { "key": "<32-char-psk>" } },
    "ike": { "diffieHellmanGroup": "16-MODP4096", "encryptionAlgorithm": "AES256", "integrityAlgorithm": "SHA256", "lifetime": 86400 },
    "esp": { "diffieHellmanGroup": "16-MODP4096", "encryptionAlgorithm": "AES256", "integrityAlgorithm": "SHA256", "lifetime": 3600 },
    "cloudNetworkCIDRs": [ "10.0.0.0/24" ],
    "peerNetworkCIDRs":  [ "198.51.100.0/24" ] } }'

Resumen

La conectividad híbrida en IONOS CLOUD consta de tres productos no superpuestos. El VPN Gateway transporta tráfico cifrado entre sitios a través de internet mediante IKEv2 (o WireGuard), enrutamiento estático basado en CIDR y una opción de HA activa-pasiva que presenta una única IP pública. El NAT Gateway proporciona a las cargas de trabajo privadas acceso de solo salida a internet mediante SNAT, sin ruta de entrada, lo que requiere una IP pública reservada y un cambio deliberado de la ruta predeterminada de la LAN. Private Cross-Connect conecta VDCs de forma privada, pero solo dentro de la misma región y contrato. La elección entre ellos depende de qué frontera se está cruzando, y durante una migración, los elementos básicos de VPN y NAT, creados aquí, transportan el tráfico de conmutación.

Puntos clave:

• VPN Gateway utiliza IKEv2/WireGuard sin IKEv1; el enrutamiento se realiza mediante listas estáticas de CIDR (sin BGP); la HA es activa-pasiva sobre una IP pública compartida; hasta 1 Gbps por túnel.
• Reserve la dirección IPv4 pública (en la misma ubicación que el VDC) antes de crear cualquiera de los gateways; no se pueden utilizar direcciones DHCP.
• NAT Gateway es solo SNAT (sin entrada/DNAT), requiere una IP pública reservada, admite hasta seis LAN privadas y solo reenvía tráfico una vez que la ruta predeterminada de la LAN apunta a él.
• Para las VM cuya ruta predeterminada es el gateway NAT, se requiere una regla de SNAT UDP, de lo contrario se rompe la resolución de DNS.
• Private Cross-Connect es solo para la misma región y el mismo contrato, requiere un rango de IP compartido, permite un Cross-Connect por LAN y es gratuito; no es un enlace entre regiones o entre contratos.

Terminología importante:

• SNAT (Source NAT): Reescritura de la dirección de origen de los paquetes salientes para que los hosts privados puedan iniciar conexiones a internet; el NAT Gateway realiza esta función y rechaza el tráfico de entrada no solicitado (DNAT).
• IKEv2: El protocolo de intercambio de claves que utiliza el VPN Gateway de IPSec; es la única versión de IKE admitida, IKEv1 no está disponible.
• Clave compartida (PSK): El secreto compartido que autentica un túnel de IPSec; se recomienda una clave de 32 caracteres y debe coincidir en ambos pares.

Lectura adicional

• Unidad 3.1, Topología y segmentación de VDC, por la base de IP reservada y tres LAN que esta implementación reutiliza.
• Unidades 3.3 y 3.4 sobre equilibrio de carga entrante, la capacidad que NAT Gateway no proporciona deliberadamente.
• Unidad 6.3, Aprovisionamiento de un Cluster privado, donde NAT Gateway y Cross-Connect se convierten en requisitos previos obligatorios para los grupos de nodos privados.