Vai al contenuto

Installazione dei server Mediation Controller

Nota

Come promemoria, il passaggio a root sulle macchine Debian deve essere effettuato con il comando seguente:

1
su -

Le istruzioni fornite in questa pagina devono essere ripetute su entrambi i server Mediation Controller, iniziando dal server MASTER.
Quando compaiono differenze tra i server MASTER e SLAVE, queste vengono evidenziate. Se non viene indicato nulla, le istruzioni si applicano sia al server MASTER sia al server SLAVE.

Download del mirror e degli strumenti necessari

Il mirror CyberElements Cleanroom 4.6 e la chiave di firma del repository Systancia possono essere scaricati da questo link (è necessaria la creazione di un account cliente): Systancia Marketplace

Oltre al mirror e alla chiave, per il processo di aggiornamento saranno necessari strumenti di terze parti:

  • Un client SSH (su Windows è possibile utilizzare PuTTY)
  • Un client SCP (su Windows è possibile utilizzare gli strumenti WinSCP o FileZilla)

Utilizzare il client SSH per connettersi in remoto al proprio server.

Utilizzare il client SCP per trasferire i file sulla propria macchina remota.

Preparazione dell'installazione

Configurazione della rete

Installare il pacchetto resolvconf affinché possa essere applicata la configurazione DNS indicata nel file di configurazione che verrà modificato a breve:

1
apt install -y resolvconf

È indispensabile configurare un indirizzo di rete statico per il Mediation Controller. A tale scopo, occorre prima ottenere il nome dell'interfaccia di rete della macchina. Eseguire il comando seguente come root:

1
ip -br a | grep -ve "^lo"

Questo comando visualizza il nome dell'interfaccia di rete, il suo stato e gli indirizzi IP assegnati all'interfaccia.

Esempio

Dopo l'esecuzione del comando, viene visualizzato il risultato seguente:

1
ens192           UP             172.16.0.23/20 172.16.0.27/32 172.16.0.28/32 172.16.0.29/32 172.16.0.24/20

Il nome dell'interfaccia di rete è ens192.

Una volta ottenuto il nome dell'interfaccia di rete, è ora possibile modificare la configurazione di rete della macchina.
Modificare il file /etc/network/interfaces seguendo il modello seguente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto INTERFACE_NAME
iface INTERFACE_NAME inet static
    address RIP_MED_WEB_MASTER
    netmask NETMASK
    gateway NETWORK_GATEWAY
    dns-nameservers IP_DNS_1 IP_DNS_2
    dns-search DNS_SUFFIX

# The secondary network interface
auto INTERFACE_NAME:1
iface INTERFACE_NAME:1 inet static
    address RIP_MED_SSL_MASTER
    netmask NETMASK

Dove:

  • INTERFACE_NAME deve essere sostituito con il nome dell'interfaccia di rete ottenuto in precedenza.
  • RIP_MED_WEB_MASTER deve essere sostituito con l'indirizzo IP reale principale del server, che sarà l'indirizzo IP tramite il quale si accederà alle console web.
  • NETMASK deve essere sostituito con la maschera di rete associata all'indirizzo IP.
  • NETWORK_GATEWAY deve essere sostituito con il gateway di rete predefinito.
  • IP_DNS deve essere sostituito con l'indirizzo IP del server DNS. Se occorre configurare più server (3 al massimo), separarli con uno spazio.
  • DNS_SUFFIX deve essere sostituito con il suffisso DNS da utilizzare. Se non occorre indicare alcun suffisso, eliminare la riga.
  • RIP_MED_SSL_MASTER deve essere sostituito con l'indirizzo IP reale secondario del server. Sarà l'indirizzo IP tramite il quale l'SSL Router sarà accessibile.
Esempio 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
    address 10.0.10.10
    netmask 255.255.255.0
    gateway 10.0.10.254
    dns-nameservers 10.0.10.100 10.0.10.101
    dns-search domain.local

# The secondary network interface
auto eth0:1
iface eth0:1 inet static
    address 10.0.10.11
    netmask 255.255.255.0

Infine, resta solo da riavviare il servizio networking per caricare la nuova configurazione di rete: 

1
systemctl restart networking

È indispensabile configurare un indirizzo di rete statico per il Mediation Controller. A tale scopo, occorre prima ottenere il nome dell'interfaccia di rete della macchina. Eseguire il comando seguente come root:

1
ip -br a | grep -ve "^lo"

Questo comando visualizza il nome dell'interfaccia di rete, il suo stato e gli indirizzi IP assegnati all'interfaccia.

Esempio

Dopo l'esecuzione del comando, viene visualizzato il risultato seguente:

1
ens192           UP             172.16.0.25/20 172.16.0.27/32 172.16.0.28/32 172.16.0.29/32 172.16.0.26/20

Il nome dell'interfaccia di rete è ens192.

Una volta ottenuto il nome dell'interfaccia di rete, è ora possibile modificare la configurazione di rete della macchina.
Modificare il file /etc/network/interfaces seguendo il modello seguente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto INTERFACE_NAME
iface INTERFACE_NAME inet static
    address RIP_MED_WEB_SLAVE
    netmask NETMASK
    gateway NETWORK_GATEWAY
    dns-nameservers IP_DNS_1 IP_DNS_2
    dns-search DNS_SUFFIX

# The secondary network interface
auto INTERFACE_NAME:1
iface INTERFACE_NAME:1 inet static
    address RIP_MED_SSL_SLAVE
    netmask NETMASK

Dove:

  • INTERFACE_NAME deve essere sostituito con il nome dell'interfaccia di rete ottenuto in precedenza.
  • RIP_MED_WEB_SLAVE deve essere sostituito con l'indirizzo IP reale principale del server, che sarà l'indirizzo IP tramite il quale si accederà alle console web.
  • NETMASK deve essere sostituito con la maschera di rete associata all'indirizzo IP.
  • NETWORK_GATEWAY deve essere sostituito con il gateway di rete predefinito.
  • IP_DNS deve essere sostituito con l'indirizzo IP del server DNS. Se occorre configurare più server (3 al massimo), separarli con uno spazio.
  • DNS_SUFFIX deve essere sostituito con il suffisso DNS da utilizzare. Se non occorre indicare alcun suffisso, eliminare la riga.
  • RIP_MED_SSL_SLAVE deve essere sostituito con l'indirizzo IP reale secondario del server. Sarà l'indirizzo IP tramite il quale l'SSL Router sarà accessibile.
