---
title: "Redes Privadas"
description: "Crea una red privada aislada (VPC), conecta servidores y dirige el tráfico con rutas a través de un firewall, un NAT Gateway o un appliance."
category: "Despliegue"
language: es
source: https://cubepath.com/es/docs/products/despliegue/redes-privadas
updated: 2026-10-28
---

# Redes Privadas

Una red privada (VPC) da a tus servidores una **red aislada** por la que hablan con IPs internas, sin nada expuesto a internet público. Añade **rutas** encima y controlas hacia dónde va el tráfico de cualquier destino: a través de un VPS firewall, un NAT Gateway o un appliance que gestiones tú.

![Cómo funcionan las redes privadas: VLAN aislada, IPs privadas, rutas y NAT Gateway](https://cdn.cubepath.com/img/docs/products/0d7dca33-5c67-4c2a-8e70-002feaf7e119.png)

Es el bloque básico para aplicaciones multicapa (web delante, base de datos en una subred privada), clústeres privados, salida por NAT y cualquier caso en el que los servidores deban alcanzarse sin IPs públicas.

## Crear una red

```steps
### Abre el asistente de creación
En la página **Private Networks** de [my.cubepath.com](https://my.cubepath.com), pulsa **Create Network**.

### Define nombre, ubicación y rango
Introduce un **nombre** (3–64 caracteres), elige una **ubicación** y define el **rango de IPs** como CIDR, p. ej. `10.0.0.0/24`.

![Formulario Create Network con nombre, ubicación y rango de IPs](https://cdn.cubepath.com/img/docs/products/424440c2-4c38-4e9b-ae84-f5fe58346b17.png)

### Crea
Confirma. La red es regional: solo pueden unirse máquinas de la misma ubicación y proyecto.
```

### Reglas del rango

| Regla | Detalle |
|-------|---------|
| **Prefijo** | Entre `/8` y `/24` |
| **Rango** | Debe ser un rango **privado**: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16` |
| **Dirección** | Debe ser la dirección de red real del prefijo — `10.0.0.0` vale para un `/24`, `10.0.0.5` no |
| **Reservadas** | `.0` (red), `.1` (gateway) y la de broadcast. El resto es asignable |
| **Límite** | Hasta **3 redes por organización** |

> Consejo: Elige un rango que no choque con nada que vayas a necesitar alcanzar: la LAN de tu oficina, la VPC de otro proveedor o el CIDR de pods de [Kubernetes](/docs/products/despliegue/desplegar-un-cluster-de-kubernetes). Los solapamientos no se rechazan al crear; aparecen después como tráfico que se va en silencio al sitio equivocado.

## Conectar servidores

Abre la pestaña Network de la máquina ([VPS](/docs/products/despliegue/vps-red) o [baremetal](/docs/products/despliegue/bm-red)) y pulsa **Attach**. El servidor toma la siguiente IP interna libre del rango.

- El servidor debe estar en el **mismo proyecto y ubicación** que la red, y estar **activo o parado**.
- **Un VPS debe reiniciarse** para que el cambio surta efecto. En baremetal la configuración del switch se aplica en segundo plano, pero aun así tienes que configurar la VLAN dentro del SO.

> Nota: "Están conectados pero no se ven" es casi siempre un VPS que no se ha reiniciado desde que se conectó.

## Rutas

Por defecto una red solo sabe llegar a su propio CIDR. Una **ruta** le dice que envíe el tráfico de otro destino a través de un next hop que tú elijas.

| Campo | Significado |
|-------|-------------|
| **Destino** | El CIDR objetivo, p. ej. `0.0.0.0/0` (todo) o `192.168.50.0/24` |
| **Tipo de next hop** | Una IP, un VPS o un servidor baremetal |
| **Next hop** | Una dirección dentro de la red, o el propio servidor |

Usos típicos: enviar todo el tráfico saliente por un VPS firewall, o enrutar una subred remota a través de la IP interna de un appliance.

### Qué está permitido

- El destino **no puede ser el propio CIDR de la red** (ya está conectado) ni caer en un rango reservado (loopback, link-local, multicast). Una supernet como `0.0.0.0/0` sí vale.
- Un **next hop de tipo IP debe estar dentro del CIDR de la red**, y no puede ser `.0`, `.1` ni la de broadcast.
- Un **next hop de tipo servidor debe estar en el mismo proyecto 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 next hop IPv4.
- Hasta **30 rutas por red**. Un mismo destino puede tener varios next hops (se tratan como caminos de igual coste); solo se rechaza un duplicado exacto.

> Importante: Las rutas creadas automáticamente por un [NAT Gateway](/docs/products/despliegue/desplegar-un-nat-gateway) están gestionadas por nosotros y no se pueden borrar directamente. Elimina el gateway y su ruta se va con él.

> Aviso: Una ruta dirige hacia dónde envía el tráfico la *red*. No configura el servidor next hop. Esa máquina sigue teniendo que estar preparada para reenviar, hacer NAT o filtrar como pretendes — activar el reenvío de IP es el paso que se suele olvidar.

## Qué no hace

- **No es una red pública.** A las IPs privadas solo llegan tus servidores conectados de la misma ubicación. Para salir a internet desde un servidor solo privado, enruta a través de un [NAT Gateway](/docs/products/despliegue/desplegar-un-nat-gateway).
- **No abarca varias ubicaciones.** Una red vive en una ubicación. Conecta ubicaciones con un appliance de routing y rutas.

## Diagnóstico

| Síntoma | Causa probable |
|---------|----------------|
| "Rango inválido" al crear | El rango no es la dirección de red de ese prefijo |
| "Límite alcanzado" al crear | Ya tienes 3 redes |
| No se puede conectar un servidor | Está en otro proyecto o ubicación, o no está activo/parado |
| Conectados pero sin conectividad | Uno o ambos VPS no se han reiniciado desde que se conectaron |
| Ruta rechazada, next hop fuera del CIDR | Un next hop de tipo IP debe ser una dirección de la red, y no `.0`/`.1`/broadcast |
| Ruta rechazada, "debe estar conectado" | El servidor destino aún no está en esta red |
| No se puede borrar la red | Sigue conectado un VPS, un baremetal o un NAT Gateway |