Zum Inhalt

Installation der Mediation-Controller-Server

Hinweis

Zur Erinnerung: Der Wechsel zu root muss auf Debian-Maschinen mit dem folgenden Befehl erfolgen:

1
su -

Die Anweisungen auf dieser Seite sind auf beiden Mediation-Controller-Servern auszuführen, beginnend mit dem Server MASTER.
Wenn es Unterschiede zwischen den Servern MASTER und SLAVE gibt, werden diese hervorgehoben. Wird nichts erwähnt, gelten die Anweisungen sowohl für den Server MASTER als auch für den Server SLAVE.

Systemkonfiguration

Verbindung mit der Maschine

Auf den virtuellen Appliances gibt es standardmäßig zwei Konten: ein Benutzerkonto und ein Superuser-Konto.

  • Benutzerkonto
    • Anmeldung: systancia
    • Passwort: systnci
  • Superuser-Konto
    • Anmeldung: root
    • Passwort: systnci

Verbinden Sie sich im Konsolenmodus mit der Maschine.

Hinweis

Die Standard-Tastaturbelegung ist QWERTY.

Ändern der Tastaturbelegung

Sie können die Tastaturbelegung mit der folgenden Befehlszeile ändern:

1
dpkg-reconfigure keyboard-configuration

Es erscheint ein Menü, in dem Sie eine andere Tastaturbelegung auswählen können.

Verwenden Sie anschließend die folgende Befehlszeile, um die Einstellungen anzuwenden und zu speichern:

1
setupcon -k --save

Die Einstellungen werden unmittelbar nach der Ausführung dieses Befehls wirksam.

Konfiguration des Netzwerks

Es ist unbedingt erforderlich, für den Mediation Controller eine statische Netzwerkadresse zu konfigurieren. Dazu muss zunächst der Name der Netzwerkschnittstelle Ihrer Maschine ermittelt werden. Führen Sie den folgenden Befehl als root aus:

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

Dieser Befehl zeigt den Namen der Netzwerkschnittstelle, ihren Status und die der Schnittstelle zugewiesenen IP-Adressen an.

Beispiel

Nach der Ausführung des Befehls wird die folgende Ausgabe angezeigt:

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

Der Name der Netzwerkschnittstelle ist ens192.

Sobald der Name der Netzwerkschnittstelle ermittelt ist, kann die Netzwerkkonfiguration der Maschine bearbeitet werden.
Bearbeiten Sie die Datei /etc/network/interfaces, um sie nach der folgenden Vorlage zu ändern:

 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

Dabei gilt:

  • INTERFACE_NAME muss durch den zuvor ermittelten Namen der Netzwerkschnittstelle ersetzt werden.
  • RIP_MED_WEB_MASTER muss durch die reale Haupt-IP-Adresse des Servers ersetzt werden; über diese IP-Adresse sind die Webkonsolen erreichbar.
  • NETMASK muss durch die zur IP-Adresse gehörende Netzmaske ersetzt werden.
  • NETWORK_GATEWAY muss durch das Standard-Gateway des Netzwerks ersetzt werden.
  • IP_DNS muss durch die IP-Adresse des DNS-Servers ersetzt werden. Wenn mehrere Server konfiguriert werden müssen (maximal 3), trennen Sie sie durch ein Leerzeichen.
  • DNS_SUFFIX muss durch das zu verwendende DNS-Suffix ersetzt werden. Wenn kein Suffix angegeben werden muss, löschen Sie die Zeile.
  • RIP_MED_SSL_MASTER muss durch die reale sekundäre IP-Adresse des Servers ersetzt werden. Über diese IP-Adresse ist der SSL Router erreichbar.
Beispiel 
 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

Schließlich muss nur noch der Dienst networking neu gestartet werden, damit die neue Netzwerkkonfiguration geladen wird: 

1
systemctl restart networking

Es ist unbedingt erforderlich, für den Mediation Controller eine statische Netzwerkadresse zu konfigurieren. Dazu muss zunächst der Name der Netzwerkschnittstelle Ihrer Maschine ermittelt werden. Führen Sie den folgenden Befehl als root aus:

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

Dieser Befehl zeigt den Namen der Netzwerkschnittstelle, ihren Status und die der Schnittstelle zugewiesenen IP-Adressen an.

Beispiel

