Boas práticas de configuração de rede em servidores: consistência, nomes e observabilidade

Por que “boas práticas” importam na rede de servidores

Em administração de servidores, a maioria dos incidentes de rede não nasce de “falta de tecnologia”, e sim de inconsistência: IPs fora do padrão, nomes ambíguos, DNS interno e externo misturados, segmentação mal documentada, regras de firewall improvisadas e pouca observabilidade. Boas práticas operacionais reduzem tempo de diagnóstico, evitam indisponibilidades por mudanças simples e facilitam auditoria e crescimento do ambiente.

Padronização: endereços, nomes e fontes de verdade

Defina uma “fonte de verdade” (SoT) para rede

Antes de configurar servidores, defina onde a equipe consulta o que é “o correto”: planilha controlada, CMDB, repositório Git com arquivos YAML/JSON, ou ferramenta de IPAM. O importante é existir um local único com: sub-redes/VLANs, gateways, DNS, faixas reservadas, nomes, responsáveis e histórico de mudanças.

• Regra prática: nada de “IP anotado no chat”. Se não está na SoT, não existe.
• Campos mínimos recomendados: hostname, FQDN interno, IP(s), VLAN/sub-rede, gateway, DNS, finalidade do servidor, portas expostas, regras de firewall associadas, data e autor da mudança.

Padronização de endereços IP (alocação previsível)

Mesmo quando você usa DHCP com reservas, é útil manter um padrão lógico de alocação para reduzir colisões e facilitar leitura. Exemplos de padrões comuns:

• Por função: faixa para bancos, faixa para aplicações, faixa para infraestrutura (monitoramento, backup, diretório).
• Por ambiente: produção, homologação, desenvolvimento em sub-redes/VLANs distintas.
• Por local: site A, site B, nuvem, laboratório.

Boas práticas:

• Reserve blocos para IPs estáticos (ou reservas) e não misture com pool dinâmico.
• Evite “ilhas” de IPs aleatórios: prefira alocação sequencial dentro do bloco reservado.
• Padronize múltiplas interfaces: por exemplo, eth0 (gerência), eth1 (dados), cada uma em sua VLAN/sub-rede.

Padronização de nomes (hostnames e FQDN)

Nomes consistentes aceleram troubleshooting e evitam erros operacionais. Um padrão simples e útil para servidores:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

<função>-<app>-<ambiente>-<site>-<nn>

Exemplos:

• db-postgres-prd-sp-01
• api-pagamentos-hml-rj-02
• mon-prometheus-prd-sp-01

Regras práticas:

• Use somente letras minúsculas, números e hífen.
• Evite nomes “criativos” (ex.: thor, zeus) — não comunicam função.
• O hostname deve bater com o registro DNS interno (FQDN) e com a documentação.

Uso correto de DNS interno e externo

Separação de responsabilidades

DNS interno deve resolver nomes e serviços usados dentro da rede corporativa (ou redes privadas na nuvem). DNS externo deve publicar somente o que precisa ser acessado de fora, com controles de segurança e exposição mínima.

• Interno: db-postgres-prd-sp-01.intra.exemplo.local (ou domínio interno escolhido pela organização).
• Externo: api.exemplo.com apontando para o ponto de publicação (WAF, balanceador, reverse proxy), não diretamente para IP privado.

Boas práticas:

• Evite “split-brain” sem necessidade: se usar o mesmo domínio internamente e externamente, documente e teste bem para não quebrar resolução em VPN, filiais e nuvem.
• Padronize TTLs: TTL muito alto atrapalha mudanças; TTL muito baixo aumenta carga e pode mascarar problemas. Defina valores por tipo de registro (ex.: serviços críticos com TTL moderado).
• Registre dependências: quais aplicações dependem de quais nomes (útil para mudanças e incidentes).

Passo a passo: validar resolução interna e externa (do ponto de vista do servidor)

Execute testes sempre do servidor (ou de uma máquina na mesma VLAN/sub-rede), porque o seu notebook pode estar em outra rota/DNS.

# Ver quais DNS o servidor está usando (Linux com systemd-resolved pode variar) cat /etc/resolv.conf  # Testar resolução interna (A/AAAA) dig +short db-postgres-prd-sp-01.intra.exemplo.local  # Testar resolução externa (se aplicável) dig +short api.exemplo.com  # Verificar tempo de resposta e servidor que respondeu dig db-postgres-prd-sp-01.intra.exemplo.local

Critérios mínimos: o nome resolve para o IP esperado, a resposta vem do servidor DNS correto, e o tempo de resposta é estável (sem picos frequentes).

