Ir para o conteúdo

Instalação dos servidores Mediation Controller

Nota

Recordamos que a mudança para root nas máquinas Debian deve ser feita com o seguinte comando:

1
su -

As instruções desta página devem ser aplicadas aos dois servidores Mediation Controller, começando pelo servidor MASTER.
Quando existirem diferenças entre os servidores MASTER e SLAVE, serão assinaladas. Se nada for indicado, as instruções aplicam-se tanto ao servidor MASTER como ao SLAVE.

Configuração do sistema

Ligação à máquina

Por predefinição, existem duas contas nas appliances virtuais: uma conta de utilizador e uma conta de superutilizador.

  • Conta de utilizador
    • Identificador : systancia
    • Palavra-passe: systnci
  • Conta de superutilizador
    • Identificador : root
    • Palavra-passe: systnci

Ligue-se à máquina em modo consola.

Nota

A disposição predefinida do teclado é QWERTY.

Alteração da disposição do teclado

Pode alterar a disposição do teclado com a linha de comandos seguinte:

1
dpkg-reconfigure keyboard-configuration

Aparece um menu que lhe permite escolher outra disposição de teclado.

Utilize depois a linha de comandos seguinte para aplicar e guardar as definições:

1
setupcon -k --save

As definições entram em vigor imediatamente após a execução deste comando.

Configuração da rede

É indispensável configurar um endereço de rede estático para o Mediation Controller. Para isso, é primeiro necessário obter o nome da interface de rede da sua máquina. Execute o seguinte comando como root:

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

Este comando apresenta o nome da interface de rede, o seu estado e os endereços IP atribuídos à interface.

Exemplo

Depois de executado o comando, é apresentado o seguinte resultado:

1
ens192           UP             172.16.0.23/20 172.16.0.27/32 172.16.0.28/32 172.16.0.29/32 172.16.0.24/20

O nome da interface de rede é ens192.

Uma vez obtido o nome da interface de rede, já é possível editar a configuração de rede da máquina.
Edite o ficheiro /etc/network/interfaces para o modificar segundo o modelo seguinte:

 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

Em que:

  • INTERFACE_NAME deve ser substituído pelo nome da interface de rede obtido anteriormente.
  • RIP_MED_WEB_MASTER deve ser substituído pelo endereço IP real principal do servidor, que será o endereço IP através do qual se acederá às consolas web.
  • NETMASK deve ser substituído pela máscara de rede associada ao endereço IP.
  • NETWORK_GATEWAY deve ser substituído pelo gateway de rede predefinido.
  • IP_DNS deve ser substituído pelo endereço IP do servidor DNS. Se for necessário configurar vários servidores (3 no máximo), separe-os com um espaço.
  • DNS_SUFFIX deve ser substituído pelo sufixo DNS a utilizar. Se não for necessário indicar nenhum sufixo, elimine a linha.
  • RIP_MED_SSL_MASTER deve ser substituído pelo endereço IP real secundário do servidor. Será o endereço IP através do qual o SSL Router estará acessível.
Exemplo 
 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, resta apenas reiniciar o serviço networking para carregar a nova configuração de rede: 

1
systemctl restart networking

É indispensável configurar um endereço de rede estático para o Mediation Controller. Para isso, é primeiro necessário obter o nome da interface de rede da sua máquina. Execute o seguinte comando como root:

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

Este comando apresenta o nome da interface de rede, o seu estado e os endereços IP atribuídos à interface.

Exemplo

Depois de executado o comando, é apresentado o seguinte resultado:

1
ens192           UP             172.16.0.25/20 172.16.0.27/32 172.16.0.28/32 172.16.0.29/32 172.16.0.26/20

O nome da interface de rede é ens192.

Uma vez obtido o nome da interface de rede, já é possível editar a configuração de rede da máquina.
Edite o ficheiro /etc/network/interfaces para o modificar segundo o modelo seguinte:

 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

