Comprobar que un túnel dividido funciona: un resultado de IP non é unha proba

Unha soa páxina de navegador que mostra un enderezo IP non demostra case nada sobre un túnel dividido. Un enderezo visible pode ser o correcto polo motivo equivocado, e un fluxo excluído nunca se exercita con ela. Anote o resultado esperado antes de probar: que aplicación ou destino debe usar o túnel, cal debe permanecer directo e que debe parar cando falle o túnel. Sen ese plan, calquera cifra plausible parece un éxito.

O mito: unha consulta de enderezo demostra cobertura

A comprobación de IP responde a unha pregunta: que ve o mundo exterior desde unha aplicación nun instante. Non di nada sobre un prefixo interno, un segundo perfil de navegador ou un nome que deba resolverse en privado. Tampouco di nada sobre o fallo, e esa é a metade dun deseño de túnel dividido que se rompe en produción.

Unha páxina de enderezos tampouco pode mostrar a ruta, o resolutor nin a política de fallo. Trátea como unha observación, non como un veredicto.

Exercite un fluxo incluído e un excluído

Envíe unha petición inofensiva desde a aplicación que debe estar incluída, ou cara ao prefixo que espera encamiñar polo túnel, e rexistre a orixe, o destino, a familia de enderezos e o camiño observado. Faga o mesmo cun fluxo que debe permanecer directo. O lado excluído é o que a xente omite, e é a única proba de que a división é deliberada e non accidental. Un proceso auxiliar pode levar unha identidade de política distinta, así que probe no proceso que posúe o 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

Por iso unha proba executada na aplicación equivocada pode mostrar o contrario do que pretende o deseño. Anote os catro campos para ambos os lados antes de sacar calquera conclusión.

Engada o DNS e o caso de fallo

Consulte o resolutor do sistema e o resolutor que usa a aplicación, e despois compare esas respostas co enderezo de saída que informa o sitio. As dúas capas poden discrepar por deseño, e unha soa consulta do navegador non exercita a política do sistema operativo. Unha shell fai a comparación repetible: Rompa o túnel a propósito e despois faga unha petición que o navegador non teña na caché; unha páxina servida desde a caché non lle di nada sobre cara a onde foi o repliegue. Rexistre o que realmente ocorreu en lugar do que prevía o deseño.

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

Un túnel dividido que falla pechado e un que falla aberto son idénticos ata que rompe o túnel a propósito. Rexistre que comportamento observou, non cal esperaba.

Repita despois do cambio de estado

Repita as mesmas observacións despois dunha reconexión, un cambio de rede e unha actualización relevante da aplicación. Unha exclusión gardada pode seguir apuntando a un camiño ou a unha identidade de aplicación que xa non existe, e o deseño deixa en silencio de coincidir coa súa documentación. Eses tres acontecementos son onde os túneles divididos se desvían, e cada un é barato de volver probar. Unha proba que só se executa unha vez no despregamento describe unha configuración que xa non existe.

Se un resultado difire, atope o propietario da regra e a etapa de procesamento antes de cambiar varios axustes á vez. Cambiar cinco cousas e observar un resultado non é un diagnóstico, é unha configuración nova.

Que debe establecer o resultado

Vincule as observacións á política e á versión de cliente que realmente probou. O obxectivo é mostrar que este despregamento coincide coa cobertura que afirma, non que toda aplicación futura vaia ser privada. É unha afirmación máis estreita, e é a que de verdade pode soster con probas. Escriba a afirmación, a versión e os resultados de catro campos no rexistro de cambios.

Así, o seguinte revisor poderá saber se cambiou o deseño ou a proba. Un túnel dividido queda verificado cando ambos os lados, a división do resolutor e o comportamento ante fallos coinciden co que anotou ao principio. Un só resultado de IP non verifica ningún deles.