Unidad 2.2: Red y conectividad como código

Introducción

En la Unidad 2.1, usted provisionó la capa de cómputo de TaskBoard: un API servidor y un worker, cada uno iniciado con cloud-init. Esos servidores no son útiles hasta que puedan comunicarse entre sí, acceder a Internet para actualizaciones de paquetes y resolver un nombre de host que apunte de regreso al punto final de API. Ese es el trabajo de la capa de red, y en IONOS Cloud cada parte de ella es un recurso Terraform.

Esta unidad construye la pila de red debajo de TaskBoard. Usted segmentará el tráfico en una capa pública, una capa de aplicación y una capa de base de datos utilizando LANs separadas, conectará servidores a esas LANs con NICs, dará a las capas privadas acceso de salida controlado a través de una puerta de enlace NAT, y publicará un registro DNS para que los clientes puedan encontrar el API. Cada recurso es declarativo, cada dependencia es resuelta por el gráfico de Terraform, y toda la topología es reproducible a partir de un solo terraform apply.

1. LANs para segmentación de red

El recurso ionoscloud_lan es la base de la segmentación de red dentro de un centro de datos virtual. Una LAN es un dominio de difusión de capa 2 limitado a un centro de datos. Usted crea una LAN por nivel, de modo que el tráfico entre niveles debe atravesar un límite controlado en lugar de compartir una red plana.

El argumento más importante es public. Una LAN pública está conectada a la puerta de enlace de internet de IONOS y sus NICs reciben una dirección IPv4 pública enrutable desde el servicio DHCP de la plataforma. Una LAN privada (public = false) no tiene una ruta de internet propia, lo cual es exactamente lo que usted quiere para los niveles de aplicación y base de datos.

1.1 Definiendo los tres niveles

TaskBoard necesita tres LANs: una LAN pública para ingreso, una LAN de aplicación privada para el API y el trabajador, y una LAN de base de datos privada. Cada LAN pertenece al centro de datos que usted provisionó en el Módulo 1.

resource "ionoscloud_lan" "public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-public"
  public        = true
}

resource "ionoscloud_lan" "app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app"
  public        = false
}

resource "ionoscloud_lan" "db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db"
  public        = false
}

Terraform asigna a cada LAN un ID numérico dentro del centro de datos una vez creado. Usted hace referencia a estos IDs desde los recursos NIC en lugar de codificarlos de forma rígida, lo que mantiene la configuración portátil en todos los entornos.

1.2 Direcciones dentro de una LAN

La plataforma asigna a cada LAN una subred privada con un tamaño de subred predeterminado /24, por lo que una sola LAN le da hasta 254 direcciones de host utilizables. Las LANs privadas utilizan rangos RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). El tamaño de unidad de transmisión estándar de Ethernet es de 1500 bytes, lo que importa cuando ajusta los tamaños de paquetes a nivel de aplicación o las cargas de VPN más adelante en esta unidad.

Usted no configura la subred en la LAN en sí. Las direcciones se asignan en el nivel NIC, ya sea automáticamente mediante DHCP o como direcciones IP estáticas explícitas, lo que se cubre en la siguiente sección.

2. Conectando servidores con NICs

Un ionoscloud_nic conecta un servidor a una LAN. Un servidor puede tener varias NICs, y eso es precisamente cómo un host participa en más de un nivel. El servidor API de TaskBoard, por ejemplo, necesita una NIC en la LAN pública (para recibir ingreso) y una NIC en la LAN de la aplicación (para llegar a los niveles de worker y base de datos).

La NIC es donde usted decide si una interfaz obtiene una dirección asignada por DHCP o una estática, y si la plataforma Firewall está activa en esa interfaz.

2.1 Direcciones DHCP y estáticas

Establezca dhcp = true para permitir que el servicio DHCP de la plataforma asigne una dirección. En una LAN pública, esto también asigna automáticamente una dirección pública IPv4 enrutables. Para niveles privados donde desea direcciones predecibles, proporcione una lista explícita ips desde el rango RFC 1918 de la LAN.

# Public-facing NIC on the API server: DHCP-assigned public IP
resource "ionoscloud_nic" "api_public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.public.id
  name          = "api-public"
  dhcp          = true
  firewall_active = true
}

# Private NIC on the API server: static address on the app LAN
resource "ionoscloud_nic" "api_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.app.id
  name          = "api-app"
  dhcp          = false
  ips           = ["10.7.1.10"]
}

