Skip to content

Network reference

Datos canónicos de red. Para diagramas y flujos, ver Architecture → Network map.

Subnet

  • LAN: 192.168.0.0/24, plana (sin VLANs, intencional)
  • Gateway/DHCP: 192.168.0.1 — ASUS TUF-AX6000 (SSH admin, algoritmos legacy). No es "Movistar R2"; ese router está fuera de servicio.
  • Broadcast: 192.168.0.255

Esquema de bloques (renumeración cerrada 2026-07-31, verificado 2026-08-01)

Bloque Uso Notas
.1 Gateway ASUS TUF-AX6000
.2 — .9 Libre Equipo UniFi (CloudKey/switch/AP) devuelto 2026-08-09 — era préstamo temporal
.10 — .19 Hipervisores / físicos pmx-50 .50… ver nota¹
.20 — .29 Almacenamiento NAS .20, PBS .22
.30 — .49 Proxy Caddy .40/.41
.100 — .199 DHCP dinámico + IoT clientes dinámicos
.200 — .229 Servidores (VMs/LXCs) ver tabla abajo
.230 — .249 Reserva libre
.250 — .254 VIP Caddy VIP .250

¹ pmx-50/pmx-51 quedaron en .50/.51 (fuera del bloque .10-.19 nominal) — anclas que no se tocaron durante la renumeración; tratar como excepción histórica, no como error.

Hosts críticos

IP Host Servicio principal
192.168.0.1 router.lan ASUS TUF-AX6000 — gateway WAN, NAT, DHCP
192.168.0.20 nas.lan NAS TerraMaster F4-423 (movido de .237 en Oleada 3)
192.168.0.22 pbs.lan (LXC 186) Proxmox Backup Server
192.168.0.40 caddy1.lan (LXC 270) Caddy primary
192.168.0.41 caddy2.lan (LXC 271) Caddy secondary
192.168.0.50 pmx-50.lan Proxmox nodo Ryzen
192.168.0.51 pmx-51.lan Proxmox nodo Celeron
192.168.0.160 synology.lan Synology DS — DSM (NAS secundario)
192.168.0.171 ha.lan (VM 171) Home Assistant
192.168.0.200 n8n.lan (LXC 200) n8n + alert forwarder
192.168.0.201 ha-ml.lan (LXC 172) ha-ml
192.168.0.202 rag.lan (LXC 251) RAG + Kiwix
192.168.0.203 vera.lan (LXC 100 clawdbot) Vera/OpenClaw agent
192.168.0.204 pihole.lan Pi-hole DNS (Raspi)
192.168.0.205 rp.lan (LXC 280) Remote-Pulse server
192.168.0.206 wireguard.lan (LXC 155) VPN
192.168.0.207 cloudflared.lan (LXC 123) CF Tunnel daemon
192.168.0.208 vm208.lan / media.lan (VM 208) Docker hub (obs + apps; Caddy vive en LXC 270/271)
192.168.0.210 tv-gw.lan (LXC 110) tv-gw (LG TV monitoring)
192.168.0.211 wp-pulse.lan (LXC 281) WP-Pulse control plane
192.168.0.227 — LG TV (monitorizada vía tv-gw)
192.168.0.250 caddy-vip.lan keepalived ingress unificado

Fuente de esta tabla: pvesh get /cluster/resources (IPs de LXC/VM) + /etc/dnsmasq.d/06-homelab-lan.conf en Pi-hole (mapa .lan vivo, creado 2026-07-31 para la renumeración — "DNS-first", cambiar la IP se hace solo ahí). Verificado 2026-08-01.

DNS

Pi-hole (.204)

  • Primary DNS para toda la LAN (vía DHCP option 6).
  • Sinkhole de listas estándar (StevenBlack hosts, etc.).
  • Override monxas.casa en dnsmasq config (/etc/dnsmasq.d/05-local-homelab.conf): 
    address=/monxas.casa/192.168.0.250   # VIP Caddy
    Esto manda cualquier subdominio *.monxas.casa a la IP local del ingress, evitando el round-trip a CF cuando estamos en LAN.

Cloudflare

  • Zona monxas.casa gestionada en CF.
  • Registro wildcard *.monxas.casa (CNAME) → <tunnel-uuid>.cfargotunnel.com.
  • Vigente desde 2026-05-20: ya no hace falta crear DNS record por servicio nuevo.
  • TTL: Automatic (CF managed).

Hostnames locales .lan (DNS-first, vigente desde 2026-07-31)

