Detalhamento técnico completo — VLANs, endereçamento IP, configurações e procedimentos operacionais
Este documento descreve em detalhes a implementação da infraestrutura, incluindo o esquema de endereçamento IP, a segmentação VLAN, as configurações de serviços essenciais, as dependências entre componentes e os procedimentos operacionais padrão. Enquanto o HLD responde "o quê" e "por quê", o LLD responde "como" — é o manual técnico para operar, manter e expandir o ambiente.
Versão pública: a estrutura, os padrões e os procedimentos refletem o ambiente real, mas identificadores (IDs de VLAN, endereços, hostnames e equipamentos) foram substituídos por valores ilustrativos.
Zonas de segurança, VLANs 802.1Q e sub-redes associadas
| VLAN | Zona | Finalidade | Sub-rede |
|---|---|---|---|
| 100 | Gerência | Administração do cluster Proxmox e dos equipamentos de rede, migração ao vivo e replicação ZFS | 10.0.100.0/24 |
| 110 | Servidores | VMs e containers de serviços internos | 10.0.110.0/24 |
| 120 | Publicação web/DMZ | Serviços publicados, acessíveis somente através do proxy reverso | 10.0.120.0/24 |
| 130 | Serviços críticos | Serviços de infraestrutura essenciais, com política de acesso mais restrita | 10.0.130.0/24 |
| 140 | IoT e automação | Dispositivos embarcados e telemetria, sem acesso às zonas internas | 10.0.140.0/24 |
| 150 | Usuários | Estações e dispositivos de usuários | 10.0.150.0/24 |
| 160 | Visitantes | Acesso somente à Internet, isolado das zonas internas | 10.0.160.0/24 |
| 170 | Backup e monitoramento | Tráfego de backup, coleta de métricas e eventos de segurança | 10.0.170.0/24 |
| 901 | WAN A | Link da operadora A, transportado isolado do switch de núcleo até o firewall | IP público (ex.: 203.0.113.10) |
| 902 | WAN B | Link da operadora B, mesmo isolamento; balanceamento e failover no firewall | IP público da operadora |
Valores ilustrativos — IDs de VLAN, endereços e nomes reais ficam na documentação interna.
Em todas as zonas internas o gateway é o endereço .1, atendido pelo IP virtual do
par de firewalls em HA. O tráfego entre zonas sempre atravessa o firewall e segue regras
explícitas por origem, destino e serviço. Clientes VPN recebem endereços de um pool próprio e são
tratados como uma zona adicional nas políticas.
Papéis dos principais componentes e convenção de nomenclatura
| Hostname | Função | Zona de gerência |
|---|---|---|
| pve-node-01 | Nó do cluster Proxmox VE (KVM/LXC sobre ZFS) | 100 · Gerência |
| pve-node-02 | Nó do cluster Proxmox VE (KVM/LXC sobre ZFS) | 100 · Gerência |
| pve-node-03 | Nó do cluster Proxmox VE — três nós mantêm o quorum Corosync | 100 · Gerência |
| pbs-01 | Proxmox Backup Server dedicado, fora do cluster | 170 · Backup e monitoramento |
| fw-01 / fw-02 | Firewall em HA (ativo/standby), VMs em nós distintos do cluster | .1 (IP virtual) em cada zona |
| sw-core-01 | Switch de núcleo (Layer 2): recebe as WANs isoladas e entrega troncos 802.1Q | 100 · Gerência |
| rt-dist-01 | Roteador de distribuição com uplinks redundantes (STP) | 100 · Gerência |
| sw-acc-01 | Switch de acesso | 100 · Gerência |
| ap-01 | Access point | 100 · Gerência |
Valores ilustrativos — IDs de VLAN, endereços e nomes reais ficam na documentação interna.
DNS, monitoramento, SIEM e aplicações em contêiner rodam como VMs e containers distribuídos pelo cluster (mais de 40 no total). O mapeamento serviço → host e os endereços individuais ficam restritos à documentação interna.
Parametrização dos principais serviços da infraestrutura
DNS interno recursivo com filtragem. Pi-hole atua como DNS sinkhole, bloqueando anúncios, rastreadores e domínios maliciosos. Unbound resolve de forma recursiva, valida a cadeia de confiança DNSSEC e mantém cache local. O Pi-hole encaminha apenas para o Unbound, sem resolvedores públicos de terceiros, e aplica limitação de taxa por cliente. O DHCP de cada zona entrega esse resolvedor aos clientes.
Cada aplicação (ex.: automação com n8n + PostgreSQL) é uma stack Compose com banco dedicado, volumes persistentes para dados e configuração, redes internas por stack e política de restart. Nenhuma porta de contêiner é publicada diretamente: o acesso passa pelo proxy reverso, com autenticação obrigatória e segredos mantidos fora do controle de versão.
Prometheus coleta métricas via node_exporter nos servidores e exporters específicos por serviço. O Grafana usa o Prometheus como datasource para dashboards de capacidade, disponibilidade e desempenho. Alertas são roteados pelo Alertmanager por webhook para um canal de mensageria da operação.
Stack completa com Wazuh Manager, Wazuh Indexer e Wazuh Dashboard. Agentes nos servidores e VMs enviam eventos para correlação, junto com os alertas de IDS da rede. Regras personalizadas detectam anomalias no cluster Proxmox e nos serviços críticos, e a resposta automatizada contém o incidente sem intervenção manual.
Nginx é o único ponto de entrada HTTP/HTTPS para as aplicações internas e publicadas, com upstreams por serviço. TLS com certificados Let's Encrypt renovados automaticamente via certbot (ex.: app.exemplo.com.br). Rate limiting, cabeçalhos de segurança e allowlist de origens administrativas para interfaces de gestão.
Inversor off-grid com banco de baterias gerenciado por BMS. Um microcontrolador lê os dados via Modbus (RS485), e o BMS controla carga e descarga das células. Um script Python coleta as leituras periodicamente e as expõe por endpoint HTTP no formato do Prometheus.
Active Directory, DNS, DHCP, IIS e GPO em ambiente de domínio
Controlador de domínio com autenticação centralizada, políticas de grupo (GPO) e integração com DNS. Gerencia usuários, computadores e permissões no domínio.
Servidor DNS integrado ao AD com zonas diretas e reversas. DHCP com escopos por VLAN, reservas por MAC e failover entre dois servidores.
Servidor web IIS para aplicações internas (intranet, dashboards administrativos). Configurado com HTTPS, isolamento de aplicações e logging centralizado.
Políticas de grupo para hardening de estações Windows (senhas, firewall, atualizações). Scripts PowerShell para automação de tarefas administrativas e relatórios.
Relações de dependência para ordem de inicialização e troubleshooting
| Serviço | Depende de | Impacto se Indisponível |
|---|---|---|
| Cluster Proxmox | Corosync, rede de gerenciamento dedicada, storage ZFS | VMs e containers ficam offline sem failover |
| DNS (Pi-hole/Unbound) | Rede de serviços interna | Resolução de nomes local e externa interrompida |
| Nginx Proxy Reverso | DNS, certificados SSL, rede DMZ | Serviços web ficam inacessíveis externamente |
| Grafana | Prometheus, InfluxDB (se aplicável) | Dashboards de métricas e alertas offline |
| Wazuh SIEM | Wazuh Indexer (elasticsearch) | Correlação de eventos e dashboards de segurança offline |
| Firewall (par HA) | Cluster Proxmox (nós distintos), troncos 802.1Q do switch de núcleo | Standby assume o IP virtual; sem nenhum dos dois, param roteamento entre zonas, NAT, DHCP e VPN |
| Energia | Inversor, banco de baterias com BMS, quadro elétrico | Infraestrutura opera em bateria com autonomia limitada; desligamento gracioso automatizado |
| Internet (WAN A / WAN B) | Links das operadoras, switch de núcleo, firewall HA (NAT e balanceamento) | Failover automático para o link remanescente; serviços publicados seguem pelo outro link |
Checklists e procedimentos para operações rotineiras e emergenciais
pvecm status — todos os 3 nós devem estar onlineha-manager crm-command node-maintenance enable pve-node-0Xrebootpvecm statusha-manager crm-command node-maintenance disable pve-node-0X/etc/pve sincronizado via cluster filesystemStack técnica envolvida nas configurações de baixo nível
"Baixo nível não é sobre onde você configura — é sobre como você recupera quando a configuração quebrar. Este LLD existe para que qualquer administrador com acesso ao documento consiga reconstruir cada serviço do zero, sem depender de memória ou de 'aquela configuração que está ali faz tempo'. Se não está documentado, não existe."
Com o LLD em mãos, explore os diagramas para visualizar a topologia ou consulte o inventário para a visão consolidada dos componentes.
