Preparação de Rede Homelab
Use este 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 remoto via VPN.
Este é um skill de planejamento e revisão. Não o transforme em configuração copia-e-cola 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
- Preparando para dividir uma rede plana em VLANs confiáveis, IoT, convidados, servidores ou gerenciamento.
- Movendo clientes DHCP para Pi-hole, AdGuard Home, Unbound ou outro resolvedor DNS local.
- Adicionando acesso via WireGuard, Tailscale, ZeroTier, OpenVPN ou VPN nativa do roteador.
- Revisando se uma alteração no homelab pode bloquear o operador do gateway, switch, ponto de acesso, servidor DNS ou servidor VPN.
- Transformando 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 administrativos do 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 ao console fora da banda ou na mesma sala antes de alterar VLANs de gerência, portas trunk, políticas padrão de firewall ou configurações DHCP/DNS.
- Mantenha um caminho funcional de volta à internet antes de apontar 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 isto 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 | Quais rotas, firewalls, DHCP e VPNs são gerenciados? |
| 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 cabeados ou mesh? |
| Endereçamento | Quais sub-redes existem hoje e quais faixas conflitam com sites VPN? |
| DNS/DHCP | Qual serviço atualmente fornece concessões 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 falharem? |
Plano de VLAN e Zonas de Confiança
Comece com a intenção, não com a sintaxe do fornecedor.
| Zona | Conteúdo típico | Política padrão |
|---|---|---|
| Confiável | Laptops, telefones, estações de trabalho administrativas | Pode alcançar serviços compartilhados e gerência 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, tomadas inteligentes, câmeras, alto-falantes | Acesso à internet mais exceções explícitas apenas |
| Convidados | Dispositivos de visitantes | Somente internet, sem alcance à LAN |
| Gerenciamento | Gateway, switches, APs, controladores | Acessível apenas de dispositivos administrativos confiáveis |
| VPN | Clientes remotos | Acesso igual ou mais restrito que clientes confiáveis |
Antes de recomendar IDs de VLAN ou sub-redes, confirme:
- O gateway suporta roteamento inter-VLAN e regras de firewall.
- O switch suporta o comportamento de porta marcada e não marcada necessário.
- Os APs podem mapear SSIDs para VLANs.
- O operador sabe por qual porta está conectado durante a alteração.
- A rede de gerenciamento permanece acessível após mudanças em trunk e SSID.
Prontidão para Filtragem DNS
Pi-hole ou outro resolvedor local deve ser introduzido como uma dependência, não como um ponto único de falha.
- Dê ao resolvedor um endereço reservado antes de usá-lo nas opções DHCP.
- Confirme que ele pode resolver nomes públicos 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 úteis de validação:
Cliente recebe concessão DHCP esperada
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 administrativas do gateway e DNS não são acessíveis das redes convidados ou IoT
Prontidão para Acesso Remoto
Para acesso estilo WireGuard, decida o que a VPN pode alcançar antes de gerar chaves ou abrir portas.
| Modo | Use quando | Anotações de risco |
|---|---|---|
| Split tunnel para uma sub-rede | Administração remota de NAS ou hosts de laboratório | Mantenha a lista de rotas estreita |
| Split tunnel para serviços confiáveis | Acessar aplicativos selecionados por IP ou DNS | Requer regras de firewall precisas |
| Full tunnel | Redes não confiáveis ou viagem | Mais largura de banda e responsabilidade DNS |
| Overlay VPN | Acesso remoto mais simples com controles de identidade | Ainda precisa de revisão ACL |
Não recomende encaminhamento de porta até que o operador confirme:
- O endpoint VPN está corrigido e ativamente mantido.
- A porta encaminhada vai apenas para o serviço VPN, não para uma interface administrativa.
- DNS dinâmico, comportamento do 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:
- Capture a 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 ou etapas de interface de reversão.
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 internet pública.
- Falha de DNS não interrompe a capacidade do operador de recuperar localmente.
- Alterações de escopo DHCP foram testadas em um cliente antes da implantação ampla.
- Clientes VPN recebem apenas as rotas e configurações DNS de que precisam.
- Regras de firewall são negação padrão entre zonas, com exceções nomeadas.
- O operador ainda pode alcançar as superfícies administrativas do gateway, switch, AP, DNS e VPN.
- A reversão está documentada no mesmo vocabulário da interface do usuário ou CLI da plataforma escolhida.
Antipadrões
- Segmentar redes antes de saber quais portas de switch e SSIDs carregam quais VLANs.
- Mover a estação de trabalho administrativa da única rede de gerenciamento acessível.
- Apontar todos os escopos DHCP para um Pi-hole antes de testar fallback DNS.
- Publicar administração de NAS, DNS, roteador ou 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