У меня есть один VPC в Amazon Web Services с подсетью 172.31.0.0/16. Я создал экземпляр EC2 в этой подсети и присвоил ему общедоступный эластичный IP-адрес. На этом VPC есть интернет-шлюз. Итак, моя таблица маршрутов выглядит так:
172.31.0.0/16 local
0.0.0.0/0 igw-b4ac67d0
Чтобы обойти некоторые проблемы с IP-доступом к внешней службе, которую я не контролирую, я добавил шлюз NAT к этому VPC, чтобы весь трафик на единственный внешний адрес A.B.C.D проходил через шлюз 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, чтобы они были доступны для внешнего мира.
Эта таблица маршрутов кажется глупой
Да, в вашей интерпретации ... но ваша интерпретация неверна. Записи таблицы маршрутов в 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) на другая подсеть или эластичный балансировщик нагрузки в одной подсети, подключенный к экземпляру EC2 в другой подсети. Действительно, переход трафика из одной подсети в другую в этих случаях является стандартной конфигурацией, при которой шлюзы NAT и ELB размещаются в общедоступных подсетях (маршрут по умолчанию - IGW), а экземпляры EC2 - в частных (маршрут по умолчанию - устройство NAT).
Обратите внимание, что конфигурация, которую вы пытаетесь, разрешит исходящий, но никогда не разрешит входящие подключения (инициированные извне) от A.B.C.D адрес к чему-либо в этой подсети, потому что обратный маршрут асимметричен через шлюз NAT.