NAT Gateway: Da Salida a Internet a Servidores Privados con una IP Compartida

Un NAT Gateway permite que servidores sin IP pública lleguen igualmente a internet para actualizaciones, instalación de paquetes, llamadas a APIs y webhooks, todo a través de una única dirección pública compartida. Lo conectas a una red privada, y cada servidor de esa red puede salir a internet a través de él mientras permanece invisible desde fuera.

Es el patrón habitual para capas privadas de base de datos y de aplicación, máquinas de build/CI cerradas, y cualquier flota que quieras mantener fuera de internet sin cortarle el acceso de salida.

Cómo funciona (en un párrafo)

Creas un NAT Gateway sobre una red privada existente. Aprovisionamos una pequeña pasarela gestionada, le damos una IP pública IPv4 e IPv6 más una IP privada dentro de tu red, y añadimos automáticamente una ruta por defecto (0.0.0.0/0) en la red que apunta a esa IP privada. A partir de ahí, cualquier servidor cuyo tráfico siga esa ruta envía sus paquetes de salida a la pasarela, que reescribe el origen con su propia IP pública (source NAT) y los reenvía; las respuestas vuelven por el mismo camino. Muchos servidores privados comparten la única IP pública de la pasarela para su salida, y nada los alcanza desde internet salvo que lo configures aparte. Todo se gestiona en el panel o por la API.

Antes de empezar

• Primero necesitas una red privada existente. Si no tienes una, créala (consulta la guía de Redes Privadas); la pasarela se conecta a ella por network_id.
• En el panel: my.cubepath.com → NAT Gateway.
• Por la API: URL base https://api.cubepath.com, autentica con Authorization: Bearer <token> (scopes nat_gateway:read / nat_gateway:write) y añade X-Requested-With: XMLHttpRequest en las escrituras. Consigue un token en Cuenta → Tokens de API.
• Tu organización debe estar verificada, sin suspensión y con saldo positivo (un NAT Gateway es un recurso facturable).

Crear un NAT Gateway

Elige un plan y la red a la que servirá:

curl -X POST https://api.cubepath.com/nat-gateway/ \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "egress-nat",
    "label": "Salida de producción",
    "plan_name": "nat.small",
    "network_id": 42
  }'

Qué recibes y qué pasa a continuación:

• Se asignan una IP pública IPv4 y una IPv6 de la ubicación de la red. Ambas deben estar disponibles o la petición se rechaza limpiamente antes de crear nada.
• La pasarela reserva una IP privada dentro de la red (no puede ser .0, .1, ni la de broadcast).
• Se añade automáticamente una ruta por defecto 0.0.0.0/0 en la red, apuntando a la IP privada de la pasarela, para que tus servidores privados empiecen a usarla para salir.
• La pasarela arranca en deploying y pasa a active cuando termina el aprovisionamiento. Lista los planes primero con GET /nat-gateway/plans.

Hay un NAT Gateway por red privada. La pasarela vive en el mismo proyecto y ubicación que su red, inferidos automáticamente (o pasa project_id, que debe coincidir con el de la red).

Qué les hace esto a tus servidores

Una vez la pasarela está active, cualquier servidor conectado a esa red privada que siga la ruta por defecto llega a internet a través de ella y aparece ante los servicios remotos como la IP pública IPv4 de la pasarela. Ese es el objetivo: un servidor de base de datos solo-privado puede hacer apt update o llamar a una API de pagos sin tener nunca su propia IP pública.

La ruta por defecto está gestionada por nosotros. La verás en la lista de rutas de la red, pero no la puedes eliminar directamente; al eliminar el NAT Gateway se quita. Si necesitas un enrutado más específico (mandar solo ciertos CIDRs por la pasarela y dejar el resto local), añade tus propias rutas más concretas en la red junto a ella.

Planes y facturación

Cada plan define el rendimiento y la capacidad de la pasarela:

La facturación es por hora o mensual, según el tipo de facturación de tu proyecto, y se acumula desde que se crea la pasarela hasta que la eliminas. Consulta el gasto actual con el campo monthly_charges de la pasarela, y el tráfico con GET /nat-gateway/{uuid}/bandwidth-usage o las métricas en vivo GET /nat-gateway/{uuid}/metrics. Una pasarela también cuenta para tus límites combinados de recursos de VPS + Load Balancer + NAT Gateway (RAM, CPU, almacenamiento).

Lo que esto no hace

• No es un balanceador de carga. Da a los servidores una salida compartida; no reparte el tráfico entrante. Para tráfico entrante repartido entre servidores, usa un Load Balancer.
• Es NAT de salida, no port forwarding de entrada. Por defecto nada de internet puede abrir una conexión a tus servidores privados a través de él. Para exponer un servicio, ponle una IP pública o un Load Balancer directamente.
• Uno por red, una ubicación. Una pasarela sirve a una sola red privada en una sola ubicación. Cada red o ubicación distinta necesita la suya.

Referencia de la API

GET    /nat-gateway/plans                       Listar planes disponibles.             (scope: nat_gateway:read)
GET    /nat-gateway/                             Listar tus NAT Gateways.               (scope: nat_gateway:read)
GET    /nat-gateway/{uuid}                       Ver una pasarela (estado, IPs, gasto).  (scope: nat_gateway:read)
POST   /nat-gateway/        { name, plan_name, network_id }  Crear una pasarela.        (scope: nat_gateway:write)
PATCH  /nat-gateway/{uuid}  { name, label }      Renombrar una pasarela.                (scope: nat_gateway:write)
POST   /nat-gateway/{uuid}/resize  { plan_name } Cambiar de plan.                       (scope: nat_gateway:write)
POST   /nat-gateway/{uuid}/move-to-project  { project_id }  Mover a otro proyecto.      (scope: nat_gateway:write)
POST   /nat-gateway/{uuid}/protection  { enabled }  Activar/desactivar protección.      (scope: nat_gateway:write)
GET    /nat-gateway/{uuid}/metrics               Métricas de ancho de banda en vivo.    (scope: nat_gateway:read)
GET    /nat-gateway/{uuid}/bandwidth-usage       Tráfico del mes en curso.              (scope: nat_gateway:read)
DELETE /nat-gateway/{uuid}                       Eliminar (libera IPs, quita la ruta).   (scope: nat_gateway:write)

Todas las peticiones se autentican con Authorization: Bearer <token> (o X-API-Key). Las peticiones de escritura necesitan además X-Requested-With: XMLHttpRequest.