Nach der Ausführung des Befehls wird die folgende Ausgabe angezeigt:

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

Der Name der Netzwerkschnittstelle ist ens192.

Sobald der Name der Netzwerkschnittstelle ermittelt ist, kann die Netzwerkkonfiguration der Maschine bearbeitet werden.
Bearbeiten Sie die Datei /etc/network/interfaces, um sie nach der folgenden Vorlage zu ändern:

 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

Dabei gilt:

  • INTERFACE_NAME muss durch den zuvor ermittelten Namen der Netzwerkschnittstelle ersetzt werden.
  • RIP_MED_WEB_SLAVE muss durch die reale Haupt-IP-Adresse des Servers ersetzt werden; über diese IP-Adresse sind die Webkonsolen erreichbar.
  • NETMASK muss durch die zur IP-Adresse gehörende Netzmaske ersetzt werden.
  • NETWORK_GATEWAY muss durch das Standard-Gateway des Netzwerks ersetzt werden.
  • IP_DNS muss durch die IP-Adresse des DNS-Servers ersetzt werden. Wenn mehrere Server konfiguriert werden müssen (maximal 3), trennen Sie sie durch ein Leerzeichen.
  • DNS_SUFFIX muss durch das zu verwendende DNS-Suffix ersetzt werden. Wenn kein Suffix angegeben werden muss, löschen Sie die Zeile.
  • RIP_MED_SSL_SLAVE muss durch die reale sekundäre IP-Adresse des Servers ersetzt werden. Über diese IP-Adresse ist der SSL Router erreichbar.
Beispiel 
 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

Schließlich muss nur noch der Dienst networking neu gestartet werden, damit die neue Netzwerkkonfiguration geladen wird: 

1
systemctl restart networking

Tipp

Nun, da die Netzwerkkonfiguration angewendet ist, kann auf den Server per SSH zugegriffen werden.

Ändern der Kennwörter der lokalen Konten

Systancia empfiehlt dringend, das Passwort dieser Konten nach der Bereitstellung der virtuellen Appliance zu ändern.

Verwenden Sie den folgenden Befehl und geben Sie das neue Passwort für das Standardkonto systancia ein:

1
passwd systancia

Wiederholen Sie den Vorgang anschließend für das Superuser-Konto root:

1
passwd root

Konfiguration des Maschinennamens

Der Name des Servers kann geändert werden, indem die Dateien hostname und hosts des Servers konfiguriert werden.

Bearbeiten Sie die Datei /etc/hostname, um den Namen der Maschine anzugeben.
Das Produkt benötigt den neuen Namen an einer anderen Stelle; daher muss mit dem folgenden Befehl eine Kopie der vorherigen Datei erstellt werden:

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

Die Konfiguration der Datei /etc/hosts muss in Bezug auf die reale Haupt-IP-Adresse der Maschine (RIP_MED_WEB_MASTER) übernommen werden.
Bearbeiten Sie dazu die Datei /etc/hosts und prüfen Sie, ob die zweite Zeile das folgende Format hat:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

Wenn die Maschine MEDIATION-CONTROLLER-MASTER heißt, ohne einer Domäne anzugehören, und ihre reale IP-Adresse RIP_MED_WEB_MASTER 10.0.10.10 ist, wäre die Datei wie folgt zu vervollständigen:

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Wenn die Maschine der Domäne DOMAIN.LOCAL angehört, wäre die Datei wie folgt zu vervollständigen:

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

Die Konfiguration der Datei /etc/hosts muss in Bezug auf die reale Haupt-IP-Adresse der Maschine (RIP_MED_WEB_SLAVE) übernommen werden.
Bearbeiten Sie dazu die Datei /etc/hosts und prüfen Sie, ob die zweite Zeile das folgende Format hat:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

Wenn die Maschine MEDIATION-CONTROLLER-SLAVE heißt, ohne einer Domäne anzugehören, und ihre reale IP-Adresse RIP_MED_WEB_SLAVE 10.0.10.12 ist, wäre die Datei wie folgt zu vervollständigen:

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Wenn die Maschine der Domäne DOMAIN.LOCAL angehört, wäre die Datei wie folgt zu vervollständigen:

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

Um die neue Konfiguration anzuwenden, starten Sie den Server neu:

1
reboot

Änderung der Zeitzone