Em que:

  • INTERFACE_NAME deve ser substituído pelo nome da interface de rede obtido anteriormente.
  • RIP_MED_WEB_SLAVE deve ser substituído pelo endereço IP real principal do servidor, que será o endereço IP através do qual se acederá às consolas web.
  • NETMASK deve ser substituído pela máscara de rede associada ao endereço IP.
  • NETWORK_GATEWAY deve ser substituído pelo gateway de rede predefinido.
  • IP_DNS deve ser substituído pelo endereço IP do servidor DNS. Se for necessário configurar vários servidores (3 no máximo), separe-os com um espaço.
  • DNS_SUFFIX deve ser substituído pelo sufixo DNS a utilizar. Se não for necessário indicar nenhum sufixo, elimine a linha.
  • RIP_MED_SSL_SLAVE deve ser substituído pelo endereço IP real secundário do servidor. Será o endereço IP através do qual o SSL Router estará acessível.
Exemplo 
 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, resta apenas reiniciar o serviço networking para carregar a nova configuração de rede: 

1
systemctl restart networking

Sugestão

Agora que as definições de rede foram aplicadas, é possível aceder ao servidor por SSH.

Alteração das palavras-passe das contas locais

A Systancia recomenda vivamente alterar a palavra-passe destas contas depois de a appliance virtual ter sido implementada.

Utilize o comando seguinte e introduza a nova palavra-passe da conta standard systancia:

1
passwd systancia

Repita depois a operação para a conta de superutilizador root:

1
passwd root

Configuração do nome da máquina

O nome do servidor pode ser alterado configurando os ficheiros hostname e hosts do servidor.

Edite o ficheiro /etc/hostname para indicar o nome da máquina.
O produto necessita do novo nome noutra localização, pelo que deve ser feita uma cópia do ficheiro anterior com o seguinte comando:

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

É necessário replicar a configuração do ficheiro /etc/hosts relativamente ao endereço IP real principal da máquina (RIP_MED_WEB_MASTER).
Para isso, edite o ficheiro /etc/hosts e verifique se a segunda linha tem o formato seguinte:

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

Se a máquina se chamar MEDIATION-CONTROLLER-MASTER sem pertencer a um domínio e o seu endereço IP real RIP_MED_WEB_MASTER for 10.0.10.10, o ficheiro seria preenchido da seguinte forma:

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Se a máquina pertencer ao domínio DOMAIN.LOCAL, o ficheiro seria preenchido da seguinte forma:

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

É necessário replicar a configuração do ficheiro /etc/hosts relativamente ao endereço IP real principal da máquina (RIP_MED_WEB_SLAVE).
Para isso, edite o ficheiro /etc/hosts e verifique se a segunda linha tem o formato seguinte:

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

Se a máquina se chamar MEDIATION-CONTROLLER-SLAVE sem pertencer a um domínio e o seu endereço IP real RIP_MED_WEB_SLAVE for 10.0.10.12, o ficheiro seria preenchido da seguinte forma:

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Se a máquina pertencer ao domínio DOMAIN.LOCAL, o ficheiro seria preenchido da seguinte forma:

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

Para aplicar a nova configuração, reinicie o servidor:

1
reboot

Modificação do fuso horário

Por predefinição, a appliance virtual está configurada no fuso horário Europe/Paris.

Para alterar este fuso horário, utilize primeiro o comando seguinte para obter a sintaxe dos fusos horários disponíveis:

1
timedatectl list-timezones

Utilize em seguida a linha de comandos seguinte:

1
timedatectl set-timezone your_time_zone
Exemplo

Para definir o fuso horário para Londres, deve executar-se o comando seguinte:

1
timedatectl set-timezone Europe/London

Verifique o fuso horário do servidor com a linha de comandos seguinte:

1
timedatectl

Inicialização do servidor Mediation Controller

Inicialização do servidor Mediation Controller

