Gå til indholdet

Installation af Mediation Controller-serverne

Bemærk

Til påmindelse: skift til root på Debian-maskiner skal ske med følgende kommando:

1
su -

Anvisningerne på denne side skal gentages på begge Mediation Controller-servere, begyndende med serveren MASTER.
Når der er forskelle mellem serverne MASTER og SLAVE, fremhæves de. Er der ingen omtale af det, gælder anvisningerne for både serveren MASTER og serveren SLAVE.

Systemkonfiguration

Forbindelse til maskinen

Som standard findes der to konti på de virtuelle appliances: en brugerkonto og en superbrugerkonto.

  • Brugerkonto
    • Login: systancia
    • Adgangskode: systnci
  • Superbrugerkonto
    • Login: root
    • Adgangskode: systnci

Forbind til maskinen i konsoltilstand.

Bemærk

Standardtastaturlayoutet er QWERTY.

Ændring af tastaturlayoutet

Du kan ændre tastaturlayoutet med følgende kommandolinje:

1
dpkg-reconfigure keyboard-configuration

Der vises en menu, hvor du kan vælge et andet tastaturlayout.

Brug derefter følgende kommandolinje til at anvende og gemme indstillingerne:

1
setupcon -k --save

Indstillingerne træder i kraft umiddelbart efter, at denne kommando er udført.

Konfiguration af netværket

Det er absolut nødvendigt at konfigurere en statisk netværksadresse til Mediation Controller. For at gøre det skal du først finde navnet på din maskines netværksinterface. Kør følgende kommando som root:

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

Denne kommando viser navnet på netværksinterfacet, dets status og de IP-adresser, der er tildelt interfacet.

Eksempel

Efter at kommandoen er udført, vises følgende output:

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

Navnet på netværksinterfacet er ens192.

Når navnet på netværksinterfacet er fundet, er det nu muligt at redigere maskinens netværkskonfiguration.
Rediger filen /etc/network/interfaces for at ændre den ud fra følgende skabelon:

 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

Hvor:

  • INTERFACE_NAME skal erstattes af navnet på det netværksinterface, der tidligere blev fundet.
  • RIP_MED_WEB_MASTER skal erstattes af serverens primære reelle IP-adresse; det er den IP-adresse, hvorigennem webkonsollerne kan nås.
  • NETMASK skal erstattes af den netværksmaske, der hører til IP-adressen.
  • NETWORK_GATEWAY skal erstattes af netværkets standardgateway.
  • IP_DNS skal erstattes af DNS-serverens IP-adresse. Hvis der skal konfigureres flere servere (højst 3), skal du adskille dem med et mellemrum.
  • DNS_SUFFIX skal erstattes af det DNS-suffiks, der skal bruges. Hvis der ikke skal angives noget suffiks, skal du slette linjen.
  • RIP_MED_SSL_MASTER skal erstattes af serverens sekundære reelle IP-adresse. Det er den IP-adresse, hvorigennem SSL Router kan nås.
Eksempel 
 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

Til sidst skal tjenesten networking blot genstartes, så den nye netværkskonfiguration indlæses: 

1
systemctl restart networking

Det er absolut nødvendigt at konfigurere en statisk netværksadresse til Mediation Controller. For at gøre det skal du først finde navnet på din maskines netværksinterface. Kør følgende kommando som root:

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

Denne kommando viser navnet på netværksinterfacet, dets status og de IP-adresser, der er tildelt interfacet.

Eksempel

Efter at kommandoen er udført, vises følgende output:

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

Navnet på netværksinterfacet er ens192.

Når navnet på netværksinterfacet er fundet, er det nu muligt at redigere maskinens netværkskonfiguration.
Rediger filen /etc/network/interfaces for at ændre den ud fra følgende skabelon:

 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

