Checklist Cambio de Red — Estudio Digital Nomada SL

Riesgos altos

Riesgos medios

Puntos OK

Fases de cambio

⚠ Proceder con precaucion

3 bloqueos criticos deben resolverse ANTES de la ventana de cambio. El CGNAT de Vodafone y el host compartido Pi-hole/UniFi son los mayores riesgos.

Inventario de la red actual

🌐 Perimetro e infraestructura

Modem / ONTVodafone HFC — modo bridge

IP publicaCGNAT (compartida) ⚠

GatewaypfSense 2.7.2 — Protectli VP2420

SwitchNetgear GS308E (gestionado, 8p)

Wi-Fi2x UniFi U6 Lite (controladas)

UniFi controllerRaspberry Pi 4 (.20) — comparte host con Pi-hole

💻 Servidores y dispositivos

NAS Synology192.168.1.10

Pi-hole + UniFi ctrl192.168.1.20

Proxmox lab192.168.1.30

Red actualFlat 192.168.1.0/24 (todo mezclado)

IoT8x Shelly, 3x Reolink, 2x Chromecast

Cables etiquetadosNO — uplink desconocido ⚠

Evaluacion de riesgos

ALTO — CGNAT de Vodafone bloquea WireGuard entrante

Vodafone HFC asigna IPs privadas compartidas. No es posible abrir puertos UDP desde internet hacia pfSense sin IP publica dedicada o alternativa.

Mitigacion: Contratar IP publica estatica con Vodafone (aprox 5€/mes) o usar Tailscale/ZeroTier como overlay VPN que no requiere puertos abiertos. Validar ANTES de la ventana.

ALTO — Pi-hole y UniFi controller en el mismo host (192.168.1.20)

Al mover .20 a la VLAN Servers, el controller UniFi perdera visibilidad de las APs si no se configura el VLAN correcto en el puerto del switch antes. Riesgo de perder gestion Wi-Fi completa.

Mitigacion: Migrar el controller UniFi a una VM en Proxmox ANTES del cambio de VLANs, o confirmar que el puerto del switch al que esta conectado el host llevara VLAN Servers sin interrupcion. Acceso fisico al switch obligatorio.

ALTO — Cables sin etiquetar; uplink de uno de los switches desconocido

Cambiar la configuracion de trunk sin saber que puerto es el uplink puede dejar todo el segmento sin conectividad instantaneamente, sin forma rapida de revertir sin acceso fisico.

Mitigacion: Mapear y etiquetar todos los puertos fisicamente el viernes 27. Documentar el puerto uplink antes de tocar cualquier VLAN. No iniciar sin este inventario completado.

MEDIO — Pi-hole como DNS unico (single point of failure)

Si el Pi-hole no arranca tras el cambio de VLAN, toda la resolucion DNS cae. pfSense debe tener fallback configurado.

Mitigacion: Configurar 1.1.1.1 como DNS secundario en todos los scopes DHCP. Probar en un cliente antes de mover toda la red.

MEDIO — Dispositivos IoT pueden perder internet al cambiar DHCP

Shelly y Reolink tienen IPs DHCP actuales. Al cambiar de scope pueden no renovar correctamente o tener conflictos si algunos tenian IPs estaticas configuradas manualmente.

Mitigacion: Verificar si algun IoT tiene IP manual. Reiniciar DHCP en la VLAN IoT primero y comprobar con un solo dispositivo.

MEDIO — Acceso de consola fuera de banda no confirmado

Si pfSense pierde conectividad al cambiar la VLAN de management, se necesita acceso fisico directo o un segundo camino de recuperacion.

Mitigacion: Preparar un portatil con cable directo a la LAN del Protectli VP2420 en los puertos de reserva. Confirmar acceso fisico a la sala el sabado.

Plan de VLANs y zonas de confianza

