# Estudo validado — alternativas de DX/VIF para alcançar a RTM (sem terceiros, com segurança total)

Data: 2026-06-22
Conta: `990933657879`, região `sa-east-1`
Método: pesquisa da doc oficial AWS Direct Connect + validação read-only da config viva + evidência empírica (4 origens testadas). Workflow multi-agente (6 agentes).
Regra: nada foi criado/alterado/deletado — 100% read-only.

## 0. TL;DR

- **O que você acertou:** as **conexões DX são nossas** (`dxcon-fh7fdtyv`, `dxcon-fgl2a4wd`, owner `990933657879`) e **temos a BGP key** visível (authKey len 24 nas duas VIFs).
- **O que trava recriar/reaproveitar a VIF (provado):**
  1. As conexões são **HOSTED**. Numa conexão hosted, **quem provisiona/deleta a VIF é o DX Partner (Equinix)** — e a AWS responde, ao vivo, que a nossa conta **"is not an authorized Direct Connect partner in sa-east-1"**. Donos da conexão, mas **não** do plano de provisionamento da VIF.
  2. `delete-virtual-interface` é **owner-scoped** → a VIF é da Lerian (`975049942889`); não deletamos da nossa conta.
  3. Hosted = **1 VIF, limite que "cannot be increased"**. Sem 2ª VIF, sem LAG (LAG só aceita dedicated), sem converter hosted→dedicated por nós.
  4. Recriar a VIF apontaria pro **nosso** DXGW (diferente do da Lerian); o lado remoto RTM/Equinix está amarrado ao peering atual → **BGP não sobe** sem reconfiguração deles.
  5. **Restaurar** a VIF da Lerian exige **partner re-alocar + Lerian re-aceitar (cross-account) + re-bind no DXGW deles** → **não reversível só por nós**.
  6. **O decisivo:** trocar VIF é **L2/L3**. O bloqueio da RTM é **firewall L4 de porta** — provado: **HSM `10.173.1.247:443` ABRE e `:60042` dá TIMEOUT no MESMO IP/rota**. Nenhuma cirurgia de VIF abre porta na RTM.
- **Conclusão:** **nenhuma** alternativa satisfaz os 3 critérios (sem-terceiros + segurança-total + alcança-o-objetivo). O caminho AWS de roteamento **já está completo e saudável**; o único muro que falta é o **firewall de porta da RTM**, que é 100% do lado deles.

## 1. Mapa de propriedade (verificado, 3 APIs)

| Camada | Recurso | Dono | Observação |
|---|---|---|---|
| Conexão DX | `dxcon-fh7fdtyv` (RJ, vlan343, EQRJ2), `dxcon-fgl2a4wd` (SP, vlan347, TNDB) | **NÓS 990933657879** | 50Mbps **hosted**, partner EQUINIX NNI, `lagId=null`, jumbo, sem MACsec |
| VIF | `dxvif-fftvbsl5`, `dxvif-fhcnovv5` | **Lerian 975049942889** | transit, BGP up, 1 por conexão (slot cheio) |
| DXGW | `976ff838-…` | **Lerian 975049942889** | `describe-direct-connect-gateways` = `[]` p/ nós; allowedPrefixes p/ nosso TGW = **só `192.168.0.0/16`** |
| TGW | `tgw-051f1a3c159dfb25b` | **NÓS** | ASN 64513; 2 route tables nossas |

Nossa conta **não está na org da `975049942889`** (`organizations describe-account` → `AccountNotFoundException`) e **não tem credencial** dela. `describe-hosted-connections`/`describe-interconnects` → **"not an authorized Direct Connect partner"**.

## 2. Spec de restauração das VIFs (referência — sem segredo)

| Campo | `dxvif-fftvbsl5` (RJ) | `dxvif-fhcnovv5` (SP) |
|---|---|---|
| connection | `dxcon-fh7fdtyv` | `dxcon-fgl2a4wd` |
| vlan | 343 | 347 |
| type / af | transit / ipv4 | transit / ipv4 |
| customer ASN | 65158 | 65158 |
| amazon ASN | 64512 | 64512 |
| amazonAddress | 169.254.96.169/29 | 169.254.96.209/29 |
| customerAddress | 169.254.96.174/29 | 169.254.96.214/29 |
| mtu / bfd | 1500 / true | 1500 / true |
| DXGW | `976ff838-…` (Lerian) | `976ff838-…` (Lerian) |
| bgpPeer | `dxpeer-fg7i8onc` (UP) | `dxpeer-fgy4idea` (UP) |
| authKey | **presente (len 24) — NÃO versionar** | **presente (len 24) — NÃO versionar** |

> As BGP MD5 keys existem e são visíveis via `describe-virtual-interfaces` à nossa conta, mas **não** ficam neste repositório (regra de segredo). Se um dia forem usadas, vêm de fonte segura e são rotacionadas via quem opera o DXGW.

## 3. Respostas às 4 perguntas

**(1) Por que não dá pra "desativar a VIF temporariamente e rotear direto pelo DX"?**
Não existe "admin-down" de VIF para o cliente: os únicos botões são `delete-virtual-interface` (a VIF) ou `delete-connection` (a conexão inteira). A VIF é da Lerian (delete owner-scoped) e a conexão é hosted (provisionamento é do partner, e não somos partner). O único botão realmente nosso é destruir a conexão inteira — destrutivo, e só Equinix/RTM reconstroem. E "rotear direto pelo DX" não existe: um circuito DX **não encaminha nada sem uma VIF** carregando o BGP. Deletar a VIF viva derruba o que hoje mantém o HSM `:443` aberto, sem rollback nosso.