Reverse DNS (PTR): quando é necessário e como padronizar

Reverse DNS (registro PTR) mapeia IP → nome. Nem todo ambiente exige PTR para tudo, mas ele é frequentemente necessário para:

• Serviços de e-mail (antispam e reputação).
• Alguns controles de autenticação/segurança e auditoria.
• Logs e ferramentas que enriquecem eventos com hostname a partir do IP.

Boas práticas:

• Se você define que PTR é obrigatório, seja consistente: PTR ausente em parte do parque vira ruído em incidentes.
• PTR deve apontar para um FQDN válido e que também tenha registro direto (A/AAAA) coerente.
• Documente quem administra o reverse (provedor, time de rede, time de DNS) e o fluxo de solicitação.

Passo a passo: validar reverse

# Consultar PTR do IP dig -x 10.20.30.40 +short  # Conferir se o nome retornado resolve de volta para o mesmo IP dig +short db-postgres-prd-sp-01.intra.exemplo.local

Separação por VLAN/sub-rede: segmentação operacional que funciona

Segmentação não é só “segurança”; é também previsibilidade de tráfego, redução de domínio de falhas e organização. A prática recomendada é separar por função e criticidade, evitando que tudo fique na mesma rede.

Padrões comuns de segmentação

• Gerência (management): SSH/RDP, agentes de monitoramento, automação.
• Aplicação: tráfego entre serviços.
• Banco de dados: acesso restrito apenas a aplicações autorizadas.
• Backup/replicação: tráfego pesado isolado para não degradar produção.
• DMZ/publicação: componentes expostos (reverse proxy, WAF, balanceador) com regras estritas para dentro.

Boas práticas:

• Evite “atalhos” (ex.: liberar banco para a VLAN inteira). Prefira regras por origem/destino e portas necessárias.
• Padronize o que existe em cada VLAN: DNS, NTP, repositórios, proxies, rotas.
• Defina claramente o caminho de acesso remoto: VPN → VLAN de gerência → servidores, e não VPN direto em redes sensíveis sem controle.

Regras mínimas de firewall: baseline operacional

Mesmo com firewalls avançados, um baseline simples evita exposição acidental e facilita auditoria. Pense em “mínimo necessário” e em regras repetíveis.

Baseline recomendado (conceitual)

• Entrada (inbound): negar por padrão; permitir apenas portas e origens necessárias.
• Saída (outbound): permitir o necessário para atualização, DNS, NTP, monitoramento e dependências; bloquear o que não faz sentido (ex.: servidor de banco saindo para a internet sem justificativa).
• Gerência: acesso administrativo somente a partir da VLAN de gerência/VPN/bastion.
• Serviços internos: permitir apenas entre componentes que precisam se falar (ex.: app → db na porta específica).

Passo a passo: construir uma matriz de portas antes de abrir regras

Antes de mexer em firewall, monte uma matriz simples por serviço:

Depois, implemente regras equivalentes no firewall de borda/segmentação e/ou no firewall do host, mantendo o mesmo padrão de nomenclatura e comentários (ex.: ticket/ID da mudança).

Observabilidade de conectividade: o que monitorar para reduzir MTTR

Observabilidade de rede para servidores não é só “ping”. Você quer detectar indisponibilidade, degradação (latência/perda), falhas de DNS e portas críticas antes do usuário perceber.

Métricas e checagens essenciais

• Disponibilidade ICMP (quando permitido): útil como sinal, mas não suficiente.
• Latência e perda: monitore média e p95/p99 quando possível; perda intermitente costuma indicar problemas de link, congestionamento ou MTU/fragmentação em algum ponto.
• DNS: tempo de resposta, taxa de falhas, e checagem de registros críticos (A/AAAA/CNAME/PTR quando aplicável).
• Portas de serviço: checar TCP connect (e, quando fizer sentido, handshake de aplicação: HTTP status, banner TLS, etc.).
• Rotas e gateway: detectar mudanças inesperadas (ex.: rota padrão alterada) e flaps.

Passo a passo: criar um “pacote mínimo” de testes de conectividade no servidor

Use um conjunto pequeno e repetível de comandos para validar rapidamente rede e registrar evidências em incidentes. Exemplo (ajuste nomes/IPs):