VLAN ID	Zona	Subred propuesta	Contenido	Politica inter-zona
VLAN 10	Trusted	10.0.10.0/24	Portatiles staff, moviles	Acceso a Servers (restringido), bloqueo IoT
VLAN 20	Servers	10.0.20.0/24	NAS .10, Pi-hole/UniFi .20, Proxmox .30	Solo inbound estrecho desde Trusted + VPN
VLAN 30	IoT	10.0.30.0/24	Shelly, Reolink, Chromecast	Solo internet + excepciones explicitas. Sin LAN
VLAN 40	Guest	10.0.40.0/24	Dispositivos visitantes	Solo internet. Sin LAN ni IoT
VLAN 99	Management	10.0.99.0/24	pfSense, GS308E, APs	Solo desde Trusted admin workstation. Sin internet
VLAN 50	VPN	10.0.50.0/24	Clientes WireGuard (Marcos)	Split tunnel: solo VLAN Servers (ruta estrecha)

Plan de migracion por fases — Sabado 28 Jun

Snapshot y verificacion de prerequisitos

10:00–10:30

Antes de tocar nada, documentar el estado actual y confirmar que los riesgos altos estan mitigados.

✓Exportar config pfSense (Diagnostics > Backup)

✓Captura de pantalla de tablas DHCP actuales y leases activos

✓Confirmar mapa de puertos del GS308E con cables etiquetados

⚠Verificar resolucion CGNAT — si no hay IP publica, WireGuard en fase 7 debe ser Tailscale

Reservar IPs de infraestructura en pfSense

10:30–11:00

Asignar MACs/IPs fijas a: pfSense LAN, GS308E, APs, NAS, Pi-hole, Proxmox. Sin esto, los dispositivos pueden cambiar de IP al mover VLANs.

✓Static DHCP mappings para todos los hosts de infraestructura

✓Confirmar que Pi-hole resuelve public DNS y nombres locales antes de continuar

Crear VLANs en pfSense y GS308E (sin mover dispositivos)

11:00–11:30

Configurar las 6 VLANs en pfSense (Interfaces > VLANs) y en el switch (sin asignar puertos aun). El operador debe seguir en la red actual durante este paso.

✓Crear VLAN IDs 10, 20, 30, 40, 50, 99 en pfSense

✓Crear interfaces en pfSense con scopes DHCP para cada VLAN

✓Configurar VLAN groups en GS308E sin mover puertos de acceso aun

Probar con un cliente en VLAN Trusted

11:30–12:00

Mover un unico portatil de prueba (no el admin workstation principal) a VLAN 10. Validar DNS, internet y acceso a NAS antes de continuar.

✓Cliente recibe lease de 10.0.10.x con DNS 10.0.20.20

✓nslookup google.com y nslookup synology.local responden

✓Acceso a NAS desde cliente Trusted funciona

Mover servidores a VLAN Servers (20)

12:00–12:30

Paso critico: mover NAS, Pi-hole y Proxmox. El controller UniFi debe estar ya migrado a Proxmox o confirmado que el puerto del switch mantiene visibilidad.

⚠Confirmar que UniFi controller sigue alcanzable desde las APs despues del cambio de puerto

✓Asignar puertos del GS308E a VLAN 20 para NAS, Pi-hole, Proxmox

✓Verificar que Pi-hole responde DNS desde VLAN Trusted

Mover IoT a VLAN 30 y Guest a VLAN 40

12:30–13:00

Crear SSIDs separados en UniFi para IoT y Guest, mapear a VLANs 30 y 40. Probar un Shelly y un Chromecast antes de mover todos.

✓SSID "DNomada-IoT" — VLAN 30 — aislamiento cliente activo

✓SSID "DNomada-Guest" — VLAN 40 — solo internet

✓Shelly obtiene IP en 10.0.30.x — internet funciona — no puede alcanzar .10 ni .20

Configurar VPN — WireGuard o Tailscale

13:00–13:30

Si CGNAT resuelto: WireGuard en pfSense, puerto UDP 51820, split tunnel a 10.0.20.0/24. Si CGNAT activo: instalar Tailscale en Proxmox como relay.

⚠NO abrir ports forwarding si CGNAT activo — usar Tailscale/ZeroTier

✓VPN cliente (Marcos) recibe ruta solo a 10.0.20.0/24 — no full tunnel

✓Acceso desde red movil externa — verificar NAS y Proxmox alcanzables

Documentacion final y cierre

