Arquitectura de red del homelab — WAN y LAN
Cómo evolucionó el acceso externo del homelab: del port forwarding clásico con NPMplus a un túnel Cloudflare sin puertos abiertos, y cómo fluye el tráfico interno en la LAN.
Una de las partes más importantes de cualquier homelab es entender cómo fluye el tráfico — tanto desde Internet hacia tus servicios, como dentro de tu propia red local. En este post explico la arquitectura actual del mío y cómo llegué hasta aquí.
El setup inicial — NPMplus y port forwarding
Al principio el acceso externo funcionaba como en la mayoría de homelabs: abrir puertos en el router y usar un reverse proxy (NPMplus) que recibía el tráfico y lo enrutaba al servicio correcto.
El flujo era el siguiente:
- El usuario accede a
wg.juanenlopez.esdesde Internet - El DNS resuelve a la IP pública del router
- El router reenvía los puertos 443 y 80 a NPMplus (192.168.1.103)
- NPMplus termina el SSL y reenvía al servicio interno
Funcionaba, pero tenía dos problemas claros: la IP pública es dinámica (si cambia, el servicio deja de funcionar hasta actualizar el DNS) y los puertos 80 y 443 estaban abiertos permanentemente en el router, exponiendo la infraestructura directamente a Internet.
El setup actual — Cloudflare Tunnel
La solución fue migrar a un túnel de Cloudflare. La diferencia fundamental es que ahora no hay ningún puerto abierto en el router para el tráfico web. En su lugar, un contenedor LXC dedicado (cloudflared) mantiene una conexión saliente permanente hacia Cloudflare.
El nuevo flujo es:
- El usuario accede a cualquier subdominio de
jelopez.link - Cloudflare recibe el tráfico en su red global
- Lo enruta por el túnel hasta el contenedor
cloudflaredde la LAN cloudflaredlo pasa al servicio correspondiente
Ventajas respecto al setup anterior:
- Sin puertos abiertos — la IP pública queda completamente oculta
- Sin problema de IP dinámica — el túnel no depende de la IP del router
- SSL gestionado automáticamente por Cloudflare — sin certbot ni APIs de IONOS
- Authelia delante de cualquier servicio expuesto — MFA obligatorio
WireGuard — acceso completo a la LAN
Para administrar la infraestructura de forma remota (Proxmox, SSH a los LXC, servicios no expuestos por el túnel) uso WireGuard VPN. Este sí requiere un puerto abierto en el router (UDP 51820), pero es el único.
La diferencia con el túnel de Cloudflare es el alcance: el túnel solo da acceso a los servicios que explícitamente publicas. WireGuard te mete dentro de la LAN como si estuvieras en casa — acceso total a cualquier IP y puerto.
El flujo interno — AdGuard y NPMplus
Desde dentro de la LAN el tráfico funciona de forma diferente. Los dispositivos de la red usan AdGuard Home como DNS, que tiene reescrituras para los subdominios internos:
status.jelopez.link→ 192.168.1.103 (NPMplus)auth.jelopez.link→ 192.168.1.105 (Authelia directo)
Así el tráfico interno nunca sale a Internet — va directamente a NPMplus, que termina el SSL y reenvía al servicio. Para los servicios de administración (Proxmox, AdGuard, NPMplus, WireGuard Dashboard) el acceso es directamente por IP y puerto, sin pasar por ningún proxy.
El diagrama completo
Conclusión
El cambio más importante fue el túnel de Cloudflare. Pasar de tener puertos abiertos en el router a una arquitectura donde todo el tráfico web sale desde dentro — sin exponer nada — es una mejora de seguridad significativa. WireGuard sigue siendo imprescindible para la administración remota, y NPMplus + AdGuard cubren el acceso interno cómodo desde la LAN.
En próximos posts iré detallando la configuración de cada componente.