Encaminhamento recursivo: quando o túnel captura os seus próprios pacotes

O túnel sobe, o registo mostra um aperto de mão concluído e, um segundo depois, a mesma sessão morre e volta a ligar-se num ciclo. Esse padrão tem uma causa concreta: a rota até ao servidor aponta agora para dentro do túnel, por isso os pacotes que transportam o túnel são enviados pelo túnel. Nada mudou na autenticação, e é por isso que voltar a introduzir as credenciais não resolve nada. Compare o caminho exterior antes e depois da alteração da rota e a recursão torna-se visível.

Verifique primeiro o caminho exterior

Há dois pacotes em jogo, não um. O pacote interior pertence à aplicação e deve ser cifrado, enquanto o pacote exterior é endereçado ao servidor e tem de o alcançar por um caminho que não dependa do túnel.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Pergunte ao kernel qual é a rota até ao endereço do servidor depois de o túnel estar ativo, e outra vez depois de a rota predefinida mudar. Um salto seguinte que aterre no dispositivo do túnel é a recursão, e é visível sem qualquer captura de pacotes. A ligação a uma interface, as marcas ou um espaço de nomes de rede podem tornar incompleta uma consulta simples, por isso use o contexto que o próprio cliente usa. Quando a resposta parece correta mas a sessão continua em ciclo, leia as regras da política de encaminhamento e não apenas a tabela principal.

Porque é que a sessão sobrevive por um instante

O aperto de mão termina antes de a nova rota ser instalada, por isso os primeiros segundos parecem saudáveis. Assim que o cliente adiciona a rota predefinida, o pacote exterior seguinte segue-a para a interface pela qual esse pacote tem de viajar. O servidor não vê nada, o cliente retransmite e a tentativa ou expira ou mata a sessão e recomeça.

Essa ordem explica porque é que um túnel pode funcionar num portátil e falhar num router, e porque é que a falha começa muitas vezes quando o tráfego arranca e não no momento da ligação. Também explica o ciclo: cada reinício restabelece a sessão antes de a rota o tornar impossível.

Descubra quem é o dono da exceção do ponto final

Os clientes suportados preparam a sua própria exceção: uma rota de anfitrião até ao servidor através do gateway original, ou uma marca que mantém o socket exterior fora do túnel. A questão é se outra coisa a removeu ou a anulou.

Em IPsec baseado em rotas, examine os seletores de política que decidem que pacotes entram no túnel e confirme que o endereço do par está excluído deles. No WireGuard, a marca de firewall da interface e as suas regras de política mantêm os pacotes de transporte fora do túnel, por isso uma rota predefinida adicionada à mão pode quebrar essa disposição. Um segundo perfil VPN ou um script de gestão que reescreva a rota predefinida é um culpado comum. As regras de contorno amplas adicionadas uma a uma são o resultado habitual, e transformam um erro de encaminhamento numa tabela que ninguém consegue manter.

Verifique novamente após uma mudança de rede

Uma rota de anfitrião através de um gateway Wi-Fi está correta até a máquina mudar para outra rede. Então o mesmo sintoma regressa sem qualquer alteração de configuração.

Registe o endereço do ponto final, a rota antes e depois da ligação e a interface que cada uma usou. Esses três factos costumam separar um erro do cliente de uma anulação, e sobrevivem à pessoa que os recolheu.

Volte a ligar-se na nova rede e repita a leitura. Se a exceção faltar outra vez, a correção pertence ao perfil que a possui, e não a um comando pontual escrito durante uma avaria.