Skip to main content

Gateway em Nuvem: runbook de implantação (caso LOGA)

Este documento registra tudo o que foi feito em 30/10/2026 para colocar o MikroTik da unidade LOGA Vila Maria (peer "local 3") funcionando na rede do cliente com o gateway em nuvem, e transforma isso em um roteiro para as próximas unidades, incluindo a migração de Jaguaré, que hoje usa Gateway físico.

A arquitetura e as decisões de projeto estão em Gateway em Nuvem (WireGuard + MikroTik). Leia aquele documento primeiro, principalmente a seção 3 (sentido da comunicação).

Senhas

Este documento não traz senhas. A senha do admin de cada MikroTik e as credenciais dos faciais ficam com o time de implantação. A credencial MQTT do Accelero de cada deploy está no .env do próprio deploy (MQTT_USER e MQTT_PASSWORD).

1. Princípio que guia a configuração​

O gateway em nuvem tem que funcionar como o gateway físico. No facial não se configura nada à mão: no Accelero se cadastra IP, usuário e senha do facial e o gateway faz o resto (servidor de eventos, validação online, faixas, cadastros).

Consequências práticas:

  • Toda a configuração fica em três lugares: MikroTik, servidor WireGuard (VPS) e rede do cliente (TI do cliente).
  • O facial não muda de gateway de rede nem recebe rota. O caminho de volta (facial para nuvem) é resolvido na rede do cliente.

2. Topologia adotada: faciais na rede do cliente​

O MikroTik chegou da fábrica (configuração inicial da Iongrade) segmentando uma sub-rede própria para os faciais, com servidor DHCP. No cliente isso foi desfeito, porque o cliente já tem DHCP e os faciais ficam na rede dele.

                 nuvem (VPS akamai, 172.237.50.20)
                 wg-LOGA 10.77.0.1  +  gateway Dahua 26050 (docker 172.26.0.0/16)
                          │
                          │  WireGuard UDP 51820
                          │
   rede do cliente ── ether1 do MikroTik (DHCP do cliente, ex.: 10.128.10.41)
   10.128.10.0/24          │  wg-LOGA 10.77.0.4
        │                  │
        ├── faciais         ether2 a ether5: só manutenção (192.168.90.1, sem DHCP)
        └── roteador do cliente (10.128.10.254)
PortaPapel
ether1Liga no switch do cliente. Cliente DHCP (pega IP, rota e DNS do cliente). É a "WAN" do MikroTik
ether2 a ether5Bridge de manutenção com IP fixo. Ligue um notebook com IP fixo na mesma faixa para administrar
wg-LOGATúnel para a nuvem

2.1 Os dois sentidos do tráfego​

SentidoQuem iniciaCaminhoO que precisa
Nuvem para facial (cadastro, setConfig, consulta de status)Gateway na VPSgateway → wg-LOGA da VPS → túnel → MikroTik → ether1 com masquerade → facialRota da LAN do cliente na VPS (seção 4). Nada no cliente além do túnel liberado
Facial para nuvem (eventos de acesso em /notification, validação online)Facialfacial → roteador do cliente → MikroTik → túnel → 10.77.0.1:90Rota 10.77.0.0/29 via MikroTik no roteador do cliente (seção 5)

O gateway grava no facial o endereço de eventos HOST_IP:HTTP_PORT do .env do gateway em nuvem (na LOGA, 10.77.0.1:90). O facial entrega esse pacote ao gateway padrão dele, que é o roteador do cliente. Sem a rota no roteador do cliente, os eventos se perdem na internet. Isso não aparece em nenhum teste da nuvem para o facial: o cadastro sincroniza e só os acessos não chegam.

3. MikroTik​

Modelo da LOGA: hEX (E50UG), RouterOS 7.20.8. O MikroTik vem com device-mode em home, que bloqueia /tool fetch e /tool sniffer. Não use fetch para testar porta: ele falha sempre, com not allowed by device-mode.

3.1 Antes de mexer​

/system backup save name=antes-rede-cliente dont-encrypt=yes
/export file=antes-rede-cliente
/export show-sensitive

Guarde também a saída do /export show-sensitive fora do equipamento (tem a chave privada do WireGuard).

3.2 Configuração aplicada​

# 1. Desliga o DHCP da sub-rede de fábrica (desativa, não apaga)
/ip dhcp-server disable [find name=defconf]

