Sari la conținut

Instalarea serverelor Mediation Controller

Notă

Ca reamintire, trecerea la root pe mașinile Debian trebuie făcută cu următoarea comandă:

1
su -

Instrucțiunile de pe această pagină trebuie aplicate pe ambele servere Mediation Controller, începând cu serverul MASTER.
Atunci când există diferențe între serverele MASTER și SLAVE, acestea vor fi semnalate. Dacă nu se indică nimic, instrucțiunile se aplică atât serverului MASTER, cât și serverului SLAVE.

Configurarea sistemului

Conectarea la mașină

În mod implicit, pe appliance-urile virtuale există două conturi: un cont de utilizator și un cont de superutilizator.

  • Cont de utilizator
    • Login: systancia
    • Parolă: systnci
  • Cont de superutilizator
    • Login: root
    • Parolă: systnci

Conectați-vă la mașină în mod consolă.

Notă

Aranjamentul implicit al tastaturii este QWERTY.

Schimbarea aranjamentului tastaturii

Puteți schimba aranjamentul tastaturii cu următoarea linie de comandă:

1
dpkg-reconfigure keyboard-configuration

Apare un meniu care vă permite să alegeți un alt aranjament de tastatură.

Apoi utilizați următoarea linie de comandă pentru a aplica și a salva setările:

1
setupcon -k --save

Setările intră în vigoare imediat după executarea acestei comenzi.

Configurarea rețelei

Este indispensabil să configurați o adresă de rețea statică pentru Mediation Controller. Pentru aceasta, trebuie mai întâi să obțineți numele interfeței de rețea a mașinii dumneavoastră. Executați următoarea comandă ca root:

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

Această comandă afișează numele interfeței de rețea, starea acesteia și adresele IP atribuite interfeței.

Exemplu

După executarea comenzii, se afișează următorul rezultat:

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

Numele interfeței de rețea este ens192.

Odată obținut numele interfeței de rețea, este acum posibil să editați configurarea de rețea a mașinii.
Editați fișierul /etc/network/interfaces pentru a-l modifica după modelul următor:

 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

Unde:

  • INTERFACE_NAME trebuie înlocuit cu numele interfeței de rețea obținut anterior.
  • RIP_MED_WEB_MASTER trebuie înlocuit cu adresa IP reală principală a serverului, care va fi adresa IP prin care vor fi accesibile consolele web.
  • NETMASK trebuie înlocuit cu masca de rețea asociată adresei IP.
  • NETWORK_GATEWAY trebuie înlocuit cu gateway-ul de rețea implicit.
  • IP_DNS trebuie înlocuit cu adresa IP a serverului DNS. Dacă trebuie configurate mai multe servere (3 maximum), separați-le cu un spațiu.
  • DNS_SUFFIX trebuie înlocuit cu sufixul DNS care urmează să fie utilizat. Dacă nu trebuie indicat niciun sufix, ștergeți linia.
  • RIP_MED_SSL_MASTER trebuie înlocuit cu adresa IP reală secundară a serverului. Aceasta va fi adresa IP prin care va fi accesibil SSL Router.
Exemplu 
 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

În final, mai rămâne doar să reporniți serviciul networking pentru a încărca noua configurare de rețea: 

1
systemctl restart networking

Este indispensabil să configurați o adresă de rețea statică pentru Mediation Controller. Pentru aceasta, trebuie mai întâi să obțineți numele interfeței de rețea a mașinii dumneavoastră. Executați următoarea comandă ca root:

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

Această comandă afișează numele interfeței de rețea, starea acesteia și adresele IP atribuite interfeței.

Exemplu

După executarea comenzii, se afișează următorul rezultat:

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

Numele interfeței de rețea este ens192.

Odată obținut numele interfeței de rețea, este acum posibil să editați configurarea de rețea a mașinii.
Editați fișierul /etc/network/interfaces pentru a-l modifica după modelul următor:

 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

