Client VPN e LAN: quando usare una zona separata

Mettere l’interfaccia tunnel nella zona della LAN è la via più breve verso una VPN funzionante, ed è di solito il valore predefinito sbagliato. Concede al client remoto la stessa fiducia della LAN cablata, cosa che il compito raramente richiede. Una zona separata costa qualche regola e rende visibile il confine. La decisione non è se le zone siano migliori; è quali tre condizioni valgono per la vostra rete.

Il nome della zona non cifra nulla e non autentica alcun utente. Raggruppa soltanto le interfacce per il modello di policy del firewall.

Che cosa controlla davvero l’appartenenza a una zona

Una zona raggruppa interfacce o traffico nel modello del firewall. Le sue impostazioni di input, output e forward governano poi ruoli diversi. L’input è il traffico verso il router stesso; il forward è il traffico che lo attraversa verso un altro host. La documentazione di OpenWrt sulle zone tratta input, output e forward come impostazioni separate proprio per questo motivo.

Un permesso dalla zona VPN alla zona LAN non è automaticamente un permesso inverso. Le regole di forward sono direzionali, e una regola che consente il traffico da client a server non consente sessioni da server a client. Un client che può aprire una connessione verso un server non è un client verso cui il server possa aprire una connessione di ritorno.

Questa distinzione è il motivo per cui una zona separata è utile: potete dichiarare esplicitamente ogni direzione e ogni ruolo. Scrivete la direzione accanto a ogni regola.

Decisione uno: input, forward o entrambi

Se i client remoti hanno bisogno del DNS dal router, consentite l’input solo per quel servizio. Se devono raggiungere un file server, consentite il forward verso quella destinazione. La maggior parte dei progetti VPN richiede entrambi, ma per servizi diversi.

L’accesso in input ampio a ogni servizio locale non è quasi mai necessario. Trattate la gestione del router come una decisione separata dall’accesso alle applicazioni. Se il router deve solo rispondere al DNS, scrivete quell’unico permesso e lasciate chiuso il resto.

Decisione due: quali risorse servono ai client remoti

Elencate gli intervalli dei client, le destinazioni e i servizi che la VPN deve fornire prima di scrivere regole. Un elenco di destinazioni è più utile di un’etichetta di fiducia, perché sopravvive a una migrazione del firewall.

Tenete le interfacce di gestione separate dall’accesso ordinario alle applicazioni. Un client remoto che raggiunge un wiki non ha per questo bisogno della pagina di amministrazione del router né della console dell’hypervisor.

Se una destinazione consentita può inoltrare oltre, il confine della zona si ferma al firewall, non a ciò che la destinazione fa dopo.

Decisione tre: come dimostrerete il confine

Provate un flusso consentito e uno negato di proposito dopo ogni modifica. Dimostrare che un sito si carica non rivela un permesso ampio non intenzionale. Provate dall’intervallo di indirizzi del client VPN, non dalla LAN, e includete la direzione che vi aspettate fallisca. Annotate entrambi i risultati accanto alla regola.

Preservate l’accesso di recupero del gateway prima di modificare la policy della zona remota. Usate la configurazione gestita persistente invece di modifiche a caldo, altrimenti il prossimo riavvio ripristinerà la vecchia fiducia. Una copia della configurazione precedente, conservata fuori dal dispositivo, è il rollback più economico che avrete mai.

Quando la rete cresce, documentate l’appartenenza e lo scopo delle regole. Un’interfaccia appena collegata non dovrebbe ereditare privilegi solo perché qualcuno le ha dato un comodo nome di zona.