# Estudo RSFN pela EC2 bastion Data: 2026-06-21 Modo: somente leitura Escopo: comparação entre EC2 `bastion`, VM Monetarie RSFN, TGW, Direct Connect e destinos RSFN de homologação. Este documento registra o estudo iniciado após a atualização do handoff principal. Ele não substitui `docs/handoff/2026-06-21-monetarie-aws-homolog-handoff.md`; ele complementa a pendência de conectividade RSFN. ## 1. Premissas - Não alterar bastion, rotas, security groups, TGW, Direct Connect, VPC ou recursos da Lerian. - Não usar o Mac como fonte de validação RSFN neste momento, porque o usuário informou que está conectado em uma VPN própria da RTM. - Não registrar chaves BGP, tokens, senhas ou material sensível. - Validar somente por AWS API e SSM nas instâncias envolvidas. ## 2. Instâncias comparadas ### 2.1 EC2 bastion - Nome: `bastion` - ID: `i-06be52454b879cbbb` - Estado: `running` - VPC: `vpc-0d5ecd0df0976bcb9` - Subnet: `subnet-0a00cc821bc642306` - IP privado: `192.168.19.59` - IP público: `56.125.101.153` - Security group: `sg-0c96368cda8e679cf` - SSM: `Online` - SourceDestCheck: `false` - Perfil de instância: `monbank-bastion-ssm` ### 2.2 VM Monetarie RSFN - Nome: `monetarie-rsfn-egress-homolog` - ID: `i-0692fbf5e0dd6d350` - Estado: `running` - VPC: `vpc-0d5ecd0df0976bcb9` - Subnet: `subnet-0c9eb0464d27ef9ae` - IP privado: `192.168.40.10` - IP público OpenVPN: `52.67.167.212` - Security group: `sg-060e624746e07ed3d` - SSM: `Online` - SourceDestCheck: `false` - Perfil de instância: `monetarie-rsfn-egress-homolog` ## 3. Rede AWS observada - As duas instâncias estão na VPC RTM `vpc-0d5ecd0df0976bcb9`. - As duas subnets usam a mesma NACL `acl-0e728901fd2a59dab`, com entrada e saída liberadas. - Os security groups das duas instâncias têm saída `0.0.0.0/0` liberada. - A subnet da `bastion` usa a route table principal `rtb-0f84caeba8d62d2d7`. - A subnet da VM Monetarie RSFN usa a route table `rtb-003e7f7e9a48d7caf`. - Ambas possuem rota para `200.218.64.0/18` via Transit Gateway `tgw-051f1a3c159dfb25b`. - A rota para o HSM de teste `200.160.162.200/32` sai pela internet na VM Monetarie RSFN e por rota padrão na `bastion`. ## 4. Transit Gateway e Direct Connect - TGW: `tgw-051f1a3c159dfb25b` - Descrição: `Transito entre Monetarie e Lerian` - Route table padrão: `tgw-rtb-00c87955e8b181f3f`, nome `lerian-monetarie` - Route table de homologação: `tgw-rtb-04af02d0211998f4f`, nome `monetarie-tgw-rt-homolog` - Attachment RTM VPC: `tgw-attach-0b707c246893a3e69` - Attachment Direct Connect Gateway: `tgw-attach-011ddb564b76e89ac` Rotas relevantes na route table padrão do TGW: - `192.168.0.0/16` propagado pela RTM VPC. - `200.218.64.0/18` propagado pelo Direct Connect Gateway. - `200.218.64.0/19` propagado pelo Direct Connect Gateway. - `200.218.96.0/19` propagado pelo Direct Connect Gateway. - `200.160.161.0/24` propagado pelo Direct Connect Gateway. - `200.160.163.0/24` propagado pelo Direct Connect Gateway. Rotas relevantes na route table de homologação: - `200.218.64.0/18` estática para a RTM VPC. - `192.168.0.0/16` estática para a RTM VPC. Direct Connect observado: - VIF `MONETARIE-LERIAN`: estado `available`, BGP `up`. - VIF `MONETARIE-LERIAN-2`: estado `available`, BGP `up`. - Associação do Direct Connect Gateway ao TGW: `associated`. - Prefixo permitido para o Direct Connect Gateway: `192.168.0.0/16`. Observação: chaves BGP e material sensível não foram registrados neste documento. ## 5. Diagnósticos SSM executados ### 5.1 DNS, rota e TCP por hostname Command ID: `3b9dde5a-c7a1-44f5-8f5e-a1b1249cfa55` Resultado na `bastion`: - DNS `*.rsfn.net.br`: não resolveu. - Resolvedor: DNS padrão da VPC, sem forwarder RSFN dedicado. - TCP para hostnames RSFN: falhou por ausência de resolução. - TCP para HSM `200.160.162.200:63351`: OK. - HTTP HSM `/index.html`: 200. Resultado na VM Monetarie RSFN: - DNS `dict-h.pi.rsfn.net.br`: resolveu `200.218.66.145` e `200.218.67.209`. - DNS `dict-np-h.pi.rsfn.net.br`: resolveu `200.218.66.147` e `200.218.67.211`. - DNS `icom-h.pi.rsfn.net.br`: resolveu `200.218.66.141` e `200.218.67.205`. - DNS `icom-sec-h.pi.rsfn.net.br`: resolveu `200.218.66.151` e `200.218.67.215`. - DNS `arq-h.pi.rsfn.net.br`: resolveu `200.218.66.143`. - DNS `www.rsfn.net.br`: resolveu `200.218.66.12`. - TCP para serviços RSFN por hostname: falhou. - TCP para HSM `200.160.162.200:63351`: OK. - HTTP HSM `/index.html`: 200. ### 5.2 TCP e ICMP por IP direto Command ID: `1234e193-509b-43a2-941c-478ab61fb39a` Resultado igual nas duas instâncias: - TCP `200.218.66.145:16522`: FAIL. - TCP `200.218.67.209:16522`: FAIL. - TCP `200.218.66.147:16532`: FAIL. - TCP `200.218.67.211:16532`: FAIL. - TCP `200.218.66.141:16522`: FAIL. - TCP `200.218.67.205:16522`: FAIL. - TCP `200.218.66.151:17522`: FAIL. - TCP `200.218.67.215:17522`: FAIL. - TCP `200.218.66.143:1130`: FAIL. - TCP `200.218.66.12:80`: FAIL. - TCP `200.160.162.200:63351`: OK. - ICMP para `200.218.*`: FAIL. - ICMP para `200.160.162.200`: OK. ### 5.3 Trace de caminho Command ID: `7e6a30c8-42e6-4285-8580-b76028b7a8dc` Resultado: - O trace não retornou hop útil para os destinos `200.218.*`. - `traceroute` não estava disponível na VM Monetarie RSFN. - A saída não alterou o diagnóstico obtido por TCP e ICMP direto. ## 6. Conclusão técnica atual O problema atual não é apenas DNS. A `bastion` realmente não resolve `*.rsfn.net.br`, portanto ela não está pronta como ponto de resolução RSFN. Porém, mesmo usando IP direto, `bastion` e VM Monetarie RSFN falham para todos os destinos `200.218.*` testados. O caminho AWS tem indícios de estar montado até o Direct Connect: - route table da subnet aponta `200.218.64.0/18` para o TGW; - TGW tem rota ativa para `200.218.64.0/18`; - Direct Connect VIFs estão `available`; - BGP está `up`; - o prefixo permitido `192.168.0.0/16` cobre as origens `192.168.19.59` e `192.168.40.10`. Mesmo assim, não há resposta TCP nem ICMP a partir da AWS para `200.218.*`. A hipótese mais forte, com base nos testes atuais, é bloqueio, ausência de liberação, filtro, ACL, política de roteamento ou assimetria no lado RTM, Lerian, RSFN ou Direct Connect após a propagação BGP. Isso precisa ser validado com a contraparte de rede. ## 7. Próximas ações recomendadas 1. Não alterar `bastion` nem recursos Lerian sem autorização explícita. 2. Se a `bastion` for usada como ponto de diagnóstico recorrente, configurar DNS RSFN nela somente depois de aprovação. 3. Solicitar à contraparte RTM/Lerian validação de tráfego saindo de: - `192.168.19.59` para `200.218.64.0/18`; - `192.168.40.10` para `200.218.64.0/18`. 4. Confirmar se a rede RSFN aceita origem `192.168.0.0/16` ou se exige NAT, origem específica, prefixo menor ou liberação nominal. 5. Confirmar se as portas `16522`, `16532`, `17522` e `1130` estão liberadas para a Monetarie no ambiente de homologação. 6. Só depois de validação externa propor mudança local de rota, NAT, security group ou DNS.