Programação Distribuída com Redes

Diagnóstico por evidências.

Por Fábio Linhares • Instituto Infnet

Estas questões não são um “questionário de teoria”. Elas são um teste de alfabetização operacional em redes no Linux: você vai ser puxado para fora da zona do “acho que é DNS” e colocado no território do “eu provo onde está o problema”. Ao longo dos exercícios, o desafio é sempre o mesmo, só muda a roupa: enxergar a rede em camadas, ler o estado real do sistema pelo terminal e tomar decisões com base em evidências.

Se você consegue resolver tudo daqui, você domina, no mínimo, as seguintes competências: pensar em camadas (TCP/IP e OSI) como um mapa de diagnóstico; entender endereçamento e roteamento em IPv4/IPv6 de forma prática; inspecionar e configurar DNS/hosts; controlar rotas e hostname de forma consciente; ler portas e conexões com ss; compreender DHCP como negociação; e, por fim, atravessar a fronteira para operar um Linux como roteador (encaminhamento, NAT e validação).

Talvez o ponto mais importante: disciplina de diagnóstico por evidências. Você não usa ferramentas (ping, traceroute/tracepath, dig/nslookup, ss, ip route, ip addr, tcpdump) como “comandos para decorar”, mas como instrumentos de investigação: hipótese → teste → evidência → próxima ação.

O objetivo não é “acertar um comando”: é conseguir justificar, com evidência, em qual camada está o problema.

Compatibilidade entre distribuicoes

• Este guia prioriza comandos portaveis entre Debian/Ubuntu, Arch e RHEL-like.

• Onde houver variacao real, a diferenca costuma estar no servico que gerencia rede/DNS/DHCP, nao no raciocinio tecnico.

• Exemplos: resolvectl depende de systemd-resolved; DHCP pode usar dhclient, dhcpcd ou NetworkManager.

• Regra pratica: preserve o metodo de diagnostico e adapte apenas a ferramenta local quando a distribuicao mudar.

Pre-voo por distribuicao

• Muitos destes pacotes ja existem em instalacoes padrao. Instale apenas o que faltar.

• Em RHEL-like atual, use dnf; em ambientes antigos, substitua por yum.

# Debian/Ubuntu
sudo apt install iproute2 iputils-ping traceroute dnsutils curl tcpdump network-manager isc-dhcp-client

# Arch
sudo pacman -S iproute2 iputils traceroute bind curl tcpdump networkmanager dhcpcd

# RHEL-like
sudo dnf install iproute iputils traceroute bind-utils curl tcpdump NetworkManager dhclient

BLOCO 01

Mapa mental: camadas, evidência e autonomia operacional

Objetivo: organizar pensamento em camadas e padronizar diagnóstico (sem achismo).

▼

Disciplina de troubleshooting (forma correta de pensar)

• Sintoma: “não abre site” não é diagnóstico; é ponto de partida.

• Pergunta certa: “qual camada tem evidência do problema?”

• Processo: hipótese → comando/teste → evidência → próxima ação.

Checklist de evidências por camada (exemplo: example.com)

Aplicação (nome → IP):
  dig +short A example.com
  dig +short AAAA example.com

Transporte (porta/handshake/HTTP):
  curl -I https://example.com

Internet (rota até o IP):
  ip route get <IP>

Acesso/Link (interface/estado físico):
  ip link show

Regra de ouro:
- Se falhar em uma camada, pare e explique por quê.
- Corrija de baixo para cima quando fizer sentido (link → rota → transporte → aplicação).

Checkpoint: você consegue escrever “onde eu começo e por quê” em 5 linhas, usando evidência real do sistema (saída dos comandos) e não opinião.

BLOCO 02

Camadas TCP/IP e o modelo OSI (mapeamento prático)

Objetivo: mapear protocolos às camadas e usar isso como ferramenta de diagnóstico.

▼

Parte 1 — TCP/IP em 4 camadas (Exercício 1)

1) Aplicação: protocolos usados diretamente por aplicações (ex.: HTTP/HTTPS).

2) Transporte: comunicação fim a fim entre processos via portas (ex.: TCP / UDP).

3) Internet: endereçamento e roteamento entre redes (ex.: IP).

