Przejdź do treści

Instalacja serwerów Mediation Controller

Uwaga

Przypomnienie: przejście na root na maszynach Debian musi odbywać się za pomocą następującego polecenia:

1
su -

Instrukcje podane na tej stronie należy wykonać na obu serwerach Mediation Controller, zaczynając od serwera MASTER.
Gdy między serwerami MASTER i SLAVE występują różnice, zostaną one wyróżnione. Jeśli nie ma o tym wzmianki, instrukcje dotyczą zarówno serwera MASTER, jak i serwera SLAVE.

Konfiguracja systemu

Połączenie z maszyną

Na wirtualnych appliance domyślnie istnieją dwa konta: konto użytkownika i konto superużytkownika.

  • Konto użytkownika
    • Login: systancia
    • Hasło: systnci
  • Konto superużytkownika
    • Login: root
    • Hasło: systnci

Połącz się z maszyną w trybie konsoli.

Uwaga

Domyślny układ klawiatury to QWERTY.

Zmiana układu klawiatury

Układ klawiatury możesz zmienić następującym wierszem poleceń:

1
dpkg-reconfigure keyboard-configuration

Pojawi się menu pozwalające wybrać inny układ klawiatury.

Następnie użyj poniższego wiersza poleceń, aby zastosować i zapisać ustawienia:

1
setupcon -k --save

Ustawienia zaczną obowiązywać natychmiast po wykonaniu tego polecenia.

Konfiguracja sieci

Skonfigurowanie statycznego adresu sieciowego dla Mediation Controller jest bezwzględnie konieczne. Aby to zrobić, najpierw trzeba ustalić nazwę interfejsu sieciowego twojej maszyny. Wykonaj następujące polecenie jako root:

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

To polecenie wyświetla nazwę interfejsu sieciowego, jego status oraz adresy IP przypisane do interfejsu.

Przykład

Po wykonaniu polecenia wyświetlany jest następujący wynik:

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

Nazwa interfejsu sieciowego to ens192.

Po ustaleniu nazwy interfejsu sieciowego można teraz edytować konfigurację sieciową maszyny.
Edytuj plik /etc/network/interfaces, aby zmodyfikować go według następującego szablonu:

 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

Gdzie:

  • INTERFACE_NAME należy zastąpić nazwą wcześniej ustalonego interfejsu sieciowego.
  • RIP_MED_WEB_MASTER należy zastąpić głównym rzeczywistym adresem IP serwera; pod tym adresem IP będą dostępne konsole webowe.
  • NETMASK należy zastąpić maską sieci powiązaną z adresem IP.
  • NETWORK_GATEWAY należy zastąpić domyślną bramą sieciową.
  • IP_DNS należy zastąpić adresem IP serwera DNS. Jeśli trzeba skonfigurować kilka serwerów (maksymalnie 3), rozdziel je spacją.
  • DNS_SUFFIX należy zastąpić sufiksem DNS, który ma być używany. Jeśli nie trzeba podawać żadnego sufiksu, usuń tę linię.
  • RIP_MED_SSL_MASTER należy zastąpić dodatkowym rzeczywistym adresem IP serwera. Pod tym adresem IP będzie dostępny SSL Router.
Przykład 
 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

Na koniec pozostaje tylko ponownie uruchomić usługę networking, aby wczytać nową konfigurację sieciową: 

1
systemctl restart networking

Skonfigurowanie statycznego adresu sieciowego dla Mediation Controller jest bezwzględnie konieczne. Aby to zrobić, najpierw trzeba ustalić nazwę interfejsu sieciowego twojej maszyny. Wykonaj następujące polecenie jako root:

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

To polecenie wyświetla nazwę interfejsu sieciowego, jego status oraz adresy IP przypisane do interfejsu.

Przykład

Po wykonaniu polecenia wyświetlany jest następujący wynik:

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

Nazwa interfejsu sieciowego to ens192.

Po ustaleniu nazwy interfejsu sieciowego można teraz edytować konfigurację sieciową maszyny.
Edytuj plik /etc/network/interfaces, aby zmodyfikować go według następującego szablonu:

 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

