Saltar a contenido

Instalación de Mediation Controller servidores

Nota

Como recordatorio, el cambio a root en las máquinas Debian debe hacerse con el siguiente comando:

1
su -

Las instrucciones dadas en esta página deben replicarse en ambos servidores Mediation Controller, comenzando por el servidor MASTER primero.
Cuando aparezcan diferencias entre los servidores MASTER y SLAVE, se resaltarán. Si no se menciona esto, entonces las instrucciones se aplican tanto a los servidores MASTER como a los SLAVE.

Descarga del espejo y las herramientas necesarias

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

Además del espejo y la llave, se requerirán herramientas de terceros para el proceso de actualización:

Usa el cliente SSH para conectarte de forma remota a tu servidor.

Usa el cliente SCP para transferir archivos a tu máquina remota.

Preparación para la instalación

Configuración de la red

Instale el paquete resolvconf para que se pueda aplicar la configuración DNS especificada en el archivo de configuración que se modificará en breve:

1
apt install -y resolvconf

Es imperativo definir una dirección de red estática para el Mediation Controller. Para ello, primero necesita recuperar el nombre de la interfaz de red de su 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

Después de ejecutar el comando, se muestra la siguiente salida:

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, ahora es posible editar la configuración de red de la máquina.
Editar el archivo /etc/network/interfaces para modificarlo utilizando la siguiente plantilla:

 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

En el caso de:

  • INTERFACE_NAME debe sustituirse por el nombre de la interfaz de red que se haya obtenido anteriormente.
  • RIP_MED_WEB_MASTER debe sustituirse por la dirección IP real principal del servidor, que será la dirección IP a través de la cual se podrá 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 pasarela de red predeterminada.
  • IP_DNS debe sustituirse por la dirección IP del servidor DNS. Si se necesitan configurar varios servidores (máximo 3), sepárelos con un espacio.
  • DNS_SUFFIX debe ser sustituido por el sufijo DNS que se utilizará. Si no es necesario introducir ningún sufijo, borrar la línea.
  • RIP_MED_SSL_MASTER debe ser sustituido por la dirección IP real secundaria del servidor. Esta será la dirección IP a través de la cual se podrá acceder al router SSL.
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, sólo queda reiniciar el servicio networking para cargar la nueva configuración de red:

1
systemctl restart networking

Es imperativo definir una dirección de red estática para el Mediation Controller. Para ello, primero necesita recuperar el nombre de la interfaz de red de su 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

Después de ejecutar el comando, se muestra la siguiente salida:

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, ahora es posible editar la configuración de red de la máquina.
Editar el archivo /etc/network/interfaces para modificarlo utilizando la siguiente plantilla:

 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

En el caso de:

  • INTERFACE_NAME debe sustituirse por el nombre de la interfaz de red que se haya obtenido anteriormente.
  • RIP_MED_WEB_SLAVE debe sustituirse por la dirección IP real principal del servidor, que será la dirección IP a través de la cual se podrá 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 pasarela de red predeterminada.
  • IP_DNS debe sustituirse por la dirección IP del servidor DNS. Si se necesitan configurar varios servidores (máximo 3), sepárelos con un espacio.
  • DNS_SUFFIX debe ser sustituido por el sufijo DNS que se utilizará. Si no es necesario introducir ningún sufijo, borrar la línea.
  • RIP_MED_SSL_SLAVE debe ser sustituido por la dirección IP real secundaria del servidor. Esta será la dirección IP a través de la cual se podrá acceder al router SSL.
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, sólo queda reiniciar el servicio networking para cargar la nueva configuración de red:

1
systemctl restart networking

Queda un paso final: modificar la resolución interna de nombre de la máquina para que resuelva su dirección IP primaria real (correspondiente a RIP_MED_WEB_MASTER o RIP_MED_WEB_SLAVE).
Para ello, edite el archivo /etc/hosts y reemplace 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 es 10.0.10.10 y cuyo nombre es mediation-controller.domain.local, el archivo /etc/hosts tendrá el siguiente valor:

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

¡Cuidado!

Una configuración incorrecta del archivo puede causar un error al instalar el paquete collectd.

Configuración del administrador de paquetes APT