Hvor:

  • INTERFACE_NAME skal erstattes af navnet på det netværksinterface, der tidligere blev fundet.
  • RIP_MED_WEB_SLAVE skal erstattes af serverens primære reelle IP-adresse; det er den IP-adresse, hvorigennem webkonsollerne kan nås.
  • NETMASK skal erstattes af den netværksmaske, der hører til IP-adressen.
  • NETWORK_GATEWAY skal erstattes af netværkets standardgateway.
  • IP_DNS skal erstattes af DNS-serverens IP-adresse. Hvis der skal konfigureres flere servere (højst 3), skal du adskille dem med et mellemrum.
  • DNS_SUFFIX skal erstattes af det DNS-suffiks, der skal bruges. Hvis der ikke skal angives noget suffiks, skal du slette linjen.
  • RIP_MED_SSL_SLAVE skal erstattes af serverens sekundære reelle IP-adresse. Det er den IP-adresse, hvorigennem SSL Router kan nås.
Eksempel 
 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

Til sidst skal tjenesten networking blot genstartes, så den nye netværkskonfiguration indlæses: 

1
systemctl restart networking

Tip

Nu hvor netværkskonfigurationen er anvendt, kan serveren nås via SSH.

Ændring af adgangskoderne til de lokale konti

Systancia anbefaler kraftigt at ændre adgangskoden til disse konti, når den virtuelle appliance er udrullet.

Brug følgende kommando og indtast den nye adgangskode til standardkontoen systancia:

1
passwd systancia

Gentag derefter handlingen for superbrugerkontoen root:

1
passwd root

Konfiguration af maskinens navn

Du kan ændre serverens navn ved at konfigurere serverens filer hostname og hosts.

Rediger filen /etc/hostname for at angive maskinens navn.
Produktet har brug for det nye navn et andet sted, så der skal laves en kopi af den forrige fil med følgende kommando:

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

Konfigurationen af filen /etc/hosts skal gentages i forhold til maskinens reelle primære IP-adresse (RIP_MED_WEB_MASTER).
Rediger til det formål filen /etc/hosts, og kontrollér, at den anden linje har følgende format:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

Hvis maskinen hedder MEDIATION-CONTROLLER-MASTER uden at tilhøre et domæne, og dens reelle IP-adresse RIP_MED_WEB_MASTER er 10.0.10.10, skal filen udfyldes som følger:

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Hvis maskinen tilhører domænet DOMAIN.LOCAL, skal filen udfyldes som følger:

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

Konfigurationen af filen /etc/hosts skal gentages i forhold til maskinens reelle primære IP-adresse (RIP_MED_WEB_SLAVE).
Rediger til det formål filen /etc/hosts, og kontrollér, at den anden linje har følgende format:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

Hvis maskinen hedder MEDIATION-CONTROLLER-SLAVE uden at tilhøre et domæne, og dens reelle IP-adresse RIP_MED_WEB_SLAVE er 10.0.10.12, skal filen udfyldes som følger:

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Hvis maskinen tilhører domænet DOMAIN.LOCAL, skal filen udfyldes som følger:

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

For at anvende den nye konfiguration skal du genstarte serveren:

1
reboot

Ændring af tidszone

Som standard er den virtuelle appliance indstillet til tidszonen Europe/Paris.

For at ændre denne tidszone skal du først med følgende kommando hente skrivemåden for de tilgængelige tidszoner:

1
timedatectl list-timezones

Brug derefter følgende kommandolinje:

1
timedatectl set-timezone your_time_zone
Eksempel

For at indstille tidszonen til London skal følgende kommando udføres:

1
timedatectl set-timezone Europe/London

Kontrollér serverens tidszone med følgende kommandolinje:

1
timedatectl

Initialisering af Mediation Controller-serveren

Initialisering af Mediation Controller-serveren

Mediation Controller-serveren initialiseres ved hjælp af et konfigurationsscript. Dette script konfigurerer clusterets IP-adresser i produktets forskellige tjenester igen og forkonfigurerer de parametre, der er nødvendige for, at en HTML5 Gateway kan fungere.
Kør det med følgende kommandolinje som root:

1
/opt/systancia/initializeCluster

Scriptet beder dig om at indtaste følgende oplysninger:

  • IP VIP HTTPS: clusterets virtuelle web-IP-adresse, altså VIP_MED_WEB.
  • IP VIP SSL: clusterets virtuelle SSL-IP-adresse, altså VIP_MED_SSL.
  • IP VIP ZIO: virtuel IP-adresse for Mediation Controller-serveren SLAVEs forbindelse til den interne konfigurationsdatabase på serveren MASTER, altså VIP_MED_ZEO.
  • IP Master HTTPS: den reelle web-IP-adresse for Mediation Controller-serveren MASTER, altså RIP_MED_WEB_MASTER.
  • IP Master SSL: den reelle IP-adresse for SSL Router på Mediation Controller-serveren MASTER, altså RIP_MED_SSL_MASTER.
  • IP Slave HTTPS: den reelle web-IP-adresse for Mediation Controller-serveren SLAVE, altså RIP_MED_WEB_SLAVE.
  • IP Slave SSL: den reelle IP-adresse for SSL Router på Mediation Controller-serveren SLAVE, altså RIP_MED_SSL_SLAVE.
  • HTML5 port: lokal lytteport til omdirigering af adgangen til HTML5 Gateway-tjenesten; vi anbefaler at angive porten 1234.
  • Gateway: navnet på Edge Gateway; angiv navnet på den første Edge Gateway.
  • Organization: navnet på den organisation, som Edge Gateways og HTML5 Gateways forbinder til.

Genstart serveren, når initialiseringen er gennemført:

1
reboot

Ændring af adgangskoden til konsollen /mediation/system i CyberElements Gate

På dette trin i installationen er en ny administrationsgrænseflade tilgængelig: Skift adgangskode

Anvendelse af licenser og certifikater

Stadig i konsollen /mediation/system skal du indtaste certifikaterne og licenserne for Mediation Controller-serveren.

Vigtigt!

Licensen og certifikatet for SSL Router er specifikke for Mediation Controller-serveren MASTER eller SLAVE.
Hvis der konfigureres en forkert licens eller et forkert certifikat, medfører det fejlfunktioner senere.

Anvend licensen og certifikatet for komponenten SSL Router:

  1. Klik på fanen Settings.
  2. Vælg SSL Connections i menuen.
  3. Søg efter certifikatet til SSL Router.
  4. Indtast adgangskoden til SSL Router-certifikatet.
  5. Klik på Apply for at anvende certifikatet på SSL Router.
  6. Vælg serverens licensfil.
  7. Klik på Modify for at anvende serverens licens.

Indtast derefter oplysningerne om certifikatet til CyberElements Bastion-klienten:

  1. Vælg fanen Plugin.
  2. Søg efter certifikatet til CyberElements Bastion-klienten.
  3. Indtast adgangskoden til certifikatet.
  4. Klik på Apply for at anvende certifikatet.

Du skal stadig indtaste oplysningerne om Watchdog-certifikatet:

  1. Vælg fanen Watchdog
  2. Søg efter Watchdog-certifikatet.
  3. Indtast adgangskoden til certifikatet.
  4. Klik på Apply for at anvende certifikatet.

For at disse ændringer får virkning skal du genstarte SSL Router og Watchdog:

Pairing af Mediation Controller-serverne

Vigtigt!

På dette tidspunkt skal begge Mediation Controller-servere være konfigureret frem til anvendelse af licenser og certifikater.
Hvis Mediation Controller-serveren SLAVE endnu ikke er konfigureret, skal du gøre det ved at starte fra begyndelsen af denne dokumentation.

Trinnet med pairing af Mediation Controller-serverne etablerer en tillidsforbindelse mellem de to servere og initialiserer clusterdriften.

På Mediation Controller-serveren SLAVE

Kør følgende kommando som root for at sende en pairing-anmodning til Mediation Controller-serveren MASTER:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Erstat RIP_MED_WEB_MASTER med den relevante IP-adresse.