Die virtuelle Appliance ist standardmäßig auf die Zeitzone Europe/Paris eingestellt.

Um diese Zeitzone zu ändern, rufen Sie zunächst mit dem folgenden Befehl die Schreibweise der verfügbaren Zeitzonen ab:

1
timedatectl list-timezones

Verwenden Sie anschließend die folgende Befehlszeile:

1
timedatectl set-timezone your_time_zone
Beispiel

Um die Zeitzone auf London einzustellen, ist der folgende Befehl auszuführen:

1
timedatectl set-timezone Europe/London

Prüfen Sie die Zeitzone des Servers mit der folgenden Befehlszeile:

1
timedatectl

Initialisierung des Mediation-Controller-Servers

Initialisierung des Mediation-Controller-Servers

Der Mediation-Controller-Server wird über ein Konfigurationsskript initialisiert. Dieses Skript konfiguriert die IP-Adressen des Clusters in den verschiedenen Diensten des Produkts neu und konfiguriert die für den Betrieb eines HTML5 Gateway erforderlichen Parameter vor.
Führen Sie es mit der folgenden Befehlszeile als root aus:

1
/opt/systancia/initializeCluster

Das Skript fordert Sie auf, die folgenden Informationen einzugeben:

  • IP VIP HTTPS: virtuelle Web-IP-Adresse des Clusters, also VIP_MED_WEB.
  • IP VIP SSL: virtuelle SSL-IP-Adresse des Clusters, also VIP_MED_SSL.
  • IP VIP ZIO: virtuelle IP-Adresse für die Verbindung des Mediation-Controller-Servers SLAVE mit der internen Konfigurationsdatenbank des Servers MASTER, also VIP_MED_ZEO.
  • IP Master HTTPS: reale Web-IP-Adresse des Mediation-Controller-Servers MASTER, also RIP_MED_WEB_MASTER.
  • IP Master SSL: reale IP-Adresse des SSL Router des Mediation-Controller-Servers MASTER, also RIP_MED_SSL_MASTER.
  • IP Slave HTTPS: reale Web-IP-Adresse des Mediation-Controller-Servers SLAVE, also RIP_MED_WEB_SLAVE.
  • IP Slave SSL: reale IP-Adresse des SSL Router des Mediation-Controller-Servers SLAVE, also RIP_MED_SSL_SLAVE.
  • HTML5 port: lokaler Lauschport für die Umleitung des Zugriffs auf den HTML5-Gateway-Dienst; wir empfehlen, den Port 1234 anzugeben.
  • Gateway: Name des Edge Gateway; geben Sie den Namen des ersten Edge Gateway an.
  • Organization: Name der Organisation, mit der sich die Edge Gateways und HTML5 Gateways verbinden.

Starten Sie nach Abschluss der Initialisierung den Server neu:

1
reboot

Ändern des Kennworts der Konsole /mediation/system von CyberElements Gate

In dieser Phase der Installation steht eine neue Administrationsoberfläche zur Verfügung: Kennwort ändern

Anwenden der Lizenzen und Zertifikate

Weiterhin in der Konsole /mediation/system müssen Sie die Zertifikate und Lizenzen des Mediation-Controller-Servers eingeben.

Achtung!

Lizenz und Zertifikat des SSL Router sind spezifisch für den Mediation-Controller-Server MASTER oder SLAVE.
Das Konfigurieren einer falschen Lizenz oder eines falschen Zertifikats führt später zu Fehlfunktionen.

Wenden Sie die Lizenz und das Zertifikat der Komponente SSL Router an:

  1. Klicken Sie auf die Registerkarte Settings.
  2. Wählen Sie im Menü SSL Connections aus.
  3. Suchen Sie das Zertifikat des SSL Router.
  4. Geben Sie das Kennwort des SSL-Router-Zertifikats ein.
  5. Klicken Sie auf Apply, um das Zertifikat auf den SSL Router anzuwenden.
  6. Wählen Sie die Lizenzdatei des Servers aus.
  7. Klicken Sie auf Modify, um die Lizenz des Servers anzuwenden.

Geben Sie anschließend die Informationen zum Zertifikat des CyberElements Bastion-Clients ein:

  1. Wählen Sie die Registerkarte Plugin aus.
  2. Suchen Sie das Zertifikat des CyberElements Bastion-Clients.
  3. Geben Sie das Kennwort des Zertifikats ein.
  4. Klicken Sie auf Apply, um das Zertifikat anzuwenden.