Coloque los archivos recuperados del mercado de Systancia en el servidor en /tmp/ usando un cliente SCP:

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

Inicie sesión en el servidor como root, luego ejecute los siguientes comandos para descifrar el repositorio de Systancia, configure su uso en APT y autenticalo.

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

Se recomienda encarecidamente desactivar la instalación de paquetes innecesarios cuando se ejecuta el comando 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 región en_US.utf8

La instalación del servidor Mediation Controller requiere la generación de locales 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 el comando de retorno muestra en_US.utf8, entonces procede al siguiente paso de la configuración GRUB.
De lo contrario, ejecute los siguientes comandos para añadir esta configuración local 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

Configurando el programa de arranque GRUB

Una vez ejecutados estos comandos, debe reiniciar la máquina después de aplicar una configuración en el programa de arranque GRUB:

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

Instalación de la cibernéticoLos elementos Cleanroom Mediation Controller servidor

Instalación de los componentes básicos

Comience a instalar los componentes utilizando el siguiente comando como root:

1
apt install -y ipdiva-base

Después de descargar todas las dependencias, se abrirá una ventana que le pedirá que seleccione el tipo de servidor. mediation:

El servidor /// tab | MASTERMediation Controller Luego seleccione el modo de instalación lbMaster:

///

El servidor /// tab | SLAVEMediation Controller Luego seleccione el modo de instalación lbSlave:

///

Entonces tendrá que introducir el puerto que el SSL Router escuchará. Este puerto de escucha se establece generalmente en 443 pero el puerto 8443 también se puede utilizar si sólo una IP es utilizada por el servidor de mediación:

A continuación, configure el modo de clúster en loadbalancing para que la carga de usuario se distribuya entre los dos servidores de controladores de mediación:

Especificar la dirección IP virtual web del grupo, VIP_MED_WEB:

Se indicará la dirección IP SSL virtual del clúster, VIP_MED_SSL:

Se indicará la dirección IP virtual de la base de datos de configuración del clúster, VIP_MED_ZEO:

Se indica la dirección IP de la Web real de las MASTER Mediation Controller, RIP_MED_WEB_MASTER:

Se indica la dirección IP de la Web real de las MASTER Mediation Controller, RIP_MED_SSL_MASTER:

Se indica la dirección IP de la Web real de las SLAVE Mediation Controller, RIP_MED_WEB_SLAVE:

Por último, introduzca la dirección IP web real de las SLAVE Mediation Controller, RIP_MED_SSL_SLAVE:

¿Qué hacer en caso de error?

Si hay un error en la información introducida, continúe con la instalación del paquete ipdiva-base y luego use el siguiente comando para reconfigurar el servidor:

1
dpkg-reconfigure ipdiva-base

Instalación de los componentes del grupo

Después de instalar los componentes básicos, los componentes del clúster deben instalarse en los servidores de los controladores de mediación:

1
apt install -y ipdiva-mediation-cluster

Después de instalar los componentes, se requiere un reinicio:

1
reboot

Configuración del grupo

Cambiando la contraseña de la ciberelements puerta /mediation/system consola

En esta fase de la instalación, se dispone de una nueva interfaz de administración: Cambiar la contraseña

Aplicación de las licencias y certificados

Todavía en la consola /mediation/system, tendrá que introducir los certificados y licencias para el servidor Mediation Controller.

¡Cuidado!

La licencia y el certificado de SSL Router son específicos para el MASTER o bien SLAVE Mediation Controller El servidor.
La configuración de la licencia o certificado incorrecto causará fallas en el funcionamiento posterior.

Aplicar la licencia y el certificado para el componente SSL Router:

  1. Haga clic en el Settings - ¿Qué es eso?
  2. Seleccione SSL Connections en el menú.
  3. Busque el certificado para el router SSL.
  4. Introduzca la contraseña para el certificado de enrutador SSL.
  5. Haga clic en Apply para aplicar el certificado al enrutador SSL.
  6. Seleccione el archivo de licencia del servidor.
  7. Haga clic en Modify para aplicar la licencia del servidor.

