Dia 12: VPNs — WireGuard, OpenVPN, IPsec e Túneis Site-to-Site

As VPNs (Virtual Private Networks) são a espinha dorsal da conectividade segura entre redes dispersas. Seja para ligar dois escritórios através da Internet pública, permitir que um colaborador aceda à rede corporativa a partir de casa, ou garantir privacidade num café Wi-Fi, uma VPN cria um túnel encriptado que protege os dados em trânsito. Neste 12.º dia do curso de redes, exploramos as três tecnologias dominantes — WireGuard, OpenVPN e IPsec — com configurações práticas e uma comparação directa.

Neste artigo

1. Introdução às VPNs

Uma VPN cria um túnel encriptado entre dois pontos, de forma que os dados que viajam entre eles são ilegíveis para terceiros. Em vez de enviar pacotes directamente pela rede pública, a VPN encapsula-os dentro de pacotes encriptados — o conteúdo original fica oculto, e os routers intermédios apenas vêem o tráfego externo.

Existem dois modos de utilização principais:

  • Remote Access — um dispositivo individual (portátil, telemóvel) liga-se a uma rede remota, como se estivesse fisicamente nela. É o cenário do teletrabalho.
  • Site-to-Site — duas redes inteiras são interligadas através de um túnel. Um escritório em Lisboa e outro no Porto comunicam como se fossem uma só rede.

As três tecnologias que cobrimos hoje representam abordagens diferentes ao mesmo problema. WireGuard aposta na simplicidade e performance. OpenVPN é o padrão de facto em Linux, robusto e flexível. IPsec é o padrão IETF, presente em praticamente todos os routers e firewalls corporativos.

ℹ O WireGuard usa criptografia moderna (ChaCha20, Poly1305) e tem apenas 4.000 linhas de código — muito mais simples de auditar que o OpenVPN (100.000+ linhas).

2. WireGuard — O Moderno

WireGuard é a tecnologia mais recente das três, incluída no kernel Linux desde a versão 5.6 (2020). Foi desenhada para ser minimalista, rápida e fácil de configurar. A filosofia é simples: menos código, menos superfície de ataque, menos opções de configuração errada.

A configuração baseia-se em pares de chaves públicas e privadas — não há certificados X.509, não há algoritmos negociáveis. O WireGuard fixa um conjunto criptográfico moderno e seguro, eliminando a possibilidade de rebaixamento.

A configuração de um servidor WireGuard resume-se a um ficheiro de texto:

# Instalar WireGuard
apt install wireguard
# Gerar chaves
wg genkey | tee privatekey | wg pubkey > publickey
# Configurar servidor (/etc/wireguard/wg0.conf)
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <chave_privada_servidor>
[Peer]
PublicKey = <chave_publica_cliente>
AllowedIPs = 10.0.0.2/32
# Activar interface
wg-quick up wg0
# Verificar túnel
wg show

O conceito de AllowedIPs é central no WireGuard: define que endereços IP podem passar pelo túnel. No servidor, restringe cada peer a um IP específico (/32). No cliente, define que tráfego é enviado pelo túnel — usar 0.0.0.0/0 encaminha tudo.

Principais vantagens do WireGuard:

  • Performance — ChaCha20 é mais rápido que AES em hardware sem aceleração dedicada.
  • Latência baixa — handshake em 1-RTT, itinerância entre redes sem reiniciar túnel.
  • Configuração trivial — um ficheiro de 10 linhas, sem certificados.
  • Stealth — sem resposta a pacotes não autenticados, impossível detectar portas abertas com nmap.

3. OpenVPN — O Clássico

OpenVPN existe desde 2001 e é a VPN de código aberto mais utilizada no mundo Linux. Baseia-se em SSL/TLS para a autenticação e encriptação, usando certificados X.509 e chaves RSA/ECC. É flexível, mas essa flexibilidade traz complexidade — há dezenas de opções de configuração.

Uma configuração típica de servidor OpenVPN:

# OpenVPN — configurar servidor
# /etc/openvpn/server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
server 10.8.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
# Iniciar OpenVPN
systemctl start openvpn@server

O OpenVPN suporta dois modos: tun (túnel IP, camada 3) e tap (ponte Ethernet, camada 2). O modo tun é o mais comum para acesso remoto. O modo tap permite ponte de difusão, útil em cenários específicos como Wake-on-LAN.

A directiva push "route ..." envia rotas para o cliente, permitindo que este aceda a sub-redes atrás do servidor. Para encaminhar todo o tráfego, usa-se push "redirect-gateway def1".

4. IPsec — O Padrão Corporativo

IPsec (Internet Protocol Security) é um conjunto de protocolos padronizados pela IETF (RFC 4301 e seguintes). Ao contrário do WireGuard e OpenVPN, que operam na camada de aplicação/túnel, o IPsec opera na camada de rede (camada 3 do modelo OSI), o que o torna transparente para aplicações.

O IPsec tem dois modos: Transport (encripta apenas a carga útil do IP) e Tunnel (encripta o pacote inteiro, encapsulando-o num novo IP). Em VPNs site-to-site, usa-se sempre o modo Tunnel.

No Linux, a implementação mais comum é o strongSwan. A configuração de um túnel site-to-site:

# IPsec — strongSwan
# /etc/ipsec.conf
conn site-to-site
    left=203.0.113.1
    leftsubnet=192.168.1.0/24
    right=198.51.100.1
    rightsubnet=192.168.2.0/24
    authby=secret
    auto=start

