Prontidão da Rede de Homelab
Use esta skill antes de alterar uma rede doméstica ou de pequeno laboratório que mistura VLANs, Pi-hole ou outro resolvedor DNS local, regras de firewall e acesso VPN remoto.
Esta é uma skill de planejamento e revisão. Não a transforme em configuração copiar-e-colar de roteador, firewall ou VPN, a menos que a plataforma alvo, a topologia atual, o caminho de reversão, o acesso ao console e a janela de manutenção sejam todos conhecidos.
Quando Usar
- Preparar-se para dividir uma rede plana em VLANs de confiança, IoT, convidados, servidores ou gerenciamento.
- Mover clientes DHCP para Pi-hole, AdGuard Home, Unbound ou outro resolvedor DNS local.
- Adicionar acesso WireGuard, Tailscale, ZeroTier, OpenVPN ou VPN nativa do roteador.
- Revisar se uma alteração no homelab pode bloquear o operador do gateway, switch, ponto de acesso, servidor DNS ou servidor VPN.
- Transformar uma ideia informal de rede doméstica em um plano de migração em etapas com evidências de validação.
Regras de Segurança
- Mantenha a primeira resposta somente leitura: inventário, riscos, plano em etapas, validação e reversão.
- Não exponha painéis de administração de gateway, resolvedores DNS, SSH, consoles NAS ou interfaces de gerenciamento VPN diretamente à internet pública.
- Não forneça comandos de firewall, NAT, VLAN, DHCP ou VPN sem uma plataforma confirmada e um procedimento de reversão.
- Exija acesso fora da banda ou console na mesma sala antes de alterar VLANs de gerenciamento, portas trunk, políticas padrão de firewall ou configurações DHCP/DNS.
- Mantenha um caminho funcional de volta à internet antes de direcionar toda a rede para um novo resolvedor DNS ou rota VPN.
- Trate redes IoT, convidados, câmeras e servidores de laboratório como zonas de confiança diferentes até que o operador escolha explicitamente o contrário.
Inventário Necessário
Colete isso antes de fornecer etapas de implementação:
| Área | Perguntas |
|---|---|
| Borda da internet | Qual é o modem ou ONT? O roteador ISP está em modo bridge ou ainda roteando? |
| Gateway | Que rotas, firewalls, gerencia DHCP e termina VPNs? |
| Switching | Quais portas do switch são uplinks, portas de acesso, trunks ou não gerenciadas? |
| Wi-Fi | Quais SSIDs mapeiam para quais redes, e os APs são com fio ou mesh? |
| Endereçamento | Quais sub-redes existem hoje, e quais intervalos entram em conflito com sites VPN? |
| DNS/DHCP | Qual serviço atualmente distribui leases e endereços de resolvedor? |
| Gerenciamento | Como o operador alcançará o gateway, switch e AP após as alterações? |
| Recuperação | O que pode ser revertido localmente se DNS, DHCP, VLANs ou rotas VPN quebrarem? |
Plano de VLAN e Zonas de Confiança
Comece pela intenção, não pela sintaxe do fornecedor.
| Zona | Conteúdo típico | Política padrão |
|---|---|---|
| Confiável | Laptops, telefones, estações de trabalho de administração | Pode alcançar serviços compartilhados e gerenciamento apenas quando necessário |
| Servidores | NAS, Home Assistant, hosts de laboratório, resolvedor DNS | Aceita fluxos de entrada estreitos de clientes confiáveis |
| IoT | TVs, plugues inteligentes, câmeras, alto-falantes | Acesso à internet mais exceções explícitas apenas |
| Convidados | Dispositivos de visitantes | Apenas internet, sem alcance à LAN |
| Gerenciamento | Gateway, switches, APs, controladores | Acessível apenas de dispositivos administradores confiáveis |
| VPN | Clientes remotos | Mesmo acesso ou mais restrito que clientes confiáveis |
Antes de recomendar IDs de VLAN ou sub-redes, confirme:
- O gateway suporta roteamento entre VLANs e regras de firewall.
- O switch suporta o comportamento de porta marcada (tagged) e não marcada (untagged) necessário.
- Os APs podem mapear SSIDs para VLANs.
- O operador sabe qual porta eles estão conectados durante a alteração.
- A rede de gerenciamento permanece acessível após alterações de trunk e SSID.
Prontidão de Filtragem DNS
Pi-hole ou outro resolvedor local deve ser introduzido como uma dependência, não como um ponto único de falha.
- Atribua um endereço reservado ao resolvedor antes de usá-lo nas opções DHCP.
- Confirme que ele pode resolver DNS público e nomes locais
home.arpa. - Mantenha o gateway ou um segundo resolvedor disponível como fallback temporário.
- Teste um cliente ou uma VLAN antes de alterar todos os escopos DHCP.
- Documente quais redes podem ignorar a filtragem e por quê.
- Verifique se as regras de bloqueio não quebram portais cativos, VPNs de trabalho, atualizações de firmware ou dispositivos médicos/de segurança.
Evidências de validação úteis:
Cliente recebe lease DHCP esperado
Cliente recebe resolvedor DNS esperado
Consulta DNS pública é bem-sucedida
Consulta local home.arpa é bem-sucedida
Domínio de teste bloqueado é bloqueado apenas onde pretendido
Interfaces de administração do gateway e DNS não são acessíveis de redes convidadas ou IoT
Prontidão de Acesso Remoto
Para acesso estilo WireGuard, decida o que a VPN pode alcançar antes de gerar chaves ou abrir portas.
| Modo | Use quando | Notas de risco |
|---|---|---|
| Túnel dividido para uma sub-rede | Administração remota de NAS ou hosts de laboratório | Mantenha a lista de rotas estreita |
| Túnel dividido para serviços confiáveis | Acessar aplicativos selecionados por IP ou DNS | Requer regras de firewall precisas |
| Túnel completo | Redes não confiáveis ou viagens | Mais largura de banda e responsabilidade DNS |
| VPN overlay | Acesso remoto mais simples com controles de identidade | Ainda precisa de revisão de ACL |
Não recomende encaminhamento de porta até que o operador confirme:
- O endpoint VPN está corrigido e mantido ativamente.
- A porta encaminhada vai apenas para o serviço VPN, não para uma interface de administração.
- DNS dinâmico, comportamento de IP público e status CGNAT do ISP são compreendidos.
- Chaves de pares podem ser revogadas sem reconstruir toda a rede.
- Logs ou status de conexão podem verificar quem se conectou e quando.
Sequência de Mudanças
Prefira mudanças pequenas e reversíveis:
- Faça um snapshot da topologia atual, plano IP, configurações DHCP, configurações DNS e regras de firewall.
- Reserve endereços de infraestrutura para gateway, DNS, controlador, APs, NAS e endpoint VPN.
- Crie a nova zona ou VLAN sem mover dispositivos críticos.
- Mova um cliente de teste e valide DHCP, DNS, roteamento, internet e comportamento de bloqueio.
- Adicione exceções de firewall estreitas para fluxos necessários.
- Mova um grupo de dispositivos de baixo risco.
- Adicione acesso VPN com a rota e política de firewall mais estreitas que satisfaçam o caso de uso.
- Documente o estado final, exceções conhecidas e comandos de reversão ou etapas da interface.
Lista de Verificação de Revisão
- Cada rede tem uma razão para existir e um limite de confiança claro.
- Nenhuma interface de gerenciamento é acessível de convidados, IoT ou da internet pública.
- A falha de DNS não derruba a capacidade do operador de recuperar localmente.
- Mudanças no escopo DHCP foram testadas em um cliente antes da implementação ampla.
- Clientes VPN recebem apenas as rotas e configurações DNS que precisam.
- Regras de firewall são padrão-negado entre zonas, com exceções nomeadas.
- O operador ainda pode alcançar as superfícies de administração do gateway, switch, AP, DNS e VPN.
- A reversão está documentada no mesmo vocabulário da interface ou CLI da plataforma escolhida.
Anti-Padrões
- Segmentar redes antes de saber quais portas de switch e SSIDs carregam quais VLANs.
- Mover a estação de trabalho de administração para fora da única rede de gerenciamento acessível.
- Apontar todos os escopos DHCP para um Pi-hole antes de testar DNS de fallback.
- Publicar NAS, DNS, roteador ou gerenciamento de hipervisor diretamente na internet.
- Tratar acesso VPN como equivalente a acesso completo à LAN confiável.
- Adicionar regras de firewall permitir-tudo temporariamente e esquecer de removê-las.
- Copiar comandos de outro fornecedor ou versão de firmware sem verificar a sintaxe exata da plataforma.
Veja Também
- Skill:
homelab-network-setup - Skill:
network-config-validation - Skill:
network-interface-health