Es bleibt noch, die Informationen zum Watchdog-Zertifikat einzugeben:

  1. Wählen Sie die Registerkarte Watchdog aus
  2. Suchen Sie das Watchdog-Zertifikat.
  3. Geben Sie das Kennwort des Zertifikats ein.
  4. Klicken Sie auf Apply, um das Zertifikat anzuwenden.

Damit diese Änderungen wirksam werden, müssen Sie den SSL Router und den Watchdog neu starten:

Pairing der Mediation-Controller-Server

Achtung!

An diesem Punkt müssen beide Mediation-Controller-Server bis zum Anwenden der Lizenzen und Zertifikate konfiguriert worden sein.
Wenn der Mediation-Controller-Server SLAVE noch nicht konfiguriert ist, tun Sie dies, indem Sie am Anfang dieser Dokumentation beginnen.

Der Pairing-Schritt der Mediation-Controller-Server stellt eine Vertrauensbeziehung zwischen den beiden Servern her und initialisiert den Cluster-Betrieb.

Auf dem Mediation-Controller-Server SLAVE

Führen Sie den folgenden Befehl als root aus, um eine Pairing-Anfrage an den Mediation-Controller-Server MASTER zu senden:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Ersetzen Sie RIP_MED_WEB_MASTER durch die entsprechende IP-Adresse.

Beispiel

Wenn RIP_MED_WEB_MASTER gleich 10.0.10.10 ist, lautet der einzugebende Befehl wie folgt:

1
hostManagerCtl bootstrap 10.0.10.10

Auf dem Mediation-Controller-Server MASTER

Führen Sie den folgenden Befehl als root aus, um die ausstehenden Pairing-Anfragen anzuzeigen und die Kennung der Anfrage abzurufen: 

1
hostManagerCtl getPendingRequests

Führen Sie anschließend den folgenden Befehl aus, um die Pairing-Anfrage zu akzeptieren, und ersetzen Sie dabei ID durch die mit dem vorherigen Befehl abgerufene Kennung:

1
hostManagerCtl acceptRequest ID
Beispiel

Wenn das Ergebnis des Befehls hostManagerCtl getPendingRequests wie folgt lautet:

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

Dann lautet der Befehl zum Akzeptieren der Pairing-Anfrage wie folgt:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

Um die Zuordnung zu überprüfen, verwenden Sie den folgenden Befehl auf dem Mediation-Controller-Server (entweder MASTER oder SLAVE):

1
hostManagerCtl listPeers

Das Ergebnis unterscheidet sich je nach Server, auf dem der Befehl ausgeführt wird:

Das erwartete Ergebnis auf dem Mediation-Controller-Server MASTER lautet wie folgt:

1
slave -> RIP_MED_WEB_SLAVE
Beispiel 
1
slave -> 10.0.10.12

Das erwartete Ergebnis auf dem Mediation-Controller-Server SLAVE lautet wie folgt:

1
master -> RIP_MED_WEB_MASTER
Beispiel 
1
master -> 10.0.10.10

Auf dem Mediation-Controller-Server SLAVE

Sie können den Status des Bootstrap vom Server SLAVE aus mit dem folgenden Befehl prüfen:

1
hostManagerCtl getBootstrapStatus

Ein Cluster, der keine Synchronisierungsprobleme aufweist, gibt den Wert 0 zurück.

Eine letzte Reihe von Befehlen ist erforderlich, wiederum auf dem Server SLAVE, um ein zwischen beiden Mediation Controllern geteiltes Geheimnis zu synchronisieren:

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2
Wozu dient die Serververbindung?

Es handelt sich um eine besondere Verbindung des Cluster-Betriebs, die es einem Mediation-Controller-Server ermöglicht, den Datenverkehr an einen anderen Mediation-Controller-Server weiterzuleiten, wenn das Ziel-Edge-Gateway nicht mit dem ersten Server, sondern nur mit dem zweiten verbunden ist.

Wenn zum Beispiel der Mediation-Controller-Server MASTER nicht mehr mit dem Edge Gateway verbunden ist, kann er die Serververbindung nutzen, um es über den Mediation-Controller-Server SLAVE zu erreichen.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Verbindung verloren| GW(Edge Gateway)
    MASTER --> |Serverübergreifende Verbindung| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

