Per què la vostra regla de túnel dividit va deixar de coincidir amb un servei

El túnel dividit sol fallar d’una de dues maneres. O bé el trànsit que hauria d’estar dins del túnel el rodeja, o bé el trànsit que hauria de quedar-se fora hi és atret. La fallada de la regla obsoleta és la primera classe i és la més confusa, perquè la regla s’aplica exactament tal com està escrita. El que ha canviat és la destinació: el servei ara respon en una adreça que la regla mai no va nomenar, i res del túnel no està malament.

Què fixa la regla i què retorna el DNS

Una regla de túnel dividit és una afirmació estàtica sobre destinacions, normalment expressada com un prefix, una ruta o una llista d’adreces. S’avalua contra la destinació del paquet en el moment d’enviar. En canvi, un nom d’amfitrió és una consulta que retorna un conjunt d’adreces amb una vida útil i una memòria cau, i la resposta pot variar segons el resolutor, el tipus de consulta i el minut.

Aquests dos objectes no negocien mai entre ells. La regla continua coincidint amb el prefix que se li va donar, el servei continua canviant l’adreça que lliura, i la distància entre tots dos s’eixampla en silenci. Per això el símptoma apareix després d’una migració de proveïdor o d’una renovació de certificat, i no després d’un canvi de configuració. Ningú no ha editat el túnel, així que ningú no mira el túnel, i el diagnòstic es desvia cap a l’aplicació en lloc de cap a la política.

Tres maneres com es trenca la coincidència

El cas evident és un servei que s’ha mogut: l’operador li ha canviat l’adreça, el DNS l’ha seguit i l’excepció no. El segon és una família d’adreces que la regla mai no va cobrir, cosa que passa quan un nom comença a retornar registres AAAA que una excepció només per a v4 ignora. El tercer és una diferència de resolutor: una vista interna i una vista pública poden retornar adreces diferents per al mateix nom, així que l’adreça que fa servir la vostra aplicació no és la que vau provar.

Una connexió en memòria cau és una quarta variant i és fàcil de passar per alt. L’aplicació pot estar parlant encara amb una adreça que va resoldre fa una hora, cosa que significa que la vostra consulta nova i el seu sòcol obert no coincideixen sobre on viu el servei.

Llegeix la destinació que l’aplicació realment utilitza

Pregunta al sistema operatiu i a la taula de sòcols, no a una pestanya del navegador. La consulta respon on es resol el nom ara mateix, i la taula de sòcols mostra l’adreça a la qual el procés està connectat, que pot ser més antiga. Executa les dues coses abans de formular una teoria, perquè la diferència entre elles és la resposta en aproximadament la meitat dels 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

Després compara-ho amb el que cobreix la regla. Si l’adreça actual cau fora de l’excepció i la petició continua fallant, has trobat la causa sense tocar la configuració del túnel. Si l’aplicació està connectada a una adreça que coincideix amb la regla i la petició continua fallant, el problema és en algun lloc més enllà del túnel i aquesta és la investigació equivocada.

Repara el mecanisme, no el símptoma

Si el producte admet un encaminament mantingut basat en dominis, fes-lo servir i segueix el comportament documentat d’actualització i abast. Això substitueix una conjectura estàtica per una resposta mantinguda, a costa de dependre que la funció funcioni tal com està documentada.

Si el disseny es basa en una llista estàtica, doneu-li un propietari i un pla d’actualització. El pla hauria de dir com es descobreix l’adreça, qui aprova el canvi i amb quina rapidesa s’espera que la llista segueixi una migració de proveïdor. Una llista sense propietari és una futura interrupció amb una causa coneguda.

No amplieu l’excepció a una gran xarxa veïna només per atrapar cada adreça que vau veure durant una prova curta. Això no és una solució; és un canvi permanent a la frontera de seguretat, i deixarà en silenci que serveis no relacionats evitin el túnel mentre la regla existeixi.

Verifica les dues meitats de la intenció

Un disseny de túnel dividit té dues intencions, i una reparació hauria de conservar-les totes dues. El servei protegit ha de passar pel túnel, i les categories excloses han de continuar passant-hi al voltant. Prova una connexió nova a la destinació reparada i després prova una cosa que hauria de quedar-se 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'

Anota l’adreça nova, el mecanisme que has triat i la data. Aquesta nota és el que impedeix que la persona següent conclogui que la VPN va ignorar aleatòriament la seva pròpia configuració.