Zone Shorewall per i due percorsi dei pacchetti OpenVPN
Separate il trasporto OpenVPN cifrato dal traffico client decifrato, date al tunnel una zona propria e consentite solo il servizio che il client richiede.
Due flussi di pacchetti attraversano un gateway Shorewall che termina OpenVPN, e solo uno dei due è cifrato. Il primo è il trasporto del client verso l’ascoltatore VPN sull’interfaccia rivolta a internet. Il secondo è la richiesta decifrata che lascia l’interfaccia del tunnel verso un server d’ufficio o un servizio sul gateway. Mappate entrambi prima di modificare la politica, perché una regola che soddisfa il primo non fa nulla per il secondo.
Disegnate i due flussi prima di modificare la politica
Scrivete i flussi come righe con origine, destinazione, protocollo e porta. Sul percorso esterno l’origine è l’indirizzo pubblico del client e la destinazione è la porta di ascolto del gateway; Shorewall la tratta come traffico da internet al firewall. Sul percorso interno l’origine è l’intervallo di indirizzi del tunnel e la destinazione è il servizio approvato. Le due righe hanno proprietari diversi anche quando un solo amministratore le mantiene entrambe.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
Aggiungete una riga solo se la richiesta termina sul gateway stesso, come l’accesso al resolver o all’amministrazione. Un servizio sull’host segue la politica di ingresso dell’host, non il percorso inoltrato. Mescolare le due cose è il modo in cui una regola di tunnel stretta finisce per esporre un’interfaccia di amministrazione.
Assegnate la zona del tunnel e l’ambito dell’interfaccia
La zona del nomade è dichiarata in /etc/shorewall/zones, l’interfaccia del tunnel è collegata in /etc/shorewall/interfaces e la connessione esterna è descritta in /etc/shorewall/tunnels. Adeguatevi alla sintassi della versione installata, perché l’ordine delle colonne e i nomi delle opzioni sono cambiati tra versioni principali. La porta d’esempio della guida non è un motivo per consentire una porta diversa da quella su cui il demone ascolta davvero. TCP e UDP non sono intercambiabili solo perché i numeri coincidono.
La guida raggruppa le interfacce con tun+. Su un host con più di un tunnel quel carattere jolly può collocare una seconda VPN con un livello di fiducia diverso nella stessa zona. Rivedete l’ambito rispetto alle interfacce che esistono davvero e mantenete la denominazione sotto il ciclo di vita del gestore delle connessioni invece di modificare i nomi delle interfacce a mano.
La guida storica contiene esempi di configurazione OpenVPN molto più vecchi, e i suoi consigli crittografici non vanno copiati in un’installazione attuale. Prendete in prestito invece il modello di zone e flussi. Prendete la base crittografica dalla politica OpenVPN mantenuta del gateway.
Consentite solo il percorso che avete classificato
Un’accettazione ampia dalla zona VPN alla LAN è uno schema iniziale, non una politica finita. Scrivete l’origine client consentita, l’indirizzo reale del servizio, il protocollo e la porta. Poi leggete le regole sopra di essa e il valore predefinito della zona, perché un’aggiunta stretta non annulla un permesso ampio che già corrisponde. Il traffico verso l’host del gateway è una relazione separata dal traffico inoltrato attraverso di esso.
Il traffico tra client richiede una decisione propria. Il client-to-client di OpenVPN e il routeback di Shorewall influenzano entrambi la possibilità dei client di raggiungersi, e nessuno dei due va abilitato solo per far funzionare un’applicazione della LAN. Decidete dove viene applicato l’isolamento prima di provarlo.
Tenete il percorso di ritorno nello stesso piano. Il servizio o il suo router deve sapere come restituire il traffico all’intervallo del tunnel, oppure il progetto deve tradurre l’origine deliberatamente e nell’ambito previsto.
Validate, poi dimostrate entrambi i percorsi
Validate la configurazione prima di riavviare qualcosa e tenete aperta una sessione amministrativa indipendente nel caso la nuova politica sia sbagliata.
shorewall checkDopo un controllo pulito applicate la configurazione e rileggete ciò che Shorewall ha caricato. Queste letture descrivono la politica in esecuzione, non ciò che un file sembra dire.
shorewall show zones
ip route get 192.168.10.20Provate una richiesta consentita nuova e una richiesta negata di proposito dallo stesso client. Una stretta di mano OpenVPN riuscita dimostra solo lo scambio esterno; il servizio consentito e la risorsa negata dimostrano la politica interna che intendevate. Poi ricollegate il client e ripetete, perché il nome e l’indirizzo dell’interfaccia del tunnel possono cambiare tra le sessioni. Se il risultato differisce, correggete l’ambito della zona invece di allargare la regola.