Dos funciones se describen con la misma palabra y hacen trabajos distintos. La reconexión automática intenta devolver el túnel, y puede lograrlo en un segundo mientras las peticiones fallan en ese hueco. El interruptor decide qué ocurre con el tráfico durante ese hueco. Leer un cliente como si ambas cosas fueran un solo ajuste es la forma en que la gente acaba confiando en un icono en lugar de una política.

Bloquear y reconectar son decisiones separadas

Un cliente bloquea solo cuando la pérdida es inesperada, y después se reconecta y levanta el bloqueo. Otro mantiene un bloqueo a nivel de sistema hasta que alguien cambia un ajuste a mano, y un tercero trata una desconexión deliberada como permiso para restaurar el acceso normal. Son tres comportamientos distintos, y la documentación del proveedor dice cuál implementa tu compilación.

Nada de la importación de un perfil decide esa cuestión. El mismo perfil de servidor se carga en dos clientes con comportamientos de bloqueo opuestos, porque el perfil lleva ajustes y no una promesa. Por eso también una casilla de escritorio y un interruptor móvil con etiquetas parecidas pueden implementar reglas diferentes. Lee la descripción junto al control de tu plataforma y luego prueba qué hace.

El mismo perfil se comporta distinto en dos clientes

Los ajustes de la aplicación OpenVPN Connect describen un modo de túnel que retiene el tráfico ordinario solo mientras el cliente informa de un estado de pausa o de reconexión, lo que es más estrecho que una promesa general sobre cada evento en cada plataforma. Lee los estados enumerados, no el nombre del producto. Una descripción escrita para una compilación de cliente no se traslada al cliente de otro proveedor.

Android muestra la misma palabra en dos controles, porque la VPN siempre activa y el bloqueo de conexiones sin VPN se documentan por separado. Un cliente de escritorio con una casilla de nombre parecido puede implementar algo más estrecho o más amplio que cualquiera de los dos. Considera una etiqueta compartida en dos menús una coincidencia hasta que se hayan leído ambas descripciones. Los dispositivos gestionados añaden una tercera capa, porque un perfil de dispositivo puede imponer un ajuste que el usuario no ve ni puede anular.

Ajustes de plataforma parecidos no son equivalentes

Compara el control que ves con la política que se aplica de verdad. En un dispositivo gestionado el interruptor visible puede estar en gris, o puede estar activado mientras un perfil de nivel superior impone lo contrario. Pide la política efectiva y no la local, y consigue la respuesta por escrito.

Anota qué afirma cada capa antes de probar nada, porque las dos suelen discrepar y la discrepancia se pierde con facilidad una vez que empiezan las pruebas. Un dispositivo que bloquea correctamente durante una prueba puede estar bloqueando por un motivo que nadie documentó.

Ejecuta un evento cada vez y anota el código

Prueba un evento por ejecución, con una petición inofensiva, y haz que cada intento sea una petición nueva en lugar de una página que quizá ya esté en caché. Los comandos de abajo bajan el túnel, piden una página y muestran si la interfaz volvió.

ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0

La tabla relaciona cada acción con la observación que importa y con la evidencia que merece conservarse. Una petición que falla dentro del tiempo de espera te dice que el bloqueo se activó; una petición que pasa te dice que el tráfico encontró otra ruta, que puede ser una ruta excluida y no un bloqueo desactivado. Repite todo el conjunto tras una actualización de software significativa o un cambio de política de enrutamiento, porque cualquiera de las dos puede alterar la rama sin que se mueva ningún ajuste visible. Al final quieres un comportamiento de fallo predecible, no un icono tranquilizador.

What I doWhat I watchEvidence to keep
Bring the tunnel down by handWhether a fresh request fails at onceThe HTTP code and the client state at that second
Choose Disconnect in the clientWhether ordinary access returns on purposeThe same request succeeding with no tunnel up
Quit the app, then rebootWhether the block outlives the clientA request made from a clean boot
Move from Wi-Fi to cellularWhether DNS and IPv6 follow the policyThe resolver answer, the route table and the code again

Excepciones, portales de invitados y qué no puede un bloqueo

El acceso a la red local es la excepción habitual, y cambia el alcance de la promesa. Un cliente puede llegar a una impresora de la misma subred mientras bloquea todo lo demás, lo que es razonable en casa y discutible en una red de invitados. Decide si quieres esa excepción antes de que un incidente la descubra por ti.

Un bloqueo estricto también hace incómoda la entrada al portal de una red de invitados, porque el portal es exactamente el tráfico directo que el bloqueo existe para detener. Aprende la forma admitida de autorizar la red y luego restaura la política a propósito en lugar de apagar controles hasta que cargue una página. Guarda la respuesta del resolutor y la tabla de rutas en la misma nota, como abajo. Lo que un interruptor no puede hacer es volver anónimo el servicio, porque bloquear el tráfico fuera del túnel no dice nada sobre lo que ocurre dentro.

resolvectl query example.com
ss -tunp | grep -v tun0

Artículos relacionados