VPN aninhada: qual túnel carrega a conexão externa?

Dois clientes VPN rodando ao mesmo tempo não produzem um túnel aninhado; produzem dois túneis e uma discussão sobre o roteamento. Um túnel aninhado existe quando a conexão do cliente interno com o próprio servidor é ela mesma carregada pelo túnel externo, e isso é um arranjo que se constrói de propósito. Se der certo, o servidor interno vê o endereço do servidor externo; se der errado, um cliente se reconecta em silêncio em volta do outro. Três condições decidem se o aninhamento é real ou acidental.

Três condições decidem o aninhamento

A primeira é qual endpoint precisa de qual caminho. Nomeie o endereço do servidor interno, nomeie o do servidor externo e afirme explicitamente que o servidor interno só é alcançável pelo túnel externo. Todo o resto decorre dessa frase, inclusive quais rotas ficam em qual tabela.

A segunda é se você consegue ver o caminho em cada camada. Se não puder perguntar ao kernel qual rota um destino específico usaria, você está deduzindo a cadeia a partir de um IP de saída final, e essa é justamente a evidência que não distingue aninhamento de coincidência.

A terceira é o que acontece quando o túnel externo cai. O túnel interno pode parar junto, reconectar pela rede comum ou ficar bloqueado até o caminho externo voltar, e as três são políticas defensáveis. Não são a mesma política, e o comportamento padrão da maioria dos clientes é o segundo. Um cliente que reconecta seu endpoint pela rede física enquanto mostra uma conexão saudável é a forma mais comum de uma cadeia pretendida virar silenciosamente dois túneis sem relação.

Condição um: qual endpoint precisa de qual caminho

ip route get 203.0.113.10 responde a essa pergunta diretamente: imprime a rota, o endereço de origem e a interface que o kernel usaria para esse destino agora.

Rode o comando para o servidor interno antes de o cliente interno iniciar e de novo depois, e compare. Se a resposta mudar da interface física para a interface do túnel externo, o aninhamento é real naquele momento. Se não mudar, o cliente interno está conectando direto, diga o que disser o painel. Repita para o endereço do servidor externo, que ainda precisa resolver pela interface física, porque uma rota que captura os dois endpoints de forma recursiva é a falha que tira a máquina da rede por completo.

Condição dois: inspecione o caminho em cada camada

Seleção de rota é mais do que a tabela principal num cliente moderno. Regras de política podem enviar pacotes marcados para outra tabela, um cliente pode vincular seu socket a uma interface, e um contêiner ou namespace tem tabelas próprias. ip rule e ip route show table all são como descobrir qual desses mecanismos está em jogo.

Um cliente que define SO_MARK no próprio socket, ou que é configurado para se vincular a um dispositivo específico, contorna a rota padrão que você achava ter arranjado. Isso é um recurso e não um defeito, e significa que a única verificação confiável é a que roda no mesmo namespace do cliente. Se os clientes rodam em contêineres, rode as verificações dentro desses contêineres em vez de no host.

Condição três: o que acontece quando o túnel externo cai

Comportamento em falha exige uma decisão, não um padrão. Anote o que deve acontecer ao túnel interno quando o externo desaparecer e depois faça os clientes cumprirem isso.

As opções são concretas. Parar o cliente interno quando o caminho externo desaparece dá uma cadeia limpa e uma interrupção óbvia. Deixá-lo reconectar direto dá disponibilidade e remove em silêncio a propriedade para a qual a cadeia foi construída. Bloquear até o caminho externo voltar é a mais estrita e a mais chata de operar, porque cada oscilação do túnel externo vira um incidente visível.

Teste as três com tráfego inofensivo e uma falha proposital do túnel externo, porque ler a configuração não dirá qual você tem. Derrube o túnel externo, observe o que o cliente interno faz e verifique a rota de novo enquanto ele está fora. Depois traga o túnel externo de volta e confirme que a cadeia se refaz em vez de deixar o cliente interno no caminho direto que ele escolheu nesse meio-tempo.

O que a cadeia não lhe dá

Camadas extras acrescentam endpoints, chaves e modos de falha; não acrescentam nenhuma garantia de anonimato e não impedem que o operador externo veja que existe um túnel. Qualquer afirmação sobre o que o aninhamento protege precisa nomear o observador contra quem ele protege.

A entrega é um documento curto e não uma conexão funcionando: qual endpoint usa qual caminho, o que acontece numa falha externa e os três comandos que mostram o estado atual. A documentação do strongSwan sobre encaminhamento é uma referência útil para como o tráfego de túnel é encaminhado entre interfaces num host Linux. Rode as verificações de novo após cada atualização de cliente, porque os padrões que produziram sua cadeia não são um contrato. Um túnel aninhado que você não consegue inspecionar é um boato com uma luz de status.