Redes de Computadores para Administração de Servidores: mapa mental dos conceitos essenciais

O que é “uma rede” no contexto de servidores

Para administrar servidores, pense em rede como o conjunto de caminhos e regras que permitem que processos (serviços) em máquinas diferentes troquem dados com previsibilidade. Na prática, você vai lidar com três perguntas o tempo todo: quem precisa falar com quem, por onde esse tráfego passa e o que pode ou não pode atravessar (políticas).

Um jeito útil de visualizar é separar em camadas de “peças” (componentes) e “fluxos” (tipos de tráfego). Abaixo está um mapa mental em forma de lista para você consultar no dia a dia.

Componentes essenciais (e como aparecem no trabalho)

Host (servidor/cliente)

É qualquer máquina que envia/recebe tráfego: servidor Linux, VM, container host, notebook do admin, instância na nuvem. No host vivem os serviços (ex.: SSH, Nginx, PostgreSQL) e as regras locais (ex.: firewall do sistema operacional).

• No dia a dia: você testa conectividade a partir do host (ping, curl, ssh), verifica rotas, DNS, portas em escuta e logs do serviço.

NIC (placa/interface de rede)

É a interface que conecta o host à rede (física ou virtual). Pode ser eth0, ens192, enp0s3, ou interfaces virtuais (vNIC em VM, interface de bridge, etc.).

• No dia a dia: link up/down, velocidade/duplex, VLAN tagging, múltiplas NICs (rede de gestão vs rede de dados), bonding/teaming.

Switch

Conecta vários dispositivos na mesma rede local (LAN). Ele encaminha quadros dentro do mesmo domínio de camada 2. Em ambientes gerenciados, também segmenta via VLAN.

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

• No dia a dia: porta errada, VLAN incorreta, loop, porta bloqueada, MAC aprendida no lugar errado, uplink para roteador/firewall.

Roteador

Conecta redes diferentes (sub-redes). É quem decide o próximo salto para alcançar um IP fora da rede local. Em muitos ambientes, o “roteador” pode ser um firewall, um appliance, ou um roteador virtual na nuvem.

• No dia a dia: gateway padrão do servidor, rotas estáticas, múltiplos caminhos, redes internas e externas.

Firewall

Aplica políticas: permite ou bloqueia tráfego com base em origem, destino, porta, protocolo e estado da conexão. Pode existir em vários pontos: no host (host firewall), na borda (perímetro) e entre segmentos internos (microsegmentação).

• No dia a dia: “funciona de dentro, não funciona de fora”, portas publicadas, regras de entrada/saída, NAT, logs de bloqueio.

Modem/ONT (acesso ao provedor)

É o equipamento que termina o link do provedor (cabo, fibra). Em fibra, o ONT faz a conversão do meio e entrega Ethernet para o roteador/firewall. Muitas vezes o equipamento do provedor também faz roteamento/NAT (o que pode complicar publicações).

• No dia a dia: IP público vs privado, CGNAT, modo bridge, queda intermitente do link, latência.

AP (Access Point / Wi‑Fi)

Conecta clientes sem fio à LAN. Pode ser doméstico (roteador Wi‑Fi) ou corporativo (APs gerenciados). Para administração de servidores, Wi‑Fi costuma ser “o caminho do seu notebook” até a rede, não o caminho ideal para servidores.

• No dia a dia: SSID em VLAN errada, isolamento de clientes, roaming, perda de pacotes.

Tipos de tráfego que você precisa reconhecer

Cliente-servidor

Um cliente inicia uma conexão para um serviço no servidor (ex.: seu notebook → SSH no servidor; navegador → site). É o padrão mais comum.

• Exemplo: admin-laptop → 10.0.10.20:22 (SSH)
• Ponto de atenção: a porta do serviço e o firewall no caminho.

Norte-sul (north-south)

Tráfego que entra ou sai do ambiente (internet ↔ rede interna). Normalmente atravessa borda: roteador/firewall, NAT, WAF, balanceador.

• Exemplo: internet → IP público → firewall/NAT → servidor web interno.
• Ponto de atenção: publicação de portas, NAT, regras de entrada, TLS, logs na borda.

Leste-oeste (east-west)

Tráfego dentro do ambiente (entre servidores e serviços internos). Em data center e nuvem, costuma ser a maior parte do tráfego: app ↔ banco, app ↔ cache, serviços entre si.

• Exemplo: app01 → db01:5432 (PostgreSQL)
• Ponto de atenção: segmentação interna (VLANs/sub-redes), firewalls internos, security groups, DNS interno.

Domínios de broadcast e colisão (conceito prático)

Domínio de broadcast

É o “alcance” de mensagens que são enviadas para todos na rede local (broadcast). Em geral, uma VLAN/sub-rede define um limite prático: broadcasts não atravessam roteadores.

• Por que importa: quanto maior o domínio, mais ruído e mais risco de impacto (ex.: tempestade de broadcast, ARP em excesso).
• No dia a dia: segmentar redes (ex.: gestão, servidores, usuários) reduz impacto e melhora segurança.

Domínio de colisão

É um conceito ligado a Ethernet antiga/hubs e meios compartilhados: quando dois dispositivos transmitem ao mesmo tempo, ocorre colisão. Em redes modernas com switches full-duplex, colisões praticamente não são um problema no cabeamento comutado.

• Por que ainda aparece: para entender por que hubs e meios compartilhados degradam desempenho e por que links full-duplex com switch são o padrão.
• No dia a dia: se você vê “colisões” em métricas modernas, geralmente é sintoma de duplex mismatch ou problema físico/negociação.

Como esses elementos aparecem em tarefas comuns