A continuación, introduzca la información para el certificado para el cliente cyberelements Cleanroom:

  1. Seleccione la pestaña Plugin.
  2. Buscar el certificado de cliente cyberelements Cleanroom.
  3. Ingrese la contraseña del certificado.
  4. Haga clic en Apply para aplicar el certificado.

Todavía necesita introducir la información para el certificado de perro guardián:

  1. Seleccione la pestaña Watchdog
  2. Busca el certificado de perro guardián.
  3. Ingrese la contraseña del certificado.
  4. Haga clic en Apply para aplicar el certificado.

Para que estos cambios surtan efecto, es necesario reiniciar el router SSL y el Watchdog:

Servidores de control de mediación de coincidencia

¡Cuidado!

En esta fase, ambos Mediation Controller los servidores deben haber sido configurados hasta el punto de que aplica las licencias y certificados.
Si el servidor SLAVE Mediation Controller aún no ha sido configurado, por favor vuelva al comienzo de esta documentación.

El paso de emparejamiento del servidor Mediation Controller establecerá un enlace de confianza entre los dos servidores e inicializará la operación del clúster.

En el servidor SLAVE Mediation Controller

Ejecutar el siguiente comando, como root, para establecer una solicitud de emparejamiento al servidor MASTER Mediation Controller:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Se sustituye RIP_MED_WEB_MASTER por la dirección IP correspondiente.

Ejemplo

Si RIP_MED_WEB_MASTER es igual a 10.0.10.10, entonces el comando para introducir es el siguiente:

1
hostManagerCtl bootstrap 10.0.10.10

En el servidor MASTER Mediation Controller

Ejecutar el siguiente comando como root para comprobar si hay solicitudes de emparejamiento pendientes y recuperar el ID de solicitud:

1
hostManagerCtl getPendingRequests

Luego ejecute el siguiente comando para aceptar la solicitud de emparejamiento, reemplazando ID con el ID recuperado con el comando anterior:

1
hostManagerCtl acceptRequest ID
Ejemplo

Si el hostManagerCtl getPendingRequests el comando devuelve lo siguiente:

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

Así que el comando para aceptar la solicitud de emparejamiento es el siguiente:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

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

1
hostManagerCtl listPeers

El resultado será diferente dependiendo del servidor en el que se ejecute el comando:

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

1
slave -> RIP_MED_WEB_SLAVE
Ejemplo

slave -> 10.0.10.12

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

1
master -> RIP_MED_WEB_MASTER
Ejemplo

master -> 10.0.10.10

En el servidor SLAVE Mediation Controller

Puede comprobar el estado de arranque desde el servidor SLAVE usando el siguiente comando:

1
hostManagerCtl getBootstrapStatus

Un clúster que no está experimentando ningún problema de sincronización devolverá el valor 0.

Se requiere una serie final de comandos, nuevamente en el servidor SLAVE, para sincronizar un secreto compartido entre ambos Controladores de Mediación:

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2
¿Cuál es el propósito de la conexión entre servidores?

Esta es una conexión especial para el funcionamiento de clúster que permite a un servidor Mediation Controller enrutar el tráfico a otro servidor Mediation Controller en los casos en que el destino Edge Gateway no está conectado al primer servidor sino solo al segundo.

Por ejemplo, si el MASTER Mediation Controller el servidor ya no está conectado al Edge Gateway, puede utilizar el enlace interserver para llegar a la Edge Gateway por medio de SLAVE Mediation Controller El servidor.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Connection lost| GW(Edge Gateway)
    MASTER --> |Interserver link| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

En el servidor MASTER Mediation Controller

Editar el archivo /etc/ipdiva/server/remoteServers.xml para indicar la NC del certificado interserver:

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

Se sustituye SLAVECN por la NC del certificado destinado a la conexión entre servidores.
Si no conoce la NC del certificado interserver, puede introducir el carácter * ( se recomienda si tiene dudas):

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 siguiente información:

  • Certificado de interconexión entre servidores CN: my-interserver-cert

El /etc/ipdiva/server/remoteServers.xml archivo en el Mediation Controller MASTER Servidor 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"/>
                -->
Archivo 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
<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 SLAVE Mediation Controller