Gdzie:

  • INTERFACE_NAME należy zastąpić nazwą wcześniej ustalonego interfejsu sieciowego.
  • RIP_MED_WEB_SLAVE należy zastąpić głównym rzeczywistym adresem IP serwera; pod tym adresem IP będą dostępne konsole webowe.
  • NETMASK należy zastąpić maską sieci powiązaną z adresem IP.
  • NETWORK_GATEWAY należy zastąpić domyślną bramą sieciową.
  • IP_DNS należy zastąpić adresem IP serwera DNS. Jeśli trzeba skonfigurować kilka serwerów (maksymalnie 3), rozdziel je spacją.
  • DNS_SUFFIX należy zastąpić sufiksem DNS, który ma być używany. Jeśli nie trzeba podawać żadnego sufiksu, usuń tę linię.
  • RIP_MED_SSL_SLAVE należy zastąpić dodatkowym rzeczywistym adresem IP serwera. Pod tym adresem IP będzie dostępny SSL Router.
Przykład 
 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

Na koniec pozostaje tylko ponownie uruchomić usługę networking, aby wczytać nową konfigurację sieciową: 

1
systemctl restart networking

Wskazówka

Teraz, gdy konfiguracja sieciowa została zastosowana, dostęp do serwera jest możliwy przez SSH.

Zmiana haseł kont lokalnych

Systancia zdecydowanie zaleca zmianę hasła tych kont po wdrożeniu wirtualnego appliance.

Użyj poniższego polecenia i wprowadź nowe hasło dla standardowego konta systancia:

1
passwd systancia

Następnie powtórz operację dla konta superużytkownika root:

1
passwd root

Konfiguracja nazwy maszyny

Nazwę serwera można zmienić, konfigurując pliki hostname i hosts serwera.

Edytuj plik /etc/hostname, aby wskazać nazwę maszyny.
Produkt potrzebuje nowej nazwy w innym miejscu, dlatego poniższym poleceniem trzeba utworzyć kopię poprzedniego pliku:

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

Konfigurację pliku /etc/hosts trzeba powtórzyć w odniesieniu do rzeczywistego głównego adresu IP maszyny (RIP_MED_WEB_MASTER).
Aby to zrobić, edytuj plik /etc/hosts i sprawdź, czy druga linia ma następujący format:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

Jeśli maszyna nazywa się MEDIATION-CONTROLLER-MASTER i nie należy do żadnej domeny, a jej rzeczywisty adres IP RIP_MED_WEB_MASTER to 10.0.10.10, plik należy uzupełnić następująco:

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Jeśli maszyna należy do domeny DOMAIN.LOCAL, plik należy uzupełnić następująco:

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

Konfigurację pliku /etc/hosts trzeba powtórzyć w odniesieniu do rzeczywistego głównego adresu IP maszyny (RIP_MED_WEB_SLAVE).
Aby to zrobić, edytuj plik /etc/hosts i sprawdź, czy druga linia ma następujący format:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

Jeśli maszyna nazywa się MEDIATION-CONTROLLER-SLAVE i nie należy do żadnej domeny, a jej rzeczywisty adres IP RIP_MED_WEB_SLAVE to 10.0.10.12, plik należy uzupełnić następująco:

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Jeśli maszyna należy do domeny DOMAIN.LOCAL, plik należy uzupełnić następująco:

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

Aby zastosować nową konfigurację, uruchom ponownie serwer:

1
reboot

Zmiana strefy czasowej

Wirtualne appliance jest domyślnie ustawione na strefę czasową Europe/Paris.

Aby zmienić tę strefę czasową, najpierw pobierz zapis dostępnych stref czasowych następującym poleceniem:

1
timedatectl list-timezones

Następnie użyj poniższego wiersza poleceń:

1
timedatectl set-timezone your_time_zone
Przykład

Aby ustawić strefę czasową na Londyn, należy wykonać następujące polecenie:

1
timedatectl set-timezone Europe/London

Sprawdź strefę czasową serwera następującym wierszem poleceń:

1
timedatectl

Inicjalizacja serwera Mediation Controller

Inicjalizacja serwera Mediation Controller

Serwer Mediation Controller inicjalizuje się za pomocą skryptu konfiguracyjnego. Ten skrypt konfiguruje ponownie adresy IP klastra w poszczególnych usługach produktu i wstępnie konfiguruje parametry wymagane do działania HTML5 Gateway.
Uruchom go następującym wierszem polecenia jako root:

1
/opt/systancia/initializeCluster