Acesso SSH a um servidor

Você (cliente) inicia uma conexão TCP para a porta 22 do servidor. No caminho, podem existir: Wi‑Fi/AP, switch, roteador, firewall, VPN, e o firewall do próprio host.

Checklist mental: seu notebook resolve o nome? alcança o IP? existe rota? a porta 22 está liberada? o serviço SSH está em escuta?

Publicação de um serviço web

Usuários externos acessam um domínio que aponta para um IP público. Esse tráfego entra (norte-sul), passa por borda (firewall/NAT e/ou balanceador) e chega ao servidor web (porta 80/443) ou a um proxy reverso.

Checklist mental: DNS público aponta para o IP certo? o IP é realmente público? há CGNAT? NAT/port-forward está correto? firewall permite 80/443? o serviço responde localmente?

Integração com banco de dados

Aplicação e banco geralmente conversam internamente (leste-oeste). O caminho pode ser curto (mesma VLAN) ou atravessar roteamento interno e firewalls entre segmentos.

Checklist mental: a aplicação resolve o hostname do banco? alcança o IP? a porta do banco está liberada (ex.: 5432, 3306)? o banco aceita conexões daquela rede/usuário? há regras de saída bloqueando?

Topologias comuns (modelos para reconhecer rapidamente)

1) Doméstica (laboratório/estudo)

Formato típico: ISP → modem/ONT → roteador Wi‑Fi (NAT + firewall) → dispositivos (PC, notebook, servidor caseiro).

• Características: uma única LAN, pouca segmentação, NAT na borda.
• Problemas comuns: dupla NAT (modem roteando + roteador roteando), CGNAT impedindo acesso externo, Wi‑Fi instável.

2) Pequena empresa

Formato típico: ISP → firewall/UTM → switch gerenciável → VLANs (usuários, servidores, convidados) → APs.

• Características: segmentação básica, regras entre VLANs, às vezes VPN para acesso remoto.
• Problemas comuns: VLAN trunk/access mal configurado, regras inter-VLAN bloqueando app↔db, DNS interno inconsistente.

3) Data center (on-premises)

Formato típico: borda (firewalls/roteadores) → core/distribution switches → racks (ToR switches) → servidores. Pode haver rede separada de gestão (OOB), storage, e redes de overlay/virtualização.

• Características: múltiplos caminhos, alta disponibilidade, segmentação forte, tráfego leste-oeste intenso.
• Problemas comuns: ACLs internas, assimetria de rotas, MTU inconsistente (especialmente com overlays), dependência de DNS/serviços internos.

4) Nuvem (IaaS)

Formato típico: VPC/VNet com sub-redes (públicas/privadas), tabelas de rotas, gateways (internet/NAT/VPN), security groups/NACLs, load balancer, instâncias.

• Características: “switch/roteador/firewall” viram recursos lógicos: rotas e regras são configuradas por políticas.
• Problemas comuns: rota faltando para internet/NAT, security group sem porta liberada, DNS privado vs público, IP público associado ao recurso errado.

Passo a passo prático: diagnosticar conectividade (checklist operacional)

Use este roteiro sempre que “não conecta”. A ideia é transformar o problema em perguntas objetivas e verificáveis.

1) Defina o fluxo: quem fala com quem

• Origem: qual host/processo está iniciando a conexão?
• Destino: qual serviço você quer atingir?
• Direção: é cliente-servidor, norte-sul ou leste-oeste?

2) Confirme identidade do destino: DNS e IP

• Você está usando nome ou IP?
• O nome resolve para o IP esperado?
• O IP é da rede correta (interna vs pública)?

# Exemplo (Linux): ver resolução DNS e IPs retornados
getent hosts api.interno.local

# Ver o caminho de resolução (se aplicável)
resolvectl query api.interno.local

3) Verifique o caminho: por qual rota o tráfego vai

• Existe rota até a rede do destino?
• O gateway padrão está correto?
• Há VPN envolvida?

# Ver rota até um IP
ip route get 10.0.20.15

# Ver tabela de rotas
ip route

4) Verifique a “porta”: qual serviço e qual protocolo

• Qual porta TCP/UDP o serviço usa?
• O serviço está em escuta no servidor?

# No servidor de destino: verificar portas em escuta
ss -lntup

# Testar conexão TCP a partir da origem
nc -vz 10.0.20.15 5432

# Testar HTTP/HTTPS
curl -v http://10.0.10.20:80/
curl -vk https://exemplo.com:443/

5) Procure bloqueios: firewalls no host e no caminho

• Firewall do host de origem bloqueia saída?
• Firewall do host de destino bloqueia entrada?
• Firewall/ACL entre redes bloqueia?

# Exemplos de verificação (varia por distro/configuração)
# Ver regras (iptables/nftables podem estar em uso)
iptables -S
nft list ruleset

6) Valide se o problema é rede ou aplicação

• Se a porta conecta mas a aplicação falha, o problema pode ser autenticação, TLS, configuração do serviço, permissões.
• Se nem a porta conecta, foque em rota/firewall/DNS.

# Exemplo: porta 443 abre, mas HTTP retorna erro
curl -vk https://api.interno.local/health

7) Mapeie “onde quebra” com testes incrementais

• Teste do próprio servidor para ele mesmo (loopback).
• Teste de um host na mesma rede do servidor.
• Teste de uma rede diferente (atravessando roteador/firewall).
• Teste de fora (internet), se for publicação.

# No servidor: testar localmente
curl -v http://127.0.0.1:8080/

# Testar IP da interface do servidor
curl -v http://10.0.10.20:8080/

Mapa mental rápido (resumo em tabela para consulta)