Redes de Longa Distância

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Serviços de rede: DHCP, DNS, VPN, NAT, VLAN e autenticação; Protecção de dados e identidades: MFA e cifra.

Objectivos

• Explicar o que uma rede privada virtual (VPN) protege e o que não protege numa ligação que atravessa o operador.
• Comparar IPsec e WireGuard quanto a normas, configuração e compatibilidade entre fabricantes.
• Configurar um túnel WireGuard entre sede e delegação e provar, por captura, que o tráfego interno segue cifrado.

Um túnel cifrado por cima de um caminho que não controlamos

Quando a ligação sede–delegação passa pelo operador ou pela Internet, quem estiver no caminho pode ler ou alterar pacotes não protegidos. Uma VPN entre locais (site-to-site) encapsula os pacotes internos dentro de pacotes cifrados e autenticados entre os dois encaminhadores. O conteúdo e os endereços internos deixam de ser visíveis no caminho; continuam visíveis os endereços das pontas do túnel, o volume e a hora do tráfego.

A VPN não substitui a firewall nem a segurança dos postos: um computador infectado na delegação continua a chegar à sede, agora por um canal cifrado. Por isso filtra-se também o que pode entrar pelo túnel.

IPsec e WireGuard

IPsec é uma arquitectura normalizada pelo IETF (RFC 4301), suportada pela generalidade dos encaminhadores e firewalls de fabricantes; tem muitas opções (IKEv2, algoritmos, modos), o que dá flexibilidade mas exige que as duas pontas acordem exactamente os mesmos parâmetros. É a escolha habitual quando uma ponta é equipamento de outro fabricante ou do operador.

WireGuard usa um conjunto fixo de algoritmos modernos e chaves públicas trocadas entre as pontas, com configuração curta; está incluído no núcleo Linux desde a versão 5.6. Não é, até à data da consulta, uma norma IETF, e o suporte em equipamentos de fabricantes varia: confirma-se na documentação do equipamento concreto. Em ambos os casos, as chaves privadas nunca saem do equipamento e as recomendações de algoritmos seguem orientações oficiais actualizadas (NIST SP 800-77 para IPsec).

Caso fictício

Na DPE (fictícia) a ligação r1–r2 passa a ser fornecida por um operador externo. A direcção pede garantia de que os documentos trocados entre a delegação e o servidor srv não possam ser lidos no caminho. O técnico propõe um túnel WireGuard entre r1 e r2, com endereços de túnel 10.255.2.1 e 10.255.2.2.

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).
• Caminho do operador (não confiável): r1 10.255.0.1 — r2 10.255.0.2.
• Túnel wg0: r1 10.255.2.1/30 (porta UDP 51820) — r2 10.255.2.2/30.
• Depois da prática: 10.20.10.0/24 e 10.10.0.0/16 passam pelo wg0 em vez do caminho directo.

Passos

1. Pré-verificação: o módulo wireguard existe e wg0 não está em uso nos dois encaminhadores.

   sudo modprobe wireguard && echo modulo-ok
   sudo ip -n r1 link show wg0 2>/dev/null && echo 'wg0 JA EXISTE em r1: parar'
   sudo ip -n r2 link show wg0 2>/dev/null && echo 'wg0 JA EXISTE em r2: parar'

   Saída de exemplo (didáctica):

   modulo-ok
   (nenhuma outra linha: pode continuar)

2. Consola A: capture no caminho do operador antes do túnel e gere um pedido do pc-del ao srv (ver o texto em claro).

   Consola C: sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53
   Consola A: sudo ip netns exec r2 tcpdump -ni r2-r1 -A 'tcp port 80'  (esperar «listening on r2-r1»)
   Consola B: sudo ip netns exec pc-del python3 -c "import urllib.request as u; u.urlopen('http://10.10.20.53/').read()"
   Ctrl+C na consola A.

   Saída de exemplo (didáctica):

   IP 10.20.10.10.51022 > 10.10.20.53.80: Flags [P.] ... GET / HTTP/1.1
   (o pedido é legível no caminho do operador)

3. Gere as chaves (em /tmp da máquina de prática, só leitura do root).

   sudo sh -c 'umask 077; wg genkey | tee /tmp/m9-r1.key | wg pubkey > /tmp/m9-r1.pub'
   sudo sh -c 'umask 077; wg genkey | tee /tmp/m9-r2.key | wg pubkey > /tmp/m9-r2.pub'

4. Crie o túnel nas duas pontas.

   sudo ip -n r1 link add wg0 type wireguard
   sudo ip netns exec r1 wg set wg0 listen-port 51820 private-key /tmp/m9-r1.key peer $(sudo cat /tmp/m9-r2.pub) endpoint 10.255.0.2:51820 allowed-ips 10.255.2.2/32,10.20.10.0/24
   sudo ip -n r1 addr add 10.255.2.1/30 dev wg0 && sudo ip -n r1 link set wg0 up
   sudo ip -n r2 link add wg0 type wireguard
   sudo ip netns exec r2 wg set wg0 listen-port 51820 private-key /tmp/m9-r2.key peer $(sudo cat /tmp/m9-r1.pub) endpoint 10.255.0.1:51820 allowed-ips 10.255.2.1/32,10.10.0.0/16
   sudo ip -n r2 addr add 10.255.2.2/30 dev wg0 && sudo ip -n r2 link set wg0 up