Skrypt poprosi cię o wprowadzenie następujących informacji:

  • IP VIP HTTPS: wirtualny webowy adres IP klastra, czyli VIP_MED_WEB.
  • IP VIP SSL: wirtualny adres IP SSL klastra, czyli VIP_MED_SSL.
  • IP VIP ZIO: wirtualny adres IP dla połączenia serwera Mediation Controller SLAVE z wewnętrzną bazą danych konfiguracji serwera MASTER, czyli VIP_MED_ZEO.
  • IP Master HTTPS: rzeczywisty webowy adres IP serwera Mediation Controller MASTER, czyli RIP_MED_WEB_MASTER.
  • IP Master SSL: rzeczywisty adres IP SSL Router serwera Mediation Controller MASTER, czyli RIP_MED_SSL_MASTER.
  • IP Slave HTTPS: rzeczywisty webowy adres IP serwera Mediation Controller SLAVE, czyli RIP_MED_WEB_SLAVE.
  • IP Slave SSL: rzeczywisty adres IP SSL Router serwera Mediation Controller SLAVE, czyli RIP_MED_SSL_SLAVE.
  • HTML5 port: lokalny port nasłuchu do przekierowania dostępu do usługi HTML5 Gateway; zalecamy podanie portu 1234.
  • Gateway: nazwa Edge Gateway; podaj nazwę pierwszego Edge Gateway.
  • Organization: nazwa organizacji, z którą będą się łączyć Edge Gateway i HTML5 Gateway.

Po zakończeniu inicjalizacji uruchom ponownie serwer:

1
reboot

Zmiana hasła konsoli /mediation/system CyberElements Gate

Na tym etapie instalacji dostępny jest nowy interfejs administracyjny: Zmień hasło

Zastosowanie licencji i certyfikatów

Nadal w konsoli /mediation/system musisz wprowadzić certyfikaty i licencje serwera Mediation Controller.

Uwaga!

Licencja i certyfikat SSL Router są specyficzne dla serwera Mediation Controller MASTER lub SLAVE.
Skonfigurowanie niewłaściwej licencji lub niewłaściwego certyfikatu spowoduje później nieprawidłowe działanie.

Zastosuj licencję i certyfikat komponentu SSL Router:

  1. Kliknij kartę Settings.
  2. Wybierz z menu SSL Connections.
  3. Wyszukaj certyfikat dla SSL Router.
  4. Wprowadź hasło certyfikatu SSL Router.
  5. Kliknij Apply, aby zastosować certyfikat do SSL Router.
  6. Wybierz plik licencji serwera.
  7. Kliknij Modify, aby zastosować licencję serwera.

Następnie wprowadź informacje o certyfikacie klienta CyberElements Bastion:

  1. Wybierz kartę Plugin.
  2. Wyszukaj certyfikat klienta CyberElements Bastion.
  3. Wprowadź hasło certyfikatu.
  4. Kliknij Apply, aby zastosować certyfikat.

Pozostaje jeszcze wprowadzić informacje o certyfikacie Watchdog:

  1. Wybierz kartę Watchdog
  2. Wyszukaj certyfikat Watchdog.
  3. Wprowadź hasło certyfikatu.
  4. Kliknij Apply, aby zastosować certyfikat.

Aby te zmiany zaczęły obowiązywać, musisz ponownie uruchomić SSL Router i Watchdog:

Pairing serwerów Mediation Controller

Uwaga!

W tym momencie oba serwery Mediation Controller muszą być skonfigurowane aż do zastosowania licencji i certyfikatów.
Jeśli serwer Mediation Controller SLAVE nie jest jeszcze skonfigurowany, zrób to, zaczynając od początku tej dokumentacji.

Krok pairingu serwerów Mediation Controller ustanawia relację zaufania między tymi dwoma serwerami i inicjalizuje pracę klastra.

Na serwerze Mediation Controller SLAVE

Wykonaj następujące polecenie jako root, aby wysłać żądanie pairingu do serwera Mediation Controller MASTER:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Zastąp RIP_MED_WEB_MASTER odpowiednim adresem IP.

Przykład

Jeśli RIP_MED_WEB_MASTER jest równe 10.0.10.10, polecenie do wprowadzenia jest następujące:

1
hostManagerCtl bootstrap 10.0.10.10

Na serwerze Mediation Controller MASTER