Auf dem Mediation-Controller-Server MASTER

Bearbeiten Sie die Datei /etc/ipdiva/server/remoteServers.xml, um den CN des Serverzertifikats anzugeben:

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

Ersetzen Sie SLAVECN durch den CN des Zertifikats, das für die Serververbindung vorgesehen ist.
Wenn Sie den CN des Serverzertifikats nicht kennen, kann das Zeichen * eingegeben werden (im Zweifelsfall empfohlen):

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

Unter Berücksichtigung der folgenden Informationen:

  • CN des Serverzertifikats: my-interserver-cert

Die Datei /etc/ipdiva/server/remoteServers.xml des Mediation-Controller-Servers MASTER wäre wie folgt zu vervollständigen:

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"/>
                -->
Vollständige Datei 
 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>

Auf dem Mediation-Controller-Server SLAVE

Senden Sie das Serverzertifikat an den Mediation Controller SLAVE, in das Verzeichnis /tmp/.
Führen Sie anschließend die folgenden Befehle als root aus, um es mit den passenden Berechtigungen in das Zielverzeichnis zu verschieben:

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

Bearbeiten Sie anschließend die Datei /etc/ipdiva/server/remoteServers.xml, um dem Tag <remoteConfig> den folgenden Inhalt hinzuzufügen (das alte Tag <localCluster> kann vollständig gelöscht werden):

 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>

Ersetzen Sie:

  • MASTERCN: Geben Sie den CN des SSL-Router-Zertifikats des Mediation Controller MASTER an; dieser ist in der Regel RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER: entspricht der sekundären IP-Adresse des Mediation Controller MASTER.
  • PORT_RIP_MED_SSL_MASTER: Dies ist der Port, auf dem der SSL Router des Mediation Controller MASTER lauscht; in der Regel ist es 443.
  • INTERSERVER.P12: Name des Zertifikats, das für die Serververbindung vorgesehen ist.
  • PASSWORD: Kennwort des Serverzertifikats.
Beispiel

Unter Berücksichtigung der folgenden Informationen:

  • Name des Serverzertifikats: my-interserver-cert.p12
  • Kennwort des Serverzertifikats: MySecurePassword
  • RIP SSL des Mediation Controller MASTER: 10.0.10.11
  • Port auf der RIP SSL des Mediation Controller MASTER: 443
  • CN des Zertifikats des Mediation Controller MASTER: 10.0.10.11

Die Datei /etc/ipdiva/server/remoteServers.xml des Mediation-Controller-Servers SLAVE wäre wie folgt zu vervollständigen:

 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>
Vollständige Datei 
 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>

Ändern Sie die Konfiguration des SSL Router SLAVE, indem Sie den folgenden Befehl ausführen:

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

Auf den Mediation-Controller-Servern MASTER und SLAVE

Starten Sie den SSL Router neu, um die Konfiguration der Serververbindung anzuwenden:

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

Um zu bestätigen, dass die Serververbindung korrekt funktioniert, muss der folgende Befehl ein Ergebnis zurückgeben:

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

Der vorherige Befehl muss ein Protokoll mit dem folgenden Inhalt erzeugen: TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers, and 0 multicast group(s).
Wenn kein solches Protokoll angezeigt wird, prüfen Sie die in diesem Kapitel vorgenommene Konfiguration.

In der Webkonsole /mediation/system des Mediation Controller MASTER

Aktivieren Sie die Serververbindung zwischen den beiden Mediation Controllern, indem Sie den virtuellen SSL-Host default bearbeiten:

Füllen Sie die verschiedenen Felder anhand der nachstehenden Angaben aus und aktivieren Sie die Funktion der Serververbindung, indem Sie das Kontrollkästchen Is cross-server linking configured? markieren:

  • Public address for plugin connections: entspricht VIP_MED_SSL, gefolgt von seinem Lauschport (in der Regel 443).
  • Actual public IP addresses for web connections: entspricht dem Paar der realen Web-IP-Adressen (RIP_MED_WEB_MASTER und RIP_MED_WEB_SLAVE) mit ihren jeweiligen Ports, eine Zeile pro Paar aus IP-Adresse und Port.
  • Actual public IP addresses for SSL connections: entspricht dem Paar der realen SSL-IP-Adressen (RIP_MED_SSL_MASTER und RIP_MED_SSL_SLAVE) mit ihren jeweiligen Ports, eine Zeile pro Paar aus IP-Adresse und Port.