# 2. O que sai pelo túnel sai com o IP do MikroTik na VPN (10.77.0.x).
#    Assim a VPS não precisa conhecer a rede do cliente para responder.
/ip firewall nat add chain=srcnat action=masquerade out-interface=wg-LOGA \
    comment="LOGA: trafego para a nuvem sai como 10.77.0.4"

# 3. Gerência do MikroTik pela VPN (SSH e Winbox), só a partir do servidor
/ip firewall filter add chain=input action=accept in-interface=wg-LOGA \
    src-address=10.77.0.1 protocol=tcp dst-port=22,8291 \
    comment="LOGA: gerencia pela VPN" \
    place-before=[find where comment="defconf: drop all not coming from LAN"]

# 4. Eventos dos faciais para o gateway na nuvem.
#    Sem isso, o "drop all from WAN not DSTNATed" derruba a conexão nova
#    que entra pela ether1 (ether1 está na lista WAN).
/ip firewall filter add chain=forward action=accept in-interface=ether1 \
    out-interface=wg-LOGA src-address=10.128.10.0/24 dst-address=10.77.0.1 \
    protocol=tcp dst-port=90 \
    comment="LOGA: faciais enviam eventos ao gateway na nuvem" \
    place-before=[find where comment="defconf: drop all from WAN not DSTNATed"]

# 5. Só se o túnel continuar bloqueado DEPOIS da liberação da TI (seção 7.4):
#    porta de origem nova, para o firewall do cliente abrir uma sessão nova.
#    O destino continua 51820.
/interface wireguard set wg-LOGA listen-port=51822

O que não precisou mudar (já vem certo da configuração padrão):

  • ether1 já é cliente DHCP (/ip dhcp-client, comentário defconf).
  • O masquerade padrão (out-interface-list=WAN) já faz o tráfego da nuvem para o facial sair com o IP do MikroTik na rede do cliente. O roteador do cliente não precisa de rota para a nuvem alcançar os faciais.
  • O forward do túnel para a ether1 já é aceito: a regra de drop padrão só olha o que entra pela WAN.
  • A interface e o peer WireGuard (chave, endpoint, allowed-address=10.77.0.1/32, persistent-keepalive=25s, MTU 1420) já vinham configurados. O allowed-address do lado do MikroTik não precisa conter a rede do cliente.

3.3 Conferência no MikroTik​

/ip dhcp-client print detail                 # status=bound, IP do cliente
/interface wireguard peers print detail      # last-handshake recente, rx crescendo
/ip firewall connection print detail where dst-address~"<IP público da VPS>"

Na tabela de conexões, olhe orig-packets e repl-packets da sessão UDP 51820. Muitos pacotes de ida e só 1 de volta é a assinatura do bloqueio por inspeção de aplicação na rede do cliente (seção 7.1).

3.4 Rede de manutenção​

Com o DHCP desligado, quem liga o notebook na ether2 a ether5 precisa de IP fixo na faixa de manutenção (192.168.90.x/24 na LOGA local 3), sem gateway, para não roubar a rota padrão do notebook. Para alcançar a rede do cliente a partir do notebook, passando pelo MikroTik:

# macOS
sudo route -n add -net <rede do cliente> 192.168.90.1

3.5 Antes de sair do local: exportar a configuração final​

Na LOGA isso não foi feito: o cabo de manutenção foi retirado e o MikroTik foi para o CPD antes de exportar o estado final, e a gerência pela VPN não funcionava (seção 4.4). Sobrou só o backup de antes das mudanças. Faça sempre, ainda com o cabo ligado:

/system backup save name=final-<unidade> dont-encrypt=yes
/export file=final-<unidade>
/export show-sensitive     # guardar fora do equipamento, só internamente (tem a chave privada)

O export sem show-sensitive é o que pode ir para documento ou e-mail. A chave privada do WireGuard permite se passar pelo MikroTik na VPN.

4. Servidor WireGuard (VPS)​

Na LOGA, o servidor é o akamai (root@akamai.iongrade.com.br, mesmo IP de loga.accelerobr.com.br). O WireGuard roda no host, não em container.

4.1 Arquivos​

ArquivoPapel
/etc/wireguard/wg-LOGA.confInterface (10.77.0.1/29, Table = off) e um [Peer] por unidade, com AllowedIPs
/etc/wireguard/wg-LOGA.varsSERVER, SOURCE=172.26.0.0/16 (rede docker do gateway), HTTP=90, TABLE=200, PRIORITY
/usr/local/sbin/iongrade-wireguard-firewallRegras gerais: DROP de entrada pela wg, exceção para a porta 90 do gateway (DOCKER-USER) e ping
/usr/local/sbin/iongrade-wireguard-loga-sitesUma linha por rede de unidade: site "$1" <rede> <IP do peer>/32 <prioridade>