O servidor Mediation Controller é inicializado através de um script de configuração. Este script reconfigura os endereços IP do cluster nos diferentes serviços do produto e pré-configura as definições necessárias ao funcionamento de um HTML5 Gateway.
Execute-o com a seguinte linha de comandos como root:

1
/opt/systancia/initializeCluster

O script pedir-lhe-á que introduza as informações seguintes:

  • IP VIP HTTPS: endereço IP web virtual do cluster, ou seja, VIP_MED_WEB.
  • IP VIP SSL: endereço IP SSL virtual do cluster, ou seja, VIP_MED_SSL.
  • IP VIP ZIO: endereço IP virtual para a ligação do servidor Mediation Controller SLAVE à base de dados interna de configuração do servidor MASTER, ou seja, VIP_MED_ZEO.
  • IP Master HTTPS: endereço IP web real do servidor Mediation Controller MASTER, ou seja, RIP_MED_WEB_MASTER.
  • IP Master SSL: endereço IP real do SSL Router do servidor Mediation Controller MASTER, ou seja, RIP_MED_SSL_MASTER.
  • IP Slave HTTPS: endereço IP web real do servidor Mediation Controller SLAVE, ou seja, RIP_MED_WEB_SLAVE.
  • IP Slave SSL: endereço IP real do SSL Router do servidor Mediation Controller SLAVE, ou seja, RIP_MED_SSL_SLAVE.
  • HTML5 port: porta de escuta local para redirecionar o acesso ao serviço HTML5 Gateway; recomendamos indicar a porta 1234.
  • Gateway: nome do Edge Gateway; indique o nome do primeiro Edge Gateway.
  • Organization: nome da organização à qual se ligarão os Edge Gateway e os HTML5 Gateway.

Uma vez concluída a inicialização, reinicie o servidor:

1
reboot

Alteração da palavra-passe da consola /mediation/system do CyberElements Gate

Nesta fase da instalação está disponível uma nova interface de administração: Alterar a palavra-passe

Aplicação das licenças e dos certificados

Ainda na consola /mediation/system, terá de introduzir os certificados e as licenças do servidor Mediation Controller.

Atenção!

A licença e o certificado do SSL Router são específicos do servidor Mediation Controller MASTER ou SLAVE.
Configurar uma licença ou um certificado errados provocará falhas posteriormente.

Aplique a licença e o certificado do componente SSL Router:

  1. Clique no separador Settings.
  2. Selecione SSL Connections no menu.
  3. Procure o certificado do SSL Router.
  4. Introduza a palavra-passe do certificado do SSL Router.
  5. Clique em Apply para aplicar o certificado ao SSL Router.
  6. Selecione o ficheiro de licença do servidor.
  7. Clique em Modify para aplicar a licença do servidor.

Introduza em seguida as informações do certificado do cliente CyberElements Bastion:

  1. Selecione o separador Plugin.
  2. Procure o certificado do cliente CyberElements Bastion.
  3. Introduza a palavra-passe do certificado.
  4. Clique em Apply para aplicar o certificado.

Falta ainda introduzir as informações do certificado do Watchdog:

  1. Selecione o separador Watchdog
  2. Procure o certificado do Watchdog.
  3. Introduza a palavra-passe do certificado.
  4. Clique em Apply para aplicar o certificado.

Para que estas alterações produzam efeito, deve reiniciar o SSL Router e o Watchdog:

Pairing dos servidores Mediation Controller

Atenção!

Neste ponto, ambos os servidores Mediation Controller devem ter sido configurados até à aplicação das licenças e dos certificados.
Se o servidor Mediation Controller SLAVE ainda não estiver configurado, faça-o começando pelo início desta documentação.

A etapa de pairing dos servidores Mediation Controller estabelecerá um vínculo de confiança entre os dois servidores e inicializará o funcionamento em Cluster.

No servidor Mediation Controller SLAVE

