Interruptor de seguridade VPN: que tráfico bloquea e cando
A reconexión restaura un túnel; o interruptor decide que pasa mentres non está. Proba por separado a perda, a desconexión manual, a saída da aplicación e o cambio de rede.
Dúas funcións descríbense coa mesma palabra e fan traballos distintos. A reconexión automática tenta devolver o túnel, e pode logralo nun segundo mentres as peticións fallan nese oco. O interruptor decide que ocorre co tráfico durante ese oco. Ler un cliente como se as dúas cousas fosen un só axuste é a forma en que a xente acaba confiando nunha icona en lugar dunha política.
Bloquear e reconectar son decisións separadas
Un cliente bloquea só cando a perda é inesperada, e despois reconéctase e levanta o bloqueo. Outro mantén un bloqueo a nivel de sistema ata que alguén cambia un axuste a man, e un terceiro trata unha desconexión deliberada como permiso para restaurar o acceso normal. Son tres comportamentos distintos, e a documentación do provedor di cal implementa a túa compilación.
Nada da importación dun perfil decide esa cuestión. O mesmo perfil de servidor cárgase en dous clientes con comportamentos de bloqueo opostos, porque o perfil leva axustes e non unha promesa. Por iso tamén unha caixa de escritorio e un interruptor móbil con etiquetas parecidas poden implementar regras diferentes. Le a descrición xunto ao control da túa plataforma e despois proba que fai.
O mesmo perfil compórtase distinto en dous clientes
Os axustes da aplicación OpenVPN Connect describen un modo de túnel que retén o tráfico ordinario só mentres o cliente informa dun estado de pausa ou de reconexión, o que é máis estreito que unha promesa xeral sobre cada evento en cada plataforma. Le os estados enumerados, non o nome do produto. Unha descrición escrita para unha compilación de cliente non se traslada ao cliente doutro provedor.
Android mostra a mesma palabra en dous controis, porque a VPN sempre activa e o bloqueo de conexións sen VPN documéntanse por separado. Un cliente de escritorio cunha caixa de nome parecido pode implementar algo máis estreito ou máis amplo que calquera dos dous. Considera unha etiqueta compartida en dous menús unha coincidencia ata que se leran ambas descricións. Os dispositivos xestionados engaden unha terceira capa, porque un perfil de dispositivo pode impoñer un axuste que o usuario non ve nin pode anular.
Axustes de plataforma parecidos non son equivalentes
Compara o control que ves coa política que se aplica de verdade. Nun dispositivo xestionado o interruptor visible pode estar en gris, ou pode estar activado mentres un perfil de nivel superior impón o contrario. Pide a política efectiva e non a local, e consegue a resposta por escrito.
Anota que afirma cada capa antes de probar nada, porque as dúas adoitan discrepar e a discrepancia pérdese con facilidade unha vez que comezan as probas. Un dispositivo que bloquea correctamente durante unha proba pode estar bloqueando por un motivo que ninguén documentou.
Executa un evento cada vez e anota o código
Proba un evento por execución, cunha petición inofensiva, e fai que cada intento sexa unha petición nova en lugar dunha páxina que quizais xa estea na caché. Os comandos de abaixo baixan o túnel, piden unha páxina e mostran se a interface volveu.
ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0A táboa relaciona cada acción coa observación que importa e coa evidencia que merece conservarse. Unha petición que falla dentro do tempo de espera dixe que o bloqueo se activou; unha petición que pasa dixe que o tráfico atopou outra ruta, que pode ser unha ruta excluída e non un bloqueo desactivado. Repite todo o conxunto tras unha actualización de software significativa ou un cambio de política de encamiñamento, porque calquera das dúas pode alterar a rama sen que se mova ningún axuste visible. Ao final queres un comportamento de fallo previsible, non unha icona tranquilizadora.
| What I do | What I watch | Evidence to keep |
|---|---|---|
| Bring the tunnel down by hand | Whether a fresh request fails at once | The HTTP code and the client state at that second |
| Choose Disconnect in the client | Whether ordinary access returns on purpose | The same request succeeding with no tunnel up |
| Quit the app, then reboot | Whether the block outlives the client | A request made from a clean boot |
| Move from Wi-Fi to cellular | Whether DNS and IPv6 follow the policy | The resolver answer, the route table and the code again |
Excepcións, portais de convidados e que non pode un bloqueo
O acceso á rede local é a excepción habitual, e cambia o alcance da promesa. Un cliente pode chegar a unha impresora da mesma subrede mentres bloquea todo o demais, o que é razoable na casa e discutible nunha rede de convidados. Decide se queres esa excepción antes de que un incidente a descubra por ti.
Un bloqueo estrito tamén fai incómoda a entrada ao portal dunha rede de convidados, porque o portal é exactamente o tráfico directo que o bloqueo existe para deter. Aprende a forma admitida de autorizar a rede e despois restaura a política a propósito en lugar de apagar controis ata que cargue unha páxina. Garda a resposta do resolutor e a táboa de rutas na mesma nota, como abaixo. O que un interruptor non pode facer é volver anónimo o servizo, porque bloquear o tráfico fóra do túnel non di nada sobre o que ocorre dentro.
resolvectl query example.com
ss -tunp | grep -v tun0