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 se refieren a llegar a través de un límite: un enlace de sitio a sitio cifrado desde el centro de datos corporativo hasta la computación en la nube durante la migración, una forma para que los servidores de Private Cloud puedan obtener parches y llegar a puntos de conexión de SaaS sin poseer nunca una dirección IP pública, y un camino privado de baja latencia entre dos de los centros de datos virtuales (VDC) de FinCorp. La plataforma responde a cada uno con un producto distinto, y los productos no se superponen: un VPN Gateway cifra el tráfico a través de internet público, un NAT Gateway proporciona a los servidores privados una salida solo de salida, y un Private Cross-Connect une los VDC en una LAN privada. Esta unidad establece cuándo se aplica cada uno y sus limitaciones no negociables, luego construye los dos que llevan la migración: un túnel VPN y un NAT Gateway para salida privada.

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

La selección se reduce a una pregunta por requisito: ¿está cruzando internet cifrado, saliendo de una red privada o uniendo dos redes privadas de forma privada?

El VPN Gateway establece una conexión segura y cifrada de sitio a sitio entre una red local y sus LANs privadas de VDC a través de internet, utilizando túneles IPSec o pares WireGuard. Es el caballo de batalla para la migración: conecta un centro de datos corporativo o una oficina de sucursal con recursos en la nube durante la duración de un corte y más allá. Sus restricciones definitorias son firmes. La implementación de IPSec es solo IKEv2; IKEv1 no es compatible, por lo que cualquier peer heredado configurado para IKEv1 debe ser reconfigurado. La autenticación para IPSec es mediante clave precompartida (se recomienda una clave PSK de 32 caracteres). La alta disponibilidad es una opción activa-pasiva que se puede combinar con el nivel: al habilitarla, se ejecuta la puerta de enlace en modo activo-pasivo, de modo que un túnel redundante se hace cargo automáticamente en caso de fallo, y ese par de alta disponibilidad presenta una sola dirección pública IP, de modo que el peer local siempre apunta a una dirección. Las direcciones de la puerta de enlace y del túnel IP son solo IPv4, aunque la carga útil transportada a través del túnel puede ser de pila dual IPv4 y IPv6. No se ofrece BGP; la routificación es estática, definida por los CIDR de red que se enumeran en cada lado del túnel. El rendimiento por túnel es de hasta 1 Gbps, y el nivel establece los límites en las LANs y los túneles.

La puerta de enlace NAT es la ruta de salida para las cargas de trabajo privadas. Permite que las máquinas virtuales dentro de un VDC lleguen a internet sin ninguna interfaz de red pública: la puerta de enlace realiza la traducción de direcciones de origen, de modo que las máquinas virtuales privadas puedan iniciar conexiones salientes y recibir respuestas, mientras que las conexiones entrantes iniciadas desde internet son rechazadas. Esta es la forma honesta del producto y el punto de confusión más común: la puerta de enlace NAT es solo SNAT, sin DNAT y, por lo tanto, sin reenvío de puertos entrantes. Si necesita conexiones entrantes, ese es el trabajo de un Load Balancer, no el de la puerta de enlace NAT. Requiere una dirección pública IPv4 reservada (puede transportar varias), admite hasta seis redes privadas por puerta de enlace y es altamente disponible, ejecutándose en varias zonas de disponibilidad en una región. Sus usos documentados son precisamente los casos de servidores privados salientes: obtener actualizaciones del sistema operativo y del software, llegar a NTP, permitir que el Backup Service llegue a máquinas virtuales privadas y restringir el acceso saliente a puntos de confianza específicos.

El Conexión privada cruzada une varios VDC a través de una red privada LAN sin exposición pública, para el paso seguro de datos con menor latencia y mejor rendimiento que la routificación entre ellos a través de internet. Sus restricciones son categóricas: los VDC participantes deben estar en la misma región y bajo el mismo contrato; no se admiten cruces de región y contrato. Todas las NIC en los VDC conectados deben compartir el mismo rango de direcciones IP, una dirección no puede usarse en más de una instancia y cada LAN solo puede pertenecer a una Conexión privada cruzada. La banda ancha es comparable a una NIC privada normal, y la función en sí no conlleva cargo. Una LAN se conecta a una Conexión privada cruzada estableciendo el identificador de la conexión en el recurso LAN, y una Conexión privada cruzada solo se puede eliminar una vez que se ha desconectado de todas las LANs y VDC. Donde dos sitios necesitan una línea dedicada proporcionada por el transportista en lugar de un enlace de VDC a VDC en la misma región, ese es un servicio de línea dedicada de Cloud Connect separado, distinto de la Conexión privada cruzada; las construcciones de esta unidad utilizan los primitivos VPN y NAT.

