Regola del listener di firewalld contro politica di inoltro: cosa fa ciascuna

Una VPN che si connette ma non raggiunge nulla viene di solito descritta come un problema di firewall, e la soluzione a cui si ricorre è mettere l'interfaccia del tunnel in una zona fidata. Funziona nel senso che il traffico inizia a fluire, ma ammette anche molto più del servizio previsto. Le due politiche coinvolte sono diverse: una ammette il trasporto esterno verso un socket in ascolto, l'altra autorizza il traffico decifrato a raggiungere una risorsa specifica. Trattarle come un'unica impostazione è ciò che trasforma un permesso ristretto in uno ampio. Le due vengono decise in punti diversi, ed è per questo che l'errore è così facile.

Due politiche, un tunnel

La politica esterna risponde a una domanda semplice: un pacchetto da questa origine può raggiungere l'UDP 1194 su questo host? La politica interna risponde a un'altra: il client autenticato dietro quel tunnel può raggiungere questa destinazione, con questo protocollo, su questa porta? La prima riguarda un socket, la seconda un percorso, e firewalld le modella con oggetti diversi perché vengono decise in punti diversi. Una è una proprietà di un socket su questo host, l'altra di un percorso che lo attraversa.

La conseguenza pratica è che un tunnel funzionante non dice nulla sulla seconda politica, e una seconda politica corretta non rende superflua la prima.

Ammettere il listener esterno reale

Iniziate esaminando ciò che è già assegnato invece di presumerlo. Leggete le zone attive, elencate la zona che trasporta davvero l'ingresso e controllate la definizione del servizio installato, perché il nome di un servizio descrive un insieme di porte e non dice nulla sul fatto che il listener di questo server vi corrisponda.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

Se il listener è davvero l'UDP 1194 su quella zona, aprite specificamente quella porta e quel trasporto, poi rendete persistente la stessa regola specifica dopo averla provata. Controllate anche le assegnazioni basate sull'origine, perché una zona legata a un intervallo di origini può intercettare il traffico prima che la zona dell'interfaccia lo veda.

Autorizzate la destinazione decifrata separatamente

Una connessione a un servizio in esecuzione sul server VPN stesso è politica di input locale. Una connessione inoltrata a un altro host sulla LAN richiede politica di inoltro, l'inoltro abilitato nel kernel e una rotta di ritorno — tre requisiti separati che le persone spesso fondono in uno. Gli oggetti di politica moderni di firewalld descrivono il traffico diretto tra una zona di ingresso e una di uscita, e quello è il posto giusto per esprimere quali origini VPN possono raggiungere quali servizi privati.

Definite esplicitamente le origini consentite e lasciate che tutto il resto cada in un rifiuto. Un permesso per il servizio esterno non è quella politica, per quanto la disposizione delle zone possa sembrarlo.

Perché fidarsi dell'interfaccia è la scorciatoia sbagliata

Mettere l'interfaccia del tunnel in una zona la cui destinazione accetta tutto ammette tutto il traffico decifrato verso ogni servizio esposto dall'host, compresi quelli che non avete esaminato. Ripuntare la zona fidata per renderla restrittiva su una macchina in esercizio è peggio, perché altre interfacce e intervalli di origini possono già dipendere dal suo significato e cambieranno comportamento quando la modificherete. Se vi serve una politica ristretta, createne una; non riutilizzate una zona condivisa.

Mantenete stabile anche l'assegnazione di zona del tunnel attraverso qualunque componente possieda quella configurazione. Perdere l'assegnazione al riavvio produce un guasto che sembra un problema di regola del firewall ed è in realtà un problema di persistenza.

Verificate tre cose, compreso un rifiuto

Provate la connessione esterna dall'esterno, provate un servizio interno autorizzato da un client connesso e provate un servizio che dovrebbe restare irraggiungibile. Il terzo test è quello che distingue una politica da un effetto collaterale, ed è quello che le persone saltano perché tutto sembra funzionare. Se il servizio negato risponde, avete ammesso una zona invece di un servizio.

Annotate zona, porta, trasporto e oggetto di politica nelle note del server. Altrimenti la prossima modifica su questo host partirà dalla stessa supposizione.