Vai al contenuto

Installazione di server Mediation Controller

Nota

Come promemoria, il passaggio a root su macchine Debian deve essere fatto con il seguente comando:

1
su -

Le istruzioni fornite in questa pagina devono essere replicate su entrambi i server Mediation Controller, a partire dal server MASTER.
Quando si verificano differenze tra i server MASTER e SLAVE, esse vengono evidenziate. Se non vi è alcuna menzione di questo, allora le istruzioni si applicano sia ai server MASTER che ai server SLAVE.

Scaricare lo specchio e gli strumenti necessari

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

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

  • Un client SSH (su Windows, lo strumento PuTTY può essere utilizzato)
  • Un client SCP (su Windows, il WinSCP o FileZilla possono essere utilizzati degli strumenti)

Usa il client SSH per connetterti in remoto al tuo server.

Usa il client SCP per trasferire i file sulla tua macchina remota.

Preparazione per l'installazione

Configurazione della rete

Installare il pacchetto resolvconf in modo che la configurazione DNS specificata nel file di configurazione che verrà modificata a breve possa essere applicata:

1
apt install -y resolvconf

È indispensabile definire un indirizzo di rete statico per Mediation Controller. Per fare questo, è necessario prima recuperare il nome dell'interfaccia di rete della macchina. Eseguire il seguente comando come root:

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

Questo comando mostra 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 seguente output:

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 utilizzando il seguente modello:

 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

In caso di:

  • INTERFACE_NAME deve essere sostituito dal nome dell'interfaccia di rete precedentemente recuperata.
  • RIP_MED_WEB_MASTER deve essere sostituito dall'indirizzo IP reale principale del server, che sarà l'indirizzo IP attraverso il quale è possibile accedere alle console web.
  • NETMASK deve essere sostituito dalla maschera di rete associata all'indirizzo IP.
  • NETWORK_GATEWAY deve essere sostituito dal gateway di rete predefinito.
  • IP_DNS deve essere sostituito dall'indirizzo IP del server DNS. Se occorre configurare più server (massimo 3), separarli con uno spazio.
  • DNS_SUFFIX deve essere sostituito dal suffisso DNS da utilizzare. Se non è necessario inserire alcun suffisso, cancellare la riga.
  • RIP_MED_SSL_MASTER deve essere sostituito dall'indirizzo IP reale secondario del server. Questo sarà l'indirizzo IP attraverso il quale sarà accessibile il router SSL.
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 riavviare il servizio networking per caricare la nuova configurazione di rete:

1
systemctl restart networking

È indispensabile definire un indirizzo di rete statico per Mediation Controller. Per fare questo, è necessario prima recuperare il nome dell'interfaccia di rete della macchina. Eseguire il seguente comando come root:

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

Questo comando mostra 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 seguente output:

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 utilizzando il seguente modello:

 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

In caso di:

  • INTERFACE_NAME deve essere sostituito dal nome dell'interfaccia di rete precedentemente recuperata.
  • RIP_MED_WEB_SLAVE deve essere sostituito dall'indirizzo IP reale principale del server, che sarà l'indirizzo IP attraverso il quale è possibile accedere alle console web.
  • NETMASK deve essere sostituito dalla maschera di rete associata all'indirizzo IP.
  • NETWORK_GATEWAY deve essere sostituito dal gateway di rete predefinito.
  • IP_DNS deve essere sostituito dall'indirizzo IP del server DNS. Se occorre configurare più server (massimo 3), separarli con uno spazio.
  • DNS_SUFFIX deve essere sostituito dal suffisso DNS da utilizzare. Se non è necessario inserire alcun suffisso, cancellare la riga.
  • RIP_MED_SSL_SLAVE deve essere sostituito dall'indirizzo IP reale secondario del server. Questo sarà l'indirizzo IP attraverso il quale sarà accessibile il router SSL.
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 riavviare il servizio networking per caricare la nuova configurazione di rete:

1
systemctl restart networking

Resta un ultimo passo: modificare la risoluzione interna del nome della macchina in modo che risolva il suo indirizzo IP primario effettivo (corrispondente a RIP_MED_WEB_MASTER o RIP_MED_WEB_SLAVE).
Per fare questo, modificare il file /etc/hosts e sostituire 127.0.1.1 con RIP_MED_WEB_MASTER o RIP_MED_WEB_SLAVE a seconda del server Mediation Controller.

