Uma empresa introduziu um requisito de segurança para inspecionar todo o tráfego das instâncias AWS corporativas em sua VPC em busca de violações de política e para bloquear endereços IP específicos. Para atender a isso, a empresa implantou instâncias EC2 executando software de proxy aprovado em sub-redes privadas como proxies transparentes, atualizou as tabelas de rotas da sub-rede para usar as instâncias de proxy como rota padrão e anexou grupos de segurança compatíveis com a política. Apesar dessas mudanças, o tráfego das instâncias em sub-redes privadas não está sendo encaminhado para a internet através dos proxies. O que um arquiteto de soluções deve fazer para corrigir isso?

A desativação das verificações de origem/destino nas instâncias EC2 que atuam como proxies transparentes é crucial porque, por padrão, uma instância EC2 verifica se o tráfego que ela envia ou recebe tem seu próprio endereço IP de origem ou destino. Quando uma instância atua como proxy ou roteador, ela precisa encaminhar tráfego para outros endereços IP, o que viola essa verificação. Desativar essa verificação permite que a instância encaminhe pacotes que não são destinados a ela mesma. As outras opções estão incorretas: Adicionar uma regra de grupo de segurança para permitir todo o tráfego entre instâncias e atribuir a todas as instâncias não resolve o problema fundamental de encaminhamento de tráfego que não tem a instância de proxy como origem/destino. Alterar as opções DHCP para o servidor DNS das instâncias de proxy afetaria apenas a resolução de nomes, não o roteamento de todo o tráfego. Anexar ENIs adicionais não é necessário para o funcionamento básico de um proxy transparente e não corrige o problema de encaminhamento de pacotes que não têm a instância como origem/destino, que é o foco da verificação de origem/destino.