Unde:

  • INTERFACE_NAME trebuie înlocuit cu numele interfeței de rețea obținut anterior.
  • RIP_MED_WEB_SLAVE trebuie înlocuit cu adresa IP reală principală a serverului, care va fi adresa IP prin care vor fi accesibile consolele web.
  • NETMASK trebuie înlocuit cu masca de rețea asociată adresei IP.
  • NETWORK_GATEWAY trebuie înlocuit cu gateway-ul de rețea implicit.
  • IP_DNS trebuie înlocuit cu adresa IP a serverului DNS. Dacă trebuie configurate mai multe servere (3 maximum), separați-le cu un spațiu.
  • DNS_SUFFIX trebuie înlocuit cu sufixul DNS care urmează să fie utilizat. Dacă nu trebuie indicat niciun sufix, ștergeți linia.
  • RIP_MED_SSL_SLAVE trebuie înlocuit cu adresa IP reală secundară a serverului. Aceasta va fi adresa IP prin care va fi accesibil SSL Router.
Exemplu 
 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

În final, mai rămâne doar să reporniți serviciul networking pentru a încărca noua configurare de rețea: 

1
systemctl restart networking

Sfat

Acum că a fost aplicată configurarea de rețea, serverul poate fi accesat prin SSH.

Schimbarea parolelor conturilor locale

Systancia recomandă insistent schimbarea parolei acestor conturi după implementarea appliance-ului virtual.

Utilizați următoarea comandă și introduceți noua parolă pentru contul standard systancia:

1
passwd systancia

Apoi repetați operațiunea pentru contul de superutilizator root:

1
passwd root

Configurarea numelui mașinii

Numele serverului poate fi schimbat prin configurarea fișierelor hostname și hosts ale serverului.

Editați fișierul /etc/hostname pentru a indica numele mașinii.
Produsul are nevoie de noul nume în alt loc, prin urmare trebuie făcută o copie a fișierului anterior cu următoarea comandă:

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

Trebuie să replicați configurarea fișierului /etc/hosts în ceea ce privește adresa IP reală principală a mașinii (RIP_MED_WEB_MASTER).
Pentru aceasta, editați fișierul /etc/hosts și verificați dacă a doua linie are formatul următor:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

Dacă mașina se numește MEDIATION-CONTROLLER-MASTER fără să aparțină unui domeniu și adresa sa IP reală RIP_MED_WEB_MASTER este 10.0.10.10, atunci fișierul s-ar completa astfel:

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Dacă mașina aparține domeniului DOMAIN.LOCAL, atunci fișierul s-ar completa astfel:

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

Trebuie să replicați configurarea fișierului /etc/hosts în ceea ce privește adresa IP reală principală a mașinii (RIP_MED_WEB_SLAVE).
Pentru aceasta, editați fișierul /etc/hosts și verificați dacă a doua linie are formatul următor:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

Dacă mașina se numește MEDIATION-CONTROLLER-SLAVE fără să aparțină unui domeniu și adresa sa IP reală RIP_MED_WEB_SLAVE este 10.0.10.12, atunci fișierul s-ar completa astfel:

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Dacă mașina aparține domeniului DOMAIN.LOCAL, atunci fișierul s-ar completa astfel:

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

Pentru a aplica noua configurare, reporniți serverul:

1
reboot

Modificarea fusului orar

În mod implicit, appliance-ul virtual este configurat pe fusul orar Europe/Paris.

Pentru a schimba acest fus orar, utilizați mai întâi următoarea comandă pentru a obține sintaxa fusurilor orare disponibile:

1
timedatectl list-timezones

Utilizați apoi următoarea linie de comandă:

1
timedatectl set-timezone your_time_zone
Exemplu

Pentru a seta fusul orar la Londra, trebuie executată următoarea comandă:

1
timedatectl set-timezone Europe/London

Verificați fusul orar al serverului cu următoarea linie de comandă:

1
timedatectl

Inițializarea serverului Mediation Controller

Inițializarea serverului Mediation Controller

Serverul Mediation Controller se inițializează prin intermediul unui script de configurare. Acest script reconfigurează adresele IP ale Clusterului în diferitele servicii ale produsului și preconfigurează parametrii necesari funcționării unei instanțe HTML5 Gateway.
Executați-l cu următoarea linie de comandă, ca root:

1
/opt/systancia/initializeCluster