# 1) Identidade e IPs ip -br addr  # 2) Rotas e gateway ip route  # 3) Teste de alcance ao gateway (se ICMP permitido) ping -c 3 10.20.30.1  # 4) DNS: resolução e tempo dig +tries=1 +time=2 db-postgres-prd-sp-01.intra.exemplo.local dig +tries=1 +time=2 api.exemplo.com  # 5) Portas críticas (TCP) - usando nc (netcat) nc -vz -w 2 10.20.30.50 5432 nc -vz -w 2 10.20.40.10 443  # 6) Se houver proxy/balanceador HTTP, validar resposta curl -sS -m 3 -o /dev/null -w "%{http_code} %{time_total}\n" https://api.exemplo.com/health

Dica operacional: guarde esse script em um local padrão (ex.: /usr/local/sbin/netcheck) e referencie em runbooks. Em incidentes, isso reduz variação entre operadores.

Logs que ajudam a explicar “por que caiu”

Além de métricas, logs são a trilha do que aconteceu. Para rede em servidores, priorize:

• Logs do firewall do host (drops relevantes, com taxa controlada para não inundar).
• Logs de DNS do resolvedor local (timeouts, SERVFAIL, mudanças de servidor DNS).
• Logs de serviços expostos (falhas de bind em porta, erros TLS, conexões recusadas).
• Eventos de link (interface down/up, renegociação, mudanças de MTU quando aplicável).

Boas práticas:

• Padronize timezone (preferencialmente UTC) e sincronização de tempo (NTP) para correlação.
• Centralize logs (syslog/agent) e defina retenção mínima para investigação.
• Evite logar dados sensíveis; foque em metadados (origem/destino/porta/ação).

Registro de mudanças (change log) para reduzir incidentes

Mudanças de rede são uma das maiores fontes de indisponibilidade: troca de DNS, alteração de rota, ajuste de firewall, mudança de VLAN, atualização de IP. Um processo leve de registro já reduz muito o retrabalho.

O que registrar em toda mudança de rede

• O que mudou: antes/depois (IP, máscara, gateway, DNS, regras, VLAN).
• Por que mudou: objetivo e risco.
• Quem aprovou e quem executou.
• Janela e impacto esperado.
• Plano de rollback: como voltar ao estado anterior rapidamente.
• Validação pós-mudança: evidências (saída de comandos, checks de monitoramento).

Passo a passo: modelo simples de registro (para ticket ou repositório)

Change-ID: NET-2026-00123 Data/Hora (UTC): 2026-01-25 02:00 Serviço: api-pagamentos (produção) Itens alterados: - Servidor: api-pagamentos-prd-sp-02 - IP: 10.20.40.22 (mantido) - DNS: alterado de 10.20.1.10 para 10.20.1.11 - Firewall: liberado 443/TCP a partir do LB 10.20.50.10 Motivo: migração do resolvedor DNS e ajuste de publicação Risco: médio Rollback: restaurar DNS anterior e remover regra adicionada Validação: - dig api-pagamentos-prd-sp-02.intra... OK - nc -vz api-pagamentos-prd-sp-02 443 OK - curl /health via LB OK

Checklist de validação pós-configuração (IP, rota, DNS, portas, acesso remoto)

1) IP e interface

• Interface correta está ativa e com o IP esperado.
• Máscara/prefixo correto e sem IP duplicado na rede.
• MTU conforme padrão do ambiente (especialmente em VLANs específicas, VPNs e túneis).

ip -br addr

2) Roteamento

• Rota padrão aponta para o gateway correto.
• Rotas específicas (se existirem) estão presentes.
• Consegue alcançar o gateway e destinos essenciais (ex.: DNS, repositórios, monitoramento) conforme política.

ip route

3) DNS (interno e, se aplicável, externo)

• /etc/resolv.conf (ou configuração equivalente) aponta para os DNS corretos.
• Resolução do FQDN interno do servidor funciona.
• Resolução de dependências críticas funciona (banco, cache, APIs internas).
• Se necessário, reverse (PTR) está configurado e coerente.

cat /etc/resolv.conf dig +short $(hostname -f) dig -x <IP_DO_SERVIDOR> +short

4) Portas e firewall

• Serviço está escutando na porta correta e na interface esperada (não expor em 0.0.0.0 sem necessidade).
• Conectividade de entrada a partir das origens permitidas funciona.
• Conectividade de saída para dependências funciona (DNS/NTP/atualizações/serviços internos).

ss -lntup nc -vz -w 2 <destino> <porta>

5) Acesso remoto e operação

• Acesso administrativo funciona somente pelos caminhos previstos (VPN/bastion/VLAN de gerência).
• Monitoramento consegue coletar métricas e logs do servidor.
• Nome do servidor aparece corretamente em inventário/CMDB/SoT.

# Exemplo de teste de acesso (a partir do bastion) ssh <usuario>@<hostname_ou_ip>