Cada linha site cria, para aquela rede: rota na tabela main e na tabela 200, ip rule from 172.26.0.0/16 to <rede> lookup 200, MASQUERADE do gateway para o túnel e liberação de ping.

4.2 Peers da LOGA (30/10/2026)​

PeerIP na VPNRedes (AllowedIPs) e prioridadeSituação
local 110.77.0.2192.168.88.0/24 (10000)Sem handshake desde ~14/10
local 2, hEX HMG0B9C45S310.77.0.3192.168.89.0/24 (10001)Sem handshake desde ~14/10
local 3, hEX HMG0B8P6WEM, Vila Maria10.77.0.4192.168.90.0/24 (10002), 10.128.10.0/24 (10003)Em operação desde 30/10 ~16:55 (origem 51822), MikroTik no CPD

4.3 Cadastrar a rede do cliente para um peer​

O peer foi criado para a sub-rede de fábrica do MikroTik (192.168.90.0/24). Com os faciais na rede do cliente, a VPS precisa conhecer a rede do cliente. Sem isso, o gateway manda o tráfego para o facial pela internet (ip route get <IP do facial> mostra dev eth0).

ts=$(date +%Y%m%d%H%M%S)
cp -p /etc/wireguard/wg-LOGA.conf /etc/wireguard/wg-LOGA.conf.bak-<unidade>-$ts
cp -p /usr/local/sbin/iongrade-wireguard-loga-sites /root/iongrade-wireguard-loga-sites.bak-$ts

# 1. AllowedIPs do peer no arquivo (persistência)
#    AllowedIPs = 10.77.0.4/32, 192.168.90.0/24, 10.128.10.0/24

# 2. Linha nova no script de sites, com prioridade ainda não usada
#    site "$1" 10.128.10.0/24 10.77.0.4/32 10003

# 3. Aplicar ao vivo, sem derrubar as outras unidades
wg set wg-LOGA peer <chave pública do MikroTik> allowed-ips 10.77.0.4/32,192.168.90.0/24,10.128.10.0/24
/usr/local/sbin/iongrade-wireguard-loga-sites up    # idempotente

Conferência:

wg show wg-LOGA allowed-ips
ip route get <IP de um facial> from 172.26.0.5 iif docker0   # deve sair por dev wg-LOGA table 200
iptables -t nat -S POSTROUTING | grep <rede>
Colisão de faixas

A rede do cliente não pode coincidir com nenhuma rede já roteada na VPS: outras unidades, outras redes de cliente e as redes docker do próprio host. No akamai, as redes docker ocupam de 172.17.0.0/16 a 172.26.0.0/16. Confira com ip route antes de cadastrar. Havendo colisão, a saída é NAT 1:1 (netmap) no MikroTik, publicando a rede do cliente sob uma faixa definida pela Iongrade (ver a seção 5 do documento de arquitetura).

4.4 O host da VPS não conversa por TCP com o túnel​

O INPUT do akamai termina em -A INPUT -i wg-LOGA -j DROP, com exceção só para ICMP, e não tem regra de ESTABLISHED,RELATED. Consequência: o ping do host para o MikroTik ou para um facial funciona, mas uma conexão TCP aberta pelo próprio host (SSH no MikroTik, curl no facial) nunca recebe a resposta. O gateway não é afetado, porque o tráfego dele passa pelo FORWARD do Docker.

  • Para testar um facial, use o container: docker exec dahuagateway-engine-1 curl -s -o /dev/null -w "%{http_code}" http://<IP do facial>/.
  • A gerência do MikroTik pela VPN (regra 3 da seção 3.2) só funciona depois de uma regra como iptables -I INPUT -i wg-LOGA -s 10.77.0.4 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT, que precisa entrar também no iongrade-wireguard-firewall para sobreviver ao restart da interface. Não aplicada em 30/10/2026.

5. Pedido para a TI do cliente​

Texto usado na LOGA, pronto para adaptar:

Unidade <nome>: equipamento Iongrade (MikroTik), IP <IP da ether1>, MAC <MAC da ether1>.

  1. Reserva de DHCP: fixar o IP <IP da ether1> para o MAC <MAC da ether1>.
  2. Liberação no firewall: saída UDP de <IP da ether1> para <IP público da VPS>, porta 51820 (VPN WireGuard), sem inspeção de aplicação ou IPS nesse tráfego.
  3. Rota estática no roteador da rede <rede do cliente>: destino 10.77.0.0/29, próximo salto <IP da ether1>. É por ela que os faciais enviam os acessos ao nosso servidor.
  4. Tráfego assimétrico: com a rota do item 3, a ida dos faciais passa pelo roteador e a volta vem direto do <IP da ether1>. Se o firewall bloqueia rota assimétrica (Fortinet e similares), precisamos que liberem esse caso ou nos avisem.

O MAC a informar é o da ether1 (/interface ethernet get ether1 mac-address), não o admin-mac da bridge. Na LOGA local 3: D0:EA:11:A6:FE:72.

6. Accelero e gateway​

6.1 Cadastro​

  • O gateway em nuvem da LOGA é o 26050 ("Mikrotik"), um container só para todas as unidades da LOGA (/home/iongrade/dahuagateway no akamai).
  • Cada facial é cadastrado no Accelero com o IP real na rede do cliente, usuário e senha, e o gateway 26050. Mais nada.
  • Confira o IP digitado. Na LOGA, um facial estava como ip10.128.10.56: o gateway tenta resolver isso como nome e falha (Could not resolve host).

6.2 Versões mínimas​

ComponenteVersãoPor quê
Gateway Dahua1.7.0Até a 1.6.x, o gateway mandava o campo PictureHttpUpload...OfflineRetransmission, que o facial não reconhece. O facial recusa a configuração inteira do servidor de eventos e nunca envia os acessos
Accelero2.18Exigência da gateway 1.7.0 (comandos de faixas, cartões adicionais e listagem de cadastrados)

6.3 HOST_IP é um só para todas as unidades​

O endereço de eventos gravado nos faciais é o HOST_IP do .env do gateway (10.77.0.1), igual para todas as unidades atendidas por aquele container. Por isso o caminho de volta depende da rota no roteador do cliente (seção 5, item 3).

Melhoria possível no gateway (não implementada): permitir um endereço de eventos por unidade (por exemplo, um mapa "faixa do facial para IP do MikroTik da unidade", com o HOST_IP como padrão) e criar no MikroTik um dst-nat da porta 90 para 10.77.0.1:90. O facial passaria a mandar eventos para um IP da própria rede, como no gateway físico, e o cliente não precisaria criar rota nenhuma. É mudança em gateway, então passa pela revisão do Caio.

7. Diagnóstico: o que aprendemos​

7.1 Handshake funciona, dados não passam​

Sintoma na LOGA: o MikroTik mostra last-handshake recente e mesmo assim o ping para 10.77.0.1 não volta.

Como provar onde está o bloqueio:

OndeComandoLeitura
MikroTik/interface wireguard peers print detail antes e depois de um pingtx sobe e rx fica parado
MikroTik/ip firewall connection print detail where dst-address~"<VPS>"orig-packets alto, repl-packets=1
MikroTikcontador passthrough em /ip firewall raw (o sniffer é bloqueado pelo device-mode)sai, não entra
VPSwg showlatest handshake antigo e transfer received parado
VPStimeout 40 tcpdump -ni any "host <IP público do cliente>"0 pacotes: o tráfego não chega

Se a VPS não recebe nada, o bloqueio está no caminho, quase sempre um firewall com inspeção de aplicação na rede do cliente, que deixa passar o primeiro par de pacotes e corta quando identifica o WireGuard. Se a VPS recebe e não responde, o problema é a VPS (AllowedIPs sem o IP do peer, ou firewall).

tip

Um servidor com AllowedIPs errado continua respondendo aos handshakes. Se nem os handshakes novos têm resposta, não perca tempo no servidor: é o caminho.

7.2 Cadastro sincroniza, acesso não chega​

O sentido facial para nuvem (seção 2.1). Confira, nesta ordem:

  1. O facial tem PictureHttpUpload apontando para 10.77.0.1:90? (configManager.cgi?action=getConfig&name=PictureHttpUpload)
  2. O roteador do cliente tem a rota 10.77.0.0/29 via MikroTik?
  3. O MikroTik tem o forward da porta 90 (seção 3.2, regra 4)?
  4. O gateway está na 1.7.0 (seção 6.2)?

7.3 Gateway na VPS não alcança o facial​