Scriptul vă va cere să introduceți informațiile următoare:

  • IP VIP HTTPS: adresa IP web virtuală a Clusterului, adică VIP_MED_WEB.
  • IP VIP SSL: adresa IP SSL virtuală a Clusterului, adică VIP_MED_SSL.
  • IP VIP ZIO: adresa IP virtuală pentru conectarea serverului Mediation Controller SLAVE la baza de date internă de configurare a serverului MASTER, adică VIP_MED_ZEO.
  • IP Master HTTPS: adresa IP web reală a serverului Mediation Controller MASTER, adică RIP_MED_WEB_MASTER.
  • IP Master SSL: adresa IP reală a SSL Router al serverului Mediation Controller MASTER, adică RIP_MED_SSL_MASTER.
  • IP Slave HTTPS: adresa IP web reală a serverului Mediation Controller SLAVE, adică RIP_MED_WEB_SLAVE.
  • IP Slave SSL: adresa IP reală a SSL Router al serverului Mediation Controller SLAVE, adică RIP_MED_SSL_SLAVE.
  • HTML5 port: portul de ascultare local pentru redirecționarea accesului la serviciul HTML5 Gateway; recomandăm să indicați portul 1234.
  • Gateway: numele serverului Edge Gateway; indicați numele primului server Edge Gateway.
  • Organization: numele organizației la care se vor conecta serverele Edge Gateway și instanțele HTML5 Gateway.

Odată finalizată inițializarea, reporniți serverul:

1
reboot

Schimbarea parolei consolei /mediation/system din CyberElements Gate

În această etapă a instalării este disponibilă o nouă interfață de administrare: Schimbarea parolei

Aplicarea licențelor și a certificatelor

Tot în consola /mediation/system, va trebui să introduceți certificatele și licențele serverului Mediation Controller.

Atenție!

Licența și certificatul SSL Router sunt specifice serverului Mediation Controller MASTER sau SLAVE.
Configurarea unei licențe sau a unui certificat greșit va provoca disfuncționalități ulterior.

Aplicați licența și certificatul componentei SSL Router:

  1. Faceți clic pe tabul Settings.
  2. Selectați SSL Connections din meniu.
  3. Căutați certificatul pentru SSL Router.
  4. Introduceți parola certificatului SSL Router.
  5. Faceți clic pe Apply pentru a aplica certificatul la SSL Router.
  6. Selectați fișierul de licență al serverului.
  7. Faceți clic pe Modify pentru a aplica licența serverului.

În continuare, introduceți informațiile certificatului clientului CyberElements Bastion:

  1. Selectați tabul Plugin.
  2. Căutați certificatul clientului CyberElements Bastion.
  3. Introduceți parola certificatului.
  4. Faceți clic pe Apply pentru a aplica certificatul.

Mai rămâne să introduceți informațiile certificatului Watchdog:

  1. Selectați tabul Watchdog
  2. Căutați certificatul Watchdog.
  3. Introduceți parola certificatului.
  4. Faceți clic pe Apply pentru a aplica certificatul.

Pentru ca aceste modificări să fie luate în calcul, trebuie să reporniți SSL Router și Watchdog:

Pairingul serverelor Mediation Controller

Atenție!

În acest punct, ambele servere Mediation Controller trebuie să fi fost configurate până la aplicarea licențelor și a certificatelor.
Dacă serverul Mediation Controller SLAVE nu a fost încă configurat, faceți-o începând de la începutul acestei documentații.

Etapa de pairing a serverelor Mediation Controller va stabili o legătură de încredere între cele două servere și va inițializa funcționarea în Cluster.

Pe serverul Mediation Controller SLAVE

Executați următoarea comandă ca root pentru a iniția o cerere de pairing cu serverul Mediation Controller MASTER:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Înlocuiți RIP_MED_WEB_MASTER cu adresa IP corespunzătoare.

Exemplu

Dacă RIP_MED_WEB_MASTER este egal cu 10.0.10.10, atunci comanda care trebuie introdusă este următoarea:

1
hostManagerCtl bootstrap 10.0.10.10

Pe serverul Mediation Controller MASTER

Executați următoarea comandă ca root pentru a consulta cererile de pairing în așteptare și a obține identificatorul cererii: 

