Saltar a contenido

Instalación de los servidores Mediation Controller

Nota

Recordatorio: el cambio a root en las máquinas Debian debe realizarse con el siguiente comando:

1
su -

Las instrucciones de esta página deben aplicarse a los dos servidores Mediation Controller, empezando por el servidor MASTER.
Cuando existan diferencias entre los servidores MASTER y SLAVE, se señalarán. Si no se indica nada, las instrucciones se aplican tanto al servidor MASTER como al SLAVE.

Configuración del sistema

Conexión a la máquina

Por defecto, hay dos cuentas en los aparatos virtuales: una cuenta de usuario y una cuenta de superusuario.

  • Cuenta de usuario
    • Iniciación de sesión: systancia
    • Paseo: systnci
  • Cuenta de superusuario
    • Iniciación de sesión: root
    • Paseo: systnci

Conectarse a la máquina en modo de consola.

Nota

El diseño predeterminado del teclado es QWERTY.

Cambio de la distribución del teclado

Puede cambiar el diseño del teclado con la siguiente línea de comandos:

1
dpkg-reconfigure keyboard-configuration

Aparece un menú que le permite elegir otro diseño de teclado.

Luego use la siguiente línea de comandos para aplicar y guardar la configuración:

1
setupcon -k --save

La configuración entrará en vigor inmediatamente después de que se ejecute este comando.

Configuración de la red

Es indispensable configurar una dirección de red estática para el Mediation Controller. Para ello, primero hay que obtener el nombre de la interfaz de red de la máquina. Ejecute el siguiente comando como root:

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

Este comando muestra el nombre de la interfaz de red, su estado y las direcciones IP asignadas a la interfaz.

Ejemplo

Tras ejecutar el comando, se muestra el siguiente resultado:

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

El nombre de la interfaz de red es ens192.

Una vez obtenido el nombre de la interfaz de red, ya es posible editar la configuración de red de la máquina.
Edite el fichero /etc/network/interfaces para modificarlo siguiendo el modelo siguiente:

 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

Where:

  • INTERFACE_NAME debe sustituirse por el nombre de la interfaz de red obtenido anteriormente.
  • RIP_MED_WEB_MASTER debe sustituirse por la dirección IP real principal del servidor, que será la dirección IP por la que se accederá a las consolas web.
  • NETMASK debe sustituirse por la máscara de red asociada a la dirección IP.
  • NETWORK_GATEWAY debe sustituirse por la puerta de enlace de red predeterminada.
  • IP_DNS debe sustituirse por la dirección IP del servidor DNS. Si hay que configurar varios servidores (3 como máximo), sepárelos con un espacio.
  • DNS_SUFFIX debe sustituirse por el sufijo DNS que se vaya a utilizar. Si no hay que indicar ningún sufijo, elimine la línea.
  • RIP_MED_SSL_MASTER debe sustituirse por la dirección IP real secundaria del servidor. Será la dirección IP por la que se accederá al SSL Router.
Ejemplo 
 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

Por último, solo queda reiniciar el servicio networking para cargar la nueva configuración de red: 

1
systemctl restart networking

Es indispensable configurar una dirección de red estática para el Mediation Controller. Para ello, primero hay que obtener el nombre de la interfaz de red de la máquina. Ejecute el siguiente comando como root:

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

Este comando muestra el nombre de la interfaz de red, su estado y las direcciones IP asignadas a la interfaz.

Ejemplo

Tras ejecutar el comando, se muestra el siguiente resultado:

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

El nombre de la interfaz de red es ens192.

Una vez obtenido el nombre de la interfaz de red, ya es posible editar la configuración de red de la máquina.
Edite el fichero /etc/network/interfaces para modificarlo siguiendo el modelo siguiente:

 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

