Host iptables solo VPN: nominate il dispositivo tun, non tun+

Scrivere -o tun+ sembra un’istruzione precisa ed è in realtà un carattere jolly che copre ogni tunnel del kernel. Un secondo client VPN, un bridge per container o un’interfaccia lasciata da una sessione andata in crash la soddisfano tutti, e l’host allora consente traffico che la politica intendeva impedire. La procedura qui sotto fissa un solo nome di dispositivo, ordina le eccezioni perché il tunnel possa davvero formarsi e vi lascia una via di ritorno se le regole vanno male. Ogni passo è abbastanza breve da poter essere annullato da solo.

Passo 1: annotate le regole che avete adesso

Prima di cambiare una politica predefinita, salvate lo stato attuale così che il ripristino sia un comando e non un ricordo. iptables-save > /root/iptables.pre scrive ogni tabella in un file che potete ripristinare, e un secondo terminale con una sessione root aperta non è paranoia quando la politica che state per impostare taglia la connessione che la trasporta. Se lavorate in remoto, pianificate anche un flush come interruttore di sicurezza.

Poi elencate le interfacce, perché un nome che avete dato per scontato è un nome che avreste dovuto leggere: ip -br link mostra cosa esiste in questo momento, e il tunnel non apparirà finché non sarà attivo. Annotate i nomi dei dispositivi mentre li leggete.

Passo 2: date al tunnel un nome proprio

OpenVPN accetta dev tun_work nella configurazione del client, e Linux crea allora un’interfaccia con esattamente quel nome invece di assegnare tun0. Il nome resta stabile tra una riconnessione e l’altra finché nulla altro lo rivendica, ed è questo che rende significativa una regola che nomina il dispositivo.

Dove il nome non è controllabile, fate corrispondere invece l’indirizzo del tunnel o un contrassegno di pacchetto. Entrambi funzionano, entrambi sono più difficili da leggere ed entrambi falliscono più silenziosamente quando il tunnel rinumera. In ogni caso, fate corrispondere una sola cosa e siate espliciti su quale.

Passo 3: scrivete la politica con l’eccezione dell’endpoint prima

Un host solo VPN è un host con rifiuto predefinito e una breve lista di eccezioni, e l’eccezione che conta di più è quella che permette al tunnel di esistere. Costruitela in questo ordine, con la regola dell’endpoint prima della regola del dispositivo del tunnel, così che la stretta di mano abbia dove andare:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

L’indirizzo e la porta letterali dell’endpoint appartengono al vostro fornitore, non a questa pagina. Se l’endpoint è un nome host, risolvetelo una volta e fissate il risultato, perché una regola non può cercare un nome e una risposta che ruota romperà la politica in silenzio dopo il prossimo cambio di DNS. Controllate anche la porta, perché i fornitori che vi spostano su TCP 443 avranno altrimenti bisogno di una regola che nessuno ha scritto. Un tunnel che funziona solo su un protocollo è di solito questa omissione e non un guasto del firewall.

Su un router la stessa forma va nella catena FORWARD per i client dietro di esso, e il traffico del router stesso ha bisogno delle proprie regole. Un insieme di regole che copre solo i pacchetti inoltrati lascia SSH e DNS sul vecchio percorso, ed è così che un router diventa irraggiungibile nel momento in cui il tunnel sale.

Passo 4: controllate l’ordine, non solo la presenza

Le regole vengono valutate in sequenza, quindi un ACCEPT che arriva prima nasconde semplicemente il REJECT che avete aggiunto dopo. La corrispondenza established e related è ciò che lascia tornare le risposte alle vostre richieste in uscita senza aprire un percorso in ingresso generale, e metterla dopo l’accettazione del tunnel significa che un tunnel caduto fa ancora passare il traffico di ritorno sulla propria interfaccia.

Tenete il numero di regole abbastanza piccolo da leggerlo su una schermata. Un insieme di regole che non potete verificare è quello che rattopperete aggiungendo eccezioni in cima, ed è così che le politiche di rifiuto predefinito acquisiscono poco a poco un bordo di autorizzazione predefinita. Contate gli ACCEPT prima e dopo la modifica.

Passo 5: fatelo sopravvivere all’avvio e alla famiglia di indirizzi

Le regole inserite a mano svaniscono al riavvio, quindi caricatene dal servizio firewall della distribuzione o da un’unità che viene eseguita dopo che esiste l’interfaccia del tunnel. Fare riferimento a tun_work in uno script eseguito prima che OpenVPN parta è un modo comune di produrre un ciclo di avvio con traffico scartato.

Poi controllate IPv6 separatamente, perché una buona politica di rifiuto predefinito per IPv4 non dice nulla sull’altra famiglia. ip -6 route vi dirà se l’host ha una rotta che potrebbe portare traffico attorno a un tunnel che gestisce solo IPv4, e ip6tables o nftables ha bisogno delle proprie regole equivalenti. Provate con una destinazione IPv6-only invece di fidarvi della simmetria dell’insieme di regole.

Passo 6: verificate ed essere pronti a ripristinare

Alzate il tunnel, confermate che il servizio previsto funzioni, poi provate qualcosa che la politica dovrebbe rifiutare. Ripristinate con iptables-restore < /root/iptables.pre se la risposta vi sorprende, e solo allora iniziate a modificare le regole. La persistenza più un percorso di ripristino provato è ciò che rende questa una modifica che potete fare due volte.