← Volver a Docs
Requisitos de Red y Sistema
Lo que necesitan tu red y dispositivos para ejecutar WireZTNA.
Requisitos de Red
Publisher → Broker
El publisher inicia todas las conexiones hacia el broker. No es necesario abrir puertos de entrada en el firewall del cliente.
| Dirección | Protocolo | Puerto | Propósito |
|---|---|---|---|
| Salida | UDP | 51820–51830 | Túnel WireGuard al broker |
| Salida | TCP | 443 | Comunicación API (enrollment, heartbeat) |
Punto clave: El publisher solo necesita acceso de salida. Sin reglas de firewall de entrada, sin reenvío de puertos, sin IP pública necesaria. Funciona detrás de NAT, firewalls corporativos y CGNAT.
Cliente → Broker
| Dirección | Protocolo | Puerto | Propósito |
|---|---|---|---|
| Salida | UDP | 51820 | Túnel WireGuard |
| Salida | TCP | 443 | API (login, renovación de sesión, enrollment) |
Los clientes también solo necesitan acceso de salida. El túnel usa UDP pero funciona a través de la mayoría de firewalls corporativos al ser iniciado de forma saliente.
Consideraciones de Firewall
- El UDP no debe estar bloqueado: Algunos firewalls corporativos bloquean UDP de salida. Si es así, WireGuard no puede establecer el túnel. Verifica con:
nc -uzv broker-host 51820 - Inspección Profunda de Paquetes (DPI): WireGuard usa un protocolo propio que algunos motores DPI no reconocen. Si tu cliente está detrás de Netskope, Zscaler o similar — añade la IP del broker a la lista de bypass.
- MTU: WireGuard añade ~60 bytes de overhead. El MTU por defecto de 1420 funciona en la mayoría de entornos. Si ves timeouts en HTTPS pero los pings funcionan, reduce el MTU a 1280.
Requisitos del Publisher
Sistema Operativo
| SO | Versión Mínima | Notas |
|---|---|---|
| Ubuntu | 20.04 LTS | Kernel 5.6+ (WireGuard integrado) |
| Debian | 11 (Bullseye) | Kernel 5.10+ |
| Amazon Linux | 2023 | Requiere modprobe wireguard |
| RHEL / Rocky / Alma | 8.4+ | Kernel 4.18 con módulo WG backported |
| Cualquier Linux | Kernel ≥ 5.6 | WireGuard integrado en el kernel desde 5.6 |
Hardware
| Recurso | Mínimo | Recomendado |
|---|---|---|
| CPU | 1 core (cualquier arquitectura) | 1 core |
| RAM | 64 MB | 128 MB |
| Disco | 20 MB | 50 MB |
| Red | Cualquiera (funciona con 1 Mbps+) | Según necesidades de throughput |
El publisher es un binario estático de 8 MB sin dependencias de runtime. Funciona en todo, desde una Raspberry Pi hasta una VM en la nube.
Arquitecturas Soportadas
linux/amd64— Intel/AMD 64-bit (la mayoría de servidores y VMs)linux/arm64— ARM 64-bit (Raspberry Pi 4+, AWS Graviton, Azure Ampere)
Permisos
- Acceso root (o
CAP_NET_ADMIN+CAP_NET_RAW) para la creación de la interfaz WireGuard - El comando
iptablesdebe estar disponible (para masquerade NAT) - IP forwarding activado (
net.ipv4.ip_forward = 1— el instalador lo configura automáticamente)
Requisitos del Cliente
Plataformas Soportadas
| Plataforma | Versión Mínima | Método de Túnel | Split DNS |
|---|---|---|---|
| macOS | 12 (Monterey) | wireguard-go (userspace) | /etc/resolver/ |
| Windows | 10 (1809+) | wintun (incluido en el MSI) | Reglas NRPT |
| Linux | Kernel 5.6+ (o wireguard-go) | Módulo WireGuard del kernel | systemd-resolved |
| Android | 10+ | VpnService + wireguard-android | VpnService.Builder |
| iOS | 15+ | NetworkExtension + WireGuardKit | NEDNSSettings |
Dependencias del Cliente
| Plataforma | Qué se necesita |
|---|---|
| macOS | brew install wireguard-go wireguard-tools |
| Windows | Nada — el instalador MSI incluye todo (wintun embebido) |
| Linux (kernel 5.6+) | Nada — el módulo WireGuard del kernel está integrado |
| Linux (kernels antiguos) | wireguard-go (fallback en userspace) |
Requisitos de Privilegios
| Plataforma | Por defecto | Opción sin root |
|---|---|---|
| macOS | sudo | Helper con privilegios (futuro) |
| Windows | Administrador (prompt UAC) | Añadir usuario al grupo Network Configuration Operators |
| Linux | sudo | setcap 'cap_net_admin+ep cap_net_raw+ep' en el binario |
Requisitos de DNS
Para que el split DNS funcione (resolver zonas internas a través del túnel), el publisher necesita:
- Un servidor DNS en la red privada que resuelva las zonas internas (ej.,
10.50.1.2:53para*.internal.empresa.com) - La IP de ese servidor DNS debe estar dentro de los CIDRs expuestos del publisher (o explícitamente añadida a los AllowedIPs de WireGuard — el reconciler lo gestiona automáticamente)
El cliente no necesita ninguna configuración DNS — el cliente WireZTNA configura el split DNS automáticamente al conectar.
Ancho de Banda y Latencia
- Throughput: La criptografía de WireGuard funciona a velocidad de línea en CPUs modernas (~1 Gbps en un solo core con AES-NI/NEON)
- Overhead: ~60 bytes por paquete (cabecera WireGuard + UDP + IP). Insignificante para la mayoría de cargas de trabajo.
- Latencia: Añade un round-trip al broker por paquete (cliente → broker → publisher). Mantén el broker geográficamente cerca de tus usuarios/publishers para una latencia óptima.
- Keepalive: WireGuard envía un keepalive de 32 bytes cada 25 segundos para mantener los mapeos NAT. Impacto en ancho de banda: ~1 KB/min por túnel.
Checklist Rápido
☐
El publisher puede alcanzar el broker en UDP 51820 (salida)
☐
El publisher puede alcanzar el broker en TCP 443 (salida, HTTPS)
☐
El host del publisher tiene Linux kernel 5.6+ (o módulo WireGuard cargado)
☐
El host del publisher tiene acceso root e iptables disponible
☐
El cliente puede alcanzar el broker en UDP 51820 (salida)
☐
El cliente puede alcanzar el broker en TCP 443 (salida)
☐
Ningún DPI/proxy bloquea UDP de salida en la red del cliente