4) Acesso à Rede (Link): entrega local no fio/ar (ex.: Ethernet / Wi‑Fi).

Parte 2 — OSI em 7 camadas (Exercício 2)

• OSI é mais detalhado/“acadêmico”; TCP/IP é o mapa operacional do mundo real.

• Mapeamento típico: TCP/IP Aplicação ≈ OSI Aplicação + Apresentação + Sessão.

• TCP/IP Transporte ≈ OSI Transporte; TCP/IP Internet ≈ OSI Rede; TCP/IP Link ≈ OSI Enlace + Física.

Validação por evidência (como usar camadas no diagnóstico)

- DNS falha → evidência na camada de Aplicação (resolução de nomes).
- TCP não conecta → evidência na camada de Transporte (porta, handshake).
- Rota inexistente → evidência na camada Internet (ip route).
- Link down / interface sem carrier → evidência na camada de Acesso/Link.

Pergunta-guia:
  “Qual evidência eu consigo coletar agora que confirma/nega a hipótese?”

Checkpoint: você consegue explicar por que “parece DNS” é hipótese e quais testes mínimos provam ou derrubam essa hipótese (dig / resolvectl / tentativa de conexão por IP).

BLOCO 03

IPv4/IPv6, tabela de rotas e leitura de interfaces

Objetivo: interpretar endereços, prefixos e rota padrão com ip.

▼

IPv4 e IPv6 (Exercício 3)

• IPv4: 32 bits, ex.: 192.168.1.10, prefixos CIDR como /24.

• IPv6: 128 bits, 8 grupos hex com :, compressão com :: (uma vez) e remoção de zeros à esquerda.

• Prática: IPv6 reduz dependência de NAT, favorece autoconfiguração (SLAAC) e redes modernas.

Tabela de rotas (Exercício 4)

• Ver rotas: ip route.

• Regra: prefixo mais específico vence; se empatar, métrica decide.

Endereços IPv6 por interface (Exercício 5)

• Ver IPv6: ip -6 addr show (ou ip -6 a).

• Ler escopo: scope link (link-local fe80::/10) vs scope global (global unicast).

Como ler uma rota (exemplo didático)

default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50 metric 100

Tradução:
- default: rota padrão (fora da LAN vai por aqui)
- via: próximo salto (gateway)
- dev: interface de saída
- proto: origem (dhcp/kernel)
- metric: custo (menor costuma vencer)
- scope link: alcançável direto no enlace
- src: IP fonte preferencial

Observação honesta: em um TP real, você deve entregar sua saída real (print/colagem) e sua leitura dela. Aqui está o modelo de leitura e os pontos que você precisa identificar.

BLOCO 04

DNS, /etc/hosts, rotas manuais e hostname

Objetivo: controlar resolução de nomes e identidade do host com responsabilidade.

▼

DNS e hosts (Exercícios 6 e 7)

• /etc/hosts: atalhos locais nome → IP (útil para lab e mapeamentos rápidos).

• /etc/resolv.conf: nameservers e search, mas pode ser gerenciado (ex.: systemd-resolved / NetworkManager).

• Validar DNS: dig +short A example.com / dig +short AAAA example.com (ou nslookup).

Rotas estáticas (Exercício 8)

• Adicionar: sudo ip route add 10.10.0.0/16 via 192.168.1.1 dev eth0.

• Remover: sudo ip route del 10.10.0.0/16.

• Validar caminho: ip route get 10.10.5.5.

Hostname (Exercício 9)

• Ver: hostname e hostnamectl.

• Temporário: sudo hostname novo-nome.

• Permanente: sudo hostnamectl set-hostname novo-nome.

Exemplos de configuração (didáticos)

/etc/hosts
  127.0.0.1   localhost
  192.168.1.10 servidorbd
  2001:db8::10 servidorv6

/etc/resolv.conf (se NÃO for gerenciado)
  nameserver 1.1.1.1
  nameserver 8.8.8.8
  search minhaempresa.local

Regra prática:
- Edite /etc/hosts sem medo.
- Entenda quem gerencia /etc/resolv.conf antes de editar (DHCP, NetworkManager, systemd-resolved).