Where:

  • INTERFACE_NAME debe sustituirse por el nombre de la interfaz de red obtenido anteriormente.
  • RIP_MED_WEB_SLAVE debe sustituirse por la dirección IP real principal del servidor, que será la dirección IP por la que se accederá a las consolas web.
  • NETMASK debe sustituirse por la máscara de red asociada a la dirección IP.
  • NETWORK_GATEWAY debe sustituirse por la puerta de enlace de red predeterminada.
  • IP_DNS debe sustituirse por la dirección IP del servidor DNS. Si hay que configurar varios servidores (3 como máximo), sepárelos con un espacio.
  • DNS_SUFFIX debe sustituirse por el sufijo DNS que se vaya a utilizar. Si no hay que indicar ningún sufijo, elimine la línea.
  • RIP_MED_SSL_SLAVE debe sustituirse por la dirección IP real secundaria del servidor. Será la dirección IP por la que se accederá al SSL Router.
Ejemplo 
 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

Por último, solo queda reiniciar el servicio networking para cargar la nueva configuración de red: 

1
systemctl restart networking

Consejo

Ahora que se ha aplicado la configuración de red, puede accederse al servidor por SSH.

Cambio de las contraseñas de las cuentas locales

Systancia recomienda encarecidamente cambiar la contraseña de estas cuentas una vez que se haya implementado el dispositivo virtual.

Utilice el siguiente comando e introduzca la nueva contraseña para la cuenta estándar systancia:

1
passwd systancia

Luego repita la operación para la cuenta de superusuario root:

1
passwd root

Configuración del nombre de la máquina

El nombre del servidor puede cambiarse configurando los ficheros hostname y hosts del servidor.

Edite el fichero /etc/hostname para indicar el nombre de la máquina.
El producto necesita el nuevo nombre en otra ubicación, por lo que debe hacerse una copia del fichero anterior con el siguiente comando:

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

Hay que replicar la configuración del fichero /etc/hosts en relación con la dirección IP real principal de la máquina (RIP_MED_WEB_MASTER).
Para ello, edite el fichero /etc/hosts y compruebe que la segunda línea tenga el formato siguiente:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

Si la máquina se llama MEDIATION-CONTROLLER-MASTER sin pertenecer a un dominio y su dirección IP real RIP_MED_WEB_MASTER es 10.0.10.10, el fichero se completaría de la siguiente manera:

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Si la máquina pertenece al dominio DOMAIN.LOCAL, el fichero se completaría de la siguiente manera:

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

Hay que replicar la configuración del fichero /etc/hosts en relación con la dirección IP real principal de la máquina (RIP_MED_WEB_SLAVE).
Para ello, edite el fichero /etc/hosts y compruebe que la segunda línea tenga el formato siguiente:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

Si la máquina se llama MEDIATION-CONTROLLER-SLAVE sin pertenecer a un dominio y su dirección IP real RIP_MED_WEB_SLAVE es 10.0.10.12, el fichero se completaría de la siguiente manera:

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Si la máquina pertenece al dominio DOMAIN.LOCAL, el fichero se completaría de la siguiente manera:

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

Para aplicar la nueva configuración, reinicie el servidor:

1
reboot

Modificación de la zona horaria

Por defecto, el aparato virtual está configurado en la zona horaria Europe/Paris.

Para cambiar esta zona horaria, primero use el siguiente comando para recuperar la sintaxis de las zonas horarias disponibles:

1
timedatectl list-timezones

Entonces use la siguiente línea de comandos:

1
timedatectl set-timezone your_time_zone
Ejemplo

Para establecer la zona horaria de Londres, se debe ejecutar el siguiente comando:

1
timedatectl set-timezone Europe/London

Compruebe la zona horaria del servidor usando la siguiente línea de comandos:

1
timedatectl

Inicialización del servidor Mediation Controller

Inicialización del servidor Mediation Controller

El servidor Mediation Controller se inicializa mediante un script de configuración. Este script reconfigura las direcciones IP del Cluster en los distintos servicios del producto y preconfigura los parámetros necesarios para el funcionamiento de una HTML5 Gateway.
Ejecútelo con la siguiente línea de comandos como root:

1
/opt/systancia/initializeCluster