Initialisierung von CyberElements Bastion

Verbindung mit der PostgreSQL-Datenbank

Für seinen Betrieb benötigt CyberElements Bastion eine externe PostgreSQL-Datenbank (DB), um seine Konfiguration und die verschiedenen Protokolle der Konsole /system zu speichern.
Wenn die DB von den Mediation-Controller-Servern direkt erreichbar ist, gehen Sie direkt zum Schritt der Initialisierung der DB über.

Verbindung mit einer Datenbank im LAN

Um die Verbindung mit einer im LAN befindlichen Datenbank zu ermöglichen, ohne einen Fluss von der DMZ zum LAN zu öffnen, wird der Fluss der Datenbank über einen TLS-Tunnel zwischen den Edge Gateways und den Mediation Controllern umgeleitet.
Dazu muss ein Edge Gateway (oder zwei Edge Gateways) mit der zugrunde liegenden Technologie CyberElements Gate konfiguriert werden.

Deklaration der Edge Gateways CyberElements Gate

Melden Sie sich dazu zunächst an der Konsole /mediation/system von CyberElements Gate an.

Öffnen Sie anschließend das Menü „Organizations“ und klicken Sie auf „Add“:

Geben Sie den Namen der Organisation ein, der sich von dem für CyberElements Bastion vergebenen unterscheiden muss (zum Beispiel tunnel), und geben Sie mindestens eine Benutzersitzungslizenz sowie das Kennwort des Kontos admin an:

Melden Sie sich mit dem Konto admin an der Administrationsoberfläche der zuvor erstellten Organisation an, indem Sie /gate/admin aufrufen:

Deklarieren Sie anschließend die beiden Edge Gateways, die für den Aufbau des Tunnels verwendet werden.
Bewegen Sie den Zeiger links über Infrastructure, klicken Sie auf Gateways und anschließend auf die Schaltfläche Add:

Geben Sie den Namen des ersten Edge Gateway ein und bestätigen Sie die Eingabe:

Hinweis

Zur Erinnerung: Der Name eines Edge Gateway ist mit dem Zertifikat verknüpft, das es verwendet, um sich gegenüber dem SSL Router des Mediation Controller zu authentifizieren.
Dieser Name hat die folgende Form <GW_NAME>@<ORGANIZATION_NAME>, wobei <GW_NAME> dem Namen des Edge Gateway und <ORGANIZATION_NAME> dem Namen der in der Systemkonsole von CyberElements Gate erstellten Organisation entspricht.

Wiederholen Sie den Schritt der Deklaration für das zweite Edge Gateway.

Verbindungen und Konfiguration des Tunnels auf den Edge Gateways

Hinweis

Die folgenden Schritte können auf beiden Edge Gateways ausgeführt werden, die für den Tunnel zum Zugriff auf die Datenbank verwendet werden.

Voraussetzungen

Um diesen Teil abzuschließen, müssen Sie eine der beiden folgenden Möglichkeiten nutzen:

Verwenden Sie zunächst ein Werkzeug wie WinSCP oder FileZilla, um das für die Verbindung erforderliche Zertifikat per SCP in das Verzeichnis /tmp/ des Edge Gateway zu übertragen.

Verbinden Sie sich anschließend per SSH und wechseln Sie zu root.

Um das Edge Gateway mit beiden Mediation Controllern zu verbinden, müssen zwei neue Edge-Gateway-Instanzen erstellt werden: eine verbindet sich mit dem Mediation Controller MASTER, die andere mit dem Mediation Controller SLAVE.
Führen Sie zum Erstellen die folgenden Befehle aus:

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

Kopieren Sie die Zertifikatsdatei in die Verzeichnisse /etc/ipdiva/gateway-tunnel-master/ssl/ und /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/

Ersetzen Sie <CERT_NAME> durch den Namen des Zertifikats, das das Edge Gateway verwenden muss, um sich mit dem Mediation Controller zu verbinden.

