APRENDER. PRATICAR. EVOLUIR.1. Encontrar a tabela que decide
O pacote entra no Transit Gateway através de um attachment. A associação desse attachment determina a tabela usada para procurar a rota. Propagação publica prefixos em tabelas; não equivale à escolha da tabela de entrada. No exercício, Apps está associado a RT-Apps e Shared a RT-Shared. Uma rota correta em RT-Shared não corrige, por si só, a procura de tráfego que entra por Apps. Escreve origem, destino, attachment de entrada e tabela consultada em cada salto. Este registo simples evita diagnosticar a tabela que tem o nome mais intuitivo em vez da que efetivamente toma a decisão.
2. Resolver prefixos e blackholes
Começa pelas rotas que correspondem ao endereço de destino e seleciona o prefixo mais específico. Para 10.84.7.40, /24 vence /16. Se o /24 selecionado é blackhole, o pacote é descartado; não há fallback automático para o /16 utilizável. Para destinos idênticos, o exercício compara apenas rota estática e propagada, dando preferência à estática conforme a documentação TGW. Não generalizes este pequeno modelo a toda a seleção BGP ou ECMP. A tabela abaixo produz descarte para 10.84.7.40 e VPN para 10.84.8.40. Explica o resultado antes de consultar a solução.
3. Desenhar o retorno como outra procura
Uma aplicação em Apps envia um SYN que chega a Shared. A resposta sai de Shared e entra no TGW pelo attachment Shared, cuja tabela precisa de uma rota para Apps. Não repitas a validação da tabela Apps e declares o problema resolvido. Além das tabelas TGW, as subnets precisam das rotas adequadas e os controlos do caminho continuam relevantes. Neste caso delimitado, a rota de retorno é a única falha identificada; fora dele, ausência de resposta não prova automaticamente routing assimétrico. Define que observação distingue rota ausente, filtro de segurança, processo sem listener e erro funcional.
4. Detetar inspeção contornada
Na tabela da oficina, 0.0.0.0/0 aponta para Inspection, mas 10.96.0.0/16 aponta diretamente para Payments. Um pacote para 10.96.2.8 segue o /16. Appliance mode no attachment da VPC de inspeção apoia afinidade de AZ em percursos suportados; não força um pacote que escolheu outra rota a visitar a appliance. Se a política exige inspeção, o caminho direto impede aceitação mesmo quando a aplicação responde. Analisa as duas direções, a configuração da VPC de inspeção e a falha de uma appliance. Uma mudança de modo em attachments existentes pode afetar fluxos em curso e precisa de planeamento.
5. Ensaiar segmentação positiva e negativa
A intenção Apps→Shared permitido e Apps→Restricted proibido precisa de evidência para os dois resultados. Uma tabela separada pode conter uma propagação demasiado ampla ou uma rota estática que cria acesso inesperado. Um blackhole /0 também não impede um /24 mais específico autorizado de ser escolhido. Verifica associações e rotas efetivas, depois ensaia os fluxos permitidos e os que devem falhar nos sentidos relevantes. O resultado da procura local é uma decisão de encaminhamento, não autenticação do utilizador nem prova de todos os controlos. Preserva essa distinção no relatório de segurança e na aceitação do projeto.
6. Da solução de mesa à mudança autorizada
Conclui a oficina com três entregas: tabela usada em cada sentido, rota selecionada para cada destino e evidência adicional exigida antes da mudança. Conserva a configuração anterior e delimita a alteração ao serviço aprovado. O modelo local usa IPv4, correspondência de prefixos e preferência estática/propagada; não simula BGP, health checks, convergência, firewalls ou pacotes reais. Um resultado correto permite discutir a hipótese, mas não garante serviço em produção nem tempo de recuperação. No handover, atribui responsáveis às rotas, monitorização, testes de retorno e condição de rollback para que RUN consiga repetir o diagnóstico.
RT-Apps
10.84.0.0/16 propagated VPN
10.84.7.0/24 static BLACKHOLE
lookup 10.84.7.40 -> DROP
lookup 10.84.8.40 -> VPN
0.0.0.0/0 static Inspection
10.96.0.0/16 static Payments
lookup 10.96.2.8 -> Payments [inspection bypass]RT-Apps seleciona o /24 blackhole para 10.84.7.40; uma rota correta em RT-Shared não altera essa procura.
Armadilhas comuns
Propagação como associação; fallback após blackhole; validar só a ida; appliance mode como desvio obrigatório; modelo como teste real.
Tópicos relacionados: DNS híbrido · Inspeção e auditoria
Segue a tabela de entrada, escolhe o prefixo mais específico e repete a análise no retorno.
Referência: How Transit Gateway works · ANS-C01