Gå til innhold

Installasjon av Mediation Controller-serverne

Merk

Til påminnelse: bytte til root på Debian-maskiner må gjøres med følgende kommando:

1
su -

Instruksjonene på denne siden skal utføres på begge Mediation Controller-serverne, og du begynner med serveren MASTER.
Når det finnes forskjeller mellom serverne MASTER og SLAVE, blir de framhevet. Hvis ingenting er nevnt, gjelder instruksjonene både for serveren MASTER og for serveren SLAVE.

Systeminnstillinger

Tilkobling til maskinen

Som standard finnes det to kontoer på virtuelle appliances: en brukerkonto og en superbrukerkonto.

  • Brukerkonto
    • Pålogging : systancia
    • Passord: systnci
  • Superbrukerkonto
    • Pålogging : root
    • Passord: systnci

Koble deg til maskinen i konsollmodus.

Merk

Standard tastaturoppsett er QWERTY.

Endre tastaturoppsettet

Du kan endre tastaturoppsettet med følgende kommandolinje:

1
dpkg-reconfigure keyboard-configuration

Det vises en meny der du kan velge et annet tastaturoppsett.

Bruk deretter følgende kommandolinje for å bruke og lagre innstillingene:

1
setupcon -k --save

Innstillingene får virkning umiddelbart etter at denne kommandoen er kjørt.

Konfigurasjon av nettverket

Det er helt nødvendig å konfigurere en statisk nettverksadresse for Mediation Controller. Først må du hente navnet på nettverksgrensesnittet til maskinen. Kjør følgende kommando som root:

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

Denne kommandoen viser navnet på nettverksgrensesnittet, statusen til det og IP-adressene som er tilordnet grensesnittet.

Eksempel

Etter at kommandoen er kjørt, vises følgende utdata:

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å nettverksgrensesnittet er ens192.

Når navnet på nettverksgrensesnittet er hentet, er det nå mulig å redigere nettverkskonfigurasjonen for maskinen.
Rediger filen /etc/network/interfaces for å endre den etter følgende mal:

 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

Der:

  • INTERFACE_NAME må erstattes med navnet på nettverksgrensesnittet som ble hentet tidligere.
  • RIP_MED_WEB_MASTER må erstattes med den reelle hoved-IP-adressen til serveren, som blir IP-adressen webkonsollene kan nås gjennom.
  • NETMASK må erstattes med nettverksmasken som hører til IP-adressen.
  • NETWORK_GATEWAY må erstattes med standardgatewayen for nettverket.
  • IP_DNS må erstattes med IP-adressen til DNS-serveren. Hvis flere servere må konfigureres (maksimalt 3), skiller du dem med et mellomrom.
  • DNS_SUFFIX må erstattes med DNS-suffikset som skal brukes. Hvis det ikke er noe suffiks å angi, sletter du linjen.
  • RIP_MED_SSL_MASTER må erstattes med den reelle sekundære IP-adressen til serveren. Dette blir IP-adressen SSL Router kan nås gjennom.
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 slutt gjenstår det bare å starte tjenesten networking på nytt for å laste inn den nye nettverkskonfigurasjonen: 

1
systemctl restart networking

Det er helt nødvendig å konfigurere en statisk nettverksadresse for Mediation Controller. Først må du hente navnet på nettverksgrensesnittet til maskinen. Kjør følgende kommando som root:

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

Denne kommandoen viser navnet på nettverksgrensesnittet, statusen til det og IP-adressene som er tilordnet grensesnittet.

Eksempel

Etter at kommandoen er kjørt, vises følgende utdata:

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å nettverksgrensesnittet er ens192.

Når navnet på nettverksgrensesnittet er hentet, er det nå mulig å redigere nettverkskonfigurasjonen for maskinen.
Rediger filen /etc/network/interfaces for å endre den etter følgende mal:

 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