Konfigurieren Sie die Edge-Gateway-Instanzen so, dass sie sich mit den Mediation Controllern verbinden können.
Die Konfigurationen unterscheiden sich je nach zu kontaktierendem Mediation Controller. Nehmen Sie beide Einstellungen vor:

Bearbeiten Sie die Datei /etc/ipdiva/gateway-tunnel-master/gateway.xml und vervollständigen Sie sie mit den folgenden Informationen (mehrere Abschnitte wurden ausgelassen und sind durch […] gekennzeichnet):

 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>

Ersetzen Sie die folgenden Elemente:

  • @SERVER@: muss durch die Adresse RIP_MED_SSL_MASTER ersetzt werden
  • @SERVERPORT@: muss durch den Lauschport des SSL Router ersetzt werden, normalerweise 443
  • keyfile.pem: muss durch den Namen der Zertifikatsdatei ersetzt werden
  • PASSWORD: muss durch das Kennwort des Zertifikats ersetzt werden
  • @RPC_PORT@: muss durch einen Port ersetzt werden, auf dem die Maschine derzeit nicht lauscht; der Port 9082 kann verwendet werden
Beispiel

Unter Berücksichtigung der folgenden Informationen:

  • RIP_MED_SSL_MASTER ist gleich: 10.0.10.11
  • Lauschport des SSL Router: 443
  • Name der Zertifikatsdatei: gate-tunnel.p12
  • Kennwort des Zertifikats: Str0ngP@ssw0rd

Die Datei /etc/ipdiva/gateway-tunnel-master/gateway.xml wäre wie folgt zu konfigurieren:

 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>
Vollständige Datei 
 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>

Bearbeiten Sie die Datei /etc/ipdiva/gateway-tunnel-slave/gateway.xml und vervollständigen Sie sie mit den folgenden Informationen (mehrere Abschnitte wurden ausgelassen und sind durch […] gekennzeichnet):

 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>

Ersetzen Sie die folgenden Elemente:

  • @SERVER@: muss durch die Adresse RIP_MED_SSL_SLAVE ersetzt werden
  • @SERVERPORT@: muss durch den Lauschport des SSL Router ersetzt werden, normalerweise 443
  • keyfile.pem: muss durch den Namen der Zertifikatsdatei ersetzt werden
  • PASSWORD: muss durch das Kennwort des Zertifikats ersetzt werden
  • @RPC_PORT@: muss durch einen Port ersetzt werden, der auf der Maschine derzeit nicht verwendet wird; der Port 9083 kann verwendet werden
Beispiel

Unter Berücksichtigung der folgenden Informationen:

  • RIP_MED_SSL_SLAVE ist gleich: 10.0.10.13
  • Lauschport des SSL Router: 443
  • Name der Zertifikatsdatei: gate-tunnel.p12
  • Kennwort des Zertifikats: Str0ngP@ssw0rd

Die Datei /etc/ipdiva/gateway-tunnel-slave/gateway.xml wäre wie folgt zu konfigurieren:

 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>
Vollständige Datei 
 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>

Nun, da die Instanzen für die Verbindung mit den Mediation Controllern konfiguriert sind, müssen sie noch so konfiguriert werden, dass sie die Verbindung des Mediation Controller zur Datenbank umleiten.
Bearbeiten Sie dazu die Datei /etc/ipdiva/gateway-tunnel-master/services.xml und ändern Sie sie wie folgt: 

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>

Ersetzen Sie DB_SERVER durch den DNS-Namen oder die IP-Adresse, die für die Verbindung mit der Datenbank verwendet wird, und DB_PORT durch den Lauschport der Datenbankinstanz.
Übernehmen Sie diese Konfiguration für die Instanz, die sich mit dem Mediation-Controller-Server SLAVE verbindet, indem Sie die Datei kopieren:

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

Starten Sie schließlich die Edge-Gateway-Instanzen, damit sie die Verbindung mit den Mediation Controllern herstellen:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Konfiguration des Tunnels auf den Mediation Controllern

Damit der Tunnel von den Mediation Controllern genutzt werden kann, muss noch seine Existenz deklariert werden.
Melden Sie sich dazu als root an den Mediation Controllern an und bearbeiten Sie die Datei /etc/ipdiva/server/services.xml, um den folgenden Abschnitt hinzuzufügen (mehrere Abschnitte wurden ausgelassen und sind durch […] gekennzeichnet):

 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>