Durante un corte de migración, estos tres juegan papeles complementarios: el VPN Gateway transporta el puente cifrado entre locales y nube mientras se mueven las cargas de trabajo; la puerta de enlace NAT permite que los servidores privados migrados pero no aún públicos lleguen a internet para agentes, actualizaciones y copias de seguridad; y una Conexión privada cruzada une privadamente los VDC que deben intercambiar datos dentro de la región. Ninguno sustituye al otro.

Implementación de DCD: Guía paso a paso

Usted construirá los dos primitivos que llevan el cutover de FinCorp: un túnel VPN Gateway con IKEv2 y un NAT Gateway que da a la aplicación privada LAN una salida solo de salida. Ambos reutilizan el VDC de tres LAN de la Unidad 3.1.

Objetivo de la construcción: Proporcionar un túnel VPN Gateway; proporcionar un NAT Gateway para la salida privada.

Requisito previo: reserve las direcciones IP públicas primero

Ambas puertas de enlace consumen una dirección IP pública reservada IPv4, y la dirección debe estar reservada en el mismo lugar que la puerta de enlace antes de crearla. Utilizando IP Management, reserve una dirección IPv4 para el VPN Gateway y una para el NAT Gateway, en la región donde vive el VDC. Una dirección asignada por DHCP no funcionará; estas puertas de enlace seleccionan solo direcciones reservadas.

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

1. Desde la página de puertas de enlace VPN, haga clic en Crear VPN Gateway.
2. En Propiedades, establezca un nombre, la Ubicación (coincidiendo con la dirección IP reservada y el VDC), y seleccione la dirección pública reservada IP desde el menú desplegable. (La dirección IP y el centro de datos deben estar en la misma ubicación.)
3. En Nivel, elija el nivel dimensionado para sus necesidades de LAN y túnel (Estándar permite hasta 5 LAN y 10 túneles/pares; Mejorado hasta 10 LAN y 20; Premium hasta 15 LAN y 30). Seleccione la variante de Alta disponibilidad del nivel para ejecutar activo-pasivo: los túneles redundantes se hacen cargo automáticamente durante una falla, minimizando el tiempo de inactividad, detrás de la puerta de enlace única IP.
4. En Protocolo, elija IPSec. La versión IKE es IKEv2 por defecto (no hay opción IKEv1 para seleccionar; esta es la única versión IKE compatible).
5. En Conexiones LAN, agregue la aplicación privada LAN que utilizará la puerta de enlace. Elija una dirección privada IP para la puerta de enlace desde el CIDR de la aplicación LAN; el rango recomendado es .2 a .9, y la dirección no debe estar en uso en el VDC. (Nota: una puerta de enlace VPN Gateway no puede conectarse directamente a una aplicación LAN gestionada por Managed Kubernetes; conecte una aplicación adicional Node-pool LAN si ese es su objetivo.)
6. Haga clic en Guardar. El estado de la puerta de enlace muestra PROVISIONANDO, luego DISPONIBLE. Puede comenzar a crear el túnel mientras aún se está provisionando.
7. En la página de puertas de enlace VPN, haga clic en Crear túneles para esta puerta de enlace. Introduzca un nombre de túnel, el Host remoto (el peer de la red local con la dirección IP pública IPv4 o FQDN), y el PSK bajo Autenticación (método PSK; use una clave fuerte de 32 caracteres).
8. Establezca la fase Intercambio inicial (IKE_SA_INIT): elija un grupo Diffie-Hellman, un algoritmo de cifrado y un algoritmo de integridad de la lista ofrecida (por ejemplo, grupo DH 16-MODP4096, AES256, SHA256), con un tiempo de vida IKE entre 3600 y 86400 segundos.
9. Establezca la fase SA hijo (ESP): elija el grupo Diffie-Hellman coincidente, el algoritmo de cifrado y el algoritmo de integridad, con un tiempo de vida ESP entre 600 y 14400 segundos.
10. Defina las redes enrutadas: CIDR de red en la nube (las subredes de IONOS permitidas a través del túnel) y CIDR de red del peer (las subredes de la red local). Estas listas de CIDR estáticas son la routificación; no hay BGP. Guarde el túnel y configure el dispositivo de la red local con parámetros idénticos y verifique que el túnel alcance un estado activo.

Pasos - NAT Gateway para salida privada (en el Data Center Designer):