El script le pedirá que introduzca la información siguiente:

  • IP VIP HTTPS: dirección IP web virtual del Cluster, es decir VIP_MED_WEB.
  • IP VIP SSL: dirección IP SSL virtual del Cluster, es decir VIP_MED_SSL.
  • IP VIP ZIO: dirección IP virtual para la conexión del servidor Mediation Controller SLAVE a la base de datos interna de configuración del servidor MASTER, es decir VIP_MED_ZEO.
  • IP Master HTTPS: dirección IP web real del servidor Mediation Controller MASTER, es decir RIP_MED_WEB_MASTER.
  • IP Master SSL: dirección IP real del SSL Router del servidor Mediation Controller MASTER, es decir RIP_MED_SSL_MASTER.
  • IP Slave HTTPS: dirección IP web real del servidor Mediation Controller SLAVE, es decir RIP_MED_WEB_SLAVE.
  • IP Slave SSL: dirección IP real del SSL Router del servidor Mediation Controller SLAVE, es decir RIP_MED_SSL_SLAVE.
  • HTML5 port: puerto de escucha local para redirigir el acceso al servicio HTML5 Gateway; recomendamos indicar el puerto 1234.
  • Gateway: nombre de la Edge Gateway; indique el nombre de la primera Edge Gateway.
  • Organization: nombre de la organización a la que se conectarán las Edge Gateways y las HTML5 Gateways.

Una vez finalizada la inicialización, reinicie el servidor:

1
reboot

Cambio de la contraseña de la consola /mediation/system de CyberElements Gate

En esta fase de la instalación hay disponible una nueva interfaz de administración: Cambiar la contraseña

Aplicación de las licencias y de los certificados

Siempre en la consola /mediation/system, deberá introducir los certificados y las licencias del servidor Mediation Controller.

¡Atención!

La licencia y el certificado del SSL Router son específicos del servidor Mediation Controller MASTER o SLAVE.
Configurar una licencia o un certificado equivocados provocará fallos posteriormente.

Aplique la licencia y el certificado del componente SSL Router:

  1. Haga clic en la pestaña Settings.
  2. Seleccione SSL Connections en el menú.
  3. Busque el certificado del SSL Router.
  4. Introduzca la contraseña del certificado del SSL Router.
  5. Haga clic en Apply para aplicar el certificado al SSL Router.
  6. Seleccione el fichero de licencia del servidor.
  7. Haga clic en Modify para aplicar la licencia del servidor.

A continuación, introduzca la información del certificado del cliente CyberElements Bastion:

  1. Seleccione la pestaña Plugin.
  2. Busque el certificado del cliente CyberElements Bastion.
  3. Introduzca la contraseña del certificado.
  4. Haga clic en Apply para aplicar el certificado.

Queda por introducir la información del certificado del Watchdog:

  1. Seleccione la pestaña Watchdog
  2. Busque el certificado del Watchdog.
  3. Introduzca la contraseña del certificado.
  4. Haga clic en Apply para aplicar el certificado.

Para que estos cambios surtan efecto, debe reiniciar el SSL Router y el Watchdog:

Emparejamiento de los servidores Mediation Controller

¡Atención!

Llegados a este punto, ambos servidores Mediation Controller deben haberse configurado hasta la aplicación de las licencias y de los certificados.
Si el servidor Mediation Controller SLAVE aún no se ha configurado, hágalo empezando desde el principio de esta documentación.

La etapa de emparejamiento de los servidores Mediation Controller establecerá un vínculo de confianza entre ambos servidores e inicializará el funcionamiento en Cluster.

En el servidor Mediation Controller SLAVE

Ejecute el siguiente comando como root para iniciar una solicitud de emparejamiento con el servidor Mediation Controller MASTER:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Sustituya RIP_MED_WEB_MASTER por la dirección IP correspondiente.

Ejemplo

Si RIP_MED_WEB_MASTER es igual a 10.0.10.10, el comando que debe introducirse es el siguiente:

1
hostManagerCtl bootstrap 10.0.10.10

En el servidor Mediation Controller MASTER

