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.

Pobieranie mirrora i niezbędnych narzędzi

Mirror CyberElements Cleanroom 4.6 oraz klucz podpisu repozytorium Systancia można pobrać z tego odnośnika (wymaga utworzenia konta klienta): Systancia Marketplace

Poza mirrorem i kluczem do procesu aktualizacji będą potrzebne narzędzia innych producentów:

  • Klient SSH (w systemie Windows możesz użyć PuTTY)
  • Klient SCP (w systemie Windows można użyć narzędzi WinSCP lub FileZilla)

Użyj klienta SSH, aby połączyć się zdalnie ze swoim serwerem.

Użyj klienta SCP, aby przenieść pliki na maszynę zdalną.

Przygotowanie do instalacji

Konfiguracja sieci

Zainstaluj pakiet resolvconf, aby można było zastosować konfigurację DNS podaną w pliku konfiguracyjnym, który zostanie zmodyfikowany za chwilę:

1
apt install -y resolvconf

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

Pozostaje jeden ostatni krok: zmodyfikować wewnętrzne rozwiązywanie nazw maszyny tak, aby rozwiązywało jej rzeczywisty główny adres IP (odpowiadający RIP_MED_WEB_MASTER lub RIP_MED_WEB_SLAVE).
Aby to zrobić, edytuj plik /etc/hosts i zastąp 127.0.1.1 przez RIP_MED_WEB_MASTER lub RIP_MED_WEB_SLAVE, zależnie od serwera Mediation Controller.

Example

Dla serwera Mediation Controller, którego rzeczywisty webowy adres IP to 10.0.10.10, a nazwa to mediation-controller.domain.local, plik /etc/hosts będzie mieć następującą wartość:

1
2
127.0.0.1       localhost
10.0.10.10      mediation-controller.domain.local   mediation-controller

Uwaga!

Nieprawidłowa konfiguracja pliku może spowodować błąd przy instalacji pakietu collectd.

Konfiguracja menedżera pakietów APT

Prześlij pliki pobrane z Systancia Marketplace do katalogu /tmp/ na serwerze za pomocą klienta SCP:

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

Zaloguj się na serwerze jako root, a następnie wykonaj poniższe polecenia, aby rozpakować repozytorium Systancia, skonfigurować jego użycie w APT i je uwierzytelnić.

1
2
3
4
5
mv /tmp/systancia.gpg /etc/apt/trusted.gpg.d/
mkdir -p /opt/systancia/repository/
tar xvzf /tmp/cleanroom-4.6*.tgz -C /opt/systancia/repository/
echo "deb file:///opt/systancia/repository/ bookworm ipdiva" > /etc/apt/sources.list.d/systancia.list
apt update

Stanowczo zalecamy wyłączenie instalacji niepotrzebnych pakietów przy wykonywaniu poleceń apt. Aby to zrobić, wykonaj następujące polecenie:

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

Sprawdzenie obecności ustawień regionalnych en_US.utf8

Instalacja serwera Mediation Controller wymaga wygenerowania ustawień regionalnych en_US.utf8.
Aby sprawdzić, czy zostały już wygenerowane na serwerze, wykonaj następujące polecenie jako root:

1
locale -a  | grep en_US.utf8

Jeśli odpowiedź polecenia zawiera en_US.utf8, przejdź do następnego kroku, czyli konfiguracji GRUB.
W przeciwnym razie wykonaj poniższe polecenia, aby dodać te ustawienia regionalne do maszyny:

1
2
sed -i "s/# en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/" /etc/locale.gen
locale-gen

Konfiguracja programu rozruchowego GRUB

Po wykonaniu tych poleceń musisz ponownie uruchomić maszynę, po wprowadzeniu ustawienia w programie rozruchowym GRUB:

1
2
3
sed '9s/quiet/quiet vsyscall=emulate/' -i /etc/default/grub
update-grub
reboot

Instalacja serwera Mediation Controller CyberElements Bastion

Instalacja komponentów podstawowych

Rozpocznij instalację komponentów za pomocą następującego polecenia jako root:

1
apt install -y ipdiva-base

Po pobraniu wszystkich zależności otworzy się okno z prośbą o wybór typu serwera. Wybierz mediation:

Następnie wybierz tryb instalacji lbMaster:

Następnie wybierz tryb instalacji lbSlave:

Następnie trzeba będzie podać port, na którym będzie nasłuchiwał SSL Router. Ten port nasłuchu jest zwykle ustawiony na 443, ale można też użyć portu 8443, jeśli Mediation Controller używa tylko jednego adresu IP:

Następnie ustaw tryb Cluster na loadbalancing, aby obciążenie użytkownikami było rozłożone na oba serwery Mediation Controller:

Podaj wirtualny webowy adres IP klastra, VIP_MED_WEB:

Podaj wirtualny adres IP SSL klastra, VIP_MED_SSL:

Podaj wirtualny adres IP bazy danych konfiguracji klastra, VIP_MED_ZEO:

Podaj rzeczywisty webowy adres IP Mediation Controller MASTER, RIP_MED_WEB_MASTER:

Podaj rzeczywisty adres IP SSL Mediation Controller MASTER, RIP_MED_SSL_MASTER:

Podaj rzeczywisty webowy adres IP Mediation Controller SLAVE, RIP_MED_WEB_SLAVE:

Na koniec podaj rzeczywisty adres IP SSL Mediation Controller SLAVE, RIP_MED_SSL_SLAVE:

Co zrobić w razie błędu?

Jeśli we wprowadzonych informacjach jest błąd, kontynuuj instalację pakietu ipdiva-base, a następnie użyj poniższego polecenia, aby ponownie skonfigurować serwer:

1
dpkg-reconfigure ipdiva-base

Instalacja komponentów Cluster

Po zainstalowaniu komponentów podstawowych trzeba zainstalować komponenty Cluster na serwerach Mediation Controller:

1
apt install -y ipdiva-mediation-cluster

Po zainstalowaniu komponentów wymagane jest ponowne uruchomienie:

1
reboot

Konfiguracja klastra

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.

Instalacja komponentów specyficznych dla CyberElements Bastion

Rozpocznij instalację komponentów CyberElements Bastion na serwerach Mediation Controller za pomocą następującego polecenia:

1
apt install -y ipdiva-safe-server

Aby zakończyć instalację, serwery muszą zostać ponownie uruchomione:

1
reboot

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

Instalacja sterowników do połączenia z bazami danych Microsoft SQL

Jeśli chcesz połączyć się z zewnętrzną bazą danych i jest nią Microsoft SQL Server, musisz zainstalować dodatkowe sterowniki ODBC.

Dostępne są dwie wersje: wersja 17 i wersja 18.

Połączenie TLS wymagane dla sterowników w wersji 18

Korzystanie ze sterowników ODBC 18 wymaga, aby połączenie było szyfrowane za pomocą TLS. W tym celu musisz skonfigurować MS SQL Server do szyfrowania połączeń.

Przed rozpoczęciem instalacji sterowników ODBC musisz zainstalować pakiety niezbędne do przygotowania, a następnie przygotować repozytorium Microsoft do instalacji pakietów:

1
2
3
4
apt install -y curl apt-transport-https gpg
curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg
curl https://packages.microsoft.com/config/debian/12/prod.list > /etc/apt/sources.list.d/mssql-release.list
apt update

Następnie zainstaluj sterowniki odpowiednio do wybranej wersji i skonfiguruj system do używania polecenia sqlcmd:

1
2
3
ACCEPT_EULA=Y apt install -y msodbcsql17 mssql-tools python3-pip
pip install mssql-scripter --break-system-packages
ln -sfn /opt/mssql-tools/bin/sqlcmd /usr/bin/sqlcmd

1
2
3
ACCEPT_EULA=Y apt install -y msodbcsql18 mssql-tools18 python3-pip
pip install mssql-scripter --break-system-packages
ln -sfn /opt/mssql-tools18/bin/sqlcmd /usr/bin/sqlcmd

Sterowniki ODBC są teraz poprawnie zainstalowane.
Jeśli serwer Mediation Controller ma dostęp do serwera MS SQL, poniższe polecenie powinno umożliwić połączenie ze zdalnym serwerem: 

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

Gdzie:

  • SERVER należy zastąpić nazwą DNS lub adresem IP serwera MS SQL.
  • INSTANCE_NAME należy zastąpić nazwą instancji, z którą trzeba się połączyć; jeśli nie jest to konieczne, usuń również znak \.
  • PORT należy zastąpić portem połączenia z instancją bazy danych MS SQL.
  • USER należy zastąpić nazwą użytkownika, za pomocą której ustanawiane jest połączenie.
Przykłady

Jeśli serwer Mediation Controller ma dostęp do serwera bazy danych MS SQL pod adresem IP 10.0.10.100, instancja, do której trzeba uzyskać dostęp, nasłuchuje na porcie 1433, a kontem dostępu jest sql-user. Wówczas polecenie połączenia jest następujące:

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

Gdyby trzeba było wskazać instancję połączenia o nazwie MSSQLINSTANCE, polecenie należałoby zmienić następująco:

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

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

  • Skonfiguruj organizację

    Skonfiguruj organizację CyberElements Bastion.

    Skonfiguruj z bezpośrednim dostępem do bazy danych

    Skonfiguruj z dostępem do bazy danych przez tunel Edge Gateway

  • Zadeklaruj Edge Gateway

    Zadeklaruj Edge Gateway lub HTML5 Gateway, które mają zostać zainstalowane.

    Utwórz Edge Gateway

  • Utwórz site logiczny

    Utwórz i skonfiguruj site logiczny, który grupuje Edge Gateway i HTML5 Gateway mogące uzyskać dostęp do zasobów lokalnych.

    Utwórz site

  • Zainstaluj Edge Gateway

    Zainstaluj i skonfiguruj nowy Edge Gateway z nowo zainstalowanymi serwerami Mediation Controller.
    Zostanie też skonfigurowana instancja HTML5 Gateway.

    Zainstaluj