Tabela de roteamento do AWS VPC com o Gateway da Internet e o Gateway NAT

3

Eu tenho um único VPC no Amazon Web Services com a sub-rede 172.31.0.0/16. Eu criei uma instância do EC2 nessa sub-rede e dei a ela um IP elástico público. Existe um gateway de Internet neste VPC. Então, minha tabela de rotas é 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 eu não controlei, adicionei um gateway NAT a esse VPC para que todo o tráfego para o único endereço externo A.B.C.D fosse roteado através do gateway NAT. Ou seja, quero que a tabela de rotas tenha esta aparência:

# 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 "SALVAR" 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 rota parece tola: o gateway NAT nunca seria usado e meu tráfego para A.B.C.D ainda parece vir do Elastic IP da instância do EC2.

Como obtenho a meta da tabela de rotas?

Observação: o serviço externo permitirá que eu adicione um endereço IP único que permitirá o acesso. Se eu tivesse apenas uma única instância do EC2, poderia simplesmente fornecer-lhes o endereço Elastic IP da instância do EC2. Mas, quero adicionar várias outras instâncias do EC2 configuradas da mesma maneira. Por isso, 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 do EC2 sejam acessíveis pelo mundo externo.

    
por user35042 14.01.2017 / 18:55

1 resposta

4

This route table seems silly

Sim, na sua interpretação ... mas a sua interpretação não está correta. As entradas da tabela de rotas no VPC não têm realmente um pedido.

A rota mais específica é sempre selecionada.

Each route in a table specifies a destination CIDR and a target (for example, traffic destined for the external corporate network 172.16.0.0/12 is targeted for the virtual private gateway). We use the most specific route that matches the traffic to determine how to route the traffic.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html

No entanto, sua configuração ainda não funciona se o Gateway NAT estiver localizado em uma sub-rede que usa essa tabela de rotas. O NAT Gateway deve estar em uma sub-rede cuja tabela de roteamento não tem qualquer rotas apontando para o NAT Gateway - caso contrário, isso é um loop de roteamento. Na direção da Internet, o NAT Gateway usa a tabela de rotas VPC da sub-rede à qual está realmente conectada para acessar o Gateway da Internet ... portanto, ele precisa estar em uma sub-rede diferente daquela com as instâncias que estão indo use-o, porque essa /32 route não pode ser colocada onde impactará o tráfego de saída do NAT Gateway.

Isso é contra-intuitivo para pessoas que não percebem 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 limites de sub-rede dentro de uma zona de disponibilidade, como é o caso de uma instância EC2 em uma sub-rede usando um NAT Gateway (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. De fato, a passagem de tráfego de uma sub-rede para outra nesses casos é a configuração padrão, colocando NAT Gateways e ELBs em sub-redes públicas (a rota padrão é IGW) e as instâncias EC2 nas privadas (a rota padrão é o dispositivo NAT).

Observe também que a configuração que você está tentando permitirá a saída, mas nunca permitirá conexões de entrada (iniciadas de fora) do endereço A.B.C.D para qualquer coisa nesta sub-rede, porque a rota de retorno é assimétrica através do gateway NAT. / p>     

por 14.01.2017 / 23:50