Limitare un gateway OpenVPN a una sola LAN con le regole di UFW

Decidete il permesso prima di aprire un file del firewall: i client autenticati possono aprire connessioni verso una sottorete precisa, e il gateway deve rifiutare ogni altro percorso di transito anche quando un client installa rotte aggiuntive. Quella frase è il progetto, e ogni regola qui sotto esiste per farla rispettare. Qualcosa di più ampio, come tutto lo spazio degli indirizzi privati, l'uscita verso internet attraverso il tunnel o il traffico peer-to-peer, è un progetto diverso che richiede una propria decisione. Le regole sono anche volutamente noiose, perché un firewall ingegnoso è quello che nessuno potrà verificare in seguito.

Scrivete prima la topologia e il permesso

L'esempio usa un server Community OpenVPN con un dispositivo TUN nello spazio utente chiamato tun0, un pool di client 10.77.0.0/24, e una sottorete collegata 192.168.60.0/24 su lan0. L'inoltro IPv4 funziona già e la LAN ha già una rotta di ritorno verso il pool, quindi nulla qui dipende dalla traduzione tra i due.

UFW possiede il firewall su questo host, e nessun insieme di regole di container né una tabella nftables separata può installare un percorso di accettazione anteriore. Una scorciatoia di scarico del flusso che salta il filtro renderebbe le catene di guardia decorative, quindi confermate che nessuna sia attiva. Lasciate disattivato l'inoltro client-to-client proprio di OpenVPN, perché il traffico peer-to-peer che non attraversa mai il filtro del sistema operativo non può essere limitato da esso. L'ascoltatore esterno e le regole di amministrazione restano come sono, dal momento che questa modifica governa il traffico decifrato del tunnel invece di sostituire il firewall.

Mettete le guardie prima delle accettazioni anticipate di UFW

Un permesso di rotta seguito da un rifiuto non basta per un confine rigido. Le regole before predefinite accettano il traffico stabilito e alcuni ICMP prima che venga consultata qualsiasi regola utente, quindi un flusso permesso la settimana scorsa può restare fuori dalla nuova restrizione di destinazione solo perché ha ancora stato. Fate un backup dei file di UFW e tenete aperta una console fuori banda prima di modificare.

Nella sezione *filter del file /etc/ufw/before.rules, dichiarate due catene accanto alle dichiarazioni esistenti e prima di qualsiasi riga di regola.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Subito dopo le dichiarazioni, e prima dei permessi di ingresso e di inoltro, saltate al loro interno e definite cosa ammettono.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Conservate il resto della sezione e la sua riga COMMIT. Incollare una seconda tabella di filtro o cancellare regole non correlate è il modo in cui una modifica al firewall diventa un'interruzione, e il file è a un riavvio dal diventare l'unica copia che conta.

Leggete cosa ammette e rifiuta ogni guardia

La prima catena prosegue l'elaborazione solo quando l'origine è nel pool, la destinazione è l'unica sottorete, l'interfaccia di uscita è la LAN e il pacchetto viaggia nella direzione originale del suo flusso. Tutto il resto che arriva dal tunnel viene scartato, compresa un'origine fuori dal pool e qualsiasi destinazione oltre la sottorete consentita.

Un pacchetto peer-to-peer entra ed esce da tun0, quindi fallisce il test dell'interfaccia LAN ancora prima di raggiungere un controllo di destinazione. Anche le nuove connessioni dalla LAN verso i client falliscono il test di direzione della risposta, cosa che chiude per impostazione predefinita il percorso di callback inverso.

L'obiettivo RETURN mantiene in gioco la normale politica di UFW. Queste catene filtrano, e il permesso di rotta che aggiungete subito dopo decide ancora se un pacchetto sopravvissuto viene accettato. È proprio questa separazione che vi permette in seguito di cambiare la sottorete consentita in un solo punto. Se le guardie accettassero i pacchetti direttamente, ogni regola futura dovrebbe essere aggiunta due volte.

Autorizzate la sottorete e chiudete le porte laterali

Visualizzate prima l'anteprima del permesso di rotta, poi togliete il flag di anteprima per applicarlo: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Dopo, riesaminate l'ordine delle regole utente, perché un rifiuto precedente vince ancora su un permesso successivo. Un permesso per l'intera sottorete è anche la forma sbagliata quando deve essere raggiungibile solo la porta HTTPS di un host.

Notate cosa fa lo scarto in ingresso: i client del tunnel non possono raggiungere alcun servizio sul gateway stesso, compreso un ascoltatore DNS legato al suo indirizzo LAN. Ospitare DNS lì richiede un'eccezione deliberata prima dello scarto e un contratto di permesso rivisto. Se UFW gestisce IPv6, aggiungete scarti corrispondenti anche per tun0 in before6.rules, perché un elenco di destinazioni IPv4 non dice nulla sui pacchetti IPv6.

Verificate la politica caricata, non l'anteprima

Visualizzate l'anteprima del ricaricamento, applicatelo in una finestra di manutenzione e leggete l'insieme di regole attivo.

sudo ufw --dry-run reload
sudo ufw show raw

Confermate che le guardie del tunnel compaiano prima dei permessi predefiniti di stato e ICMP. Un ufw status semplice non mostra le regole before modificate a mano, ed è per questo che gli operatori concludono che manchi una regola quando in realtà è caricata. Leggete l'elenco grezzo dall'alto verso il basso invece di cercare un frammento. Se le guardie compaiono dopo un permesso di stato, il confine non fa ciò che il file suggerisce.

Poi provate il comportamento, non il testo. Aprite una connessione nuova verso un host consentito e osservate la risposta, instradate una richiesta innocua verso una destinazione fuori dalla sottorete e confermate che muore, provate una connessione peer-to-peer, provate un servizio locale al gateway e provate una connessione non richiesta dalla LAN verso un client. Includete un flusso fuori ambito che esisteva prima della modifica, e cancellate solo quel flusso invece di svuotare l'intera tabella di tracciamento della macchina.

Annotate i limiti accanto alle regole: questo limita il transito e nient'altro. Non impedisce a un client di usare la propria connessione internet, non impedisce a un host LAN consentito di inoltrare ulteriormente il traffico e non sostituisce l'autenticazione all'interno dei servizi consentiti.