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.

Descarga del espejo y de las herramientas necesarias

El espejo CyberElements Cleanroom 4.6 y la clave de firma del repositorio de Systancia pueden descargarse desde este enlace (requiere la creación de una cuenta de cliente): Systancia Marketplace

Además del espejo y de la clave, se necesitarán herramientas de terceros para el proceso de instalación:

  • Un cliente SSH (en Windows puede utilizar PuTTY)
  • Un cliente SCP (en Windows pueden utilizarse las herramientas WinSCP o FileZilla)

Utilice el cliente SSH para conectarse de forma remota a su servidor.

Utilice el cliente SCP para transferir ficheros a su máquina remota.

Preparación de la instalación

Configuración de la red

Instale el paquete resolvconf para que pueda aplicarse la configuración DNS indicada en el fichero que se modificará a continuación:

1
apt install -y resolvconf

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

Queda una última etapa: modificar la resolución de nombres interna de la máquina para que resuelva su dirección IP real principal (correspondiente a RIP_MED_WEB_MASTER o RIP_MED_WEB_SLAVE).
Para ello, edite el fichero /etc/hosts y sustituya 127.0.1.1 por RIP_MED_WEB_MASTER o RIP_MED_WEB_SLAVE según el servidor Mediation Controller.

Example

Para un servidor Mediation Controller cuya dirección IP web real sea 10.0.10.10 y cuyo nombre sea mediation-controller.domain.local, el fichero /etc/hosts tendrá el valor siguiente:

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

¡Atención!

Una configuración incorrecta del fichero puede provocar un error al instalar el paquete collectd.

Configuración del gestor de paquetes APT

Suba al directorio /tmp/ del servidor, mediante un cliente SCP, los ficheros descargados desde Systancia Marketplace:

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

Conéctese al servidor como root y ejecute los siguientes comandos para descomprimir el repositorio de Systancia, configurar su uso en APT y autenticarlo.

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

Recomendamos encarecidamente desactivar la instalación de paquetes innecesarios al ejecutar los comandos apt. Para ello, ejecute el siguiente comando:

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

Comprobación de la presencia de la configuración regional en_US.utf8

La instalación del servidor Mediation Controller requiere generar las configuraciones regionales en_US.utf8.
Para comprobar si ya se han generado en el servidor, ejecute el siguiente comando como root:

1
locale -a  | grep en_US.utf8

Si la respuesta del comando muestra en_US.utf8, pase a la etapa siguiente, la configuración de GRUB.
En caso contrario, ejecute los siguientes comandos para añadir esta configuración regional a la máquina:

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

Configuración del gestor de arranque GRUB

Una vez ejecutados estos comandos, debe reiniciar la máquina tras aplicar un ajuste en el gestor de arranque GRUB:

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

Instalación del servidor Mediation Controller de CyberElements Bastion

Instalación de los componentes básicos

Inicie la instalación de los componentes con el siguiente comando, ejecutado como root:

1
apt install -y ipdiva-base

Tras descargar todas las dependencias, se abrirá una ventana que le pedirá seleccionar el tipo de servidor. Seleccione mediation:

Seleccione después el modo de instalación lbMaster:

Seleccione después el modo de instalación lbSlave:

A continuación deberá indicar el puerto de escucha del SSL Router. Este puerto suele ser el 443, pero también puede utilizarse el 8443 si el servidor de mediación solo usa una IP:

Defina después el modo del Cluster en loadbalancing para que la carga de usuarios se reparta entre los dos servidores Mediation Controller:

Indique la dirección IP web virtual del Cluster, VIP_MED_WEB:

Indique la dirección IP SSL virtual del Cluster, VIP_MED_SSL:

Indique la dirección IP virtual de la base de datos de configuración del Cluster, VIP_MED_ZEO:

Indique la dirección IP web real del Mediation Controller MASTER, RIP_MED_WEB_MASTER:

Indique la dirección IP SSL real del Mediation Controller MASTER, RIP_MED_SSL_MASTER:

Indique la dirección IP web real del Mediation Controller SLAVE, RIP_MED_WEB_SLAVE:

Por último, indique la dirección IP SSL real del Mediation Controller SLAVE, RIP_MED_SSL_SLAVE:

¿Qué hacer en caso de error?

Si se ha producido un error en la información introducida, continúe con la instalación del paquete ipdiva-base y utilice después el siguiente comando para reconfigurar el servidor:

1
dpkg-reconfigure ipdiva-base

Instalación de los componentes Cluster

Tras instalar los componentes básicos, hay que instalar los componentes Cluster en los servidores Mediation Controller:

1
apt install -y ipdiva-mediation-cluster

Tras la instalación de los componentes, es necesario reiniciar:

1
reboot

Configuración del Cluster

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.

Instalación de los componentes específicos de CyberElements Bastion

Inicie la instalación de los componentes CyberElements Bastion en los servidores Mediation Controller con el siguiente comando:

1
apt install -y ipdiva-safe-server

Hay que reiniciar los servidores para finalizar la instalación:

1
reboot

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

Instalación de los controladores para la conexión a bases de datos Microsoft SQL

Si desea conectarse a una base de datos externa y esta es un Microsoft SQL Server, hay que instalar controladores ODBC adicionales.

Hay dos versiones disponibles: la versión 17 y la versión 18.

Conexión TLS obligatoria para los controladores en versión 18

El uso de los controladores ODBC 18 exige que la conexión esté cifrada mediante TLS. Para ello, hay que configurar MS SQL Server para el cifrado de las conexiones.

Antes de iniciar la instalación de los controladores ODBC, hay que instalar los paquetes necesarios para la preparación y después preparar el repositorio de Microsoft para la instalación de los paquetes:

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

A continuación, instale los controladores según la versión elegida y configure el sistema para utilizar el comando 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

Los controladores ODBC ya están correctamente instalados.
Si el servidor Mediation Controller tiene acceso a un servidor MS SQL, el siguiente comando debería permitir la conexión al servidor remoto: 

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

Where:

  • SERVER debe sustituirse por el nombre DNS o la dirección IP del servidor MS SQL.
  • INSTANCE_NAME debe sustituirse por el nombre de la instancia a la que conectarse; si no es necesario, elimine también el carácter \.
  • PORT debe sustituirse por el puerto de conexión a la instancia de base de datos MS SQL.
  • USER debe sustituirse por el nombre de usuario con el que se establece la conexión.
Ejemplos

Si el servidor Mediation Controller tiene acceso a un servidor de bases de datos MS SQL en la dirección IP 10.0.10.100, la instancia a la que se accede está a la escucha en el puerto 1433 y la cuenta de acceso es sql-user. El comando de conexión es entonces el siguiente:

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

Si hubiera que indicar la instancia de conexión denominada MSSQLINSTANCE, el comando se modificaría de la siguiente manera:

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

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

  • Configurar la organización

    Configure la organización de CyberElements Bastion.

    Configurar con acceso directo a la base de datos

    Configurar con acceso a la base de datos por el túnel de las Edge Gateways

  • Declarar las Edge Gateways

    Declare la Edge Gateway o las Edge Gateways, o bien la HTML5 Gateway o las HTML5 Gateways, que se van a instalar.

    Crear las Edge Gateways

  • Crear un sitio lógico

    Cree y configure un sitio lógico que agrupe las Edge Gateways y las HTML5 Gateways que pueden acceder a los recursos locales.

    Crear un sitio

  • Instalar una Edge Gateway

    Instale y configure una nueva Edge Gateway con los servidores Mediation Controller recién instalados.
    También se configurará una instancia de HTML5 Gateway.

    Instalar