O log do gateway (/home/iongrade/dahuagateway/logs/error.log) mostra cURL error 28: Connection timed out para o IP do facial. Rode ip route get <IP do facial> na VPS: se sair por eth0, falta cadastrar a rede (seção 4.3). Se sair por wg-LOGA, o problema é o túnel (seção 7.1).

7.4 Liberado pela TI e ainda bloqueado​

Na LOGA, depois da liberação, o túnel seguiu exatamente como antes: handshake antigo e rx parado. O firewall do cliente guarda o estado da sessão já classificada como bloqueada, e a regra nova só vale para sessões novas. Como o WireGuard reaproveita a mesma origem e o mesmo destino, a sessão nunca muda.

Correção: trocar a porta de origem no MikroTik (/interface wireguard set wg-LOGA listen-port=51822). A sessão nova passou na hora: ping para 10.77.0.1 em ~13 ms e, na tabela de conexões, repl-packets subindo junto com orig-packets. O servidor aprende o endpoint novo sozinho. Outra saída é a TI limpar as sessões do IP do MikroTik no firewall.

8. Atualizações feitas na LOGA em 30/10/2026​

8.1 Accelero 2.17.2-HF1 para 2.18.0-RC4​

cd /root/docker/loga.accelerobr.com.br/scripts
./makeBackup.sh                                   # gera backup/<data>_iongrade_<deploy>_accelero.tar.gz
./upgradeToNewestVersion.sh -v 2.18.0-RC4 -u 1
Ordem dos parâmetros

No getopts do script, o -u exige um argumento. Em -u -v 2.18.0-RC4, o -u consome o -v como valor, a versão fica vazia e o script atualiza para a "latest" do Ozone (na data, a própria 2.17.2-HF1). O resultado é uma parada completa do deploy sem troca de versão. Use -v <tag> -u 1.

O makeBackup.sh termina com rm: cannot remove '.../mysql/tmp/*.sql' (glob entre aspas no script). O backup é gerado mesmo assim.

8.2 Gateway em nuvem 26050: 1.5.0 para 1.7.0​

O script oficial (gatewaycommon-upgrade.sh) foi feito para hardware dedicado: grava /serialnumber, instala Portainer, chave SSH no root, serviços systemd e logrotate global. Não use no host compartilhado. O pacote 1.7.0 só muda a pasta app (compose, .env-sample e as demais pastas são idênticos à 1.5.0), então a troca foi:

G=/home/iongrade/dahuagateway; ts=$(date +%Y%m%d%H%M%S)
mkdir /root/gw170 && cd /root/gw170
curl -s "https://internal.iongrade.com.br/dahua/versions/iongrade_dahuagateway-v1.7.0.tar.gz.protected" | gunzip | tar x
tar -czf /root/dahuagateway-1.5.0-backup-$ts.tar.gz -C /home/iongrade dahuagateway
cd $G && docker compose stop engine php_fpm
mv $G/app /root/dahuagateway-app-1.5.0-$ts && cp -a /root/gw170/app $G/app
docker compose up -d engine php_fpm

Depois, conferir: HOST_IP no .env inalterado, rede dahuagateway_internal ainda em 172.26.0.0/16 (é a SOURCE das regras do WireGuard) e app/version. O engine reinicia uma vez logo após subir. É normal.

8.3 Gateway físico 26031 (Jaguaré): 1.4.2 para 1.7.0​

Acesso remoto pelo SSH reverso, replicando o start.sh do diacetyl (que é interativo). A primeira mensagem MQTT não abriu o túnel; a segunda sim. Para diagnosticar sem túnel, um receptor HTTP temporário no diacetyl e um curl mandado pelo remotecommand mostram o que o host executou.

No appliance Buildroot, o gateway fica em /opt/iongrade/dahuagateway e o / está quase cheio (94%): grave tudo em /opt. Mesma troca da pasta app da seção 8.2, executada com setsid nohup para não depender do túnel.

Armadilha do hostIP

A 1.7.0 usa /home/iongrade/hostIP como endereço de eventos gravado nos faciais. Nesse appliance o arquivo tinha 192.168.15.9, resto de bancada, e a 1.4.2 não lia esse arquivo. Depois da atualização, os faciais passaram a apontar para um IP inexistente. Correção:

printf '%s' "$(ip -4 -o addr show eth0 | awk '{print $4}' | cut -d/ -f1)" > /home/iongrade/hostIP
cd /opt/iongrade/dahuagateway && docker compose restart engine php_fpm