Eksempel

Hvis RIP_MED_WEB_MASTER er lig med 10.0.10.10, er kommandoen, der skal indtastes, som følger:

1
hostManagerCtl bootstrap 10.0.10.10

På Mediation Controller-serveren MASTER

Kør følgende kommando som root for at se de ventende pairing-anmodninger og hente anmodningens id: 

1
hostManagerCtl getPendingRequests

Kør derefter følgende kommando for at acceptere pairing-anmodningen, og erstat ID med det id, der blev hentet med den forrige kommando:

1
hostManagerCtl acceptRequest ID
Eksempel

Hvis resultatet af kommandoen hostManagerCtl getPendingRequests er som følger:

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

Så lyder kommandoen til at acceptere pairing-anmodningen som følger:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

For at kontrollere tilknytningen skal du bruge følgende kommando på Mediation Controller-serveren (enten MASTER eller SLAVE):

1
hostManagerCtl listPeers

Resultatet er forskelligt afhængigt af den server, som kommandoen udføres på:

Det forventede resultat på Mediation Controller-serveren MASTER er som følger:

1
slave -> RIP_MED_WEB_SLAVE
Eksempel 
1
slave -> 10.0.10.12

Det forventede resultat på Mediation Controller-serveren SLAVE er som følger:

1
master -> RIP_MED_WEB_MASTER
Eksempel 
1
master -> 10.0.10.10

På Mediation Controller-serveren SLAVE

Du kan kontrollere status for bootstrap fra serveren SLAVE med følgende kommando:

1
hostManagerCtl getBootstrapStatus

Et cluster uden synkroniseringsproblemer returnerer værdien 0.

Der kræves en sidste række kommandoer, igen på serveren SLAVE, for at synkronisere en hemmelighed, der deles mellem de to Mediation Controllere:

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2
Hvad er formålet med interserver-forbindelsen?

Det er en særlig forbindelse i clusterdriften, som gør det muligt for en Mediation Controller-server at videresende trafikken til en anden Mediation Controller-server i de tilfælde, hvor mål-Edge Gateway ikke er forbundet til den første server, men kun til den anden.

Hvis f.eks. Mediation Controller-serveren MASTER ikke længere er forbundet til Edge Gateway, kan den bruge interserver-forbindelsen til at nå Edge Gateway via Mediation Controller-serveren SLAVE.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Forbindelse mistet| GW(Edge Gateway)
    MASTER --> |Forbindelse mellem servere| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

På Mediation Controller-serveren MASTER

Rediger filen /etc/ipdiva/server/remoteServers.xml for at angive CN for interserver-certifikatet:

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

Erstat SLAVECN med CN for det certifikat, der er beregnet til interserver-forbindelsen.
Hvis du ikke kender CN for interserver-certifikatet, kan tegnet * indtastes (anbefales i tvivlstilfælde):

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

Med følgende oplysninger taget i betragtning:

  • CN for interserver-certifikatet: my-interserver-cert

Filen /etc/ipdiva/server/remoteServers.xml på Mediation Controller-serveren MASTER skal udfyldes som følger:

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"/>
                -->
Fuldstændig fil 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='interserver-documentation-cluster'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->

                <!-- in this example we use a custom certificate, it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl">
                                <cert>/etc/ipdiva/server/ssl/interserver.p12</cert>
                <password>s3cr3t</password>
                <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
                <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
                                <min-version>tls1.3</min-version>
                                <max-version></max-version>
                                <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
                                <cipherlist-tls1.3>TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256</cipherlist-tls1.3>
                <use-cn>no</use-cn>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
                <cert-peername>MASTERCN</cert-peername>
                        </remoteServer>
                -->
        </localCluster>

        <!--
                Intersites connections
        -->
        <intersites localSiteName='localSite1'>
                <!-- An accepted remote connection
                        name : the name of the accepted remote site
                        password : the associated password
                        pattern : a list of pattern of allowed peers for this remote site (separated by ;)
                -->
                <!-- <accept name='david-desktop' password='passwd' pattern='S:[^@]+@ipdiva'/> -->

                <!-- A connection to a remote site
                        name : is the name of the remoteSite
                        password : the password to use to connect
                        pattern : a list of pattern (regex) of the gateway that could be addressed via this link (separated by ;)
                        connect : a connection URL

                        the body can contain traditional TlsData parameters:
                            <cert>file.p12</cert>
                            <password>....</password>
                            <cadir>....</cadir>
                -->
                <!--
                        <remoteSite name='remoteSiteName'
                                        password='mypass'
                                        pattern='S:gw1@ipdiva;S:gw2@ipdiva'
                                        connect="192.168.0.168:9002" />
                -->
        </intersites>


