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.

Laste ned speilet og de nødvendige verktøyene

Speilet CyberElements Cleanroom 4.6 og signaturnøkkelen til Systancia-repositoryet kan lastes ned fra denne lenken (krever at det opprettes en kundekonto): Systancia Marketplace

I tillegg til speilet og nøkkelen kreves det tredjepartsverktøy for oppgraderingsprosessen:

  • En SSH-klient (på Windows kan du bruke PuTTY)
  • En SCP-klient (på Windows kan verktøyene WinSCP eller FileZilla brukes)

Bruk SSH-klienten til å koble deg eksternt til serveren.

Bruk SCP-klienten til å overføre filer til den eksterne maskinen.

Forberede installasjonen

Konfigurasjon av nettverket

Installer pakken resolvconf slik at DNS-konfigurasjonen som er angitt i konfigurasjonsfilen som endres om litt, kan tas i bruk:

1
apt install -y resolvconf

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

Ett siste trinn gjenstår: å endre den interne navneoppløsningen på maskinen slik at den slår opp den reelle hoved-IP-adressen sin (som svarer til RIP_MED_WEB_MASTER eller RIP_MED_WEB_SLAVE).
Rediger derfor filen /etc/hosts og erstatt 127.0.1.1 med RIP_MED_WEB_MASTER eller RIP_MED_WEB_SLAVE avhengig av Mediation Controller-serveren.

Example

For en Mediation Controller-server der den reelle web-IP-adressen er 10.0.10.10 og navnet er mediation-controller.domain.local, får filen /etc/hosts følgende verdi:

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

OBS!

En feilaktig konfigurasjon av filen kan forårsake en feil ved installasjonen av pakken collectd.

Konfigurere pakkebehandleren APT

Last opp filene som er lastet ned fra Systancia Marketplace, til katalogen /tmp/ på serveren ved hjelp av en SCP-klient:

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

Logg på serveren som root, og kjør deretter følgende kommandoer for å pakke ut Systancia-repositoryet, konfigurere bruken av det i APT og autentisere det.

1
2
3
4
5
mv /tmp/systancia.gpg /etc/apt/trusted.gpg.d/
mkdir -p /opt/systancia/repository/
tar xvzf /tmp/cleanroom-4.6*.tgz -C /opt/systancia/repository/
echo "deb file:///opt/systancia/repository/ bookworm ipdiva" > /etc/apt/sources.list.d/systancia.list
apt update

Vi anbefaler sterkt å deaktivere installasjonen av unødvendige pakker når apt-kommandoer kjøres. Kjør følgende kommando for å gjøre det:

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

Kontrollere om locale en_US.utf8 finnes

Installasjon av Mediation Controller-serveren krever at locale en_US.utf8 genereres.
For å kontrollere om de allerede er generert på serveren, kjører du følgende kommando som root:

1
locale -a  | grep en_US.utf8

Hvis svaret fra kommandoen viser en_US.utf8, går du videre til neste trinn, konfigurasjonen av GRUB.
Ellers kjører du følgende kommandoer for å legge denne localen til maskinen:

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

Konfigurere oppstartsprogrammet GRUB

Når disse kommandoene er kjørt, må du starte maskinen på nytt etter at du har gjort en innstilling i oppstartsprogrammet GRUB:

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

Installasjon av Mediation Controller-serveren i CyberElements Bastion

Installasjon av basiskomponentene

Start installasjonen av komponentene med følgende kommando som root:

1
apt install -y ipdiva-base

Når alle avhengighetene er lastet ned, åpnes det et vindu der du må velge servertypen. Velg mediation:

Velg deretter installasjonsmodusen lbMaster:

Velg deretter installasjonsmodusen lbSlave:

Deretter må du angi porten som SSL Router skal lytte på. Denne lytteporten er vanligvis satt til 443, men porten 8443 kan også brukes hvis Mediation Controller bare bruker én IP-adresse:

Sett deretter Cluster-modusen til loadbalancing slik at brukerlasten fordeles på begge Mediation Controller-serverne:

Angi den virtuelle web-IP-adressen for clusteret, VIP_MED_WEB:

Angi den virtuelle SSL-IP-adressen for clusteret, VIP_MED_SSL:

Angi den virtuelle IP-adressen for konfigurasjonsdatabasen til clusteret, VIP_MED_ZEO:

Angi den reelle web-IP-adressen til Mediation Controller MASTER, RIP_MED_WEB_MASTER:

Angi den reelle SSL-IP-adressen til Mediation Controller MASTER, RIP_MED_SSL_MASTER:

Angi den reelle web-IP-adressen til Mediation Controller SLAVE, RIP_MED_WEB_SLAVE:

Angi til slutt den reelle SSL-IP-adressen til Mediation Controller SLAVE, RIP_MED_SSL_SLAVE:

Hva gjør jeg hvis det oppstår en feil?

Hvis det er en feil i informasjonen du har skrevet inn, fortsetter du installasjonen av pakken ipdiva-base og bruker deretter følgende kommando for å konfigurere serveren på nytt:

1
dpkg-reconfigure ipdiva-base

Installasjon av Cluster-komponentene

Etter installasjonen av basiskomponentene må Cluster-komponentene installeres på Mediation Controller-serverne:

1
apt install -y ipdiva-mediation-cluster

Etter installasjonen av komponentene kreves en omstart:

1
reboot

Konfigurasjon av clusteret

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.

Installasjon av komponentene som er spesifikke for CyberElements Bastion

Start installasjonen av komponentene i CyberElements Bastion på Mediation Controller-serverne med følgende kommando:

1
apt install -y ipdiva-safe-server

Serverne må startes på nytt for å fullføre installasjonen:

1
reboot

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

Installasjon av drivere for tilkobling til Microsoft SQL-databaser

Hvis du vil koble til en ekstern database og den er en Microsoft SQL Server, må ytterligere ODBC-drivere installeres.

Det finnes to versjoner: versjon 17 og versjon 18.

TLS-tilkobling kreves for drivere i versjon 18

Bruk av ODBC 18-drivere krever at tilkoblingen er kryptert med TLS. For å gjøre det må du konfigurere MS SQL Server for kryptering av tilkoblinger.

Før du starter installasjonen av ODBC-driverne, må du installere pakkene som kreves for forberedelsen, og deretter forberede Microsoft-repositoryet for installasjonen av pakkene:

1
2
3
4
apt install -y curl apt-transport-https gpg
curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg
curl https://packages.microsoft.com/config/debian/12/prod.list > /etc/apt/sources.list.d/mssql-release.list
apt update

Installer deretter driverne i henhold til den valgte versjonen og konfigurer systemet for å bruke kommandoen sqlcmd:

1
2
3
ACCEPT_EULA=Y apt install -y msodbcsql17 mssql-tools python3-pip
pip install mssql-scripter --break-system-packages
ln -sfn /opt/mssql-tools/bin/sqlcmd /usr/bin/sqlcmd

1
2
3
ACCEPT_EULA=Y apt install -y msodbcsql18 mssql-tools18 python3-pip
pip install mssql-scripter --break-system-packages
ln -sfn /opt/mssql-tools18/bin/sqlcmd /usr/bin/sqlcmd

ODBC-driverne er nå korrekt installert.
Hvis Mediation Controller-serveren har tilgang til en MS SQL-server, skal følgende kommando gjøre det mulig å koble til den eksterne serveren: 

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

Der:

  • SERVER må erstattes med DNS-navnet eller IP-adressen til MS SQL-serveren.
  • INSTANCE_NAME må erstattes med navnet på forekomsten det skal kobles til; hvis det ikke er nødvendig, fjerner du også tegnet \.
  • PORT må erstattes med tilkoblingsporten til MS SQL-databaseforekomsten.
  • USER må erstattes med brukernavnet som tilkoblingen opprettes med.
Eksempler

Hvis Mediation Controller-serveren har tilgang til en MS SQL-databaseserver via IP-adressen 10.0.10.100, forekomsten som skal nås, lytter på porten 1433, og tilgangskontoen er sql-user. Da lyder tilkoblingskommandoen slik:

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

Hvis tilkoblingsforekomsten med navnet MSSQLINSTANCE måtte angis, ville kommandoen endres slik:

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

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

  • Konfigurere organisasjonen

    Konfigurer organisasjonen i CyberElements Bastion.

    Konfigurere med direkte tilgang til databasen

    Konfigurere med tilgang til databasen via tunnelen på Edge Gateway-serverne

  • Deklarere Edge Gateway-serverne

    Deklarer Edge Gateway-serveren eller -serverne, eller HTML5 Gateway-serveren eller -serverne, som skal installeres.

    Opprette Edge Gateway-servere

  • Opprette et logisk site

    Opprett og konfigurer et logisk site som grupperer Edge Gateway-serverne og HTML5 Gateway-serverne som kan få tilgang til de lokale ressursene.

    Opprette et site

  • Installere en Edge Gateway

    Installer og konfigurer en ny Edge Gateway med de nylig installerte Mediation Controller-serverne.
    Det konfigureres også en HTML5 Gateway-forekomst.

    Installer