Итак, у меня есть VPN-туннель, настроенный и работающий между моим SonicWall TZ105 и моим AWS VPC. Нет проблем, он отлично работает, насколько это возможно.
Я понятия не имею, как это сделать, так это получить мои экземпляры EC2 в моем VPC, получить доступ к Интернету. Я хочу, чтобы мои экземпляры EC2 (у которых есть только частный IP-адрес) могли маршрутизировать трафик через SonicWall и иметь доступ к Интернету.
Я думаю, мне нужна какая-то комбинация маршрутизации и политики NAT, чтобы сделать это?
Кто-нибудь может мне подсказать?
Спасибо!
Хотя вы можете или не можете делать все, что показано на рисунке, ваша настройка по сути такая же, как Сценарий VPC 3.
В двух словах...
Создайте новую таблицу маршрутов VPC.
Установите его маршрут по умолчанию (0.0.0.0/0) так, чтобы он указывал на ваш Sonicwall, которому будет назначен идентификатор виртуального частного шлюза внутри VPC - это выглядит так vgw-xxxxxxxx.
Свяжите подсети, в которых расположены ваши экземпляры без общедоступных IP-адресов, с этой новой таблицей маршрутов.
Вам не нужно настраивать маршрутизацию на стороне AWS, чтобы трафик из туннеля достигал экземпляров. Это всегда возможно в VPC - VPN пользуется доверием в том, что касается маршрутизации, поэтому маршрутизация входящего трафика в подсети, где расположены экземпляры, является неявной.
Это отправит связанный с Интернетом трафик от экземпляров VPC через VPN-соединение с сохранением их частных IP-адресов. Sonicwall необходимо будет настроить для выполнения необходимой трансляции сетевых адресов в трафике, чтобы разрешить ему доступ в Интернет с использованием общедоступного IP-адреса Sonicwall, что, как мы надеемся, является наиболее простой частью этой настройки.
Видеть http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html
Обратите внимание: если вы - сейчас или в будущем - хотите, чтобы экземпляры EC2 внутри VPC имели назначенные AWS общедоступные IP-адреса, вам необходимо будет разместить их в разных подсетях внутри VPC. Эти подсети, известные как общедоступные подсети, используют объект Интернет-шлюза VPC (igw-xxxxxxxx) для входа и выхода в Интернет.
Также обратите внимание, что если вы используете сервисы AWS, такие как DynamoDB, SNS, SQS и т. Д., Вам, вероятно, понадобится экземпляр NAT или шлюз NAT в вашем VPC, чтобы позволить некоторому уровню исходящего интернет-трафика сократить путь через вашу VPN. потому что почти все сервисы AWS, даже в пределах региона, требуют, чтобы ваши экземпляры имели доступ к «Интернету», чтобы получить к ним доступ. (S3 является одним исключением, он позволяет создать «конечную точку» VPC, которая устраняет необходимость в доступе в Интернет). Если вы получаете доступ к этим сервисам посредством обратного рейса через ваше VPN-соединение, у вас будут повышенные затраты и более высокая задержка, поскольку вы будете без необходимости платить за трафик в обоих направлениях, перенаправляя его за пределы региона AWS и обратно.
Последнее замечание: при устранении неполадок вы обнаружите, что разрешение DNS в VPC по умолчанию всегда работает ... даже если остальная часть вашей маршрутизации полностью и безнадежно неверна ... потому что разрешение DNS обрабатывается некоторой скрытой сетевой магией внутри VPC . Пусть вас не смущает тот факт, что DNS работает. (пример: «хост x разрешается, но я не могу на самом деле пинговать его» - да, это почти всегда будет разрешаться, и этот факт не обязательно ничего говорит о конфигурации вашей сети.)