Der:

  • INTERFACE_NAME må erstattes med navnet på nettverksgrensesnittet som ble hentet tidligere.
  • RIP_MED_WEB_SLAVE må erstattes med den reelle hoved-IP-adressen til serveren, som blir IP-adressen webkonsollene kan nås gjennom.
  • NETMASK må erstattes med nettverksmasken som hører til IP-adressen.
  • NETWORK_GATEWAY må erstattes med standardgatewayen for nettverket.
  • IP_DNS må erstattes med IP-adressen til DNS-serveren. Hvis flere servere må konfigureres (maksimalt 3), skiller du dem med et mellomrom.
  • DNS_SUFFIX må erstattes med DNS-suffikset som skal brukes. Hvis det ikke er noe suffiks å angi, sletter du linjen.
  • RIP_MED_SSL_SLAVE må erstattes med den reelle sekundære IP-adressen til serveren. Dette blir IP-adressen SSL Router kan nås gjennom.
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 slutt gjenstår det bare å starte tjenesten networking på nytt for å laste inn den nye nettverkskonfigurasjonen: 

1
systemctl restart networking

Tips

Nå som nettverksinnstillingene er tatt i bruk, kan serveren nås via SSH.

Endre passordene for de lokale kontoene

Systancia anbefaler på det sterkeste å endre passordet for disse kontoene når den virtuelle appliancen er rullet ut.

Bruk følgende kommando og skriv inn det nye passordet for standardkontoen systancia:

1
passwd systancia

Gjenta deretter operasjonen for superbrukerkontoen root:

1
passwd root

Konfigurere maskinnavnet

Du kan endre navnet på serveren ved å konfigurere filene hostname og hosts på serveren.

Rediger filen /etc/hostname for å angi navnet på maskinen.
Produktet trenger det nye navnet på et annet sted, så det må lages en kopi av den forrige filen med følgende kommando:

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

Konfigurasjonen av filen /etc/hosts må gjentas med hensyn til den reelle hoved-IP-adressen til maskinen (RIP_MED_WEB_MASTER).
For å gjøre det redigerer du filen /etc/hosts og kontrollerer at den andre linjen har følgende format:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

Hvis maskinen heter MEDIATION-CONTROLLER-MASTER uten å tilhøre et domene, og den reelle IP-adressen RIP_MED_WEB_MASTER er 10.0.10.10, fylles filen ut slik:

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Hvis maskinen tilhører domenet DOMAIN.LOCAL, fylles filen ut slik:

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

Konfigurasjonen av filen /etc/hosts må gjentas med hensyn til den reelle hoved-IP-adressen til maskinen (RIP_MED_WEB_SLAVE).
For å gjøre det redigerer du filen /etc/hosts og kontrollerer at den andre linjen har følgende format:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

Hvis maskinen heter MEDIATION-CONTROLLER-SLAVE uten å tilhøre et domene, og den reelle IP-adressen RIP_MED_WEB_SLAVE er 10.0.10.12, fylles filen ut slik:

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Hvis maskinen tilhører domenet DOMAIN.LOCAL, fylles filen ut slik:

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

For å ta i bruk den nye konfigurasjonen starter du serveren på nytt:

1
reboot

Endring av tidssone

Som standard er den virtuelle appliancen satt til tidssonen Europe/Paris.

For å endre denne tidssonen henter du først skrivemåten for de tilgjengelige tidssonene med følgende kommando:

1
timedatectl list-timezones

Bruk deretter følgende kommandolinje:

1
timedatectl set-timezone your_time_zone
Eksempel

For å sette tidssonen til London må følgende kommando kjøres:

1
timedatectl set-timezone Europe/London

Kontroller tidssonen til serveren med følgende kommandolinje:

1
timedatectl

Initialisering av Mediation Controller-serveren

Initialisering av Mediation Controller-serveren

Mediation Controller-serveren initialiseres ved hjelp av et konfigurasjonsskript. Dette skriptet konfigurerer IP-adressene til clusteret på nytt i de ulike tjenestene i produktet og forhåndskonfigurerer innstillingene som kreves for at en HTML5 Gateway skal fungere.
Kjør det med følgende kommandolinje som root:

1
/opt/systancia/initializeCluster

Skriptet ber deg skrive inn følgende informasjon:

  • IP VIP HTTPS: virtuell web-IP-adresse for clusteret, altså VIP_MED_WEB.
  • IP VIP SSL: virtuell SSL-IP-adresse for clusteret, altså VIP_MED_SSL.
  • IP VIP ZIO: virtuell IP-adresse for tilkoblingen fra Mediation Controller-serveren SLAVE til den interne konfigurasjonsdatabasen på serveren MASTER, altså VIP_MED_ZEO.
  • IP Master HTTPS: den reelle web-IP-adressen til Mediation Controller-serveren MASTER, altså RIP_MED_WEB_MASTER.
  • IP Master SSL: den reelle IP-adressen for SSL Router på Mediation Controller-serveren MASTER, altså RIP_MED_SSL_MASTER.
  • IP Slave HTTPS: den reelle web-IP-adressen til Mediation Controller-serveren SLAVE, altså RIP_MED_WEB_SLAVE.
  • IP Slave SSL: den reelle IP-adressen for SSL Router på Mediation Controller-serveren SLAVE, altså RIP_MED_SSL_SLAVE.
  • HTML5 port: lokal lytteport for videresending av tilgangen til HTML5 Gateway-tjenesten; vi anbefaler å angi porten 1234.
  • Gateway: navnet på Edge Gateway; angi navnet på den første Edge Gateway.
  • Organization: navnet på organisasjonen som Edge Gateway-serverne og HTML5 Gateway-serverne kobler seg til.

Når initialiseringen er fullført, starter du serveren på nytt:

1
reboot

Endre passordet for konsollet /mediation/system i CyberElements Gate

På dette stadiet av installasjonen er et nytt administrasjonsgrensesnitt tilgjengelig: Endre passord

Bruk av lisenser og sertifikater

Fortsatt i konsollet /mediation/system må du legge inn sertifikatene og lisensene for Mediation Controller-serveren.

OBS!

Lisensen og sertifikatet for SSL Router er spesifikke for Mediation Controller-serveren MASTER eller SLAVE.
Å konfigurere feil lisens eller feil sertifikat vil føre til feilfunksjoner senere.

Bruk lisensen og sertifikatet for komponenten SSL Router:

  1. Klikk på fanen Settings.
  2. Velg SSL Connections i menyen.
  3. Søk etter sertifikatet for SSL Router.
  4. Skriv inn passordet for SSL Router-sertifikatet.
  5. Klikk på Apply for å bruke sertifikatet på SSL Router.
  6. Velg lisensfilen for serveren.
  7. Klikk på Modify for å bruke serverlisensen.

Legg deretter inn sertifikatinformasjonen for CyberElements Bastion-klienten:

  1. Velg fanen Plugin.
  2. Søk etter sertifikatet for CyberElements Bastion-klienten.
  3. Skriv inn passordet for sertifikatet.
  4. Klikk på Apply for å bruke sertifikatet.

Det gjenstår å legge inn informasjonen for Watchdog-sertifikatet:

  1. Velg fanen Watchdog
  2. Søk etter Watchdog-sertifikatet.
  3. Skriv inn passordet for sertifikatet.
  4. Klikk på Apply for å bruke sertifikatet.

For at disse endringene skal tre i kraft, må du starte SSL Router og Watchdog på nytt:

Pairing av Mediation Controller-serverne

OBS!

På dette punktet må begge Mediation Controller-serverne være konfigurert til og med bruk av lisenser og sertifikater.
Hvis Mediation Controller-serveren SLAVE ennå ikke er konfigurert, gjør du det ved å begynne fra starten av denne dokumentasjonen.

Trinnet for pairing av Mediation Controller-serverne oppretter en tillitsforbindelse mellom de to serverne og initialiserer cluster-driften.

