Arquitectura

Visión General

WireZTNA consta de tres componentes principales conectados mediante túneles WireGuard:

┌─────────┐       WireGuard        ┌──────────┐      WireGuard      ┌───────────┐
│  Cliente │◄─────(overlay)────────►│  Broker  │◄────(per-pub ns)───►│ Publisher │
│10.200.x.x│     sesión PSK        │10.200.0.1│                     │ acceso LAN│
└─────────┘                        └──────────┘                     └───────────┘
                                        │
                                   Plano de Control
                                   (API + Web UI)
                                   Políticas · DNS · Flujos

Modelo de Acceso

WireZTNA utiliza un modelo de permisos jerárquico:

Usuario ──(miembro de)──► Grupo ──(acceso a)──► Publisher ──(expone)──► CIDRs + Apps
                                                                    │
                                                                    ├─ exposed_cidrs: ["10.50.0.0/16"]
                                                                    ├─ published_apps: [{target, port, protocol}]
                                                                    └─ dns_zones: ["internal.empresa.com"]

• Un usuario solo puede alcanzar los CIDRs/apps de los publishers asignados a sus grupos
• El acceso se aplica a nivel de kernel (nftables) — no solo a nivel de aplicación
• Las apps publicadas permiten reglas por puerto (ej., solo TCP 5432 a una base de datos)
• Las zonas DNS permiten split DNS — los nombres internos solo se resuelven a través del túnel

Flujo de Tráfico

Cuando un cliente envía un paquete a un recurso privado (ej., 10.50.1.100:5432):

1. Cliente → Broker: El paquete entra en el túnel WireGuard (interfaz wg-clients en el broker). La IP de origen es la dirección overlay del cliente (10.200.x.x).
2. nftables mangle: El broker compara la IP origen y el CIDR destino contra las políticas. Marca el paquete con el fwmark del publisher correcto.
3. Policy routing: El enrutamiento por políticas de Linux (ip rule fwmark N → table 10N) envía el paquete marcado al par veth correcto.
4. Network namespace: El paquete entra en el namespace de red aislado del publisher a través del puente veth.
5. Broker → Publisher: Dentro del namespace, un túnel WireGuard dedicado reenvía el paquete al publisher.
6. Publisher → LAN: El publisher entrega el paquete al destino real en la red privada.
7. Camino de vuelta: La respuesta sigue el mismo camino en reverso (rastreado por conntrack).

Internos del Broker

Network Namespaces

Cada publisher tiene un namespace de red Linux aislado en el broker. Esto proporciona:

• Aislamiento: Los publishers no pueden ver el tráfico de los demás
• Enrutamiento independiente: Cada namespace tiene su propia tabla de rutas e interfaz WireGuard
• Seguridad: Un túnel de publisher comprometido no puede afectar a otros publishers

Host namespace (broker)
├── wg-clients          (todos los peers clientes, overlay 10.200.0.0/16)
├── veth-pub1-host ◄──► veth-pub1-ns   (namespace: ns-publisher1)
│                           └── wg-pub1 (túnel a publisher-1)
├── veth-pub2-host ◄──► veth-pub2-ns   (namespace: ns-publisher2)
│                           └── wg-pub2 (túnel a publisher-2)
└── nftables inet wireztna
    ├── mangle: marcar paquetes según mapeo cliente→publisher
    └── forward: permitir/denegar según marca + destino

Bucle de Reconciliación

El agente del broker ejecuta un bucle de reconciliación cada 10–15 segundos:

1. Obtiene el estado deseado de la API del Plano de Control (usuarios, grupos, publishers, sesiones)
2. Compara con el estado actual del kernel (peers WG, reglas nftables, namespaces)
3. Converge: añade/elimina peers, actualiza reglas de firewall, crea/destruye namespaces

Esto significa que los cambios en el panel de administración (nuevo usuario, cambio de grupo, toggle de publisher) se aplican en 10–15 segundos automáticamente.

Gestión de Sesiones y PSK

Cada sesión de cliente tiene una clave pre-compartida (PSK) WireGuard efímera:

• Se genera en la creación de sesión (login o renovación)
• Se aplica al peer WG del cliente en el broker
• Expira después de un TTL configurable (por defecto 8 horas)
• Al expirar, el handshake WG falla → el cliente debe renovar
• Proporciona forward secrecy: incluso si una clave a largo plazo se compromete, las sesiones pasadas permanecen seguras

Split DNS

WireZTNA incluye un proxy DNS por cliente ejecutándose en la IP overlay del broker (10.200.0.1:53):

• Cada cliente solo resuelve zonas asignadas a sus publishers accesibles
• Las consultas para zonas internas (ej., *.internal.empresa.com) se reenvían a través del namespace del publisher al servidor DNS privado del cliente
• Todas las demás consultas DNS usan el resolver normal del sistema (split DNS)
• DNS routing hints: cuando un nombre se resuelve a través de un publisher específico, una regla nftables /32 asegura que el tráfico a esa IP vaya por el publisher correcto

Fronteras de Seguridad

Un paquete no autorizado (cliente incorrecto, destino incorrecto, sesión expirada) se descarta a nivel de kernel antes de que llegue al espacio de usuario o al túnel del publisher.

Sin Punto Único de Descifrado

El broker enruta paquetes WireGuard cifrados entre peers — no termina ni descifra payloads de tráfico. El broker solo tiene claves públicas y metadatos de sesión. Las claves privadas se generan en el dispositivo y nunca salen del cliente o publisher.

Para un análisis más profundo de nuestra pila criptográfica, consulta la página de Seguridad.