Enviar el certificado interserver a la SLAVE Mediation Controller en el directorio /tmp/.
Luego ejecute los siguientes comandos como root para moverlo al directorio de destino con los permisos apropiados:

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 archivo /etc/ipdiva/server/remoteServers.xml para agregar el siguiente contenido a la etiqueta <remoteConfig> (la etiqueta <localCluster> antigua se puede eliminar 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>

Sustituir:

  • MASTERCN: especificar la CN del certificado de enrutador SSL del MASTER Mediation Controller, que suele ser RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER: corresponde a la dirección IP secundaria de la MASTER Mediation Controller.
  • PORT_RIP_MED_SSL_MASTER: corresponde al puerto escuchado por el enrutador SSL del servidor MASTER Mediation Controller , que generalmente es 443.
  • INTERSERVER.P12: nombre del certificado destinado al interserver.
  • PASSWORD: contraseña del certificado entre servidores.
Ejemplo

Teniendo en cuenta la siguiente información:

  • Nombre del certificado interservidor: my-interserver-cert.p12
  • Pase de certificado entre servidores: MySecurePassword
  • RIP SSL de las Mediation Controller MASTER: 10.0.10.11
  • Puerto en el RIP SSL de la Mediation Controller MASTER: 443
  • CN del certificado Mediation Controller MASTER: 10.0.10.11

El /etc/ipdiva/server/remoteServers.xml archivo en el Mediation Controller SLAVE Servidor 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>
Archivo 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
<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>

Modificar el SLAVE Configuración del router SSL ejecutando el siguiente comando:

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

En el MASTER y SLAVE Mediation Controller servidores

Reinicie el enrutador SSL para aplicar las configuraciones de enlace entre servidores:

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

Para confirmar que el enlace interserver está funcionando correctamente, el siguiente comando debe devolver un resultado:

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

El comando anterior debe devolver un registro que contenga este 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 el /mediation/system Consola web del MASTER Mediation Controller

Habilitar la conexión entre servidores entre ambos controladores de mediación mediante la edición de la default SSL virtual de acogida:

Configurar los diversos campos utilizando la información que se muestra a continuación y habilitar la función de conexión entre servidores comprobando la caché Is interserver configured?:

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

Instalación de sistemas de cibernéticoLos elementos Cleanroom componentes

Comience a instalar los componentes cyberelements Cleanroom en los servidores de los controladores de mediación utilizando el siguiente comando:

1
apt install -y ipdiva-safe-server

Los servidores deben reiniciarse para completar la instalación:

1
reboot

Conexión con la base de datos PostgreSQL

Para funcionar, cyberelements Cleanroom requiere el uso de una base de datos PostgreSQL externa (DB) para almacenar sus configuraciones y varios registros en la consola /system.
Si la base de datos es directamente accesible desde los servidores Mediation Controller, proceda directamente al paso de inicialización de la base de datos .

Conexión a una base de datos en la red local

Para permitir la conexión a una base de datos situada en la LAN sin abrir una DMZ al flujo de LAN, el flujo de la base de datos se redirigirá a través de un túnel TLS entre las puertas de enlace de borde y los controladores de mediación.
Para lograrlo, es necesario configurar una Edge Gateway (o dos Edge Gateways) utilizando la tecnología subyacente de cyberelements Gate.

Declaración de elementos cibernéticosEntradas de los bordes de las puertas

Para hacer esto, comience por iniciar sesión en la consola /mediation/system de cyberelements Gate.

Luego vaya al menú Organizaciones y haga clic en Agregar:

Introduzca el nombre de la organización, que debe ser diferente del asignado a los elementos cyberCleanroom (por ejemplo tunnel), defina al menos una licencia de sesión de usuario y la contraseña de la cuenta admin:

Inicie sesión en la interfaz de administración de la organización creada previamente con la cuenta admin y vaya a /gate/admin:

Entonces declara las dos puertas de entrada que se utilizarán para establecer el túnel.
En la izquierda, pase el cursor sobre Infrastructure y haga clic en Gateways, luego haga clic en el botón Add:

Indique el nombre del primer Edge Gateway y confirme su declaración:

Info

Como recordatorio, el nombre de un Edge Gateway está vinculado al certificado que utilizará para autenticarse con el enrutador SSL de la Mediation Controller.
Este nombre tiene la siguiente forma <GW_NAME>@<ORGANIZATION_NAME>, donde <GW_NAME> corresponde al nombre de Edge Gateway y donde <ORGANIZATION_NAME> corresponde al nombre de la organización creada en la consola del sistema cyberelements Gate.

Repetir el paso de declaración Edge Gateway para el segundo Edge Gateway.

Conexiones de túnel y configuración en las puertas de acceso de borde

Info

Los siguientes pasos se pueden replicar en ambas puertas de enlace de los bordes utilizadas para el túnel para acceder a la base de datos.

Requisitos previos

Para completar esta parte, deberá utilizar cualquiera de las siguientes:

En primer lugar, utilice una herramienta como WinSCP o FileZilla para enviar el certificado que permite la conexión al directorio Edge Gateway /tmp/ a través de SCP.

Luego conecte a través de SSH y cambie a root.

Para conectar el Edge Gateway a ambos Controladores de Mediación, debe crear dos nuevas instancias Edge Gateway de modo que una se conecte al MASTER Mediation Controller y la segunda se conecte al SLAVE Mediation Controller.
Para crearlos, ejecute los siguientes comandos:

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

Copiar el archivo de 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/

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

Configurar las instancias Edge Gateway para permitirles conectarse a los controladores de mediación.
Las configuraciones varían según el Mediation Controller que se desea contactar.

Edite el archivo /etc/ipdiva/gateway-tunnel-master/gateway.xml y complete con la siguiente información (se han omitido varias secciones y están marcadas con […]):

 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>

Se sustituyen los siguientes elementos:

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

Teniendo en cuenta la siguiente información:

  • RIP_MED_SSL_MASTER es igual a: 10.0.10.11
  • Puerto de escucha del enrutador SSL: 443
  • Nombre del archivo del certificado: gate-tunnel.p12
  • Pase de certificado: Str0ngP@ssw0rd

El /etc/ipdiva/gateway-tunnel-master/gateway.xml archivo se configuraría 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>
Archivo 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 archivo /etc/ipdiva/gateway-tunnel-slave/gateway.xml y complete con la siguiente información (se han omitido varias secciones y están marcadas con […]):

 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>

Se sustituyen los siguientes elementos:

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

Teniendo en cuenta la siguiente información:

  • RIP_MED_SSL_SLAVE es igual a: 10.0.10.13
  • Puerto de escucha del enrutador SSL: 443
  • Nombre del archivo del certificado: gate-tunnel.p12
  • Pase de certificado: Str0ngP@ssw0rd

El /etc/ipdiva/gateway-tunnel-slave/gateway.xml archivo se configuraría 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>
Archivo 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 Controladores de Mediación, aún necesitan ser configuradas para redirigir la conexión Mediation Controller a la base de datos.
Para ello, edite el archivo /etc/ipdiva/gateway-tunnel-master/services.xml 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>

Reemplazar DB_SERVER con el nombre DNS o la dirección IP para conectarse a la base de datos y DB_PORT con el puerto de escucha de la instancia de la base de datos.
Replicar la configuración para la instancia de conexión al servidor SLAVE Mediation Controller mediante la copia del archivo:

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

Por último, iniciar las instancias Edge Gateway para que establezcan una conexión con los controladores de mediación:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Configuración del túnel de los controladores de mediación

Para que el túnel pueda ser usado por los Controladores de Mediación, aún necesitas declarar su existencia.
Para ello, inicie sesión como root en los Controladores de Mediación y edite el archivo /etc/ipdiva/server/services.xml para agregar la siguiente sección (se han omitido varias secciones y están marcadas con […]):

 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>

Se sustituyen los siguientes elementos:

  • GW1_NAME por el nombre del primer Edge Gateway
  • GW2_NAME por el nombre del segundo Edge Gateway
  • ORGANIZATION_NAME por el nombre de la organización de la puerta cyberelements que se creó anteriormente
Ejemplo

Teniendo en cuenta la siguiente información:

  • Nombre de Edge Gateway 1: gate-tunnel-1
  • Nombre de Edge Gateway 2: gate-tunnel-2
  • Nombre de la organización ciberelementos Puerta: tunnel

El /etc/ipdiva/server/services.xml El archivo 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>
Archivo 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 enrutador SSL con el siguiente comando:

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

Inicialización de la base de datos

Para iniciar la base de datos PostgreSQL para la configuración del sistema, primero debe declarar cómo conectarse a ella en los Controladores de Mediación.
Para ello, edite el archivo /etc/ipdiva/care/databasesettings.ini en ambos servidores para introducir los siguientes elementos:

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

Se sustituyen los siguientes elementos:

  • 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, deberá introducir 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, entonces deberá introducir 1432.

La inicialización de la base de datos puede iniciarse con los siguientes comandos, ** para ser ejecutado sólo en un Mediation Controller**:

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

Después de eso, todo lo que queda es reiniciar el servicio apache2 ** en ambos Controladores de Mediación** para aplicar la inicialización de la base de datos del sistema:

1
systemctl restart apache2

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

Si desea conectarse a una base de datos externa y es un servidor SQL de Microsoft, entonces se deben instalar controladores ODBC adicionales.

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

Se requiere conexión TLS con los controladores de la versión 18

El uso de los controladores ODBC 18 requiere que la conexión se cifrará utilizando TLS. Para ello, MS SQL Server debe estar configurado para la encriptación de conexiones.

Antes de iniciar la instalación de los controladores ODBC, debe instalar los paquetes necesarios para la preparación, y luego preparar el repositorio de Microsoft para la instalación del paquete:

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 de acuerdo con la versión seleccionada y configure la configuración del sistema para usar 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 están ahora correctamente instalados.
Si el servidor Mediation Controller tiene acceso a un servidor MS SQL, el siguiente comando debe permitir la conexión al servidor remoto:

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

En el caso de:

  • 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 se desea conectar; si no es necesario, también se debe eliminar el carácter de barra trasera.
  • PORT debe sustituirse por el puerto de conexión a la instancia de la base de datos MS SQL.
  • USER debe sustituirse por el nombre de usuario para establecer la conexión.
Ejemplos

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

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

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

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

Configurando un servidor de tiempo NTP

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

Configuraciones iniciales en cibernéticoLos elementos Cleanroom

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

Por defecto, no está permitido conectarse a las interfaces web elementos ciber Cleanroom del producto con la IP virtual VIP_MED_WEB.
Para añadir la autorización, ejecute como root los siguientes comandos en los Controladores de Mediación:

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

Se sustituye IP por la dirección IP correspondiente a VIP_MED_WEB.

Configuraciones iniciales

En esta etapa, los servidores de los controladores de mediación están instalados, pero aún se deben realizar varias acciones:

  • Cambiar las contraseñas predeterminadas

    Cambiar las contraseñas predeterminadas para las consolas del sistema.

    Cambiar

  • Instalar certificados y licencias

    El Mediation Controller requiere varios certificados y una licencia para estar operativo.
    Sólo el certificado para el cliente **elementos cibernéticos ** Cleanroom necesita ser declarado de nuevo en ambos controladores de mediación (utilice el RIP RIP_MED_WEB_MASTER y RIP_MED_WEB_SLAVE).

    Instalar certificados y licencias

  • Configurar el certificado web

    Configurar el certificado web utilizado para conectarse a las interfaces web

    Configurar

  • Declarar un nombre DNS

    Agregar un nombre DNS autorizado para conectarse a interfaces web.

    Añadir

  • Configurar la organización

    Configurar el cibernéticoLos elementos Cleanroom organización de las actividades.

    Configurar con acceso directo a la base de datos

    Configurar con acceso a la base de datos a través del túnel de puertas de enlace de los bordes

  • Declarar las puertas de entrada de borde

    Declarar que el Edge Gateway (s) o el HTML5 Gateway (s) están instalados.

    Crear puertas de enlace

  • Crear un sitio lógico

    Crear y configurar un sitio lógico que agrupa Gateways Edge y Gateways HTML5 que pueden acceder a recursos locales.

    Crear un sitio

  • Instalar un Edge Gateway

    Instalar y configurar un nuevo Edge Gateway con el nuevo sistema de Mediation Controller los servidores.
    También se configurará una instancia de HTML5 Gateway.

    Instalar