Wykonaj następujące polecenie jako root, aby wyświetlić oczekujące żądania pairingu i pobrać identyfikator żądania: 

1
hostManagerCtl getPendingRequests

Następnie wykonaj poniższe polecenie, aby zaakceptować żądanie pairingu, zastępując ID identyfikatorem pobranym poprzednim poleceniem:

1
hostManagerCtl acceptRequest ID
Przykład

Jeśli wynik polecenia hostManagerCtl getPendingRequests jest następujący:

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

Wówczas polecenie akceptujące żądanie pairingu jest następujące:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

Aby zweryfikować powiązanie, użyj poniższego polecenia na serwerze Mediation Controller (MASTER albo SLAVE):

1
hostManagerCtl listPeers

Wynik różni się w zależności od serwera, na którym polecenie jest wykonywane:

Oczekiwany wynik na serwerze Mediation Controller MASTER jest następujący:

1
slave -> RIP_MED_WEB_SLAVE
Przykład 
1
slave -> 10.0.10.12

Oczekiwany wynik na serwerze Mediation Controller SLAVE jest następujący:

1
master -> RIP_MED_WEB_MASTER
Przykład 
1
master -> 10.0.10.10

Na serwerze Mediation Controller SLAVE

Status bootstrapu możesz sprawdzić z serwera SLAVE za pomocą następującego polecenia:

1
hostManagerCtl getBootstrapStatus

Klaster, który nie ma problemów z synchronizacją, zwraca wartość 0.

Potrzebna jest ostatnia seria poleceń, ponownie na serwerze SLAVE, aby zsynchronizować sekret dzielony między oboma Mediation Controller:

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2
Do czego służy połączenie międzyserwerowe?

Jest to szczególne połączenie pracy klastra, które umożliwia serwerowi Mediation Controller przekierowanie ruchu do innego serwera Mediation Controller, gdy docelowy Edge Gateway nie jest połączony z pierwszym serwerem, lecz tylko z drugim.

Na przykład jeśli serwer Mediation Controller MASTER nie jest już połączony z Edge Gateway, może wykorzystać połączenie międzyserwerowe, aby dotrzeć do Edge Gateway przez serwer Mediation Controller SLAVE.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Utracone połączenie| GW(Edge Gateway)
    MASTER --> |Połączenie między serwerami| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

Na serwerze Mediation Controller MASTER

Edytuj plik /etc/ipdiva/server/remoteServers.xml, aby wskazać CN certyfikatu międzyserwerowego:

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

Zastąp SLAVECN przez CN certyfikatu przeznaczonego do połączenia międzyserwerowego.
Jeśli nie znasz CN certyfikatu międzyserwerowego, możesz wprowadzić znak * (zalecane w razie wątpliwości):

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"/>
                -->
Przykład

Uwzględniając następujące informacje:

  • CN certyfikatu międzyserwerowego: my-interserver-cert

Plik /etc/ipdiva/server/remoteServers.xml na serwerze Mediation Controller MASTER należy uzupełnić następująco:

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

Na serwerze Mediation Controller SLAVE

Wyślij certyfikat międzyserwerowy do Mediation Controller SLAVE, do katalogu /tmp/.
Następnie wykonaj poniższe polecenia jako root, aby przenieść go do katalogu docelowego z odpowiednimi uprawnieniami:

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

Następnie edytuj plik /etc/ipdiva/server/remoteServers.xml, aby dodać do tagu <remoteConfig> następującą treść (stary tag <localCluster> można całkowicie usunąć):

 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>

Zamień:

  • MASTERCN: wskaż CN certyfikatu SSL Router Mediation Controller MASTER; zwykle jest to RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER: odpowiada dodatkowemu adresowi IP Mediation Controller MASTER.
  • PORT_RIP_MED_SSL_MASTER: to port, na którym nasłuchuje SSL Router Mediation Controller MASTER; zwykle jest to 443.
  • INTERSERVER.P12: nazwa certyfikatu przeznaczonego do połączenia międzyserwerowego.
  • PASSWORD: hasło certyfikatu międzyserwerowego.
Przykład

Uwzględniając następujące informacje:

  • Nazwa certyfikatu międzyserwerowego: my-interserver-cert.p12
  • Hasło certyfikatu międzyserwerowego: MySecurePassword
  • RIP SSL Mediation Controller MASTER: 10.0.10.11
  • Port na RIP SSL Mediation Controller MASTER: 443
  • CN certyfikatu Mediation Controller MASTER: 10.0.10.11