Ejecute el siguiente comando como root para consultar las solicitudes de emparejamiento pendientes y obtener el identificador de la solicitud: 

1
hostManagerCtl getPendingRequests

A continuación, ejecute el siguiente comando para aceptar la solicitud de emparejamiento, sustituyendo ID por el identificador obtenido con el comando anterior:

1
hostManagerCtl acceptRequest ID
Ejemplo

Si el resultado del comando hostManagerCtl getPendingRequests es el siguiente:

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

El comando para aceptar la solicitud de emparejamiento es entonces el siguiente:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

Para comprobar la asociación, utilice el siguiente comando en el servidor Mediation Controller (ya sea MASTER o SLAVE):

1
hostManagerCtl listPeers

El resultado variará según el servidor en el que se ejecute el comando:

El resultado esperado en el servidor Mediation Controller MASTER es el siguiente:

1
slave -> RIP_MED_WEB_SLAVE
Ejemplo 
1
slave -> 10.0.10.12

El resultado esperado en el servidor Mediation Controller SLAVE es el siguiente:

1
master -> RIP_MED_WEB_MASTER
Ejemplo 
1
master -> 10.0.10.10

En el servidor Mediation Controller SLAVE

Puede comprobar el estado del bootstrap desde el servidor SLAVE con el siguiente comando:

1
hostManagerCtl getBootstrapStatus

Un Cluster que no presente ningún problema de sincronización devolverá el valor 0.

Es necesaria una última serie de comandos, de nuevo en el servidor SLAVE, para sincronizar un secreto compartido entre ambos Mediation Controllers:

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2
¿Para qué sirve la conexión interservidor?

Se trata de una conexión particular del funcionamiento en Cluster, que permite a un servidor Mediation Controller encaminar el tráfico hacia otro servidor Mediation Controller cuando la Edge Gateway de destino no está conectada al primer servidor, sino únicamente al segundo.

Por ejemplo, si el servidor Mediation Controller MASTER ya no está conectado a la Edge Gateway, puede utilizar el enlace interservidor para alcanzarla a través del servidor Mediation Controller SLAVE.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Conexión perdida| GW(Edge Gateway)
    MASTER --> |Enlace entre servidores| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

En el servidor Mediation Controller MASTER

Edite el fichero /etc/ipdiva/server/remoteServers.xml para indicar el CN del certificado interservidor:

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

Sustituya SLAVECN por el CN del certificado destinado a la conexión interservidor.
Si desconoce el CN del certificado interservidor, puede introducirse el carácter * (recomendado en caso de duda):

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

Teniendo en cuenta la información siguiente:

  • CN del certificado interservidor: my-interserver-cert

El fichero /etc/ipdiva/server/remoteServers.xml del servidor Mediation Controller MASTER se completaría de la siguiente manera:

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

En el servidor Mediation Controller SLAVE

Envíe el certificado interservidor al Mediation Controller SLAVE, en el directorio /tmp/.
A continuación, ejecute los siguientes comandos como root para trasladarlo al directorio de destino con los permisos adecuados:

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

A continuación, edite el fichero /etc/ipdiva/server/remoteServers.xml para añadir el contenido siguiente a la etiqueta <remoteConfig> (la antigua etiqueta <localCluster> puede eliminarse por completo):

 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>

Replace:

  • MASTERCN: indique el CN del certificado del SSL Router del Mediation Controller MASTER, que suele ser RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER: corresponde a la dirección IP secundaria del Mediation Controller MASTER.
  • PORT_RIP_MED_SSL_MASTER: es el puerto de escucha del SSL Router del Mediation Controller MASTER; suele ser el 443.
  • INTERSERVER.P12: nombre del certificado destinado al interservidor.
  • PASSWORD: contraseña del certificado interservidor.
Ejemplo

Teniendo en cuenta la información siguiente:

  • Nombre del certificado interservidor: my-interserver-cert.p12
  • Contraseña del certificado interservidor: MySecurePassword
  • RIP SSL del Mediation Controller MASTER: 10.0.10.11
  • Puerto en la RIP SSL del Mediation Controller MASTER: 443
  • CN del certificado del Mediation Controller MASTER: 10.0.10.11