La bandera firewall_active activa la Firewall por NIC. Cuando se activa, la Firewall de la NIC bloquea todo el tráfico de entrada por defecto y solo permite tráfico en puertos explícitamente habilitados. La Firewall de la NIC es el control de seguridad por interfaz; la provisión de reglas detalladas y Network Security Groups se cubren en la Unidad 2.3.

2.2 Servidores con varias NICs y membresía en niveles

El worker solo necesita llegar a los niveles de la aplicación y la base de datos, por lo que obtiene dos NICs privadas y no tiene interfaz pública en absoluto.

resource "ionoscloud_nic" "worker_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.worker.id
  lan           = ionoscloud_lan.app.id
  name          = "worker-app"
  dhcp          = false
  ips           = ["10.7.1.20"]
}

resource "ionoscloud_nic" "worker_db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.worker.id
  lan           = ionoscloud_lan.db.id
  name          = "worker-db"
  dhcp          = false
  ips           = ["10.7.2.20"]
}

Como Terraform ve que cada NIC hace referencia tanto a un servidor como a una LAN, automáticamente ordena la creación: centro de datos primero, luego LANs y servidores, luego NICs. Usted nunca escribe una cadena de creación explícita depends_on para esta cadena. Sin una NIC pública, el worker es inaccesible desde Internet, lo que es el aislamiento que desea para un proceso de backend.

3. Acceso saliente con una NAT Gateway

Un LAN privado no tiene una ruta de internet. Eso es bueno para la seguridad de entrada, pero es un problema cuando su servidor API necesita obtener actualizaciones del sistema operativo, recuperar dependencias o llamar a un SaaS API externo. El recurso ionoscloud_natgateway resuelve esto al proporcionar conectividad controlada y solo de salida.

La puerta de enlace NAT es SNAT-only (Source NAT). Reescribe la dirección de origen del tráfico de salida de los hosts privados a una dirección IP pública que la puerta de enlace posee, y bloquea automáticamente todo el tráfico de entrada no solicitado. Una sola puerta de enlace puede servir hasta 6 redes privadas.

3.1 Aprovisionamiento de la puerta de enlace

La puerta de enlace requiere una o más direcciones IPv4 públicas reservadas, que usted asigna como un bloque IP. Adjunte la puerta de enlace a las LAN cuyos hosts necesitan salida, y defina la dirección IP interna de la puerta de enlace que se utiliza en cada LAN.

resource "ionoscloud_ipblock" "nat" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-nat-ip"
}

resource "ionoscloud_natgateway" "taskboard" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nat"
  public_ips    = ionoscloud_ipblock.nat.ips

  lans {
    id           = ionoscloud_lan.app.id
    gateway_ips  = ["10.7.1.1/24"]
  }
}

La llamada subyacente API se asigna a POST /datacenters/{datacenterId}/natgateways. Al igual que todas las operaciones de aprovisionamiento de IONOS, esta es asíncrona; el proveedor Terraform sondea la solicitud hasta que se complete antes de informar que el recurso se ha creado.

3.2 Reglas SNAT

La puerta de enlace no pasa tráfico hasta que usted defina reglas. Una regla de puerta de enlace NAT especifica qué direcciones de origen privadas se traducen y sobre qué protocolo. Las reglas se asignan a POST /datacenters/{datacenterId}/natgateways/{natGatewayId}/rules.

resource "ionoscloud_natgateway_rule" "app_egress" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  natgateway_id = ionoscloud_natgateway.taskboard.id
  name          = "app-tier-egress"
  type          = "SNAT"
  protocol      = "ALL"
  source_subnet = "10.7.1.0/24"
  public_ip     = ionoscloud_ipblock.nat.ips[0]
}

El protocolo se puede restringir (por ejemplo, a TCP o UDP) cuando se desea un control más estricto, pero ALL es adecuado para una regla de salida general. Tenga en cuenta que la ruta predeterminada no se inyecta automáticamente: los hosts en la LAN privada deben utilizar la dirección IP de la puerta de enlace (10.7.1.1 anterior) como su puerta de enlace predeterminada, lo que normalmente se establece a través de cloud-init o opciones DHCP en la NIC.

4. Conectividad de sitio a sitio con IPSec VPN

Cuando TaskBoard necesita acceder a un recurso en su centro de datos local, como un proveedor de identidad interno, usted conecta las dos redes con el recurso ionoscloud_vpn_ipsec_gateway. El VPN Gateway admite IPSec y WireGuard; esta sección utiliza IPSec para un túnel clásico de sitio a sitio.

