Comprobar que un túnel dividido funciona: un resultado de IP no es una prueba

Una sola página de navegador que muestra una dirección IP no demuestra casi nada sobre un túnel dividido. Una dirección visible puede ser la correcta por el motivo equivocado, y un flujo excluido nunca se ejercita con ella. Anote el resultado esperado antes de probar: qué aplicación o destino debe usar el túnel, cuál debe seguir directo y qué debe detenerse cuando falle el túnel. Sin ese plan, cualquier cifra plausible parece un éxito.

El mito: una consulta de dirección demuestra cobertura

La comprobación de IP responde a una pregunta: qué ve el mundo exterior desde una aplicación en un instante. No dice nada sobre un prefijo interno, un segundo perfil de navegador o un nombre que deba resolverse de forma privada. Tampoco dice nada sobre el fallo, y esa es la mitad de un diseño de túnel dividido que se rompe en producción.

Una página de direcciones tampoco puede mostrar la ruta, el resolutor ni la política de fallo. Trátela como una observación, no como un veredicto.

Ejercite un flujo incluido y uno excluido

Envíe una petición inofensiva desde la aplicación que debe estar incluida, o al prefijo que espera enrutar por el túnel, y registre el origen, el destino, la familia de direcciones y la ruta observada. Haga lo mismo con un flujo que debe seguir directo. El lado excluido es el que la gente omite, y es la única prueba de que la división es deliberada y no accidental. Un proceso auxiliar puede llevar una identidad de política distinta, así que pruebe en el proceso que posee 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

Por eso una prueba ejecutada en la aplicación equivocada puede mostrar lo contrario de lo que pretende el diseño. Anote los cuatro campos para ambos lados antes de sacar cualquier conclusión.

Añada DNS y el caso de fallo

Consulte el resolutor del sistema y el resolutor que usa la aplicación, y luego compare esas respuestas con la dirección de salida que informa el sitio. Las dos capas pueden discrepar por diseño, y una sola consulta del navegador no ejercita la política del sistema operativo. Un intérprete de comandos hace repetible la comparación: Rompa el túnel a propósito y luego haga una petición que el navegador no tenga en caché; una página servida desde la caché no le dice nada sobre hacia dónde fue el respaldo. Registre lo que realmente ocurrió en lugar de lo que el diseño predijo.

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

Un túnel dividido que falla cerrado y uno que falla abierto se ven idénticos hasta que rompe el túnel a propósito. Registre qué comportamiento observó, no cuál esperaba.

Repita tras el cambio de estado

Repita las mismas observaciones tras una reconexión, un cambio de red y una actualización relevante de la aplicación. Una exclusión guardada puede seguir apuntando a una ruta o a una identidad de aplicación que ya no existe, y el diseño deja en silencio de coincidir con su documentación. Esos tres eventos son donde los túneles divididos se desvían, y cada uno es barato de volver a probar. Una prueba que solo se ejecuta una vez en el despliegue describe una configuración que ya no existe.

Si un resultado difiere, encuentre el propietario de la regla y la etapa de procesamiento antes de cambiar varios ajustes a la vez. Cambiar cinco cosas y observar un resultado no es un diagnóstico, es una configuración nueva.

Qué debe establecer el resultado

Vincule las observaciones a la política y a la versión de cliente que realmente probó. El objetivo es mostrar que este despliegue coincide con la cobertura que afirma, no que toda aplicación futura vaya a ser privada. Es una afirmación más estrecha, y es la que de verdad puede respaldar con pruebas. Escriba la afirmación, la versión y los resultados de cuatro campos en el registro de cambios.

Así, el siguiente revisor podrá saber si cambió el diseño o la prueba. Un túnel dividido queda verificado cuando ambos lados, la división del resolutor y el comportamiento ante fallos coinciden con lo que anotó al principio. Un solo resultado de IP no verifica ninguno de ellos.