</remoteConfig>

På Mediation Controller-serveren SLAVE

Send interserver-certifikatet til Mediation Controller SLAVE i mappen /tmp/.
Kør derefter følgende kommandoer som root for at flytte det til målmappen med de rette tilladelser:

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

Rediger derefter filen /etc/ipdiva/server/remoteServers.xml for at tilføje følgende indhold til tagget <remoteConfig> (det gamle tag <localCluster> kan slettes helt):

 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>

Erstat:

  • MASTERCN: angiv CN for SSL Router-certifikatet for Mediation Controller MASTER; det er normalt RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER: svarer til den sekundære IP-adresse for Mediation Controller MASTER.
  • PORT_RIP_MED_SSL_MASTER: det er den port, som SSL Router for Mediation Controller MASTER lytter på; det er normalt 443.
  • INTERSERVER.P12: navnet på det certifikat, der er beregnet til interserver-forbindelsen.
  • PASSWORD: adgangskoden til interserver-certifikatet.
Eksempel

Med følgende oplysninger taget i betragtning:

  • Navn på interserver-certifikatet: my-interserver-cert.p12
  • Adgangskode til interserver-certifikatet: MySecurePassword
  • RIP SSL for Mediation Controller MASTER: 10.0.10.11
  • Port på RIP SSL for Mediation Controller MASTER: 443
  • CN for certifikatet til Mediation Controller MASTER: 10.0.10.11

Filen /etc/ipdiva/server/remoteServers.xml på Mediation Controller-serveren SLAVE skal udfyldes som følger:

 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>
Fuldstændig fil 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='10.0.10.11'>
            <remoteServer connect="10.0.10.11:443:ssl">
                <cert>/etc/ipdiva/server/ssl/my-interserver-cert.p12</cert>
                <password>MySecurePassword</password>
                <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
                <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
                <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
                <use-cn>no</use-cn>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
                <cert-peername>10.0.10.11</cert-peername>
            </remoteServer>
        </localCluster>

        <!--
                Intersites connections
        -->
        <intersites localSiteName='localSite1'>
                <!-- An accepted remote connection
                        name : the name of the accepted remote site
                        password : the associated password
                        pattern : a list of pattern of allowed peers for this remote site (separated by ;)
                -->
                <!-- <accept name='david-desktop' password='passwd' pattern='S:[^@]+@ipdiva'/> -->

                <!-- A connection to a remote site
                        name : is the name of the remoteSite
                        password : the password to use to connect
                        pattern : a list of pattern (regex) of the gateway that could be addressed via this link (separated by ;)
                        connect : a connection URL

                        the body can contain traditional TlsData parameters:
                            <cert>file.p12</cert>
                            <password>....</password>
                            <cadir>....</cadir>
                -->
                <!--
                        <remoteSite name='remoteSiteName'
                                        password='mypass'
                                        pattern='S:gw1@ipdiva;S:gw2@ipdiva'
                                        connect="192.168.0.168:9002" />
                -->
        </intersites>


</remoteConfig>

Ændr konfigurationen af SSL Router SLAVE ved at køre følgende kommando:

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

På Mediation Controller-serverne MASTER og SLAVE

