Доступ в Интернет из частной подсети VPC?
Мой мозг немного взволнован, пытаясь понять это, но я не могу заставить частные подсети подключаться к Интернету, например, для получения обновлений. В основном все, что мне нужно, это доступ к этим серверам в сети. Я пробовал решения, найденные в других сообщениях, но мог легко что-то упустить, так как я смотрел на это довольно долго.
Пока что я сделал следующую настройку:
- Отключить проверку источника / назначения на моем экземпляре NAT
- Создайте таблицу маршрутизации для общедоступной подсети и установите ее источник на IGW (проверено, что это работает)
- Создайте таблицу маршрутизации для частной подсети и установите ее источником для экземпляра NAT.
- Создайте группу безопасности для экземпляра NAT с правилами для входящего и исходящего трафика для 80/443 и ssh
- Создайте группу безопасности для частного экземпляра с входящим и исходящим 80/443 и ssh
Я могу подключиться к экземпляру NAT через SSH, а затем перейти на частный сервер, поэтому я знаю, что многое работает. Я проверил свои правила путем проверки связи с внутренними адресами, но когда я выхожу из локальной сети, у меня начинаются проблемы.
Где мне нужно искать или что мне нужно устранить, чтобы сузить круг вопросов? Нужно ли выполнить некоторую настройку экземпляра NAT, который я пропустил?
РЕДАКТИРОВАТЬ: обновление конфигурации
- VPC: 172.16.0.0./16
- Частная подсеть: 172.16.1.0/24
- Публичная подсеть: 172.16.0.0/24
Таблица маршрутизации частной подсети:
Указывает на экземпляр NAT в общедоступной подсети. Невозможно получить доступ к Интернету, EIP привязан к общедоступному интерфейсу с выходом в Интернет.
Таблица маршрутизации публичной подсети:
Указывает общедоступную подсеть на IGW, я проверил доступ в Интернет.
Мысли:
Я начинаю думать, что есть что-то, что нужно настроить или создать в экземпляре NAT, который живет в общедоступной подсети для пересылки трафика от частных экземпляров, но я не совсем уверен, что нужно добавить. я нашел эта почта это объясняет добавление правила маскарада в iptables, относится ли это к моей ситуации?
да, на хосте nat необходимо настроить маскировку iptables.
iptables -A POSTROUTING -t nat -s (private-subnet/cidr) -j MASQUERADE
у нас такая же настройка, все остальное вы сделали правильно (отключите проверку источника, укажите частную подсеть на интерфейс экземпляра nat, укажите общедоступную подсеть на igw).
Некоторое время я боролся с этим, пока не нашел:
Затем запустите экземпляр в своей общедоступной подсети из AMI, настроенного для работы в качестве экземпляра NAT. Amazon предоставляет AMI Amazon Linux, настроенные для работы как инстансы NAT. Эти AMI включают в себя строку amzn-ami-vpc-nat, поэтому вы можете искать их в консоли Amazon EC2.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html#NATInstance
Я настроил NAT-сервер как свой собственный стандартный (Ubuntu) экземпляр, как только я использовал Amazon Linux AMI и обновил свои таблицы маршрутизации, он начал работать.
Просто наткнулся на это с похожей проблемой. Предполагая, что вы использовали мастер для создания экземпляра NAT, упомянутое выше правило маскарада уже будет там - это только то, что вам нужно добавить, если вы собираетесь «развернуть свой собственный» экземпляр NAT. (Обычно я делаю это, чтобы удвоить это, а также сделать его VPN-сервером удаленного пользователя OpenSWAN L2TP / IPSec).
Что я забыл добавить с момента создания одного из них в последний раз, так это правила, которые разрешают весь трафик (или, по крайней мере, то, что вы хотите разрешить) из всех частных групп безопасности или подсетей, которые будут маршрутизировать трафик через экземпляр NAT. Экземпляр NAT не будет принимать такой исходящий трафик без правил, разрешающих его - не думайте только о том, что приходит из Интернета, чтобы добраться до него. Не уверен, что это ваша проблема, поскольку вы упомянули о добавлении 22/80/443 в свою группу безопасности NAT, но подумали, что я предлагаю это для других, у которых может быть аналогичная проблема.