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.

Systemeinstellungen

Anschluss an die Maschine

Standardmäßig gibt es zwei Konten auf virtuellen Geräten: ein Benutzerkonto und ein Superbenutzerkonto.

  • Benutzerkonto
    • Einloggen: systancia
    • Passwort: systnci
  • Superbenutzerkonto
    • Einloggen: root
    • Passwort: systnci

Verbinden Sie sich mit der Maschine im Konsolenmodus.

Anmerkung

Das Standard-Tastaturlayout ist QWERTY.

Änderung des Tastaturlayouts

Konfiguration des Netzes

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

Tip

Nachdem die Netzwerkinstellungen angewendet wurden, kann über SSH auf den Server zugegriffen werden.

Änderung der Passwörter für lokale Konten

Konfiguration des Maschinennamens

Sie können den Servernamen ändern, indem Sie den Hostnamen des Servers und die Hosts-Dateien konfigurieren.

Bearbeiten Sie die /etc/hostname-Datei, um den Maschinennamen anzugeben.
Das Produkt benötigt den neuen Namen für einen anderen Speicherort, daher muss eine Kopie der vorherigen Datei mit dem folgenden Befehl erstellt werden:

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

Es ist notwendig, die Konfiguration der /etc/hosts-Datei in Bezug auf die tatsächliche primäre IP-Adresse der Maschine (RIP_MED_WEB_MASTER) zu replizieren.
Um dies zu tun, bearbeiten Sie die /etc/hosts-Datei und überprüfen Sie, ob die zweite Zeile im folgenden Format ist:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

Wenn der Rechner MEDIATION-CONTROLLER-MASTER heißt, ohne zu einer Domäne zu gehören, und seine RIP_MED_WEB_MASTER tatsächliche IP-Adresse 10.0.10.10 ist, dann würde die Datei wie folgt ausgefüllt:

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Wenn die Maschine der DOMAIN.LOCAL-Domäne angehört, wird die Datei wie folgt ausgefüllt:

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

Es ist notwendig, die Konfiguration der /etc/hosts-Datei in Bezug auf die tatsächliche primäre IP-Adresse der Maschine (RIP_MED_WEB_SLAVE) zu replizieren.
Um dies zu tun, bearbeiten Sie die /etc/hosts-Datei und überprüfen Sie, ob die zweite Zeile im folgenden Format ist:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

Wenn der Rechner MEDIATION-CONTROLLER-SLAVE heißt, ohne zu einer Domäne zu gehören, und seine RIP_MED_WEB_SLAVE tatsächliche IP-Adresse 10.0.10.12 ist, dann würde die Datei wie folgt ausgefüllt:

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Wenn die Maschine der DOMAIN.LOCAL-Domäne angehört, wird die Datei wie folgt ausgefüllt:

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

Zur Anwendung der neuen Konfiguration startet der Server neu:

1
reboot

Änderung der Zeitzone

Initialisierung der Mediation Controller Server

Initialisierung der Mediation Controller Server

Der Mediation Controller-Server wird mit einem Konfigurationsskript initialisiert. Dieses Skript konfiguriert die IP-Adressen des Clusters in den verschiedenen Diensten des Produkts neu und konfiguriert die Einstellungen vor, die für die Funktionsfähigkeit eines HTML5-Gateways erforderlich sind.
Führen Sie es über die folgende Befehlszeile als root aus:

1
/opt/systancia/initializeCluster

Das Skript fordert Sie auf, folgende Informationen einzugeben:

  • IP VIP HTTPS: virtuelle Web-IP-Adresse des Clusters, die VIP_MED_WEB ist.
  • IP VIP SSL: virtuelle SSL-IP-Adresse des Clusters, die VIP_MED_SSL ist.
  • IP VIP ZIO: virtuelle IP-Adresse für die SLAVEMediation Controller-Serververbindung zur internen Konfigurationsdatenbank des MASTER-Servers, die VIP_MED_ZEO ist.
  • IP Master HTTPS: Die tatsächliche Web-IP-Adresse des MASTERMediation Controller-Servers, die RIP_MED_WEB_MASTER ist.
  • IP Master SSL: Die tatsächliche IP-Adresse des SSL-Routers des MASTERMediation Controller-Servers, die RIP_MED_SSL_MASTER ist.
  • IP Slave HTTPS: Die tatsächliche Web-IP-Adresse des SLAVEMediation Controller-Servers, die RIP_MED_WEB_SLAVE ist.
  • IP Slave SSL: Die tatsächliche IP-Adresse des SSL-Routers des SLAVEMediation Controller-Servers, die RIP_MED_SSL_SLAVE ist.
  • HTML5 port: lokaler Abhör-Port zur Umleitung des Zugriffs auf den HTML5-Gateway-Dienst; wir empfehlen, den Port 1234 einzugeben.
  • Gateway: Name des Edge Gateway; Name des ersten Edge Gateway.
  • Organization: Name der Organisation, mit der die Edge-Gateways und HTML5-Gateways verbunden werden.

Nach Abschluss der Initialisierung wird der Server neu gestartet:

1
reboot

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

Mediation Controller Serverpaarung

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.

Initialisierung von CyberElementen Cleanroom

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

Konfiguration eines NTP-Zeitservers

Die erforderlichen Schritte sind auf der NTP-Konfigurationsseite beschrieben.

Anfängliche Konfigurationen von 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