Ya SÍ están configuradas — esto cambió con la renumeración. Pi-hole sirve host-record para cada host en /etc/dnsmasq.d/06-homelab-lan.conf ("al mover una IP, se cambia SOLO la línea de aquí"). Mapa completo verificado 2026-08-01:

# --- red ---
router.lan       192.168.0.1
cloudkey.lan      192.168.0.2
switch.lan        192.168.0.3
ap.lan            192.168.0.4
# --- hipervisores / fisicos ---
pmx-50.lan        192.168.0.50
pmx-51.lan        192.168.0.51
pihole.lan        192.168.0.204
octopi.lan        192.168.0.120
bazzite.lan       192.168.0.141
# --- almacenamiento ---
nas.lan           192.168.0.20
synology.lan      192.168.0.160
pbs.lan           192.168.0.22
# --- servidores (VMs/LXCs) ---
ha.lan            192.168.0.171
ha-ml.lan         192.168.0.201
vm208.lan / media.lan  192.168.0.208
n8n.lan           192.168.0.200
rp.lan            192.168.0.205
wp-pulse.lan      192.168.0.211
vera.lan          192.168.0.203
tv-gw.lan         192.168.0.210
rag.lan           192.168.0.202
cloudflared.lan   192.168.0.207
wireguard.lan     192.168.0.206
# --- proxy ---
caddy1.lan        192.168.0.40
caddy2.lan        192.168.0.41
caddy-vip.lan     192.168.0.250

VIPs

VIP keepalived priority Backed by Purpose
192.168.0.250 MASTER 150, BACKUP 100 LXC 270 (pmx-50) → LXC 271 (pmx-51) Caddy HA ingress

track_process caddy weight -20: si Caddy muere en MASTER, prioridad baja a 130 y BACKUP (100) sigue siendo BACKUP… mal. Ver keepalived.conf: en realidad el weight se debe restar de la BACKUP para que el failover funcione, o usar track_script con un check de TCP :443. Validar empíricamente durante el Caddy failover drill.

CF Tunnel

  • Tunnel UUID: gestionado en CF dashboard, credentials en secrets/cloudflared.sops.yaml.
  • Daemon: LXC 123 (pmx-51), cloudflared service.
  • Config: /etc/cloudflared/config.yaml — generado por homelab-ctl.py.
  • Ingress regla por defecto post-F4: 
    ingress:
  - hostname: "*.monxas.casa"
    service: https://192.168.0.250:443
    originRequest:
      noTLSVerify: true   # Caddy serve internal TLS
  - service: http_status:404

Puertos en el router

CF Tunnel es el ingress externo deseado (443 saliente, sin exponer nada entrante). Pero verificado 2026-08-01 vía nvram get vts_rulelist en el ASUS, el router tiene port-forwards activos que contradicen la idea de "cero entrantes":

Regla Puerto Destino Protocolo
HTTP Server 80 192.168.0.208 TCP+UDP
HTTPS Server 443 192.168.0.208 TCP+UDP
Torrent 50413 192.168.0.208 TCP+UDP
Wireguard-udp 51820 192.168.0.206 UDP

⚠️ TODO/gotcha sin resolver: las reglas 80/443/50413→.208 parecen residuo de antes de migrar a Cloudflare Tunnel (o de un setup de puerto directo para torrent/*arr). No verificado si siguen realmente necesarias — candidatas a limpieza, pero no las he tocado (fuera de alcance de esta auditoría de docs). Confirmar con el propietario antes de borrarlas.

Filosofía original (parcialmente vigente):

  • Toda exposición HTTP(S) debería ir por CF (DDoS protection, CF Access SSO).
  • Si CF cae, todo lo externo debería caer — pero los forwards de arriba son una vía alternativa no documentada previamente.

VPN (WireGuard)

  • Server: LXC 155 (pmx-51), IP 192.168.0.206.
  • Listen port: 51820 UDP (ver tabla de port-forwards arriba — ya no es el único forward del router, hay 3 reglas TCP+UDP más sin explicar).
  • Subnet WG: 10.0.0.0/24.
  • Clientes: móviles + Macs cuando se viaja.
  • Routing: full tunnel (todo el tráfico) o split (solo 192.168.0.0/24 + *.monxas.casa).

Cosas que NO existen

  • VLANs — red plana intencionalmente.
  • IPv6 LAN — solo IPv4 internamente; CF maneja dual-stack externo.
  • mDNS/Bonjour cross-subnet — irrelevante (un solo subnet).
  • Multicast routing — keepalived usa VRRP en mismo subnet, no necesita.