Migrazione NethServer 7

La migrazione è il processo per convertire una macchina NethServer 7 (sorgente) in una NethSecurity (destinazione).

La migrazione della configurazione del firewall da NethServer 7 a NethSecurity è un processo cruciale per garantire la continuità e la sicurezza dei servizi di rete.

Requisiti per la migrazione:

• garantire l’accesso a Cockpit su NethServer 7

• installare l’applicazione Firewall Migration su NethServer 7. Dopo l’installazione, l’applicazione sarà disponibile nell’elenco delle applicazioni di Cockpit

Scenari di migrazione:

Sistema di origine	Metodo supportato	Note
NethServer 7 con solo il ruolo firewall	In-place o esportazione/importazione	È possibile riutilizzare l’hardware esistente se NethSecurity 8 rileva tutti i dischi e le schede di rete necessari.
NethServer 7 con ruoli aggiuntivi come NethService, NethVoice o mail	Esporta/importa solo	La migrazione in-place non è supportata. Installare NethSecurity 8 su una macchina dedicata e importare solo la configurazione del firewall.
NethServer 6.x	Non supportato	Eseguire prima l’aggiornamento a NethServer 7.

Nota

Se si utilizza l’Alta Affidabilità (HA) con NethServer 7, consultare anche la guida alla migrazione HA per istruzioni dettagliate sulla migrazione mantenendo la funzionalità HA.

Compatibilità hardware

Prima di riutilizzare l’hardware esistente, avviare l’immagine live USB o una nuova installazione di NethSecurity 8 e verificare che tutti i dischi e le schede di rete vengano rilevati. Non è necessario alcun passaggio di migrazione speciale per gli adattatori SFP/SFP+ 10 Gb supportati: se la scheda viene rilevata, è possibile procedere normalmente con la migrazione. Se non viene rilevata, utilizzare un hardware diverso o una scheda di rete già supportata da NethSecurity 8.

Gli adattatori USB-to-Ethernet non sono supportati in produzione su NethSecurity 8. Consultare la sezione sugli adattatori USB-to-Ethernet per maggiori dettagli.

Test della migrazione

Questo metodo consente di effettuare test approfonditi senza influire sull’installazione esistente. Un sistema di test verrà avviato da una chiavetta USB lasciando l’installazione attuale invariata.

Per eseguire una migrazione di prova, seguire questi passaggi:

1. Accedere alla pagina Firewall Migration su NethServer 7 Cockpit: la pagina elencherà tutte le configurazioni migrate

2. Scaricare l’immagine live USB: fare clic su Scarica nella sezione Download live USB image

3. Preparare l’unità USB: scrivere l’immagine scaricata utilizzando il metodo preferito su un’unità USB, vedere la sezione di installazione per ulteriori informazioni su come copiare l’immagine su un disco.

4. Avvio da unità USB: spegnere il firewall, collegare l’unità USB e riavviarlo, assicurandosi che l’avvio avvenga dall’unità USB. Questo viene generalmente effettuato tramite le impostazioni del BIOS/UEFI.

5. Avvio di migrazione: durante il processo di avvio, il sistema viene caricato dall’unità USB invece che dal disco rigido interno

6. Ambiente di test: il sistema ora opera utilizzando il sistema migrato memorizzato sulla USB. Eventuali modifiche o test effettuati avvengono all’interno di questo ambiente isolato.

Ricordare che, dopo il test, è sufficiente rimuovere la chiavetta USB, riavviare normalmente il firewall e questo riprenderà a utilizzare la configurazione originale, lasciando l’installazione esistente invariata.

Migrazione in-place

Se la configurazione iniziale di NethServer 7 include solo il modulo firewall, è possibile migrare e riutilizzare l’hardware attuale senza interruzioni. Questo approccio semplifica la migrazione, eliminando la necessità di hardware aggiuntivo.

Per eseguire la migrazione in-place da NethServer 7 a NethSecurity, seguire questi passaggi:

1. Eseguire il backup dei dati: la migrazione in-place è un processo distruttivo. Si consiglia vivamente di creare un backup completo della macchina prima di procedere. Questo passaggio è fondamentale per garantire la sicurezza dei dati in caso di eventuali problemi durante la migrazione.

2. Accedere alla pagina Firewall Migration su NethServer 7 Cockpit: la pagina elencherà tutte le configurazioni migrate

3. Scaricare l’archivio di configurazione come precauzione: come misura precauzionale, scaricare l’archivio contenente la configurazione esportata facendo clic su Scarica nella sezione Download exported archive. Conservare questo archivio in un luogo sicuro; potrebbe essere utile nel caso in cui la migrazione in-place fallisca.

4. Avviare la migrazione: quando si è pronti, fare clic sul pulsante Migra per avviare il processo di migrazione. Questo segnala al sistema di iniziare la migrazione da NethServer 7 a NethSecurity.

5. Selezionare il disco di destinazione: scegliere il disco su cui verrà installato NethSecurity. Si noti che NethSecurity non supporta RAID. Se il server NethServer 7 originale dispone di più di un disco, gli altri dischi rimarranno invariati e inutilizzati durante il processo di migrazione.

6. Confermare e avviare il processo: dopo aver selezionato il disco, fare clic su Migra per confermare. Il sistema scaricherà l’immagine di NethSecurity e la scriverà sul disco selezionato. Successivamente, il sistema si riavvierà automaticamente.

7. Completare la migrazione al primo avvio: al primo avvio di NethSecurity, la configurazione da NethServer 7 verrà migrata automaticamente. Assicurarsi di verificare attentamente tutte le impostazioni e i servizi per confermare che siano stati migrati correttamente.

Dopo aver completato la migrazione, seguire i passaggi post-migrazione per assicurarsi che il sistema sia configurato correttamente.

Migrazione con altri moduli installati

Questo scenario prevede l’esportazione di un archivio di configurazione speciale da NethServer 7 e l’importazione dello stesso in NethSecurity.

Questo metodo è consigliato quando la configurazione originale di NethServer 7 include moduli aggiuntivi, come il mail server, il groupware WebTop o il modulo PBX NethVoice. Per eseguire questa migrazione, è necessario installare NethSecurity su un nuovo hardware e poi importare la configurazione nel sistema NethSecurity appena installato.

Per eseguire la migrazione da NethServer 7 a NethSecurity, seguire questi passaggi:

1. Installare NethSecurity su una nuova macchina: seguire le istruzioni di installazione

2. Accedere alla pagina Firewall Migration su NethServer 7 Cockpit: la pagina elencherà tutte le configurazioni migrate

3. Scaricare l’archivio con la configurazione esportata: fare clic su Scarica nella sezione Download export archive

4. Accedere alla pagina Backup & Restore su NethSecurity e andare nella scheda Migrazione, quindi fare clic su Carica file di migrazione e selezionare l’archivio scaricato nel passaggio precedente.

5. Quando si importa la configurazione su un nuovo hardware, gli indirizzi MAC delle interfacce di rete cambiano, rendendo necessaria una decisione su come rimappare queste interfacce. L’interfaccia utente mostra le interfacce della macchina di origine a sinistra e quelle della macchina di destinazione a destra. Se la macchina di origine aveva VLAN configurate, è necessario rimappare l’interfaccia fisica e il sistema ricreerà automaticamente la VLAN sull’interfaccia sottostante.

6. Fare clic su Migra per avviare il processo di migrazione

Dopo aver completato la migrazione, seguire i passaggi post-migrazione per assicurarsi che il sistema sia configurato correttamente.

Passaggi post-migrazione

Il processo di migrazione in-place viene eseguito quando il sistema è offline. Poiché il processo di registrazione richiede una connessione Internet attiva, la subscription non viene migrata durante la migrazione in-place. Se è stata eseguita una migrazione in-place, è necessario registrare nuovamente il sistema. Questo passaggio non è necessario se è stata eseguita una migrazione utilizzando il metodo dell’archivio esportato.