Example

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

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

Posizionare i file recuperati dal Systancia Marketplace sul server in /tmp/ utilizzando un client SCP:

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

Accedi al server come root, poi esegui i seguenti comandi per sbloccare il repository di Systancia, configurare il suo utilizzo 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 consiglia vivamente di disabilitare l'installazione di pacchetti non necessari quando si eseguono i comandi apt. Per farlo, eseguire il seguente comando:

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

Controllo della presenza del locale en_US.utf8

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

1
locale -a  | grep en_US.utf8

Se il ritorno di comando mostra en_US.utf8, allora procedere alla fase successiva della configurazione GRUB.
In caso contrario, eseguire i seguenti comandi 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, è necessario riavviare la macchina dopo aver applicato una 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 cyberelements Cleanroom Mediation Controller

Installazione di componenti di base

Iniziare l'installazione dei componenti utilizzando il seguente comando come root:

1
apt install -y ipdiva-base

Dopo aver scaricato tutte le dipendenze, si aprirà una finestra che vi chiederà di selezionare il tipo di server. mediation:

Quindi selezionare la modalità di installazione lbMaster:

Quindi selezionare la modalità di installazione lbSlave:

Questa porta di ascolto è solitamente impostata su 443, ma la porta 8443 può essere utilizzata anche se il server di mediazione utilizza un solo IP:

Quindi impostare la modalità Cluster su loadbalancing in modo che il carico utente sia distribuito tra i due server dei Controlli di mediazione:

Indicare l'indirizzo IP virtuale del cluster, VIP_MED_WEB:

Indicare l'indirizzo IP SSL virtuale del cluster, VIP_MED_SSL:

Indicare l'indirizzo IP virtuale del database di configurazione del cluster, VIP_MED_ZEO:

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

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

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

Infine, inserire l'indirizzo IP web reale del SLAVE Mediation Controller, RIP_MED_SSL_SLAVE:

Cosa fare in caso di errore?

Se vi è un errore nelle informazioni inserite, continuare con l'installazione del pacchetto ipdiva-base e quindi utilizzare il seguente comando per riconfigurare il server:

1
dpkg-reconfigure ipdiva-base

Installazione di componenti di cluster

Dopo l'installazione dei componenti di base, i componenti del cluster devono essere installati sui server dei controllori di mediazione:

1
apt install -y ipdiva-mediation-cluster

Dopo l'installazione dei componenti, è necessario un riavvio:

1
reboot

Configurazione del cluster

Cambiare la password della console cyberelements Gate /mediation/system

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

Applicazione di licenze e certificati

Sempre nella console /mediation/system, dovrai inserire i certificati e le licenze per il server Mediation Controller.

Attenzione!

La licenza e il certificato SSL Router sono specifici per il server MASTER o SLAVE Mediation Controller.
La configurazione della licenza o del certificato sbagliato causerà malfunzionamenti in seguito.

Applicare la licenza e il certificato per il componente del router SSL:

  1. Clicca sulla scheda Settings.
  2. Selezionare SSL Connections dal menu.
  3. Cerca il certificato per il router SSL.
  4. Inserisci la password per il certificato SSL Router.
  5. Clicca su Apply per applicare il certificato al router SSL.
  6. Selezionare il file di licenza del server.
  7. Clicca su Modify per applicare la licenza del server.

Inserire le informazioni relative al certificato per il client cyberelements Cleanroom:

  1. Selezionare la scheda Plugin.
  2. Cerca del certificato client cyberelements Cleanroom.
  3. Inserire la password del certificato.
  4. Clicca su Apply per applicare il certificato.

È comunque necessario inserire le informazioni per il certificato Watchdog:

  1. Selezionare la scheda Watchdog
  2. Cerca del certificato Watchdog.
  3. Inserire la password del certificato.
  4. Clicca su Apply per applicare il certificato.

Per far entrare in vigore queste modifiche, è necessario riavviare il router SSL e il Watchdog:

Server di controllo di mediazione di corrispondenza