På Mediation Controller-serveren SLAVE

Kjør følgende kommando som root for å sende en pairing-forespørsel til Mediation Controller-serveren MASTER:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Erstatt RIP_MED_WEB_MASTER med den aktuelle IP-adressen.

Eksempel

Hvis RIP_MED_WEB_MASTER er lik 10.0.10.10, er kommandoen som skal skrives inn, følgende:

1
hostManagerCtl bootstrap 10.0.10.10

På Mediation Controller-serveren MASTER

Kjør følgende kommando som root for å vise ventende pairing-forespørsler og hente ID-en til forespørselen: 

1
hostManagerCtl getPendingRequests

Kjør deretter følgende kommando for å godta pairing-forespørselen, og erstatt ID med ID-en som ble hentet med den forrige kommandoen:

1
hostManagerCtl acceptRequest ID
Eksempel

Hvis returverdien til kommandoen hostManagerCtl getPendingRequests er som følger:

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

Da er kommandoen for å godta pairing-forespørselen følgende:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

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

1
hostManagerCtl listPeers

Resultatet er forskjellig avhengig av serveren kommandoen kjøres på:

Det forventede resultatet på Mediation Controller-serveren MASTER er følgende:

1
slave -> RIP_MED_WEB_SLAVE
Eksempel 
1
slave -> 10.0.10.12

Det forventede resultatet på Mediation Controller-serveren SLAVE er følgende:

1
master -> RIP_MED_WEB_MASTER
Eksempel 
1
master -> 10.0.10.10

På Mediation Controller-serveren SLAVE

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

1
hostManagerCtl getBootstrapStatus

Et cluster som ikke har synkroniseringsproblemer, returnerer verdien 0.

En siste rekke kommandoer er nødvendig, igjen på serveren SLAVE, for å synkronisere en hemmelighet som deles mellom de to Mediation Controller-serverne:

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

Det er en spesiell forbindelse i cluster-driften som gjør det mulig for en Mediation Controller-server å rute trafikk til en annen Mediation Controller-server i tilfeller der Edge Gateway-målet ikke er koblet til den første serveren, men bare til den andre.

Hvis for eksempel Mediation Controller-serveren MASTER ikke lenger er koblet til Edge Gateway, kan den bruke interserver-forbindelsen for å nå Edge Gateway via Mediation Controller-serveren SLAVE.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Tilkobling mistet| GW(Edge Gateway)
    MASTER --> |Forbindelse mellom 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 å angi CN for interserver-sertifikatet:

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

Erstatt SLAVECN med CN for sertifikatet som er beregnet på interserver-forbindelsen.
Hvis du ikke kjenner CN for interserver-sertifikatet, kan tegnet * skrives inn (anbefalt hvis du er i tvil):

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 informasjon lagt til grunn:

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

Filen /etc/ipdiva/server/remoteServers.xml på Mediation Controller-serveren MASTER fylles ut slik:

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"/>
                -->
