Script di dismissione o regola del firewall: quale ferma la fuga?

Due progetti promettono la stessa cosa: quando il tunnel cade, niente esce in chiaro. Uno esegue uno script alla dismissione e taglia le interfacce. L’altro lascia in vigore una regola del firewall e non chiede nulla al client VPN. Differiscono per chi ha il privilegio di agire, per ciò che accade durante la lacuna e per come la macchina torna in rete dopo. Confrontarli su questi tre punti è più utile che discutere di quale sia più rigido.

Lo stesso lavoro con due meccanismi

Il client può eseguire hook quando il tunnel sale e quando viene dismesso, purché il profilo consenta l’esecuzione di script. Quell’hook gira nel ciclo di vita del client, nel momento in cui la connessione si chiude. Una regola del firewall, al contrario, appartiene al sistema e non si cura se il client è in esecuzione, si è bloccato o è stato ucciso.

Quella tabella è tutto l’argomento. Uno script che gira solo a una chiusura pulita copre il caso che vi preoccupava meno; il caso che conta è il blocco o la rete che sparisce, e nessuno dei due produce una dismissione pulita.

Cosa può e cosa non può fare l’hook di dismissione

Lo schema documentato percorre le interfacce di rete e abbassa tutto tranne loopback. Con il dispositivo fisico abbassato, nulla può uscire fuori dal tunnel, che è esattamente l’intento.

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

Abbassa anche la rete locale, ogni servizio che la macchina ospita e il percorso che usereste per riparare il problema. Su un portatile il dispositivo wireless a volte richiede un cambio manuale dopo, così una breve interruzione diventa una sessione di riparazione. Peggio, all’hook potrebbe non essere permesso fare nulla di tutto ciò: quando il client rinuncia ai privilegi, lo script di dismissione gira con l’account senza privilegi e ogni modifica dell’interfaccia fallisce con un errore di permessi scritto nel momento in cui nessuno legge il registro.

Controllate come viene avviato il client prima di fidarvi dell’hook. Uno script che funziona quando lo eseguite a mano come root non dimostra nulla sul servizio che parte all’avvio.

Cosa fa diversamente la regola del firewall

Una regola che consente solo il traffico del tunnel continua a funzionare quando il processo del client è sparito, perché il kernel non dipende da quel processo. La regola è anche più stretta: blocca esattamente i flussi che intercetta e lascia in pace loopback, la sottorete locale e il percorso di ripristino, ed è per questo che non lascia la macchina isolata.

Il prezzo è che la regola deve essere scritta e mantenuta da chi possiede il firewall dell’host, e deve nominare il dispositivo di tunnel che il client crea davvero. Questo significa che la regola e il profilo vanno mantenuti insieme; un’interfaccia rinominata lascia un firewall che blocca tutto e non spiega nulla.

Nessuno dei due meccanismi rende superfluo l’altro. Una regola del firewall mai ricaricata dopo una modifica è fittizia quanto uno script che non viene mai eseguito.

persist-tun decide se esiste una lacuna

Quando il dispositivo di tunnel sopravvive a una disconnessione, sopravvivono anche le rotte che puntano a esso. Il traffico viene quindi scartato anziché reindirizzato, così la rotta predefinita non ricade sul gateway fisico. È questo comportamento che rende improbabile una fuga ancora prima che entri in gioco qualsiasi regola del firewall.

Senza questa impostazione il dispositivo viene rimosso e le rotte con lui, e la rotta predefinita può tornare a puntare al gateway fisico. Se lo faccia dipende dalla piattaforma e dal client, ed è proprio per questo che lo stato va osservato anziché dato per scontato. Trattate l’impostazione come parte del kill switch, non come un’opzione di prestazione.

Tenete vivo il percorso di riconnessione, poi provate quattro stati

Un blocco rigoroso può anche impedire al client di riconnettersi, perché il client ha ancora bisogno di una rotta verso il server attraverso il gateway fisico mentre tutto il resto è negato. Installate una rotta host per quell’unico indirizzo prima che il tunnel salga, e risolvete prima il nome, perché il DNS potrebbe essere bloccato nel momento in cui vi servirà.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Poi verificate gli stati e non l’etichetta. Esercitate quattro momenti di proposito: un avvio a freddo senza tunnel, una sessione sana, una caduta che nessuno ha chiesto e la sessione dopo che si riprende. In ogni momento leggete la rotta predefinita e fate una richiesta di cui sia visibile l’indirizzo di uscita. Un’applicazione che si arrende mentre il tunnel è abbassato non dice nulla di un client di posta o di un programma di aggiornamento, quindi ripetete l’ultimo controllo con un’applicazione in background. Annotate la regola, i nomi delle interfacce e i passi di ripristino, perché un kill switch che nessuno può verificare è una voce.