El fichero /etc/ipdiva/server/remoteServers.xml del servidor Mediation Controller SLAVE se completaría de la siguiente manera:

 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>
Fichero completo 
 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>

Modifique la configuración del SSL Router SLAVE ejecutando el siguiente comando:

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

En los servidores Mediation Controller MASTER y SLAVE

Reinicie el SSL Router para aplicar la configuración del enlace interservidor:

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

Para confirmar que el enlace interservidor funciona correctamente, el siguiente comando debe devolver un resultado:

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

El comando anterior debe producir un registro que contenga lo siguiente: TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers, and 0 multicast group(s).
Si no aparece ningún registro de este tipo, compruebe la configuración realizada en este capítulo.

En la consola web /mediation/system del Mediation Controller MASTER

Active la conexión interservidor entre los dos Mediation Controllers editando el host virtual SSL default:

Rellene los distintos campos siguiendo las indicaciones que figuran a continuación y active la función de enlace interservidor marcando la casilla Is cross-server linking configured?:

  • Public address for plugin connections: corresponde a VIP_MED_SSL seguido de su puerto de escucha (normalmente 443).
  • Actual public IP addresses for web connections: corresponde al par de direcciones IP web reales (RIP_MED_WEB_MASTER y RIP_MED_WEB_SLAVE) con sus puertos correspondientes, una línea por par de dirección IP y puerto.
  • Actual public IP addresses for SSL connections: corresponde al par de direcciones IP SSL reales (RIP_MED_SSL_MASTER y RIP_MED_SSL_SLAVE) con sus puertos correspondientes, una línea por par de dirección IP y puerto.

Inicialización de CyberElements Bastion

Conexión a la base de datos PostgreSQL

Para funcionar, CyberElements Bastion necesita utilizar una base de datos (BD) PostgreSQL externa para almacenar su configuración y los distintos registros de la consola /system.
Si la BD es directamente accesible desde los servidores Mediation Controller, pase directamente a la etapa de inicialización de la BD.

Conexión a una base de datos situada en la LAN

Para permitir la conexión a una base de datos situada en la LAN sin abrir un flujo de la DMZ hacia la LAN, el flujo de la base de datos se redirigirá a través de un túnel TLS entre las Edge Gateways y los Mediation Controllers.
Para lograrlo, hay que configurar una Edge Gateway (o dos Edge Gateways) utilizando la tecnología CyberElements Gate subyacente.

Declaración de las Edge Gateways CyberElements Gate

Para ello, empiece por conectarse a la consola /mediation/system de CyberElements Gate.

Vaya después al menú « Organizations » y haga clic en « Add »:

Introduzca el nombre de la organización, que debe ser distinto del asignado a CyberElements Bastion (por ejemplo, tunnel), e indique al menos una licencia de sesión de usuario junto con la contraseña de la cuenta admin:

Conéctese a la interfaz de administración de la organización creada anteriormente con la cuenta admin, accediendo a /gate/admin:

Declare a continuación las dos Edge Gateways que se utilizarán para establecer el túnel.
A la izquierda, sitúe el cursor sobre Infrastructure, haga clic en Gateways y después en el botón Add:

Introduzca el nombre de la primera Edge Gateway y confirme la entrada:

Información

Recordatorio: el nombre de una Edge Gateway está vinculado al certificado que utilizará para autenticarse ante el SSL Router del Mediation Controller.
Este nombre adopta la forma siguiente <GW_NAME>@<ORGANIZATION_NAME>, donde <GW_NAME> corresponde al nombre de la Edge Gateway y <ORGANIZATION_NAME> al nombre de la organización creada en la consola del sistema de CyberElements Gate.

Repita la etapa de declaración para la segunda Edge Gateway.

Conexiones y configuración del túnel en las Edge Gateways

Información

Las etapas siguientes pueden replicarse en las dos Edge Gateways utilizadas para el túnel de acceso a la base de datos.

