Script de baixada o regla de tallafoc: quina atura la fuita?

Dos dissenys prometen el mateix: quan el túnel cau, no surt res a l’exterior en clar. Un executa un script en desmuntar i talla les interfícies. L’altre deixa una regla de tallafoc en vigor i no demana res al client VPN. Difereixen en qui té el privilegi d’actuar, en què passa durant el buit i en com la màquina torna a estar en línia després. Comparar-los en aquests tres punts és més útil que discutir quin és més estricte.

La mateixa feina amb dos mecanismes

El client pot executar ganxos quan el túnel puja i quan es desmunta, sempre que el perfil permeti executar scripts. Aquest ganxo s’executa dins del cicle de vida del client, en el moment que la connexió es tanca. Una regla de tallafoc, en canvi, pertany al sistema i no li importa si el client funciona, s’ha penjat o l’han matat.

Aquesta taula és tot l’argument. Un script que només s’executa en un tancament ordenat cobreix el cas que menys us preocupava; el cas que importa és la fallada o la desaparició de la xarxa, i cap dels dos produeix un desmuntatge net.

Què pot fer el ganxo de desmuntatge i què no

El patró documentat recorre les interfícies de xarxa i abaixa tot excepte loopback. Amb el dispositiu físic abaixat, res no pot escapar fora del túnel, que és exactament la intenció.

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

També abaixa la xarxa local, qualsevol servei que allotgi la màquina i el camí que faríeu servir per arreglar el problema. En un portàtil el dispositiu sense fils de vegades necessita un canvi manual després, així que una breu interrupció es converteix en una sessió de reparació. Pitjor encara, potser no es permet al ganxo fer res d’això: quan el client renuncia als privilegis, l’script de desmuntatge s’executa amb el compte sense privilegis i cada canvi d’interfície falla amb un error de permisos escrit en el moment que ningú llegeix el registre.

Comproveu com s’inicia el client abans de confiar en el ganxo. Un script que funciona quan el executeu a mà com a root no demostra res sobre el servei que arrenca a l’engegada.

Què fa diferent la regla de tallafoc

Una regla que només permet el trànsit del túnel continua funcionant quan el procés del client ha desaparegut, perquè el nucli no depèn d’aquest procés. La regla també és més estreta: bloqueja exactament els fluxos que coincideixen i deixa en pau loopback, la subxarxa local i el camí de recuperació, i per això no deixa la màquina aïllada.

El preu és que la regla l’ha d’escriure i mantenir qui posseeix el tallafoc de l’amfitrió, i ha de anomenar el dispositiu de túnel que el client crea realment. Això vol dir que la regla i el perfil s’han de mantenir junts; una interfície reanomenada deixa un tallafoc que ho bloqueja tot i no explica res.

Cap dels dos mecanismes fa l’altre redundant. Una regla de tallafoc que no es recarrega mai després d’una edició és tan fictícia com un script que no s’executa mai.

persist-tun decideix si hi ha un buit

Quan el dispositiu de túnel sobreviu a una desconnexió, les rutes que hi apunten també sobreviuen. Llavors el trànsit es descarta en lloc de redirigir-se, així que la ruta per defecte no torna a la passarel·la física. Aquest és el comportament que fa improbable una fuita fins i tot abans que hi intervingui cap regla de tallafoc.

Sense aquest paràmetre, el dispositiu s’elimina i les rutes amb ell, i la ruta per defecte pot tornar a resoldre’s cap a la passarel·la física. Si ho fa depèn de la plataforma i del client, i per això mateix l’estat s’ha d’observar en lloc de suposar. Tracteu el paràmetre com a part del kill switch, no com una opció de rendiment.

Manteniu viu el camí de reconnexió i després proveu quatre estats

Un blocatge estricte també pot impedir que el client es reconnecti, perquè el client encara necessita una ruta al servidor a través de la passarel·la física mentre tota la resta es denega. Instal·leu una ruta d’amfitrió per a aquesta única adreça abans que pugi el túnel, i resoleu el nom primer, perquè el DNS pot estar bloquejat quan el necessiteu.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Després verifiqueu els estats i no l’etiqueta. Exerciteu quatre moments deliberadament: una arrencada en fred sense túnel, una sessió sana, una caiguda que ningú no ha demanat i la sessió després que es recuperi. A cada moment llegiu la ruta per defecte i feu una petició l’adreça de sortida de la qual sigui visible. Una aplicació que es rendeix mentre el túnel és avall no diu res d’un client de correu o d’un actualitzador, així que repetiu l’última comprovació amb una aplicació en segon pla. Anoteu la regla, els noms de les interfícies i els passos de recuperació, perquè un kill switch que ningú pot verificar és un rumor.