IPSec en IONOS utiliza IKEv2 y autentica túneles con una clave precompartida (PSK). El VPN API es regional: cada puerta de enlace se encuentra detrás de un host específico de la región, como https://vpn.de-fra.ionos.com, con las puertas de enlace IPSec expuestas en la ruta de recurso /ipsecgateways y sus túneles anidados bajo /ipsecgateways/{gatewayId}/tunnels.

4.1 Puerta de enlace y túnel

La puerta de enlace necesita una dirección pública IP reservada y una conexión al LAN que sirve. El túnel define el peer remoto y los selectores de tráfico.

resource "ionoscloud_ipblock" "vpn" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-vpn-ip"
}

resource "ionoscloud_vpn_ipsec_gateway" "hybrid" {
  name       = "taskboard-hybrid"
  location   = "de/fra"
  gateway_ip = ionoscloud_ipblock.vpn.ips[0]

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    lan_id        = ionoscloud_lan.app.id
    ipv4_cidr     = "10.7.1.5/24"  # the gateway's own host address on the app LAN, not the network address
  }
}

resource "ionoscloud_vpn_ipsec_tunnel" "onprem" {
  gateway_id    = ionoscloud_vpn_ipsec_gateway.hybrid.id
  location      = "de/fra"
  name          = "to-onprem"
  remote_host   = "203.0.113.10"

  auth {
    method = "PSK"
    psk {
      key = var.vpn_psk
    }
  }

  cloud_network_cidrs = ["10.7.1.0/24"]
  peer_network_cidrs  = ["192.168.50.0/24"]
}

Mantenga el PSK fuera del control de código fuente. Declararlo como una variable sensible (variable "vpn_psk" { sensitive = true }) y proporciónelo a través de una variable de entorno o un almacén de secretos, nunca como un literal en el archivo .tf.

4.2 Enrutamiento a través del túnel

El cloud_network_cidrs y el peer_network_cidrs definen qué subredes son accesibles a través del túnel. El tráfico desde 10.7.1.0/24 destinado a 192.168.50.0/24 es cifrado y reenviado; todo lo demás sigue la ruta normal. Coincida exactamente con estos CIDRs en su configuración local, porque una discrepancia es la razón más común por la que un túnel se establece pero no transporta tráfico.

5. DNS como código

Una pila de red que nadie puede encontrar es incompleta. Los recursos ionoscloud_dns_zone y ionoscloud_dns_record le permiten publicar DNS entirely desde Terraform, por lo que el hostname para TaskBoard's API se versiona junto con la infraestructura que lo sirve. IONOS Cloud DNS se sirve desde una red Anycast, por lo que los registros se resuelven desde el punto de presencia más cercano.

5.1 Zonas y registros

Cree la zona, luego agregue registros que apunten al IP público asignado a la NIC pública del servidor API.

resource "ionoscloud_dns_zone" "taskboard" {
  name        = "taskboard.example.com"
  description = "TaskBoard application zone"
  enabled     = true
}

resource "ionoscloud_dns_record" "api" {
  zone_id = ionoscloud_dns_zone.taskboard.id
  name    = "api"
  type    = "A"
  content = ionoscloud_nic.api_public.ips[0]
  ttl     = 300
  enabled = true
}

Los valores de TTL deben estar entre 60 y 604800 segundos. Cloud DNS admite un amplio conjunto de tipos de registros, incluyendo A, AAAA, CNAME, ALIAS, MX, NS, SOA, SRV, TXT, CAA, y HTTPS. Para crear un registro de apex (raíz de zona), deje el campo de nombre de registro vacío en lugar de utilizar @.

La llamada correspondiente a API se publica en https://dns.<region>.ionos.com/zones para zonas y en la ruta /records de la zona para registros, por ejemplo POST https://dns.de-fra.ionos.com/zones/{zoneId}/records.

5.2 Alcance de Cloud DNS y dónde pertenece el failover

Cloud DNS es un servicio de DNS autoritativo: publica y resuelve sus zonas y registros. No sondea sus backends ni realiza failover basado en comprobaciones de salud, por lo que un registro sigue resolviendo su objetivo configurado independientemente de si ese objetivo está activo. No confíe en DNS para enrutar alrededor de un backend fallido. Para el failover automático, coloque un Load Balancer gestionado delante de sus objetivos y apunte el registro de DNS al Load Balancer, de modo que la comprobación de salud y la eliminación de objetivos ocurran en el nivel de equilibrio de carga introducido en la Unidad 2.3.