Requisitos previos

Para completar esta parte, deberá utilizar una de estas dos opciones:

En primer lugar, utilice una herramienta como WinSCP o FileZilla para transferir por SCP, al directorio /tmp/ de la Edge Gateway, el certificado necesario para la conexión.

Conéctese después por SSH y cambie a root.

Para conectar la Edge Gateway a los dos Mediation Controllers, hay que crear dos nuevas instancias de Edge Gateway: una se conectará al Mediation Controller MASTER y la otra al Mediation Controller SLAVE.
Para crearlas, ejecute los siguientes comandos:

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

Copie el fichero del certificado en los directorios /etc/ipdiva/gateway-tunnel-master/ssl/ y /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/

Sustituya <CERT_NAME> por el nombre del certificado que la Edge Gateway debe utilizar para conectarse al Mediation Controller.

Configure las instancias de Edge Gateway para que puedan conectarse a los Mediation Controllers.
Las configuraciones difieren según el Mediation Controller que se vaya a contactar. Realice ambas configuraciones:

Edite el fichero /etc/ipdiva/gateway-tunnel-master/gateway.xml y complételo con la información siguiente (se han omitido varias secciones, indicadas mediante […]):

 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>

Sustituya los elementos siguientes:

  • @SERVER@: debe sustituirse por la dirección RIP_MED_SSL_MASTER
  • @SERVERPORT@: debe sustituirse por el puerto de escucha del SSL Router, normalmente el 443
  • keyfile.pem: debe sustituirse por el nombre del fichero del certificado
  • PASSWORD: debe sustituirse por la contraseña del certificado
  • @RPC_PORT@: debe sustituirse por un puerto que no esté a la escucha en la máquina; puede utilizarse el puerto 9082
Ejemplo

Teniendo en cuenta la información siguiente:

  • RIP_MED_SSL_MASTER es igual a: 10.0.10.11
  • Puerto de escucha del SSL Router: 443
  • Nombre del fichero del certificado: gate-tunnel.p12
  • Contraseña del certificado: Str0ngP@ssw0rd

El fichero /etc/ipdiva/gateway-tunnel-master/gateway.xml quedaría configurado de la siguiente manera:

 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>
Fichero completo 
 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>

Edite el fichero /etc/ipdiva/gateway-tunnel-slave/gateway.xml y complételo con la información siguiente (se han omitido varias secciones, indicadas mediante […]):

 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>

Sustituya los elementos siguientes:

  • @SERVER@: debe sustituirse por la dirección RIP_MED_SSL_SLAVE
  • @SERVERPORT@: debe sustituirse por el puerto de escucha del SSL Router, normalmente el 443
  • keyfile.pem: debe sustituirse por el nombre del fichero del certificado
  • PASSWORD: debe sustituirse por la contraseña del certificado
  • @RPC_PORT@: debe sustituirse por un puerto que no esté en uso en la máquina; puede utilizarse el puerto 9083
Ejemplo

Teniendo en cuenta la información siguiente:

  • RIP_MED_SSL_SLAVE es igual a: 10.0.10.13
  • Puerto de escucha del SSL Router: 443
  • Nombre del fichero del certificado: gate-tunnel.p12
  • Contraseña del certificado: Str0ngP@ssw0rd

El fichero /etc/ipdiva/gateway-tunnel-slave/gateway.xml quedaría configurado de la siguiente manera:

 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>
Fichero completo 
 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>

Ahora que las instancias están configuradas para conectarse a los Mediation Controllers, queda configurarlas para redirigir hacia la base de datos la conexión del Mediation Controller.
Para ello, edite el fichero /etc/ipdiva/gateway-tunnel-master/services.xml y modifíquelo de la siguiente manera: 

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>

Sustituya DB_SERVER por el nombre DNS o la dirección IP utilizada para conectarse a la base de datos, y DB_PORT por el puerto de escucha de la instancia de base de datos.
Replique esta configuración en la instancia que se conecta al servidor Mediation Controller SLAVE copiando el fichero:

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