Ersetzen Sie die folgenden Elemente:

  • GW1_NAME durch den Namen des ersten Edge Gateway
  • GW2_NAME durch den Namen des zweiten Edge Gateway
  • ORGANIZATION_NAME durch den Namen der zuvor erstellten Organisation CyberElements Gate
Beispiel

Unter Berücksichtigung der folgenden Informationen:

  • Name des Edge Gateway 1: gate-tunnel-1
  • Name des Edge Gateway 2: gate-tunnel-2
  • Name der Organisation CyberElements Gate: tunnel

Die Datei /etc/ipdiva/server/services.xml wäre wie folgt zu vervollständigen:

 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>
Vollständige Datei 
 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>

Um die neue Konfiguration anzuwenden, starten Sie den SSL Router mit dem folgenden Befehl neu:

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

Initialisierung der Datenbank

Achtung!

Sie müssen die Datenbank default erstellen, bevor CyberElements Bastion sie initialisiert (sie wird nicht automatisch erstellt).

Um die PostgreSQL-Datenbank der Systemkonfiguration zu initialisieren, müssen zunächst die Verbindungsparameter auf den Mediation Controllern konfiguriert werden.
Bearbeiten Sie dazu die Datei /etc/ipdiva/care/databasesettings.ini auf beiden Servern und fügen Sie die folgenden Einträge hinzu:

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

Ersetzen Sie die folgenden Elemente:

  • DB_USERNAME durch den Benutzernamen, der für die Verbindung mit der Datenbank verwendet wird.
  • DB_PWD durch das Kennwort des Benutzers, der sich verbindet.
  • DB_HOST durch die IP-Adresse oder den DNS-Namen, der für die Verbindung mit der Datenbank verwendet wird; wird eine Verbindung über Edge Gateways genutzt, ist 127.0.0.1 anzugeben.
  • DB_PORT durch den Port, der für die Verbindung mit der Datenbankinstanz verwendet wird; wird eine Verbindung über Edge Gateways genutzt, ist 1432 anzugeben.

Die Initialisierung der Datenbank kann mit den folgenden Befehlen gestartet werden, die nur auf einem Mediation Controller auszuführen sind:

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

Danach muss nur noch der Dienst apache2 auf beiden Mediation Controllern neu gestartet werden, um die Initialisierung der Systemdatenbank anzuwenden:

1
systemctl restart apache2

Konfiguration eines NTP-Zeitservers

Es wird empfohlen, einen Zeitserver einzurichten, um die Systemuhr aktuell zu halten. Die erforderlichen Schritte sind auf der Seite zur NTP-Konfiguration beschrieben.

Initiale Konfigurationen von CyberElements Bastion

Berechtigung für den Zugriff auf die Weboberflächen mit der virtuellen IP

Standardmäßig ist es nicht erlaubt, sich mit der virtuellen IP VIP_MED_WEB mit den Weboberflächen des Produkts CyberElements Bastion zu verbinden.
Um die Berechtigung hinzuzufügen, führen Sie als root die folgenden Befehle auf den Mediation Controllern aus:

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

Ersetzen Sie IP durch die IP-Adresse, die VIP_MED_WEB entspricht.

Initiale Konfigurationen

In dieser Phase sind die Mediation-Controller-Server installiert, es sind jedoch noch mehrere Aktionen erforderlich:

  • Die Standardkennwörter ändern

    Ändern Sie die Standardkennwörter der Systemkonsolen.

    Ändern

  • Die Zertifikate und Lizenzen installieren

    Der Mediation Controller benötigt verschiedene Zertifikate und eine Lizenz, um betriebsbereit zu sein.
    Nur das Zertifikat des Clients CyberElements Bastion muss auf beiden Mediation Controllern erneut deklariert werden (verwenden Sie die RIP RIP_MED_WEB_MASTER und RIP_MED_WEB_SLAVE).

    Die Zertifikate und die Lizenz installieren

  • Das Webzertifikat konfigurieren

    Konfigurieren Sie das Webzertifikat, das für die Verbindung mit den Weboberflächen verwendet wird

    Konfigurieren

  • Einen DNS-Namen deklarieren

    Fügen Sie einen DNS-Namen hinzu, der zur Verbindung mit den Weboberflächen berechtigt ist.

    Hinzufügen