5. Desvie as rotas internas para o túnel.

   sudo ip -n r1 route replace 10.20.10.0/24 via 10.255.2.2 dev wg0
   sudo ip -n r2 route replace 10.10.0.0/16 via 10.255.2.1 dev wg0
   sudo ip netns exec pc-del traceroute -n 10.10.20.53

   Saída de exemplo (didáctica):

    1  10.20.10.1  0.05 ms
    2  10.255.2.1  0.40 ms
    3  10.10.20.53  0.45 ms

6. Repita a captura no caminho do operador e o mesmo pedido.

   Consola A: sudo ip netns exec r2 tcpdump -ni r2-r1 'udp port 51820 or tcp port 80'
   Consola B: repetir o pedido do pc-del.
   sudo ip netns exec r1 wg show wg0 latest-handshakes

   Saída de exemplo (didáctica):

   IP 10.255.0.2.51820 > 10.255.0.1.51820: UDP, length 128
   IP 10.255.0.1.51820 > 10.255.0.2.51820: UDP, length 96
   (nenhuma linha tcp port 80 no caminho do operador)
   (chave pública de r2)	1759055000

Critérios de sucesso

• Antes do túnel, o pedido HTTP é legível no caminho; depois, só aparecem pacotes UDP 51820 entre 10.255.0.1 e 10.255.0.2.
• O traceroute mostra 10.255.2.1 como segundo salto.
• O formando indica o que continua visível ao operador (endereços das pontas, volume, hora).

Como desfazer (reversão)

• sudo ip -n r1 route replace 10.20.10.0/24 via 10.255.0.2
• sudo ip -n r2 route replace 10.10.0.0/16 via 10.255.0.1
• sudo ip -n r1 link del wg0; sudo ip -n r2 link del wg0
• sudo rm -f /tmp/m9-r1.key /tmp/m9-r1.pub /tmp/m9-r2.key /tmp/m9-r2.pub
• Ctrl+C nas consolas A e C. Verificar: sudo ip netns exec pc-del traceroute -n 10.10.20.53 volta a mostrar 10.255.0.1 no segundo salto.

Alternativa em papel: tarefas e respostas esperadas

Compare as duas capturas de exemplo: o que via o operador antes e depois do túnel?

Antes: endereços internos 10.20.10.10 e 10.10.20.53, porta 80 e o texto «GET / HTTP/1.1». Depois: só UDP 51820 entre 10.255.0.2 e 10.255.0.1, com tamanhos e horas; o conteúdo e os endereços internos deixam de ser visíveis.

Na linha allowed-ips do r1 está 10.255.2.2/32,10.20.10.0/24. Explique o que acontece se faltar 10.20.10.0/24.

O WireGuard não aceita pacotes vindos do túnel com origem na delegação nem envia para lá tráfego destinado a 10.20.10.0/24: a delegação deixa de chegar à sede pelo túnel, embora o aperto de mão possa existir.

A delegação vai ligar-se a um encaminhador de outro fabricante que só suporta IPsec. Que muda na proposta?

Usar IPsec com IKEv2, acordando os mesmos parâmetros nas duas pontas, com base na documentação do equipamento e em NIST SP 800-77; o princípio (túnel cifrado entre locais e filtragem do que entra) mantém-se.

Verifique o que aprendeu

Questão 1

Com um túnel VPN entre sede e delegação, o que o operador ainda consegue ver?

1. O conteúdo dos documentos
2. Os endereços internos dos postos
3. Os endereços públicos das pontas, o volume e a hora do tráfego
4. Nada, o tráfego fica invisível

Questão 2

Um posto infectado na delegação liga-se à sede pela VPN. A VPN impede o ataque?

1. Sim, porque o tráfego é cifrado
2. Não; a VPN protege o caminho, não os postos — é preciso filtrar e proteger os equipamentos
3. Sim, se for IPsec
4. Sim, se a chave for longa

Em leitura fácil

• Uma VPN é um túnel fechado por cima do caminho do operador.
• Quem está no caminho não consegue ler o que vai dentro do túnel.
• A VPN não limpa um computador infectado.
• As chaves secretas nunca saem do equipamento.

Fontes

• WireGuard — documentação e wg(8) (https://www.wireguard.com/quickstart/)
• IETF RFC 4301 — Security Architecture for the Internet Protocol (IPsec) (https://www.rfc-editor.org/rfc/rfc4301)
• NIST SP 800-77 Rev. 1 — Guide to IPsec VPNs (https://csrc.nist.gov/pubs/sp/800/77/r1/final)
• 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)
• tcpdump/libpcap — manual tcpdump(1) e pcap-filter(7) (https://www.tcpdump.org/manpages/)