Zum Inhalt

Installation von Mediation Controller Server

Anmerkung

Als Erinnerung muss der Wechsel auf root auf Debian-Maschinen mit folgendem Befehl erfolgen:

1
su -

Die Anweisungen auf dieser Seite sollten auf beiden Mediation Controller-Servern repliziert werden, beginnend mit dem MASTER-Server.
Wenn Unterschiede zwischen den MASTER und SLAVE Servern auftreten, werden diese hervorgehoben. Wenn dies nicht erwähnt wird, gelten die Anweisungen sowohl für MASTER als auch für SLAVE Server.

Herunterladen des Spiegels und der notwendigen Werkzeuge

Der cyberelements Cleanroom 4.6-Spiegel und der Signaturschlüssel des Systancia-Repositoriums können von diesem Link heruntergeladen werden (erfordert die Erstellung eines Kundenkontos): Systancia Marketplace

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

  • Ein SSH-Client (unter Windows kann das PuTTY-Tool verwendet werden)
  • Ein SCP-Client (unter Windows können die WinSCP oder FileZilla-Tools verwendet werden)

Verwenden Sie den SSH-Client, um sich aus der Ferne mit Ihrem Server zu verbinden.

Übertrage mit dem SCP-Client Dateien auf deine Remote-Maschine.

Vorbereitung auf die Installation

Konfiguration des Netzes

Installieren Sie das resolvconf-Paket, damit die in der Konfigurationsdatei angegebene DNS-Konfiguration angewendet werden kann, die in Kürze geändert wird:

1
apt install -y resolvconf

Es ist zwingend erforderlich, eine statische Netzwerkadresse für die Mediation Controller zu definieren. Dazu müssen Sie zunächst den Namen der Netzwerkoberfläche Ihres Computers abrufen. Führen Sie den folgenden Befehl als root aus:

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

Dieser Befehl zeigt den Namen der Netzwerk-Schnittstelle, ihren Status und die IP-Adressen an, die der Schnittstelle zugewiesen sind.

Beispiel

Nach Ausführung des Befehls wird 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 Netzwerk-Schnittstelle ist ens192.

Sobald der Name der Netzwerkoberfläche ermittelt wurde, kann die Netzwerkkonfiguration der Maschine bearbeitet werden.
Bearbeiten Sie die /etc/network/interfaces-Datei, um sie mit 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

In welcher Hinsicht:

  • INTERFACE_NAME muss durch den Namen der zuvor abgerufenen Netzwerkschnittstelle ersetzt werden.
  • RIP_MED_WEB_MASTER muss durch die Haupt-IP-Adresse des Servers ersetzt werden, die IP-Adresse ist, über die auf die Web-Konsolen zugegriffen werden kann.
  • NETMASK muss durch die mit der IP-Adresse verbundene Netzmaske ersetzt werden.
  • NETWORK_GATEWAY muss durch das Standardnetzwerk-Gateway 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.
  • RIP_MED_SSL_MASTER muss durch die sekundäre reale IP-Adresse des Servers ersetzt werden. Dies ist die IP-Adresse, über die der SSL-Router zugänglich ist.
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 bleibt nur noch der networking-Dienst neu zu starten, um die neue Netzwerkkonfiguration zu laden:

1
systemctl restart networking

Es ist zwingend erforderlich, eine statische Netzwerkadresse für die Mediation Controller zu definieren. Dazu müssen Sie zunächst den Namen der Netzwerkoberfläche Ihres Computers abrufen. Führen Sie den folgenden Befehl als root aus:

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

Dieser Befehl zeigt den Namen der Netzwerk-Schnittstelle, ihren Status und die IP-Adressen an, die der Schnittstelle zugewiesen sind.

Beispiel

Nach Ausführung des Befehls wird 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 Netzwerk-Schnittstelle ist ens192.

Sobald der Name der Netzwerkoberfläche ermittelt wurde, kann die Netzwerkkonfiguration der Maschine bearbeitet werden.
Bearbeiten Sie die /etc/network/interfaces-Datei, um sie mit 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

