Redes de Longa Distância

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade.

Objectivos

• Aplicar um método por etapas ao diagnóstico de uma ligação de longa distância (ligação local, próximo salto, caminho, serviço).
• Localizar perda num salto com mtr e distinguir perda real de limitação de respostas ICMP num encaminhador.
• Diagnosticar um problema de MTU (pedidos pequenos passam, transferências grandes param) e corrigi-lo com ajuste do MSS.

Método em quatro etapas

1) Ligação local: a interface está activa e tem endereço? 2) Próximo salto: o encaminhador do outro lado responde? 3) Caminho: onde se perde o tráfego (traceroute, mtr)? 4) Serviço: o protocolo concreto funciona (DNS, web, tamanho dos pacotes)? Registam-se hora, comando e resultado de cada etapa: é esse registo que se envia ao operador ao abrir avaria.

No mtr, perda que aparece num salto intermédio mas não nos seguintes significa normalmente que esse encaminhador limita as respostas ICMP, não que o tráfego se perde. Perda real aparece no salto onde começa e mantém-se até ao destino.

MTU: quando o ping funciona e a aplicação não

A MTU é o maior pacote que uma ligação transporta sem fragmentar (1500 bytes em Ethernet). Túneis e algumas ligações WAN reduzem-na (por exemplo WireGuard acrescenta cabeçalhos). Com a descoberta da MTU do caminho (RFC 1191), o emissor envia pacotes com «não fragmentar» e espera uma mensagem ICMP «fragmentation needed» se forem grandes demais. Se uma firewall no caminho bloquear essas mensagens ICMP, os pacotes grandes perdem-se sem aviso: o ping pequeno e o início da ligação passam, mas a página ou o ficheiro não chega.

Correcções: não bloquear as mensagens ICMP necessárias; e, no encaminhador da ligação reduzida, ajustar o MSS do TCP à MTU do caminho, para que as ligações TCP usem segmentos que cabem.

Caso fictício

Na DPE (fictícia) os utilizadores da delegação conseguem abrir a página inicial pequena do srv, mas o descarregamento de um relatório de 200 kB fica parado. O ping funciona. A ligação principal foi migrada para um operador cuja ligação tem MTU 1400, e um técnico bloqueou todo o ICMP no r1 «por segurança».

Prática guiada em rede isolada

Rede de prática fictícia, criada dentro de um computador de prática com o script base (módulo 1, lição 1). Nunca use estes passos na rede de produção nem contra endereços reais. As saídas mostradas são exemplos didácticos, não resultados de uma execução.

Topologia (descrição em texto)

• pc-adm (10.10.10.10) — ligado a r1 pela VLAN 10.
• srv (10.10.20.53) — ligado a r1 pela VLAN 20.
• r1 (encaminhador da sede) — ligado a pc-adm, srv, r2 e isp.
• r2 (encaminhador da delegação) — ligado a r1 e a pc-del (10.20.10.10).
• isp (operador simulado) — ligado a r1 e ao servidor externo 198.51.100.10 (endereço dentro de isp).
• Simulação: MTU 1400 na ligação r1–r2 (interfaces r1-r2 e r2-r1) e bloqueio de ICMP «fragmentation needed» numa tabela nft própria no r1 (m9mtu).

Passos

1. Prepare o cenário do caso (formador) e um ficheiro de 200 kB no srv.

   sudo ip -n r1 link set r1-r2 mtu 1400; sudo ip -n r2 link set r2-r1 mtu 1400
   sudo ip netns exec r1 nft add table inet m9mtu
   sudo ip netns exec r1 nft add chain inet m9mtu saida '{ type filter hook output priority 0; policy accept; }'
   sudo ip netns exec r1 nft add rule inet m9mtu saida icmp type destination-unreachable icmp code frag-needed counter drop
   mkdir -p /tmp/m9-web && head -c 200000 /dev/zero > /tmp/m9-web/relatorio.bin
   Consola C: sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53 --directory /tmp/m9-web

2. Etapas 1 e 2: interface e próximo salto a partir da delegação.

   sudo ip -n pc-del addr show pc-del-r2 | grep inet
   sudo ip netns exec pc-del ping -c 2 10.20.10.1
   sudo ip netns exec r2 ping -c 2 10.255.0.1

   Saída de exemplo (didáctica):

   inet 10.20.10.10/24 ...
   2 packets transmitted, 2 received
   2 packets transmitted, 2 received

3. Etapa 3: caminho com mtr (10 ciclos, relatório).

   sudo ip netns exec pc-del mtr -n -r -c 10 10.10.20.53

   Saída de exemplo (didáctica):

   HOST                Loss%  Snt  Avg
   1. 10.20.10.1         0.0%   10  0.1
   2. 10.255.0.1         0.0%   10  0.1
   3. 10.10.20.53        0.0%   10  0.1

