Zona VPN di OpenWrt, inoltro e mascheramento: quale serve?
L’ingresso di zona, l’inoltro e il mascheramento rispondono a domande diverse. Decidete cosa serve al vostro traffico VPN prima di aprire la zona WAN.
Tre modifiche si mescolano ogni volta che una VPN incontra OpenWrt: aprire una porta, consentire l’inoltro e attivare il mascheramento. Rispondono a domande diverse, e di solito solo una di esse è il requisito reale. Leggere ogni controllo secondo il ruolo del traffico che governa trasforma un’ipotesi in una decisione, e dice anche quale sintomo aspettarsi quando la modifica è sbagliata. Iniziate dal nominare il ruolo che ha fallito, non la casella che ricordate.
Nominate il ruolo del traffico prima di toccare un controllo
L’ingresso di zona decide cosa può raggiungere il router stesso. L’uscita di zona copre il traffico che il router origina, l’inoltro di zona è il valore predefinito per il traffico che attraversa una zona, e il mascheramento decide se l’indirizzo sorgente viene riscritto in uscita. Sono quattro domande diverse, e una politica di zona le risponde tutte insieme con lo stesso valore, per questo una modifica sull’intera zona è uno strumento grossolano. Una regola con nome può rispondere a una di esse senza toccare le altre.
La mappa utile è per ruolo del traffico, perché è ciò che potete osservare quando qualcosa fallisce. Ogni ruolo qui sotto ha un controllo che lo decide e un sintomo che lo indica:
| Traffic role | Control that decides it | Where it lives in the config | Symptom when it is wrong |
|---|---|---|---|
| A client reaching a listener on the router | Input policy of the zone that carries the connection, or a rule for the port | option input in the zone stanza, or a named rule | The handshake never completes and the tunnel log says nothing |
| A tunnel client reaching the router itself | Input policy of the tunnel zone | option input in the VPN zone | A ping to the gateway fails |
| A tunnel client reaching another LAN host | Forwarding from the tunnel zone to the LAN zone | config forwarding plus the zone assignment | The gateway answers and the file share times out |
| The router's own traffic leaving the WAN | Output policy, and translation if the far side needs it | option output and option masq | The tunnel never establishes, or replies vanish |
Un servizio in ascolto sul router richiede una sola regola di ingresso stretta
Un server OpenVPN sul router riceve traffico indirizzato al router, quindi la sua connessione esterna dipende dalla politica di ingresso della zona che lo trasporta. Consentite il trasporto e la porta configurati e lasciate tutto il resto di quella zona in rifiuto. Una sola regola di porta è una modifica molto più piccola di un’accettazione sull’intera zona, ed è quella che potrete ancora spiegare dopo un anno.
Due cose rendono quella regola sicura da mantenere: nomina la porta che il servizio usa davvero, e sta accanto alla definizione della zona perché la persona successiva veda perché esiste. Le righe qui sotto sono la forma, con la porta al posto di ciò che è configurato sul server. Cambiate quella porta in entrambi i punti quando il servizio si sposta, perché una regola rimasta su quella vecchia è invisibile fino a un controllo.
config zone
option name 'wan'
option input 'REJECT'
option forward 'REJECT'
option output 'ACCEPT'
option masq '1'
config rule
option name 'allow-openvpn'
option src 'wan'
option proto 'udp'
option dest_port '1194'
option target 'ACCEPT'Validate prima di ricaricare, perché un errore di sintassi in un file del firewall può lasciare il router senza un insieme di regole funzionante. In una versione che usa fw4 la verifica è un comando separato, e fallisce rumorosamente invece di accettare in silenzio un blocco rotto. Ricaricate solo dopo che la verifica è passata, e conservate il file precedente dove potete rimetterlo.
fw4 check
service firewall reloadLa richiesta di un client passa per l’inoltro, non per l’ingresso
Dopo l’autenticazione, la richiesta di un client del tunnel verso un servizio della LAN produce un flusso inoltrato, quindi il controllo che la decide è la relazione di inoltro tra la zona del tunnel e la zona LAN. Assegnate l’interfaccia del tunnel alla zona desiderata, poi dichiarate la direzione, le sorgenti e il servizio. L’assegnazione della zona è ciò che dà senso alla regola di inoltro, e le due cose si capiscono solo lette insieme. Una relazione di inoltro che nomina la zona del tunnel come sorgente e la zona LAN come destinazione si legge come una decisione deliberata, mentre due accettazioni sull’intera zona si leggono come un incidente.
Raggiungere il router stesso usa ancora il percorso di ingresso, per questo un ping verso il gateway non dice nulla sulla condivisione file che c’è dietro. Quei due guasti vivono in blocchi diversi e si correggono con modifiche diverse. Scrivete entrambi i percorsi separatamente prima di cambiarne uno.
Il mascheramento è una decisione di instradamento, non un permesso
Il mascheramento riscrive l’indirizzo sorgente del traffico in uscita selezionato. Può salvare un progetto di uscita in cui il lato remoto non ha una rotta di ritorno, e nasconde anche gli indirizzi dei singoli client a qualsiasi servizio che registri o autorizzi per indirizzo. Disattivarlo è una scelta di instradamento sulla rotta di ritorno, non un interruttore di sicurezza che chiude un buco in ingresso. Un tunnel che funziona con la traduzione attiva e fallisce nel momento in cui la si disattiva di solito ha una rotta di ritorno mancante, non una regola del firewall mancante.
L’alternativa instradata richiede una rotta di ritorno sul lato remoto invece della traduzione. Nessuna delle due opzioni fornisce l’autorizzazione del firewall o l’account dell’applicazione, per questo disattivare il mascheramento quasi mai ripara un client del tunnel che non raggiunge nulla. Trattate separatamente anche la politica IPv4 e la IPv6, perché una sola impostazione di traduzione non descrive entrambe le famiglie.
Dimostrate la decisione con una richiesta consentita e una rifiutata
Inviate una richiesta che dovrebbe essere consentita e una che dovrebbe essere rifiutata, poi identificate il controllo che ha preso ogni decisione. Una pagina che si carica per caso non è una prova; la prova è la regola che ha corrisposto, nella catena in cui ha corrisposto. Il rifiuto conta quanto il successo, perché mostra che la politica fa qualcosa invece che tutto sia consentito.
Due comandi vi danno quella prova su una versione attuale. Il contatore sulla regola corrispondente si muove quando la richiesta viene accettata, e il registro mostra lo scarto se avete attivato la registrazione per la regola:
nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'Conservate un percorso di amministrazione ancora utilizzabile prima di cambiare qualsiasi politica del firewall, e seguite il processo di validazione e ripristino del proprietario della configurazione. Una modifica che vi chiude fuori dal router non è un risultato di test, è un secondo incidente. Annotate la zona e il ruolo del traffico accanto a ogni osservazione, così la coppia di risultati spiega la politica invece di descrivere un caricamento di pagina fortunato.