Quando si utilizza un server LDAP remoto o Active Directory per autenticare i client OpenVPN Road Warrior, assicurarsi che il server remoto sia raggiungibile dalla nuova macchina NethSecurity verificando anche la risoluzione dei nomi DNS. Se necessario, aggiornare la configurazione DNS sulla nuova macchina. Inoltre, consultare la pagina del database utenti remoto per verificare che tutti gli utenti siano stati importati correttamente.

Si noti che il server web di NethSecurity ascolta solo su HTTPS (porta 443) per le regole di reverse proxy. Se erano state configurate delle regole di reverse proxy su NethServer 7 utilizzando HTTP (porta 80), sarà necessario aggiornarle per utilizzare HTTPS. Consultare la documentazione sul reverse proxy per ulteriori dettagli.

Quindi, verificare che tutti i servizi funzionino correttamente. In caso di problemi, consultare la sezione di risoluzione dei problemi.

Il processo di migrazione viene registrato in un file di log speciale situato in /root/migration.log. Questo file contiene tutte le azioni eseguite durante il processo di migrazione. Si noti che il file di log viene eliminato dopo un aggiornamento dell’immagine.

Correzione della denominazione di bond e VLAN per l’Alta Disponibilità

Se si è effettuata una migrazione da NethServer 7, si potrebbe notare che i dispositivi di rete aggregati hanno nomi lunghi come bond-bond0 invece del formato più breve bond0 utilizzato nelle nuove installazioni di NethSecurity 8. Anche se ciò non influisce sulle funzionalità di base, questi nomi più lunghi possono impedire la configurazione dell’Alta Affidabilità (HA) e potrebbero apparire incoerenti nell’interfaccia utente.

Se si prevede di utilizzare l’Alta Disponibilità o si preferisce semplicemente avere nomi di dispositivi più chiari, è possibile rinominarli utilizzando uno script semplice.

Prima di iniziare, effettuare una copia di backup della configurazione di rete:

cp /etc/config/network /root/network.ori

Quindi, eseguire questo comando per rinominare i dispositivi:

sed -i \
  -e "/option[[:space:]]\+ifname/s/'bond-bond\([0-9]\+\)'/'bond-b\1'/" \
  -e "/option[[:space:]]\+device/s/'bond-bond\([0-9]\+\)'/'bond-b\1'/" \
  -e "/option[[:space:]]\+name/s/'bond-bond\([0-9]\+\)\(\.[0-9]\+\)'/'b\1\2'/" \
  -e "/option[[:space:]]\+name/s/'bond-bond\([0-9]\+\)'/'bond-b\1'/" \
  -e "s/^\([[:space:]]*option[[:space:]]\+name[[:space:]]\+\)'b\([0-9]\+\)'\([[:space:]]*\)$/\1'bond-b\2'\3/" \
  /etc/config/network

Dopo aver eseguito lo script, riavviare la rete per applicare le modifiche:

/etc/init.d/network restart

In alternativa, è possibile riavviare l’intero sistema per assicurarsi che tutte le modifiche abbiano effetto correttamente.

Una volta verificato che tutto funziona correttamente, è possibile eliminare in sicurezza il backup:

rm -f /root/network.ori

Dopo le modifiche, i dispositivi utilizzeranno la convenzione di denominazione più breve (ad esempio, b0, b0.20), che è compatibile con High Availability e corrisponde alle nuove installazioni.

Matrice di copertura della migrazione

La tabella seguente mostra ciò che viene migrato da NethServer 7 e ciò che richiede ancora un intervento manuale.