Execute o seguinte comando como root para iniciar um pedido de pairing com o servidor Mediation Controller MASTER:

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Substitua RIP_MED_WEB_MASTER pelo endereço IP correspondente.

Exemplo

Se RIP_MED_WEB_MASTER for igual a 10.0.10.10, o comando a introduzir é o seguinte:

1
hostManagerCtl bootstrap 10.0.10.10

No servidor Mediation Controller MASTER

Execute o seguinte comando como root para consultar os pedidos de pairing pendentes e obter o identificador do pedido: 

1
hostManagerCtl getPendingRequests

Execute em seguida o seguinte comando para aceitar o pedido de pairing, substituindo ID pelo identificador obtido com o comando anterior:

1
hostManagerCtl acceptRequest ID
Exemplo

Se o resultado do comando hostManagerCtl getPendingRequests for o seguinte:

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

O comando para aceitar o pedido de pairing é então o seguinte:

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

Para verificar a associação, utilize o seguinte comando no servidor Mediation Controller (seja MASTER ou SLAVE):

1
hostManagerCtl listPeers

O resultado varia em função do servidor no qual o comando é executado:

O resultado esperado no servidor Mediation Controller MASTER é o seguinte:

1
slave -> RIP_MED_WEB_SLAVE
Exemplo 
1
slave -> 10.0.10.12

O resultado esperado no servidor Mediation Controller SLAVE é o seguinte:

1
master -> RIP_MED_WEB_MASTER
Exemplo 
1
master -> 10.0.10.10

No servidor Mediation Controller SLAVE

Pode verificar o estado do bootstrap a partir do servidor SLAVE com o seguinte comando:

1
hostManagerCtl getBootstrapStatus

Um cluster que não apresente nenhum problema de sincronização devolverá o valor 0.

É necessária uma última série de comandos, novamente no servidor SLAVE, para sincronizar um segredo partilhado entre os dois Mediation Controllers:

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2
Para que serve a ligação interservidor?

Trata-se de uma ligação específica do funcionamento em cluster, que permite a um servidor Mediation Controller encaminhar o tráfego para outro servidor Mediation Controller nos casos em que o Edge Gateway de destino não está ligado ao primeiro servidor, mas apenas ao segundo.

Por exemplo, se o servidor Mediation Controller MASTER já não estiver ligado ao Edge Gateway, pode utilizar o vínculo interservidor para alcançar o Edge Gateway através do servidor Mediation Controller SLAVE.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Ligação perdida| GW(Edge Gateway)
    MASTER --> |Ligação entre servidores| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

No servidor Mediation Controller MASTER

Edite o ficheiro /etc/ipdiva/server/remoteServers.xml para indicar o CN do certificado interservidor:

1
2
3
4
5
6
7
8
9
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='SLAVECN'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->

Substitua SLAVECN pelo CN do certificado destinado à ligação interservidor.
Se não souber o CN do certificado interservidor, pode introduzir-se o carácter * (recomendado em caso de dúvida):

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

Tendo em conta as informações seguintes:

  • CN do certificado interservidor: my-interserver-cert

O ficheiro /etc/ipdiva/server/remoteServers.xml do servidor Mediation Controller MASTER seria preenchido da seguinte forma:

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"/>
                -->
