Unidad 2.2: Red y conectividad como código

Introducción

En la Unidad 2.1, aprovisionó la capa de cómputo de TaskBoard: un servidor de API y un worker, cada uno iniciado con cloud-init. Esos servidores son inútiles hasta que puedan comunicarse entre sí, acceder a internet para actualizar paquetes y resolver un nombre de host que apunte de vuelta al punto de acceso de la API. Esa es la función de la capa de red, y en IONOS CLOUD cada parte de ella es un recurso de Terraform.

Esta unidad construye la pila de red que subyace a TaskBoard. 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á los servidores a esas LANs con NICs, otorgará a las capas privadas acceso saliente controlado a través de una pasarela NAT y publicará un registro de DNS para que los clientes puedan encontrar la API. Cada recurso es declarativo, cada dependencia se resuelve mediante el grafo de Terraform y toda la topología es reproducible a partir de un único terraform apply.

1. LAN para la segmentación de red

El recurso ionoscloud_lan es la base de la segmentación de red dentro de un VDC. Una LAN es un dominio de difusión de capa 2 limitado a un centro de datos. Debe crear una LAN por nivel para que el tráfico entre niveles deba cruzar 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 pasarela de internet de IONOS CLOUD y sus NIC reciben una dirección IPv4 pública enrutable del servicio DHCP de la plataforma. Una LAN privada (public = false) no tiene una ruta de internet propia, lo cual es exactamente lo que se desea para los niveles de aplicación y base de datos.

1.1 Definición de los tres niveles

TaskBoard requiere tres LAN: una LAN pública para la entrada, una LAN de aplicación privada para la API y el worker, y una LAN de base de datos privada. Cada LAN pertenece al centro de datos que 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 que se crea. Se hace referencia a estos IDs desde los recursos de NIC en lugar de codificarlos de forma fija, lo que mantiene la configuración portable entre entornos.

1.2 Direccionamiento dentro de una LAN

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

No configura la subred en la propia LAN. Las direcciones se asignan a nivel de NIC, ya sea automáticamente mediante DHCP o como IPs estáticas explícitas, lo que se aborda en la siguiente sección.

2. Adjuntar servidores con NICs

Una ionoscloud_nic conecta un servidor a una LAN. Un servidor puede tener múltiples NICs, y es precisamente así como 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 tráfico entrante) y una NIC en la LAN de aplicaciones (para alcanzar los niveles de workers y base de datos).

La NIC es donde se decide si una interfaz recibe una dirección asignada por DHCP o una dirección estática, y si el firewall de la plataforma está activo en esa interfaz.

2.1 Dirección DHCP y estática

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 enrutable. Para niveles privados donde se desean direcciones predecibles, proporcione una lista explícita de 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 el firewall por NIC. Cuando se activa, el firewall de la NIC bloquea todo el tráfico entrante de forma predeterminada y solo permite el tráfico en los puertos habilitados explícitamente. El firewall de la NIC es el control de seguridad por interfaz; la provisión detallada de reglas y los Network Security Groups se abordan en la Unidad 2.3.

2.2 Servidores con múltiples NIC y membresía en niveles

El worker solo necesita acceder a los niveles de aplicación y base de datos, por lo que se le asignan dos NIC privadas y no se le proporciona ninguna interfaz pública.

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"]
}

Dado que Terraform detecta que cada NIC hace referencia tanto a un servidor como a una LAN, ordena automáticamente la creación: primero el centro de datos, luego las LAN y los servidores, y después las NIC. Nunca se escribe un depends_on explícito para esta cadena. Al no haber una NIC pública, el nodo de trabajo no es accesible desde internet, lo cual es el aislamiento que se desea para un proceso de backend.

3. Acceso saliente con una pasarela NAT

Una LAN privada no tiene una ruta hacia Internet. Esto es beneficioso para la seguridad de tráfico entrante, pero representa un problema cuando su servidor de API necesita descargar actualizaciones del sistema operativo, obtener dependencias o llamar a una API SaaS externa. El recurso ionoscloud_natgateway resuelve este problema al proporcionar conectividad controlada y exclusivamente saliente.

La pasarela NAT opera únicamente como SNAT (Source NAT). Reescribe la dirección de origen del tráfico saliente desde los hosts privados hacia una IP pública que posee la pasarela, y bloquea automáticamente todo el tráfico entrante no solicitado. Una sola pasarela puede servir hasta 6 redes privadas.

