VPN always-on ou kill switch: cal activou de verdade?

Always-on e kill switch están a dúas liñas na mesma pantalla de axustes, por iso a xente les como dous nomes dunha soa función. Non o son. Always-on é unha política de reconexión: inicia o túnel ao arrincar, recupérao tras unha caída ou un cambio de rede e segue intentándoo mentres falla. Un kill switch é unha política de tráfico: nomea os paquetes que aínda poden saír do equipo mentres o túnel está caído. Pode activar o primeiro sen o segundo, e na maioría das plataformas o resultado de fábrica aínda deixa saír tráfico durante o oco.

Comprobación 1: o bloqueo é un interruptor propio?

En Android 10 e posteriores, un perfil de VPN gardado abre tras a icona do engrenaxe dous interruptores independentes: VPN always-on e Bloquear conexións sen VPN. Só o segundo é o kill switch. Con só always-on o túnel volve tras unha caída, pero calquera aplicación a metade dunha petición chega á rede por Wi-Fi ou datos móbiles ata que iso ocorre.

Os equipos xestionados manteñen a mesma división na API de políticas. setAlwaysOnVpnPackage() toma o nome do paquete e un indicador lockdownEnabled; quen fixa o paquete e deixa o indicador en falso construíu un túnel persistente, non un equipo pechado. A redacción da consola raramente fai visible esa diferenza.

Lea o estado desde o dispositivo e non desde a consola: adb shell settings get global always_on_vpn_app e adb shell settings get global always_on_vpn_lockdown. Se o primeiro devolve null, non hai ningún paquete imposto a nivel de plataforma; se o segundo devolve 0, a plataforma non bloquea nada. A guía de VPN de Android describe estas como capacidades separadas e non como un só modo.

Comprobación 2: que capa posúe o bloqueo?

As etiquetas viven no cliente e os bloqueos adoitan vivir na devasa, por iso a mesma palabra significa cousas distintas en cada plataforma. As filas de abaixo merecen confirmación antes de confiar en calquera.

Windows é o exemplo máis claro dunha etiqueta que non bloquea. Always On alí describe a persistencia do túnel: un túnel de dispositivo para a autenticación da máquina, un túnel de usuario para a conta iniciada, configurados por XML de perfil ou Add-VpnConnection. Nada nese perfil detén un paquete saínte cando falta o túnel, e o filtrado de saída non está activo por defecto, así que un portátil en Wi-Fi segue funcionando mentres a VPN está caída.

WireGuard divídese igual, pero por cliente. WireGuard para Windows leva unha opción por túnel, Bloquear tráfico non tunelizado, que instala regras de filtro; as ferramentas de Linux non teñen ese interruptor. wg-quick engade unha ruta por cada entrada AllowedIPs máis unha regra fwmark, e wg-quick down elimina ambas, así que a ruta física por defecto volve mandar sen perder ningún paquete entre medias.

Nas plataformas de Apple, always-on chega como función de perfil de xestión para equipos supervisados e exprésase como regras baixo demanda, non como unha casiña. A pregunta que hai que responder desde a carga é se un túnel fallido denega o tráfico ou só pide outra conexión. O título do menú non llo dirá.

Comprobación 3: mida o oco, non a icona

Catro transicións importan e fallan de forma distinta: arrinque antes de que ninguén inicie sesión, suspensión e reanudación, un cambio de Wi-Fi a datos móbiles e unha caída do cliente que deixa a interface do túnel a medio configurar. Unha reconexión limpa nunha delas non demostra nada sobre as outras tres.

A proba máis barata detén o túnel a propósito e logo tenta saír. Co túnel caído, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com devolvendo 200 significa que a política é fail-open; un tempo esgotado ou unha conexión rexeitada significa que algo segue bloqueando. ip route get 1.1.1.1 nomea a interface que levaría o paquete, o que adoita dicir máis que a icona da bandexa, e systemctl status wg-quick@wg0 mostra se a interface se retirou limpiamente.

Execute a mesma proba nunha segunda xanela mentres a rede cambia, non só despois. O intervalo entre a caída e o reintento é a parte que importa, e unha consulta de nome é a forma máis rápida de notar que o tráfico escapou: se o resolutor local responde mentres o túnel está caído, o bloqueo non está completo.

Comprobación 4: decida as excepcións antes de pechar

Dúas excepcións son estruturais. O cliente ten que chegar ao propio servidor de VPN, así que un conxunto de regras que descarta todo tamén impide a reconexión que restauraría a protección. Un portal cativo tampouco é accesible por un túnel que non está levantado, así que un equipo bloqueado no Wi-Fi dun hotel necesita unha forma documentada de abrir o portal, non improvisada.

Unha forma mínima, punto final permitido e todo o demais descartado:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Trate esa liña de punto final como unha variable, non como unha constante. Os provedores rotan enderezos, e unha excepción obsoleta é a razón habitual de que un kill switch que funcionaba se converta nun equipo que non pode reconectar. As impresoras locais, os recursos compartidos NAS e os servizos de desenvolvemento pertencen á mesma lista escrita, ou descóbrense un ticket de soporte á vez.

Comprobación 5: rexistre que demostrou de verdade

Manteña unha táboa de catro columnas e énchaa probando: estado, comportamento esperado, comportamento observado, evidencia. As filas son as transicións da comprobación 3 máis un fallo deliberado. Unha fila que non pode encher con saída de comando é unha fila que non probou, e un equipo que pasa a fila de reconexión e falla a de arrinque é abondo común para valer os dez minutos extra.

Antes de dalo por feito:

• Confirme que o axuste de bloqueo está separado do de reconexión, e lea o seu valor no dispositivo.
• Saiba que capa aplica o bloqueo - opción do cliente, política do equipo ou devasa - e onde se configura esa capa.
• Garde un comando de proba que demostre o bloqueo, e execúteo durante unha transición e non despois.
• Escriba a lista de excepcións, punto final incluído, e anote quen a actualiza.
• En hardware xestionado, deixe a política imposta en paz; quitar o bloqueo cambia o requisito en lugar de arranxar o túnel.