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.

Transferência do espelho e das ferramentas necessárias

O espelho CyberElements Cleanroom 4.6 e a chave de assinatura do repositório da Systancia podem ser transferidos a partir deste link (requer a criação de uma conta de cliente): Systancia Marketplace

Além do espelho e da chave, serão necessárias ferramentas de terceiros para o processo de upgrade:

  • Um cliente SSH (no Windows, pode utilizar o PuTTY)
  • Um cliente SCP (no Windows, podem utilizar-se as ferramentas WinSCP ou FileZilla)

Utilize o cliente SSH para se ligar remotamente ao seu servidor.

Utilize o cliente SCP para transferir ficheiros para a sua máquina remota.

Preparação da instalação

Configuração da rede

Instale o pacote resolvconf para que a configuração DNS indicada no ficheiro de configuração que será modificado em seguida possa ser aplicada:

1
apt install -y resolvconf

É 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

Falta uma última etapa: modificar a resolução de nomes interna da máquina para que resolva o seu endereço IP real principal (correspondente a RIP_MED_WEB_MASTER ou RIP_MED_WEB_SLAVE).
Para isso, edite o ficheiro /etc/hosts e substitua 127.0.1.1 por RIP_MED_WEB_MASTER ou RIP_MED_WEB_SLAVE, em função do servidor Mediation Controller.

Example

Para um servidor Mediation Controller cujo endereço IP web real seja 10.0.10.10 e cujo nome seja mediation-controller.domain.local, o ficheiro /etc/hosts terá o valor seguinte:

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

Atenção!

Uma configuração incorreta do ficheiro pode provocar um erro ao instalar o pacote collectd.

Configuração do gestor de pacotes APT

Carregue para o diretório /tmp/ do servidor, através de um cliente SCP, os ficheiros transferidos do Systancia Marketplace:

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

Ligue-se ao servidor como root e execute depois os seguintes comandos para descompactar o repositório da Systancia, configurar a sua utilização no APT e autenticá-lo.

1
2
3
4
5
mv /tmp/systancia.gpg /etc/apt/trusted.gpg.d/
mkdir -p /opt/systancia/repository/
tar xvzf /tmp/cleanroom-4.6*.tgz -C /opt/systancia/repository/
echo "deb file:///opt/systancia/repository/ bookworm ipdiva" > /etc/apt/sources.list.d/systancia.list
apt update

Recomendamos vivamente que desative a instalação de pacotes desnecessários ao executar os comandos apt. Para isso, execute o seguinte comando:

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

Verificação da presença da configuração regional en_US.utf8

A instalação do servidor Mediation Controller exige a geração das configurações regionais en_US.utf8.
Para verificar se já foram geradas no servidor, execute o seguinte comando como root:

1
locale -a  | grep en_US.utf8

Se a resposta do comando apresentar en_US.utf8, passe à etapa seguinte, a configuração do GRUB.
Caso contrário, execute os seguintes comandos para adicionar esta configuração regional à máquina:

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

Configuração do programa de arranque GRUB

Uma vez executados estes comandos, deve reiniciar a máquina depois de aplicar uma definição no programa de arranque GRUB:

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

Instalação do servidor Mediation Controller do CyberElements Bastion

Instalação dos componentes básicos

Inicie a instalação dos componentes com o seguinte comando, executado como root:

1
apt install -y ipdiva-base

Depois de transferidas todas as dependências, abre-se uma janela que lhe pede para selecionar o tipo de servidor. Selecione mediation:

Selecione em seguida o modo de instalação lbMaster:

Selecione em seguida o modo de instalação lbSlave:

Em seguida, terá de indicar a porta de escuta do SSL Router. Esta porta de escuta é habitualmente a 443, mas a porta 8443 também pode ser utilizada se o servidor de mediação usar apenas um IP:

Defina depois o modo do Cluster em loadbalancing para que a carga de utilizadores seja repartida entre os dois servidores Mediation Controller:

Indique o endereço IP web virtual do Cluster, VIP_MED_WEB:

Indique o endereço IP SSL virtual do Cluster, VIP_MED_SSL:

Indique o endereço IP virtual da base de dados de configuração do Cluster, VIP_MED_ZEO:

Indique o endereço IP web real do Mediation Controller MASTER, RIP_MED_WEB_MASTER:

Indique o endereço IP SSL real do Mediation Controller MASTER, RIP_MED_SSL_MASTER:

Indique o endereço IP web real do Mediation Controller SLAVE, RIP_MED_WEB_SLAVE:

Por último, indique o endereço IP SSL real do Mediation Controller SLAVE, RIP_MED_SSL_SLAVE:

O que fazer em caso de erro?

Se existir um erro nas informações introduzidas, continue a instalação do pacote ipdiva-base e utilize depois o seguinte comando para reconfigurar o servidor:

1
dpkg-reconfigure ipdiva-base

Instalação dos componentes Cluster

Depois de instalar os componentes básicos, é necessário instalar os componentes Cluster nos servidores Mediation Controller:

1
apt install -y ipdiva-mediation-cluster

Após a instalação dos componentes, é necessário reiniciar:

1
reboot

Configuração do Cluster

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.

Instalação dos componentes específicos do CyberElements Bastion

Inicie a instalação dos componentes CyberElements Bastion nos servidores Mediation Controller com o seguinte comando:

1
apt install -y ipdiva-safe-server

É necessário reiniciar os servidores para concluir a instalação:

1
reboot

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

Instalação dos controladores para a ligação a bases de dados Microsoft SQL

Se quiser ligar-se a uma base de dados externa e esta for um Microsoft SQL Server, é necessário instalar controladores ODBC adicionais.

Estão disponíveis duas versões: a versão 17 e a versão 18.

Ligação TLS obrigatória para os controladores na versão 18

A utilização dos controladores ODBC 18 exige que a ligação seja cifrada com TLS. Para isso, é necessário configurar o MS SQL Server para a cifra das ligações.

Antes de iniciar a instalação dos controladores ODBC, é necessário instalar os pacotes necessários à preparação e, em seguida, preparar o repositório da Microsoft para a instalação dos pacotes:

1
2
3
4
apt install -y curl apt-transport-https gpg
curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg
curl https://packages.microsoft.com/config/debian/12/prod.list > /etc/apt/sources.list.d/mssql-release.list
apt update

Instale em seguida os controladores de acordo com a versão escolhida e configure o sistema para utilizar o comando sqlcmd:

1
2
3
ACCEPT_EULA=Y apt install -y msodbcsql17 mssql-tools python3-pip
pip install mssql-scripter --break-system-packages
ln -sfn /opt/mssql-tools/bin/sqlcmd /usr/bin/sqlcmd

1
2
3
ACCEPT_EULA=Y apt install -y msodbcsql18 mssql-tools18 python3-pip
pip install mssql-scripter --break-system-packages
ln -sfn /opt/mssql-tools18/bin/sqlcmd /usr/bin/sqlcmd

Os controladores ODBC estão agora corretamente instalados.
Se o servidor Mediation Controller tiver acesso a um servidor MS SQL, o seguinte comando deverá permitir a ligação ao servidor remoto: 

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

Em que:

  • SERVER deve ser substituído pelo nome DNS ou pelo endereço IP do servidor MS SQL.
  • INSTANCE_NAME deve ser substituído pelo nome da instância à qual se pretende ligar; se não for necessário, elimine também o carácter \.
  • PORT deve ser substituído pela porta de ligação à instância de base de dados MS SQL.
  • USER deve ser substituído pelo nome de utilizador com o qual se estabelece a ligação.
Exemplos

Se o servidor Mediation Controller tiver acesso a um servidor de bases de dados MS SQL no endereço IP 10.0.10.100, a instância a que se acede estiver à escuta na porta 1433 e a conta de acesso for sql-user. O comando de ligação é então o seguinte:

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

Se fosse necessário indicar a instância de ligação denominada MSSQLINSTANCE, o comando seria modificado da seguinte forma:

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

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 na página de configuração NTP.

Configurações iniciais no 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

  • Configurar a organização

    Configure a organização do CyberElements Bastion.

    Configurar com acesso direto à base de dados

    Configurar com acesso à base de dados através do túnel dos Edge Gateway

  • Declarar os Edge Gateway

    Declare o Edge Gateway (ou os Edge Gateway) ou o HTML5 Gateway (ou os HTML5 Gateway) a instalar.

    Criar os Edge Gateway

  • Criar um site lógico

    Crie e configure um site lógico que agrupe os Edge Gateway e os HTML5 Gateway que podem aceder aos recursos locais.

    Criar um site

  • Instalar um Edge Gateway

    Instale e configure um novo Edge Gateway com os servidores Mediation Controller recém-instalados.
    Será também configurada uma instância de HTML5 Gateway.

    Instalar