**(2) Podemos criar uma VIF com o nosso range?**
Não nas conexões atuais: hosted = 1 VIF (não aumentável), slot ocupado. E não somos DX partner pra auto-alocar VIF em hosted. Uma VIF nossa apontaria pro **nosso** DXGW; o lado remoto não sobe sem RTM/Equinix casarem peer-IP+MD5+VLAN. Anunciar `10.50/10.45` é proibido (são blocos da Lerian; o DXGW rejeita prefixo sobreposto e o retorno seria black-hole). Só podemos anunciar `192.168.0.0/16` (e já anunciamos).

**(3) Um novo peering de VIF impacta algo / precisa de autorização da RTM?**
Sim aos dois. Uma VIF nova só encaminha se o peer remoto casar VLAN + IPs /29 + ASN 65158/64512 + MD5 — e como aponta pro nosso DXGW (não o da Lerian), **a RTM/Equinix precisa reconfigurar/whitelistar** o novo peering, senão BGP e forwarding não sobem. E o firewall L4 da RTM continua intocado de qualquer jeito.

**(4) Como ficaria reaproveitar a VIF/circuito existente?**
Reaproveitar = **deixar intacto** (é a topologia que funciona). O caminho Lerian-VIF + Lerian-DXGW + nosso-TGW já tem rotas ativas pra todos os alvos da RTM e **encaminha** (HSM `:443` abre). "Reaproveitar trocando" (deletar a da Lerian e por a nossa com mesma VLAN/ASN) falha: não deletamos VIF da Lerian, não auto-alocamos em hosted, o lado remoto está amarrado ao DXGW da Lerian, e restaurar exige partner + Lerian. O "reaproveitar" correto: **não mexer no DX** e fazer a RTM abrir as portas pra nossa origem legítima.

## 4. Matriz de alternativas (veredito adversarial)

| Alternativa | Sem terceiros? | Seguro/reversível? | Alcança objetivo? | Veredito |
|---|---|---|---|---|
| **A — substituir a VIF** (deletar a da Lerian, criar a nossa, mesmo VLAN/ASN → nosso DXGW) | ❌ | ❌ | ❌ | **REJEITAR** — não deletamos VIF da Lerian (owner-scoped), não somos partner (hosted), restaurar precisa Lerian+Equinix, derruba o caminho vivo, e não abre porta L4 da RTM |
| **B — sem tocar a VIF** (2ª VIF / novo circuito / widen allowedPrefixes / public VIF / LAG) | ❌ | ❌ | ❌ | **REJEITAR** — b1/b4/b5 fisicamente impossíveis em hosted 50Mbps; b3 é do DXGW da Lerian; b2 (circuito novo) é máximo-terceiros, lento, caro e ainda termina no firewall da RTM |
| **C — só do nosso lado** (SNAT/rota + relay Cecresa) | ⚠️ parcial | ✅ | ❌ p/ MQ/HSM | **PARCIAL** — seguro e reversível, mas SNAT não vence DROP da RTM; relay Cecresa cobre só os 5 hosts RSFN PIX/SPI (não MQ/HSM:60042) e depende organizacionalmente da Cecresa |

## 5. Dependências irredutíveis

1. **Firewall L4 da RTM** (o bloqueio real): HSM `:60042`, MQ `1414/1514/12522`, SSH `22`, RSFN service ports — DROP silencioso. Provado por HSM `:443` OPEN vs `:60042` TIMEOUT no mesmo IP/rota. Whitelist #331997 pendente, 100% RTM. **Não há substituto AWS do nosso lado.**
2. **Lerian (`975049942889`)** para qualquer mudança no data-plane do DX (VIFs + DXGW + allowedPrefixes). Execução **e** restauração.
3. **DX Partner / Equinix** para alocar VIF em hosted ou novo circuito. Não somos partner.
4. **Cecresa (`364807861246`)** para o relay RSFN PIX/SPI (temporário; só os 5 hosts; teste funcional ainda depende de cert ICP-Brasil + ISPB Monetarie).

## 6. Recomendação

Nenhuma alternativa fecha os 3 critérios. O caminho AWS já está completo e saudável — o muro é exclusivamente o **firewall de porta da RTM**. Portanto:

1. **Não** deletar/repointar VIF, **não** anunciar `10.50/10.45`, **não** ordenar circuito novo como atalho. Tudo isso adiciona raio de impacto sem destravar nada e quebra o que funciona.
2. **Único caminho que destrava MQ/HSM:60042:** a RTM aplicar o whitelist (#331997) para a nossa origem legítima `192.168.x` e abrir as portas, sobre o caminho que **já funciona**. Re-testar `:60042` / MQ / RSFN assim que confirmarem.
3. **Valor entregável hoje, 100% nosso e reversível:** o relay Cecresa para alcance de rede RSFN PIX/SPI (com a ressalva da dependência organizacional Cecresa + teste funcional aberto).
4. Manter `IBM_MQ_ENABLED=false` e `RTM_HSM_ENABLED=false` até a RTM confirmar porta + entregar UIDs.

## 7. Rastreabilidade (comandos read-only usados)

`describe-connections`, `describe-virtual-interfaces` (full + customerRouterConfig), `describe-lags`, `describe-direct-connect-gateways`, `describe-direct-connect-gateway-associations`, `describe-direct-connect-gateway-association-proposals`, `describe-transit-gateways`, `describe-transit-gateway-attachments`, `get-transit-gateway-route-table-associations/propagations`, `search-transit-gateway-routes`, `describe-hosted-connections`/`describe-interconnects` (negados = não somos partner), `sts get-caller-identity` por profile, `organizations describe-account 975049942889` (AccountNotFoundException).