O IPsec negocia dois parâmetros em fases distintas: IKE (Internet Key Exchange) para estabelecer a associação de segurança, e ESP (Encapsulating Security Payload) para a encriptação dos dados. A autenticação pode ser por chave partilhada (PSK) ou certificados.

O IPsec é a tecnologia nativa em routers e firewalls comerciais (Cisco, Fortinet, pfSense, OPNsense). Quase todo o equipamento empresarial suporta IPsec, tornando-o a escolha natural para interoperabilidade entre fabricantes.

5. Túneis Site-to-Site

Um túnel site-to-site liga duas redes locais através da Internet, como se fossem uma só rede. É o cenário típico de empresas com múltiplos escritórios, ou de centros de dados que precisam de comunicar de forma segura.

Os componentes de um túnel site-to-site são:

  • Gateway local (left) — o router/firewall na rede A, com IP público e acesso à sub-rede interna.
  • Gateway remoto (right) — o router/firewall na rede B, com IP público e acesso à sub-rede remota.
  • Sub-redes — as redes internas que comunicam através do túnel (ex: 192.168.1.0/24 e 192.168.2.0/24).
  • Tráfego — apenas os pacotes entre as sub-redes definidas são encriptados; o resto do tráfego de Internet não passa pelo túnel.

A escolha de tecnologia para site-to-site depende do equipamento. Entre dois routers Linux, WireGuard é a opção mais simples. Entre um router Cisco e um firewall Fortinet, IPsec é a única opção interoperável. OpenVPN também suporta site-to-site, mas é menos eficiente que IPsec para alto débito.

ℹ Em túneis site-to-site, usar sub-redes diferentes em cada lado. Se ambos usarem 192.168.1.0/24, o tráfego não encaminha correctamente — é o erro mais comum na configuração.

⚠ Uma VPN sem firewall correcto expõe a rede interna — sempre restringir acesso através do túnel com regras de firewall.

6. Comparação WireGuard vs OpenVPN vs IPsec

A tabela seguinte resume as diferenças principais entre as três tecnologias:

Característica WireGuard OpenVPN IPsec
Linhas de código ~4.000 ~100.000 ~500.000+
Criptografia ChaCha20, Poly1305 AES, OpenSSL AES, ChaCha20
Autenticação Chaves públicas Certificados X.509 PSK ou certificados
Porta padrão 51820 UDP 1194 UDP/TCP 500/4500 UDP
Performance Excelente Boa Excelente (hardware)
Configuração Muito simples Complexa Complexa
Interoperabilidade Limitada Boa Universal
Roaming Nativo Limitado MOBIKE (opcional)
Espaço do núcleo Sim (nativo) Não (espaço de utilizador) Sim (nativo)

Em resumo: WireGuard para simplicidade e performance entre sistemas modernos. OpenVPN quando se precisa de flexibilidade e compatibilidade com clientes diversos (Windows, macOS, Android). IPsec para interoperabilidade com equipamento de rede empresarial.

7. Erros Comuns e Lista de Verificação

A configuração de VPNs é propensa a erros que impedem o funcionamento ou comprometem a segurança. Os mais frequentes:

  • Sub-redes sobrepostas — se ambos os lados usam a mesma sub-rede (ex: 192.168.1.0/24), o tráfego não encaminha. Usar sub-redes distintas.
  • IP forwarding desactivado — sem net.ipv4.ip_forward=1 no sysctl, o Linux não encaminha pacotes entre interfaces.
  • Firewall bloqueia portas — 51820/UDP (WireGuard), 1194/UDP (OpenVPN), 500 e 4500/UDP (IPsec) devem estar abertas.
  • MTU incorrecto — túneis adicionam sobrecarga. Se o MTU for demasiado alto, pacotes grandes são descartados. Usar MSS clamping ou reduzir MTU para 1400.
  • Chaves trocadas — no WireGuard, a chave privada vai na interface e a pública no peer. Inverter impede a ligação.
  • NAT traversal — IPsec por trás de NAT requer NAT-T (porta 4500). Sem isso, o túnel não estabelece.

Lista de verificação antes de colocar uma VPN em produção:

  • ✓ Sub-redes diferentes em cada lado do túnel
  • ✓ IP forwarding activado no gateway (sysctl net.ipv4.ip_forward=1)
  • ✓ Portas UDP abertas no firewall (51820, 1194, 500, 4500)
  • ✓ Chaves privadas protegidas (permissões 600)
  • ✓ MTU/MSS configurado para evitar fragmentação
  • ✓ Firewall restringe acesso através do túnel (não abrir tudo)
  • ✓ Monitorização do estado do túnel (alertas se cair)
  • ✓ Cópia de segurança das configurações e chaves em local seguro
  • ✓ Teste de comutação pós-falha (o que acontece se o túnel cair?)

As VPNs são infra-estrutura crítica — um túnel em baixo significa utilizadores sem acesso. Documentar a configuração, testar a recuperação e monitorizar activamente são tão importantes como a própria encriptação.

No Dia 11 abordámos firewalls e Netfilter — a base de segurança que protege os túneis VPN. No Dia 20 do curso Linux voltaremos às VPNs com configuração prática passo-a-passo no terminal.

Continue o curso no próximo artigo, onde exploramos DNS em profundidade — resolução de nomes, tipos de registo e configuração de servidores.