Таблица маршрутизации AWS VPC с интернет-шлюзом и шлюзом NAT

Таблица маршрутизации AWS VPC с интернет-шлюзом и шлюзом NAT

У меня есть один VPC в Amazon Web Services с подсетью 172.31.0.0/16. Я создал экземпляр EC2 в этой подсети и дал ему публичный Elastic IP. На этом VPC есть интернет-шлюз. Итак, моя таблица маршрутизации выглядит так:

172.31.0.0/16   local
0.0.0.0/0       igw-b4ac67d0    

Чтобы обойти некоторые проблемы с доступом по IP на внешнем сервисе, который я не контролирую, я добавил шлюз NAT к этому VPC, чтобы весь трафик на единственный внешний адрес ABCD направлялся через шлюз NAT. То есть, я хочу, чтобы таблица маршрутизации выглядела так:

# GOAL
172.31.0.0/16   local
A.B.C.D/32      nat-451b3be9
0.0.0.0/0       igw-b4ac67d0    

Однако, как бы я ни старался, интерфейс AWS меняет порядок, когда я нажимаю «СОХРАНИТЬ», так что в итоге я всегда получаю

# What AWS gives me
172.31.0.0/16   local
0.0.0.0/0       igw-b4ac67d0    
A.B.C.D/32      nat-451b3be9

Эта таблица маршрутизации кажется глупой: шлюз NAT никогда не будет использоваться, а мой трафик по-прежнему A.B.C.Dбудет поступать с эластичного IP-адреса экземпляра EC2.

Как получить таблицу маршрутов GOAL?

Примечание: внешняя служба позволит мне добавитьодинокийIP-адрес, который он разрешит. Если бы у меня был только один экземпляр EC2, я мог бы просто дать им эластичный IP-адрес экземпляра EC2. Но я хочу добавить еще несколько экземпляров EC2, настроенных таким же образом. Следовательно, шлюз NAT. Кроме того, я не могу просто обойтись без интернет-шлюза и использовать только шлюз NAT, так как мне нужно, чтобы службы на экземпляре EC2 были доступны из внешнего мира.

решение1

Эта таблица маршрутов кажется глупой

Да, в вашей интерпретации... но ваша интерпретация неверна. Записи таблицы маршрутизации в VPC на самом деле не имеют порядка.

Всегда выбирается наиболее конкретный маршрут.

Каждый маршрут в таблице указывает CIDR назначения и цель (например, трафик, предназначенный для внешней корпоративной сети 172.16.0.0/12, предназначен для виртуального частного шлюза). Мы используем наиболее конкретный маршрут, который соответствует трафику, чтобы определить, как маршрутизировать трафик.

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

Однако ваша конфигурация все еще не работает, если шлюз NAT фактически находится в подсети, которая использует эту таблицу маршрутизации. Шлюз NAT должен находиться в подсети, таблица маршрутизации которой не имеетлюбоймаршруты, указывающие обратно на шлюз NAT -- в противном случае это петля маршрутизации. В направлении Интернета шлюз NAT использует таблицу маршрутизации VPC подсети, к которой он фактически подключен, чтобы получить доступ к шлюзу Интернета... поэтому он должен находиться в другой подсети, нежели та, в которой находятся экземпляры, которые будут его использовать, поскольку этот /32маршрут не может быть размещен там, где он повлияет на исходящий трафик от шлюза NAT.

Это противоречит здравому смыслу для людей, которые не понимают, что сеть VPC — это не обычная сеть Ethernet с маршрутизаторами. Вся сеть определяется программным обеспечением, а не физически, поэтому нет никакого ухудшения производительности, когда трафик пересекает границы подсетей в пределах зоны доступности, как в случае с экземпляром EC2 в одной подсети, использующим шлюз NAT (или экземпляр NAT) в другой подсети, или Elastic Load Balancer в одной подсети, подключающимся к экземпляру EC2 в другой подсети. Действительно, переход трафика из одной подсети в другую в этих случаях является стандартной конфигурацией, размещающей шлюзы NAT и ELB в публичных подсетях (маршрут по умолчанию — IGW), а экземпляры EC2 — в частных (маршрут по умолчанию — устройство NAT).

Обратите внимание, что конфигурация, которую вы пытаетесь настроить, разрешит исходящие, но никогда не разрешит входящие соединения (инициированные извне) с A.B.C.Dадреса на что-либо в этой подсети, поскольку обратный маршрут через шлюз NAT асимметричен.

Связанный контент