Script de baixada ou regra de cortalumes: cal detén a fuga?

Dous deseños prometen o mesmo: cando o túnel cae, nada sae ao exterior en claro. Un executa un script ao desmontar e corta as interfaces. O outro deixa unha regra de cortalumes en vigor e non lle pide nada ao cliente VPN. Diferéncianse en quen ten o privilexio de actuar, en que ocorre durante o oco e en como a máquina volve estar en liña despois. Comparalos neses tres puntos é máis útil que discutir cal é máis estrito.

O mesmo traballo con dous mecanismos

O cliente pode executar ganchos cando o túnel sobe e cando se desmonta, sempre que o perfil permita executar scripts. Ese gancho execútase dentro do ciclo de vida do cliente, no momento en que a conexión se pecha. Unha regra de cortalumes, pola contra, pertence ao sistema e non lle importa se o cliente está a funcionar, colgou ou foi matado.

Esa táboa é todo o argumento. Un script que só se executa nun peche ordenado cobre o caso que menos lle preocupaba; o caso que importa é o fallo ou a desaparición da rede, e ningún dos dous produce unha desmontaxe limpa.

Que pode e que non pode facer o gancho de desmontaxe

O patrón documentado percorre as interfaces de rede e baixa todo excepto loopback. Co dispositivo físico baixado, nada pode escapar fóra do túnel, que é exactamente a intención.

#!/bin/sh
for dev in /sys/class/net/*; do
  name=$(basename "$dev")
  [ "$name" = lo ] || ip link set dev "$name" down
done

Tamén baixa a rede local, calquera servizo que aloxe a máquina e a ruta que usaría para arranxar o problema. Nun portátil o dispositivo sen fíos ás veces necesita un cambio manual despois, así que unha interrupción breve convértese nunha sesión de reparación. Peor aínda, pode que non se lle permita ao gancho facer nada diso: cando o cliente renuncia aos privilexios, o script de desmontaxe execútase coa conta sen privilexios e cada cambio de interface falla cun erro de permisos escrito no momento en que ninguén le o rexistro.

Comprobe como se inicia o cliente antes de confiar no gancho. Un script que funciona ao executalo a man como root non demostra nada sobre o servizo que arrinca no inicio.

Que fai distinta a regra de cortalumes

Unha regra que só permite o tráfico do túnel segue funcionando cando o proceso do cliente desapareceu, porque o núcleo non depende dese proceso. A regra tamén é máis estreita: bloquea exactamente os fluxos que coincide e deixa en paz loopback, a subrede local e a ruta de recuperación, e por iso non deixa a máquina illada.

O prezo é que a regra debe escribila e mantela quen posúe o cortalumes do equipo, e ten que nomear o dispositivo de túnel que o cliente crea realmente. Iso significa que a regra e o perfil deben manterse xuntos; unha interface renomeada deixa un cortalumes que o bloquea todo e non explica nada.

Ningún dos dous mecanismos fai superfluo o outro. Unha regra de cortalumes que nunca se recarga tras unha edición é tan ficticia como un script que nunca se executa.

persist-tun decide se existe un oco

Cando o dispositivo de túnel sobrevive a unha desconexión, as rutas que apuntan a el tamén sobreviven. O tráfico entón descártase en lugar de redirixirse, así que a ruta por defecto non volve á pasarela física. Ese é o comportamento que fai improbable unha fuga mesmo antes de que interveña ningunha regra de cortalumes.

Sen ese axuste, o dispositivo elimínase e as rutas con el, e a ruta por defecto pode volver resolverse cara a pasarela física. Se o fai depende da plataforma e do cliente, e por iso mesmo o estado debe observarse en lugar de supoñerse. Trate o axuste como parte do kill switch, non como unha opción de rendemento.

Manteña vivo o camiño de reconexión e despois probe catro estados

Un bloqueo estrito tamén pode impedir que o cliente se reconecte, porque o cliente segue necesitando unha ruta ao servidor a través da pasarela física mentres todo o demais se denega. Instale unha ruta de host para esa única dirección antes de que suba o túnel, e resolva o nome primeiro, porque o DNS pode estar bloqueado cando o necesite.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Despois verifique os estados e non a etiqueta. Practique catro momentos a propósito: un arrinque en frío sen túnel, unha sesión sá, unha caída que ninguén pediu e a sesión despois de que se recupere. En cada momento lea a ruta por defecto e faga unha petición cuxa dirección de saída sexa visible. Unha aplicación que se rende mentres o túnel está abaixo non di nada dun cliente de correo nin dun actualizador, así que repita a última comprobación cunha aplicación en segundo plano. Anote a regra, os nomes das interfaces e os pasos de recuperación, porque un kill switch que ninguén pode verificar é un rumor.