Come bloccare l’uscita di Linux perché non filtri nulla quando la VPN cade

Immagina un box multimediale su un collegamento domestico che dovrebbe raggiungere internet solo attraverso un tunnel. Quando il tunnel cade, l’applicazione dovrebbe bloccarsi invece di continuare silenziosamente sull’interfaccia fisica. Ottenere questo comportamento è un problema di firewall e non di instradamento, e la distinzione conta perché una rotta può essere sostituita riavviando il demone mentre un filtro resta dove l’hai messo. Qui di seguito vediamo come decide davvero il percorso del pacchetto e poi come delimitare le eccezioni che tengono il tunnel in riconnessione.

L’uscita locale è un hook diverso dall’inoltro

Un pacchetto che lascia un’applicazione sulla macchina attraversa l’hook di uscita; un pacchetto che la macchina instrada per un altro host attraversa l’inoltro. Una politica che nomina solo forward vincola il secondo e lascia il primo completamente aperto, ed è per questo che tanti blocchi di uscita sembrano corretti e non fanno nulla. La corrispondenza dell’interfaccia appartiene alla stessa regola: oifname "tun0" accept lascia passare il traffico già instradato fuori dal tunnel. Anche instradamento e filtraggio restano decisioni separate, quindi può esistere una rotta di collegamento mentre il filtro rifiuta il pacchetto. Su questa separazione fai affidamento.

Un gateway che inoltra per altri dispositivi ha bisogno di entrambi gli hook. Bloccare solo l’uscita protegge la macchina stessa e lascia ogni client a valle libero di filtrare.

Scrivi l’elenco delle eccezioni dall’endpoint verso l’esterno

Parti dall’endpoint del tunnel: un indirizzo di destinazione o un piccolo insieme approvato, il protocollo di trasporto e la porta di destinazione, per esempio udp dport 1194 ip daddr 203.0.113.7 accept. Se il client risolve un nome host, lo scambio DNS iniziale ha bisogno di una propria regola limitata al resolver e alla porta 53, non di un permesso generale verso l’indirizzo di quel resolver. Ogni eccezione dovrebbe nominare il motivo per cui esiste. Un permesso per tutto il traffico UDP verso la porta della VPN copre molto più dell’unico servizio autenticato che avevi in mente.

La risoluzione iniziale è il punto in cui i blocchi di solito marciscono. Un insieme di indirizzi aggiornato da un timer ha bisogno di un comportamento definito quando l’aggiornamento fallisce, e quel comportamento non può essere aprire il collegamento finché non riesce. Aggiorna attraverso il tunnel mentre il tunnel è attivo e, altrimenti, torna all’ultimo endpoint sano conosciuto.

L’amministrazione locale ha bisogno dello stesso trattamento. Una sottorete di gestione non è affidabile solo perché i suoi indirizzi sono privati, e una regola che si fida di essa invita un secondo percorso attorno al blocco.

La corrispondenza dell’interfaccia non prova un tunnel sano

Le regole che accettano tutto ciò che esce da tun0 presumono che un pacchetto su quell’interfaccia provenga dal tunnel. I nomi delle interfacce vengono ricreati, e un nome non è un’identità crittografica. Anche il peer può essere sparito mentre l’interfaccia resta attiva, il che rende la regola un’inazione molto convincente.

Il tracciamento delle connessioni aggiunge una trappola correlata. Una regola ampia per le connessioni stabilite riproduce il permesso che un flusso aveva ottenuto prima, così una sessione iniziata prima della caduta del tunnel continua dopo. Limita l’accettazione con stato alle interfacce e agli indirizzi che intendi davvero, altrimenti hai costruito un blocco che si apre da solo. Anche le regole di ingresso e di uscita rispondono a domande diverse, e irrigidire l’una ignorando l’altra lascia la macchina raggiungibile nella direzione che non hai considerato.

Cosa sopravvive a un crash del demone

Un filtro installato da uno script che viene eseguito dopo che il tunnel sale sparisce insieme al tunnel, proprio nel momento in cui serviva. Carica il blocco all’avvio e lascia che il demone gestisca solo le sue eccezioni.

Anche cancellare la rotta predefinita non è un sostituto. La rotta è stato che il demone possiede e riscrive, e rimuoverla può togliere il percorso necessario per riconnettersi. IPv6 ha bisogno di un proprio piano, perché la scoperta dei vicini e gli annunci del router sono servizi di collegamento che devono continuare a funzionare mentre il traffico ordinario è bloccato. DHCP rientra nella stessa categoria. Annota queste cose come eccezioni con uno scopo, invece di scoprirle più tardi sotto forma di interruzioni.

Percorso di recupero prima del rilascio

Prova il blocco nel modo in cui fallirà: avvio senza tunnel, uccisione del demone, cambio dell’endpoint e riconnessione. Ogni caso dovrebbe bloccare le applicazioni e lasciare funzionante il canale di recupero. Fallo da una console, perché una shell remota è la sessione che più probabilmente verrà chiusa fuori dalla tua stessa regola.

Poi controlla a cosa può ancora arrivare un’applicazione comune, con una destinazione innocua e una richiesta che puoi verificare. Il risultato che vuoi è un rifiuto sul collegamento e un successo attraverso il tunnel, non un timeout ambiguo che potrebbe significare entrambe le cose. Tieni l’insieme di regole sotto lo stesso proprietario del resto del firewall invece di sostituire l’intera tabella da uno script di shell. Una politica in cui ogni permesso può giustificarsi vale più di un lungo insieme di regole che nessuno sa spiegare.