3.1 Aprovisionamiento de la pasarela

La pasarela requiere una o más direcciones IPv4 públicas reservadas, las cuales debe asignar como un bloque de IP. Conecte la pasarela a las LAN cuyos hosts necesiten salida, y defina la IP interna de la pasarela que 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 de API subyacente se corresponde con POST /datacenters/{datacenterId}/natgateways. Al igual que todas las operaciones de aprovisionamiento de IONOS CLOUD, esta operación es asíncrona; el proveedor de Terraform realiza consultas periódicas a la solicitud hasta que esta se completa antes de informar de que el recurso ha sido creado.

3.2 Reglas SNAT

La pasarela no permite el paso del tráfico hasta que usted defina reglas. Una regla de pasarela NAT especifica qué direcciones de origen privadas se traducen y mediante qué protocolo. Las reglas se corresponden con 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 puede restringirse (por ejemplo, a TCP o UDP) cuando se desea un control más estricto, pero ALL es apropiado para una regla de egreso general. Tenga en cuenta que la ruta predeterminada no se inyecta automáticamente: los hosts en la LAN privada deben usar la IP de la pasarela (10.7.1.1 anterior) como su pasarela predeterminada, la cual normalmente se configura a través de cloud-init o las opciones de 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, se establecen puentes entre las dos redes mediante 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 CLOUD utiliza IKEv2 y autentica los túneles mediante una clave compartida previa (PSK). La API de VPN es regional: cada gateway se encuentra detrás de un host específico de la región, como https://vpn.de-fra.ionos.com, con los gateways de IPSec expuestos en la ruta de recurso /ipsecgateways y sus túneles anidados bajo /ipsecgateways/{gatewayId}/tunnels.

4.1 Gateway y túnel

El gateway requiere una IP pública reservada y una conexión a la LAN que sirve. El túnel define el par 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 versiones. Declárelo como una variable sensible (variable "vpn_psk" { sensitive = true }) y proporciónelo mediante 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

Los parámetros cloud_network_cidrs y 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 se cifra y reenvía; todo lo demás sigue el enrutamiento normal. Asegúrese de que estos CIDR coincidan exactamente con su configuración en las instalaciones, ya que una discrepancia es la causa más común de que un túnel se establezca pero no transporte tráfico.

5. DNS como código

Una pila de red que nadie puede encontrar está incompleta. Los recursos ionoscloud_dns_zone y ionoscloud_dns_record le permiten publicar DNS por completo desde Terraform, de modo que el nombre de host de la API de TaskBoard se versiona junto con la infraestructura que la 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 y, a continuación, agregue registros que apunten a la IP pública asignada a la NIC pública del servidor de 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, entre ellos A, AAAA, CNAME, ALIAS, MX, NS, SOA, SRV, TXT, CAA y HTTPS. Para crear un registro de ápice (raíz de la zona), deje el campo de nombre del registro vacío en lugar de usar @.

La llamada a la API correspondiente envía una solicitud POST a https://dns.<region>.ionos.com/zones para las zonas y a la ruta /records de la zona para los registros, por ejemplo POST https://dns.de-fra.ionos.com/zones/{zoneId}/records.

5.2 Alcance de Cloud DNS y dónde corresponde la conmutación por error

Cloud DNS es un servicio DNS autoritativo: publica y resuelve sus zonas y registros. No realiza sondeos a sus backends ni ejecuta conmutación por error basada en comprobaciones de estado, por lo que un registro sigue resolviéndose hacia su destino configurado, independientemente de si dicho destino está activo o no. No confíe en DNS para enrutar alrededor de un backend fallido. Para la conmutación por error automática, coloque un equilibrador de carga administrado delante de sus destinos y dirija el registro DNS hacia el equilibrador de carga, de modo que la comprobación de estado y la eliminación de destinos se realicen en la capa de equilibrado de carga introducida en la Unidad 2.3.

Tarjeta rápida de referencia de API

Puntos finales de API clave para la aprovisionamiento de red y conectividad:

URL base (API de Cloud): https://api.ionos.com/cloudapi/v6 Host DNS regional: https://dns.de-fra.ionos.com Host VPN regional: 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 aplicación y de base de datos, tarjetas de red (NIC) de los servidores, un gateway NAT para la salida privada y un registro DNS para la API. A continuación, verificar la conectividad entre los niveles.

