Tenho uma única VPC na Amazon Web Services com a sub-rede 172.31.0.0/16. Criei uma instância EC2 nesta sub-rede e atribuí a ela um IP elástico público. Há um gateway de Internet nesta VPC. Então, minha tabela de rotas fica assim:
172.31.0.0/16 local
0.0.0.0/0 igw-b4ac67d0
Para contornar alguns problemas de acesso IP em um serviço externo que não controlo, adicionei um gateway NAT a esta VPC para que todo o tráfego para o único endereço externo ABCD fosse roteado através do gateway NAT. Ou seja, quero que a tabela de rotas fique assim:
# GOAL
172.31.0.0/16 local
A.B.C.D/32 nat-451b3be9
0.0.0.0/0 igw-b4ac67d0
No entanto, por mais que eu tente, a interface da AWS muda a ordem quando clico em "SAVE" para que eu sempre termine com
# What AWS gives me
172.31.0.0/16 local
0.0.0.0/0 igw-b4ac67d0
A.B.C.D/32 nat-451b3be9
Esta tabela de rotas parece boba: o gateway NAT nunca seria usado e meu tráfego A.B.C.Dainda parece vir do Elastic IP da instância do EC2.
Como obtenho o GOAL da tabela de rotas?
Nota: O serviço externo me permitirá adicionar umsolteiroEndereço IP que permitirá o acesso. Se eu tivesse apenas uma única instância do EC2, poderia simplesmente fornecer a eles o endereço IP elástico da instância do EC2. Porém, quero adicionar várias outras instâncias do EC2 configuradas da mesma maneira. Conseqüentemente, o gateway NAT. Além disso, não posso simplesmente dispensar o gateway da Internet e usar apenas o gateway NAT, pois preciso que os serviços na instância EC2 sejam acessíveis ao mundo exterior.
Responder1
Esta tabela de rotas parece boba
Sim, na sua interpretação... mas a sua interpretação não está correta. As entradas da tabela de rotas na VPC não têm, na verdade, uma ordem.
A rota mais específica é sempre selecionada.
Cada rota em uma tabela especifica um CIDR de destino e um destino (por exemplo, o tráfego destinado à rede corporativa externa 172.16.0.0/12 é direcionado ao gateway privado virtual). Usamos a rota mais específica que corresponde ao tráfego para determinar como rotear o tráfego.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html
No entanto, a sua configuração ainda não funciona se o Gateway NAT estiver realmente localizado numa sub-rede que utiliza esta tabela de rotas. O Gateway NAT deve estar em uma sub-rede cuja tabela de rotas não tenhaqualquerrotas apontando de volta para o gateway NAT - caso contrário, é um loop de roteamento. Para a Internet, o Gateway NAT usa a tabela de rotas VPC da sub-rede à qual está realmente conectado para acessar o Gateway da Internet... portanto, deve estar em uma sub-rede diferente daquela com as instâncias que irão use-a, porque esta /32rota não pode ser colocada onde impactará o tráfego de saída do gateway NAT.
Isso é contra-intuitivo para quem não percebe que a rede VPC não é uma rede Ethernet convencional com roteadores. Toda a rede é definida por software, não física, portanto não há penalidade de desempenho quando o tráfego cruza os limites da sub-rede dentro de uma zona de disponibilidade, como é o caso de uma instância EC2 em uma sub-rede usando um gateway NAT (ou instância NAT) em um sub-rede diferente ou um Elastic Load Balancer em uma sub-rede conectando-se a uma instância do EC2 em uma sub-rede diferente. Na verdade, o tráfego que cruza de uma sub-rede para outra nesses casos é a configuração padrão, colocando gateways NAT e ELBs em sub-redes públicas (a rota padrão é IGW) e instâncias EC2 em sub-redes privadas (a rota padrão é o dispositivo NAT).
Observe ainda que a configuração que você está tentando permitirá conexões de saída, mas nunca permitirá conexões de entrada (iniciadas de fora) do A.B.C.Dendereço para qualquer coisa nesta sub-rede, porque a rota de retorno é assimétrica através do gateway NAT.