O handshake do PiVPN funciona, mas as páginas travam: verifique a MASQUERADE

O telemóvel mostra o túnel como ligado, o cliente comunica um endereço privado, e a primeira página continua presa a meio do carregamento. Essa combinação envia a maioria das pessoas para as definições de cifra e para a temperatura do processador, onde na realidade nada está errado. O túnel subiu, portanto a negociação terminou; o que falhou é o passo seguinte, quando o servidor tenta entregar os pacotes do cliente à internet. Siga o mesmo caminho que esses pacotes fazem, e a discrepância costuma ver-se numa linha da tabela NAT.

Comece pelo que o cliente consegue e não consegue alcançar

A partir do cliente ligado, carregue uma página que viva na internet pública e repare se falha de imediato ou encrava a meio. Depois abra um recurso no endereço privado do próprio servidor VPN e compare os dois resultados.

Um endereço de túnel que responde a ping enquanto os sites públicos esgotam o tempo é o sinal de um problema de reencaminhamento ou de tradução, não de um handshake quebrado. O painel de estado do próprio cliente não consegue distingui-los, porque só sabe que o canal de controlo está ativo. Verifique no servidor a interface do túnel com ip -br addr show tun0 e confirme que o endereço atribuído ao cliente cai dentro do conjunto que configurou. Se o conjunto e o endereço do cliente não coincidirem, corrija isso primeiro, porque cada regra abaixo corresponde ao conjunto.

A seguir, pergunte ao servidor que interface usaria para chegar a um endereço público. ip route get 203.0.113.9 imprime o dispositivo e a origem escolhidos na sua primeira linha. Anote o nome desse dispositivo, porque é o valor que a regra NAT tem de conter.

Leia a regra que decide se os pacotes saem

O MASQUERADE só reescreve um pacote quando o pacote sai pela interface indicada na regra. Uma regra limitada a um dispositivo com cabo não faz nada pelo tráfego que sai por Wi-Fi, e o pacote mantém o endereço de origem privado até ao router superior. Esse router não tem rota de volta para o seu conjunto do túnel, por isso descarta a resposta, e o cliente vê uma ligação que abre e depois morre. O sintoma cresce com a quantidade de página que chega antes de ser precisa a primeira resposta.

Liste a tabela viva e leia a coluna da interface de saída em vez de procurar apenas a palavra MASQUERADE. A saída na forma de adicionar é mais fácil de comparar do que uma listagem formatada:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Num Raspberry Pi que antes usava Ethernet e agora usa Wi-Fi, o nome desatualizado é quase sempre toda a história. O instalador registou que dispositivo estava presente na configuração, e o conjunto de regras guardado repete-o em cada arranque. Compare o dispositivo da pesquisa de rota com o da regra antes de mudar mais alguma coisa. Se coincidirem, a interface não é o seu problema e deve passar aos contadores da última secção. Se diferirem, a correção é uma alteração de uma palavra no ficheiro de persistência.

Corrija o conjunto de regras guardado, não apenas o que está em execução

Editar apenas a tabela viva dura até ao próximo reinício, o que é exatamente o tempo suficiente para o convencer de que o problema está resolvido. As regras que voltam no arranque vivem num ficheiro que um pacote de persistência da firewall recarrega. Nas imagens de Pi baseadas em Debian esse ficheiro costuma ser /etc/iptables/rules.v4.

Faça uma cópia antes de lhe tocar, depois substitua a interface de saída na linha MASQUERADE pelo dispositivo que anotou, por exemplo -o wlan0 em vez de -o eth0. Deixe o intervalo de origem como está, a não ser que o seu conjunto de clientes tenha mudado. Recarregue e confirme que a regra já indica o dispositivo correto:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Dois ajustes adjacentes esquecem-se com facilidade. sysctl net.ipv4.ip_forward deve indicar 1, e o router superior não deve filtrar por si só os endereços de origem privados.

Prove que a regra dispara e depois isole o que ainda está lento

Os contadores são a única prova honesta de que uma regra correspondeu. Execute a listagem detalhada, inicie uma transferência no cliente e execute-a de novo. As colunas de pacotes e bytes ao lado da sua regra devem subir, e uma regra que fica em zero ainda não corresponde. Se os contadores se movem mas as páginas continuam a falhar, compare o intervalo de origem com o conjunto real com grep -n "^server " /etc/openvpn/server.conf. Se se movem e as páginas carregam mas o débito é fraco, a tradução está feita e o problema restante está noutro lugar.

Compare duas transferências do mesmo cliente, uma para um anfitrião na rede local e outra pelo túnel para esse mesmo anfitrião. Lento nos dois casos aponta para o uplink do Pi ou para a ligação Wi-Fi, não para a VPN. Lento apenas pelo túnel aponta para a MTU e para as retransmissões, que pode inspecionar com ip -s link show tun0 antes de alterar qualquer definição de cifra.

Para desfazer a experiência, restaure a cópia e volte a carregá-la, depois confirme que a regra original e os seus contadores voltaram. Escreva o dispositivo de saída e o comando de recarga nas notas do servidor, porque a próxima alteração de uplink vai redescobrir a mesma discrepância. Uma regra que indica o dispositivo errado fica invisível até o tráfego precisar dela.