1
hostManagerCtl getPendingRequests

În continuare, executați următoarea comandă pentru a accepta cererea de pairing, înlocuind ID cu identificatorul obținut cu comanda anterioară:

1
hostManagerCtl acceptRequest ID
Exemplu

Dacă rezultatul comenzii hostManagerCtl getPendingRequests este următorul:

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

Atunci comanda pentru acceptarea cererii de pairing este următoarea:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

Pentru a verifica asocierea, utilizați următoarea comandă pe serverul Mediation Controller (fie MASTER, fie SLAVE):

1
hostManagerCtl listPeers

Rezultatul va diferi în funcție de serverul pe care se execută comanda:

Rezultatul așteptat pe serverul Mediation Controller MASTER este următorul:

1
slave -> RIP_MED_WEB_SLAVE
Exemplu 
1
slave -> 10.0.10.12

Rezultatul așteptat pe serverul Mediation Controller SLAVE este următorul:

1
master -> RIP_MED_WEB_MASTER
Exemplu 
1
master -> 10.0.10.10

Pe serverul Mediation Controller SLAVE

Puteți verifica starea bootstrapului de pe serverul SLAVE cu următoarea comandă:

1
hostManagerCtl getBootstrapStatus

Un Cluster care nu prezintă nicio problemă de sincronizare va returna valoarea 0.

Este necesară o ultimă serie de comenzi, din nou pe serverul SLAVE, pentru a sincroniza un secret partajat între cele două Mediation Controller:

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2
La ce servește conexiunea între servere?

Este vorba despre o conexiune specifică funcționării în Cluster, care permite unui server Mediation Controller să direcționeze traficul către un alt server Mediation Controller atunci când serverul Edge Gateway de destinație nu este conectat la primul server, ci numai la al doilea.

De exemplu, dacă serverul Mediation Controller MASTER nu mai este conectat la Edge Gateway, poate utiliza legătura între servere pentru a ajunge la Edge Gateway prin serverul Mediation Controller SLAVE.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Conexiune pierdută| GW(Edge Gateway)
    MASTER --> |Legătură între servere| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

Pe serverul Mediation Controller MASTER

Editați fișierul /etc/ipdiva/server/remoteServers.xml pentru a indica CN-ul certificatului între servere:

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"/>
                -->

Înlocuiți SLAVECN cu CN-ul certificatului destinat conexiunii între servere.
Dacă nu cunoașteți CN-ul certificatului între servere, atunci poate fi introdus caracterul * (recomandat în caz de dubiu):

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"/>
                -->
Exemplu

Ținând cont de informațiile următoare:

  • CN-ul certificatului între servere: my-interserver-cert

Fișierul /etc/ipdiva/server/remoteServers.xml al serverului Mediation Controller MASTER s-ar completa astfel:

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

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

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

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

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


</remoteConfig>

Pe serverul Mediation Controller SLAVE

Trimiteți certificatul între servere către Mediation Controller SLAVE, în directorul /tmp/.
În continuare, executați următoarele comenzi ca root pentru a-l muta în directorul de destinație cu permisiunile adecvate:

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

În continuare, editați fișierul /etc/ipdiva/server/remoteServers.xml pentru a adăuga conținutul următor în eticheta <remoteConfig> (vechea etichetă <localCluster> poate fi ștearsă în întregime):

 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>

Înlocuiți:

  • MASTERCN: indicați CN-ul certificatului SSL Router al Mediation Controller MASTER, care este de obicei RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER: corespunde adresei IP secundare a Mediation Controller MASTER.
  • PORT_RIP_MED_SSL_MASTER: este portul pe care ascultă SSL Router al Mediation Controller MASTER; de obicei este 443.
  • INTERSERVER.P12: numele certificatului destinat conexiunii între servere.
  • PASSWORD: parola certificatului între servere.
Exemplu

Ținând cont de informațiile următoare:

  • Numele certificatului între servere: my-interserver-cert.p12
  • Parola certificatului între servere: MySecurePassword
  • RIP SSL al Mediation Controller MASTER: 10.0.10.11
  • Portul pe RIP-ul SSL al Mediation Controller MASTER: 443
  • CN-ul certificatului Mediation Controller MASTER: 10.0.10.11