Por último, inicie las instancias de Edge Gateway para que establezcan la conexión con los Mediation Controllers:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Configuración del túnel en los Mediation Controllers

Para que el túnel pueda ser utilizado por los Mediation Controllers, queda por declarar su existencia.
Para ello, conéctese como root a los Mediation Controllers y edite el fichero /etc/ipdiva/server/services.xml para añadir la sección siguiente (se han omitido varias secciones, indicadas mediante […]):

 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>

Sustituya los elementos siguientes:

  • GW1_NAME por el nombre de la primera Edge Gateway
  • GW2_NAME por el nombre de la segunda Edge Gateway
  • ORGANIZATION_NAME por el nombre de la organización CyberElements Gate creada anteriormente
Ejemplo

Teniendo en cuenta la información siguiente:

  • Nombre de la Edge Gateway 1: gate-tunnel-1
  • Nombre de la Edge Gateway 2: gate-tunnel-2
  • Nombre de la organización CyberElements Gate: tunnel

El fichero /etc/ipdiva/server/services.xml se completaría de la siguiente manera:

 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>
Fichero completo 
 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>

Para aplicar la nueva configuración, reinicie el SSL Router con el siguiente comando:

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

Inicialización de la base de datos

¡Atención!

Debe crear la base de datos default antes de que CyberElements Bastion la inicialice (no se crea automáticamente).

Para inicializar la base de datos PostgreSQL de configuración del sistema, primero hay que configurar los parámetros de conexión en los Mediation Controllers.
Para ello, edite el fichero /etc/ipdiva/care/databasesettings.ini en ambos servidores y añada las entradas siguientes:

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

Sustituya los elementos siguientes:

  • DB_USERNAME por el nombre de usuario utilizado para conectarse a la base de datos.
  • DB_PWD por la contraseña del usuario que se conecta.
  • DB_HOST por la dirección IP o el nombre DNS utilizado para conectarse a la base de datos; si se utiliza una conexión a través de Edge Gateways, habrá que indicar 127.0.0.1.
  • DB_PORT por el puerto utilizado para conectarse a la instancia de base de datos; si se utiliza una conexión a través de Edge Gateways, habrá que indicar 1432.

La inicialización de la base de datos puede lanzarse con los siguientes comandos, que deben ejecutarse en un solo Mediation Controller:

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

Después, solo queda reiniciar el servicio apache2 en los dos Mediation Controllers para aplicar la inicialización de la base de datos del sistema:

1
systemctl restart apache2

Configuración de un servidor de tiempo NTP

Se recomienda configurar un servidor de tiempo para mantener el reloj del sistema actualizado. Los pasos necesarios se describen en la página de configuración NTP.

Configuraciones iniciales de CyberElements Bastion

Autorización de acceso a las interfaces web con la IP virtual

De forma predeterminada, no está permitido conectarse a las interfaces web del producto CyberElements Bastion con la IP virtual VIP_MED_WEB.
Para añadir la autorización, ejecute como root los siguientes comandos en los Mediation Controllers:

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

Sustituya IP por la dirección IP correspondiente a VIP_MED_WEB.

Configuraciones iniciales

En esta fase, los servidores Mediation Controller están instalados, pero quedan varias acciones por realizar:

  • Cambiar las contraseñas predeterminadas

    Cambie las contraseñas predeterminadas de las consolas del sistema.

    Cambiar

  • Instalar los certificados y las licencias

    El Mediation Controller necesita varios certificados y una licencia para ser operativo.
    Solo el certificado del cliente CyberElements Bastion debe volver a declararse en los dos Mediation Controllers (utilice las RIP RIP_MED_WEB_MASTER y RIP_MED_WEB_SLAVE).

    Instalar los certificados y la licencia

  • Configurar el certificado web

    Configure el certificado web utilizado para conectarse a las interfaces web

    Configurar

  • Declarar un nombre DNS

    Añada un nombre DNS autorizado a conectarse a las interfaces web.

    Añadir