Esempio 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
    address 10.0.10.12
    netmask 255.255.255.0
    gateway 10.0.10.254
    dns-nameservers 10.0.10.100 10.0.10.101
    dns-search domain.local

# The secondary network interface
auto eth0:1
iface eth0:1 inet static
    address 10.0.10.13
    netmask 255.255.255.0

Infine, resta solo da riavviare il servizio networking per caricare la nuova configurazione di rete: 

1
systemctl restart networking

Resta un ultimo passaggio: modificare la risoluzione dei nomi interna della macchina affinché risolva il suo indirizzo IP reale principale (corrispondente a RIP_MED_WEB_MASTER o RIP_MED_WEB_SLAVE).
A tale scopo, modificare il file /etc/hosts e sostituire 127.0.1.1 con RIP_MED_WEB_MASTER o RIP_MED_WEB_SLAVE in funzione del server Mediation Controller.

Example

Per un server Mediation Controller il cui indirizzo IP web reale è 10.0.10.10 e il cui nome è mediation-controller.domain.local, il file /etc/hosts avrà il valore seguente:

1
2
127.0.0.1       localhost
10.0.10.10      mediation-controller.domain.local   mediation-controller

Attenzione!

Una configurazione errata del file può causare un errore durante l'installazione del pacchetto collectd.

Configurazione del gestore di pacchetti APT

Caricare nella directory /tmp/ del server, tramite un client SCP, i file scaricati da Systancia Marketplace:

  • systancia.gpg
  • cleanroom-4.6.1-build33.1096.D12-full.tgz

Connettersi al server come root, quindi eseguire i comandi seguenti per decomprimere il repository Systancia, configurarne l'uso in APT e autenticarlo.

1
2
3
4
5
mv /tmp/systancia.gpg /etc/apt/trusted.gpg.d/
mkdir -p /opt/systancia/repository/
tar xvzf /tmp/cleanroom-4.6*.tgz -C /opt/systancia/repository/
echo "deb file:///opt/systancia/repository/ bookworm ipdiva" > /etc/apt/sources.list.d/systancia.list
apt update

Si raccomanda vivamente di disabilitare l'installazione dei pacchetti non necessari durante l'esecuzione dei comandi apt. A tale scopo, eseguire il comando seguente:

1
echo -e 'APT::Install-Recommends false;\nAPT::Install-Suggests false;' > /etc/apt/apt.conf.d/99norecommends

Verifica della presenza del locale en_US.utf8

L'installazione del server Mediation Controller richiede la generazione dei locale en_US.utf8.
Per verificare se sono già stati generati sul server, eseguire il comando seguente come root:

1
locale -a  | grep en_US.utf8

Se la risposta del comando visualizza en_US.utf8, passare al passaggio successivo, la configurazione di GRUB.
In caso contrario, eseguire i comandi seguenti per aggiungere questo locale alla macchina:

1
2
sed -i "s/# en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/" /etc/locale.gen
locale-gen

Configurazione del programma di avvio GRUB

Una volta eseguiti questi comandi, occorre riavviare la macchina dopo aver applicato un'impostazione nel programma di avvio GRUB:

1
2
3
sed '9s/quiet/quiet vsyscall=emulate/' -i /etc/default/grub
update-grub
reboot

Installazione del server Mediation Controller di CyberElements Bastion

Installazione dei componenti di base

Avviare l'installazione dei componenti con il comando seguente, eseguito come root:

1
apt install -y ipdiva-base

Dopo il download di tutte le dipendenze, si apre una finestra che chiede di selezionare il tipo di server. Selezionare mediation:

Selezionare quindi la modalità di installazione lbMaster:

Selezionare quindi la modalità di installazione lbSlave:

Occorrerà quindi immettere la porta sulla quale l'SSL Router sarà in ascolto. Questa porta di ascolto è di solito la 443, ma è possibile utilizzare anche la porta 8443 se il Mediation Controller utilizza un solo IP:

Impostare poi la modalità Cluster su loadbalancing affinché il carico degli utenti sia distribuito sui due server Mediation Controller:

Indicare l'indirizzo IP virtuale web del Cluster, VIP_MED_WEB:

Immettere l'indirizzo IP virtuale SSL del Cluster, VIP_MED_SSL:

Immettere l'indirizzo IP virtuale del database di configurazione del Cluster, VIP_MED_ZEO:

Immettere l'indirizzo IP reale web del Mediation Controller MASTER, RIP_MED_WEB_MASTER:

Immettere l'indirizzo IP reale SSL del Mediation Controller MASTER, RIP_MED_SSL_MASTER:

Immettere l'indirizzo IP reale web del Mediation Controller SLAVE, RIP_MED_WEB_SLAVE:

Infine, immettere l'indirizzo IP reale SSL del Mediation Controller SLAVE, RIP_MED_SSL_SLAVE:

Cosa fare in caso di errore?

Se si è verificato un errore nelle informazioni immesse, proseguire con l'installazione del pacchetto ipdiva-base e utilizzare quindi il comando seguente per riconfigurare il server:

1
dpkg-reconfigure ipdiva-base

Installazione dei componenti Cluster

Dopo l'installazione dei componenti di base, i componenti Cluster devono essere installati sui server Mediation Controller:

1
apt install -y ipdiva-mediation-cluster

Dopo l'installazione dei componenti è necessario un riavvio:

1
reboot

Configurazione del Cluster

Modifica della password della console /mediation/system di CyberElements Gate

In questa fase dell'installazione è disponibile una nuova interfaccia di amministrazione: Modificare la password

Applicazione delle licenze e dei certificati

Sempre nella console /mediation/system, occorrerà immettere i certificati e le licenze del server Mediation Controller.

Attenzione!

La licenza e il certificato dell'SSL Router sono specifici del server Mediation Controller MASTER o SLAVE.
La configurazione di una licenza o di un certificato errati causerà malfunzionamenti in seguito.