Fișierul /etc/ipdiva/server/remoteServers.xml al serverului Mediation Controller SLAVE s-ar completa astfel:

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

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

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

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


</remoteConfig>

Modificați configurarea SSL Router SLAVE executând următoarea comandă:

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

Pe serverele Mediation Controller MASTER și SLAVE

Reporniți SSL Router pentru a aplica configurarea legăturii între servere:

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

Pentru a confirma că legătura între servere funcționează corect, următoarea comandă trebuie să returneze un rezultat:

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

Comanda anterioară trebuie să producă un log care conține următorul text: TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers, and 0 multicast group(s).
Dacă nu se afișează niciun log de acest tip, verificați configurarea realizată în acest capitol.

În consola web /mediation/system a Mediation Controller MASTER

Activați conexiunea între servere între cele două Mediation Controller editând hostul virtual SSL default:

Completați diferitele câmpuri urmând indicațiile de mai jos și activați funcția de legătură între servere bifând caseta Is cross-server linking configured?:

  • Public address for plugin connections: corespunde VIP_MED_SSL urmat de portul său de ascultare (de obicei 443).
  • Actual public IP addresses for web connections: corespunde perechii de adrese IP web reale (RIP_MED_WEB_MASTER și RIP_MED_WEB_SLAVE) cu porturile lor corespunzătoare, o linie pentru fiecare pereche de adresă IP și port.
  • Actual public IP addresses for SSL connections: corespunde perechii de adrese IP SSL reale (RIP_MED_SSL_MASTER și RIP_MED_SSL_SLAVE) cu porturile lor corespunzătoare, o linie pentru fiecare pereche de adresă IP și port.

Inițializarea CyberElements Bastion

Conectarea la baza de date PostgreSQL

Pentru a funcționa, CyberElements Bastion are nevoie să utilizeze o bază de date (BD) PostgreSQL externă pentru a stoca setările sale și diferitele loguri din consola /system.
Dacă BD este direct accesibilă de pe serverele Mediation Controller, treceți direct la etapa de inițializare a BD.

Conectarea la o bază de date situată în LAN

Pentru a permite conectarea la o bază de date situată în LAN fără a deschide un flux dinspre DMZ către LAN, fluxul bazei de date va fi redirecționat printr-un tunel TLS între serverele Edge Gateway și Mediation Controller.
Pentru a reuși acest lucru, trebuie să configurați un server Edge Gateway (sau două servere Edge Gateway) utilizând tehnologia CyberElements Gate subiacentă.

Declararea serverelor Edge Gateway CyberElements Gate

Pentru aceasta, începeți prin a vă conecta la consola /mediation/system din CyberElements Gate.

Mergeți apoi la meniul „Organizations” și faceți clic pe „Add”:

Introduceți numele organizației, care trebuie să fie diferit de cel atribuit CyberElements Bastion (de exemplu, tunnel), și indicați cel puțin o licență de sesiune de utilizator, împreună cu parola contului admin:

Conectați-vă la interfața de administrare a organizației create anterior cu contul admin, accesând /gate/admin:

Declarați în continuare cele două servere Edge Gateway care vor fi utilizate pentru stabilirea tunelului.
În stânga, plasați cursorul pe Infrastructure, faceți clic pe Gateways, apoi pe butonul Add:

Introduceți numele primului server Edge Gateway și confirmați introducerea:

Informație

Ca reamintire, numele unui server Edge Gateway este legat de certificatul pe care îl va utiliza pentru a se autentifica la SSL Router al Mediation Controller.
Acest nume are forma următoare <GW_NAME>@<ORGANIZATION_NAME>, unde <GW_NAME> corespunde numelui serverului Edge Gateway, iar <ORGANIZATION_NAME> corespunde numelui organizației create în consola de sistem a CyberElements Gate.

Repetați etapa de declarare pentru al doilea server Edge Gateway.

Conexiunile și configurarea tunelului pe serverele Edge Gateway

Informație

Etapele următoare pot fi replicate pe cele două servere Edge Gateway utilizate pentru tunelul de acces la baza de date.

Cerințe preliminare

