Una sola pàgina de navegador que mostra una adreça IP no demostra gairebé res sobre un túnel dividit. Una adreça visible pot ser la correcta pel motiu equivocat, i un flux exclòs no s'exercita mai amb ella. Anoteu el resultat esperat abans de provar: quina aplicació o destí ha d'usar el túnel, quin ha de restar directe i què ha d'aturar-se quan falli el túnel. Sense aquest pla, qualsevol xifra plausible sembla un èxit.

El mite: una consulta d'adreça demostra cobertura

La comprovació d'IP respon una pregunta: què veu el món exterior des d'una aplicació en un instant. No diu res sobre un prefix intern, un segon perfil de navegador o un nom que s'hagi de resoldre en privat. Tampoc no diu res sobre la fallada, i aquesta és la meitat d'un disseny de túnel dividit que es trenca en producció.

Una pàgina d'adreces tampoc no pot mostrar la ruta, el resolutor ni la política de fallada. Tracteu-la com una observació, no com un veredicte.

Exerciu un flux inclòs i un d'exclòs

Envieu una petició innòcua des de l'aplicació que ha d'estar inclosa, o cap al prefix que espereu encaminar pel túnel, i registreu l'origen, la destinació, la família d'adreces i el camí observat. Feu el mateix per a un flux que ha de restar directe. El costat exclòs és el que la gent omet, i és l'única prova que la divisió és deliberada i no accidental. Un procés auxiliar pot portar una identitat de política separada, així que proveu en el procés que posseeix el socket.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Per això una prova executada en l'aplicació equivocada pot mostrar el contrari del que pretén el disseny. Anoteu els quatre camps per als dos costats abans de treure cap conclusió.

Afegiu el DNS i el cas de fallada

Consulteu el resolutor del sistema i el resolutor que usa l'aplicació, i després compareu aquestes respostes amb l'adreça de sortida que informa el lloc. Les dues capes poden discrepar per disseny, i una sola consulta del navegador no exerceix la política del sistema operatiu. Una shell fa la comparació repetible: Trenqueu el túnel a propòsit i després feu una petició que el navegador no tingui a la memòria cau; una pàgina servida des de la memòria cau no diu res sobre cap a on va anar el replegament. Registreu què va passar realment en lloc del que preveia el disseny.

curl -s https://ifconfig.me
nslookup intranet.example

Un túnel dividit que falla tancat i un que falla obert són idèntics fins que trenqueu el túnel a propòsit. Registreu quin comportament vau observar, no quin esperàveu.

Repetiu després del canvi d'estat

Repetiu les mateixes observacions després d'una reconnexió, un canvi de xarxa i una actualització rellevant de l'aplicació. Una exclusió desada pot continuar apuntant a un camí o a una identitat d'aplicació que ja no existeix, i el disseny deixa en silenci de coincidir amb la seva documentació. Aquests tres esdeveniments són on els túnels dividits es desvien, i cadascun és barat de tornar a provar. Una prova que només s'executa un cop al desplegament descriu una configuració que ja no existeix.

Si un resultat difereix, trobeu el propietari de la regla i l'etapa de processament abans de canviar diversos paràmetres alhora. Canviar cinc coses i observar un resultat no és un diagnòstic, és una configuració nova.

Què ha d'establir el resultat

Vinculeu les observacions a la política i a la versió de client que realment vau provar. L'objectiu és mostrar que aquest desplegament coincideix amb la cobertura que afirma, no que tota aplicació futura serà privada. És una afirmació més estreta, i és la que de debò podeu sostenir amb proves. Escriviu l'afirmació, la versió i els resultats de quatre camps al registre de canvis.

Així, el revisor següent pot saber si va canviar el disseny o la prova. Un túnel dividit queda verificat quan tots dos costats, la divisió del resolutor i el comportament en cas de fallada coincideixen amb el que vau anotar al principi. Un sol resultat d'IP no en verifica cap.

Articles relacionats