Applicare la licenza e il certificato del componente SSL Router:

  1. Fare clic sulla scheda Settings.
  2. Selezionare SSL Connections nel menu.
  3. Cercare il certificato dell'SSL Router.
  4. Immettere la password del certificato dell'SSL Router.
  5. Fare clic su Apply per applicare il certificato all'SSL Router.
  6. Selezionare il file di licenza del server.
  7. Fare clic su Modify per applicare la licenza del server.

Immettere quindi le informazioni del certificato del client CyberElements Bastion:

  1. Selezionare la scheda Plugin.
  2. Cercare il certificato del client CyberElements Bastion.
  3. Immettere la password del certificato.
  4. Fare clic su Apply per applicare il certificato.

Resta da immettere le informazioni del certificato Watchdog:

  1. Selezionare la scheda Watchdog
  2. Cercare il certificato Watchdog.
  3. Immettere la password del certificato.
  4. Fare clic su Apply per applicare il certificato.

Affinché queste modifiche abbiano effetto, occorre riavviare l'SSL Router e il Watchdog:

Pairing dei server Mediation Controller

Attenzione!

A questo punto, entrambi i server Mediation Controller devono essere stati configurati fino all'applicazione delle licenze e dei certificati.
Se il server Mediation Controller SLAVE non è ancora stato configurato, procedere partendo dall'inizio di questa documentazione.

Il passaggio di pairing dei server Mediation Controller stabilirà un collegamento di fiducia tra i due server e inizializzerà il funzionamento in Cluster.

Sul server Mediation Controller SLAVE

Eseguire il comando seguente come root per avviare una richiesta di pairing con il server Mediation Controller MASTER:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Sostituire RIP_MED_WEB_MASTER con l'indirizzo IP corrispondente.

Esempio

Se RIP_MED_WEB_MASTER è uguale a 10.0.10.10, il comando da immettere è il seguente:

1
hostManagerCtl bootstrap 10.0.10.10

Sul server Mediation Controller MASTER

Eseguire il comando seguente come root per visualizzare le richieste di pairing in attesa e recuperare l'identificativo della richiesta: 

1
hostManagerCtl getPendingRequests

Eseguire quindi il comando seguente per accettare la richiesta di pairing, sostituendo ID con l'identificativo ottenuto con il comando precedente:

1
hostManagerCtl acceptRequest ID
Esempio

Se il risultato del comando hostManagerCtl getPendingRequests è il seguente:

1
2
3
                  id          name      url
===============================================================
900elffl744ph7vpn6kepiswdh1rncd73            slave      https://10.0.10.12:9060/

Il comando per accettare la richiesta di pairing è quindi il seguente:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

Per verificare l'associazione, utilizzare il comando seguente sul server Mediation Controller (indifferentemente MASTER o SLAVE):

1
hostManagerCtl listPeers

Il risultato varia in funzione del server sul quale viene eseguito il comando:

Il risultato atteso sul server Mediation Controller MASTER è il seguente:

1
slave -> RIP_MED_WEB_SLAVE
Esempio 
1
slave -> 10.0.10.12

Il risultato atteso sul server Mediation Controller SLAVE è il seguente:

1
master -> RIP_MED_WEB_MASTER
Esempio 
1
master -> 10.0.10.10

Sul server Mediation Controller SLAVE

È possibile verificare lo stato del bootstrap dal server SLAVE con il comando seguente:

1
hostManagerCtl getBootstrapStatus

Un Cluster che non presenta alcun problema di sincronizzazione restituirà il valore 0.

È necessaria un'ultima serie di comandi, sempre sul server SLAVE, per sincronizzare un segreto condiviso tra i due Mediation Controller:

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2
A cosa serve la connessione interserver?

Si tratta di una connessione particolare del funzionamento in Cluster, che consente a un server Mediation Controller di instradare il traffico verso un altro server Mediation Controller quando l'Edge Gateway di destinazione non è connesso al primo server, ma soltanto al secondo.

Ad esempio, se il server Mediation Controller MASTER non è più connesso all'Edge Gateway, può utilizzare il collegamento interserver per raggiungerlo tramite il server Mediation Controller SLAVE.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Connessione perduta| GW(Edge Gateway)
    MASTER --> |Collegamento tra server| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

Sul server Mediation Controller MASTER

Modificare il file /etc/ipdiva/server/remoteServers.xml per indicare il CN del certificato interserver:

1
2
3
4
5
6
7
8
9
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='SLAVECN'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->

Sostituire SLAVECN con il CN del certificato destinato alla connessione interserver.
Se non si conosce il CN del certificato interserver, è possibile immettere il carattere * (consigliato in caso di dubbio):

1
2
3
4
5
6
7
8
9
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='*'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->
Esempio

Tenendo conto delle informazioni seguenti:

  • CN del certificato interserver: my-interserver-cert

Il file /etc/ipdiva/server/remoteServers.xml del server Mediation Controller MASTER andrebbe completato come segue:

1
2
3
4
5
6
7
8
9
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='my-interserver-cert'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->
File completo 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='interserver-documentation-cluster'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->

                <!-- in this example we use a custom certificate, it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl">
                                <cert>/etc/ipdiva/server/ssl/interserver.p12</cert>
                <password>s3cr3t</password>
                <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
                <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
                                <min-version>tls1.3</min-version>
                                <max-version></max-version>
                                <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
                                <cipherlist-tls1.3>TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256</cipherlist-tls1.3>
                <use-cn>no</use-cn>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
                <cert-peername>MASTERCN</cert-peername>
                        </remoteServer>
                -->
        </localCluster>

        <!--
                Intersites connections
        -->
        <intersites localSiteName='localSite1'>
                <!-- An accepted remote connection
                        name : the name of the accepted remote site
                        password : the associated password
                        pattern : a list of pattern of allowed peers for this remote site (separated by ;)
                -->
                <!-- <accept name='david-desktop' password='passwd' pattern='S:[^@]+@ipdiva'/> -->

                <!-- A connection to a remote site
                        name : is the name of the remoteSite
                        password : the password to use to connect
                        pattern : a list of pattern (regex) of the gateway that could be addressed via this link (separated by ;)
                        connect : a connection URL

                        the body can contain traditional TlsData parameters:
                            <cert>file.p12</cert>
                            <password>....</password>
                            <cadir>....</cadir>
                -->
                <!--
                        <remoteSite name='remoteSiteName'
                                        password='mypass'
                                        pattern='S:gw1@ipdiva;S:gw2@ipdiva'
                                        connect="192.168.0.168:9002" />
                -->
        </intersites>