Ficheiro completo 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='interserver-documentation-cluster'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->

                <!-- in this example we use a custom certificate, it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl">
                                <cert>/etc/ipdiva/server/ssl/interserver.p12</cert>
                <password>s3cr3t</password>
                <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
                <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
                                <min-version>tls1.3</min-version>
                                <max-version></max-version>
                                <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
                                <cipherlist-tls1.3>TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256</cipherlist-tls1.3>
                <use-cn>no</use-cn>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
                <cert-peername>MASTERCN</cert-peername>
                        </remoteServer>
                -->
        </localCluster>

        <!--
                Intersites connections
        -->
        <intersites localSiteName='localSite1'>
                <!-- An accepted remote connection
                        name : the name of the accepted remote site
                        password : the associated password
                        pattern : a list of pattern of allowed peers for this remote site (separated by ;)
                -->
                <!-- <accept name='david-desktop' password='passwd' pattern='S:[^@]+@ipdiva'/> -->

                <!-- A connection to a remote site
                        name : is the name of the remoteSite
                        password : the password to use to connect
                        pattern : a list of pattern (regex) of the gateway that could be addressed via this link (separated by ;)
                        connect : a connection URL

                        the body can contain traditional TlsData parameters:
                            <cert>file.p12</cert>
                            <password>....</password>
                            <cadir>....</cadir>
                -->
                <!--
                        <remoteSite name='remoteSiteName'
                                        password='mypass'
                                        pattern='S:gw1@ipdiva;S:gw2@ipdiva'
                                        connect="192.168.0.168:9002" />
                -->
        </intersites>


</remoteConfig>

No servidor Mediation Controller SLAVE

Envie o certificado interservidor para o Mediation Controller SLAVE, no diretório /tmp/.
Execute em seguida os seguintes comandos como root para o mover para o diretório de destino com as permissões adequadas:

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