Genstart SSL Router for at anvende konfigurationen af interserver-forbindelsen:

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

For at bekræfte, at interserver-forbindelsen fungerer korrekt, skal følgende kommando returnere et resultat:

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

Den forrige kommando skal producere en log, der indeholder følgende: TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers, and 0 multicast group(s).
Hvis ingen sådan log vises, skal du kontrollere den konfiguration, der er foretaget i dette kapitel.

I webkonsollen /mediation/system for Mediation Controller MASTER

Slå interserver-forbindelsen mellem de to Mediation Controllere til ved at redigere den virtuelle SSL-host default:

Udfyld de forskellige felter ved hjælp af nedenstående anvisninger, og slå funktionen interserver-forbindelse til ved at markere afkrydsningsfeltet Is cross-server linking configured?:

  • Public address for plugin connections: svarer til VIP_MED_SSL efterfulgt af dens lytteport (normalt 443).
  • Actual public IP addresses for web connections: svarer til parret af reelle web-IP-adresser (RIP_MED_WEB_MASTER og RIP_MED_WEB_SLAVE) med deres tilsvarende porte, én linje pr. par af IP-adresse og port.
  • Actual public IP addresses for SSL connections: svarer til parret af reelle SSL-IP-adresser (RIP_MED_SSL_MASTER og RIP_MED_SSL_SLAVE) med deres tilsvarende porte, én linje pr. par af IP-adresse og port.

Initialisering af CyberElements Bastion

Forbindelse til PostgreSQL-databasen

For at fungere kræver CyberElements Bastion brug af en ekstern PostgreSQL-database (DB) til at lagre sin konfiguration og de forskellige logfiler i konsollen /system.
Hvis DB'en er direkte tilgængelig fra Mediation Controller-serverne, kan du gå direkte til trinnet med initialisering af DB'en.

Forbindelse til en database på LAN'et

For at gøre det muligt at forbinde til en database, der befinder sig på LAN'et, uden at åbne en trafikstrøm fra DMZ til LAN, omdirigeres databasens trafik gennem en TLS-tunnel mellem Edge Gateways og Mediation Controllerne.
Til det formål skal én Edge Gateway (eller to Edge Gateways) konfigureres ved hjælp af den underliggende CyberElements Gate-teknologi.

Deklaration af CyberElements Gate Edge Gateways

Log dertil først på konsollen /mediation/system i CyberElements Gate.

Gå derefter til menuen ”Organizations”, og klik på ”Add”:

Indtast organisationens navn, som skal være forskelligt fra det, der er tildelt CyberElements Bastion (for eksempel tunnel), og angiv mindst én brugersessionslicens samt adgangskoden til kontoen admin:

Log på administrationsgrænsefladen for den organisation, du tidligere har oprettet, med kontoen admin ved at gå til /gate/admin:

Deklarér derefter de to Edge Gateways, der skal bruges til at oprette tunnelen.
Til venstre skal du holde markøren over Infrastructure, klikke på Gateways og derefter på knappen Add:

Indtast navnet på den første Edge Gateway, og bekræft indtastningen:

Information

Til påmindelse: navnet på en Edge Gateway er knyttet til det certifikat, som den bruger til at godkende sig over for SSL Router på Mediation Controller.
Dette navn har følgende form <GW_NAME>@<ORGANIZATION_NAME>, hvor <GW_NAME> svarer til navnet på Edge Gateway, og hvor <ORGANIZATION_NAME> svarer til navnet på den organisation, der er oprettet i systemkonsollen i CyberElements Gate.

Gentag trinnet med deklaration af Edge Gateway for den anden Edge Gateway.

Forbindelser og konfiguration af tunnelen på Edge Gateways

Information

De følgende trin kan gentages på begge de Edge Gateways, der bruges til tunnelen for at få adgang til databasen.

Forudsætninger

For at gennemføre denne del skal du bruge en af følgende:

