Por que uma rota de túnel completo corta o servidor que a transporta

Ative um túnel completo e cada destino passa agora a pertencer à interface VPN, incluindo a máquina que o termina. Os pacotes exteriores que transportam o túnel são endereçados a essa máquina, por isso a rota acaba por consumir o transporte de que depende. Uma rota específica adicional resolve isto, e a razão merece ser compreendida. Sem essa razão, a próxima reconstrução reintroduz a falha.

Uma rota que come o seu próprio transporte

A encapsulação envolve cada pacote num segundo cabeçalho. O exterior é endereçado do endereço físico local para o endereço público do servidor, e tem de atravessar a ligação física antes de qualquer túnel poder existir.

Agora deixe a pesquisa desse endereço público escolher o túnel. Para enviar o pacote, a máquina tem de o encapsular, o que exige uma rota para o mesmo endereço, que devolve o túnel. Os clientes lidam com isto de uma de duas formas. Um cuidadoso recusa instalar a rota predefinida e reporta um erro, enquanto um menos cuidadoso reporta sucesso e depois não move nada. A falha silenciosa é a que custa uma tarde.

A correspondência do prefixo mais longo decide a pesquisa antes de qualquer métrica ser consultada, por isso uma rota de um só endereço supera qualquer rota predefinida na máquina. É todo o mecanismo por trás da reparação.

Instale a exceção antes da predefinida

Crie uma rota de um só endereço para o servidor, com a gateway física como salto seguinte, antes de a rota predefinida se mover. A ordem importa: instalá-la depois significa viver com um túnel quebrado enquanto escreve.

A maioria dos clientes faz isto sem ser pedido. OpenVPN procura o endereço remoto e fixa-o antes de reescrever a gateway predefinida, e a sua opção route-delay existe para plataformas onde essa sequência corre. O wg-quick segue um caminho totalmente diferente, marcando pacotes e consultando uma regra de política em vez de acrescentar uma exceção. Mecanismos diferentes, o mesmo requisito: o pacote exterior tem de escapar ao túnel que cria.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

A saída da pesquisa é o teste de aceitação. Tem de nomear o dispositivo físico e o salto seguinte físico. Um dispositivo de túnel nessa resposta significa que falta a exceção, ou que foi colocada depois de algo que a sobrepõe.

A imagem espelhada no servidor

A mesma armadilha espera do outro lado, invertida. Dê ao servidor uma rota predefinida por outro túnel, ou empurre-lhe uma rota que cubra os endereços públicos dos clientes, e as suas respostas ganham o hábito da direção errada.

Imagine um cliente que se liga e envia um pedido. A resposta é endereçada ao endereço público desse cliente, que agora corresponde a uma rota de túnel, por isso sai por outra interface levando uma origem que o cliente nunca marcou. O cliente pode receber esse pacote e ainda assim descartá-lo, porque nada o liga ao pedido que enviou. Comece pela decisão de encaminhamento do servidor em vez do tempo limite do cliente, já que só uma das duas mostra a escolha real.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Existem três reparações e não são iguais. Fixar o serviço ao endereço físico, ou traduzir a origem, ambas escondem a decisão de encaminhamento em vez de a corrigir. Enviar o tráfego de resposta do conjunto do túnel por uma tabela dedicada corrige a causa, e as outras duas só são aceitáveis enquanto o desenho de encaminhamento estiver congelado.

Exceções que o túnel continua a roubar

Uma mão-cheia de tarefas precisa da internet aberta mesmo enquanto o túnel possui a rota predefinida, e cada uma precisa da sua própria exceção. O atualizador de DNS dinâmico é normalmente o primeiro a quebrar.

Resolve o fornecedor, abre uma ligação e descobre que os seus próprios pacotes viajam por um túnel cujo endereço mudou há segundos, por isso a atualização falha ou publica o endereço errado. Três saídas: fixar o fornecedor com uma rota de host pela gateway física, executar a atualização antes de o túnel subir, ou dar ao atualizador uma tabela de política que o túnel nunca toca. A sincronização de tempo tem a mesma exposição num dispositivo que arranca sem resolvedor, e os pontos de validação de certificados pertencem à lista pelo mesmo motivo.

Uma exceção que ninguém escreveu é uma exceção que a próxima reconstrução deixará cair em silêncio.

Comprove-o depois de uma reconexão, não antes

Teste três destinos, não um: o ponto final, um endereço privado atrás do túnel e um endereço público para lá dele. Uma única pesquisa bem-sucedida não diz quase nada sobre as outras duas.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Depois reinicie a ligação, porque um cliente que reconstrói a sua tabela ao reconectar descartará uma rota que escreveu à mão. Com um kill switch em jogo, verifique que o ponto final é permitido, senão o túnel não pode voltar após uma mudança de rede e o sintoma parece uma falha. Guarde a exceção no perfil ou no ficheiro unit em vez do histórico da shell, para que a reconexão a recrie em vez de a apagar.