Pentru a finaliza această parte, va trebui să utilizați una dintre următoarele două opțiuni:

În primul rând, utilizați un instrument precum WinSCP sau FileZilla pentru a transfera prin SCP, în directorul /tmp/ al serverului Edge Gateway, certificatul necesar conexiunii.

Conectați-vă apoi prin SSH și treceți la root.

Pentru a conecta serverul Edge Gateway la cele două Mediation Controller, trebuie să creați două instanțe noi de Edge Gateway: una se va conecta la Mediation Controller MASTER, iar cealaltă la Mediation Controller SLAVE.
Pentru a le crea, executați următoarele comenzi:

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

Copiați fișierul certificatului în directoarele /etc/ipdiva/gateway-tunnel-master/ssl/ și /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/

Înlocuiți <CERT_NAME> cu numele certificatului pe care serverul Edge Gateway trebuie să îl utilizeze pentru a se conecta la Mediation Controller.

Configurați instanțele Edge Gateway pentru a le permite să se conecteze la Mediation Controller.
Configurările diferă în funcție de Mediation Controller care trebuie contactat. Realizați ambele configurări:

Editați fișierul /etc/ipdiva/gateway-tunnel-master/gateway.xml și completați-l cu informațiile următoare (mai multe secțiuni au fost omise și sunt indicate prin […]):

 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>

Înlocuiți elementele următoare:

  • @SERVER@: trebuie înlocuit cu adresa RIP_MED_SSL_MASTER
  • @SERVERPORT@: trebuie înlocuit cu portul de ascultare al SSL Router, în mod normal 443
  • keyfile.pem: trebuie înlocuit cu numele fișierului certificatului
  • PASSWORD: trebuie înlocuit cu parola certificatului
  • @RPC_PORT@: trebuie înlocuit cu un port care nu este în ascultare pe mașină; poate fi utilizat portul 9082
Exemplu

Ținând cont de informațiile următoare:

  • RIP_MED_SSL_MASTER este egal cu: 10.0.10.11
  • Portul de ascultare al SSL Router: 443
  • Numele fișierului certificatului: gate-tunnel.p12
  • Parola certificatului: Str0ngP@ssw0rd

Fișierul /etc/ipdiva/gateway-tunnel-master/gateway.xml ar fi configurat astfel:

 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>
Fișier complet 
 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>

Editați fișierul /etc/ipdiva/gateway-tunnel-slave/gateway.xml și completați-l cu informațiile următoare (mai multe secțiuni au fost omise și sunt indicate prin […]):

 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>

Înlocuiți elementele următoare:

  • @SERVER@: trebuie înlocuit cu adresa RIP_MED_SSL_SLAVE
  • @SERVERPORT@: trebuie înlocuit cu portul de ascultare al SSL Router, în mod normal 443
  • keyfile.pem: trebuie înlocuit cu numele fișierului certificatului
  • PASSWORD: trebuie înlocuit cu parola certificatului
  • @RPC_PORT@: trebuie înlocuit cu un port care nu este utilizat pe mașină; poate fi utilizat portul 9083
Exemplu

Ținând cont de informațiile următoare:

  • RIP_MED_SSL_SLAVE este egal cu: 10.0.10.13
  • Portul de ascultare al SSL Router: 443
  • Numele fișierului certificatului: gate-tunnel.p12
  • Parola certificatului: Str0ngP@ssw0rd

Fișierul /etc/ipdiva/gateway-tunnel-slave/gateway.xml ar fi configurat astfel:

 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>
Fișier complet 
 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>

Acum că instanțele sunt configurate pentru a se conecta la Mediation Controller, mai rămâne să fie configurate pentru a redirecționa conexiunea Mediation Controller către baza de date.
Pentru aceasta, editați fișierul /etc/ipdiva/gateway-tunnel-master/services.xml și modificați-l astfel: 

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>

Înlocuiți DB_SERVER cu numele DNS sau adresa IP utilizată pentru a vă conecta la baza de date, iar DB_PORT cu portul de ascultare al instanței de bază de date.
Replicați această configurare pe instanța care se conectează la serverul Mediation Controller SLAVE, copiind fișierul:

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

