CGNAT en sedes y teletrabajo: paso a paso sin IP pública
Conectar sedes y teletrabajadores bajo CGNAT es viable sin contratar direcciones IP públicas fijas ni abrir puertos en el cortafuegos. Una red en malla basada en WireGuard negocia enlaces directos mediante STUN y utiliza un repetidor TCP cifrado como alternativa automática cuando ambos extremos carecen de direccionamiento enrutable.
El problema de comunicar extremos sin direccionamiento público
Los operadores de fibra y telefonía móvil asignan habitualmente a oficinas y hogares direcciones dentro de CGNAT o NAT simétrico, lo que impide que un router reciba paquetes entrantes no solicitados. En una arquitectura tradicional, establecer una conexión exige que al menos una sede disponga de una dirección IPv4 pública estática y reglas de reenvío de puertos configuradas en su cortafuegos perimetral.
Cuando ninguna de las dos ubicaciones cuenta con IP pública, los túneles VPN clásicos no pueden iniciar el saludo de enlace de forma bidireccional. Esta limitación obliga frecuentemente a depender de concentradores centrales costosos o a publicar servicios internos hacia Internet, incrementando la superficie de exposición ante análisis de puertos no autorizados, como se analiza al comparar una red en malla privada frente a VPN tradicionales.
Negociación STUN y retransmisión sobre el puerto TCP 4430
STUN opera en el plano de control mediante UDP 3478 para que cada nodo descubra su dirección pública aparente y perfore el cortafuegos local hacia su par. Si la perforación de puertos (hole punching) tiene éxito, el tráfico viaja de extremo a extremo sin intermediarios a través de túneles WireGuard, donde cada dispositivo mantiene su propio par de claves criptográficas y no intervienen nombres de usuario ni contraseñas en la ruta de datos. WireGuard es una marca registrada de Jason A. Donenfeld.
Cuando ambos extremos se sitúan tras un CGNAT estricto o un NAT simétrico que altera los puertos salientes de forma impredecible, la ruta directa falla. En ese escenario, el tráfico se redirige a un servidor de retransmisión en TCP 4430. Este componente conmuta los paquetes entre pares sin descifrar su contenido, requiriendo aproximadamente 23 ns por trama con independencia del volumen de clientes concurrentes.
Cada dispositivo integrado en la malla recibe una dirección fija dentro del rango 100.64.0.0/10, reservado según RFC 6598 para servicios compartidos. Este espacio evita colisiones con redes locales que empleen 192.168.x.x o 10.x.x.x, simplificando el acceso tanto a equipos individuales como al gestionar servidores de clientes sin abrir puertos.
Comparativa de rutas de red para oficinas y teletrabajo tras CGNAT
| Mecanismo de transporte | Apertura en el cortafuegos | Cifrado del tráfico | Consumo típico por hora |
|---|---|---|---|
| Enlace directo (STUN) | Ninguna requerida | WireGuard de extremo a extremo | Sin límite de transferencia |
| Retransmisión relay (TCP 4430) | Solo salida hacia TCP 4430 | Opaco para el relay | SSH < 1 MB; RDP 0,5 a 1 GB |
| Subred local anunciada | Ninguna en router periférico | Encapsulado en nodo Linux | Varía según servicios LAN |
Despliegue del plano de control en infraestructura propia
El paquete autoalojado de prialo consta de tres contenedores gestionados mediante Docker Compose: el servidor de coordinación (gRPC en TCP 50051 y STUN en UDP 3478), el repetidor de tráfico en TCP 4430 y una base de datos PostgreSQL. Para cientos de nodos son suficientes 2 vCPU y 2 GB de memoria RAM en sistemas Linux x86_64 o arm64 que ejecuten Docker Engine 24 o posterior con Compose v2. El software se obtiene descargándolo desde la sección de servidor autoalojado para Linux.
La API administrativa en el puerto 8080 nunca se expone a Internet; el acceso al panel se realiza a través de un túnel SSH. La confianza del plano de control se fundamenta en un anclaje SPKI (sha256:...) configurado en los clientes, prescindiendo de autoridades de certificación externas. La empresa Sinergia, radicada en Barcelona, no almacena ni tiene acceso a las claves criptográficas ni a la base de datos de las instancias autoalojadas.
Instalación del cliente y publicación de subredes paso a paso
- Instalación inicial: ejecute el comando de enrolamiento en el nodo terminal Linux o macOS con privilegios administrativos para establecer el anclaje criptográfico.
- Verificación de estado: confirme con
prialo statusque la conexión refleja el estado 'Control: tls, pinned' y una IP fija asignada dentro de 100.64.0.0/10. - Comprobación de pares: utilice
prialo peersyprialo ping <host-or-ip>para evaluar si la conexión con la sede remota es directa o retransmitida. - Anuncio de subred remota: publique la LAN interna de una sede ejecutando
prialo up --advertise-routes=192.168.50.0/24desde un nodo con sistema operativo Linux. - Aprobación administrativa: autorice la ruta desde la gestión central mediante
prialo node routes <router> --approve 192.168.50.0/24para habilitar el enrutamiento. - Aceptación en clientes: aplique el parámetro
--accept-routesen los equipos cliente que requieran acceder a la subred aprobada.
sudo PRIALO_AUTH_KEY='<enrolment key>' prialo install --server=control.example.com:50051 --relay=control.example.com:4430 --tls-pin=sha256:<fingerprint>Únicamente las máquinas Linux pueden actuar como encaminadores de subred. Los clientes para Windows y teléfonos móviles no permiten aceptar rutas de subred actualmente. A fecha 17 de octubre de 2026, las aplicaciones para Mac e iPhone se encuentran en proceso de revisión por Apple y no están disponibles para descarga; la compilación para Windows se ofrece en fase preliminar sin instalador ni firma digital, mientras que la versión para Android continúa en preparación.
Respecto al marco regulatorio, normativas como la Directiva NIS2 (Directiva UE 2022/2555), el RGPD (Reglamento UE 2016/679) o el Esquema Nacional de Seguridad español (Real Decreto 311/2022) demandan un riguroso control sobre los accesos administrativos. prialo no posee certificaciones bajo estos estándares; su aportación consiste en asegurar que las claves, los identificadores y el registro de auditoría permanezcan alojados exclusivamente en la infraestructura bajo control del cliente.
Preguntas frecuentes
¿Cómo atraviesa la red el CGNAT cuando ambos extremos carecen de IP pública?
El sistema intenta primero perforar el cortafuegos mediante STUN en UDP 3478 para establecer un túnel WireGuard directo. Si la topología de red bloquea el tráfico punto a punto, los paquetes cifrados se derivan automáticamente a un repetidor en TCP 4430, que los entrega sin descifrar su contenido.
¿Qué ocurre si una sede supera el límite mensual de tráfico retransmitido?
Cuando se define la variable PRIALO_MESH_QUOTA_BYTES y una malla sobrepasa la cuota establecida, el servidor de retransmisión descarta las tramas excedentes y registra el contador, pero en ningún momento desconecta los dispositivos ni interrumpe la sincronización del plano de control.
¿Puede un equipo con Windows actuar como pasarela para una subred local?
No, únicamente los nodos con sistema operativo Linux pueden anunciar y enrutar subredes locales hacia la malla. Además, las versiones preliminares para Windows y los dispositivos móviles todavía no admiten la opción de aceptar rutas hacia subredes remotas.
¿Qué recursos requiere el servidor de coordinación en modalidad autoalojada?
El entorno autoalojado requiere 2 vCPU y 2 GB de memoria RAM en sistemas Linux x86_64 o arm64 con Docker Engine 24 o posterior y Compose v2. Esta configuración sustenta tres contenedores (coordinación, retransmisión y PostgreSQL) para cientos de nodos.
¿Prefieres tu propio servidor? Guía del paquete autoalojado de prialo