Por que sua regra de túnel dividido deixou de corresponder a um serviço

O túnel dividido normalmente falha de uma de duas maneiras. Ou o tráfego que deveria estar dentro do túnel o contorna, ou o tráfego que deveria ficar fora acaba sendo puxado para dentro. A falha da regra desatualizada é o primeiro tipo, e é a mais confusa, porque a regra é aplicada exatamente como foi escrita. O que mudou é o destino: o serviço agora responde em um endereço que a regra nunca nomeou, e nada no túnel está errado.

O que a regra fixa e o que o DNS retorna

Uma regra de túnel dividido é uma afirmação estática sobre destinos, geralmente expressa como um prefixo, uma rota ou uma lista de endereços. Ela é avaliada contra o destino do pacote no momento do envio. Um nome de host é uma consulta que retorna um conjunto de endereços com um tempo de vida e um cache, e a resposta pode variar conforme o resolver, o tipo de consulta e o minuto.

Esses dois objetos nunca negociam entre si. A regra continua correspondendo ao prefixo que recebeu, o serviço continua trocando o endereço que entrega, e a lacuna entre eles aumenta em silêncio. Por isso o sintoma aparece depois de uma migração do provedor ou de uma renovação de certificado e não depois de uma mudança de configuração. Ninguém editou o túnel, então ninguém olha para o túnel, e o diagnóstico deriva para a aplicação em vez da política.

Três maneiras pelas quais a correspondência se quebra

O caso óbvio é um serviço que mudou de lugar: o operador lhe deu um novo endereço, o DNS acompanhou e a exceção não. O segundo é uma família de endereços que a regra nunca cobriu, o que acontece quando um nome começa a retornar registros AAAA que uma exceção apenas para IPv4 ignora. O terceiro é uma diferença de resolver: uma visão interna e uma visão pública podem retornar endereços diferentes para o mesmo nome, então o endereço que sua aplicação usa não é o que você testou.

Uma conexão em cache é uma quarta variante e é fácil de passar despercebida. A aplicação pode ainda estar falando com um endereço que resolveu há uma hora, o que significa que sua consulta recente e o socket aberto dela não concordam sobre onde o serviço mora.

Leia o destino que a aplicação realmente usa

Pergunte ao sistema operacional e à tabela de sockets, não a uma aba do navegador. A consulta responde a que o nome resolve agora, e a tabela de sockets mostra o endereço ao qual o processo está conectado, que pode ser mais antigo. Execute as duas antes de formar uma teoria, porque a diferença entre elas é ela mesma a resposta em cerca de metade dos casos.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Em seguida, compare com o que a regra cobre. Se o endereço atual ficar fora da exceção e a requisição ainda falhar, você encontrou a causa sem tocar na configuração do túnel. Se a aplicação estiver conectada a um endereço que corresponde à regra e a requisição ainda falhar, o problema está além do túnel e esta é a investigação errada.

Repare o mecanismo, não o sintoma

Se o produto oferece suporte a direcionamento mantido baseado em domínios, use-o e siga o comportamento documentado de atualização e escopo. Isso substitui um palpite estático por uma resposta mantida, ao custo de depender de que o recurso funcione conforme documentado.

Se o projeto depende de uma lista estática, dê a ela um responsável e um plano de atualização. O plano deve dizer como o endereço é descoberto, quem aprova a mudança e com que rapidez se espera que a lista siga uma migração do provedor. Uma lista sem responsável é uma futura falha com uma causa conhecida.

Não amplie a exceção para uma grande rede vizinha só para capturar cada endereço que você viu durante um teste curto. Isso não é um reparo; é uma mudança permanente na fronteira de segurança, e ela deixará serviços não relacionados contornarem o túnel em silêncio enquanto a regra existir.

Verifique as duas metades da intenção

Um projeto de túnel dividido tem duas intenções, e um reparo deve preservar ambas. O serviço protegido deve passar pelo túnel, e as categorias excluídas devem continuar contornando-o. Teste uma conexão nova com o destino reparado e depois teste algo que deveria ficar fora.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Anote o novo endereço, o mecanismo escolhido e a data. É essa nota que impede a próxima pessoa de concluir que a VPN ignorou ao acaso a própria configuração.