API Tarjeta de referencia rápida

Puntos de enlace clave de API para la provisión de red y conectividad:

URL base (Cloud API): https://api.ionos.com/cloudapi/v6 Host regional DNS: https://dns.de-fra.ionos.com Host regional VPN: https://vpn.de-fra.ionos.com Autenticación: Authorization: Bearer <token>

Laboratorio de código

Objetivo: Construir la pila de red de tres niveles de TaskBoard con Terraform: LANs públicas, de aplicaciones y de bases de datos, NICs de servidor, una puerta de enlace NAT para salida privada y un registro DNS para el API. Luego, verificar la conectividad entre los niveles.

Requisitos previos:

• Cuenta de IONOS Cloud con token API (IONOS_TOKEN exportado)
• Terraform con el proveedor ionoscloud instalado
• El centro de datos de TaskBoard y los servidores de la Unidad 2.1 ya en estado

Paso 1: Definir las tres LANs

resource "ionoscloud_lan" "public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-public"
  public        = true
}
resource "ionoscloud_lan" "app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app"
  public        = false
}
resource "ionoscloud_lan" "db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db"
  public        = false
}

Salida esperada:

Plan: 3 to add, 0 to change, 0 to destroy.

Paso 2: Adjuntar las NICs de servidor API

resource "ionoscloud_nic" "api_public" {
  datacenter_id   = ionoscloud_datacenter.taskboard.id
  server_id       = ionoscloud_server.api.id
  lan             = ionoscloud_lan.public.id
  dhcp            = true
  firewall_active = true
}
resource "ionoscloud_nic" "api_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.app.id
  dhcp          = false
  ips           = ["10.7.1.10"]
}

Salida esperada:

ionoscloud_nic.api_public: Creation complete after 1m12s

Paso 3: Reservar un bloque IP y crear la puerta de enlace NAT

resource "ionoscloud_ipblock" "nat" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-nat-ip"
}
resource "ionoscloud_natgateway" "taskboard" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nat"
  public_ips    = ionoscloud_ipblock.nat.ips
  lans {
    id          = ionoscloud_lan.app.id
    gateway_ips = ["10.7.1.1/24"]
  }
}

Salida esperada:

ionoscloud_natgateway.taskboard: Creation complete after 2m03s

Paso 4: Agregar la regla de salida SNAT

resource "ionoscloud_natgateway_rule" "app_egress" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  natgateway_id = ionoscloud_natgateway.taskboard.id
  name          = "app-tier-egress"
  type          = "SNAT"
  protocol      = "ALL"
  source_subnet = "10.7.1.0/24"
  public_ip     = ionoscloud_ipblock.nat.ips[0]
}

Salida esperada:

ionoscloud_natgateway_rule.app_egress: Creation complete

Paso 5: Publicar el registro DNS

resource "ionoscloud_dns_zone" "taskboard" {
  name    = "taskboard.example.com"
  enabled = true
}
resource "ionoscloud_dns_record" "api" {
  zone_id = ionoscloud_dns_zone.taskboard.id
  name    = "api"
  type    = "A"
  content = ionoscloud_nic.api_public.ips[0]
  ttl     = 300
  enabled = true
}

Salida esperada:

ionoscloud_dns_record.api: Creation complete

Paso 6: Aplicar y verificar la salida desde un host privado

terraform apply -auto-approve
# SSH to the API server via its public IP, then test outbound through NAT:
ssh root@$(terraform output -raw api_public_ip)
curl -s https://ifconfig.io   # should return the NAT gateway public IP

Salida esperada:

<the public IP from ionoscloud_ipblock.nat>

Paso 7: Verificar la conectividad entre los niveles

# From the API server, reach the worker on the app LAN:
ping -c 2 10.7.1.20

Salida esperada:

2 packets transmitted, 2 received, 0% packet loss

Lista de verificación:

• [ ] Tres LANs creadas (1 pública, 2 privadas)
• [ ] El servidor API tiene tanto una NIC pública como una NIC de nivel de aplicaciones
• [ ] El host privado alcanza internet a través de la puerta de enlace NAT pública IP
• [ ] El servidor API y el trabajador se comunican en el nivel de aplicaciones LAN
• [ ] El registro A DNS se resuelve en la dirección IP pública del servidor API

Limpieza:

terraform destroy -auto-approve

Errores comunes

Errores de los desarrolladores que deben evitarse con la provisión de redes en IONOS Cloud:

1. Suponer que los hosts privados LAN pueden llegar a Internet sin una puerta de enlace NAT

   • Problema: Su servidor API en un LAN privado no puede apt update o llamar a APIs externas, y las conexiones simplemente expiran.
   • Por qué sucede: Un LAN privado (public = false) no tiene una ruta a Internet. La ruta predeterminada no se inyecta automáticamente incluso después de adjuntar una puerta de enlace NAT.
   • Solución: Proporcionar un ionoscloud_natgateway con una regla SNAT, luego apuntar la puerta de enlace predeterminada de los hosts a la puerta de enlace IP a través de cloud-init o opciones DHCP:

   lans {
     id          = ionoscloud_lan.app.id
     gateway_ips = ["10.7.1.1/24"]
   }
   

2. Selectores de tráfico VPN no coincidentes

   • Problema: El túnel IPSec muestra que está activo, pero no se cruzan paquetes y los hosts locales siguen siendo inaccesibles.
   • Por qué sucede: cloud_network_cidrs y peer_network_cidrs no coinciden exactamente con las subredes configuradas en el peer remoto, por lo que el tráfico no se selecciona para el cifrado.
   • Solución: Alinear los CIDRs en ambos extremos con precisión. El lado de IONOS debe enumerar su propia subred LAN y la subred del peer que refleja la configuración del dispositivo remoto:

   cloud_network_cidrs = ["10.7.1.0/24"]
   peer_network_cidrs  = ["192.168.50.0/24"]
   

3. Usar un TTL no válido en un registro DNS

   • Problema: La creación de un registro DNS falla con un error de validación en el campo ttl.
   • Por qué sucede: El TTL está fuera del rango permitido de 60 a 604800 segundos (por ejemplo, un ttl = 30 que se llevó de otro proveedor).
   • Solución: Limitar el TTL al rango admitido:

   resource "ionoscloud_dns_record" "api" {
     ttl = 300   # valid: 60..604800
   }
   

Resumen

Ahora puede crear una red segmentada completa para una aplicación enteramente como código. Las LAN ofrecen aislamiento en capas, las NIC conectan servidores a una o más capas con direcciones estáticas o DHCP, un gateway NAT otorga acceso de salida controlado a hosts privados, un gateway IPSec conecta con redes locales, y los registros DNS publican el punto de acceso, todo declarado en Terraform y reproducible bajo demanda. TaskBoard ahora tiene una capa de entrada pública, una capa de aplicación privada y una capa de base de datos aislada, con salida privada y un nombre de host API resoluble.

La pila de red es el sustrato sobre el que se construye la REST del Módulo 2. La Unidad 2.3 agrega equilibradores de carga y reglas de grupos de seguridad de red sobre estas LAN y NIC, y el Módulo 4 conecta el código de la aplicación con las bases de datos gestionadas que vivirán en la capa de base de datos que acaba de crear.

Puntos clave:

• Un ionoscloud_lan por capa; public = true se conecta al gateway de internet, public = false aísla la capa
• Un servidor se une a múltiples capas al tener múltiples recursos ionoscloud_nic, uno por LAN
• Las LAN privadas necesitan un ionoscloud_natgateway SNAT-only para el acceso de salida, y la ruta predeterminada no se inyecta automáticamente
• El gateway IPSec VPN utiliza IKEv2 con un PSK y requiere selectores de tráfico coincidentes exactamente en ambos extremos
• Las zonas y registros DNS son recursos Terraform con TTL limitados a 60 a 604800 segundos, servidos sobre una red Anycast

Terminología importante:

• LAN: Un dominio de difusión de capa 2 con ámbito en un VDC, la unidad de segmentación de red; provisionado con ionoscloud_lan.
• NIC: Una interfaz de red que conecta un servidor a un LAN; un servidor con NIC en múltiples LAN participa en múltiples capas.
• SNAT (Traducción de NAT de origen): La traducción que el gateway NAT realiza, reescribiendo las direcciones de origen de salida a una IP pública mientras bloquea el tráfico de entrada no solicitado.
• Selector de tráfico: El par de CIDR de la nube y el par en un túnel IPSec que determina qué tráfico se cifra y se enruta a través del VPN.
• Registro Apex: Un registro DNS en la raíz de la zona, creado en Cloud DNS dejando el campo de nombre de registro vacío.

Próximos pasos

Continuar aprendiendo: Unidad 2.3: Equilibrio de carga y Seguridad como código

Temas relacionados:

• Unidad 2.1: Cómputo y automatización de servidores
• Unidad 1.2: Proveedor Terraform y patrones básicos