Perché una regola di blocco del client OpenVPN non arriva mai a FORWARD

Due client sullo stesso server OpenVPN possono raggiungersi anche dopo che hai aggiunto una regola DROP per il loro pool. La regola sta nella catena FORWARD, il traffico scorre chiaramente e il contatore di quella regola resta a zero. La conclusione naturale è che il firewall sia rotto. Più spesso il pacchetto non è mai entrato nella catena.

Esistono due percorsi che un pacchetto di un peer può seguire attraverso un server OpenVPN, e li decide la configurazione, non il firewall. Sapere quale percorso è in uso ti dice se una regola dell'host è persino nel posto giusto.

Due percorsi che un pacchetto di un peer può seguire

Con l'opzione di inoltro interno disattivata, un pacchetto dal cliente A arriva sull'interfaccia del tunnel con una destinazione all'interno dell'indirizzo assegnato al cliente B. La tabella di routing del server lo rimanda fuori dalla stessa interfaccia del tunnel, perché il server possiede la route verso l'indirizzo di B. È un flusso in entrata e in uscita attraverso l'host, e il percorso di inoltro IPv4 lo valuta.

Con l'opzione di inoltro interno attivata, il processo del server abbina il pacchetto a un client connesso e lo riscrive direttamente verso quel client. Il pacchetto viene gestito dentro il demone e non rientra mai nel dispositivo del tunnel, quindi il percorso di inoltro dell'host viene saltato del tutto. Il manuale di OpenVPN 2.6 descrive questa opzione come inoltro interno da client a client, ed è esattamente per questo che una regola del firewall dell'host non può vederla.

Esiste una terza variante nelle installazioni che spostano il canale dati su un modulo del kernel. La decisione di inoltro e la crittografia escono dallo spazio utente, e se netfilter vede il flusso dipende da come è costruito il percorso di offload. Non dare mai per scontato che un vecchio set di regole si comporti su un server con offload come su uno nello spazio utente. Conferma la modalità dalla configurazione in esecuzione, non dalla versione del pacchetto.

Quando il contatore non si muove mai

Un contatore a zero significa che il pacchetto non ha corrisposto a quella regola in quel punto, e le ragioni sono diverse. La prima è il bypass sopra: il traffico non ha mai raggiunto la catena. La seconda è una discrepanza nell'interfaccia, nella direzione, nella sorgente o nella destinazione, cosa comune quando il pool è stato rinumerato e la regola nomina ancora il vecchio prefisso.

La terza è la posizione. Una regola più in alto nella catena può accettare il flusso prima che il tuo DROP venga valutato, e una regola più in basso può essere quella che decide davvero l'esito. Leggi la catena in ordine con i contatori visibili, poi controlla quale contatore cresce quando ripeti il test.

Esegui uno scambio controllato tra due client di cui hai confermato gli indirizzi reali dallo stato del server stesso, non da un lease che ricordi. Se il contatore rilevante non si muove ancora, sospetta il percorso prima di riscrivere la corrispondenza. Se si muove ma la connessione riesce ancora, il drop viene sovrascritto più avanti e il problema è l'ordine. Questa risposta decide se la riparazione è un cambio di regola o un cambio di topologia, quindi ottienila prima di modificare qualsiasi cosa.

Scegliere un confine che possa filtrare

Se la policy deve vivere nel firewall dell'host, metti il traffico dove il firewall può vederlo. Disattivare l'inoltro interno è il modo supportato per far attraversare il traffico dei peer dall'interfaccia del tunnel e dal percorso di inoltro, al costo di far passare ogni pacchetto dei peer attraverso lo stack dell'host.

Poi abbina il flusso con precisione. Il traffico arriva sull'interfaccia del tunnel e ne esce, in entrambe le direzioni, quindi le regole che considerano solo l'interfaccia fisica non corrisponderanno. Le regole basate sugli indirizzi hanno bisogno del pool attuale e devono tenere conto della direzione di ritorno oltre a quella di andata.

Molte installazioni sono servite meglio da un filtraggio a livello di client o di gruppo, dove l'identità è nota e la policy segue l'utente invece di un indirizzo che cambia alla riconnessione. È un meccanismo diverso da una catena dell'host, e i due non dovrebbero essere mescolati senza una ragione chiara.

Non trasportare invariato il set di regole di una vecchia topologia attraverso una migrazione. Pool di indirizzi, nomi delle interfacce e modalità di inoltro influenzano tutti la corrispondenza di una regola, e una regola copiata che funzionava prima è il tipo di prova più fuorviante. Parti dal flusso che vuoi consentire e scrivi la regola che vi corrisponde.

Testare l'isolamento invece di fidarsi di una regola

Prova il caso vietato e il caso consentito nella stessa esecuzione. Avvia una nuova connessione da un client all'altro e conferma che fallisca, poi conferma che una connessione che dovrebbe essere permessa funziona ancora. Se si prova solo il primo, un firewall che blocca tutto sembra un successo.

Ripeti dopo aver ricaricato la configurazione del server e dopo che un client si riconnette, perché l'inoltro interno e le assegnazioni dei pool sono stato di runtime. Controlla i contatori in entrambe le direzioni, dato che una regola che corrisponde a una direzione e non alla risposta produce un isolamento parziale difficile da notare in un test rapido.

L'isolamento è il risultato osservato al confine che trasporta davvero il flusso. Una regola DROP da qualche parte nell'host non è una prova; una connessione fallita più un contatore spostato sulla regola che l'ha causata lo è.