In welcher Hinsicht:

  • INTERFACE_NAME muss durch den Namen der zuvor abgerufenen Netzwerkschnittstelle ersetzt werden.
  • RIP_MED_WEB_SLAVE muss durch die Haupt-IP-Adresse des Servers ersetzt werden, die IP-Adresse ist, über die auf die Web-Konsolen zugegriffen werden kann.
  • NETMASK muss durch die mit der IP-Adresse verbundene Netzmaske ersetzt werden.
  • NETWORK_GATEWAY muss durch das Standardnetzwerk-Gateway 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.
  • RIP_MED_SSL_SLAVE muss durch die sekundäre reale IP-Adresse des Servers ersetzt werden. Dies ist die IP-Adresse, über die der SSL-Router zugänglich ist.
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 bleibt nur noch der networking-Dienst neu zu starten, um die neue Netzwerkkonfiguration zu laden:

1
systemctl restart networking

Ein letzter Schritt bleibt: die interne Namensauflösung des Computers so zu ändern, dass sie seine tatsächliche primäre IP-Adresse (entsprechend RIP_MED_WEB_MASTER oder RIP_MED_WEB_SLAVE) auflöst.
Um dies zu tun, bearbeiten Sie die /etc/hosts-Datei und ersetzen Sie 127.0.1.1 durch RIP_MED_WEB_MASTER oder RIP_MED_WEB_SLAVE, je nach Mediation Controller-Server.

Example

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

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

Aufgepasst!

Eine falsche Konfiguration der Datei kann bei der Installation des collectd-Pakets zu einem Fehler führen.

Konfiguration des APT-Paketmanagers

Legen Sie die vom Systancia Marketplace abgerufenen Dateien mit einem SCP-Client auf den Server in /tmp/:

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

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

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 unnötiger Pakete beim Ausführen von apt Befehlen zu deaktivieren.

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

Überprüfung auf das Vorhandensein der en_US.utf8-Local

Die Installation des Mediation Controller-Servers erfordert die Generierung von en_US.utf8-Locals.
Um zu überprüfen, ob sie bereits auf dem Server erzeugt wurden, führen Sie den folgenden Befehl als root aus:

1
locale -a  | grep en_US.utf8

Wenn die Kommandowiedergabe en_US.utf8 anzeigt, geht zum nächsten Schritt der GRUB-Konfiguration über.
Wenn nicht, führen Sie die folgenden Befehle aus, um dieses Logeal dem Computer 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 GRUB-Startprogramms

Wenn diese Befehle ausgeführt sind, müssen Sie die Maschine nach einer Einstellung im GRUB-Startprogramm neu starten:

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

Installation des cyberelements Cleanroom Mediation Controller Servers

Einrichtung von Grundbauteilen

Installieren der Komponenten mit dem folgenden Befehl als root:

1
apt install -y ipdiva-base

Nach dem Herunterladen aller Abhängigkeiten wird ein Fenster geöffnet, in dem Sie aufgefordert werden, den Servertyp auszuwählen. mediation:

Dann wählen Sie den lbMaster Installationsmodus:

Dann wählen Sie den lbSlave Installationsmodus:

Dann müssen Sie den Port eingeben, auf dem der SSL-Router zuhört. Dieser Zuhörport ist normalerweise auf 443 eingestellt, aber der 8443 Port kann auch verwendet werden, wenn nur eine IP vom Mediationsserver verwendet wird:

Dann wird der Cluster-Modus auf loadbalancing eingestellt, so dass die Benutzerlast auf die beiden Mediation Controller-Server verteilt wird:

Angabe der virtuellen Web-IP-Adresse des Clusters, VIP_MED_WEB:

Die virtuelle SSL-IP-Adresse des Clusters ist VIP_MED_SSL anzugeben:

Die virtuelle IP-Adresse der Cluster-Konfigurationsdatenbank VIP_MED_ZEO wird eingegeben:

Die IP-Adresse des MASTER Mediation Controller, RIP_MED_WEB_MASTER ist wie folgt anzugeben:

Die IP-Adresse des MASTER Mediation Controller, RIP_MED_SSL_MASTER ist wie folgt anzugeben:

Die IP-Adresse des SLAVE Mediation Controller, RIP_MED_WEB_SLAVE ist wie folgt anzugeben:

Schließlich wird die tatsächliche IP-Webadresse der SLAVE Mediation Controller, RIP_MED_SSL_SLAVE eingegeben:

Was ist bei einem Fehler zu tun?

Wenn sich bei den eingegebenen Informationen ein Fehler befindet, setzen Sie die Installation des ipdiva-base-Pakets fort und verwenden Sie dann den folgenden Befehl, um den Server neu zu konfigurieren:

1
dpkg-reconfigure ipdiva-base

Einrichtung von Clusterkomponenten

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

1
apt install -y ipdiva-mediation-cluster

Nach der Installation der Komponenten ist ein Neustart erforderlich:

1
reboot

Konfiguration des Clusters

Änderung des Passworts der cyberelements Gate /mediation/system Konsole

In dieser Installationsphase steht eine neue Verwaltungsschnittstelle zur Verfügung: Passwort ändern

Anwendung von Lizenzen und Zertifikaten

In der /mediation/system-Konsole müssen Sie die Zertifikate und Lizenzen für den Mediation Controller-Server eingeben.

Aufgepasst!

Die SSL-Routerlizenz und das SSL-Zertifikat sind spezifisch für den MASTER oder SLAVE Mediation Controller Server.
Die Konfiguration der falschen Lizenz oder des falschen Zertifikats führt später zu Störungen.

Wenden Sie die Lizenz und das Zertifikat für die SSL-Router-Komponente an:

  1. Klicken Sie auf die Settings Registerkarte.
  2. Wählen Sie SSL Connections aus dem Menü.
  3. Suche nach dem Zertifikat für den SSL-Router.
  4. Geben Sie das Passwort für das SSL-Router-Zertifikat ein.
  5. Klicken Sie auf Apply, um das Zertifikat auf den SSL-Router anzuwenden.
  6. Wählen Sie die Serverlizenzdatei aus.
  7. Klicken Sie auf Modify, um die Serverlizenz anzuwenden.

Als nächstes geben Sie die Informationen für das Zertifikat für den cyberelements Cleanroom Client ein:

  1. Wählen Sie die Plugin Registerkarte aus.
  2. Suche nach dem cyberelements Cleanroom Client-Zertifikat.
  3. Geben Sie das Zertifikatspasswort ein.
  4. Klicken Sie auf Apply, um das Zertifikat anzuwenden.

Sie müssen dennoch die Angaben für das Watchdog-Zertifikat eingeben:

  1. Wählen Sie die Watchdog Registerkarte
  2. Suche nach dem Watchdog-Zertifikat.
  3. Geben Sie das Zertifikatspasswort 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:

Server für die Vermittlung von Übereinstimmungen

Aufgepasst!

In diesem Stadium müssen beide Mediation Controller-Server bis zum Punkt der Anwendung von Lizenzen und Zertifikaten konfiguriert sein.
Wenn der SLAVE Mediation Controller Server noch nicht konfiguriert wurde, gehen Sie bitte zum Anfang dieser Dokumentation zurück.

Der Schritt der Mediation Controller-Server-Paarung stellt eine vertrauenswürdige Verbindung zwischen den beiden Servern her und initialisiert den Cluster-Betrieb.

** Auf dem SLAVE Mediation Controller Server**

Führen Sie den folgenden Befehl als root aus, um eine Paarungsanforderung an den MASTER Mediation Controller Server zu erstellen:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

RIP_MED_WEB_MASTER durch die entsprechende IP-Adresse ersetzen.

Beispiel

Wenn RIP_MED_WEB_MASTER 10.0.10.10 entspricht, ist der Befehl zur Eingabe wie folgt:

1
hostManagerCtl bootstrap 10.0.10.10

** Auf dem MASTER Mediation Controller Server**

Führen Sie den folgenden Befehl als root aus, um auf ausstehende Paarungsanfragen zu prüfen und die Anforderungs-ID abzurufen:

1
hostManagerCtl getPendingRequests

Dann laufen Sie den folgenden Befehl aus, um die Paarungsanforderung zu akzeptieren, indem Sie ID durch die ID ersetzen, die mit dem vorherigen Befehl abgerufen wurde:

1
hostManagerCtl acceptRequest ID
Beispiel

Wenn der Befehl hostManagerCtl getPendingRequests folgendes zurückgibt:

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

Der Befehl zur Annahme der Paarungsanfrage lautet also wie folgt:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