În final, porniți instanțele Edge Gateway pentru ca acestea să stabilească conexiunea cu Mediation Controller:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Configurarea tunelului pe serverele Mediation Controller

Pentru ca tunelul să poată fi utilizat de Mediation Controller, mai rămâne să declarați existența lor.
Pentru aceasta, conectați-vă ca root la Mediation Controller și editați fișierul /etc/ipdiva/server/services.xml pentru a adăuga secțiunea următoare (mai multe secțiuni au fost omise și sunt indicate prin […]):

 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>

Înlocuiți elementele următoare:

  • GW1_NAME cu numele primului server Edge Gateway
  • GW2_NAME cu numele celui de-al doilea server Edge Gateway
  • ORGANIZATION_NAME cu numele organizației CyberElements Gate creată anterior
Exemplu

Ținând cont de informațiile următoare:

  • Numele serverului Edge Gateway 1: gate-tunnel-1
  • Numele serverului Edge Gateway 2: gate-tunnel-2
  • Numele organizației CyberElements Gate: tunnel

Fișierul /etc/ipdiva/server/services.xml s-ar completa astfel:

 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>
Fișier complet 
 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>

Pentru a aplica noua configurare, reporniți SSL Router cu următoarea comandă:

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

Inițializarea bazei de date

Atenție!

Trebuie să creați baza de date default înainte ca CyberElements Bastion să o inițializeze (nu se creează automat).

Pentru a inițializa baza de date PostgreSQL de configurare a sistemului, trebuie mai întâi să configurați parametrii de conexiune pe Mediation Controller.
Pentru aceasta, editați fișierul /etc/ipdiva/care/databasesettings.ini pe ambele servere și adăugați intrările următoare:

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

Înlocuiți elementele următoare:

  • DB_USERNAME cu numele de utilizator folosit pentru conectarea la baza de date.
  • DB_PWD cu parola utilizatorului care se conectează.
  • DB_HOST cu adresa IP sau numele DNS utilizat pentru conectarea la baza de date; dacă se utilizează o conexiune prin serverele Edge Gateway, va trebui să indicați 127.0.0.1.
  • DB_PORT cu portul utilizat pentru conectarea la instanța de bază de date; dacă se utilizează o conexiune prin serverele Edge Gateway, va trebui să indicați 1432.

Inițializarea bazei de date poate fi lansată cu următoarele comenzi, care trebuie executate pe un singur Mediation Controller:

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

După aceea, mai rămâne doar să reporniți serviciul apache2 pe cele două Mediation Controller pentru a aplica inițializarea bazei de date a sistemului:

1
systemctl restart apache2

Configurarea unui server de timp NTP

Se recomandă configurarea unui server de timp pentru a menține actualizat ceasul sistemului. Etapele necesare sunt descrise pe pagina de configurare NTP.

Configurările inițiale ale CyberElements Bastion

Autorizarea accesului la interfețele web cu IP-ul virtual

În mod implicit, nu este permisă conectarea la interfețele web ale produsului CyberElements Bastion cu IP-ul virtual VIP_MED_WEB.
Pentru a adăuga autorizarea, executați ca root următoarele comenzi pe Mediation Controller:

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

Înlocuiți IP cu adresa IP corespunzătoare lui VIP_MED_WEB.

Configurări inițiale

În această etapă, serverele Mediation Controller sunt instalate, dar mai rămân mai multe acțiuni de efectuat:

  • Schimbarea parolelor implicite

    Schimbați parolele implicite ale consolelor de sistem.

    Schimbare

  • Instalarea certificatelor și a licențelor

    Mediation Controller are nevoie de mai multe certificate și de o licență pentru a fi operațional.
    Numai certificatul clientului CyberElements Bastion trebuie declarat din nou pe ambele Mediation Controller (utilizați RIP-urile RIP_MED_WEB_MASTER și RIP_MED_WEB_SLAVE).

    Instalarea certificatelor și a licenței

  • Configurarea certificatului web

    Configurați certificatul web utilizat pentru conectarea la interfețele web

    Configurare

  • Declararea unui nume DNS

    Adăugați un nume DNS autorizat să se conecteze la interfețele web.

    Adăugare