</remoteConfig>

Sul server Mediation Controller SLAVE

Inviare il certificato interserver al Mediation Controller SLAVE, nella directory /tmp/.
Eseguire quindi i comandi seguenti come root per spostarlo nella directory di destinazione con le autorizzazioni appropriate:

1
2
3
mv /tmp/*.p12 /etc/ipdiva/server/ssl/
chown root:ipdivasrv /etc/ipdiva/server/ssl/*.p12
chmod 640 /etc/ipdiva/server/ssl/*.p12

Modificare quindi il file /etc/ipdiva/server/remoteServers.xml per aggiungere il contenuto seguente al tag <remoteConfig> (il vecchio tag <localCluster> può essere eliminato completamente):

 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
<localCluster allowed-cns='MASTERCN'>
    <remoteServer connect="RIP_MED_SSL_MASTER:PORT_RIP_MED_SSL_MASTER:ssl">
        <cert>/etc/ipdiva/server/ssl/INTERSERVER.P12</cert>
        <password>PASSWORD</password>
        <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
        <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
        <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
        <use-cn>no</use-cn>
        <verify-cert>true</verify-cert>
        <verify-certhostnamematch>true</verify-certhostnamematch>
        <cert-peername>MASTERCN</cert-peername>
    </remoteServer>
</localCluster>

Sostituire:

  • MASTERCN: indicare il CN del certificato dell'SSL Router del Mediation Controller MASTER, che di solito è RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER: corrisponde all'indirizzo IP secondario del Mediation Controller MASTER.
  • PORT_RIP_MED_SSL_MASTER: è la porta di ascolto dell'SSL Router del Mediation Controller MASTER; di solito è la 443.
  • INTERSERVER.P12: nome del certificato destinato all'interserver.
  • PASSWORD: password del certificato interserver.
Esempio

Tenendo conto delle informazioni seguenti:

  • Nome del certificato interserver: my-interserver-cert.p12
  • Password del certificato interserver: MySecurePassword
  • RIP SSL del Mediation Controller MASTER: 10.0.10.11
  • Porta sulla RIP SSL del Mediation Controller MASTER: 443
  • CN del certificato del Mediation Controller MASTER: 10.0.10.11

Il file /etc/ipdiva/server/remoteServers.xml del server Mediation Controller SLAVE andrebbe completato come segue:

 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
<localCluster allowed-cns='10.0.10.11'>
    <remoteServer connect="10.0.10.11:443:ssl">
        <cert>/etc/ipdiva/server/ssl/my-interserver-cert.p12</cert>
        <password>MySecurePassword</password>
        <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
        <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
        <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
        <use-cn>no</use-cn>
        <verify-cert>true</verify-cert>
        <verify-certhostnamematch>true</verify-certhostnamematch>
        <cert-peername>10.0.10.11</cert-peername>
    </remoteServer>
</localCluster>
File completo 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='10.0.10.11'>
            <remoteServer connect="10.0.10.11:443:ssl">
                <cert>/etc/ipdiva/server/ssl/my-interserver-cert.p12</cert>
                <password>MySecurePassword</password>
                <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
                <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
                <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
                <use-cn>no</use-cn>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
                <cert-peername>10.0.10.11</cert-peername>
            </remoteServer>
        </localCluster>

        <!--
                Intersites connections
        -->
        <intersites localSiteName='localSite1'>
                <!-- An accepted remote connection
                        name : the name of the accepted remote site
                        password : the associated password
                        pattern : a list of pattern of allowed peers for this remote site (separated by ;)
                -->
                <!-- <accept name='david-desktop' password='passwd' pattern='S:[^@]+@ipdiva'/> -->

                <!-- A connection to a remote site
                        name : is the name of the remoteSite
                        password : the password to use to connect
                        pattern : a list of pattern (regex) of the gateway that could be addressed via this link (separated by ;)
                        connect : a connection URL

                        the body can contain traditional TlsData parameters:
                            <cert>file.p12</cert>
                            <password>....</password>
                            <cadir>....</cadir>
                -->
                <!--
                        <remoteSite name='remoteSiteName'
                                        password='mypass'
                                        pattern='S:gw1@ipdiva;S:gw2@ipdiva'
                                        connect="192.168.0.168:9002" />
                -->
        </intersites>


</remoteConfig>

Modificare la configurazione dell'SSL Router SLAVE eseguendo il comando seguente:

1
sed -i '8i\\t<network-id>1</network-id>' /etc/ipdiva/server/server.xml

Sui server Mediation Controller MASTER e SLAVE

Riavviare l'SSL Router per applicare le impostazioni del collegamento interserver:

1
/usr/local/ipdiva/server/bin/restart

Per confermare che il collegamento interserver funziona correttamente, il comando seguente deve restituire un risultato:

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

Il comando precedente deve produrre un log contenente quanto segue: TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers, and 0 multicast group(s).
Se non viene visualizzato alcun log di questo tipo, verificare la configurazione effettuata in questo capitolo.

Nella console web /mediation/system del Mediation Controller MASTER

Attivare la connessione interserver tra i due Mediation Controller modificando l'host virtuale SSL default:

Compilare i vari campi seguendo le indicazioni riportate di seguito e attivare la funzionalità di collegamento interserver selezionando la casella Is cross-server linking configured?:

  • Public address for plugin connections: corrisponde a VIP_MED_SSL seguito dalla sua porta di ascolto (di solito la 443).
  • Actual public IP addresses for web connections: corrisponde alla coppia di indirizzi IP web reali (RIP_MED_WEB_MASTER e RIP_MED_WEB_SLAVE) con le rispettive porte, una riga per ogni coppia di indirizzo IP e porta.
  • Actual public IP addresses for SSL connections: corrisponde alla coppia di indirizzi IP SSL reali (RIP_MED_SSL_MASTER e RIP_MED_SSL_SLAVE) con le rispettive porte, una riga per ogni coppia di indirizzo IP e porta.

Installazione dei componenti specifici di CyberElements Bastion

Avviare l'installazione dei componenti di CyberElements Bastion sui server Mediation Controller con il comando seguente:

1
apt install -y ipdiva-safe-server

I server devono essere riavviati per completare l'installazione:

1
reboot

Connessione al database PostgreSQL

Per funzionare, CyberElements Bastion richiede l'uso di un database PostgreSQL (DB) esterno per memorizzare le proprie impostazioni e i vari log nella console /system.
Se il DB è direttamente accessibile dai server Mediation Controller, passare direttamente al passaggio di inizializzazione del DB.

Connessione a un database nella LAN

Per consentire la connessione a un database situato nella LAN senza aprire un flusso dalla DMZ verso la LAN, il flusso del database verrà reindirizzato attraverso un tunnel TLS tra gli Edge Gateway e i Mediation Controller.
A tale scopo, è necessario configurare un Edge Gateway (o due Edge Gateway) utilizzando la tecnologia sottostante CyberElements Gate.

Dichiarazione degli Edge Gateway CyberElements Gate

A tale scopo, iniziare connettendosi alla console /mediation/system di CyberElements Gate.

Passare quindi al menu «Organizations» e fare clic su «Add»:

Immettere il nome dell'organizzazione, che deve essere diverso da quello assegnato a CyberElements Bastion (ad esempio, tunnel), e indicare almeno una licenza di sessione utente insieme alla password dell'account admin:

Connettersi all'interfaccia di amministrazione dell'organizzazione creata in precedenza con l'account admin, accedendo a /gate/admin:

Dichiarare quindi i due Edge Gateway che verranno utilizzati per stabilire il tunnel.
A sinistra, passare il puntatore su Infrastructure, fare clic su Gateways e quindi sul pulsante Add:

Immettere il nome del primo Edge Gateway e confermare l'immissione:

Informazioni

Come promemoria, il nome di un Edge Gateway è collegato al certificato che utilizzerà per autenticarsi presso l'SSL Router del Mediation Controller.
Questo nome assume la forma seguente <GW_NAME>@<ORGANIZATION_NAME>, dove <GW_NAME> corrisponde al nome dell'Edge Gateway e <ORGANIZATION_NAME> corrisponde al nome dell'organizzazione creata nella console di sistema di CyberElements Gate.

Ripetere il passaggio di dichiarazione per il secondo Edge Gateway.

Connessioni e impostazioni del tunnel sugli Edge Gateway

Informazioni

I passaggi seguenti possono essere replicati sui due Edge Gateway utilizzati per il tunnel di accesso al database.

Prerequisiti

Per completare questa parte, occorrerà utilizzare una delle due opzioni seguenti:

In primo luogo, utilizzare uno strumento come WinSCP o FileZilla per trasferire tramite SCP, nella directory /tmp/ dell'Edge Gateway, il certificato necessario per la connessione.

Connettersi quindi tramite SSH e passare a root.

Per connettere l'Edge Gateway ai due Mediation Controller, occorre creare due nuove istanze di Edge Gateway: una si connetterà al Mediation Controller MASTER, l'altra al Mediation Controller SLAVE.
Per crearle, eseguire i comandi seguenti:

1
2
/usr/local/ipdiva/gateway/bin/gatewayCloner -tunnel-master
/usr/local/ipdiva/gateway/bin/gatewayCloner -tunnel-slave

Copiare il file del certificato nelle directory /etc/ipdiva/gateway-tunnel-master/ssl/ e /etc/ipdiva/gateway-tunnel-slave/ssl/:

1
2
cp /tmp/<CERT_NAME> /etc/ipdiva/gateway-tunnel-master/ssl/
cp /tmp/<CERT_NAME> /etc/ipdiva/gateway-tunnel-slave/ssl/

Sostituire <CERT_NAME> con il nome del certificato che l'Edge Gateway deve utilizzare per connettersi al Mediation Controller.

Configurare le istanze di Edge Gateway affinché possano connettersi ai Mediation Controller.
Le configurazioni differiscono in funzione del Mediation Controller da contattare. Effettuare entrambe le impostazioni:

Modificare il file /etc/ipdiva/gateway-tunnel-master/gateway.xml e completarlo con le informazioni seguenti (diverse sezioni sono state omesse e sono indicate da […]):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<gateway>
    <server>@SERVER@:@SERVERPORT@:ssl</server>
[…]
    <ssl>
        <cert>/etc/ipdiva/gateway-tunnel-master/ssl/keyfile.pem</cert>
        <password>PASSWORD</password>
[…]
    </ssl>
[…]
    <rpc-listen>127.0.0.1:@RPC_PORT@</rpc-listen>
[…]
</gateway>

Sostituire gli elementi seguenti:

  • @SERVER@: deve essere sostituito con l'indirizzo RIP_MED_SSL_MASTER
  • @SERVERPORT@: deve essere sostituito con la porta di ascolto dell'SSL Router, normalmente la 443
  • keyfile.pem: deve essere sostituito con il nome del file del certificato
  • PASSWORD: deve essere sostituito con la password del certificato
  • @RPC_PORT@: deve essere sostituito con una porta su cui la macchina non è attualmente in ascolto; è possibile utilizzare la porta 9082
Esempio

Tenendo conto delle informazioni seguenti:

  • RIP_MED_SSL_MASTER è uguale a: 10.0.10.11
  • Porta di ascolto dell'SSL Router: 443
  • Nome del file del certificato: gate-tunnel.p12
  • Password del certificato: Str0ngP@ssw0rd

Il file /etc/ipdiva/gateway-tunnel-master/gateway.xml andrebbe configurato come segue:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<gateway>
    <server>10.0.10.11:443:ssl</server>
[…]
    <ssl>
        <cert>/etc/ipdiva/gateway-tunnel-master/ssl/gate-tunnel.p12</cert>
        <password>Str0ngP@ssw0rd</password>
[…]
    </ssl>
[…]
    <rpc-listen>127.0.0.1:9082</rpc-listen>
[…]
</gateway>
File completo 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
<gateway>
        <server>10.0.10.11:443:ssl</server>
        <pipe>
                <ping-timeout>60000</ping-timeout>
                <rout-max-lock>20000</rout-max-lock>
        </pipe>
        <timeout>
                <reconnect>15000</reconnect>
        </timeout>
        <ticket><hmac></hmac></ticket>
        <proxy>
                <type>no</type>
                <address></address>
                <login></login>
                <password></password>
                <domain></domain>
        </proxy>
        <periodic-licence-check>false</periodic-licence-check>
        <session>
           <sslconf name="default">
              <ca-dir>/etc/ssl/certs</ca-dir>
              <verify-cert>true</verify-cert>
           </sslconf>
        </session>
        <ssl>
                <cert>/etc/ipdiva/gateway-tunnel-master/ssl/gate-tunnel.p12</cert>
                <password>Str0ngP@ssw0rd</password>
                <ca-dir>/etc/ipdiva/gateway-tunnel-master/ssl/ca</ca-dir>
                <min-version>tls1.3</min-version>
                <max-version></max-version>
                <cipherlist>!ADH:!AECDH:!MD5:kEECDH+AES:kEDH+AES:AES256+RSA:3DES+RSA</cipherlist>
                <cipherlist-tls1.3>TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256</cipherlist-tls1.3>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
        </ssl>
        <webaccess>
                <proxy></proxy>
                <useragent>true</useragent>
                <autoauth>true</autoauth>
                <forceauth>false</forceauth>
                <forcebasic>false</forcebasic>
                <persistentbasicauth>true</persistentbasicauth>
                <cache-date>Thu, 14 Dec 2006 09:28:00 GMT</cache-date>
                <reverse-proxy>
                        <headers>
                                <x-forwarded-for enabled='false'/>
                                <x-forwarded-host enabled='false'/>
                        </headers>
                </reverse-proxy>
                <davenport compatibilityMode="false">127.0.0.1:8070</davenport>
        </webaccess>
        <rpc-listen>127.0.0.1:9082</rpc-listen>
        <network-id></network-id>
        <services>/etc/ipdiva/gateway-tunnel-master/services.xml</services>
        <compression>zlib</compression>
        <vlan>
                <prefixe></prefixe>
        </vlan>

        <openvpn>
                <ssl>
                        <cert>/usr/local/ipdiva/share/gw-controller-openvpnng/keys/allInOne.pem</cert>
                        <ca-file>/usr/local/ipdiva/share/gw-controller-openvpnng/keys/tmp-ca.crt</ca-file>
                        <version>tls1</version>
                </ssl>
                <client-ov>
                        <ip-type>V4</ip-type>
                        <dev-type>tun</dev-type>
                        <link-mtu>1507</link-mtu>
                        <tun-mtu>1500</tun-mtu>
                        <proto>TCPv4_CLIENT</proto>
                        <cipher>[null-cipher]</cipher>
                        <auth>[null-digest]</auth>
                        <keysize>0</keysize>
                        <key-method>2</key-method>
                        <tls-type>tls-client</tls-type>
                </client-ov>
        </openvpn>
    <useoldprotocol>false</useoldprotocol>
    <rate>0</rate>
</gateway>

Modificare il file /etc/ipdiva/gateway-tunnel-slave/gateway.xml e completarlo con le informazioni seguenti (diverse sezioni sono state omesse e sono indicate da […]):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<gateway>
    <server>@SERVER@:@SERVERPORT@:ssl</server>
[…]
    <ssl>
        <cert>/etc/ipdiva/gateway-tunnel-slave/ssl/keyfile.pem</cert>
        <password>PASSWORD</password>
[…]
    </ssl>
[…]
    <rpc-listen>127.0.0.1:@RPC_PORT@</rpc-listen>
[…]
</gateway>

Sostituire gli elementi seguenti:

  • @SERVER@: deve essere sostituito con l'indirizzo RIP_MED_SSL_SLAVE
  • @SERVERPORT@: deve essere sostituito con la porta di ascolto dell'SSL Router, normalmente la 443
  • keyfile.pem: deve essere sostituito con il nome del file del certificato
  • PASSWORD: deve essere sostituito con la password del certificato
  • @RPC_PORT@: deve essere sostituito con una porta non attualmente in uso sulla macchina; è possibile utilizzare la porta 9083
Esempio

Tenendo conto delle informazioni seguenti:

  • RIP_MED_SSL_SLAVE è uguale a: 10.0.10.13
  • Porta di ascolto dell'SSL Router: 443
  • Nome del file del certificato: gate-tunnel.p12
  • Password del certificato: Str0ngP@ssw0rd

Il file /etc/ipdiva/gateway-tunnel-slave/gateway.xml andrebbe configurato come segue:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<gateway>
    <server>10.0.10.13:443:ssl</server>
[…]
    <ssl>
        <cert>/etc/ipdiva/gateway-tunnel-slave/ssl/gate-tunnel.p12</cert>
        <password>Str0ngP@ssw0rd</password>
[…]
    </ssl>
[…]
    <rpc-listen>127.0.0.1:9083</rpc-listen>
[…]
</gateway>
File completo 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
<gateway>
        <server>10.0.10.13:443:ssl</server>
        <pipe>
                <ping-timeout>60000</ping-timeout>
                <rout-max-lock>20000</rout-max-lock>
        </pipe>
        <timeout>
                <reconnect>15000</reconnect>
        </timeout>
        <ticket><hmac></hmac></ticket>
        <proxy>
                <type>no</type>
                <address></address>
                <login></login>
                <password></password>
                <domain></domain>
        </proxy>
        <periodic-licence-check>false</periodic-licence-check>
        <session>
           <sslconf name="default">
              <ca-dir>/etc/ssl/certs</ca-dir>
              <verify-cert>true</verify-cert>
           </sslconf>
        </session>
        <ssl>
                <cert>/etc/ipdiva/gateway-tunnel-slave/ssl/gate-tunnel.p12</cert>
                <password>Str0ngP@ssw0rd</password>
                <ca-dir>/etc/ipdiva/gateway-tunnel-slave/ssl/ca</ca-dir>
                <min-version>tls1.3</min-version>
                <max-version></max-version>
                <cipherlist>!ADH:!AECDH:!MD5:kEECDH+AES:kEDH+AES:AES256+RSA:3DES+RSA</cipherlist>
                <cipherlist-tls1.3>TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256</cipherlist-tls1.3>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
        </ssl>
        <webaccess>
                <proxy></proxy>
                <useragent>true</useragent>
                <autoauth>true</autoauth>
                <forceauth>false</forceauth>
                <forcebasic>false</forcebasic>
                <persistentbasicauth>true</persistentbasicauth>
                <cache-date>Thu, 14 Dec 2006 09:28:00 GMT</cache-date>
                <reverse-proxy>
                        <headers>
                                <x-forwarded-for enabled='false'/>
                                <x-forwarded-host enabled='false'/>
                        </headers>
                </reverse-proxy>
                <davenport compatibilityMode="false">127.0.0.1:8070</davenport>
        </webaccess>
        <rpc-listen>127.0.0.1:9083</rpc-listen>
        <network-id></network-id>
        <services>/etc/ipdiva/gateway-tunnel-slave/services.xml</services>
        <compression>zlib</compression>
        <vlan>
                <prefixe></prefixe>
        </vlan>

        <openvpn>
                <ssl>
                        <cert>/usr/local/ipdiva/share/gw-controller-openvpnng/keys/allInOne.pem</cert>
                        <ca-file>/usr/local/ipdiva/share/gw-controller-openvpnng/keys/tmp-ca.crt</ca-file>
                        <version>tls1</version>
                </ssl>
                <client-ov>
                        <ip-type>V4</ip-type>
                        <dev-type>tun</dev-type>
                        <link-mtu>1507</link-mtu>
                        <tun-mtu>1500</tun-mtu>
                        <proto>TCPv4_CLIENT</proto>
                        <cipher>[null-cipher]</cipher>
                        <auth>[null-digest]</auth>
                        <keysize>0</keysize>
                        <key-method>2</key-method>
                        <tls-type>tls-client</tls-type>
                </client-ov>
        </openvpn>
    <useoldprotocol>false</useoldprotocol>
    <rate>0</rate>
</gateway>

Ora che le istanze sono configurate per connettersi ai Mediation Controller, resta da configurarle per reindirizzare verso il database la connessione del Mediation Controller.
A tale scopo, modificare il file /etc/ipdiva/gateway-tunnel-master/services.xml come segue: 

1
2
3
4
5
6
7
8
9
<services>
    <out>
        <service>
            <name>DB</name>
            <protocol>tcp</protocol>
            <connect>DB_SERVER:DB_PORT</connect>
        </service>
    </out>
</services>

Sostituire DB_SERVER con il nome DNS o l'indirizzo IP utilizzato per connettersi al database e DB_PORT con la porta di ascolto dell'istanza di database.
Replicare queste impostazioni sull'istanza che si connette al server Mediation Controller SLAVE copiando il file:

1
cp /etc/ipdiva/gateway-tunnel-master/services.xml /etc/ipdiva/gateway-tunnel-slave/

Infine, avviare le istanze di Edge Gateway affinché stabiliscano la connessione con i Mediation Controller:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Configurazione del tunnel dei Mediation Controller

Affinché il tunnel possa essere utilizzato dai Mediation Controller, resta da dichiararne l'esistenza.
A tale scopo, connettersi come root ai Mediation Controller e modificare il file /etc/ipdiva/server/services.xml per aggiungere la sezione seguente (diverse sezioni sono state omesse e sono indicate da […]):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<services>
[…]
    <in>
[…]
        <service>
            <name>DB</name>
            <gateway>GW1_NAME@ORGANIZATION_NAME</gateway>
            <gateway>GW2_NAME@ORGANIZATION_NAME</gateway>
            <protocol>tcp</protocol>
            <listen>127.0.0.1:1432</listen>
            <must-exist>true</must-exist>
        </service>
    </in>
</services>

Sostituire gli elementi seguenti:

  • GW1_NAME con il nome del primo Edge Gateway
  • GW2_NAME con il nome del secondo Edge Gateway
  • ORGANIZATION_NAME con il nome dell'organizzazione CyberElements Gate creata in precedenza
Esempio

Tenendo conto delle informazioni seguenti:

  • Nome dell'Edge Gateway 1: gate-tunnel-1
  • Nome dell'Edge Gateway 2: gate-tunnel-2
  • Nome dell'organizzazione CyberElements Gate: tunnel

Il file /etc/ipdiva/server/services.xml andrebbe completato come segue:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<services>
[…]
    <in>
[…]
        <service>
            <name>DB</name>
            <gateway>gate-tunnel-1@tunnel</gateway>
            <gateway>gate-tunnel-2@tunnel</gateway>
            <protocol>tcp</protocol>
            <listen>127.0.0.1:1432</listen>
            <must-exist>true</must-exist>
        </service>
    </in>
</services>
File completo 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<services>
    <out>
        <service>
            <name>ntp</name>
            <protocol>udp</protocol>
            <connect>127.0.0.1:123</connect>
        </service>
        <service>
            <name>logging</name>
            <protocol>tcp</protocol>
            <connect>127.0.0.1:1514</connect>
        </service>
        <service>
            <name>clreanroom_acm</name>
            <protocol>tcp</protocol>
            <connect>127.0.0.1:8001</connect>
        </service>
    </out>
    <in>
        <service>
            <gateway>edge-gateway-1@my-organization-name</gateway>
            <protocol>tcp</protocol>
            <name>HTML5</name>
            <listen>127.0.0.1:1234</listen>
            <must-exist>true</must-exist>
        </service>
        <service>
            <name>DB</name>
            <gateway>gate-tunnel-1@tunnel</gateway>
            <gateway>gate-tunnel-2@tunnel</gateway>
            <protocol>tcp</protocol>
            <listen>127.0.0.1:1432</listen>
            <must-exist>true</must-exist>
        </service>
    </in>
</services>

Per applicare la nuova configurazione, riavviare l'SSL Router con il comando seguente:

1
/usr/local/ipdiva/server/bin/restart

Inizializzazione del database

Attenzione!

Occorre creare il database default prima che CyberElements Bastion lo inizializzi (non viene creato automaticamente).

Per inizializzare il database PostgreSQL di configurazione del sistema, occorre prima configurare le impostazioni di connessione sui Mediation Controller.
A tale scopo, modificare il file /etc/ipdiva/care/databasesettings.ini su entrambi i server e aggiungere le voci seguenti:

2
3
4
5
6
7
8
9
[database]

ENGINE:django.db.backends.postgresql
NAME:default
USER:DB_USERNAME
PASSWORD:DB_PWD
HOST:DB_HOST
PORT:DB_PORT

Sostituire gli elementi seguenti:

  • DB_USERNAME con il nome utente utilizzato per connettersi al database.
  • DB_PWD con la password dell'utente che si connette.
  • DB_HOST con l'indirizzo IP o il nome DNS utilizzato per connettersi al database; se si utilizza una connessione tramite Edge Gateway, occorrerà indicare 127.0.0.1.
  • DB_PORT con la porta utilizzata per connettersi all'istanza di database; se si utilizza una connessione tramite Edge Gateway, occorrerà indicare 1432.

L'inizializzazione del database può essere avviata con i comandi seguenti, da eseguire su un solo Mediation Controller:

1
2
cd /var/lib/ipdiva/care/
python3 manage.py migrate

Successivamente, resta solo da riavviare il servizio apache2 sui due Mediation Controller per applicare l'inizializzazione del database di sistema:

1
systemctl restart apache2

Installazione dei driver per la connessione ai database Microsoft SQL

Se si desidera connettersi a un database esterno e questo è un Microsoft SQL Server, occorre installare driver ODBC aggiuntivi.

Sono disponibili due versioni: la versione 17 e la versione 18.

Connessione TLS obbligatoria per i driver in versione 18

L'uso dei driver ODBC 18 richiede che la connessione sia cifrata mediante TLS. A tale scopo, occorre configurare MS SQL Server per la cifratura delle connessioni.

Prima di avviare l'installazione dei driver ODBC, occorre installare i pacchetti necessari per la preparazione e poi preparare il repository Microsoft per l'installazione dei pacchetti:

1
2
3
4
apt install -y curl apt-transport-https gpg
curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg
curl https://packages.microsoft.com/config/debian/12/prod.list > /etc/apt/sources.list.d/mssql-release.list
apt update

Installare quindi i driver in funzione della versione scelta e configurare il sistema per utilizzare il comando sqlcmd:

1
2
3
ACCEPT_EULA=Y apt install -y msodbcsql17 mssql-tools python3-pip
pip install mssql-scripter --break-system-packages
ln -sfn /opt/mssql-tools/bin/sqlcmd /usr/bin/sqlcmd

1
2
3
ACCEPT_EULA=Y apt install -y msodbcsql18 mssql-tools18 python3-pip
pip install mssql-scripter --break-system-packages
ln -sfn /opt/mssql-tools18/bin/sqlcmd /usr/bin/sqlcmd

I driver ODBC sono ora correttamente installati.
Se il server Mediation Controller ha accesso a un server MS SQL, il comando seguente dovrebbe consentire la connessione al server remoto: 

1
sqlcmd -S SERVER\INSTANCE_NAME,PORT -U USER

Dove:

  • SERVER deve essere sostituito con il nome DNS o l'indirizzo IP del server MS SQL.
  • INSTANCE_NAME deve essere sostituito con il nome dell'istanza alla quale connettersi; se non è necessario, eliminare anche il carattere \.
  • PORT deve essere sostituito con la porta di connessione all'istanza di database MS SQL.
  • USER deve essere sostituito con il nome utente con cui stabilire la connessione.
Esempi

Se il server Mediation Controller ha accesso a un server di database MS SQL all'indirizzo IP 10.0.10.100, l'istanza a cui accedere è in ascolto sulla porta 1433 e l'account di accesso è sql-user. Il comando di connessione è quindi il seguente:

1
sqlcmd -S 10.0.10.100,1433 -U sql-user

Se fosse necessario indicare l'istanza di connessione denominata MSSQLINSTANCE, il comando andrebbe modificato come segue:

1
sqlcmd -S 10.0.10.100\MSSQLINSTANCE,1433 -U sql-user

Configurazione di un server di riferimento orario NTP

Si consiglia di configurare un server di riferimento orario per mantenere aggiornato l'orologio di sistema. I passaggi necessari sono descritti nella pagina di configurazione NTP.

Configurazioni iniziali su CyberElements Bastion

Autorizzazione dell'accesso alle interfacce web con l'IP virtuale

Per impostazione predefinita, non è consentito connettersi alle interfacce web del prodotto CyberElements Bastion con l'IP virtuale VIP_MED_WEB.
Per aggiungere l'autorizzazione, eseguire come root i comandi seguenti sui Mediation Controller:

1
2
sed -i '2s/$/, IP/' /etc/ipdiva/care/djangosettings.ini
systemctl restart apache2

Sostituire IP con l'indirizzo IP corrispondente a VIP_MED_WEB.

Configurazioni iniziali

In questa fase i server Mediation Controller sono installati, ma occorre ancora eseguire diverse azioni:

  • Modificare le password predefinite

    Modificare le password predefinite delle console di sistema.

    Modificare

  • Installare i certificati e le licenze

    Il Mediation Controller richiede diversi certificati e una licenza per essere operativo.
    Solo il certificato del client CyberElements Bastion deve essere dichiarato di nuovo su entrambi i Mediation Controller (utilizzare le RIP RIP_MED_WEB_MASTER e RIP_MED_WEB_SLAVE).

    Installare i certificati e la licenza

  • Configurare il certificato web

    Configurare il certificato web utilizzato per connettersi alle interfacce web

    Configurare

  • Dichiarare un nome DNS

    Aggiungere un nome DNS autorizzato a connettersi alle interfacce web.

    Aggiungere

  • Configurare l'organizzazione

    Configurare l'organizzazione CyberElements Bastion.

    Configurare con accesso diretto al database

    Configurare con accesso al database tramite il tunnel degli Edge Gateway

  • Dichiarare gli Edge Gateway

    Dichiarare gli Edge Gateway o gli HTML5 Gateway da installare.

    Creare gli Edge Gateway

  • Creare un sito logico

    Creare e configurare un sito logico che raggruppa gli Edge Gateway e gli HTML5 Gateway che possono accedere alle risorse locali.

    Creare un sito

  • Installare un Edge Gateway

    Installare e configurare un nuovo Edge Gateway con i server Mediation Controller appena installati.
    Verrà inoltre configurata un'istanza di HTML5 Gateway.

    Installare