Problema
En muchos homelabs la tentación de añadir varios dispositivos (NAS, servidores, Raspberry Pi, APs) lleva a una red plana donde todos los equipos comparten el mismo broadcast. Esa arquitectura simplifica la configuración inicial, pero rápidamente se vuelve un riesgo: dispositivos IoT pueden comprometerse y, sin aislamiento, pueden atacar máquinas de gestión o servidores críticos. El patrón recurrente es la necesidad de segmentar la red en zonas lógicas (trusted, internal, iot, guest, servers) y, al mismo tiempo, ofrecer a los usuarios finales una forma sencilla de acceder a servicios internos mediante nombres de dominio amigables y certificados válidos. Cuando la segmentación se combina con un proxy inverso como Nginx Proxy Manager (NPM) y una autoridad de certificación externa (Let’s Encrypt vía DNS‑01), la complejidad de la configuración aumenta y los errores de enrutamiento, firewall o resolución DNS son comunes.
Causa
Los fallos habituales se originan en tres áreas:
-
VLAN mal etiquetadas o inconsistentes
- Los switches POE pueden estar configurados con un ID de VLAN diferente al que usa el UDR.
- Los APs transmiten SSID con etiquetas que no coinciden con la subred esperada, provocando que dispositivos terminen en la zona equivocada.
-
Políticas de firewall que bloquean tráfico esencial
- En Unifi, las reglas de zona a zona se definen en la política de red. Un “Block All” demasiado amplio impide que el NPM responda a peticiones de DNS interno o que los clientes de una zona accedan al servidor de gestión.
-
Resolución DNS interna que no apunta al proxy
- Si el motor de políticas de Unifi no está configurado para sobrescribir la resolución de
*.internal.redactedcon la IP del NPM, los clientes intentarán contactar directamente al backend (TrueNAS, Proxmox) y chocarán con los firewalls de zona.
- Si el motor de políticas de Unifi no está configurado para sobrescribir la resolución de
Estos problemas aparecen de forma intermitente, especialmente cuando se añaden nuevos dispositivos o se cambian los rangos de subred. La falta de una base reproducible (por ejemplo, Ansible) hace que la solución sea manual y propensa a errores.
Solución
Una arquitectura reproducible se basa en tres pilares: definición clara de VLAN, políticas de firewall basadas en zonas y DNS interno redirigido al proxy. A continuación se describen los pasos genéricos que pueden adaptarse a cualquier homelab con hardware Unifi y servicios similares.
1. Definir la tabla de VLAN y subredes
| Zona | VLAN | Subred | Gateway |
|---|---|---|---|
| TRUSTED | 10 | 192.168.10.0/24 | .1 |
| INTERNAL | 20 | 192.168.20.0/24 | .1 |
| IOT | 30 | 192.168.30.0/24 | .1 |
| GUEST | 40 | 192.168.40.0/24 | .1 |
| SERVERS | 50 | 192.168.50.0/24 | .1 |
En el Unifi UDR crea cada red como “Network → Create New Network”, asigna el ID de VLAN correspondiente y habilita DHCP con el gateway indicado. En los switches POE, bajo “Port Profile → VLAN”, asigna el mismo ID a los puertos que conectan los servidores y a los uplinks de los APs.
2. Configurar SSID con mapeo de VLAN
En el “Wireless Network” de cada AP, especifica:
Wifi‑TRUSTED→ VLAN 10Wifi‑INTERNAL→ VLAN 20Wifi‑IOT→ VLAN 30Wifi‑GUEST→ VLAN 40
Asegúrate de que la opción “Apply Guest Policies” esté desactivada para los SSID que no son guest, de modo que la política de zona sea la misma que la del cableado.
3. Crear políticas de zona a zona
En Settings → Routing & Firewall → Firewall → Rules, crea reglas de la siguiente forma (orden de mayor a menor prioridad):
| Origen | Destino | Acción | Comentario |
|---|---|---|---|
| SERVERS | TRUSTED | Allow | Acceso a consola |
| SERVERS | INTERNAL | Return | Permite tráfico iniciado desde INTERNAL |
| INTERNAL | SERVERS | Return | Respuesta a solicitudes a SERVERS |
| TRUSTED | * | Allow | Acceso total a gestión |
| INTERNAL | * | Block | Aislamiento estándar |
| IOT | * | Block | Sin movimiento lateral |
| GUEST | * | Block | Sólo puertos expuestos |
El uso de “Return” evita crear reglas explícitas para cada puerto; el firewall devolverá el tráfico que ya haya sido permitido por la regla inversa.
4. Redirigir DNS interno al NPM
En Settings → Services → DNS, habilita “Custom DNS” y añade una entrada de “Domain Override”:
- Domain:
*.internal.redacted - IP:
192.168.50.14(IP del NPM)
Esto obliga a cualquier cliente que solicite something.internal.redacted a recibir la IP del NPM, independientemente de la zona de origen. El NPM, a su vez, tiene los “Host” configurados para redirigir a los contenedores o VM correspondientes (Immich, Jellyfin, Proxmox).
5. Automatizar certificados con Certbot + Cloudflare DNS‑01
Instala Certbot en el host del NPM (Docker o VM) y crea un script que:
- Solicite/renueve certificados para
*.internal.redacted. - Use el plugin
certbot-dns-cloudflarecon la API token de Cloudflare. - Copie los certificados al contenedor NPM y recargue Nginx.
Esto garantiza que los navegadores internos acepten los dominios sin advertencias.
6. Versionar la configuración con Ansible
Guarda los siguientes recursos en un playbook:
unifi_network.yml– creación de redes y DHCP.unifi_vlan.yml– asignación de VLAN a puertos y APs.unifi_firewall.yml– reglas de zona a zona.unifi_dns.yml– dominio override.certbot_renew.yml– cron job para renovación.
Ejecutar el playbook en un nuevo nodo reproduce la topología exacta, evitando “drift” de configuración.
Cuándo aplicar esta solución
- Entorno multi‑zona: cuando al menos dos grupos de dispositivos (ej. servidores vs IoT) requieren aislamiento de capa 2/3.
- Uso de nombres internos: si los usuarios consumen servicios mediante dominios (
service.internal.redacted) y necesitan certificados válidos. - Escalabilidad prevista: si planeas añadir más servidores o contenedores y quieres evitar reescribir reglas de firewall manualmente.
No es necesario si tu homelab consiste en un único segmento de red sin exposición a dispositivos inseguros; en ese caso la sobrecarga de VLAN y políticas puede ser excesiva.
Código
# Instalar certbot con plugin Cloudflare
apt-get update && apt-get install -y certbot python3-certbot-dns-cloudflare
# Archivo de credenciales Cloudflare (chmod 600)
cat > ~/.secrets/cloudflare.ini <<EOF
dns_cloudflare_email = [email protected]
dns_cloudflare_api_token = YOUR_API_TOKEN
EOF
# Solicitar certificado wildcard
certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
-d "*.internal.redacted" \
--non-interactive --agree-tos --email [email protected]
# Copiar certificados al contenedor NPM y recargar
docker cp /etc/letsencrypt/live/internal.redacted/fullchain.pem npm:/config/ssl/fullchain.pem
docker cp /etc/letsencrypt/live/internal.redacted/privkey.pem npm:/config/ssl/privkey.pem
docker exec npm nginx -s reload
Verificación
-
Conectividad VLAN
- Desde una máquina en la zona
INTERNAL, ejecutaping 192.168.50.14. - El ping debe responder; un fallo indica VLAN o routing mal configurado.
- Desde una máquina en la zona
-
Resolución DNS
dig immich.internal.redacted @192.168.50.1(IP del UDR).- La respuesta debe contener
192.168.50.14.
-
Acceso al proxy
- Navega a
https://immich.internal.redacted. - El certificado debe ser emitido por Let’s Encrypt y el contenido debe cargar sin advertencias.
- Navega a
-
Política de firewall
- Desde la zona
IOT, intentacurl http://192.168.50.14. - La conexión debe ser rechazada; desde
TRUSTEDdebe funcionar.
- Desde la zona
-
Renovación automática
- Simula una renovación con
certbot renew --dry-run. - Verifica que el contenedor NPM recargue sin errores.
- Simula una renovación con
Notas adicionales
- Wake‑on‑LAN vía Unifi: habilita “Enable Magic Packet” en el perfil del puerto que conecta la workstation. Un script simple (
etherwake <MAC>) puede dispararse desde cualquier