Cómo probar el interruptor de seguridad de una VPN sin tus cuentas reales
Ejecuta una prueba del interruptor de seguridad con una página señuelo y un perfil de repuesto: cubre cada tipo de corte, lee los códigos de salida de curl y separa un bloqueo real de un fallo de DNS.
No necesitas una cuenta real para saber si un interruptor de seguridad aguanta; eso es justo lo que una prueba pone en riesgo. La comprobación crea una ventana breve en la que el tráfico puede o no salir fuera del túnel, así que la carga útil debería ser algo que puedas perder. Ahora lo hago con una página señuelo y un perfil de navegador de repuesto, y da una respuesta más clara que la rutina de navegador y correo web que usaba antes. Lo que sigue recorre el mismo orden que presenta el cliente: el ajuste, el destino, la transición y luego las pruebas.
La prueba responde una pregunta estrecha: durante esta transición, ¿puede esta aplicación llegar a la red fuera del túnel? No dice nada sobre si el resto de la política es sensato. Mantén el alcance así de pequeño y el resultado merece escribirse.
Encuentra el interruptor y su alcance en el cliente
Abre el cliente y localiza el ajuste de bloqueo antes de cambiar cualquier estado de red. Los proveedores lo llaman de forma distinta: interruptor de seguridad, modo de bloqueo, bloqueo de red, bloquear el tráfico fuera del túnel. La etiqueta dice menos que las opciones de dentro. Lo que importa es si el bloqueo se aplica siempre, o solo cuando la aplicación decide que un túnel acaba de fallar, y si cubre todas las aplicaciones o una lista seleccionada.
Después enumera las transiciones que tu cliente puede realizar de verdad. Una desconexión iniciada por el usuario, salir de la aplicación y perder el contacto con el servidor son tres rutas de código distintas en la mayoría de los clientes, y no comparten una sola política de bloqueo. Algunos liberan el bloqueo cuando la aplicación se cierra. Otros dejan las reglas de filtrado instaladas hasta que algo las elimina. Lee la referencia de ajustes del proveedor para la versión que ejecutas en vez de suponer, y luego anota cuál de las tres estás probando.
Anota también el perfil: protocolo, familias de direcciones y si el túnel dividido está activado. Una afirmación sobre todo el dispositivo no tiene sentido si el perfil excluye a propósito unas pocas aplicaciones, y una exclusión que configuraste no es una fuga. La referencia de ajustes de OpenVPN Connect es el tipo de página que nombra qué conmutador cambia qué comportamiento, aunque las etiquetas difieren según el cliente.
Elige un destino señuelo que también funcione sin el túnel
El señuelo necesita dos propiedades, y saltarse cualquiera de ellas produce un resultado ilegible. Debe ser accesible directamente cuando el túnel está caído y el bloqueo desactivado, o «dejó de responder» podría significar simplemente que el host desapareció. Y no debe necesitar un inicio de sesión, una cookie ni un pago, para que una fuga te cueste una línea de registro en lugar de una sesión.
Una página estática en un host que controlas es la opción limpia. Una máquina virtual de repuesto con un servidor HTTP sencillo es casi igual de buena, y una página pública de comprobación de conectividad sirve si aceptas que su disponibilidad queda fuera de tu control. Anota la dirección, el puerto, la familia de direcciones y si la petición necesita una consulta de nombre, porque cada uno de esos se convierte en una variable que quizá tengas que aislar más adelante.
Establece la línea base antes de tocar el interruptor. Con el túnel activo, el señuelo debe responder a través del túnel, lo que demuestra que la ruta de la política funciona. Con el túnel caído y el bloqueo desactivado, debe responder directamente, lo que demuestra que el destino está vivo. Solo entonces un fallo en el estado bloqueado te dice algo.
Ejecuta las transiciones en un orden fijo
Toma las transiciones de una en una y dale a cada una unos segundos para asentarse, porque los clientes a menudo desmontan y reconstruyen reglas en ese hueco. Ejecutar la misma comprobación breve cada vez mantiene las observaciones comparables:
curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
La fila de salir de la aplicación merece su propia ejecución aunque nunca cierres el cliente en el uso normal. Si el bloqueo se libera al salir, un fallo o una actualización forzada te dan la misma exposición, y eso es un hecho sobre el despliegue, no sobre tu paciencia. En Windows las sondas equivalentes son Resolve-DnsName decoy.example y curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.
Separa un bloqueo de un resolutor roto
Una página que no carga tiene varias causas, y solo una es que el interruptor funcione. Si el nombre no se resuelve, has aprendido que el DNS está bloqueado o roto, no que la ruta de datos esté bloqueada. Sondea también una dirección literal, para que la respuesta no dependa en absoluto de la resolución.
Los códigos de salida de curl separan esos casos: 6 es un fallo de resolución de nombres, 7 significa que se rechazó la conexión, 28 es un tiempo de espera. Una ruta bloqueada suele aparecer como un tiempo de espera o un rechazo contra una dirección literal. Un bloqueo solo de DNS deja un 6 y oculta todo lo demás. Una página en caché o un portal cautivo engañan al ojo, y por eso la prueba es el código de salida, no la pantalla.
Repite la sonda sobre IPv6 con una dirección literal. Un bloqueo que cubre IPv4 e ignora IPv6 es lo bastante común como para merecer su propia línea en tus notas, y un cliente que desactiva IPv6 fuera del túnel debería fallar limpiamente en ambas familias.
Anota el alcance que cubre el resultado
Cuando el túnel vuelva, confirma la recuperación: el señuelo responde a través del túnel, el resolutor devuelve respuestas y la política se queda donde la dejaste. Después deshaz los experimentos. Una regla de cortafuegos temporal, una ruta de depuración o un perfil de prueba que se queden en su sitio confundirán la siguiente ejecución y pueden sobrevivir a la aplicación.
Una sola pasada cubre una versión del cliente, un perfil, una transición y una familia de direcciones. Anota esos cuatro junto con el resultado:
- Versión del cliente y plataforma, y si el ajuste es por perfil o global.
- Perfil, protocolo y cualquier exclusión de túnel dividido.
- Transición probada, y cómo la desencadenaste.
- Familias de direcciones y DNS, con los códigos de salida de curl para los estados bloqueado y desbloqueado.
Si alguna línea queda en blanco, la prueba no ha terminado. La itinerancia significa repetir la fila del cambio de red. Un reinicio sin supervisión significa comprobar que las reglas vuelven, que es una pregunta sobre el orden de restauración y no sobre el interruptor. Repite la secuencia tras una actualización del cliente, porque los conmutadores rara vez cambian mientras el comportamiento que hay detrás sí lo hace. Guarda el señuelo: nada que rotar y la próxima comprobación tarda cinco minutos.