Plik /etc/ipdiva/server/remoteServers.xml na serwerze Mediation Controller SLAVE należy uzupełnić następująco:

 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>
Kompletny plik 
 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>

Zmień konfigurację SSL Router SLAVE, wykonując następujące polecenie:

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

Na serwerach Mediation Controller MASTER i SLAVE

Uruchom ponownie SSL Router, aby zastosować konfigurację połączenia międzyserwerowego:

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

Aby potwierdzić, że połączenie międzyserwerowe działa poprawnie, poniższe polecenie musi zwrócić wynik:

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

Poprzednie polecenie musi wygenerować log o następującej treści: TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers, and 0 multicast group(s).
Jeśli taki log nie jest wyświetlany, sprawdź konfigurację wprowadzoną w tym rozdziale.

W konsoli webowej /mediation/system Mediation Controller MASTER

Włącz połączenie międzyserwerowe między oboma Mediation Controller, edytując wirtualny host SSL default:

Wypełnij poszczególne pola zgodnie z poniższymi wskazaniami i włącz funkcję połączenia międzyserwerowego, zaznaczając pole wyboru Is cross-server linking configured?:

  • Public address for plugin connections: odpowiada VIP_MED_SSL, po którym następuje jego port nasłuchu (zwykle 443).
  • Actual public IP addresses for web connections: odpowiada parze rzeczywistych webowych adresów IP (RIP_MED_WEB_MASTER i RIP_MED_WEB_SLAVE) z odpowiednimi portami, po jednej linii na parę adresu IP i portu.
  • Actual public IP addresses for SSL connections: odpowiada parze rzeczywistych adresów IP SSL (RIP_MED_SSL_MASTER i RIP_MED_SSL_SLAVE) z odpowiednimi portami, po jednej linii na parę adresu IP i portu.

Inicjalizacja CyberElements Bastion

Połączenie z bazą danych PostgreSQL

Do działania CyberElements Bastion wymaga zewnętrznej bazy danych PostgreSQL (BD), aby przechowywać swoją konfigurację i różne logi konsoli /system.
Jeśli BD jest bezpośrednio osiągalna z serwerów Mediation Controller, przejdź od razu do kroku inicjalizacji BD.

Połączenie z bazą danych w sieci LAN

Aby umożliwić połączenie z bazą danych znajdującą się w sieci LAN bez otwierania przepływu z DMZ do LAN, przepływ bazy danych zostanie przekierowany przez tunel TLS między Edge Gateway a Mediation Controller.
W tym celu trzeba skonfigurować jeden Edge Gateway (lub dwa Edge Gateway) przy użyciu leżącej u podstaw technologii CyberElements Gate.

Deklaracja Edge Gateway CyberElements Gate

Aby to zrobić, zaloguj się najpierw do konsoli /mediation/system w CyberElements Gate.

Następnie otwórz menu „Organizations” i kliknij „Add”:

Wprowadź nazwę organizacji, która musi być inna niż nazwa przypisana dla CyberElements Bastion (na przykład tunnel), i podaj co najmniej jedną licencję sesji użytkownika oraz hasło konta admin:

Zaloguj się do interfejsu administracyjnego utworzonej wcześniej organizacji za pomocą konta admin, przechodząc do /gate/admin:

Następnie zadeklaruj oba Edge Gateway, które zostaną użyte do zbudowania tunelu.
Po lewej stronie najedź na Infrastructure, kliknij Gateways, a następnie kliknij przycisk Add:

Wprowadź nazwę pierwszego Edge Gateway i zatwierdź wpis:

Informacja

Przypomnienie: nazwa Edge Gateway jest powiązana z certyfikatem, którego użyje on do uwierzytelnienia się względem SSL Router serwera Mediation Controller.
Ta nazwa ma następującą postać <GW_NAME>@<ORGANIZATION_NAME>, gdzie <GW_NAME> odpowiada nazwie Edge Gateway, a <ORGANIZATION_NAME> odpowiada nazwie organizacji utworzonej w konsoli systemowej CyberElements Gate.

Powtórz krok deklaracji dla drugiego Edge Gateway.