Confira o campo ip do keepalive no broker e o PictureHttpUpload de um facial. Faça essa conferência em toda atualização de gateway físico para a 1.7.0.

8.4 Ler o broker MQTT da LOGA​

O mosquitto_sub e o mosquitto_pub do container MQTT do deploy estão quebrados (falta libmosquitto). Use um cliente temporário na rede do deploy:

cd /root/docker/loga.accelerobr.com.br
PW=$(grep ^MQTT_PASSWORD= .env | cut -d= -f2-)
docker run --rm --network logaaccelerobrcombr_deploy-internal eclipse-mosquitto:2 \
  mosquitto_sub -h accelero_mqtt_loga.accelerobr.com.br -p 1883 -u accelero -P "$PW" \
  -t "LOGA/dahua/<serial>/keepalive" -v -W 60 -C 1

O keepalive traz versão, IP do gateway e o estado de cada facial.

9. Roteiro para a próxima unidade​

  1. Levantar a rede do cliente, os IPs dos faciais e se o cliente tem firewall com inspeção de aplicação.
  2. Conferir colisão da rede do cliente com as rotas e redes docker da VPS (seção 4, caution). Havendo colisão, planejar netmap.
  3. MikroTik: backup, configuração da seção 3.2 (ajustando a rede do cliente e o IP do peer), cabo do cliente na ether1.
  4. Pedido à TI (seção 5), com o IP e o MAC da ether1 que o MikroTik recebeu.
  5. VPS: cadastrar a rede do cliente no peer (seção 4.3).
  6. Accelero: faciais cadastrados com IP real, usuário, senha e o gateway em nuvem. Gateway na 1.7.0 ou superior.
  7. Validar, depois da liberação da TI. Se o túnel continuar bloqueado, trocar a porta de origem (seção 7.4).
    • wg show com handshake recente e transfer crescendo nos dois sentidos;
    • log do gateway sem timeout para os faciais da unidade;
    • keepalive com todos os faciais true;
    • PictureHttpUpload de um facial apontando para 10.77.0.1:90;
    • um acesso real chegando ao Accelero.
  8. Exportar a configuração final do MikroTik antes de retirar o cabo de manutenção (seção 3.5).
  9. Repassar ao cliente as recomendações: exceção do túnel documentada no firewall e fora do IPS, limpeza de sessões ao mudar regras, IP fixo ou reserva para o MikroTik e para cada facial, rota e assimetria no inventário de rede, MikroTik no nobreak. Texto pronto na seção 5 do relatório da LOGA (apoio/gateway-em-nuvem/relatorio-loga-vila-maria.md).

9.1 Jaguaré: migração do Gateway físico para o gateway em nuvem​

ItemSituação em 30/10/2026
Gateway físico26031, 1.7.0, 172.21.4.105
Rede dos faciais172.21.4.0/23 (5 faciais, entre eles 172.21.4.36 e .37)
Saída para a internetIP público 201.63.24.186

Pontos que diferem da Vila Maria:

  • Colisão confirmada: no akamai, a rede docker do deploy akamaidemo é 172.21.0.0/16, que contém 172.21.4.0/23. Cadastrar a rede direto na VPS cria ambiguidade de rota. Usar netmap no MikroTik para publicar 172.21.4.0/23 sob outra faixa, e cadastrar os faciais no Accelero com o IP publicado.
  • Desligar o 26031 antes de mover os faciais para o 26050 (ver a seção 8 do documento de arquitetura). Os dois gateways não podem administrar os mesmos faciais.
  • O firewall da LOGA em Jaguaré deixou passar SSH para porta alta do diacetyl. Não quer dizer que deixe passar WireGuard: pedir a liberação do item 2 da seção 5 do mesmo jeito.

10. Pendências abertas (30/10/2026)​

  • TI da LOGA: liberação, rota e assimetria atendidas e validadas em campo em 30/10. Falta confirmar a reserva de DHCP do 10.128.10.41.
  • Configuração final do MikroTik local 3 sem export (seção 3.5). Exportar pela VPN depois do ajuste da seção 4.4, ou no local.
  • Firewall do akamai: regra de ESTABLISHED,RELATED para a wg-LOGA (seção 4.4).
  • Peers local 1 e local 2 sem handshake desde ~14/10. Verificar se é o mesmo bloqueio.
  • Gateway: endereço de eventos por unidade (seção 6.3), para não depender de rota no cliente.
  • Este roteiro em script: cadastro de peer e de rede na VPS, e template de configuração do MikroTik.

Próximos passos​