Checkpoint: você consegue explicar “nome não resolve” separando: (a) arquivo local (/etc/hosts), (b) cliente DNS configurado (resolv.conf / resolved), (c) reachability até o servidor DNS (rota/firewall).

BLOCO 05

Portas, sockets com ss e DHCP (rede como mecanismo de aplicações)

Objetivo: ler conexões e entender serviços como multiplexação por portas.

▼

Portas TCP (Exercício 10)

• Porta TCP (0–65535) identifica um serviço/processo e permite multiplexação no mesmo IP.

• Portas padrão: 80/tcp (HTTP), 443/tcp (HTTPS), 22/tcp (SSH).

Inspecionar conexões com `ss` (Exercício 11)

• TCP básico: ss -t.

• Com UDP, nomes e processos: ss -tuna (pode exigir permissão para ver o processo).

• Leitura: State (LISTEN/ESTAB), filas (Recv-Q/Send-Q), endpoints (Local/Peer), Process.

DHCP como negociação (Exercícios 12 e 13)

• Fluxo DORA: Discover → Offer → Request → ACK.

• Com dhclient (comum em Debian/RHEL-like): liberar sudo dhclient -r eth0 e renovar sudo dhclient eth0.

• Com dhcpcd (comum em ambientes Arch): renovar via sudo dhcpcd -k eth0 e depois sudo dhcpcd eth0.

• Com NetworkManager: nmcli dev disconnect eth0 / nmcli dev connect eth0.

Exemplo didático de ss (como ler)

State   Recv-Q Send-Q Local Address:Port   Peer Address:Port   Process
ESTAB   0      0      192.168.1.50:22      192.168.1.100:53422 users:(("sshd",pid=1234,fd=3))
LISTEN  0      128    0.0.0.0:80           0.0.0.0:*          users:(("nginx",pid=900,fd=6))

Leitura rápida:
- LISTEN: serviço esperando conexão
- ESTAB: sessão estabelecida (conexão ativa)
- Filas crescendo: possível gargalo (app lenta, buffer, rede, backpressure)

Checkpoint: você consegue olhar um serviço “fora” e provar se ele está (a) sem processo escutando, (b) escutando mas bloqueado por firewall, ou (c) aceitando conexões mas falhando na aplicação.

BLOCO 06

Linux como roteador: encaminhamento, gateway padrão e ferramentas de evidência

Objetivo: configurar/validar forwarding e justificar mudanças com evidências e mínimo necessário.

▼

Linux como roteador (Exercício 14)

• Habilitar encaminhamento IPv4 (temporário): sudo sysctl -w net.ipv4.ip_forward=1.

• Permanente: /etc/sysctl.conf ou /etc/sysctl.d/*.conf com net.ipv4.ip_forward = 1.

• NAT/Firewall: iptables/nftables (a ideia é a mesma: forward + nat conforme topologia).

Gateway padrão (Exercício 15)

• Adicionar default: sudo ip route add default via 192.168.1.1 dev eth0.

• Trocar: remova e adicione (ex.: sudo ip route del default → sudo ip route add default ...).

• Validar: ip route e ip route get 8.8.8.8.

Ferramentas e o que revelam (Exercício 16)

• ping: reachability e latência (RTT); pode ser bloqueado e não garante serviço OK.

• traceroute / tracepath: caminho e onde o tráfego para; alguns hops não respondem.

• Complementos: dig (DNS), ss (sockets), tcpdump (evidência bruta do tráfego).

Exercício de consolidação (curto e bom)

Escolha um domínio (ex.: example.com) e produza 1 evidência por camada:

Aplicação:
  dig +short A example.com
  dig +short AAAA example.com

Transporte:
  curl -I https://example.com

Internet:
  ip route get <IP retornado pelo dig>

Acesso/Link:
  ip link show

Depois escreva em 5 linhas:
  “Se falhar, onde eu começo e por quê.”

Debrief:
Você não decorou comandos; você aprendeu a mapear sintomas em camadas,
coletar evidência e decidir o próximo teste. Isso é a base de redes e também
de sistemas distribuídos (falhas parciais são regra).

Quando você configurar algo (rota, DNS, forward), sempre anote: hipótese → mudança → comando de validação → evidência (saída).