Area	Risultato	Note
Password di root	Migrato	La stessa password può essere utilizzata per SSH e per l’interfaccia web.
Interfacce di rete e VLAN	Migrato con limitazioni	La configurazione di rete viene migrata. I bridge su bond non sono supportati. Su nuovo hardware, le VLAN vengono ricreate automaticamente sull’interfaccia fisica scelta durante la rimappatura. Se si è migrato da NethServer 7 e si ha la necessità di normalizzare i nomi di bond e VLAN per HA, consultare Correzione della denominazione di bond e VLAN per l’Alta Disponibilità.
Etichette delle interfacce di rete	Migrato	Le etichette di origine vengono mantenute come nomi delle interfacce, ad eccezione delle interfacce WAN che mantengono i loro nomi originali.
Data e fuso orario	Migrato
Server DHCP e prenotazioni	Migrato con limitazioni	I server DHCP sulle interfacce bond non sono supportati.
Configurazione DNS e host locali	Migrato con limitazioni	Le opzioni TFTP vengono migrate, ma il contenuto TFTP no. Per riabilitarlo, configurare manualmente tftp_root.
Route IPv4 statiche	Migrato
Reindirizzamenti di porta	Migrato
Zone del firewall	Migrato	Le zone verdi diventano lan, quelle rosse diventano wan, quelle arancioni diventano dmz e quelle blu diventano guest. Se esisteva una zona blu, le regole di accettazione per DNS e DHCP vengono aggiunte automaticamente.
Regole del firewall	Migrato con conversione	Le regole che utilizzano i servizi NDPI non sono supportate. Gli oggetti di origine e destinazione, incluse le zone personalizzate, vengono convertiti in valori IP/CIDR all’interno delle regole migrate. I NAT helper vengono caricati automaticamente con i parametri standard del kernel.
Oggetti firewall	Non ricreato	Al momento, gli oggetti firewall non possono essere reimportati automaticamente nel nuovo sistema. Le regole che utilizzavano oggetti come origine o destinazione vengono convertite nei corrispondenti valori IP/CIDR.
MultiWAN	Parziale	I provider vengono mantenuti. Le regole di deviazione (policy routing) non vengono migrate.
QoS	Parziale	Le classi con larghezza di banda riservata e le relative regole non sono supportate.
OpenVPN Road Warrior	Parziale	Le impostazioni vengono migrate. Il database di contabilità non viene migrato e la notifica tramite email non è supportata. Se il server si autentica tramite un Active Directory remoto, consultare anche Database remoti.
Tunnel OpenVPN	Migrato
Tunnel IPSec	Migrato
Threat Shield IP	Parziale	Solo le liste enterprise vengono migrate. Le liste community devono essere configurate nuovamente manualmente.
Abbonamento	Condizionale	Viene migrato solo quando si utilizza il metodo di esportazione dell’archivio.
Hotspot	Condizionale	Su nuovo hardware l’indirizzo MAC cambia, quindi l’hotspot deve essere registrato nuovamente sul remote manager.
Let’s Encrypt e certificati reverse proxy	Rigenerato	La configurazione viene migrata, ma i certificati vengono generati nuovamente dopo la migrazione.
Filtro DNS Cloud FlashStart	Migrato

Esempi di rimappatura

I seguenti esempi mostrano come alcune configurazioni vengono migrate quando le interfacce di rete delle macchine di origine e destinazione non corrispondono:

• Rimappatura VLAN: se la VLAN 20 era configurata su eth1 nel firewall di origine e eth1 viene mappata su eth2 nel firewall di destinazione, la VLAN 20 viene ricreata automaticamente su eth2.

• Conversione degli oggetti firewall: se una regola utilizzava un set di host chiamato BranchOffice con valore 10.20.30.0/24, la regola migrata mantiene direttamente 10.20.30.0/24 invece di ricreare l’oggetto.

Funzionalità non migrate

Le seguenti funzionalità non sono migrate su NethSecurity:

• Proxy web (Squid) e filtro (ufdbGuard), sostituiti da Content Filtering e Filtro Deep Packet Inspection (DPI)

• IPS (Suricata) e avvisi IPS (EveBox), sostituiti da Intrusion Prevention System (Snort)

• Monitoraggio UPS (NUT), disponibile solo da riga di comando con UPS (NUT)

• Statistiche di sistema (Collectd), sostituite da Netdata in Monitoraggio in tempo reale

• Report (Dante), sostituiti dalle metriche del controller in Metriche

• Monitoraggio della larghezza di banda (ntopng), il monitoraggio integrato della larghezza di banda è disponibile in Monitoraggio in tempo reale e tramite Metriche

