# Pedido de liberação RTM — evidência técnica (ref. ticket #331997)

Data: 2026-06-22
De: Monetarie (conta AWS própria, conectada à RTM por Direct Connect + Transit Gateway)
Para: RTM (Luciano Maia Cirilo / Herbeth Santana)
Ref.: "RTM | Implementação RCS | MONETARIE SOCIEDADE DE CREDITO DIRETO S/A | #331997"

> Documento técnico para coordenação de rede com a RTM. Pode ser encaminhado à RTM. Não contém segredos (tokens, senhas, chaves). Não é o relatório do cliente.

## 1. Pedido objetivo

Confirmamos por testes que o **caminho de rede até a RTM está funcional** (o console do HSM abre), mas os destinos de **MQ**, **API do HSM (`:60042`)** e **serviços RSFN diretos** estão sendo **descartados em silêncio** (TIMEOUT) para as nossas origens. Pedimos:

1. **Aplicar/confirmar o whitelist do #331997** e **incluir a nossa origem de homologação `192.168.40.0/24` (IP `192.168.40.10`)**. Se a RTM preferir que a origem seja `192.168.19.0/24` (bloco HML do e-mail), confirmar isso explicitamente — nós originamos a partir de lá.
2. **Abrir a porta TCP `60042`** (API KMIP do vHSM `cloudhsm-hml.priv.rtmcloud.net.br` / `10.173.1.247`) para a nossa origem. Hoje só a `:443` (console) abre.
3. **Confirmar a porta real do IBM MQ HML** em `172.31.2.50`: o e-mail #331997 cita `1414`, mas o mapeamento que recebemos aponta `1514` (SPB01 / `QM.46026562.01`) e `12522` (MES01 / `QM.46026562.02`), canal `APP.SVRCONN`. Precisamos do par porta/QM/canal correto para HML.
4. **Confirmar se a RSFN aceita a origem `192.168.0.0/16` (Monetarie)** ou se exige NAT/origem específica para `dict-h`, `dict-np-h`, `icom-h`, `icom-sec-h`, `arq-h`.

## 2. Evidência — o que funciona

Testes TCP read-only a partir de duas origens nossas (via Direct Connect/TGW):

- HSM HML `10.173.1.247:443` (console web): **abre** de `192.168.40.10` e de `192.168.19.59`.
- HSM de teste público `200.160.162.200:63351`: **abre**.
- Direct Connect: VIFs `MONETARIE-LERIAN` (vlan 343) e `MONETARIE-LERIAN-2` (vlan 347) `available`, BGP `up`; prefixo permitido ao DXGW = `192.168.0.0/16`.
- DNS RSFN (`dict-h.pi.rsfn.net.br` etc.) resolve normalmente.

Ou seja, **roteamento, Direct Connect e BGP estão corretos** — o pacote chega à RTM (o `:443` do HSM prova isso).

## 3. Evidência — o que está bloqueado (TIMEOUT / descarte silencioso)

Mesmo teste, mesmas duas origens, resultado **idêntico**:

| Destino | Porta | Resultado |
|---|---|---|
| MQ HML `172.31.2.50` | `22`, `1414`, `1514`, `12522` | TIMEOUT |
| HSM HML `10.173.1.247` | `60042` (API KMIP) | TIMEOUT |
| RSFN `200.218.66.145` (`dict-h`) | `16522` | TIMEOUT |

O erro é **TIMEOUT** (sem `connection refused` e sem `no route to host`): a assinatura de um **firewall descartando o pacote em silêncio**, não de porta fechada nem de rota ausente. Como a `:443` do HSM abre pela mesma origem e caminho, **não é problema de roteamento/NAT do nosso lado** — falta liberação no lado RTM.

Importante: testamos inclusive a partir de `192.168.19.59` (que está no bloco `192.168.19.0/24` listado como liberado no #331997) e o resultado é o mesmo TIMEOUT. Isso indica que a liberação descrita no e-mail **ainda não está ativa** para as nossas origens.

## 4. Dados de referência para a liberação

| Item | Valor |
|---|---|
| Origem egress Monetarie (homolog) | `192.168.40.10` (`192.168.40.0/24`) |
| Origem alternativa (bloco HML do e-mail) | `192.168.19.0/24` |
| MQ HML (destino, máquina RTM) | `172.31.2.50` (`097514SP_MQ_HML`) |
| HSM HML (destino) | `cloudhsm-hml.priv.rtmcloud.net.br` = `10.173.1.247`, vHSM `60042` |
| RSFN serviço (exemplo) | `dict-h.pi.rsfn.net.br` → `200.218.66.145` / `.67.209`, porta `16522` |
| Prefixo anunciado ao DXGW | `192.168.0.0/16` |

## 5. Resultado esperado após a liberação

Assim que a RTM confirmar a aplicação do whitelist (com a nossa origem incluída) e abrir as portas, refazemos os mesmos testes read-only; o critério de sucesso é o TCP abrir (e, para MQ/HSM, prosseguirmos com a validação funcional usando as credenciais já configuradas no nosso Secrets Manager).