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.

Impostazioni del sistema

Connezione alla macchina

Per impostazione predefinita, ci sono due account su apparecchi virtuali: un account utente e un account superutente.

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

Collegati alla macchina in modalità console.

Nota

Il layout di tastiera predefinito è QWERTY.

Cambiamento del layout della tastiera

Puoi modificare il layout della tastiera con la seguente riga di comando:

1
dpkg-reconfigure keyboard-configuration

Un menu appare per consentire di scegliere un altro layout della tastiera.

Quindi usa la seguente riga di comando per applicare e salvare le impostazioni:

1
setupcon -k --save

Le impostazioni entreranno in vigore immediatamente dopo l'esecuzione di questo comando.

Configurazione della rete

È 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

Tip

Ora che le impostazioni di rete sono state applicate, il server può essere accessibile tramite SSH.

Cambiamento delle password degli account locali

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

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

1
passwd systancia

Ripetere l'operazione per l'account root:

1
passwd root

--8<-- [fine:cambiamento di password]

Puoi modificare il layout della tastiera con la seguente riga di comando:

1
dpkg-reconfigure keyboard-configuration

Un menu appare per consentire di scegliere un altro layout della tastiera.

Quindi usa la seguente riga di comando per applicare e salvare le impostazioni:

1
setupcon -k --save

Le impostazioni entreranno in vigore immediatamente dopo l'esecuzione di questo comando.

--8<-- [start:cambiare fuso orario]

Per impostazione predefinita, l'apparecchio virtuale è impostato sul fuso orario Europe/Paris.

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

1
timedatectl list-timezones

Poi usa la seguente riga di comando:

1
timedatectl set-timezone your_time_zone
Esempio

Per impostare il fuso orario su Londra, è necessario eseguire il seguente comando:

1
timedatectl set-timezone Europe/London

Controllare il fuso orario del server utilizzando la seguente riga di comando:

1
timedatectl

--8<-- [fine:cambiamento di fuso orario]

Il wizard inizia chiedendo di selezionare una lingua:

Info

La lingua scelta influirà sia sulla lingua di visualizzazione del sistema che sul layout della tastiera.

Il wizard ti chiede quindi di aggiungere una nuova password per l'account di sistema root (assicurati che soddisfi la complessità richiesta):

Successivamente, è necessario modificare la password dell'account utente di sistema systancia (assicurarsi che soddisfi la complessità richiesta):

Infine, è necessario inserire il nome della macchina:

--8<-- [fine: sistema-inizializzazione-gw]

- 8 <-- [start:network-config-gw]

Una volta applicate le impostazioni di sistema, l'Assistente passa alle impostazioni di rete della macchina.

Il primo pannello chiede di scegliere tra una configurazione statica e una configurazione dinamica tramite DHCP:

Raccomandazione

Si raccomanda di utilizzare una configurazione statica per le impostazioni di rete della macchina, in particolare per la funzione di accesso diretto.
È possibile utilizzare DHCP anche se l'indirizzo IP è impostato a livello del server DHCP.

Se la configurazione statica è scelta, il wizard richiederà le seguenti impostazioni di rete:

Tip

È possibile inserire più server DNS (massimo 3) separandoli con spazi.

Configurazione del nome della macchina

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

Modificare il file /etc/hostname per specificare il nome della macchina.
Il prodotto ha bisogno del nuovo nome per un'altra posizione, quindi deve essere fatta una copia del file precedente utilizzando il seguente comando:

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

È necessario replicare la configurazione del file /etc/hosts in relazione all'indirizzo IP primario effettivo della macchina (RIP_MED_WEB_MASTER).
Per fare questo, modificare il file /etc/hosts e verificare che la seconda riga sia nel formato seguente:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

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

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Se la macchina appartiene al dominio DOMAIN.LOCAL, il file verrebbe 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 primario effettivo della macchina (RIP_MED_WEB_SLAVE).
Per fare questo, modificare il file /etc/hosts e verificare che la seconda riga sia nel formato seguente:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

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

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Se la macchina appartiene al dominio DOMAIN.LOCAL, il file verrebbe 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

Inizializzazione del Mediation Controller server

Inizializzazione del Mediation Controller server

Il server Mediation Controller viene inizializzato utilizzando uno script di configurazione. Questo script riconfigura gli indirizzi IP del cluster nei vari servizi del prodotto e preconfigura le impostazioni necessarie per il funzionamento di un gateway HTML5.
Eseguire il programma tramite la seguente riga di comando come root:

1
/opt/systancia/initializeCluster

Lo script ti chiederà di inserire le seguenti informazioni:

  • IP VIP HTTPS: indirizzo IP virtuale web del cluster, che è VIP_MED_WEB.
  • IP VIP SSL: indirizzo IP SSL virtuale del cluster, che è VIP_MED_SSL.
  • IP VIP ZIO: indirizzo IP virtuale per la connessione del server SLAVEMediation Controller al database di configurazione interno del server MASTER, che è VIP_MED_ZEO.
  • IP Master HTTPS: l'indirizzo IP web reale del server MASTER Mediation Controller, che è RIP_MED_WEB_MASTER.
  • IP Master SSL: l'indirizzo IP reale per il router SSL del server MASTER Mediation Controller, che è RIP_MED_SSL_MASTER.
  • IP Slave HTTPS: l'indirizzo IP web reale del server SLAVE Mediation Controller, che è RIP_MED_WEB_SLAVE.
  • IP Slave SSL: l'indirizzo IP reale per il router SSL del server SLAVE Mediation Controller, che è RIP_MED_SSL_SLAVE.
  • HTML5 port: porta di ascolto locale per il reindirizzamento dell'accesso al servizio HTML5 Gateway; si consiglia di inserire la porta 1234.
  • Gateway: nome del Edge Gateway; inserire il nome del primo Edge Gateway.
  • Organization: nome dell'organizzazione a cui si connetteranno i gateway Edge e i gateway HTML5.

Una volta completata l'inizializzazione, riavviare il server:

1
reboot

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:

Mediation Controller Accoppiamento del server

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.

Inizializzazione cyberelementi Cleanroom

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

Configurazione di un server NTP

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

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