Um die Assoziation zu überprüfen, verwenden Sie auf dem MASTER oder SLAVE Mediation Controller Server den folgenden Befehl:

1
hostManagerCtl listPeers

Das Ergebnis wird je nach Server, auf dem der Befehl ausgeführt wird, unterschiedlich sein:

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

1
slave -> RIP_MED_WEB_SLAVE
Beispiel

slave -> 10.0.10.12

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

1
master -> RIP_MED_WEB_MASTER
Beispiel

master -> 10.0.10.10

** Auf dem SLAVE Mediation Controller Server**

Sie können den Bootstrap-Status vom SLAVE-Server mit folgendem Befehl überprüfen:

1
hostManagerCtl getBootstrapStatus

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

Eine letzte Reihe von Befehlen ist erforderlich, wieder auf dem SLAVE Server, um ein Geheimnis zu synchronisieren, das zwischen beiden Mediation Controllers geteilt wird:

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2
Was ist der Zweck der Serververbindung?

Dies ist eine spezielle Verbindung für den Clusterbetrieb, die es einem Mediation Controller-Server ermöglicht, den Datenverkehr auf einen anderen Mediation Controller-Server zu leiten, wenn das Ziel Edge Gateway nicht mit dem ersten Server, sondern nur mit dem zweiten verbunden ist.

Zum Beispiel kann der MASTER Mediation Controller Server, wenn er nicht mehr mit dem Edge Gateway verbunden ist, die Interserver-Verbindung nutzen, um über den SLAVE Mediation Controller Server zum Edge Gateway zu gelangen.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Connection lost| GW(Edge Gateway)
    MASTER --> |Interserver link| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

** Auf dem MASTER Mediation Controller Server**

Bearbeiten Sie die /etc/ipdiva/server/remoteServers.xml-Datei, um die KN des Zertifikats zwischen den Servern 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"/>
                -->

SLAVECN wird durch die KN der für die Interserververbindung vorgesehenen Bescheinigung ersetzt.
Wenn Sie die KN des Zertifikats für den Interserver nicht kennen, können Sie das Zeichen * eingeben ( empfohlen, wenn Sie Zweifel haben):

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

Bereichsverteilung der folgenden Angaben:

  • Zertifikat für Interserver CN: my-interserver-cert

Die /etc/ipdiva/server/remoteServers.xml Datei auf dem Mediation Controller MASTER Server wie folgt ausgefüllt werden:

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
62
<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 SLAVE Mediation Controller Server**

Das Interserver-Zertifikat wird an die SLAVE Mediation Controller im Verzeichnis /tmp/ gesendet.
Dann laufen die folgenden Befehle als root, um es in das Zielverzeichnis mit den entsprechenden Berechtigungen 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