• Fail2ban, viene sostituito da Threat shield funzionalità di blocco dei tentativi di forza bruta

• Threat shield DNS deve essere riconfigurato manualmente Threat shield DNS

Zone personalizzate

Le zone personalizzate sono raramente utilizzate in NethServer 7 e tipicamente per compiti molto specifici. Sono necessarie per definire un segmento di rete con regole firewall differenti da quelle dell’interfaccia primaria o, più comunemente, per gestire correttamente il traffico proveniente da una rete diversa da quella a cui l’interfaccia è collegata. Queste zone permettono di definire un comportamento specifico per quel segmento di rete e garantiscono un corretto instradamento in ambienti complessi (ad esempio, una regola di port forwarding con destinazione host remoto tramite MPLS o tunnel VPN).

In NethSecurity, le zone funzionano in modo diverso rispetto a NethServer 7, offrendo in questi casi una gestione molto più semplice. Tipicamente, in NethSecurity, tutte le precedenti configurazioni effettuate con zone personalizzate possono essere gestite facilmente senza la necessità di ricreare alcuna zona personalizzata, grazie al seguente comportamento predefinito.

1. Ereditarietà delle policy per il traffico in ingresso

Tutto il traffico in ingresso da un’interfaccia NethSecurity eredita automaticamente le stesse policy dell’interfaccia a cui è collegata, indipendentemente dalla rete di origine. Questo include il masquerading automatico quando il traffico è destinato a Internet.

Vediamo un esempio:

Un’interfaccia locale denominata office opera sul segmento di rete 192.168.1.0/24 ed è assegnata alla zona lan. Un gateway con IP 192.168.1.220 è collegato allo stesso switch dell’interfaccia office, fornendo accesso alla rete remota 10.10.10.0/24. La rete remota 10.10.10.0/24 deve utilizzare NethSecurity per accedere a Internet.

In NethSecurity, non è necessaria alcuna configurazione aggiuntiva: tutti i pacchetti inviati all’interfaccia office vengono instradati correttamente, anche se provengono da un segmento di rete diverso. Il masquerading viene inoltre applicato a tutti i pacchetti in uscita.

2. Non è necessario creare nuove zone per segmenti diversi

Proprio come le policy, le regole standard possono essere applicate a questo traffico senza la necessità di creare una nuova zona. Se si desidera applicare policy diverse per questo segmento, è sufficiente creare regole firewall standard. Per comodità, è possibile utilizzare un set di host con la rete CIDR negli oggetti firewall.

3. Il routing funziona senza problemi senza regole aggiuntive

Il routing per questo specifico segmento di rete funziona correttamente senza la necessità di regole o zone aggiuntive. In NethServer 7, era obbligatorio creare una zona per garantire il corretto instradamento dei pacchetti in ingresso, come menzionato nell’esempio iniziale di port forwarding.

Adattatori USB-Ethernet

Può raramente accadere che il NethServer 7 in fase di migrazione abbia collegato un adattatore USB a Ethernet per aggiungere un dispositivo di rete. Questi adattatori non dovrebbero essere utilizzati in un firewall e non sono supportati su NethSecurity 8. Tuttavia, è possibile installare alcuni driver specifici per scopi sperimentali, non per ambienti di produzione. Questi driver possono essere utili per gestire temporaneamente il firewall migrato in attesa di hardware dotato di tutte le schede di rete necessarie. Maggiori informazioni sono disponibili nella sezione di rete.

Avvertimento

Se si utilizzano questi adattatori, ricordare che non funzioneranno fino a quando non sarà installato il driver corretto. Tenere presente che NethSecurity 8 potrebbe non disporre del driver corretto per l’adattatore utilizzato su NethServer 7. In questo caso, sarà necessario utilizzare un adattatore diverso.

Nota

Se si utilizza un adattatore da USB a Ethernet per un’interfaccia RED/WAN, è importante sapere che non sarà possibile scaricare i moduli necessari per farlo funzionare correttamente su NethSecurity 8 a meno che non siano presenti altre interfacce RED/WAN che utilizzano schede di rete collegate direttamente alla scheda madre.