Połączenia i konfiguracja tunelu na Edge Gateway

Informacja

Poniższe kroki można wykonać na obu Edge Gateway używanych do tunelu dostępu do bazy danych.

Wymagania wstępne

Aby ukończyć tę część, musisz skorzystać z jednej z dwóch możliwości:

Najpierw użyj narzędzia takiego jak WinSCP lub FileZilla, aby przenieść przez SCP certyfikat wymagany do połączenia do katalogu /tmp/ na Edge Gateway.

Następnie połącz się przez SSH i przejdź na root.

Aby połączyć Edge Gateway z oboma Mediation Controller, musisz utworzyć dwie nowe instancje Edge Gateway: jedna połączy się z Mediation Controller MASTER, a druga z Mediation Controller SLAVE.
Aby je utworzyć, wykonaj następujące polecenia:

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

Skopiuj plik certyfikatu do katalogów /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/

Zastąp <CERT_NAME> nazwą certyfikatu, którego Edge Gateway musi użyć, aby połączyć się z Mediation Controller.

Skonfiguruj instancje Edge Gateway tak, aby mogły łączyć się z Mediation Controller.
Konfiguracje różnią się w zależności od Mediation Controller, z którym trzeba się połączyć. Wykonaj obie konfiguracje:

Edytuj plik /etc/ipdiva/gateway-tunnel-master/gateway.xml i uzupełnij go następującymi informacjami (kilka sekcji zostało pominiętych i oznaczonych jako […]):

 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>

Zastąp następujące elementy:

  • @SERVER@: należy zastąpić adresem RIP_MED_SSL_MASTER
  • @SERVERPORT@: należy zastąpić portem nasłuchu SSL Router, zwykle ustawionym na 443
  • keyfile.pem: należy zastąpić nazwą pliku certyfikatu
  • PASSWORD: należy zastąpić hasłem certyfikatu
  • @RPC_PORT@: należy zastąpić portem, na którym maszyna obecnie nie nasłuchuje; można użyć portu 9082
Przykład

Uwzględniając następujące informacje:

  • RIP_MED_SSL_MASTER jest równe: 10.0.10.11
  • Port nasłuchu SSL Router: 443
  • Nazwa pliku certyfikatu: gate-tunnel.p12
  • Hasło certyfikatu: Str0ngP@ssw0rd

Plik /etc/ipdiva/gateway-tunnel-master/gateway.xml należy skonfigurować następująco:

 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>
Kompletny plik 
 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>

Edytuj plik /etc/ipdiva/gateway-tunnel-slave/gateway.xml i uzupełnij go następującymi informacjami (kilka sekcji zostało pominiętych i oznaczonych jako […]):

 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>

Zastąp następujące elementy:

  • @SERVER@: należy zastąpić adresem RIP_MED_SSL_SLAVE
  • @SERVERPORT@: należy zastąpić portem nasłuchu SSL Router, zwykle ustawionym na 443
  • keyfile.pem: należy zastąpić nazwą pliku certyfikatu
  • PASSWORD: należy zastąpić hasłem certyfikatu
  • @RPC_PORT@: należy zastąpić portem, który obecnie nie jest używany na maszynie; można użyć portu 9083
Przykład

Uwzględniając następujące informacje:

  • RIP_MED_SSL_SLAVE jest równe: 10.0.10.13
  • Port nasłuchu SSL Router: 443
  • Nazwa pliku certyfikatu: gate-tunnel.p12
  • Hasło certyfikatu: Str0ngP@ssw0rd

Plik /etc/ipdiva/gateway-tunnel-slave/gateway.xml należy skonfigurować następująco:

 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>
Kompletny plik 
 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>

Teraz, gdy instancje są skonfigurowane do łączenia się z Mediation Controller, trzeba je jeszcze skonfigurować tak, aby przekierowywały połączenie Mediation Controller do bazy danych.
Aby to zrobić, edytuj plik /etc/ipdiva/gateway-tunnel-master/services.xml i zmodyfikuj go następująco: 

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>

Zastąp DB_SERVER nazwą DNS lub adresem IP używanym do połączenia z bazą danych, a DB_PORT portem nasłuchu instancji bazy danych.
Powtórz tę konfigurację dla instancji łączącej się z serwerem Mediation Controller SLAVE, kopiując plik:

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

