Probar una afirmación de privacidad de una VPN: guarde pruebas que resistan
Escriba la afirmación, el observador y la configuración antes de mirar un resultado. Una prueba de enrutamiento muestra una salida; nunca muestra qué retiene el operador.
La prueba comienza con una frase que alguien quiere que sea cierta, y las pruebas o bien respaldan una versión estrecha de ella o nada en absoluto. Una comprobación de la dirección pública muestra qué salida usó una petición. No muestra qué retiene el proveedor, quién puede leerlo ni qué ocurre con una sesión que nunca se completa. Recorrer la prueba como un procedimiento documentado le impide afirmar más de lo que la medición puede sostener.
Elija una afirmación observable
Escriba la afirmación como una sola frase comprobable antes de abrir cualquier herramienta: para este perfil, en esta red, las peticiones a un eco de dirección pública salen por la salida declarada del proveedor. Esa frase nombra un sujeto, una condición y una observación, y eso es lo que la hace refutable. Una afirmación como que la VPN protege la privacidad no tiene forma observable, así que ninguna medición puede resolverla. Guarde una segunda frase para lo que la prueba no cubrirá, porque la retención, el acceso de terceros y la correlación de tráfico quedan todos fuera de una prueba en el navegador.
Escriba esa segunda frase por adelantado, no después de que llegue el resultado. Es mucho más fácil ser honesto sobre el alcance mientras el desenlace aún es desconocido que después de que una captura de pantalla tranquilizadora aterrice en el tique. Una nota de alcance añadida después tiende a describir el resultado en lugar de la pregunta.
Datos de configuración que un lector necesita para repetir la medición
La configuración es lo que hace reproducible un resultado, y es lo que la gente omite cuando la respuesta parece buena. Las cadenas de versión, los nombres de perfil, la red de acceso y las familias de direcciones pertenecen a la nota, junto con cualquier regla de división del túnel que pudiera sacar tráfico del túnel. Nombre también el evento bajo prueba, porque una conexión que funciona, una caída inesperada, una desconexión manual y un traspaso de red ejercen reglas distintas. Una prueba que mezcla esos eventos demuestra poco sobre cualquiera de ellos.
Use tráfico no sensible en un entorno en el que tenga autorización para probar. Capturar paquetes no relacionados hace que el registro parezca técnico y añade exposición sin añadir pruebas. Dirija la captura solo a la interfaz del túnel y fije un límite de tamaño de archivo para que una ejecución larga no llene el disco. Detenga la captura antes de cambiar nada, para que el archivo coincida con la línea de configuración que escribió.
Diga qué se midió y qué significa
Registre qué imprimió la herramienta y qué podía ver la herramienta. Una respuesta del resolutor, un resultado del eco de dirección y una consulta de ruta responden a preguntas distintas, y una etiqueta de ubicación dentro de una página web es una inferencia sobre una base de datos, no un hecho sobre la salida. Escriba el comando que produjo cada línea junto a ella, porque un valor sin su comando no se puede reproducir. Mantenga la marca de tiempo en la misma zona horaria que el tique de cambio, o la secuencia se vuelve ilegible una semana después.
curl -s https://icanhazip.com
curl -s https://ipinfo.io/ip; echo
resolvectl status --no-pager | head -15
Dos servicios de eco independientes que coinciden son más fuertes que uno, y una discrepancia es en sí misma un hallazgo que merece anotarse. La salida del resolutor muestra si el DNS siguió el túnel o siguió usando la red local, lo que es una afirmación separada de la dirección de salida. Guarde la salida en bruto con una marca de tiempo y conserve los resultados contrarios en lugar de la captura de pantalla más tranquilizadora. Cuando un cambio mueve el resultado, aplique una variable a la vez, porque cambiar servidor y cliente juntos le deja sin poder decir cuál importó.
Qué pertenece al registro y qué debe eliminarse
Conserve el método, la salida no secreta y las limitaciones, y luego elimine el resto. Los perfiles con credenciales, los nombres de host privados y los identificadores de cuenta no necesitan viajar con las pruebas, y un registro de prueba que los filtra ha dañado aquello que debía demostrar. Los cinco campos de abajo son la forma más corta que aún sobrevive a un traspaso.
| Field | What to write |
|---|---|
| Claim | One testable sentence naming the profile, the network and the observation |
| Observer and scope | Who could see the traffic or the record, and under which conditions |
| Setup | Client and server versions, profile name, access network, address families, split-tunnel rules, event under test |
| Raw result | Tool output with a timestamp, exit addresses from both echo services, resolver answer |
| What it does not support | Retention, third-party access, correlation, untested address families |
Adjunte la declaración de política con la que compara, con su fecha y su alcance. RFC 6973 enmarca el análisis de privacidad en torno a observadores nombrados y un alcance definido, y ese marco encaja con un registro de prueba: quién podía observar qué, en qué condiciones y qué partes quedaron sin examinar.
Termine con un párrafo que declare qué respaldan las pruebas y qué no. Ese párrafo es el entregable, y todo lo anterior existe para hacerlo honesto. Si no se puede escribir sin matizar cada cláusula, la prueba midió menos de lo que afirma el tique.