Por que a túa regra de túnel dividido deixou de coincidir cun servizo

O túnel dividido adoita fallar dunha de dúas maneiras. Ou o tráfico que debería ir dentro do túnel o rodea, ou o tráfico que debería quedar fóra acaba dentro. O fallo da regra obsoleta é o primeiro tipo, e é o máis confuso, porque a regra aplícase exactamente como está escrita. O que cambiou é o destino: o servizo agora responde nun enderezo que a regra nunca nomeou, e nada no túnel está mal.

Que fixa a regra e que devolve o DNS

Unha regra de túnel dividido é unha afirmación estática sobre destinos, normalmente expresada como un prefixo, unha ruta ou unha lista de enderezos. Avalíase contra o destino do paquete no momento do envío. Un nome de host é unha consulta que devolve un conxunto de enderezos cunha vida útil e unha caché, e a resposta pode variar segundo o resolvedor, o tipo de consulta e o minuto.

Eses dous obxectos nunca negocian entre si. A regra segue coincidindo co prefixo que recibiu, o servizo segue cambiando o enderezo que entrega, e a fenda entre ambos amplíase en silencio. Por iso o síntoma aparece tras unha migración do provedor ou unha renovación de certificado e non tras un cambio de configuración. Ninguén editou o túnel, así que ninguén mira o túnel, e o diagnóstico desprázase cara á aplicación en lugar de cara á política.

Tres formas en que se rompe a coincidencia

O caso obvio é un servizo que se trasladou: o operador deulle outro enderezo, o DNS seguiuno, e a excepción non. O segundo é unha familia de enderezos que a regra nunca cubriu, o que ocorre cando un nome comeza a devolver rexistros AAAA que unha excepción só para IPv4 ignora. O terceiro é unha diferenza de resolvedor: unha vista interna e unha vista pública poden devolver enderezos distintos para o mesmo nome, polo que o enderezo que usa a túa aplicación non é o que usaches para probar.

Unha conexión en caché é unha cuarta variante e é fácil de pasar por alto. A aplicación pode seguir falando cun enderezo que resolveu hai unha hora, o que significa que a túa consulta recente e o seu socket aberto non coinciden en onde vive o servizo.

Le o destino que a aplicación usa de verdade

Pregunta ao sistema operativo e á táboa de sockets, non a unha pestana do navegador. A consulta responde a que resolve o nome agora mesmo, e a táboa de sockets mostra o enderezo ao que está conectado o proceso, que pode ser máis antigo. Executa ambas antes de formar unha teoría, porque a diferenza entre elas é en si mesma a resposta en aproximadamente a 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

Despois compara co que cobre a regra. Se o enderezo actual queda fóra da excepción e a solicitude segue fallando, atopaches a causa sen tocar a configuración do túnel. Se a aplicación está conectada a un enderezo que coincide coa regra e a solicitude segue fallando, o problema está máis alá do túnel e esta é a investigación equivocada.

Repara o mecanismo, non o síntoma

Se o produto admite direccionamento mantido baseado en dominios, úsao e segue o seu comportamento documentado de actualización e alcance. Iso substitúe unha suposición estática por unha resposta mantida, a costa de depender de que a función funcione como se documenta.

Se o deseño depende dunha lista estática, dálle un responsable e un plan de actualización. Ese plan debería dicir como se descobre o enderezo, quen aproba o cambio e con que rapidez se espera que a lista siga unha migración do provedor. Unha lista sen responsable é unha futura caída cunha causa coñecida.

Non amplíes a excepción a unha gran rede veciña só para capturar cada enderezo que viches durante unha proba curta. Iso non é unha reparación; é un cambio permanente na fronteira de seguridade, e deixará que servizos non relacionados eviten o túnel en silencio mentres a regra exista.

Verifica as dúas metades da intención

Un deseño de túnel dividido ten dúas intencións, e unha reparación debería preservar ambas. O servizo protexido debe pasar polo túnel, e as categorías excluídas deben seguir rodeándoo. Proba unha conexión nova ao destino reparado e despois proba algo que se supón que debe quedar fóra.

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'

Anota o novo enderezo, o mecanismo que escolliches e a data. Esa nota é o que impide que a seguinte persoa conclúa que a VPN ignorou ao chou a súa propia configuración.