Problema

Montar un entorno de auto‑hosting que sea estable, seguro y fácil de escalar suele colapsar cuando se combinan varios componentes críticos: firewall, segmentación de red, acceso remoto y monitorización. El patrón típico es que el administrador tiene que lidiar con configuraciones aisladas, documentación dispersa y fallos de integración que aparecen al conectar Docker a una red VLAN protegida por pfSense, o al intentar que Zabbix descubra dispositivos detrás de un VPN. El resultado es un lab que funciona a medias, con puertos abiertos sin control, contenedores que no alcanzan los recursos de red y alertas perdidas.

Causa

  1. Diseño de red sin segmentación clara – Muchos homelabs colocan todos los dispositivos en la misma subred. Cuando se introduce un firewall o VLAN, las reglas de NAT y los rangos de IP se solapan, provocando pérdida de conectividad entre Docker y la LAN.

  2. Configuración de pfSense incompleta – El firewall se instala pero no se ajustan las reglas de salida/internas ni el DNS resolver. Sin reglas explícitas, el tráfico de los contenedores queda bloqueado y el VPN no enruta correctamente.

  3. VPN mal alineada con la topología – WireGuard u OpenVPN se crean con rangos de IP que coinciden con la LAN o con la red de Docker, generando conflictos de rutas y NAT hairpin.

  4. Zabbix sin descubrimiento automático – Si el agente no está instalado en los hosts o la zona de red no está incluida en los rangos de escaneo, el monitoreo queda incompleto y las alertas no se disparan.

  5. Backup sin política 3‑2‑1 – Copias de seguridad que se guardan en el mismo disco o en la misma VLAN que el resto de servicios son vulnerables a fallos simultáneos.

Solución

Adoptar una arquitectura modular donde cada capa tenga su propio rango de IP y sus reglas de firewall definidas de forma explícita. El flujo recomendado es:

  1. Planificar subredes

    • LAN: 192.168.10.0/24 (hosts fijos, servidores)
    • DMZ (Docker): 192.168.20.0/24 (contenedores, servicios expuestos)
    • VPN: 10.200.0.0/24 (clientes remotos)
    • IoT/VLAN: 192.168.30.0/24 (dispositivos aislados)

  2. Instalar y configurar pfSense

    • Realizar la instalación en hardware dedicado o en una VM con al menos 2 GB RAM.
    • Configurar interfaces WAN, LAN y opcionalmente una interfaz OPT para la DMZ.
    • Crear reglas de firewall que permitan tráfico LAN ↔ DMZ solo en puertos necesarios (80, 443, 22) y bloquear todo lo demás.
    • Habilitar DNS Resolver con “Enable DNSSEC” y añadir “Host Overrides” para los nombres internos (p.ej. docker.local → 192.168.20.2).

  3. Definir VLANs en el switch gestionado

    • Asignar VLAN 10 a la LAN, VLAN 20 a la DMZ y VLAN 30 a IoT.
    • Configurar “tagged” en los puertos que conectan al router pfSense y “untagged” en los puertos de los dispositivos finales.
    • Verificar la tabla de MAC y la propagación de DHCP por VLAN.

  4. Desplegar Docker con Docker‑Compose

    • Crear un bridge network aislado que use la subred 192.168.20.0/24.
    • Mapear puertos solo cuando sea necesario, evitando el uso de “host” mode.
    • Montar volúmenes persistentes en /srv/docker para que los datos sobrevivan a reinicios.

  5. Configurar VPN (WireGuard recomendado)

    • Generar pares de claves en el servidor pfSense (o en una VM dedicada).
    • Definir AllowedIPs = 192.168.10.0/24, 192.168.20.0/24 para que el cliente tenga acceso a LAN y DMZ.
    • Añadir una regla NAT en pfSense que traduzca el tráfico VPN hacia la LAN/DMZ.

  6. Instalar Zabbix

    • Ejecutar Zabbix Server y Frontend en contenedores dentro de la DMZ.
    • Configurar “Network discovery” con los rangos 192.168.10.0/24 y 192.168.30.0/24.
    • Desplegar agentes Zabbix en servidores Linux y Windows usando paquetes oficiales.

  7. Implementar backup 3‑2‑1

    • Primera copia: snapshots locales en ZFS o Btrfs (día a día).
    • Segunda copia: replicación a un NAS en la VLAN 30 (semana).
    • Tercera copia: envío cifrado a un bucket S3 compatible (mes).
    • Automatizar con rsync y cron para que se ejecuten fuera de horas pico.

Cuándo aplicar esta solución

  • Síntomas: contenedores que no responden desde la LAN, clientes VPN sin acceso a recursos internos, alertas de Zabbix que nunca se disparan, o backups que fallan por falta de espacio.
  • Entorno: cualquier homelab o pequeña oficina que combine servicios de red, contenedores y monitorización. Funciona tanto en hardware bare‑metal como en VMs.
  • Exclusiones: si solo se necesita un único contenedor sin exposición externa, la capa de VLAN y DMZ es excesiva; en ese caso simplifique a una sola subred y reglas mínimas.

Código

# pfSense: crear alias para la DMZ
pfSsh.php playback alias_add DMZ 192.168.20.0/24

# Docker‑Compose: red aislada para la DMZ
cat > docker-compose.yml <<'EOF'
version: "3.8"
services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    networks:
      dmz_net:
        ipv4_address: 192.168.20.10
networks:
  dmz_net:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.20.0/24
EOF
docker compose up -d

# WireGuard: configuración del servidor (pfSense)
cat > wg0.conf <<'EOF'
[Interface]
Address = 10.200.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>

[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 192.168.10.0/24, 192.168.20.0/24
EOF

Verificación

  1. Conectividad LAN ↔ DMZ

    • Desde un host LAN (ping 192.168.20.10) debería responder el contenedor Nginx.
    • curl http://192.168.20.10 debe devolver la página por defecto.

  2. VPN

    • Conectar el cliente WireGuard y ejecutar ping 192.168.10.1 (router LAN) y ping 192.168.20.10. Ambos deben responder.
    • Verificar en pfSense que la regla “WireGuard → LAN/DMZ” está en estado “Pass”.

  3. Zabbix discovery

    • En la UI de Zabbix, abrir “Discovery” y confirmar que aparecen los hosts de la LAN y la VLAN 30.
    • Generar una prueba de alerta (p.ej. detener el servicio Nginx) y comprobar que el trigger se dispara.

  4. Backup

    • Ejecutar manualmente el script de backup y revisar los logs en /var/log/backup.log.
    • Confirmar que el archivo de snapshot aparece en el NAS y que el objeto S3 está presente.

Notas adicionales

  • DHCP vs estático: reserva direcciones estáticas para dispositivos críticos (pfSense, Docker host, NAS) mediante DHCP static mappings; evita colisiones.
  • Reglas de firewall: siempre prueba con pfctl -sr para listar reglas y con pfctl -t <tag> -T show para depurar tablas de alias.
  • Actualizaciones: mantén pfSense y los contenedores actualizados, pero usa versiones LTS para evitar rupturas inesperadas.
  • Seguridad de VPN: revoca claves de clientes que ya no necesiten acceso y rota la clave del servidor cada 6‑12 meses.
  • Monitoreo de recursos: añade ítems de CPU, RAM y disco de los contenedores al host Zabbix para detectar cuellos de botella antes de que afecten a la producción.

Con esta arquitectura modular, cualquier sysadmin puede replicar el entorno, adaptar rangos y servicios, y mantener un control granular sobre la seguridad y la observabilidad del homelab.