# RTM/RSFN — liberação pendente, prova egress vs bastion e whitelist RTM #331997

Data: 2026-06-22
Ambiente: homologação
Conta AWS: `990933657879`, região `sa-east-1`
Operação: tudo via **AWS API read-only** e **SSM read-only** (sem alterar bastion, rotas, TGW, DX ou recursos da Lerian).
Complementa e refina: `2026-06-21-rsfn-bastion-study.md`, `2026-06-21-hsm-mq-hml-preconfig.md`, `2026-06-21-rtm-cloudhsm-hml-acesso-egress-openvpn.md`.

## 1. Resumo executivo

1. O deploy de homologação foi **re-validado empiricamente em 2026-06-22** (workflow read-only de 5 dimensões). Tudo confere com o estado canônico: 15 serviços ECS `1/1`, 15 target groups `healthy`, ALB interno HTTP:80, Aurora PG `16.6` Serverless v2 `0.5–4`, Redis `7.1.0` `t4g.micro`, TGW/DX/Route53/Secrets conforme documentado. Detalhes na seção 6.
2. **Inteligência nova (e-mail RTM #331997):** a RTM informou os **blocos de origem** que serão liberados para o tráfego. É o **whitelist acordado**, redigido em tempo futuro (planejado), e **não inclui** o `192.168.40.0/24` da nossa VM de egress. Seção 2.
3. **Experimento decisivo (egress vs bastion):** rodamos o **mesmo** teste de conectividade TCP a partir do `bastion` (`192.168.19.59`, dentro do bloco HML que o e-mail diz estar liberado) e da nossa VM de egress (`192.168.40.10`, fora do whitelist). **Os dois falham de forma idêntica** para MQ, HSM `:60042` e RSFN direto. Seção 3.
4. **Conclusão corrigida:** o diferencial **não é a nossa subnet de origem**. O bloqueio está **do lado RTM/Lerian** — a liberação descrita no e-mail **ainda não foi aplicada** para nenhuma das nossas origens (nem para o bloco do próprio bastion). Isso bate com a fala do contato RTM no WhatsApp: *"acho que só liberaram para a RSFN o CIDR da Lerian"*. Seção 4.
5. **Lacuna do nosso lado (corrigível por nós):** a route table do egress (`rtb-003e7f7e9a48d7caf`) **não tem rota para `172.31.2.0/24`** (rede do MQ HML), enquanto a route table principal usada pelo bastion (`rtb-0f84caeba8d62d2d7`) **tem** `172.31.2.0/24 → TGW`. Hoje o tráfego MQ do egress cai na default `0.0.0.0/0 → IGW`. Seção 5.
6. **Porta MQ em aberto:** o e-mail cita IBM MQ na porta **`1414`** (default), mas a config do `spb-api` usa **`1514` (SPB01)** e **`12522` (MES01)**. Como o MQ não responde de nenhuma origem ainda, não dá para validar empiricamente qual porta a RTM expõe. Precisa ser confirmado com a RTM antes de habilitar. Seção 4.3.

## 1.1 Esclarecimentos do dono (2026-06-22)

- O **MQ HML `172.31.2.50` é máquina disponibilizada pela RTM** (confirmado: não há ENI/instância nossa com esse IP).
- O **relay Cecresa foi um workaround temporário** apenas para acessar a RSFN e testar GET no âmbito do PIX (ICOM e DICT). Não é o caminho definitivo e não deve ser tratado como solução final de produção.
- A **VM de egress própria (`192.168.40.10`) foi criada de propósito para não ter conflito** com as redes do cliente nem do cliente com a Lerian. O isolamento é intencional.
- A comunicação de **homologação, em tese, deve sair pela `192.168.19.0/24`** (bloco HML que a RTM lista no #331997). Daí a tensão: a RTM espera origem em `192.168.19.0/24`, mas nossa VM isolada está em `192.168.40.0/24`. Resolver isso é decisão de arquitetura: ou a RTM aceita `192.168.40.0/24`, ou originamos por `192.168.19.0/24` (ex.: IP livre `192.168.19.169/32`).
- Direção das próximas validações: manter **read-only** e focado no caminho HML `192.168.19.0/24`.

## 2. E-mail RTM #331997 — whitelist de origem acordado

Origem: e-mail "Re: RTM | Implementação RCS | MONETARIE SOCIEDADE DE CREDITO DIRETO S/A | #331997", de Luciano Maia Cirilo (`luciano.cirilo@rtm.net.br`), respondido por Herbeth Santana. Assunto do trecho: "Sobre o interesse de tráfego" (tempo verbal **futuro**, "as conexões de origem **sairão** dos seguintes blocos" → é o que a RTM **vai** liberar, não necessariamente o que já está aplicado).

Para a porta **`1414` (IBM MQ)**, origens previstas:

| Bloco | Papel |
|---|---|
| `10.50.0.0/16` | Lerian (Core Bancário) |
| `10.45.0.0/16` | Lerian (Core Bancário) |
| `192.168.18.0/24` | subnet-prod (Produção) |
| `192.168.19.0/24` | subnet-hml (Homologação) |
| `192.168.30.0/24` | subnet-dr (Contingência) |

Para a porta **`22` (SSH)**, origens previstas (restrito a administração):

| Bloco | Papel |
|---|---|
| `192.168.18.0/24` | Produção |
| `192.168.19.0/24` | Homologação |

A RTM ofereceu refinar depois para IPs específicos (bastions) conforme a evolução do ambiente.

**Implicação direta:** nenhum dos blocos é o `192.168.40.0/24` da nossa VM de egress. Quando a RTM aplicar esse whitelist, a origem `192.168.40.10` **continuará de fora**. As subnets `192.168.18/19/30` são da **Lerian** (subnet-prod/hml/dr, route table principal `rtb-0f84caeba8d62d2d7`); a nossa é a `192.168.40.0/24` (route table exclusiva `rtb-003e7f7e9a48d7caf`).

WhatsApp correlato (MonBank <> Vulci, 2026-06-22 08:21–08:25): pedimos à RTM confirmar (a) rotas do `192.168.0.0/16` para a RSFN, (b) liberação do DNS `*.rsfn.net.br`, (c) liberação da porta `60042` do HSM / confirmação do endpoint `cloudhsm-hml.priv.rtmcloud.net.br:60042`. Resposta do contato RTM: *"Vou verificar com a RTM, mas acho que só liberaram para a RSFN o CIDR da Lerian"*.

## 3. Experimento egress vs bastion (read-only, autorizado)

Comando SSM `AWS-RunShellScript` (read-only, somente `bash /dev/tcp` + `ip route get`), enviado às duas instâncias na mesma execução.
Command ID: `adf12e68-3690-47b6-bb67-830178c19030` (2026-06-22). SSM PingStatus `Online` nas duas.

Resultado idêntico nas duas origens:

| Destino | Porta | `bastion` `192.168.19.59` | `egress` `192.168.40.10` | Leitura |
|---|---|---|---|---|
| MQ HML `172.31.2.50` | `22` | FAIL | FAIL | SSH do túnel sidecar |
| MQ HML `172.31.2.50` | `1414` | FAIL | FAIL | porta do e-mail RTM |
| MQ HML `172.31.2.50` | `1514` | FAIL | FAIL | porta SPB01 da config |
| MQ HML `172.31.2.50` | `12522` | FAIL | FAIL | porta MES01 da config |
| HSM HML `10.173.1.247` | `443` | **OK** | **OK** | console web CloudHSM |
| HSM HML `10.173.1.247` | `60042` | FAIL | FAIL | API KMIP vHSM |
| RSFN `200.218.66.145` (dict-h) | `16522` | FAIL | FAIL | porta de serviço RSFN direta |
| HSM teste `200.160.162.200` | `63351` | **OK** | **OK** | endpoint público de teste |

`ip route get` confirma que, no nível do SO, ambas as instâncias mandam tudo que não é local para o gateway da própria subnet (`192.168.19.1` no bastion, `192.168.40.1` no egress); a decisão TGW vs IGW acontece no **roteador da VPC** (route table), que difere entre as duas — ver seção 5.

### 3.1 errno preciso (refused vs timeout vs no-route)

Segundo teste read-only (command ID `eb74b522-427c-4547-b77d-87d330957cc8`, 2026-06-22) capturando o motivo exato da falha, idêntico nas duas origens:

| Destino | Porta | bastion `.19.59` | egress `.40.10` | Leitura |
|---|---|---|---|---|
| HSM `10.173.1.247` | `443` | **OPEN** | **OPEN** | caminho DX→RTM OK |
| MQ `172.31.2.50` | `22`/`1414`/`1514`/`12522` | **TIMEOUT** (rc=124) | **TIMEOUT** | SYN sai, nada volta |
| HSM `10.173.1.247` | `60042` | **TIMEOUT** | **TIMEOUT** | porta KMIP não liberada |
| RSFN `200.218.66.145` | `16522` | **TIMEOUT** | **TIMEOUT** | serviço RSFN direto bloqueado |

Distinção que isso permite:
- **TIMEOUT** (e não `Connection refused`/RST) → o destino não responde nem com SYN-ACK nem com RST: assinatura de **DROP silencioso por firewall** no lado RTM/Lerian. Se o host MQ estivesse no ar com a porta fechada, viria `Connection refused`.
- **Não houve `No route to host`** em nenhum caso → não falta rota no nosso lado; o `:443` do HSM abrindo prova que o pacote chega na RTM por DX.
- Portanto a falha do MQ/HSM:60042/RSFN-direto é **descarte ativo no lado RTM**, igual para `192.168.19.59` e `192.168.40.10`.

### 3.2 Estudo NAT do bastion (read-only) — descarta SNAT mascarando origem

Inspeção read-only das regras do bastion (command ID `ab109351-dbe5-4804-911b-13f0316bd372`):

- `ip rule`: só `local`/`main`/`default` (sem policy routing).
- NAT POSTROUTING (iptables + nft): **MASQUERADE só para `-s 10.99.0.0/24`** (clientes WireGuard) com destino `192.168.0.0/16` e `10.173.0.0/16`. **Não há SNAT/MASQUERADE para o tráfego originado no próprio bastion** (`192.168.19.59`).
- `ip route get` para `172.31.2.50`, `10.173.1.247`, `200.218.66.145`: todos `via 192.168.19.1 dev ens5 src 192.168.19.59` — sai como `.59`, sem tradução.
- O bastion é hub WireGuard (`wg0`, peer `herbeth`): o cliente (faixa `10.99.0.0/24`) alcança o HSM `10.173.x` pelo bastion (contador nft ~5927 pacotes). Ninguém alcança o MQ `172.31.x`.

Conclusão: o bastion apresenta genuinamente a origem `192.168.19.59` (o IP que o e-mail diz estar liberado) e **ainda assim é descartado**. Isso **elimina** a hipótese de o WireGuard estar mascarando a origem do bastion. Por consequência, um host limpo em `192.168.19.169` (mesmo `/24`) **também seria descartado** enquanto a RTM não aplicar a liberação — o probe `.169` só passa a ter valor depois que a RTM confirmar que aplicou.

## 4. Conclusão técnica refinada

### 4.1 O diferencial não é a nossa origem

O bastion está dentro do bloco `192.168.19.0/24` que o e-mail #331997 lista como liberado para MQ e SSH, e a route table dele já tem `172.31.2.0/24 → TGW`. Mesmo assim, MQ `:22/:1414/:1514/:12522` falham igual ao egress, e o errno é **TIMEOUT (DROP silencioso)**, não `Connection refused` nem `No route to host`. Portanto a hipótese de que bastaria mudar a origem para um IP `192.168.19.x`/`192.168.18.x` **não se sustenta no estado atual**: a liberação RTM não está ativa nem para o bloco do bastion. O `:443` do HSM abrindo das duas origens prova que o caminho DX está correto; o que falta é a RTM parar de descartar nossos SYNs para MQ/HSM:60042/RSFN-direto.

Nota sobre `192.168.19.169/32` (IP livre sugerido pelo dono para evitar conflito): a subnet-hml só usa hoje `.59` (bastion) e `.78` (ENI do TGW), então `.169` está disponível. Porém, como está no **mesmo `/24` do bastion**, que já sofre DROP silencioso, um probe a partir de `.169` deve **também dar TIMEOUT** enquanto a RTM não aplicar a liberação. O probe `.169` só vira teste útil **depois** que a RTM confirmar que aplicou o whitelist — aí ele prova de forma limpa (sem fatores específicos do bastion) se a origem `192.168.19.x` passa. Criar fonte em `.169` é a única forma de originar tráfego desse IP (subnet da Lerian), então fica como ação condicional, sob aprovação, e reversível (terminar/destacar após o teste).

### 4.2 HSM: padrão consistente

HSM HML `:443` abre das duas origens (porta liberada, rota TGW→DX correta); `:60042` falha das duas (porta KMIP não liberada no firewall RTM). Confirma o diagnóstico anterior: o problema do HSM é **liberação de porta `:60042` no lado RTM**, não rota/tradução nossa. HSM de teste público `:63351` segue OK.

### 4.3 MQ: porta + liberação + rota, todas em aberto

Três coisas precisam convergir para o MQ funcionar:
1. **Porta correta:** `1414` (e-mail) vs `1514`/`12522` (config `spb-api`). Não validável até a RTM responder na porta.
2. **Liberação RTM:** o firewall RTM precisa aceitar a nossa origem para a porta do MQ. Hoje recusa até o bloco do bastion.
3. **Rota nossa:** o egress precisa ter rota para `172.31.2.0/24` via TGW (hoje não tem — seção 5).

### 4.4 RSFN de serviço: dois caminhos distintos

- **Caminho direto** (`200.218.*` via DX): falha em TCP das duas origens (igual ao estudo de 2026-06-21). Bloqueio/assimetria no lado RTM/Lerian/RSFN.
- **Caminho via relay Cecresa** (`172.16.70.51-55`, HAProxy L4): a camada de rede está **completa e validada** (TCP nas 5 portas + certificado de servidor do BACEN voltando intacto). Falta apenas o teste funcional de mensagem, que depende do certificado ICP-Brasil e do ISPB da Monetarie no nível de aplicação. Ver `2026-06-21-rsfn-relay-monetarie-isolado-design.md`. Não confundir os dois: o direto está bloqueado; o relay está pronto em rede.

## 5. Comparação de route tables (read-only)

| Rota | egress `rtb-003e7f7e9a48d7caf` | principal Lerian `rtb-0f84caeba8d62d2d7` (bastion) |
|---|---|---|
| `172.31.2.0/24` (MQ HML) | **ausente** | `→ TGW` |
| `10.173.1.247/32` (HSM HML) | `→ TGW` | `→ TGW` |
| `200.218.64.0/18` (RSFN) | `→ TGW` | `→ TGW` |
| `200.160.16x.0/24` (HSM teste) | `→ TGW` | (default) |
| `172.16.70.0/24` (relay Cecresa) | `→ pcx-0e15a54db2a1fc8b1` | ausente (isolado de propósito) |
| `10.40.0.0/16` (app VPC) | `→ pcx-035032773d2f617e4` | ausente |
| `10.0.17.2/32`, `10.0.33.2/32` | ausente | `→ TGW` |
| `0.0.0.0/0` | `→ IGW` | `→ IGW` |

O TGW (route table default `tgw-rtb-00c87955e8b181f3f`) tem `172.31.1.0/24`, `172.31.2.0/24`, `172.31.3.0/24` **propagados via DX** — ou seja, a RTM anuncia a rede do MQ pela Direct Connect, e o caminho existe no TGW. O que falta no nosso lado é a rota na route table do egress.

`172.31.2.50` **não é recurso nosso**: não há ENI/instância na conta `990933657879` com esse IP (existe um default VPC `172.31.0.0/16` = `vpc-070f1ff919057a761`, mas sem essa instância). É destino remoto da RTM, alcançável (em tese) por DX.

## 6. Re-validação do deploy (2026-06-22, read-only)

Resumo dos verdicts (todos CONFIRMED salvo onde indicado):

- ECS `monetarie-greenfield-homolog`: 15 serviços, todos `running=1`/`desired=1`, rollout `COMPLETED`. **Revisões de task definition avançaram** em relação ao handoff de 2026-06-21: `core-api:10` (era :8), `pix-api:14` (era :11), `spb-api:9` (era :5), demais UIs em `:5`, `clst-api:6`, `npc-api:6`, `sta-api:6`, `docs-portal:5`. Imagem ainda na tag `b72cc6a`. Sempre conferir por `ecs describe-services`, não por tag anotada.
- TigerBeetle EC2 `i-0e62f373860bc11b3`: instância `running`, mas **SSM PingStatus `ConnectionLost`** → imagem `0.17.3` não foi confirmável em runtime nesta passagem (UNVERIFIABLE, não refutado). NATS `i-04d3eb5ed0a4f5207`: `Online`, `nats:2.10-alpine` confirmado em runtime.
- ALB interno `monetarie-internal-homolog` (`...755178618...`): `internal`, `active`, 1 listener HTTP:80. 15 target groups, 15/15 targets `healthy`.
- Aurora `monetarie-core-homolog`: `aurora-postgresql 16.6`, Serverless v2 `0.5–4.0`, `available`, encriptado (KMS `3b581405-...`). Redis `monetarie-gf-redis-node-homolog`: `redis 7.1.0`, `cache.t4g.micro`, `available` — **encryption at-rest e in-transit desabilitados** (nota de segurança, fora do escopo de homologação atual).
- Rede: VPCs/subnets/TGW/DX/Route53 conforme handoff. DXGW `976ff838-...` (conta Lerian `975049942889`), `allowedPrefixesToDirectConnectGateway = [192.168.0.0/16]`, VIFs `MONETARIE-LERIAN` (vlan343) + `MONETARIE-LERIAN-2` (vlan347) `available`, BGP `up`.
- Secrets (describe-only, sem ler valores): 8 secrets existem (HSM pix/spb crypto_user+token, MQ ssh_private_key, admin core/pix/spb initial_password). Flags `RTM_HSM_ENABLED=false` (pix+spb), `IBM_MQ_ENABLED=false` (spb), `BACEN_ENABLED=false` (pix em modo simulador). `core-api` sem nenhuma env `RTM_HSM_*`/`IBM_MQ_*` — isolamento do Core confirmado.
- Observação de config: `BACEN_RTM_SSH_USER=herberth` está como env em claro no `spb-api` (identidade de operador, não é segredo, mas convém parametrizar).

## 7. O que podemos fazer do nosso lado vs. o que depende da RTM

**Nosso lado (construímos/operamos — pode ser executado por nós, sob aprovação):**
1. Adicionar `172.31.2.0/24 → tgw-051f1a3c159dfb25b` na route table **do egress** (`rtb-003e7f7e9a48d7caf`, nossa). Pré-requisito para o egress sequer tentar o MQ por DX. Não toca Lerian. (Sozinho não resolve enquanto a RTM não liberar a origem.)
2. Manter `IBM_MQ_ENABLED=false` e `RTM_HSM_ENABLED=false` até liberação + UIDs + porta confirmada.
3. Reconciliar a porta MQ na config (`1514/12522`) com a resposta da RTM (`1414`?) antes de habilitar.
4. (Opcional) restaurar/checar SSM agent da EC2 TigerBeetle (`ConnectionLost`) — manutenção nossa, não afeta runtime do ledger.
5. Caminho RSFN: o relay Cecresa já está pronto em rede; o teste funcional depende de cert ICP-Brasil + ISPB Monetarie (item externo).

**Depende da RTM/Lerian (pedido, não alteração nossa):**
1. Aplicar de fato o whitelist do e-mail #331997 e **incluir `192.168.40.0/24` (ou `192.168.40.10/32`)** — senão nossa origem de egress fica de fora mesmo após a liberação.
2. Abrir a API KMIP do HSM `:60042` para a nossa origem.
3. Confirmar a porta real do MQ HML (`1414` vs `1514`/`12522`) e o usuário/каnal.
4. Confirmar aceitação do `192.168.0.0/16` (Monetarie) na RSFN, ou exigência de NAT/origem específica.

## 8. O que NÃO inferir

- E-mail #331997 lista blocos liberados ≠ liberação aplicada. O teste empírico mostra que, hoje, nem o bloco do bastion alcança o MQ.
- `bastion` no bloco liberado **não** alcançou o MQ — não tratar "usar origem `192.168.19.x`" como solução enquanto a RTM não confirmar liberação ativa.
- HSM `:443` OK não significa `:60042` OK. RSFN DNS OK e relay OK não significam RSFN direto OK.
- Adicionar a rota `172.31.2.0/24` no egress, sozinha, não fará o MQ funcionar; é só um pré-requisito do nosso lado.

## 9. IDs de referência

| Item | Valor |
|---|---|
| EC2 egress (nossa) | `i-0692fbf5e0dd6d350` / `192.168.40.10` / RT `rtb-003e7f7e9a48d7caf` / subnet `subnet-0c9eb0464d27ef9ae` (`192.168.40.0/24`) |
| EC2 bastion (Lerian, só leitura) | `i-06be52454b879cbbb` / `192.168.19.59` / subnet `subnet-0a00cc821bc642306` (`192.168.19.0/24`) / RT principal `rtb-0f84caeba8d62d2d7` |
| MQ HML (destino remoto RTM) | `172.31.2.50` (`097514SP_MQ_HML`), SPB01 `QM.46026562.01`, MES01 `QM.46026562.02`, canal `APP.SVRCONN`, user `spb_server`, SSH user `herberth` |
| HSM HML real | `cloudhsm-hml.priv.rtmcloud.net.br` = `10.173.1.247` (vHSM `60042`) |
| TGW / DXGW | `tgw-051f1a3c159dfb25b` / `976ff838-a4ae-49a8-bb22-93515b088779` (conta Lerian `975049942889`) |
| Comando SSM do teste | `adf12e68-3690-47b6-bb67-830178c19030` |