Os clientes VPN ligam mas não têm internet: três peças em falta

O cliente recebe um endereço, o servidor responde aos ping e, mesmo assim, cada página acaba por expirar. A maioria das pessoas começa a editar o perfil do cliente neste ponto, o que normalmente é esforço perdido: assim que o túnel está de pé, o servidor tem de se comportar como um router. Três condições têm de se verificar ao mesmo tempo antes de um pacote sair e voltar uma resposta, e o sintoma é idêntico seja qual for a que falta.

Porque é que um túnel a funcionar continua sem saída

O kernel tem de encaminhar pacotes entre interfaces, o que está desativado por predefinição na maioria das distribuições Linux. O tráfego tem de ser traduzido para um endereço a que o mundo exterior consiga responder, a menos que cada router a montante já conheça a rota de regresso à sub-rede do túnel. O caminho de encaminhamento da firewall tem de permitir o tráfego nos dois sentidos, incluindo as respostas.

Cada uma destas pode ser corrigida em separado, e é aí que está a armadilha. Ativar o encaminhamento sem uma regra de tradução deixa os pacotes a sair com uma origem privada e sem caminho de regresso. Acrescentar a tradução sem uma regra de encaminhamento deixa o kernel a descartar o pacote um passo depois.

Por isso teste as três camadas em vez do cliente, e mude uma de cada vez para que o resultado signifique algo.

O encaminhamento é um interruptor do kernel que tem de tornar permanente

Verifique o valor atual antes de o alterar, depois defina-o e confirme que a alteração produziu efeito.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

O primeiro comando indica o valor atual, o segundo define-o em tempo de execução e o terceiro prova que a escrita funcionou. O valor em tempo de execução desaparece no reinício seguinte, e é por isso que uma sessão a funcionar pode quebrar após manutenção sem qualquer alteração de configuração.

Torne-o permanente num ficheiro em /etc/sysctl.d/, e depois aplique esse ficheiro em vez de reiniciar para descobrir. No FreeBSD o equivalente é net.inet.ip.forwarding, com gateway_enable=YES em rc.conf para persistência. Um equipamento que reporta o encaminhamento desativado explica toda uma classe de relatos «os pacotes chegam e nada volta». Verifique a definição também após cada atualização, porque um kernel reconstruído ou uma imagem de equipamento substituída podem repô-la sem avisar ninguém.

Escolha masquerade ou um endereço de tradução fixo

Com um endereço exterior dinâmico, masquerading é a forma correta mais simples. Nomeie a sub-rede do túnel como origem e a interface exterior como saída.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Com um endereço público estático, a tradução de origem para esse endereço exato é mais previsível e mais fácil de auditar.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

A segunda forma traz uma armadilha de manutenção: um endereço codificado de forma rígida que depois muda mantém o túnel a funcionar enquanto o acesso à internet pára em silêncio. Ou usa masquerade ou atualiza a regra sempre que o fornecedor o mover. A interface também importa, porque um router que partilha o seu próprio túnel a montante tem de traduzir através desse túnel e não através da WAN física.

A tabela de filtros é a terceira porta

O encaminhamento e a tradução podem estar ambos corretos enquanto o pacote ainda morre na tabela de filtros. O ufw é um culpado frequente: a sua política de encaminhamento é entregue como DROP, e o resto da configuração pode parecer perfeitamente correta enquanto essa única definição mata o tráfego. Subi-la é uma decisão de segurança deliberada e não uma caixa de verificação.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

A primeira regra permite tráfego novo do túnel para fora, e a segunda apenas as respostas de volta. Restrinja ambas à sub-rede do túnel e ao destino pretendido, porque uma aceitação geral na interface do túnel transforma a VPN num ponto de saída aberto para quem consiga autenticar-se.

Um túnel em ponte precisa de outra resposta. O endereço pertence à ponte, não à porta física, por isso escravizar a interface remove o endereço que tinha antes e o anfitrião parece inalcançável até a própria ponte receber um, o que o dhclient br0 pode fornecer. Essa falha parece um problema de VPN e é um problema de camada dois. Verifique o endereço da própria ponte antes de tocar na firewall, porque uma alteração de filtro não pode reparar um anfitrião que já não tem endereço de onde enviar.

Onde olhar quando uma página nunca carrega

Faça ping ao endereço do túnel do servidor para provar que o túnel existe. Depois execute um traceroute do cliente para um endereço público e leia onde pára: no servidor o pacote chega mas não é encaminhado nem traduzido; para lá do servidor o problema está a montante e fora das suas mãos.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

O primeiro comando prova que o túnel transporta tráfego até ao próprio servidor, e o segundo mostra até onde um pacote chega para fora. Um traço que termina no endereço do túnel aponta para encaminhamento ou tradução no servidor, enquanto um traço que pára um salto depois aponta para o fornecedor ou para a rota de regresso do router a montante.

No servidor, observe a interface exterior enquanto um cliente carrega uma página. Tráfego que sai com um endereço de origem privado significa que falta tradução, e a ausência total de resposta significa que o caminho de encaminhamento ou a rota de regresso a montante o está a descartar.

Se os clientes remotos também tiverem de chegar a anfitriões na LAN do servidor, lembre-se de que a LAN precisa de uma rota de regresso à sub-rede do túnel. Isso é encaminhamento e não tradução, e é o passo que mais frequentemente se esquece quando o caminho para a internet finalmente funciona.