4. Etapa 4: serviço. O ficheiro grande pára; teste o tamanho com «não fragmentar».

   sudo ip netns exec pc-del python3 -c "import urllib.request as u; print(len(u.urlopen('http://10.10.20.53/relatorio.bin', timeout=5).read()))"
   sudo ip netns exec srv ping -c 1 -W 1 -M do -s 1372 10.20.10.10
   sudo ip netns exec srv ping -c 1 -W 1 -M do -s 1472 10.20.10.10
   sudo ip netns exec r1 nft list chain inet m9mtu saida

   Saída de exemplo (didáctica):

   TimeoutError: timed out
   1 packets transmitted, 1 received  (1372 + 28 = 1400 bytes)
   1 packets transmitted, 0 received  (1500 bytes não passam e o aviso ICMP é descartado)
   ... counter packets 3 bytes ... drop

5. Correcção 1: deixe passar as mensagens ICMP necessárias (retire a regra errada).

   sudo ip netns exec r1 nft delete table inet m9mtu
   sudo ip netns exec srv ping -c 1 -W 1 -M do -s 1472 10.20.10.10

   Saída de exemplo (didáctica):

   ping: local error: message too long, mtu=1400  (o emissor passa a saber a MTU do caminho)

6. Correcção 2 (complementar): ajuste do MSS no r1 para as ligações TCP que atravessam a ligação reduzida; depois repita o descarregamento.

   sudo ip netns exec r1 nft add table inet m9mss
   sudo ip netns exec r1 nft add chain inet m9mss fwd '{ type filter hook forward priority 0; policy accept; }'
   sudo ip netns exec r1 nft add rule inet m9mss fwd oifname r1-r2 tcp flags syn tcp option maxseg size set rt mtu
   sudo ip netns exec pc-del python3 -c "import urllib.request as u; print(len(u.urlopen('http://10.10.20.53/relatorio.bin', timeout=5).read()))"

   Saída de exemplo (didáctica):

   200000

Critérios de sucesso

• A folha de diagnóstico tem as quatro etapas com hora, comando e resultado.
• A dupla explica porque o ping de 1372 bytes passa e o de 1472 não.
• Depois das correcções, o ficheiro de 200000 bytes chega completo.
• A dupla escreve a mensagem de abertura de avaria ao operador com os dados recolhidos.

Como desfazer (reversão)

• Ctrl+C na consola C.
• sudo ip netns exec r1 nft delete table inet m9mss; sudo ip netns exec r1 nft delete table inet m9mtu 2>/dev/null
• sudo ip -n r1 link set r1-r2 mtu 1500; sudo ip -n r2 link set r2-r1 mtu 1500
• rm -rf /tmp/m9-web
• Verificar: sudo ip netns exec r1 nft list tables não mostra m9mtu nem m9mss; ip -n r1 link show r1-r2 mostra mtu 1500.

Alternativa em papel: tarefas e respostas esperadas

Relatório mtr de exemplo: salto 2 (10.255.0.1) com 40 % de perda; salto 3 (destino) com 0 %. Há perda real?

Não no caminho: o destino recebe tudo. O salto 2 limita respostas ICMP dirigidas a ele. Perda real apareceria também nos saltos seguintes e no destino.

Outro relatório: salto 2 com 12 % e salto 3 com 12 %. Onde começa o problema e o que envia ao operador?

Começa entre o salto 1 e o salto 2 (a ligação WAN). Envia: hora, origem e destino, relatório mtr com 12 % a partir do salto 2, confirmação de que a rede local está sem perda, número de contrato.

Com as saídas do passo 4, explique o caso em três frases.

A ligação tem MTU 1400. Pacotes de 1500 bytes com «não fragmentar» não passam e o r1 descarta o aviso ICMP que diria ao emissor para reduzir. Pedidos pequenos passam; o ficheiro grande pára.

Porque bloquear todo o ICMP «por segurança» é mau desenho?

Algumas mensagens ICMP são necessárias ao funcionamento (descoberta da MTU, destino inalcançável). Filtra-se de forma selectiva, não por completo.

Verifique o que aprendeu

Questão 1

Num relatório mtr, só o salto intermédio mostra perda e o destino tem 0 %. O que significa normalmente?

1. O cabo está partido nesse salto
2. Esse encaminhador limita as respostas ICMP; o tráfego passa
3. O destino está em baixo
4. O DNS falhou

Questão 2

O ping funciona, a página pequena abre, mas ficheiros grandes param. Primeira hipótese?

1. Vírus no servidor
2. Problema de MTU com mensagens ICMP bloqueadas no caminho
3. Falta de licença
4. Endereço IP duplicado

Em leitura fácil

• Diagnostique por etapas: cabo, vizinho, caminho, serviço.
• Anote a hora e o resultado de cada teste.
• Se o ping funciona e os ficheiros grandes não, suspeite do tamanho dos pacotes.
• Não bloqueie todo o ICMP.

Fontes

• IETF RFC 792 — Internet Control Message Protocol (https://www.rfc-editor.org/rfc/rfc792)
• IETF RFC 791 — Internet Protocol (https://www.rfc-editor.org/rfc/rfc791)
• Linux iproute2 — páginas de manual ip(8), ip-netns(8), bridge(8), tc(8) (https://man7.org/linux/man-pages/man8/ip.8.html)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)
• Wireshark — User's Guide e referência de filtros de visualização (https://www.wireshark.org/docs/)