1. Abra el VDC y confirme que existe una aplicación privada LAN que contenga al menos un VM (la aplicación privada LAN de la Unidad 3.1).
2. Agregue un NAT Gateway al espacio de trabajo y conecte su interfaz (red de origen) a esa aplicación privada LAN.
3. Seleccione el NAT Gateway y abra sus Propiedades en el Inspector > Configuración. Establezca un nombre y agregue una dirección IP pública IP de las direcciones reservadas (una es suficiente; se pueden agregar varias).
4. Cree una regla NAT. Establezca un nombre y un Protocolo (TCP, UDP, ICMP o CUALQUIERA). Para Origen > Dirección IP pública, seleccione una de las direcciones IP públicas de la puerta de enlace (esto enmascara la dirección de origen de salida). Para Origen > Subred, introduzca la subred privada VM o subred en notación CIDR (por ejemplo, 10.10.10.0/24). Opcionalmente, restrinja Destino > Subred a destinos externos específicos para permitir solo la salida a puntos de llegada de confianza.
5. Establezca la ruta predeterminada de la aplicación LAN en la puerta de enlace. En las máquinas virtuales privadas, la tabla de routificación debe enviar el tráfico de Internet a la puerta de enlace NAT: apunte la ruta predeterminada (0.0.0.0/0) a ella, o agregue una ruta dedicada por destino externo si una ruta predeterminada no es aceptable. Sin este cambio de routificación, la puerta de enlace existe pero no se utiliza.
6. Si esas máquinas virtuales privadas necesitan resolución de DNS mientras utilizan la ruta predeterminada NAT, asegúrese de que una regla SNAT cubra UDP, de lo contrario, la resolución de DNS predeterminada fallará.

Errores comunes:

• Reserve la dirección IP pública estática IP antes de crear la puerta de enlace; ambas puertas de enlace seleccionan direcciones reservadas y una dirección asignada por DHCP no puede ser utilizada.
• No busque una opción IKEv1, no hay ninguna; el peer debe hablar IKEv2 (o utilizar WireGuard). Los parámetros de fase 1 y fase 2 deben coincidir en ambos extremos exactamente o el túnel no se establecerá.
• El par de alta disponibilidad VPN comparte una dirección IP pública IP; configure el peer de la red local para que se dirija a esa dirección única, no a dos.
• El NAT Gateway es SNAT-only: no hay camino de entrada/DNAT. No intente publicar un servicio a través de él; use un Load Balancer para la entrada.
• Proporcione el NAT Gateway y sus reglas antes de esperar la salida, luego cambie la ruta predeterminada de la aplicación LAN a la puerta de enlace, el cambio de routificación es el paso que la gente olvida, y el tráfico nunca sale en silencio hasta que se realiza.
• Falta una regla SNAT de UDP rompe la resolución de DNS para las máquinas virtuales cuya ruta predeterminada es la puerta de enlace NAT.

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

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 consta de tres productos no superpuestos. El VPN Gateway transporta tráfico de sitio a sitio cifrado a través de Internet con IKEv2 (o WireGuard), enrutamiento estático basado en CIDR y una opción de alta disponibilidad activa-pasiva que presenta una sola dirección pública IP. El NAT Gateway proporciona acceso a Internet solo de salida para las cargas de trabajo privadas a través de SNAT, sin camino de entrada, lo que requiere una dirección pública IP reservada y un cambio deliberado de la ruta predeterminada LAN. Private Cross-Connect une VDCs de forma privada, pero solo dentro de la misma región y contrato. La elección entre ellos depende de qué límite se esté cruzando, y durante una migración, los primitivos VPN y NAT, construidos aquí, transportan el tráfico de corte.

Puntos clave:

• El VPN Gateway es IKEv2/WireGuard sin IKEv1; el enrutamiento es estático con listas CIDR (no BGP); la alta disponibilidad es activa-pasiva en una dirección pública IP compartida; hasta 1 Gbps por túnel.
• Reserve la dirección pública IPv4 (en la misma ubicación que el VDC) antes de crear cualquier gateway; no se pueden utilizar direcciones DHCP.
• El NAT Gateway es solo SNAT (no entrada/DNAT), necesita una dirección pública IP reservada, admite hasta seis LANs privadas y solo reenvía tráfico una vez que la ruta predeterminada LAN apunta a él.
• Para las máquinas virtuales cuya ruta predeterminada es el NAT gateway, se requiere una regla UDP SNAT o se produce un error en la resolución DNS.
• Private Cross-Connect es solo para la misma región y contrato, requiere un rango de direcciones IP compartido, permite un enlace Cross-Connect por LAN y es gratuito; no es un enlace entre regiones o contratos.

Terminología importante:

• SNAT (Source NAT): Reescribir la dirección de origen de los paquetes de salida para que los hosts privados puedan iniciar conexiones a Internet; el NAT Gateway realiza esto y rechaza el tráfico de entrada no solicitado (DNAT).
• IKEv2: El protocolo de intercambio de claves que utiliza el túnel IPSec VPN Gateway; la única versión de IKE admitida, IKEv1 no está disponible.
• Clave precompartida (PSK): El secreto compartido que autentica un túnel 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, para el trabajo de base de tres-LAN y el trabajo de base reservado-IP que esta construcción reutiliza.
• Unidad 3.3 y 3.4 para el equilibrio de carga de entrada, la capacidad que la puerta de NAT no proporciona deliberadamente.
• Unidad 6.3, Provisionamiento de un Cluster privado, donde la puerta de NAT y Cross-Connect se convierten en requisitos previos obligatorios para un Node Pools privado.