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.

Configuración del sistema

Conexión con la máquina

Cambiar el diseño del teclado

Configuración de la red

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

Tip

Ahora que se han aplicado las configuraciones de red, se puede acceder al servidor a través de SSH.

Cambiar las contraseñas de las cuentas locales

Configuración del nombre de la máquina

Puede cambiar el nombre del servidor configurando el nombre de host del servidor y los archivos de hosts.

Edite el archivo /etc/hostname para especificar el nombre de la máquina.
El producto necesita el nuevo nombre para otra ubicación, por lo que se debe hacer una copia del archivo anterior utilizando el siguiente comando:

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

Es necesario replicar la configuración del archivo /etc/hosts en relación con la dirección IP primaria real de la máquina (RIP_MED_WEB_MASTER).
Para ello, edite el archivo /etc/hosts y compruebe que la segunda línea esté en el siguiente formato:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

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

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

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

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

Es necesario replicar la configuración del archivo /etc/hosts en relación con la dirección IP primaria real de la máquina (RIP_MED_WEB_SLAVE).
Para ello, edite el archivo /etc/hosts y compruebe que la segunda línea esté en el siguiente formato:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

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

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

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

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

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

1
reboot

Modificación de las zonas horarias

Inicialización del Mediation Controller servidor

Inicialización del Mediation Controller servidor

El servidor Mediation Controller se inicializa mediante un script de configuración. Este script reconfigura las direcciones IP del clúster en los diversos servicios del producto y preconfigura las configuraciones requeridas para que funcione un Gateway HTML5.
Ejecutarlo a través de la siguiente línea de comandos como root:

1
/opt/systancia/initializeCluster

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

  • IP VIP HTTPS: dirección IP virtual web del clúster, que es VIP_MED_WEB.
  • IP VIP SSL: dirección IP SSL virtual del clúster, que es VIP_MED_SSL.
  • IP VIP ZIO: dirección IP virtual para la conexión del servidor SLAVEMediation Controller con la base de datos de configuración interna del servidor MASTER, que es VIP_MED_ZEO.
  • IP Master HTTPS: La dirección IP real de la web del servidor MASTER Mediation Controller, que es RIP_MED_WEB_MASTER.
  • IP Master SSL: La dirección IP real para el enrutador SSL del servidor MASTER Mediation Controller, que es RIP_MED_SSL_MASTER.
  • IP Slave HTTPS: La dirección IP real de la web del servidor SLAVE Mediation Controller, que es RIP_MED_WEB_SLAVE.
  • IP Slave SSL: La dirección IP real para el enrutador SSL del servidor SLAVE Mediation Controller, que es RIP_MED_SSL_SLAVE.
  • HTML5 port: puerto de escucha local para redirigir el acceso al servicio de puerta de enlace HTML5; se recomienda introducir el puerto 1234.
  • Gateway: nombre del Edge Gateway; introduzca el nombre del primer Edge Gateway.
  • Organization: nombre de la organización a la que se conectarán las puertas de enlace de Edge y las puertas de enlace HTML5.

Una vez que la inicialización se complete, reinicie el servidor:

1
reboot

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:

Mediation Controller Emparejamiento de servidores

¡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.

Inicialización cibernéticoLos elementos Cleanroom

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

Configurando un servidor de tiempo NTP

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

Configuraciones iniciales de las 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