Tabela de rotas versus consulta real: para onde vai o tráfego VPN

Um despejo da tabela de rotas é o diagnóstico menos útil na resolução de problemas de VPN e o mais frequentemente colado. Quarenta linhas de prefixos dizem-lhe o que a máquina poderia fazer, não o que fez para o pedido que falhou. O mecanismo que realmente quer é a consulta: dados esta origem e este destino, que regra correspondeu, que tabela foi consultada e que interface e salto seguinte saíram. Comece por um destino e uma origem, leia depois a tabela com essa pergunta na mão, e a mesma saída torna-se prova em vez de ruído.

Uma tabela é um conjunto de candidatos, não uma decisão

Cada entrada descreve um prefixo e o que fazer com o tráfego que corresponde a ele: enviá-lo para uma interface, entregá-lo a um salto seguinte ou descartá-lo. Nada nessa lista está ordenado por intenção, e a entrada que a um humano parece mais específica não é sempre a que o kernel seleciona, porque a seleção segue a correspondência de prefixo mais longa e, entre prefixos iguais, a métrica.

Portanto o primeiro passo é perguntar ao kernel em vez de ler a lista. O comando de consulta responde para um destino, e com um argumento de origem responde para o par exato que uma ligação reencaminhada ou vinculada usaria:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Cada endereço acima é um exemplo de documentação. O ponto é a forma da resposta: interface, endereço de origem escolhido, gateway e a tabela de onde veio a entrada. Se essa saída não corresponder à interface que esperava, localizou o problema com um único comando, e nenhuma quantidade de leitura da tabela completa lhe diria qual candidato ganhou.

A consulta percorre primeiro regras e depois tabelas

No Linux a decisão é em duas fases. As regras de política são avaliadas por ordem de prioridade, e a primeira regra que corresponde nomeia uma tabela a consultar; essa tabela faz então a correspondência de prefixo mais longa. Uma regra pode corresponder por origem, destino, marca de firewall, interface ou uma combinação, e é por isso que um despejo da tabela principal pode ser perfeitamente exato e completamente irrelevante para o pacote que investiga.

ip rule show
ip route show table all | head -40
ip route show table 100

Se uma regra envia tráfego do seu pool VPN para a tabela 100, então é a tabela 100 que importa, e a tabela principal é um engodo. Este é também o mecanismo por trás do encaminhamento baseado na origem num router: o mesmo destino pode ter duas respostas diferentes consoante de onde veio o pacote, e só a consulta com um argumento de origem revela qual se aplica.

O IPv6 tem as suas próprias regras e tabelas. Um projeto que executa ambas as famílias precisa das duas consultas, e uma resposta IPv4 funcional não diz nada sobre o caminho v6 que um cliente de dupla pilha pode preferir.

O que o cliente VPN instala

Os clientes normalmente não substituem a rota predefinida, porque isso quebraria o próprio caminho exterior do túnel. Instalam algo mais específico que ganha pelo comprimento do prefixo: um par de meias rotas predefinidas que cobrem 0.0.0.0/1 e 128.0.0.0/1 é o truque clássico, já que ambos são prefixos mais longos do que 0.0.0.0/0 e juntos cobrem todo o espaço. Outros instalam prefixos privados específicos mais uma regra de política, e alguns acrescentam uma marca para que só o tráfego selecionado seja capturado.

É por isso que "a VPN não alterou a minha rota predefinida" não é prova de falha. Verifique o que ela acrescentou de facto, e se o destino em questão cai dentro desses prefixos:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Duas meias rotas são fáceis de escapar num despejo porque não se parecem com uma predefinida. Uma configuração de split-tunnel que se esqueceu de incluir um prefixo produz exatamente o sintoma que está a perseguir: a aplicação que deveria usar o túnel resolve e liga-se localmente em vez disso. Compare os prefixos instalados com os destinos de que o utilizador realmente precisa, não com os endereços que testou por acaso. Uma lista de split-tunnel que cobre o servidor de ficheiros mas não o seu resolvedor produz uma ligação que resolve para um endereço público e depois falha a autenticação, o que parece um problema de palavra-passe e é um problema de rota.

A rota exterior também tem de sobreviver

O túnel é ele próprio tráfego. Os pacotes que transportam a carga encapsulada vão para o endereço do par pela interface física, e esse caminho não deve ser encaminhado de volta para dentro do túnel. Quando é, obtém a falha característica em que o túnel se estabelece e depois deixa de passar tráfego, porque o transporte do túnel está agora dentro do túnel.

Verifique o endereço do par como verificou o destino interior, e confirme que resolve para a interface física e não para o túnel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Uma rota recursiva, uma regra de política que apanha o par, ou uma predefinida substituída por um cliente de túnel completo são as três causas habituais. Todas as três são visíveis na consulta exterior, e nenhuma é visível num despejo da tabela principal tirado a posteriori.

O que a saída de encaminhamento não lhe pode dizer

Uma consulta correta significa que o kernel enviaria o pacote para um lugar sensato. Não significa que a firewall o permita, que a política IPsec o cubra, que a regra NAT o traduza, ou que o lado remoto tenha uma rota de retorno. Cada uma dessas é uma fase posterior, e as notas de reencaminhamento do strongSwan descrevem a cadeia que um pacote tem de atravessar em ambas as extremidades.

Também não tem em conta a ligação ao nível da aplicação. Um processo pode ligar-se a uma interface, definir uma marca ou usar o seu próprio resolvedor e ligar-se por um nome que resolve de forma diferente do que testou. Quando a consulta está correta e a ligação continua a falhar, a pergunta seguinte é que processo a está a fazer e se esse processo vê a mesma tabela que você.

Por isso mantenha o diagnóstico ordenado: nomeie o destino e a origem, execute a consulta, leia apenas a tabela e a regra que a consulta nomeou, e depois teste a fase seguinte. Essa sequência mantém uma investigação de encaminhamento em minutos e deixa um registo que outra pessoa pode seguir, o que uma tabela colada nunca faz.