Attenzione!

In questa fase, entrambi i Mediation Controller I server devono essere stati configurati fino al punto di che applica le licenze e i certificati.
Se il server SLAVE Mediation Controller non è ancora stato configurato, si prega di farlo tornando al inizio di questa documentazione .

Il passaggio di abbinamento del server Mediation Controller stabilisce un collegamento di fiducia tra i due server e inizializza l'operazione di cluster.

** Sul server SLAVE Mediation Controller **

Eseguire il seguente comando, come root, per stabilire una richiesta di accoppiamento al server MASTER Mediation Controller:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Sostituire RIP_MED_WEB_MASTER con l'indirizzo IP pertinente.

Esempio

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

1
hostManagerCtl bootstrap 10.0.10.10

** Sul server MASTER Mediation Controller **

Eseguire il seguente comando come root per verificare se ci sono richieste di accoppiamento in sospeso e recuperare l'ID di richiesta:

1
hostManagerCtl getPendingRequests

Quindi eseguire il seguente comando per accettare la richiesta di accoppiamento, sostituendo ID con l'ID recuperato con il comando precedente:

1
hostManagerCtl acceptRequest ID
Esempio

Se il comando hostManagerCtl getPendingRequests restituisce quanto segue:

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

Quindi il comando per accettare la richiesta di accoppiamento è il seguente:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

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

1
hostManagerCtl listPeers

Il risultato sarà diverso a seconda del server su cui viene eseguito il comando:

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

1
slave -> RIP_MED_WEB_SLAVE
Esempio

slave -> 10.0.10.12

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

1
master -> RIP_MED_WEB_MASTER
Esempio

master -> 10.0.10.10

** Sul server SLAVE Mediation Controller **

È possibile controllare lo stato di bootstrap dal server SLAVE utilizzando il seguente comando:

1
hostManagerCtl getBootstrapStatus

Un cluster che non sta riscontrando problemi di sincronizzazione restituirà il valore 0.

Una serie finale di comandi è necessaria, sempre sul server SLAVE, per sincronizzare un segreto condiviso tra entrambi i Controlli di mediazione:

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2
Qual è lo scopo della connessione inter-server?

Si tratta di una connessione speciale per il funzionamento del cluster che consente a un server Mediation Controller di instradare il traffico verso un altro server Mediation Controller nei casi in cui il server Edge Gateway di destinazione non è collegato al primo server ma solo al secondo.

Per esempio, se il server MASTER Mediation Controller non è più connesso al Edge Gateway, può utilizzare il collegamento interserver per raggiungere Edge Gateway tramite il server SLAVE Mediation Controller.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Connection lost| GW(Edge Gateway)
    MASTER --> |Interserver link| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

** Sul server MASTER Mediation Controller **