Brug først et værktøj som WinSCP eller FileZilla til at overføre det certifikat, der er nødvendigt for forbindelsen, til mappen /tmp/ på Edge Gateway via SCP.

Forbind derefter via SSH, og skift til root.

For at forbinde Edge Gateway til begge Mediation Controllere skal du oprette to nye Edge Gateway-instanser: den ene forbinder til Mediation Controller MASTER, den anden til Mediation Controller SLAVE.
Kør følgende kommandoer for at oprette dem:

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

Kopiér certifikatfilen til mapperne /etc/ipdiva/gateway-tunnel-master/ssl/ og /etc/ipdiva/gateway-tunnel-slave/ssl/:

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

Erstat <CERT_NAME> med navnet på det certifikat, som Edge Gateway skal bruge for at forbinde til Mediation Controller.

Konfigurér Edge Gateway-instanserne, så de kan forbinde til Mediation Controllerne.
Konfigurationerne er forskellige afhængigt af den Mediation Controller, der skal kontaktes. Foretag begge indstillinger:

Rediger filen /etc/ipdiva/gateway-tunnel-master/gateway.xml, og udfyld den med følgende oplysninger (flere afsnit er udeladt og markeret med […]):

 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>

Erstat følgende elementer:

  • @SERVER@: skal erstattes med adressen RIP_MED_SSL_MASTER
  • @SERVERPORT@: skal erstattes med SSL Routers lytteport, normalt sat til 443
  • keyfile.pem: skal erstattes med navnet på certifikatfilen
  • PASSWORD: skal erstattes med certifikatets adgangskode
  • @RPC_PORT@: skal erstattes med en port, som maskinen ikke lytter på i øjeblikket; porten 9082 kan bruges
Eksempel

Med følgende oplysninger taget i betragtning:

  • RIP_MED_SSL_MASTER er lig med: 10.0.10.11
  • Lytteport for SSL Router: 443
  • Navn på certifikatfilen: gate-tunnel.p12
  • Adgangskode til certifikatet: Str0ngP@ssw0rd

Filen /etc/ipdiva/gateway-tunnel-master/gateway.xml skal konfigureres som følger:

 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>
Fuldstændig fil 
 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>

Rediger filen /etc/ipdiva/gateway-tunnel-slave/gateway.xml, og udfyld den med følgende oplysninger (flere afsnit er udeladt og markeret med […]):

 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>

Erstat følgende elementer:

  • @SERVER@: skal erstattes med adressen RIP_MED_SSL_SLAVE
  • @SERVERPORT@: skal erstattes med SSL Routers lytteport, normalt sat til 443
  • keyfile.pem: skal erstattes med navnet på certifikatfilen
  • PASSWORD: skal erstattes med certifikatets adgangskode
  • @RPC_PORT@: skal erstattes med en port, der ikke er i brug på maskinen i øjeblikket; porten 9083 kan bruges
Eksempel

Med følgende oplysninger taget i betragtning:

  • RIP_MED_SSL_SLAVE er lig med: 10.0.10.13
  • Lytteport for SSL Router: 443
  • Navn på certifikatfilen: gate-tunnel.p12
  • Adgangskode til certifikatet: Str0ngP@ssw0rd

Filen /etc/ipdiva/gateway-tunnel-slave/gateway.xml skal konfigureres som følger:

 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>
Fuldstændig fil 
 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>

Nu hvor instanserne er konfigureret til at forbinde til Mediation Controllerne, skal de stadig konfigureres til at omdirigere Mediation Controllers forbindelse til databasen.
Rediger til det formål filen /etc/ipdiva/gateway-tunnel-master/services.xml, og ændr den som følger: 

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>

Erstat DB_SERVER med det DNS-navn eller den IP-adresse, der bruges til at forbinde til databasen, og DB_PORT med databaseinstansens lytteport.
Overfør denne konfiguration til den instans, der forbinder til Mediation Controller-serveren SLAVE, ved at kopiere filen:

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