Requisitos previos:

• Cuenta de IONOS CLOUD con token de API (IONOS_TOKEN exportado)
• Terraform con el proveedor ionoscloud instalado
• El centro de datos y los servidores de TaskBoard de la Unidad 2.1 ya presentes en el 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 NIC del servidor de 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 de IP y crear el gateway de 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 de 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 de la capa

# 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:

• [ ] Se crearon tres LAN (1 pública, 2 privadas)
• [ ] El servidor de API tiene tanto una NIC pública como una NIC de nivel de aplicación
• [ ] El host privado accede a internet a través de la IP pública de NAT
• [ ] El servidor de API y el worker se comunican en la LAN de aplicaciones
• [ ] El registro A de DNS se resuelve a la IP pública de API

Limpieza:

terraform destroy -auto-approve

Errores comunes

Errores de desarrollo que debe evitar al aprovisionar redes en IONOS CLOUD:

1. Esperar que los hosts de una LAN privada puedan acceder a internet sin una pasarela NAT

   • Problema: Su servidor de API en una LAN privada no puede apt update ni llamar a APIs externas, y las conexiones simplemente agotan el tiempo de espera.
   • Por qué ocurre: Una LAN privada (public = false) no tiene una ruta hacia internet. La ruta predeterminada no se inyecta automáticamente, incluso después de que usted adjunte una pasarela NAT.
   • Solución: Aprovisione un ionoscloud_natgateway con una regla SNAT y, a continuación, dirija la puerta de enlace predeterminada de los hosts hacia la IP de la pasarela mediante cloud-init u opciones de DHCP:

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

2. Selectores de tráfico de VPN no coincidentes

   • Problema: El túnel IPSec se muestra como activo, pero no hay paquetes que lo crucen y los hosts en las instalaciones siguen siendo inaccesibles.
   • Causa: cloud_network_cidrs y peer_network_cidrs no coinciden exactamente con las subredes configuradas en el par remoto, por lo que el tráfico no se selecciona para el cifrado.
   • Solución: Alinee con precisión las CIDRs en ambos extremos. El lado de IONOS CLOUD debe listar su propia subred de LAN y la subred del par 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. Uso de un TTL no válido en un registro de DNS

   • Problema: La creación de un registro de DNS falla con un error de validación en el campo ttl.
   • Causa: El TTL se encuentra fuera del rango permitido de 60 a 604800 segundos (por ejemplo, un ttl = 30 heredado de otro proveedor).
   • Solución: Ajuste el TTL al rango admitido:

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

Resumen

Ahora puede construir una red segmentada y completa para una aplicación, totalmente como código. Las LAN le permiten un aislamiento por niveles, las NIC conectan los servidores a uno o más niveles con direccionamiento estático o DHCP, una pasarela NAT otorga acceso saliente controlado a los hosts privados, una pasarela IPSec crea un puente hacia redes en las instalaciones, y los registros DNS publican el punto de acceso, todo declarado en Terraform y reproducible bajo demanda. TaskBoard ahora tiene un nivel de entrada público, un nivel de aplicación privado y un nivel de base de datos aislado, con salida privada y un nombre de host de API resoluble.

La pila de red es el sustrato sobre el que el resto del Módulo 2 se construye. La Unidad 2.3 agrega equilibradores de carga y reglas de Network Security Group sobre estas LAN y NIC, y el Módulo 4 conecta el código de la aplicación con las bases de datos administradas que estarán en el nivel de base de datos que acaba de crear.

Puntos clave:

• Una ionoscloud_lan por nivel; public = true se conecta a la pasarela de internet, public = false aísla el nivel
• Un servidor se une a múltiples niveles teniendo múltiples recursos ionoscloud_nic, uno por LAN
• Las LAN privadas necesitan una ionoscloud_natgateway solo SNAT para el acceso saliente, y la ruta por defecto no se inyecta automáticamente
• IPSec VPN utiliza IKEv2 con una PSK y requiere selectores de tráfico exactamente coincidentes en ambos extremos
• Las zonas y registros DNS son recursos de Terraform con TTL limitados a 60 a 604800 segundos, servidos a través de una red Anycast

Terminología importante:

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

Próximos pasos

Siga 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: Terraform Provider y patrones principales