Redes Privadas (VPC) y Rutas: Conecta tus Servidores en Privado

Una Red Privada da a tus servidores una red aislada de capa 3 por la que comunicarse con IPs internas, sin que el tráfico salga de CubePath ni quede expuesto a internet. Añade Rutas encima y controlas a dónde va el tráfico de cualquier CIDR: a través de un VPS firewall, un NAT Gateway, o un appliance de enrutado que gestiones tú.

Es el bloque básico para apps multicapa (web delante, base de datos en una subred privada), clústeres privados, salida por NAT, y cualquier montaje donde los servidores deban verse entre sí sin IPs públicas.

Cómo funciona (en un párrafo)

Creas una red privada dentro de un proyecto, en una ubicación, con un CIDR privado que eliges tú (por ejemplo 10.0.0.0/24). Los servidores de ese mismo proyecto y ubicación se pueden conectar a ella; cada uno recibe una IP interna del rango y alcanza a los demás directamente, con .1 reservado como gateway. Por defecto una red privada solo transporta el tráfico de su propio CIDR. Cuando necesitas que el tráfico hacia otros destinos pase por una máquina concreta (un firewall, un NAT Gateway, un túnel a tu oficina), añades una Ruta: un CIDR de destino más un siguiente salto, que es o bien una IP dentro de la red o bien uno de tus servidores. Todo se gestiona en el panel o por la API; no se instala nada a mano.

Antes de empezar

• En el panel: my.cubepath.com → Redes (las redes viven dentro de un proyecto).
• Por la API: URL base https://api.cubepath.com, autentica con Authorization: Bearer <token> (scopes network:read / network:write, y vps:write para conectar un servidor) y añade X-Requested-With: XMLHttpRequest en las escrituras. Consigue un token en Cuenta → Tokens de API.

Parte 1: Crear una red privada

Una red pertenece a un proyecto y una ubicación, y tiene un CIDR privado formado por un ip_range (la dirección de red) y un prefix.

curl -X POST https://api.cubepath.com/networks/create_network \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "backend-net",
    "label": "Backend Network",
    "location_name": "us-mia-1",
    "ip_range": "10.0.0.0",
    "prefix": 24
  }'

Reglas a tener en cuenta:

• El nombre tiene de 3 a 64 caracteres.
• El prefijo está entre /8 y /24.
• ip_range debe ser la dirección de red real para ese prefijo (para un /24, 10.0.0.0 es válido, 10.0.0.5 no). Usa un rango privado (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
• Puedes tener hasta 3 redes por organización.

Dentro del rango, .1 es el gateway y está reservado, junto con la dirección de red (.0) y la de broadcast. El resto es asignable a servidores.

Puedes renombrar una red (PUT /networks/{id}, solo nombre y label) o moverla a otro proyecto de la misma organización (POST /networks/{id}/move-project).

Conectar servidores

Un servidor se une a la red desde el lado del servidor. Debe estar en el mismo proyecto y ubicación que la red, y estar activo o parado.

curl -X POST https://api.cubepath.com/vps/<vps_id>/network \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{ "network_id": 42 }'

El servidor recibe la siguiente IP interna libre del rango. Reinícialo para que el cambio surta efecto. Los servidores bare metal se conectan igual. Para quitarlo, DELETE /vps/<vps_id>/network (también requiere reinicio).

Parte 2: Rutas

Por defecto una red solo sabe alcanzar su propio CIDR. Una ruta le dice que envíe el tráfico de otro destino a través de un siguiente salto que tú eliges.

Una ruta tiene tres partes:

Ejemplos

Enviar todo el tráfico de salida a través de un VPS firewall/NAT de la red:

curl -X POST https://api.cubepath.com/networks/42/routes \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{ "destination": "0.0.0.0/0", "next_hop_type": "vps", "next_hop_target": "123", "description": "Salida por firewall" }'

Enrutar una subred remota a través de la IP interna de un appliance:

curl -X POST https://api.cubepath.com/networks/42/routes \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{ "destination": "192.168.50.0/24", "next_hop_type": "ip", "next_hop_target": "10.0.0.5" }'

Lista las rutas con GET /networks/42/routes (cada una muestra su resolved_next_hop_ip), y elimina una con DELETE /networks/42/routes/{route_id}.

Qué se permite

• El destino no puede ser el propio CIDR de la red (eso ya es una ruta conectada) ni caer dentro de un rango reservado (loopback, link-local, multicast). Un supernet como 0.0.0.0/0 sí vale.
• Un siguiente salto de tipo ip debe estar dentro del CIDR de la red, y no puede ser la dirección de red (.0), la de broadcast, ni el gateway (.1).
• Un siguiente salto vps / baremetal debe estar en el mismo proyecto, en un estado utilizable, y ya conectado a esta red. Si no, es inalcanzable y la ruta se rechaza.
• Las familias de direcciones deben coincidir (un destino IPv4 necesita un siguiente salto IPv4).
• Hasta 30 rutas por red. El mismo destination puede tener varios siguientes saltos (se tratan como rutas de igual coste); solo se rechaza un duplicado exacto de destino + tipo + target.

Las rutas que crea automáticamente un NAT Gateway se gestionan solas y no se pueden eliminar directamente. Elimina el NAT Gateway y sus rutas se limpian con él.

Límites

Lo que esto no hace

• No es una red pública. Las IPs privadas solo son alcanzables por tus servidores conectados en la misma ubicación, no desde internet. Para salir a internet desde un servidor solo-privado, enruta a través de un NAT Gateway.
• No abarca varias ubicaciones. Una red vive en una ubicación; los servidores de otra ubicación no pueden unirse. Conecta ubicaciones con un appliance de enrutado y rutas.
• Las rutas no reconfiguran el firewall de tu servidor. Dirigen a dónde envía el tráfico la red; la máquina del siguiente salto todavía tiene que estar configurada para reenviar, hacer NAT o filtrar como tú quieras.

Solución de problemas

Referencia de la API

POST   /networks/create_network            { name, location_name, ip_range, prefix }  Crear una red. (scope: network:write)
PUT    /networks/{id}                       { name, label }                            Renombrar una red. (scope: network:write)
POST   /networks/{id}/move-project          { project_id }                             Mover a otro proyecto. (scope: network:write)
DELETE /networks/{id}                                                                  Eliminar una red. (scope: network:write)
GET    /networks/{id}/routes                                                           Listar rutas. (scope: network:read)
POST   /networks/{id}/routes                { destination, next_hop_type, next_hop_target }  Añadir una ruta. (scope: network:write)
DELETE /networks/{id}/routes/{route_id}                                                Eliminar una ruta. (scope: network:write)
POST   /vps/{vps_id}/network                { network_id }                             Conectar un servidor. (scope: vps:write)
DELETE /vps/{vps_id}/network                                                           Desconectar un servidor. (scope: vps: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.