Start til sidst Edge Gateway-instanserne, så de etablerer forbindelsen til Mediation Controllerne:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Konfiguration af tunnelen på Mediation Controllerne

For at tunnelen kan bruges af Mediation Controllerne, skal dens eksistens stadig deklareres.
Log dertil på Mediation Controllerne som root, og rediger filen /etc/ipdiva/server/services.xml for at tilføje følgende afsnit (flere afsnit er udeladt og markeret med […]):

 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>

Erstat følgende elementer:

  • GW1_NAME med navnet på den første Edge Gateway
  • GW2_NAME med navnet på den anden Edge Gateway
  • ORGANIZATION_NAME med navnet på den CyberElements Gate-organisation, der blev oprettet tidligere
Eksempel

Med følgende oplysninger taget i betragtning:

  • Navn på Edge Gateway 1: gate-tunnel-1
  • Navn på Edge Gateway 2: gate-tunnel-2
  • Navn på organisationen CyberElements Gate: tunnel

Filen /etc/ipdiva/server/services.xml skal udfyldes som følger:

 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>
Fuldstændig fil 
 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>

For at anvende den nye konfiguration skal du genstarte SSL Router med følgende kommando:

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

Initialisering af databasen

Vigtigt!

Du skal oprette databasen default, før CyberElements Bastion initialiserer den (den oprettes ikke automatisk).

For at initialisere PostgreSQL-databasen med systemkonfigurationen skal forbindelsesparametrene først konfigureres på Mediation Controllerne.
Rediger til det formål filen /etc/ipdiva/care/databasesettings.ini på begge servere, og tilføj følgende poster:

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

Erstat følgende elementer:

  • DB_USERNAME med det brugernavn, der bruges til at forbinde til databasen.
  • DB_PWD med adgangskoden for den bruger, der forbinder.
  • DB_HOST med den IP-adresse eller det DNS-navn, der bruges til at forbinde til databasen; hvis der bruges en forbindelse via Edge Gateways, skal du indtaste 127.0.0.1.
  • DB_PORT med den port, der bruges til at forbinde til databaseinstansen; hvis der bruges en forbindelse via Edge Gateways, skal du indtaste 1432.

Initialiseringen af databasen kan startes med følgende kommandoer, som kun må udføres på én Mediation Controller:

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

Derefter skal tjenesten apache2 blot genstartes på begge Mediation Controllere for at anvende initialiseringen af systemdatabasen:

1
systemctl restart apache2

Konfiguration af en NTP-tidsserver

Det anbefales at opsætte en tidsserver for at holde systemuret opdateret. De nødvendige trin er beskrevet på siden om NTP-konfiguration.

Indledende konfigurationer af CyberElements Bastion

Tilladelse til adgang til webgrænsefladerne med den virtuelle IP

Som standard er det ikke tilladt at forbinde til produktets CyberElements Bastion-webgrænseflader med den virtuelle IP VIP_MED_WEB.
For at tilføje tilladelsen skal du køre følgende kommandoer som root på Mediation Controllerne:

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

Erstat IP med den IP-adresse, der svarer til VIP_MED_WEB.

Indledende konfigurationer

På dette trin er Mediation Controller-serverne installeret, men der skal stadig udføres flere handlinger:

  • Ændr standardadgangskoderne

    Ændr standardadgangskoderne til systemkonsollerne.

    Ændr

  • Installér certifikaterne og licenserne

    Mediation Controller kræver forskellige certifikater og en licens for at være driftsklar.
    Kun certifikatet til CyberElements Bastion-klienten skal deklareres igen på begge Mediation Controllere (brug RIP'erne RIP_MED_WEB_MASTER og RIP_MED_WEB_SLAVE).

    Installér certifikaterne og licensen

  • Konfigurér webcertifikatet

    Konfigurér det webcertifikat, der bruges til at forbinde til webgrænsefladerne

    Konfigurér

  • Deklarér et DNS-navn

    Tilføj et DNS-navn, der har tilladelse til at forbinde til webgrænsefladerne.

    Tilføj