Edite em seguida o ficheiro /etc/ipdiva/server/remoteServers.xml para adicionar o conteúdo seguinte à etiqueta <remoteConfig> (a antiga etiqueta <localCluster> pode ser eliminada 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>

Substitua:

  • MASTERCN: indique o CN do certificado do SSL Router do Mediation Controller MASTER, que é habitualmente RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER: corresponde ao endereço IP secundário do Mediation Controller MASTER.
  • PORT_RIP_MED_SSL_MASTER: é a porta de escuta do SSL Router do Mediation Controller MASTER; é habitualmente a 443.
  • INTERSERVER.P12: nome do certificado destinado ao interservidor.
  • PASSWORD: palavra-passe do certificado interservidor.
Exemplo

Tendo em conta as informações seguintes:

  • Nome do certificado interservidor: my-interserver-cert.p12
  • Palavra-passe do certificado interservidor: MySecurePassword
  • RIP SSL do Mediation Controller MASTER: 10.0.10.11
  • Porta na RIP SSL do Mediation Controller MASTER: 443
  • CN do certificado do Mediation Controller MASTER: 10.0.10.11

O ficheiro /etc/ipdiva/server/remoteServers.xml do servidor Mediation Controller SLAVE seria preenchido da seguinte forma:

 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>
Ficheiro completo 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='10.0.10.11'>
            <remoteServer connect="10.0.10.11:443:ssl">
                <cert>/etc/ipdiva/server/ssl/my-interserver-cert.p12</cert>
                <password>MySecurePassword</password>
                <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
                <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
                <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
                <use-cn>no</use-cn>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
                <cert-peername>10.0.10.11</cert-peername>
            </remoteServer>
        </localCluster>

        <!--
                Intersites connections
        -->
        <intersites localSiteName='localSite1'>
                <!-- An accepted remote connection
                        name : the name of the accepted remote site
                        password : the associated password
                        pattern : a list of pattern of allowed peers for this remote site (separated by ;)
                -->
                <!-- <accept name='david-desktop' password='passwd' pattern='S:[^@]+@ipdiva'/> -->

                <!-- A connection to a remote site
                        name : is the name of the remoteSite
                        password : the password to use to connect
                        pattern : a list of pattern (regex) of the gateway that could be addressed via this link (separated by ;)
                        connect : a connection URL

                        the body can contain traditional TlsData parameters:
                            <cert>file.p12</cert>
                            <password>....</password>
                            <cadir>....</cadir>
                -->
                <!--
                        <remoteSite name='remoteSiteName'
                                        password='mypass'
                                        pattern='S:gw1@ipdiva;S:gw2@ipdiva'
                                        connect="192.168.0.168:9002" />
                -->
        </intersites>


</remoteConfig>

Modifique a configuração do SSL Router SLAVE executando o seguinte comando:

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

Nos servidores Mediation Controller MASTER e SLAVE

Reinicie o SSL Router para aplicar as definições do vínculo interservidor:

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

Para confirmar que o vínculo interservidor funciona corretamente, o seguinte comando deve devolver um resultado:

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

O comando anterior deve produzir um log que contenha o seguinte: TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers, and 0 multicast group(s).
Se não for apresentado nenhum log deste tipo, verifique a configuração efetuada neste capítulo.

Na consola web /mediation/system do Mediation Controller MASTER

Ative a ligação interservidor entre os dois Mediation Controllers editando o host virtual SSL default:

Preencha os diferentes campos seguindo as indicações abaixo e ative a funcionalidade de vínculo interservidor selecionando a caixa de verificação Is cross-server linking configured?:

  • Public address for plugin connections: corresponde a VIP_MED_SSL seguido da sua porta de escuta (habitualmente 443).
  • Actual public IP addresses for web connections: corresponde ao par de endereços IP web reais (RIP_MED_WEB_MASTER e RIP_MED_WEB_SLAVE) com as respetivas portas, uma linha por par de endereço IP e porta.
  • Actual public IP addresses for SSL connections: corresponde ao par de endereços IP SSL reais (RIP_MED_SSL_MASTER e RIP_MED_SSL_SLAVE) com as respetivas portas, uma linha por par de endereço IP e porta.

Inicialização do CyberElements Bastion

Ligação à base de dados PostgreSQL

Para funcionar, o CyberElements Bastion necessita de utilizar uma base de dados (BD) PostgreSQL externa para armazenar as suas definições e os diversos logs na consola /system.
Se a BD estiver diretamente acessível a partir dos servidores Mediation Controller, passe diretamente à etapa de inicialização da BD.

Ligação a uma base de dados situada na LAN

Para permitir a ligação a uma base de dados situada na LAN sem abrir um fluxo da DMZ para a LAN, o fluxo da base de dados será redirecionado através de um túnel TLS entre os Edge Gateway e os Mediation Controllers.
Para isso, é necessário configurar um Edge Gateway (ou dois Edge Gateway) utilizando a tecnologia CyberElements Gate subjacente.

Declaração dos Edge Gateway CyberElements Gate

Para isso, comece por se ligar à consola /mediation/system do CyberElements Gate.

Vá em seguida ao menu «Organizations» e clique em «Add»:

Introduza o nome da organização, que deve ser diferente do atribuído ao CyberElements Bastion (por exemplo, tunnel), e indique pelo menos uma licença de sessão de utilizador, bem como a palavra-passe da conta admin:

Ligue-se à interface de administração da organização criada anteriormente com a conta admin, acedendo a /gate/admin:

Declare em seguida os dois Edge Gateway que serão utilizados para estabelecer o túnel.
À esquerda, passe o cursor sobre Infrastructure, clique em Gateways e depois no botão Add:

Introduza o nome do primeiro Edge Gateway e confirme a entrada:

Informação

Recordamos que o nome de um Edge Gateway está vinculado ao certificado que utilizará para se autenticar junto do SSL Router do Mediation Controller.
Este nome adota a forma seguinte <GW_NAME>@<ORGANIZATION_NAME>, em que <GW_NAME> corresponde ao nome do Edge Gateway e <ORGANIZATION_NAME> ao nome da organização criada na consola de sistema do CyberElements Gate.

Repita a etapa de declaração de Edge Gateway para o segundo Edge Gateway.

Ligações e configuração do túnel nos Edge Gateway

Informação

As etapas seguintes podem ser replicadas nos dois Edge Gateway utilizados para o túnel de acesso à base de dados.

Pré-requisitos

Para concluir esta parte, terá de utilizar uma das opções seguintes:

Em primeiro lugar, utilize uma ferramenta como o WinSCP ou o FileZilla para transferir por SCP, para o diretório /tmp/ do Edge Gateway, o certificado necessário para a ligação.

Ligue-se em seguida por SSH e mude para root.

Para ligar o Edge Gateway aos dois Mediation Controllers, é necessário criar duas novas instâncias de Edge Gateway: uma ligar-se-á ao Mediation Controller MASTER e a outra ao Mediation Controller SLAVE.
Para as criar, execute os seguintes comandos:

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

Copie o ficheiro do certificado para os diretórios /etc/ipdiva/gateway-tunnel-master/ssl/ e /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/

Substitua <CERT_NAME> pelo nome do certificado que o Edge Gateway deve utilizar para se ligar ao Mediation Controller.

Configure as instâncias de Edge Gateway para que possam ligar-se aos Mediation Controllers.
As configurações diferem em função do Mediation Controller a contactar. Efetue ambas as configurações:

Edite o ficheiro /etc/ipdiva/gateway-tunnel-master/gateway.xml e complete-o com as informações seguintes (foram omitidas várias secções, indicadas por […]):

 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>

Substitua os elementos seguintes:

  • @SERVER@: deve ser substituído pelo endereço RIP_MED_SSL_MASTER
  • @SERVERPORT@: deve ser substituído pela porta de escuta do SSL Router, normalmente a 443
  • keyfile.pem: deve ser substituído pelo nome do ficheiro do certificado
  • PASSWORD: deve ser substituído pela palavra-passe do certificado
  • @RPC_PORT@: deve ser substituído por uma porta que não esteja à escuta na máquina; pode utilizar-se a porta 9082
Exemplo

Tendo em conta as informações seguintes:

  • RIP_MED_SSL_MASTER é igual a: 10.0.10.11
  • Porta de escuta do SSL Router: 443
  • Nome do ficheiro do certificado: gate-tunnel.p12
  • Palavra-passe do certificado: Str0ngP@ssw0rd

O ficheiro /etc/ipdiva/gateway-tunnel-master/gateway.xml ficaria configurado da seguinte forma:

 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>
Ficheiro 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 o ficheiro /etc/ipdiva/gateway-tunnel-slave/gateway.xml e complete-o com as informações seguintes (foram omitidas várias secções, indicadas por […]):

 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>

Substitua os elementos seguintes:

  • @SERVER@: deve ser substituído pelo endereço RIP_MED_SSL_SLAVE
  • @SERVERPORT@: deve ser substituído pela porta de escuta do SSL Router, normalmente a 443
  • keyfile.pem: deve ser substituído pelo nome do ficheiro do certificado
  • PASSWORD: deve ser substituído pela palavra-passe do certificado
  • @RPC_PORT@: deve ser substituído por uma porta que não esteja em uso na máquina; pode utilizar-se a porta 9083
Exemplo

Tendo em conta as informações seguintes:

  • RIP_MED_SSL_SLAVE é igual a: 10.0.10.13
  • Porta de escuta do SSL Router: 443
  • Nome do ficheiro do certificado: gate-tunnel.p12
  • Palavra-passe do certificado: Str0ngP@ssw0rd

O ficheiro /etc/ipdiva/gateway-tunnel-slave/gateway.xml ficaria configurado da seguinte forma:

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

Agora que as instâncias estão configuradas para se ligarem aos Mediation Controllers, resta configurá-las para redirecionar para a base de dados a ligação do Mediation Controller.
Para isso, edite o ficheiro /etc/ipdiva/gateway-tunnel-master/services.xml e modifique-o da seguinte forma: 

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>

Substitua DB_SERVER pelo nome DNS ou pelo endereço IP utilizado para se ligar à base de dados, e DB_PORT pela porta de escuta da instância de base de dados.
Replique estas definições na instância que se liga ao servidor Mediation Controller SLAVE, copiando o ficheiro:

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

Por último, inicie as instâncias de Edge Gateway para que estabeleçam a ligação aos Mediation Controllers:

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Configuração do túnel nos Mediation Controllers

Para que o túnel possa ser utilizado pelos Mediation Controllers, resta declarar a sua existência.
Para isso, ligue-se como root aos Mediation Controllers e edite o ficheiro /etc/ipdiva/server/services.xml para adicionar a secção seguinte (foram omitidas várias secções, indicadas por […]):

 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>

Substitua os elementos seguintes:

  • GW1_NAME pelo nome do primeiro Edge Gateway
  • GW2_NAME pelo nome do segundo Edge Gateway
  • ORGANIZATION_NAME pelo nome da organização CyberElements Gate criada anteriormente
Exemplo

Tendo em conta as informações seguintes:

  • Nome do Edge Gateway 1: gate-tunnel-1
  • Nome do Edge Gateway 2: gate-tunnel-2
  • Nome da organização CyberElements Gate: tunnel

O ficheiro /etc/ipdiva/server/services.xml seria preenchido da seguinte forma:

 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>
Ficheiro 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 a nova configuração, reinicie o SSL Router com o seguinte comando:

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

Inicialização da base de dados

Atenção!

Deve criar a base de dados default antes de o CyberElements Bastion a inicializar (não é criada automaticamente).

Para inicializar a base de dados PostgreSQL de configuração do sistema, é necessário configurar primeiro as definições de ligação nos Mediation Controllers.
Para isso, edite o ficheiro /etc/ipdiva/care/databasesettings.ini em ambos os servidores e adicione as entradas seguintes:

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

Substitua os elementos seguintes:

  • DB_USERNAME pelo nome de utilizador utilizado para se ligar à base de dados.
  • DB_PWD pela palavra-passe do utilizador que se liga.
  • DB_HOST pelo endereço IP ou nome DNS utilizado para se ligar à base de dados; se for utilizada uma ligação através de Edge Gateway, terá de indicar 127.0.0.1.
  • DB_PORT pela porta utilizada para se ligar à instância de base de dados; se for utilizada uma ligação através de Edge Gateway, terá de indicar 1432.

A inicialização da base de dados pode ser lançada com os seguintes comandos, a executar apenas num Mediation Controller:

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

Depois disso, resta apenas reiniciar o serviço apache2 nos dois Mediation Controllers para aplicar a inicialização da base de dados do sistema:

1
systemctl restart apache2

Configuração de um servidor de tempo NTP

Recomenda-se configurar um servidor de tempo para manter o relógio do sistema atualizado. As etapas necessárias são descritas em a página de configuração NTP.

Configurações iniciais do CyberElements Bastion

Autorização de acesso às interfaces web com o IP virtual

Por predefinição, não é permitido ligar-se às interfaces web do produto CyberElements Bastion com o IP virtual VIP_MED_WEB.
Para adicionar a autorização, execute como root os seguintes comandos nos Mediation Controllers:

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

Substitua IP pelo endereço IP correspondente a VIP_MED_WEB.

Configurações iniciais

Nesta fase, os servidores Mediation Controller estão instalados, mas faltam várias ações a realizar:

  • Alterar as palavras-passe predefinidas

    Altere as palavras-passe predefinidas das consolas de sistema.

    Alterar

  • Instalar os certificados e as licenças

    O Mediation Controller necessita de vários certificados e de uma licença para estar operacional.
    Apenas o certificado do cliente CyberElements Bastion deve ser novamente declarado nos dois Mediation Controllers (utilize os RIP RIP_MED_WEB_MASTER e RIP_MED_WEB_SLAVE).

    Instalar os certificados e a licença

  • Configurar o certificado web

    Configure o certificado web utilizado para se ligar às interfaces web

    Configurar

  • Declarar um nome DNS

    Adicione um nome DNS autorizado a ligar-se às interfaces web.

    Adicionar