Homelab Network Readiness
Utiliza esta skill antes de realizar cambios en una red doméstica o de laboratorio pequeño que combine VLANs, Pi-hole u otro resolutor DNS local, reglas de firewall y acceso VPN remoto.
Esta es una skill de planificación y revisión. No la conviertas en comandos de copiar y pegar para el router, firewall o VPN a menos que la plataforma de destino, la topología actual, la ruta de reversión, el acceso a la consola y la ventana de mantenimiento sean todos conocidos.
Cuándo Usarla
- Prepararse para dividir una red plana en VLANs de confianza, IoT, invitados, servidores o administración.
- Mover clientes DHCP a Pi-hole, AdGuard Home, Unbound u otro resolutor DNS local.
- Agregar acceso mediante WireGuard, Tailscale, ZeroTier, OpenVPN o VPN nativa del router.
- Revisar si un cambio en el homelab puede bloquear al operador del gateway, switch, punto de acceso, servidor DNS o servidor VPN.
- Convertir una idea informal de red doméstica en un plan de migración por etapas con evidencia de validación.
Reglas de Seguridad
- Mantén la primera respuesta como solo lectura: inventario, riesgos, plan por etapas, validación y reversión.
- No expongas paneles de administración de gateway, resolutores DNS, SSH, consolas NAS o interfaces de gestión de VPN directamente a Internet público.
- No proporciones comandos de firewall, NAT, VLAN, DHCP o VPN sin una plataforma confirmada y un procedimiento de reversión.
- Exige acceso fuera de banda o en la misma sala antes de cambiar VLANs de gestión, puertos trunk, políticas predeterminadas del firewall o configuraciones DHCP/DNS.
- Mantén una ruta de retorno a Internet antes de dirigir toda la red hacia un nuevo resolutor DNS o ruta VPN.
- Trata las redes de IoT, invitados, cámaras y servidores de laboratorio como diferentes zonas de confianza hasta que el operador decida explícitamente lo contrario.
Inventario Necesario
Recopila esto antes de proporcionar pasos de implementación:
| Área | Preguntas |
|---|---|
| Borde de Internet | ¿Cuál es el módem u ONT? ¿El router del ISP está en modo puente o aún enrutando? |
| Gateway | ¿Qué enruta, cortafuegos, maneja DHCP y termina VPNs? |
| Conmutación | ¿Qué puertos del switch son uplinks, puertos de acceso, trunks o no gestionados? |
| Wi-Fi | ¿Qué SSID se asignan a qué redes, y los APs están cableados o en malla? |
| Direccionamiento | ¿Qué subredes existen hoy, y qué rangos entran en conflicto con sitios VPN? |
| DNS/DHCP | ¿Qué servicio otorga actualmente concesiones y direcciones de resolutor? |
| Gestión | ¿Cómo llegará el operador al gateway, switch y AP después de los cambios? |
| Recuperación | ¿Qué se puede revertir localmente si fallan DNS, DHCP, VLANs o rutas VPN? |
Plan de VLANs y Zonas de Confianza
Comienza con la intención en lugar de la sintaxis del proveedor.
| Zona | Contenido típico | Política predeterminada |
|---|---|---|
| Confianza | Portátiles, teléfonos, estaciones de trabajo de administración | Puede alcanzar servicios compartidos y gestión solo cuando sea necesario |
| Servidores | NAS, Home Assistant, hosts de laboratorio, resolutor DNS | Acepta flujos entrantes limitados de clientes de confianza |
| IoT | TVs, enchufes inteligentes, cámaras, altavoces | Solo acceso a Internet más excepciones explícitas |
| Invitados | Dispositivos de visitantes | Solo Internet, sin alcance a la LAN |
| Gestión | Gateway, switches, APs, controladores | Accesible solo desde dispositivos de administración de confianza |
| VPN | Clientes remotos | Mismo o más restrictivo que los clientes de confianza |
Antes de recomendar IDs de VLAN o subredes, confirma:
- El gateway admite enrutamiento entre VLANs y reglas de firewall.
- El switch admite el comportamiento de puertos etiquetados y sin etiquetar requerido.
- Los APs pueden mapear SSIDs a VLANs.
- El operador sabe por qué puerto está conectado durante el cambio.
- La red de gestión sigue siendo alcanzable después de cambios en trunks y SSIDs.
Preparación para Filtrado DNS
Pi-hole u otro resolutor local debe introducirse como una dependencia, no como un punto único de fallo.
- Asigna al resolutor una dirección reservada antes de usarla en las opciones de DHCP.
- Confirma que puede resolver DNS público y nombres locales
home.arpa. - Mantén el gateway o un segundo resolutor disponible como fallback temporal.
- Prueba un cliente o una VLAN antes de cambiar cada ámbito DHCP.
- Documenta qué redes pueden omitir el filtrado y por qué.
- Verifica que las reglas de bloqueo no afecten portales cautivos, VPNs de trabajo, actualizaciones de firmware o dispositivos médicos/de seguridad.
Evidencia de validación útil:
El cliente recibe la concesión DHCP esperada
El cliente recibe el resolutor DNS esperado
La consulta DNS pública se resuelve correctamente
La consulta local home.arpa se resuelve correctamente
El dominio de prueba bloqueado se bloquea solo donde se pretende
Las interfaces de administración del gateway y DNS no son accesibles desde redes de invitados o IoT
Preparación para Acceso Remoto
Para acceso estilo WireGuard, decide a qué se permite que acceda la VPN antes de generar claves o abrir puertos.
| Modo | Cuándo usarlo | Notas de riesgo |
|---|---|---|
| Túnel dividido a una subred | Administración remota de NAS o hosts de laboratorio | Mantén la lista de rutas limitada |
| Túnel dividido a servicios de confianza | Acceder a aplicaciones seleccionadas por IP o DNS | Requiere reglas de firewall precisas |
| Túnel completo | Redes no confiables o viajes | Más ancho de banda y responsabilidad de DNS |
| VPN superpuesta | Acceso remoto más simple con controles de identidad | Aún necesita revisión de ACL |
No recomiendes reenvío de puertos hasta que el operador confirme:
- El punto final de VPN está parcheado y mantenido activamente.
- El puerto reenviado va solo al servicio VPN, no a una interfaz de administración.
- Se entiende DNS dinámico, comportamiento de IP pública y estado CGNAT del ISP.
- Las claves de los peers se pueden revocar sin reconstruir toda la red.
- Los registros o el estado de conexión pueden verificar quién se conectó y cuándo.
Secuencia de Cambios
Prefiere cambios pequeños y reversibles:
- Captura la topología actual, plan IP, configuración DHCP, configuración DNS y reglas de firewall.
- Reserva direcciones de infraestructura para gateway, DNS, controlador, APs, NAS y punto final VPN.
- Crea la nueva zona o VLAN sin mover dispositivos críticos.
- Mueve un cliente de prueba y valida DHCP, DNS, enrutamiento, internet y comportamiento de bloqueo.
- Agrega excepciones de firewall estrechas para los flujos necesarios.
- Mueve un grupo de dispositivos de bajo riesgo.
- Agrega acceso VPN con la ruta y política de firewall más estrechas que satisfagan el caso de uso.
- Documenta el estado final, las excepciones conocidas y los comandos o pasos de IU de reversión.
Lista de Verificación de Revisión
- Cada red tiene una razón de existir y un límite de confianza claro.
- Ninguna interfaz de gestión es accesible desde invitados, IoT o Internet público.
- Un fallo de DNS no imposibilita la capacidad del operador para recuperarse localmente.
- Los cambios en el ámbito DHCP se probaron en un cliente antes de una implementación amplia.
- Los clientes VPN reciben solo las rutas y configuraciones DNS que necesitan.
- Las reglas de firewall son denegación predeterminada entre zonas, con excepciones nombradas.
- El operador aún puede llegar a las superficies de administración del gateway, switch, AP, DNS y VPN.
- La reversión está documentada en el mismo vocabulario que la IU o CLI de la plataforma elegida.
Antipatrones
- Segmentar redes antes de conocer qué puertos del switch y qué SSIDs transportan qué VLANs.
- Mover la estación de trabajo de administración fuera de la única red de gestión alcanzable.
- Apuntar todos los ámbitos DHCP a un Pi-hole antes de probar el DNS de respaldo.
- Publicar NAS, DNS, router o gestión de hipervisor directamente en Internet.
- Tratar el acceso VPN como equivalente al acceso completo a la LAN de confianza.
- Agregar reglas de firewall de permiso total temporalmente y olvidar eliminarlas.
- Copiar comandos de otro proveedor o versión de firmware sin verificar la sintaxis exacta de la plataforma.
Ver También
- Skill:
homelab-network-setup - Skill:
network-config-validation - Skill:
network-interface-health