Fullstendig 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-sertifikatet til Mediation Controller SLAVE, i katalogen /tmp/.
Kjør deretter følgende kommandoer som root for å flytte det til målkatalogen med de riktige tillatelsene:

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 deretter filen /etc/ipdiva/server/remoteServers.xml for å legge følgende innhold til taggen <remoteConfig> (den gamle taggen <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>

Erstatt:

  • MASTERCN: angi CN for SSL Router-sertifikatet til Mediation Controller MASTER; det er vanligvis RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER: svarer til den sekundære IP-adressen til Mediation Controller MASTER.
  • PORT_RIP_MED_SSL_MASTER: dette er porten som SSL Router til Mediation Controller MASTER lytter på; den er vanligvis 443.
  • INTERSERVER.P12: navnet på sertifikatet som er beregnet på interserver-forbindelsen.
  • PASSWORD: passordet for interserver-sertifikatet.
Eksempel

Med følgende informasjon lagt til grunn:

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

Filen /etc/ipdiva/server/remoteServers.xml på Mediation Controller-serveren SLAVE fylles ut slik:

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

Endre konfigurasjonen av SSL Router SLAVE ved å kjø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

Start SSL Router på nytt for å ta i bruk innstillingene for interserver-forbindelsen:

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

For å bekrefte at interserver-forbindelsen fungerer riktig, må følgende kommando returnere et resultat:

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

Den forrige kommandoen skal produsere en logg som inneholder følgende: TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers, and 0 multicast group(s).
Hvis ingen slik logg vises, kontrollerer du konfigurasjonen som ble satt opp i dette kapitlet.

I webkonsollet /mediation/system til Mediation Controller MASTER

Aktiver interserver-forbindelsen mellom de to Mediation Controller-serverne ved å redigere den virtuelle SSL-verten default:

Fyll ut de ulike feltene ved hjelp av instruksjonene nedenfor, og aktiver funksjonen for interserver-forbindelse ved å merke av boksen Is cross-server linking configured?:

  • Public address for plugin connections: svarer til VIP_MED_SSL fulgt av lytteporten (vanligvis 443).
  • Actual public IP addresses for web connections: svarer til paret av reelle web-IP-adresser (RIP_MED_WEB_MASTER og RIP_MED_WEB_SLAVE) med de tilhørende portene, én linje per par av IP-adresse og port.
  • Actual public IP addresses for SSL connections: svarer til paret av reelle SSL-IP-adresser (RIP_MED_SSL_MASTER og RIP_MED_SSL_SLAVE) med de tilhørende portene, én linje per par av IP-adresse og port.

Initialisering av CyberElements Bastion

Tilkobling til PostgreSQL-databasen

For å fungere krever CyberElements Bastion bruk av en ekstern PostgreSQL-database (DB) for å lagre innstillingene sine og de ulike loggene i konsollet /system.
Hvis DB-en er direkte tilgjengelig fra Mediation Controller-serverne, går du direkte til trinnet for initialisering av DB-en.

Tilkobling til en database i LAN-et

For å muliggjøre tilkobling til en database som ligger i LAN-et, uten å åpne en flyt fra DMZ til LAN, videresendes databaseflyten gjennom en TLS-tunnel mellom Edge Gateway-serverne og Mediation Controller-serverne.
For å oppnå dette må én Edge Gateway (eller to Edge Gateway-servere) konfigureres ved hjelp av den underliggende teknologien CyberElements Gate.

Deklarasjon av Edge Gateway-serverne i CyberElements Gate

For å gjøre det starter du med å logge på konsollet /mediation/system i CyberElements Gate.

Gå deretter til menyen ”Organizations” og klikk på ”Add”:

Skriv inn navnet på organisasjonen, som må være forskjellig fra det som er tilordnet CyberElements Bastion (for eksempel tunnel), og angi minst én lisens for brukerøkt sammen med passordet for kontoen admin:

Logg på administrasjonsgrensesnittet til organisasjonen du opprettet tidligere, med kontoen admin ved å gå til /gate/admin:

Deklarer deretter de to Edge Gateway-serverne som skal brukes til å sette opp tunnelen.
Til venstre holder du pekeren over Infrastructure, klikker på Gateways og deretter på knappen Add:

Skriv inn navnet på den første Edge Gateway og bekreft oppføringen:

Informasjon

Til påminnelse: navnet på en Edge Gateway er knyttet til sertifikatet den bruker for å autentisere seg overfor SSL Router til Mediation Controller.
Dette navnet har følgende form <GW_NAME>@<ORGANIZATION_NAME>, der <GW_NAME> svarer til navnet på Edge Gateway, og der <ORGANIZATION_NAME> svarer til navnet på organisasjonen som er opprettet i systemkonsollet til CyberElements Gate.

Gjenta trinnet for deklarasjon av Edge Gateway for den andre Edge Gateway.

Tilkoblinger og innstillinger for tunnelen på Edge Gateway-serverne

Informasjon

De følgende trinnene kan gjentas på begge Edge Gateway-serverne som brukes til tunnelen for å få tilgang til databasen.

Forutsetninger

For å fullføre denne delen må du bruke en av følgende:

Bruk først et verktøy som WinSCP eller FileZilla for å overføre sertifikatet som kreves for tilkoblingen, til katalogen /tmp/ på Edge Gateway via SCP.

Koble deg deretter til via SSH og bytt til root.

For å koble Edge Gateway til begge Mediation Controller-serverne må du opprette to nye Edge Gateway-forekomster: den ene kobler seg til Mediation Controller MASTER, den andre til Mediation Controller SLAVE.
Kjør følgende kommandoer for å opprette dem:

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

Kopier sertifikatfilen til katalogene /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/

Erstatt <CERT_NAME> med navnet på sertifikatet som Edge Gateway må bruke for å koble seg til Mediation Controller.

Konfigurer Edge Gateway-forekomstene slik at de kan koble seg til Mediation Controller-serverne.
Konfigurasjonene er forskjellige avhengig av hvilken Mediation Controller som skal kontaktes. Utfør begge innstillingene:

Rediger filen /etc/ipdiva/gateway-tunnel-master/gateway.xml og fyll den ut med følgende informasjon (flere deler er utelatt og er merket 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>

Erstatt følgende elementer:

  • @SERVER@: må erstattes med adressen RIP_MED_SSL_MASTER
  • @SERVERPORT@: må erstattes med lytteporten til SSL Router, normalt satt til 443
  • keyfile.pem: må erstattes med navnet på sertifikatfilen
  • PASSWORD: må erstattes med passordet for sertifikatet
  • @RPC_PORT@: må erstattes med en port som maskinen ikke lytter på for øyeblikket; porten 9082 kan brukes
Eksempel

Med følgende informasjon lagt til grunn:

  • RIP_MED_SSL_MASTER er lik: 10.0.10.11
  • Lytteport for SSL Router: 443
  • Navn på sertifikatfilen: gate-tunnel.p12
  • Passord for sertifikatet: Str0ngP@ssw0rd

Filen /etc/ipdiva/gateway-tunnel-master/gateway.xml konfigureres slik:

 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>
Fullstendig 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 fyll den ut med følgende informasjon (flere deler er utelatt og er merket 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>

Erstatt følgende elementer:

  • @SERVER@: må erstattes med adressen RIP_MED_SSL_SLAVE
  • @SERVERPORT@: må erstattes med lytteporten til SSL Router, normalt satt til 443
  • keyfile.pem: må erstattes med navnet på sertifikatfilen
  • PASSWORD: må erstattes med passordet for sertifikatet
  • @RPC_PORT@: må erstattes med en port som ikke er i bruk på maskinen for øyeblikket; porten 9083 kan brukes
Eksempel

Med følgende informasjon lagt til grunn:

  • RIP_MED_SSL_SLAVE er lik: 10.0.10.13
  • Lytteport for SSL Router: 443
  • Navn på sertifikatfilen: gate-tunnel.p12
  • Passord for sertifikatet: Str0ngP@ssw0rd

Filen /etc/ipdiva/gateway-tunnel-slave/gateway.xml konfigureres slik:

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

Nå som forekomstene er konfigurert for å koble seg til Mediation Controller-serverne, må de i tillegg konfigureres for å videresende tilkoblingen fra Mediation Controller til databasen.
Rediger derfor filen /etc/ipdiva/gateway-tunnel-master/services.xml og endre den slik: 

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>

Erstatt DB_SERVER med DNS-navnet eller IP-adressen som brukes for å koble til databasen, og DB_PORT med lytteporten til databaseforekomsten.
Gjenta denne konfigurasjonen for forekomsten som kobler seg til Mediation Controller-serveren SLAVE, ved å kopiere filen:

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

Start til slutt Edge Gateway-forekomstene slik at de oppretter tilkoblingen til Mediation Controller-serverne:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Konfigurere tunnelen på Mediation Controller-serverne

For at tunnelen skal kunne brukes av Mediation Controller-serverne, må du i tillegg deklarere at den finnes.
Logg derfor på Mediation Controller-serverne som root og rediger filen /etc/ipdiva/server/services.xml for å legge til følgende del (flere deler er utelatt og er merket 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>

Erstatt følgende elementer:

  • GW1_NAME med navnet på den første Edge Gateway
  • GW2_NAME med navnet på den andre Edge Gateway
  • ORGANIZATION_NAME med navnet på CyberElements Gate-organisasjonen som ble opprettet tidligere
Eksempel

Med følgende informasjon lagt til grunn:

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

Filen /etc/ipdiva/server/services.xml fylles ut slik:

 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>
Fullstendig 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 å ta i bruk den nye konfigurasjonen starter du SSL Router på nytt med følgende kommando:

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

Initialisere databasen

OBS!

Du må opprette databasen default før CyberElements Bastion initialiserer den (den opprettes ikke automatisk).

For å initialisere PostgreSQL-databasen for systemkonfigurasjonen må du først konfigurere tilkoblingsinnstillingene på Mediation Controller-serverne.
Rediger derfor filen /etc/ipdiva/care/databasesettings.ini på begge serverne og legg til følgende oppføringer:

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

Erstatt følgende elementer:

  • DB_USERNAME med brukernavnet som brukes for å koble til databasen.
  • DB_PWD med passordet til brukeren som kobler seg til.
  • DB_HOST med IP-adressen eller DNS-navnet som brukes for å koble til databasen; hvis en tilkobling via Edge Gateway-servere brukes, må du skrive inn 127.0.0.1.
  • DB_PORT med porten som brukes for å koble til databaseforekomsten; hvis en tilkobling via Edge Gateway-servere brukes, må du skrive inn 1432.

Initialiseringen av databasen kan startes med følgende kommandoer, som bare skal kjøres på én Mediation Controller:

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

Deretter gjenstår det bare å starte tjenesten apache2 på nytt på begge Mediation Controller-serverne for å ta i bruk initialiseringen av systemdatabasen:

1
systemctl restart apache2

Konfigurasjon av en NTP-tidsserver

Det anbefales å sette opp en tidsserver for å holde systemklokken oppdatert. De nødvendige trinnene er beskrevet på siden om NTP-konfigurasjon.

Første konfigurasjoner av CyberElements Bastion

Tillatelse til tilgang til webgrensesnittene med den virtuelle IP-adressen

Som standard er det ikke tillatt å koble seg til webgrensesnittene til produktet CyberElements Bastion med den virtuelle IP-adressen VIP_MED_WEB.
For å legge til tillatelsen kjører du følgende kommandoer som root på Mediation Controller-serverne:

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

Erstatt IP med IP-adressen som svarer til VIP_MED_WEB.

Første konfigurasjoner

På dette stadiet er Mediation Controller-serverne installert, men flere handlinger må fortsatt utføres:

  • Endre standardpassordene

    Endre standardpassordene for systemkonsollene.

    Endre

  • Installere sertifikatene og lisensene

    Mediation Controller krever ulike sertifikater og en lisens for å være driftsklar.
    Bare sertifikatet for CyberElements Bastion-klienten må deklareres på nytt på begge Mediation Controller-serverne (bruk RIP-ene RIP_MED_WEB_MASTER og RIP_MED_WEB_SLAVE).

    Installere sertifikatene og lisensen

  • Konfigurere websertifikatet

    Konfigurer websertifikatet som brukes til å koble til webgrensesnittene

    Konfigurere

  • Deklarere et DNS-navn

    Legg til et DNS-navn som har tillatelse til å koble til webgrensesnittene.

    Legge til