Als nächstes bearbeiten Sie die /etc/ipdiva/server/remoteServers.xml-Datei, um dem <remoteConfig>-Tag den folgenden Inhalt hinzuzufügen (das alte <localCluster>-Tag 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:

  • MASTERCN: die KN des SSL-Router-Zertifikats des MASTER Mediation Controller angeben, die in der Regel RIP_MED_SSL_MASTER ist.
  • RIP_MED_SSL_MASTER: entspricht der sekundären IP-Adresse des MASTER Mediation Controller.
  • PORT_RIP_MED_SSL_MASTER: entspricht dem Port, auf den der SSL-Router des MASTERMediation Controller-Servers hört, der normalerweise 443 ist.
  • INTERSERVER.P12: Name des für den Interserver vorgesehenen Zertifikats.
  • PASSWORD: Passwort für das Zertifikat zwischen den Servern.
Beispiel

Bereichsverteilung der folgenden Angaben:

  • Name des Zertifikats zwischen den Servern: my-interserver-cert.p12
  • Passwort für das Zertifikat zwischen den Servern: MySecurePassword
  • RIP SSL der Mediation Controller MASTER: 10.0.10.11
  • Port auf dem SSL-RIP des Mediation Controller MASTER: 443
  • KN des Mediation Controller MASTER Zeugnisses: 10.0.10.11

Die /etc/ipdiva/server/remoteServers.xml Datei auf dem Mediation Controller SLAVE Server wie folgt ausgefüllt werden:

 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
51
<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 SLAVE SSL-Router-Konfiguration durch Ausführen des folgenden Befehls:

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

Auf den MASTER und SLAVE Mediation Controller Servern

Starten Sie den SSL-Router neu, um die Interserver-Verbindungseinstellungen anzuwenden:

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

Um zu bestätigen, dass die Interserver-Verbindung ordnungsgemäß funktioniert, sollte der folgende Befehl ein Ergebnis zurückgeben:

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

Der vorherige Befehl sollte ein Protokoll mit diesem TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers and 0 multicast group(s) zurückgeben.
Wenn kein Protokoll dieses Typs angezeigt wird, überprüfen Sie die Konfiguration in diesem Kapitel.

**In der /mediation/system Web-Konsole der MASTER Mediation Controller **

Aktivieren Sie die Server-Zwischenverbindung zwischen beiden Mediation Controllers durch Bearbeiten des default SSL-Virtualhosts:

Konfigurieren Sie die verschiedenen Felder unter Verwendung der folgenden Informationen und aktivieren Sie die Funktion der Server-Verbindung, indem Sie den Cache Is interserver configured? überprüfen:

  • Public address for plugin connections: entspricht VIP_MED_SSL gefolgt von der Abhörschnittstelle (in der Regel 443).
  • Real IP addresses for web connections: entspricht dem realen Web-IP-Adresspaar (RIP_MED_WEB_MASTER und RIP_MED_WEB_SLAVE) mit dem entsprechenden Port, eine Zeile pro IP-Adresse und Portpaar.
  • Real IP addresses for SSL connections: entspricht dem echten SSL-IP-Adresspaar (RIP_MED_SSL_MASTER und RIP_MED_SSL_SLAVE) mit dem entsprechenden Port, einer Zeile pro IP-Adresse und Portpaar.

Installation spezifischer InternetElemente Cleanroom Teile

Beginnen Sie mit der Installation von cyberelements Cleanroom-Komponenten auf Mediation Controllers-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 zur PostgreSQL-Datenbank

Um zu funktionieren, benötigt cyberelements Cleanroom die Verwendung einer externen PostgreSQL-Datenbank (DB), um seine Einstellungen und verschiedene Protokolle in der /system Konsole zu speichern.
Wenn die DB direkt von den Mediation Controller Servern aus zugänglich ist, geht man direkt zum DB-Initialisierungsschritt über.

Verbindung zu einer Datenbank im LAN

Um eine Verbindung zu einer Datenbank im LAN zu ermöglichen, ohne eine DMZ zum LAN-Fluss zu öffnen, wird der Datenbankfluss durch einen TLS-Tunnel zwischen den Edge-Gateways und den Mediation-Controllern umgeleitet.
Um dies zu erreichen, ist es notwendig, ein Edge Gateway (oder zwei Edge Gateways) mit der zugrunde liegenden cyberelements Gate-Technologie zu konfigurieren.

Erklärung von cyberElementen Gate Edge Gateways

Um dies zu tun, melden Sie sich zunächst in der /mediation/system Konsole von cyberelements Gate an.

Dann gehen Sie zum Menü Organisationen und klicken Sie auf Add:

Geben Sie den Namen der Organisation ein, der sich von dem für cyberElemente Cleanroom bestimmten Namen unterscheiden muss (z. B. tunnel), definieren Sie mindestens eine Benutzer-Sitzungslizenz und das Passwort des admin Kontos:

Loggen Sie sich in die Verwaltungsschnittstelle der Organisation ein, die Sie zuvor mit dem admin Konto erstellt haben, und gehen Sie zu /gate/admin:

Dann deklarieren Sie beide Edge-Gateways, die zum Aufbau des Tunnels verwendet werden.
Auf der linken Seite, bewegen Sie den Mauszeiger über Infrastructure und klicken Sie auf Gateways, dann klicken Sie auf die Schaltfläche Add:

Name des ersten Edge Gateway und Bestätigung seiner Erklärung:

Info

Zur Erinnerung: Der Name eines Edge Gateway ist mit dem Zertifikat verknüpft, das er zur Authentifizierung mit dem SSL-Router des Mediation Controller verwendet.
Dieser Name hat die folgende Form <GW_NAME>@<ORGANIZATION_NAME>, wobei <GW_NAME> dem Namen des Edge Gateway entspricht und <ORGANIZATION_NAME> dem Organisationsnamen, der in der cyberelements Gate-Systemkonsole erstellt wurde, entspricht.

Wiederholen Sie den Edge Gateway-Erklärungsschritt für den zweiten Edge Gateway.

Tunnelverbindungen und Einstellungen an Rand-Gateways

Info

Die folgenden Schritte können auf beiden Edges-Gateways für den Tunnel zum Zugriff auf die Datenbank repliziert werden.

Voraussetzungen

Um diesen Teil abzuschließen, müssen Sie entweder:

Zunächst wird ein Werkzeug wie WinSCP oder FileZilla verwendet, um das Zertifikat zu senden, das die Verbindung zum Verzeichnis Edge Gateway/tmp/ über SCP ermöglicht.

Dann verbinden Sie über SSH und wechseln Sie zu root.

Um die Edge Gateway mit beiden Mediation Controllers zu verbinden, müssen Sie zwei neue Edge Gateway Instanzen erstellen, so dass sich eine mit der MASTER Mediation Controller verbindet, während sich die zweite mit der SLAVE Mediation Controller verbindet.
Um sie zu erstellen, führen Sie die folgenden Befehle aus:

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

Die Zertifikatsdatei wird in die Verzeichnisse /etc/ipdiva/gateway-tunnel-master/ssl/ und /etc/ipdiva/gateway-tunnel-slave/ssl/ kopiert:

1
2
cp /tmp/<CERT_NAME> /etc/ipdiva/gateway-tunnel-master/ssl/
cp /tmp/<CERT_NAME> /etc/ipdiva/gateway-tunnel-slave/ssl/

<CERT_NAME> durch den Namen des Zertifikats ersetzen, das Edge Gateway für die Verbindung mit Mediation Controller verwenden muss.

Die Edge Gateway-Instanzen so konfigurieren, dass sie sich mit den Mediation Controllers verbinden können.
Die Konfigurationen unterscheiden sich je nach dem zu kontaktierenden Mediation Controller.

Bearbeiten Sie die /etc/ipdiva/gateway-tunnel-master/gateway.xml-Datei und vervollständigen Sie sie mit den folgenden Informationen (einige Abschnitte wurden weggelassen und sind mit […] 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>

Folgende Elemente sind zu ersetzen:

  • @SERVER@: muss durch die Adresse RIP_MED_SSL_MASTER ersetzt werden
  • @SERVERPORT@: muss durch den Abhöranschluss des SSL-Routers ersetzt werden, der normalerweise auf 443 eingestellt ist
  • keyfile.pem: muss durch den Namen der Zertifikatsdatei ersetzt werden
  • PASSWORD: muss durch das Zertifikatspasswort ersetzt werden
  • @RPC_PORT@: muss durch einen Port ersetzt werden, der nicht auf der Maschine abhört; der Port 9082 kann verwendet werden
Beispiel

Bereichsverteilung der folgenden Angaben:

  • RIP_MED_SSL_MASTER ist gleich: 10.0.10.11
  • SSL Router-Listening-Port: 443
  • Name der Zertifikatsdatei: gate-tunnel.p12
  • Passwort für das Zertifikat: Str0ngP@ssw0rd

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

 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 /etc/ipdiva/gateway-tunnel-slave/gateway.xml-Datei und vervollständigen Sie sie mit den folgenden Informationen (einige Abschnitte wurden weggelassen und sind mit […] 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>

Folgende Elemente sind zu ersetzen:

  • @SERVER@: muss durch die Adresse RIP_MED_SSL_SLAVE ersetzt werden
  • @SERVERPORT@: muss durch den Abhöranschluss des SSL-Routers ersetzt werden, der normalerweise auf 443 eingestellt ist
  • keyfile.pem: muss durch den Namen der Zertifikatsdatei ersetzt werden
  • PASSWORD: muss durch das Zertifikatspasswort ersetzt werden
  • @RPC_PORT@: muss durch einen Port ersetzt werden, der nicht auf der Maschine abhört; der Port 9083 kann verwendet werden
Beispiel

Bereichsverteilung der folgenden Angaben:

  • RIP_MED_SSL_SLAVE ist gleich: 10.0.10.13
  • SSL Router-Listening-Port: 443
  • Name der Zertifikatsdatei: gate-tunnel.p12
  • Passwort für das Zertifikat: Str0ngP@ssw0rd

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

 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>

Die Instanzen sind nun konfiguriert, um eine Verbindung zu den Mediation Controllers herzustellen, aber sie müssen noch konfiguriert werden, um die Mediation Controller-Verbindung zur Datenbank umzuleiten.
Hierzu bearbeiten Sie die /etc/ipdiva/gateway-tunnel-master/services.xml-Datei 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 für die Verbindung zur Datenbank und DB_PORT durch den Abhör-Port der Datenbank-Instanz.
Replizieren Sie die Einstellungen für die Instanz, die sich mit dem SLAVE Mediation Controller Server verbindet, indem Sie die Datei kopieren:

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

Schließlich starten Sie die Edge Gateway-Instanzen, damit sie eine Verbindung zu den Mediation Controllers herstellen:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Konfiguration des Mediationskontrolltunnels

Damit der Tunnel für die Vermittlungskontrolleure nutzbar ist, müssen Sie ihre Existenz erklären.
Dazu loggen Sie sich als root bei den Mediation Controllers ein und bearbeiten Sie die /etc/ipdiva/server/services.xml Datei, um den folgenden Abschnitt hinzuzufügen (mehrere Abschnitte wurden weggelassen und sind mit […] 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>

Folgende Elemente sind zu ersetzen:

  • GW1_NAME nach dem Namen des ersten Edge Gateway
  • GW2_NAME durch den Namen des zweiten Edge Gateway
  • ORGANIZATION_NAME durch den Namen der zuvor erstellten cyberelements Gate-Organisation
Beispiel

Bereichsverteilung der folgenden Angaben:

  • Name von Edge Gateway 1: gate-tunnel-1
  • Name von Edge Gateway 2: gate-tunnel-2
  • Name der Organisation cyberelements Gate: tunnel

Die /etc/ipdiva/server/services.xml Die Datei wird wie folgt ausgefüllt:

 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>

Zur Anwendung der neuen Konfiguration starten Sie den SSL-Router mit dem folgenden Befehl neu:

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

Initialisierung der Datenbank

Um die PostgreSQL-Datenbank für die Systemkonfiguration zu initialisieren, müssen Sie zunächst die Verbindung mit ihr über die Mediation Controller deklarieren.
Um dies zu tun, bearbeiten Sie die /etc/ipdiva/care/databasesettings.ini Datei auf beiden Servern, um die folgenden Elemente einzugeben:

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

Folgende Elemente sind zu ersetzen:

  • DB_USERNAME durch den Benutzernamen, der zur Verbindung mit der Datenbank verwendet wird.
  • DB_PWD durch das Passwort des Anmelder.
  • DB_HOST durch die IP-Adresse oder den DNS-Namen, die zur Verbindung mit der Datenbank verwendet werden; wenn eine Verbindung über Edge Gateways verwendet wird, müssen Sie 127.0.0.1 eingeben.
  • DB_PORT durch den Port, der zur Verbindung mit der Datenbankinstance verwendet wird; wenn eine Verbindung über Edge Gateways verwendet wird, müssen Sie 1432 eingeben.

Die Datenbankinitialisierung kann mit folgenden Befehlen gestartet werden, , die nur auf Mediation Controller ausgeführt werden:

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

Danach bleibt nur noch der Apache2-Dienst ** auf beiden Mediation Controllern ** neu zu starten, um die Initialisierung der Systemdatenbank anzuwenden:

1
systemctl restart apache2

Installation von Treibern für die Verbindung mit Microsoft SQL-Datenbanken

Wenn Sie eine Verbindung zu einer externen Datenbank herstellen möchten, die ein Microsoft SQL Server ist, müssen zusätzliche ODBC-Treiber installiert sein.

Es gibt zwei Versionen: Version 17 und Version 18.

TLS-Verbindung erforderlich mit Treibern der Version 18

Die Verwendung von ODBC 18 Treibern erfordert, dass die Verbindung mit TLS verschlüsselt wird. MS SQL Server muss für die Verschlüsselung der Verbindung konfiguriert sein.

Bevor Sie mit der Installation der ODBC-Treiber beginnen, müssen Sie die notwendigen Pakete zur Vorbereitung installieren und dann das Microsoft-Repository für die Paketinstallation 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

Als nächstes installieren Sie die Treiber entsprechend der ausgewählten Version und konfigurieren Sie die Systemeinstellungen 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 zum Remote-Server ermöglichen:

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

In welcher Hinsicht:

  • SERVER sollte durch den DNS-Namen oder die IP-Adresse des MS SQL-Servers ersetzt werden.
  • INSTANCE_NAME sollte durch den Namen der Instanz ersetzt werden, mit der eine Verbindung hergestellt werden soll; falls dies nicht erforderlich ist, entfernen Sie auch den Rückschrägstrich.
  • PORT sollte durch den Anschlussanschluss zur MS SQL-Datenbankinstance ersetzt werden.
  • USER sollte durch den Benutzernamen für die Herstellung der Verbindung ersetzt werden.
Beispiele

Wenn der Mediation Controller Server über die IP-Adresse 10.0.10.100 auf einen MS SQL-Datenbankserver zugreifen kann, ist die zu erreichende Instanz auf dem Port 1433 ausgelauscht und das Zugriffskonto sql-user. Dann lautet der Verbindungsbefehl wie folgt:

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

Wenn die Verbindungsinstanz MSSQLINSTANCE angegeben werden müsste, würde der Befehl wie folgt geändert:

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

Konfiguration eines NTP-Zeitservers

Die erforderlichen Schritte sind auf der NTP-Konfigurationsseite beschrieben.

Anfängliche Konfigurationen auf CyberElementen Cleanroom

Zulassung des Zugriffs auf Web-Schnittstellen mit der virtuellen IP

Standardmäßig ist es nicht erlaubt, eine Verbindung zu den CyberElementen Cleanroom des Produkts mit der virtuellen IP VIP_MED_WEB herzustellen.
Um die Berechtigung hinzuzufügen, führen Sie als root die folgenden Befehle auf den Mediation Controllers aus:

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

IP wird durch die IP-Adresse ersetzt, die VIP_MED_WEB entspricht.

Anfängliche Konfigurationen

In dieser Phase sind die Mediation Controller-Server installiert, es müssen jedoch noch mehrere Aktionen ausgeführt werden:

  • Wechseln Sie die Standardpasswörter

    Ändern Sie die Standardpasswörter für die Systemkonsolen.

    Veränderung

  • Installieren von Zertifikaten und Lizenzen

    Die Mediation Controller erfordert verschiedene Zertifikate und eine Lizenz, um in Betrieb zu sein.
    Nur das Zertifikat für den CyberElement Cleanroom Client muss auf beiden Mediations Controllern erneut deklariert werden (verwenden Sie die RIP RIP_MED_WEB_MASTER und RIP_MED_WEB_SLAVE).

    Installieren von Zertifikaten und Lizenzen

  • Konfigurieren des Webzertifikats

    Konfigurieren des Webzertifikats, das zur Verbindung mit Web-Schnittstellen verwendet wird

    Konfigurieren

  • Erklären eines DNS-Namens

    Ein DNS-Name hinzufügen, der für die Verbindung mit Web-Schnittstellen autorisiert ist.

    Hinzufügen

  • Konfigurieren der Organisation

    Konfigurieren Sie die InternetElemente Cleanroom Organisation.

    Konfigurieren mit direktem Zugriff auf die Datenbank

    Konfiguration mit Zugriff auf die Datenbank über den Edge Gateways Tunnel

  • Deklarieren der Edge-Gateways

    Erklären Sie, dass das Edge Gateway (s) oder das HTML5-Gateway (s) installiert werden soll.

    Erstellen von Edge-Gateways

  • Erstellen einer logischen Website

    Erstellen und konfigurieren einer logischen Website, die Edge Gateways und HTML5-Gateways zusammenfasst, die auf lokale Ressourcen zugreifen können.

    Eine Website erstellen

  • Ein Edge Gateway installieren

    Ein neuer Edge Gateway mit den neu installierten Mediation Controller Servern installieren und konfigurieren.
    Eine HTML5-Gateway-Instanz wird ebenfalls konfiguriert.

    Installieren