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.

Herunterladen des Spiegels und der erforderlichen Werkzeuge

Der Spiegel CyberElements Cleanroom 4.6 und der Signaturschlüssel des Systancia-Repositorys können über diesen Link heruntergeladen werden (erfordert die Erstellung eines Kundenkontos): Systancia Marketplace

Zusätzlich zum Spiegel und zum Schlüssel werden für den Upgrade-Vorgang Werkzeuge von Drittanbietern benötigt:

  • Einen SSH-Client (unter Windows können Sie PuTTY verwenden)
  • Ein SCP-Client (unter Windows können die Werkzeuge WinSCP oder FileZilla verwendet werden)

Verwenden Sie den SSH-Client, um sich remote mit Ihrem Server zu verbinden.

Verwenden Sie den SCP-Client, um Dateien auf Ihre entfernte Maschine zu übertragen.

Vorbereitung der Installation

Konfiguration des Netzwerks

Installieren Sie das Paket resolvconf, damit die DNS-Konfiguration angewendet werden kann, die in der Datei angegeben ist, die als Nächstes geändert wird:

1
apt install -y resolvconf

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

Es bleibt ein letzter Schritt: die interne Namensauflösung der Maschine so zu ändern, dass sie ihre reale Haupt-IP-Adresse auflöst (entsprechend RIP_MED_WEB_MASTER oder RIP_MED_WEB_SLAVE).
Bearbeiten Sie dazu die Datei /etc/hosts und ersetzen Sie 127.0.1.1 je nach Mediation-Controller-Server durch RIP_MED_WEB_MASTER oder RIP_MED_WEB_SLAVE.

Example

Für einen Mediation-Controller-Server, dessen reale Web-IP-Adresse 10.0.10.10 und dessen Name mediation-controller.domain.local ist, hat die Datei /etc/hosts den folgenden Wert:

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

Achtung!

Eine fehlerhafte Konfiguration der Datei kann bei der Installation des Pakets collectd einen Fehler verursachen.

Konfiguration des Paketmanagers APT

Laden Sie die von Systancia Marketplace heruntergeladenen Dateien mit einem SCP-Client in das Verzeichnis /tmp/ des Servers hoch:

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

Melden Sie sich als root am Server an und führen Sie die folgenden Befehle aus, um das Systancia-Repository zu entpacken, seine Verwendung in APT zu konfigurieren und es zu authentifizieren.

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

Wir empfehlen dringend, die Installation nicht benötigter Pakete bei der Ausführung von apt-Befehlen zu deaktivieren. Führen Sie dazu den folgenden Befehl aus:

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

Prüfen, ob die Locale en_US.utf8 vorhanden ist

Für die Installation des Mediation-Controller-Servers müssen die Locales en_US.utf8 erzeugt werden.
Um zu prüfen, ob sie auf dem Server bereits erzeugt wurden, führen Sie den folgenden Befehl als root aus:

1
locale -a  | grep en_US.utf8

Wenn die Antwort des Befehls en_US.utf8 anzeigt, gehen Sie zum nächsten Schritt, der Konfiguration von GRUB, über.
Führen Sie andernfalls die folgenden Befehle aus, um diese Locale der Maschine hinzuzufügen:

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

Konfiguration des Bootloaders GRUB

Nach der Ausführung dieser Befehle müssen Sie die Maschine neu starten, nachdem Sie eine Einstellung im Bootloader GRUB vorgenommen haben:

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

Installation des Mediation-Controller-Servers von CyberElements Bastion

Installation der Basiskomponenten

Starten Sie die Installation der Komponenten mit dem folgenden Befehl als root:

1
apt install -y ipdiva-base

Nach dem Herunterladen aller Abhängigkeiten öffnet sich ein Fenster, in dem Sie den Servertyp auswählen müssen. Wählen Sie mediation:

Wählen Sie anschließend den Installationsmodus lbMaster:

Wählen Sie anschließend den Installationsmodus lbSlave:

Anschließend müssen Sie den Port angeben, auf dem der SSL Router lauscht. Dieser Lauschport ist in der Regel 443, es kann jedoch auch der Port 8443 verwendet werden, wenn der Mediation Controller nur eine IP verwendet:

Setzen Sie danach den Cluster-Modus auf loadbalancing, damit die Benutzerlast auf beide Mediation-Controller-Server verteilt wird:

Geben Sie die virtuelle Web-IP-Adresse des Clusters an, VIP_MED_WEB:

Geben Sie die virtuelle SSL-IP-Adresse des Clusters an, VIP_MED_SSL:

Geben Sie die virtuelle IP-Adresse der Konfigurationsdatenbank des Clusters an, VIP_MED_ZEO:

Geben Sie die reale Web-IP-Adresse des Mediation Controller MASTER an, RIP_MED_WEB_MASTER:

Geben Sie die reale SSL-IP-Adresse des Mediation Controller MASTER an, RIP_MED_SSL_MASTER:

Geben Sie die reale Web-IP-Adresse des Mediation Controller SLAVE an, RIP_MED_WEB_SLAVE:

Geben Sie schließlich die reale SSL-IP-Adresse des Mediation Controller SLAVE an, RIP_MED_SSL_SLAVE:

Was ist bei einem Fehler zu tun?

Wenn bei den eingegebenen Informationen ein Fehler aufgetreten ist, setzen Sie die Installation des Pakets ipdiva-base fort und verwenden Sie anschließend den folgenden Befehl, um den Server neu zu konfigurieren:

1
dpkg-reconfigure ipdiva-base

Installation der Cluster-Komponenten

Nach der Installation der Basiskomponenten müssen die Cluster-Komponenten auf den Mediation-Controller-Servern installiert werden:

1
apt install -y ipdiva-mediation-cluster

Nach der Installation der Komponenten ist ein Neustart erforderlich:

1
reboot

Konfiguration des Clusters

Ä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.

Installation der für CyberElements Bastion spezifischen Komponenten

Starten Sie die Installation der Komponenten von CyberElements Bastion auf den Mediation-Controller-Servern mit dem folgenden Befehl:

1
apt install -y ipdiva-safe-server

Die Server müssen neu gestartet werden, um die Installation abzuschließen:

1
reboot

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

Installation der Treiber für die Verbindung mit Microsoft-SQL-Datenbanken

Wenn Sie sich mit einer externen Datenbank verbinden möchten und es sich dabei um einen Microsoft SQL Server handelt, müssen zusätzliche ODBC-Treiber installiert werden.

Es sind zwei Versionen verfügbar: Version 17 und Version 18.

TLS-Verbindung für die Treiber in Version 18 erforderlich

Die Verwendung der ODBC-18-Treiber setzt voraus, dass die Verbindung mit TLS verschlüsselt ist. Dazu müssen Sie MS SQL Server für die Verschlüsselung der Verbindungen konfigurieren.

Bevor Sie mit der Installation der ODBC-Treiber beginnen, müssen Sie die für die Vorbereitung erforderlichen Pakete installieren und anschließend das Microsoft-Repository für die Installation der Pakete vorbereiten:

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

Installieren Sie anschließend die Treiber entsprechend der gewählten Version und konfigurieren Sie das System für die Verwendung des Befehls 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

Die ODBC-Treiber sind nun korrekt installiert.
Wenn der Mediation-Controller-Server Zugriff auf einen MS-SQL-Server hat, sollte der folgende Befehl die Verbindung mit dem entfernten Server ermöglichen: 

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

Dabei gilt:

  • SERVER muss durch den DNS-Namen oder die IP-Adresse des MS-SQL-Servers ersetzt werden.
  • INSTANCE_NAME muss durch den Namen der Instanz ersetzt werden, mit der sich verbunden werden soll; ist dies nicht erforderlich, entfernen Sie auch das Zeichen \.
  • PORT muss durch den Verbindungsport zur MS-SQL-Datenbankinstanz ersetzt werden.
  • USER muss durch den Benutzernamen ersetzt werden, mit dem die Verbindung hergestellt wird.
Beispiele

Wenn der Mediation-Controller-Server über die IP-Adresse 10.0.10.100 Zugriff auf einen MS-SQL-Datenbankserver hat, die betreffende Instanz auf dem Port 1433 lauscht und das Zugangskonto sql-user ist. Dann lautet der Verbindungsbefehl wie folgt:

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

Wenn die Verbindungsinstanz mit dem Namen MSSQLINSTANCE angegeben werden müsste, wäre der Befehl wie folgt zu ändern:

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

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

  • Die Organisation konfigurieren

    Konfigurieren Sie die Organisation von CyberElements Bastion.

    Mit direktem Zugriff auf die Datenbank konfigurieren

    Mit Zugriff auf die Datenbank über den Tunnel der Edge Gateways konfigurieren

  • Die Edge Gateways deklarieren

    Deklarieren Sie das oder die zu installierenden Edge Gateways bzw. HTML5 Gateways.

    Edge Gateways erstellen

  • Einen logischen Standort erstellen

    Erstellen und konfigurieren Sie einen logischen Standort, der die Edge Gateways und HTML5 Gateways zusammenfasst, die auf die lokalen Ressourcen zugreifen können.

    Einen Standort erstellen

  • Ein Edge Gateway installieren

    Installieren und konfigurieren Sie ein neues Edge Gateway mit den neu installierten Mediation-Controller-Servern.
    Es wird außerdem eine HTML5-Gateway-Instanz konfiguriert.

    Installieren