Tengo una única VPC en Amazon Web Services con la subred 172.31.0.0/16. Creé una instancia EC2 en esta subred y le asigné una IP elástica pública. Hay una puerta de enlace de Internet en esta VPC. Entonces, mi tabla de rutas se ve así:
172.31.0.0/16 local
0.0.0.0/0 igw-b4ac67d0
Para solucionar algunos problemas de acceso IP en un servicio externo que no controlo, agregué una puerta de enlace NAT a esta VPC para que todo el tráfico a la única dirección externa ABCD se enrute a través de la puerta de enlace NAT. Es decir, quiero que la tabla de rutas se vea así:
# GOAL
172.31.0.0/16 local
A.B.C.D/32 nat-451b3be9
0.0.0.0/0 igw-b4ac67d0
Sin embargo, por más que lo intento, la interfaz de AWS cambia el orden cuando hago clic en "GUARDAR", de modo que siempre termino con
# 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 tabla de rutas parece una tontería: la puerta de enlace NAT nunca se usaría y mi tráfico todavía A.B.C.Dparece provenir de la IP elástica de la instancia EC2.
¿Cómo obtengo el OBJETIVO de la tabla de rutas?
Nota: El servicio externo me permitirá agregar unsolteroDirección IP que permitirá el acceso. Si solo tuviera una instancia EC2, simplemente podría darles la dirección IP elástica de la instancia EC2. Pero quiero agregar varias instancias EC2 más configuradas de la misma manera. De ahí la puerta de enlace NAT. Además, no puedo simplemente prescindir de Internet Gateway y usar solo la puerta de enlace NAT, ya que necesito que los servicios en la instancia EC2 sean accesibles desde el mundo exterior.
Respuesta1
Esta tabla de rutas parece tonta.
Sí, en tu interpretación... pero tu interpretación no es correcta. Las entradas de la tabla de rutas en VPC en realidad no tienen un orden.
Siempre se selecciona la ruta más específica.
Cada ruta en una tabla especifica un CIDR de destino y un destino (por ejemplo, el tráfico destinado a la red corporativa externa 172.16.0.0/12 está destinado a la puerta de enlace privada virtual). Utilizamos la ruta más específica que coincida con el tráfico para determinar cómo enrutar el tráfico.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html
Sin embargo, su configuración aún no funciona si la puerta de enlace NAT está realmente ubicada en una subred que usa esta tabla de rutas. La puerta de enlace NAT debe estar en una subred cuya tabla de rutas no tengacualquierrutas que apuntan hacia la puerta de enlace NAT; de lo contrario, se trata de un bucle de enrutamiento. Hacia Internet, el Gateway NAT utiliza la tabla de rutas VPC de la subred a la que realmente está conectado para poder acceder al Gateway de Internet... por lo que tiene que estar en una subred diferente a la que tienen las instancias que van a Úselo, porque esta /32ruta no se puede colocar donde afecte el tráfico saliente desde la puerta de enlace NAT.
Esto es contradictorio para las personas que no se dan cuenta de que la red VPC no es una red Ethernet convencional con enrutadores. Toda la red está definida por software, no física, por lo que no hay penalización en el rendimiento cuando el tráfico cruza los límites de la subred dentro de una zona de disponibilidad, como es el caso de una instancia EC2 en una subred que utiliza una puerta de enlace NAT (o instancia NAT) en una subred diferente, o un Elastic Load Balancer en una subred que se conecta a una instancia EC2 en una subred diferente. De hecho, el tráfico que cruza de una subred a otra en estos casos es la configuración estándar, colocando puertas de enlace NAT y ELB en subredes públicas (la ruta predeterminada es IGW) e instancias EC2 en privadas (la ruta predeterminada es el dispositivo NAT).
Tenga en cuenta además que la configuración que está intentando permitirá conexiones salientes, pero nunca entrantes (iniciadas desde el exterior) desde la A.B.C.Ddirección a cualquier elemento de esta subred, porque la ruta de retorno es asimétrica a través de la puerta de enlace NAT.