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.

Impostazioni di sistema

Connessione alla macchina

Per impostazione predefinita, sulle appliance virtuali esistono due account: un account utente e un account superutente.

  • Account utente
    • Login: systancia
    • Password: systnci
  • Account superutente
    • Login: root
    • Password: systnci

Connettersi alla macchina in modalità console.

Nota

Il layout di tastiera predefinito è QWERTY.

Modifica del layout della tastiera

È possibile cambiare il layout di tastiera con la riga di comando seguente:

1
dpkg-reconfigure keyboard-configuration

Compare un menu che permette di scegliere un altro layout di tastiera.

Utilizzare poi la riga di comando seguente per applicare e salvare le impostazioni:

1
setupcon -k --save

Le impostazioni diventano effettive immediatamente dopo l'esecuzione di questo comando.

Configurazione della rete

È 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

Suggerimento

Ora che le impostazioni di rete sono state applicate, è possibile accedere al server tramite SSH.

Modifica delle password degli account locali

Systancia raccomanda vivamente di cambiare la password di questi account una volta distribuita l'appliance virtuale.

Utilizzare il comando seguente e immettere la nuova password per l'account standard systancia:

1
passwd systancia

Ripetere poi l'operazione per l'account superutente root:

1
passwd root

Configurazione del nome della macchina

È possibile modificare il nome del server configurando i file hostname e hosts del server.

Modificare il file /etc/hostname per indicare il nome della macchina.
Il prodotto necessita del nuovo nome in un'altra posizione; occorre quindi creare una copia del file precedente con il comando seguente:

1
cp /etc/hostname /var/ipdiva/zopeChroot/etc/hostname

È necessario replicare la configurazione del file /etc/hosts in relazione all'indirizzo IP reale principale della macchina (RIP_MED_WEB_MASTER).
A tale scopo, modificare il file /etc/hosts e verificare che la seconda riga abbia il formato seguente:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

Se la macchina si chiama MEDIATION-CONTROLLER-MASTER senza appartenere a un dominio e il suo indirizzo IP reale RIP_MED_WEB_MASTER è 10.0.10.10, il file andrebbe completato come segue:

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Se la macchina appartiene al dominio DOMAIN.LOCAL, il file andrebbe completato come segue:

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER.DOMAIN.LOCAL   MEDIATION-CONTROLLER-MASTER

È necessario replicare la configurazione del file /etc/hosts in relazione all'indirizzo IP reale principale della macchina (RIP_MED_WEB_SLAVE).
A tale scopo, modificare il file /etc/hosts e verificare che la seconda riga abbia il formato seguente:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

Se la macchina si chiama MEDIATION-CONTROLLER-SLAVE senza appartenere a un dominio e il suo indirizzo IP reale RIP_MED_WEB_SLAVE è 10.0.10.12, il file andrebbe completato come segue:

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Se la macchina appartiene al dominio DOMAIN.LOCAL, il file andrebbe completato come segue:

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE.DOMAIN.LOCAL   MEDIATION-CONTROLLER-SLAVE

Per applicare la nuova configurazione, riavviare il server:

1
reboot

Modifica del fuso orario

Per impostazione predefinita, l'appliance virtuale è configurata sul fuso orario Europe/Paris.

Per cambiare questo fuso orario, utilizzare prima il comando seguente per recuperare la sintassi dei fusi orari disponibili:

1
timedatectl list-timezones

Utilizzare poi la riga di comando seguente:

1
timedatectl set-timezone your_time_zone
Esempio

Per impostare il fuso orario su Londra deve essere eseguito il comando seguente:

1
timedatectl set-timezone Europe/London

Verificare il fuso orario del server con la riga di comando seguente:

1
timedatectl

Inizializzazione del server Mediation Controller

Inizializzazione del server Mediation Controller

Il server Mediation Controller viene inizializzato mediante uno script di configurazione. Questo script riconfigura gli indirizzi IP del cluster nei diversi servizi del prodotto e preconfigura le impostazioni necessarie al funzionamento di un HTML5 Gateway.
Eseguirlo tramite la riga di comando seguente come root:

1
/opt/systancia/initializeCluster

Lo script chiederà di immettere le informazioni seguenti:

  • IP VIP HTTPS: indirizzo IP web virtuale del cluster, ossia VIP_MED_WEB.
  • IP VIP SSL: indirizzo IP SSL virtuale del cluster, ossia VIP_MED_SSL.
  • IP VIP ZIO: indirizzo IP virtuale per la connessione del server Mediation Controller SLAVE al database di configurazione interno del server MASTER, ossia VIP_MED_ZEO.
  • IP Master HTTPS: indirizzo IP web reale del server Mediation Controller MASTER, ossia RIP_MED_WEB_MASTER.
  • IP Master SSL: indirizzo IP reale dell'SSL Router del server Mediation Controller MASTER, ossia RIP_MED_SSL_MASTER.
  • IP Slave HTTPS: indirizzo IP web reale del server Mediation Controller SLAVE, ossia RIP_MED_WEB_SLAVE.
  • IP Slave SSL: indirizzo IP reale dell'SSL Router del server Mediation Controller SLAVE, ossia RIP_MED_SSL_SLAVE.
  • HTML5 port: porta di ascolto locale per il reindirizzamento dell'accesso al servizio HTML5 Gateway; si consiglia di indicare la porta 1234.
  • Gateway: nome dell'Edge Gateway; immettere il nome del primo Edge Gateway.
  • Organization: nome dell'organizzazione alla quale si connetteranno gli Edge Gateway e gli HTML5 Gateway.

Una volta completata l'inizializzazione, riavviare il server:

1
reboot

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.

Inizializzazione di CyberElements Bastion

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

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 di 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