Modifica del file /etc/ipdiva/server/remoteServers.xml per indicare la NC 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 la NC del certificato destinato alla connessione interserver.
Se non si conosce la CN del certificato interserver, è possibile inserire il carattere * ( raccomandato 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

Considerando le seguenti informazioni:

  • Certificato interserver CN: my-interserver-cert

Il /etc/ipdiva/server/remoteServers.xml Il documento Mediation Controller MASTER server sarebbe compilato 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
62
<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 SLAVE Mediation Controller **

Inviare il certificato interserver alla SLAVE Mediation Controller nella directory /tmp/.
Quindi eseguire i seguenti comandi come root per spostarlo alla 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

Successivamente, modificare il file /etc/ipdiva/server/remoteServers.xml per aggiungere il seguente contenuto al tag <remoteConfig> (il vecchio tag <localCluster> può essere cancellato 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: specificare la CN del certificato SSL Router del MASTER Mediation Controller, che di solito è RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER: corrisponde all'indirizzo IP secondario del MASTER Mediation Controller.
  • PORT_RIP_MED_SSL_MASTER: corrisponde alla porta ascoltata dal router SSL del server MASTER Mediation Controller , che di solito è 443.
  • INTERSERVER.P12: nome del certificato destinato all'interserver.
  • PASSWORD: password del certificato interserver.
Esempio

Considerando le seguenti informazioni:

  • Nome del certificato Interserver: my-interserver-cert.p12
  • Certificato di interserver password: MySecurePassword
  • RIP SSL della Mediation Controller MASTER: 10.0.10.11
  • Porta sul RIP SSL del Mediation Controller MASTER: 443
  • CN del certificato Mediation Controller MASTER: 10.0.10.11

Il /etc/ipdiva/server/remoteServers.xml Il documento Mediation Controller SLAVE server sarebbe compilato 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
51
<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 il SLAVE Configurazione del router SSL eseguendo il seguente comando:

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

**Sul server MASTER e SLAVE Mediation Controller **

Riavviare il router SSL per applicare le impostazioni del collegamento interserver:

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

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

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

Il comando precedente dovrebbe restituire un log contenente questo TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers and 0 multicast group(s).
Se non viene visualizzato alcun registro di questo tipo, controllare la configurazione eseguita in questo capitolo.

Nel /mediation/system Consola Web del MASTER Mediation Controller

Abilitare la connessione inter-server tra entrambi i controller di mediazione modificando il default Host virtuale SSL:

Configurare i vari campi utilizzando le informazioni di seguito e abilitare la funzione di connessione inter-server controllando la cache Is interserver configured?:

  • Public address for plugin connections: corrisponde a VIP_MED_SSL seguita dalla sua porta di ascolto (di solito 443).
  • Real IP addresses for web connections: corrisponde alla coppia di indirizzi IP Web reali (RIP_MED_WEB_MASTER e RIP_MED_WEB_SLAVE) con la loro corrispondente porta, una riga per indirizzo IP e coppia di porte.
  • Real IP addresses for SSL connections: corrisponde alla coppia di indirizzi IP SSL reali (RIP_MED_SSL_MASTER e RIP_MED_SSL_SLAVE) con la loro corrispondente porta, una riga per indirizzo IP e coppia di porte.

Installazione di componenti cyberspecifici Cleanroom

Iniziare l'installazione di componenti cyberelements Cleanroom sui server dei Mediation Controllers utilizzando il seguente comando:

1
apt install -y ipdiva-safe-server

Per completare l'installazione, i server devono essere riavviati:

1
reboot

Connezione al database PostgreSQL

Per funzionare, cyberelements Cleanroom richiede l'uso di un database PostgreSQL esterno (DB) per memorizzare le sue impostazioni e vari log nella console /system.
Se la DB è direttamente accessibile dai server Mediation Controller, procedere direttamente alla fase di inizializzazione DB .

Connezione a una banca dati sulla LAN

Per consentire la connessione a un database situato sulla LAN senza aprire una DMZ al flusso LAN, il flusso del database sarà reindirizzato attraverso un tunnel TLS tra i gateway edge e i controllori di mediazione.
Per ottenere questo risultato, è necessario configurare un Edge Gateway (o due Edge Gateway) utilizzando la tecnologia di base cyberelements Gate.

Dichiarazione di elementi cyberGate Edge Gateways

Per fare questo, iniziare con l'accesso alla console /mediation/system di cyberelements Gate.

Poi vai al menu Organizzazioni e fai clic su Aggiungi:

Inserire il nome dell'organizzazione, che deve essere diverso da quello assegnato a ** cyber** elementi Cleanroom (ad esempio tunnel), definire almeno una licenza di sessione utente e la password dell'account admin:

Accedere all'interfaccia di amministrazione dell'organizzazione creata in precedenza con l'account admin e andare a /gate/admin:

Quindi dichiari entrambi gli Edge Gateway che verranno usati per creare il tunnel.
Sulla sinistra, passare il mouse su Infrastructure e fare clic su Gateways, quindi fare clic sul pulsante Add:

Indicare il nome del primo Edge Gateway e confermare la sua dichiarazione:

Info

Come promemoria, il nome di un Edge Gateway è collegato al certificato che userà per autenticarsi con il router SSL del Mediation Controller.
Questo nome assume la forma seguente <GW_NAME>@<ORGANIZATION_NAME>, dove <GW_NAME> corrisponde al nome del Edge Gateway e dove <ORGANIZATION_NAME> corrisponde al nome dell'organizzazione creato nella console di sistema cyberelements Gate.

Ripetere la fase di dichiarazione Edge Gateway per la seconda Edge Gateway.

Connessioni e impostazioni di tunnel su gateway di bordo

Info

I seguenti passaggi possono essere replicati su entrambi i gateway edge utilizzati per il tunnel per accedere al database.

Prerequisiti

Per completare questa parte, è necessario utilizzare:

In primo luogo, utilizzare uno strumento come WinSCP o FileZilla per inviare il certificato che consente la connessione alla directory Edge Gateway/tmp/ tramite SCP.

Quindi connettersi tramite SSH e passare a root.

Per collegare il Edge Gateway a entrambi i Controller di mediazione, è necessario creare due nuove istanze Edge Gateway in modo che una si connetta al MASTER Mediation Controller mentre la seconda si connette al SLAVE Mediation Controller.
Per crearli, eseguire i seguenti comandi:

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

Copia 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 il Edge Gateway deve utilizzare per connettersi al Mediation Controller.

Configurare le istanze Edge Gateway in modo da consentire loro di connettersi ai controllori di mediazione.
Le configurazioni variano a seconda del Mediation Controller da contattare.

Modificare il file /etc/ipdiva/gateway-tunnel-master/gateway.xml e completarlo utilizzando le seguenti informazioni (sono state omesse diverse sezioni contrassegnate 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 i seguenti elementi:

  • @SERVER@: deve essere sostituito dall'indirizzo RIP_MED_SSL_MASTER
  • @SERVERPORT@: deve essere sostituita dalla porta di ascolto del router SSL, normalmente impostata su 443
  • keyfile.pem: deve essere sostituito dal nome del file del certificato
  • PASSWORD: deve essere sostituito dalla password del certificato
  • @RPC_PORT@: deve essere sostituita da una porta che non ascolta la macchina; può essere utilizzata la porta 9082
Esempio

Considerando le seguenti informazioni:

  • RIP_MED_SSL_MASTER è uguale a: 10.0.10.11
  • SSL Porta di ascolto del router: 443
  • Nome del file del certificato: gate-tunnel.p12
  • Certificato password: Str0ngP@ssw0rd

Il /etc/ipdiva/gateway-tunnel-master/gateway.xml file sarebbe 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 utilizzando le seguenti informazioni (sono state omesse diverse sezioni contrassegnate 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 i seguenti elementi:

  • @SERVER@: deve essere sostituito dall'indirizzo RIP_MED_SSL_SLAVE
  • @SERVERPORT@: deve essere sostituita dalla porta di ascolto del router SSL, normalmente impostata su 443
  • keyfile.pem: deve essere sostituito dal nome del file del certificato
  • PASSWORD: deve essere sostituito dalla password del certificato
  • @RPC_PORT@: deve essere sostituita da una porta che non ascolta la macchina; può essere utilizzata la porta 9083
Esempio

Considerando le seguenti informazioni:

  • RIP_MED_SSL_SLAVE è uguale a: 10.0.10.13
  • SSL Porta di ascolto del router: 443
  • Nome del file del certificato: gate-tunnel.p12
  • Certificato password: Str0ngP@ssw0rd

Il /etc/ipdiva/gateway-tunnel-slave/gateway.xml file sarebbe 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 Controlli di mediazione, devono ancora essere configurate per reindirizzare la connessione Mediation Controller al database.
Per fare questo, 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 per la connessione al database e DB_PORT con la porta di ascolto dell'istanza del database.
Replicare le impostazioni per l'istanza che si connette al server SLAVE Mediation Controller copiando il file:

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

Infine, avviare le istanze Edge Gateway in modo che stabiliscano una connessione con i Controlli di mediazione:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Configurazione del tunnel dei controllori di mediazione

Per far sì che il tunnel possa essere utilizzato dai Controllatori di Mediazione, dovete ancora dichiarare la loro esistenza.
Per fare ciò, accedi come root ai Controlli di mediazione e modifica il file /etc/ipdiva/server/services.xml per aggiungere la sezione seguente (sono state omesse diverse sezioni contrassegnate con […]):

 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 i seguenti elementi:

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

Considerando le seguenti informazioni:

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

Il /etc/ipdiva/server/services.xml Il fascicolo sarebbe compilato 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 il router SSL con il seguente comando:

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

Inizializzazione del database

Per inizializzare il database PostgreSQL per la configurazione del sistema, è necessario prima dichiarare come connettersi ad esso sui Controlli di mediazione.
Per fare questo, modificare il file /etc/ipdiva/care/databasesettings.ini su entrambi i server per inserire i seguenti elementi:

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 i seguenti elementi:

  • DB_USERNAME con il nome utente utilizzato per connettersi al database.
  • DB_PWD con la password dell'utente che si accede.
  • DB_HOST per l'indirizzo IP o il nome DNS utilizzato per connettersi al database; se si utilizza una connessione tramite Edge Gateways, è necessario inserire 127.0.0.1.
  • DB_PORT per la porta utilizzata per connettersi all'istanza del database; se viene utilizzata una connessione tramite Edge Gateways, è necessario inserire 1432.

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

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

Dopo di che, tutto ciò che resta è di riavviare il servizio apache2 ** su entrambi i Controlli di mediazione ** per applicare l'inizializzazione del database di sistema:

1
systemctl restart apache2

Installazione di driver per la connessione a database Microsoft SQL

Se si desidera connettersi a un database esterno ed è un Microsoft SQL Server, devono essere installati driver ODBC aggiuntivi.

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

connessione TLS richiesta con i driver della versione 18

L'uso dei driver ODBC 18 richiede che la connessione sia crittografata utilizzando TLS. Per fare questo, MS SQL Server deve essere configurato per la crittografia della connessione.

Prima di iniziare l'installazione dei driver ODBC, è necessario installare i pacchetti necessari per la preparazione, quindi preparare il repository Microsoft per l'installazione del pacchetto:

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

Successivamente, installare i driver in base alla versione selezionata e configurare le impostazioni di sistema per l'utilizzo del 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 seguente comando dovrebbe consentire la connessione al server remoto:

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

In caso di:

  • 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 a cui connettersi; se non necessario, rimuovere anche il carattere di barra inversa.
  • PORT deve essere sostituito con la porta di connessione all'istanza di database MS SQL.
  • USER deve essere sostituito con il nome utente per stabilire la connessione.
Esempio

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

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

Se si dovesse specificare l'istanza di connessione denominata MSSQLINSTANCE, il comando verrebbe modificato come segue:

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

Configurazione di un server NTP

Si raccomanda di impostare un server orario per mantenere aggiornato l'orologio del sistema. nella pagina di configurazione NTP.

Configurazioni iniziali su elementi cyber Cleanroom

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

Per impostazione predefinita, non è consentito collegarsi alle interfacce web elementi cyber Cleanroom del prodotto con l'IP virtuale VIP_MED_WEB.
Per aggiungere l'autorizzazione, eseguire come root i seguenti comandi sui Controlli di mediazione:

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 dei controllori di mediazione sono installati, ma devono ancora essere eseguite diverse azioni:

  • Modificare le password predefinite

    Modificare le password predefinite per le console di sistema.

    Cambiamento

  • Installare certificati e licenze

    Il Mediation Controller richiede diversi certificati e una licenza per essere operativo.
    Solo il certificato per il client cyberelements Cleanroom deve essere nuovamente dichiarato su entrambi i controller di mediazione (utilizzare il RIP RIP_MED_WEB_MASTER e RIP_MED_WEB_SLAVE).

    Installare certificati e licenza

  • Configurare il certificato web

    Configurare il certificato web utilizzato per connettersi alle interfacce web

    Configurare

  • Dichiarazione di un nome DNS

    Aggiungere un nome DNS autorizzato per connettersi alle interfacce web.

    Aggiungere

  • Configurare l'organizzazione

    Configurare l'organizzazione elementi cyber Cleanroom.

    Configurazione con accesso diretto alla base di dati

    Configurare con l'accesso al database tramite il tunnel di Edge Gateways

  • Dichiarazione dei gateway di bordo

    Declare che il Edge Gateway (s) o il devono essere installati.

    Creare gateway di bordo

  • Creare un sito logico

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

    Creazione di un sito

  • Installare un Edge Gateway

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

    Installare