13:30–14:00

Documentar el estado final, exportar config pfSense actualizada y verificar el checklist de revision completo.

✓Exportar backup final de pfSense con nueva configuracion

✓Guardar diagrama de red actualizado con VLANs, subredes y dispositivos

✓Anotar comandos de rollback para cada fase

Evidencia de validacion DNS — Comandos de prueba

✅ Tests desde cliente VLAN Trusted (10.0.10.x)

        # 1. Verificar lease DHCP correcto

        ip addr show → inet 10.0.10.42/24

        cat /etc/resolv.conf → nameserver 10.0.20.20

        # 2. DNS publico

        nslookup google.com 10.0.20.20

        Address: 142.250.x.x ✓

        # 3. DNS local (home.arpa)

        nslookup synology.local

        Address: 10.0.20.10 ✓

        # 4. Dominio bloqueado

        nslookup doubleclick.net

        Address: 0.0.0.0 ✓ (bloqueado)

🚫 Tests de aislamiento entre zonas

        # Desde IoT (10.0.30.x) — NO debe alcanzar Servers

        ping 10.0.20.10

        Request timeout ✓ (correcto)

        # Desde Guest (10.0.40.x) — NO puede ver LAN

        ping 10.0.10.1

        Destination unreachable ✓ (correcto)

        # Panel pfSense NO expuesto en Guest/IoT

        curl http://10.0.99.1

        Connection refused ✓ (correcto)

        # VPN — solo alcanza Servers

        ping 10.0.10.1 Timeout ✓

        ping 10.0.20.10 Reply ✓

Checklist de revision final

🔐 Seguridad y acceso

⚠

Ningun panel de gestion expuesto a internetPendiente: confirmar con Vodafone si hay IP publica y que pfSense no expone puertos admin

🔴

VLAN Management (99) solo accesible desde admin workstationA configurar en fase 3

✅

pfSense actualizado a 2.7.2 — sin CVEs criticos conocidosVerificado antes del cambio

⚠

Acceso fisico al switch confirmado para la ventanaPendiente confirmar acceso fisico sala el sabado

✅

Claves WireGuard revocables individualmenteDiseno por peer — Marcos tiene peer propio

📈 DNS y DHCP

✅

Pi-hole con IP reservada fija (10.0.20.20)No puede cambiar de IP al mover VLANs

✅

DNS fallback 1.1.1.1 configurado en todos los scopesPi-hole caido no interrumpe internet

🔴

Probar DNS en un cliente antes de rollout masivoObligatorio en fase 4 antes de continuar

🔴

Reglas de bloqueo no afectan portales cautivos ni VPN de trabajoVerificar whitelist Vodafone captive portal

✅

Dispositivos IoT sin IPs manuales configuradasVerificado antes de la ventana

Plan de reversión

🔄 Procedimiento de rollback — Maximo 15 minutos

Restaurar config pfSense desde backup
Diagnostics > Backup & Restore > seleccionar el backup tomado en Fase 1. pfSense vuelve a la config plana 192.168.1.0/24.

Diagnostics > Backup & Restore > Restore Config

Revertir puertos del switch a VLAN 1 (default)
En GS308E Smart Switch Utility, seleccionar todos los puertos y asignar PVID=1, VLAN membership=1. Guardar y aplicar.

GS308E GUI: VLAN > 802.1Q > Port PVID Config > All ports PVID=1

Revertir SSIDs de UniFi a red legacy
En UniFi Network: editar cada SSID de IoT/Guest y quitar la asignacion de VLAN (dejar en red default). Aplicar y forzar reasociacion.

UniFi Network: Settings > WiFi > SSID > Quitar VLAN override

Reiniciar DHCP en pfSense
Forzar renovacion en todos los clientes. La red plana 192.168.1.0/24 debe estar operativa en menos de 2 minutos tras el rollback de pfSense.

pfSense: Services > DHCP Server > Restart DHCP

Verificar conectividad completa
Comprobar que NAS (.10), Pi-hole (.20) y Proxmox (.30) responden en sus IPs originales. Confirmar internet desde un cliente.

Checklist de Preparacion — Cambio de Red