Na koniec uruchom instancje Edge Gateway, aby ustanowiły połączenie z Mediation Controller:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Konfiguracja tunelu na Mediation Controller

Aby tunel mógł być używany przez Mediation Controller, trzeba jeszcze zadeklarować jego istnienie.
Aby to zrobić, zaloguj się jako root na Mediation Controller i edytuj plik /etc/ipdiva/server/services.xml, aby dodać następującą sekcję (kilka sekcji zostało pominiętych i oznaczonych jako […]):

 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>

Zastąp następujące elementy:

  • GW1_NAME nazwą pierwszego Edge Gateway
  • GW2_NAME nazwą drugiego Edge Gateway
  • ORGANIZATION_NAME nazwą utworzonej wcześniej organizacji CyberElements Gate
Przykład

Uwzględniając następujące informacje:

  • Nazwa Edge Gateway 1: gate-tunnel-1
  • Nazwa Edge Gateway 2: gate-tunnel-2
  • Nazwa organizacji CyberElements Gate: tunnel

Plik /etc/ipdiva/server/services.xml należy uzupełnić następująco:

 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>
Kompletny plik 
 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>

Aby zastosować nową konfigurację, uruchom ponownie SSL Router następującym poleceniem:

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

Inicjalizacja bazy danych

Uwaga!

Musisz utworzyć bazę danych default, zanim CyberElements Bastion ją zainicjalizuje (nie jest tworzona automatycznie).

Aby zainicjalizować bazę danych PostgreSQL konfiguracji systemowej, musisz najpierw skonfigurować parametry połączenia na Mediation Controller.
Aby to zrobić, edytuj plik /etc/ipdiva/care/databasesettings.ini na obu serwerach i dodaj następujące wpisy:

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

Zastąp następujące elementy:

  • DB_USERNAME nazwą użytkownika używaną do połączenia z bazą danych.
  • DB_PWD hasłem użytkownika, który się łączy.
  • DB_HOST adresem IP lub nazwą DNS używaną do połączenia z bazą danych; jeśli wykorzystywane jest połączenie przez Edge Gateway, trzeba podać 127.0.0.1.
  • DB_PORT portem używanym do połączenia z instancją bazy danych; jeśli wykorzystywane jest połączenie przez Edge Gateway, trzeba podać 1432.

Inicjalizację bazy danych można uruchomić następującymi poleceniami, wykonywanymi tylko na jednym Mediation Controller:

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

Następnie pozostaje tylko ponownie uruchomić usługę apache2 na obu Mediation Controller, aby zastosować inicjalizację systemowej bazy danych:

1
systemctl restart apache2

Konfiguracja serwera czasu NTP

Zaleca się skonfigurowanie serwera czasu, aby zegar systemowy pozostawał aktualny. Niezbędne kroki są opisane na stronie konfiguracji NTP.

Początkowe konfiguracje CyberElements Bastion

Uprawnienie do dostępu do interfejsów webowych za pomocą wirtualnego adresu IP

Domyślnie łączenie się z interfejsami webowymi produktu CyberElements Bastion przy użyciu wirtualnego adresu IP VIP_MED_WEB nie jest dozwolone.
Aby dodać uprawnienie, wykonaj jako root następujące polecenia na Mediation Controller:

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

Zastąp IP adresem IP odpowiadającym VIP_MED_WEB.

Początkowe konfiguracje

Na tym etapie serwery Mediation Controller są zainstalowane, ale trzeba jeszcze wykonać kilka działań:

  • Zmień domyślne hasła

    Zmień domyślne hasła konsol systemowych.

    Zmień

  • Zainstaluj certyfikaty i licencje

    Mediation Controller wymaga różnych certyfikatów oraz licencji, aby był gotowy do pracy.
    Tylko certyfikat klienta CyberElements Bastion trzeba zadeklarować ponownie na obu Mediation Controller (użyj RIP RIP_MED_WEB_MASTER i RIP_MED_WEB_SLAVE).

    Zainstaluj certyfikaty i licencję

  • Skonfiguruj certyfikat webowy

    Skonfiguruj certyfikat webowy używany do łączenia się z interfejsami webowymi

    Skonfiguruj

  • Zadeklaruj nazwę DNS

    Dodaj nazwę DNS uprawnioną do łączenia się z interfejsami webowymi.

    Dodaj