Я пытаюсь подключить клиентскую сеть к нашему дата-центру AWS, чтобы разрешить доступ к (ранее общедоступному) внутреннему веб-приложению.
На данный момент у нас настроена VPN с динамической маршрутизацией к новому пустому VPC с CIDR, который не конфликтует с сетью клиента, так как наш основной VPC конфликтует.
Несколько вопросов:
1) Нужно ли рекламировать или распространять этот CIDR в клиентской сети, и как мне это сделать?
2) Как перенаправить доступный клиенту IP-адрес в этом диапазоне на внутренний IP-адрес в VPC, содержащем веб-приложение?
3) И после этого как я могу применить группу безопасности к этому VPN-соединению, чтобы ограничить доступ к этому IP-адресу?
Или я ошибаюсь?
1) Нужно ли рекламировать или распространять этот CIDR в клиентской сети, и как мне это сделать?
Если у VPN есть динамическая маршрутизация, это означает, что он настроен для BGP, поэтому CIDR для VPC должен автоматически объявляться.
2) Как перенаправить доступный клиенту IP-адрес в этом диапазоне на внутренний IP-адрес в VPC, содержащем веб-приложение?
Вот где ваш план рушится.
Чтобы трафик пересекал границы VPC, у VPC должно быть пиринговое соединение. Пиринговые соединения не поддерживают транзитный трафик.
Если какой-либо VPC в пиринговом соединении имеет одно из следующих соединений, вы не можете расширить пиринговые отношения на это соединение:
• VPN-соединение [...]
http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/invalid-peering-configurations.html
VPN-соединение с VPC B не имеет доступа к ресурсам в VPC A, даже когда A и B находятся в одноранговой сети.
Но, как покажет следующий момент, это тоже хорошо.
3) И после этого как я могу применить группу безопасности к этому VPN-соединению, чтобы ограничить доступ к этому IP-адресу?
Вы не можете. VPN-подключения, предоставляемые VPC, по своей сути являются надежными. Им разрешен доступ к любому экземпляру в VPC, где группа безопасности на экземпляре разрешает этот доступ, что означает, что все ваши экземпляры, в том числе с частными IP-адресами, должны быть должным образом защищены их группами безопасности, поскольку соединение VPC VPN открывает большую дыру в брандмауэре для этого доверенного соединения.
Однако ... у вас нет этой проблемы, потому что вы создали новый VPC для взаимодействия с клиентом, и он не может проходить через ваше пиринговое соединение в основной VPC.
Решением проблемы в пункте 2 является настройка прокси-сервера в VPC B. Настройте его группу безопасности, чтобы разрешить доступ с разрешенного IP-адреса клиента, что решает пункт 3, поскольку в этом VPC больше ничего нет. Направьте прокси-сервер на реальную службу в VPC A и разрешите его IP-адресу доступ к службе через соответствующую группу безопасности в VPC A.
Или я ошибаюсь?
Может быть. :) Сервис VPN, встроенный в VPC, похоже, предназначен для подключения к полностью доверенным сетям.
В моей инфраструктуре у меня есть только одно такое VPN-подключение к сети клиента, но в этом случае весь VPC находится в отдельной учетной записи AWS и имеет инфраструктуру, выделенную для этого одного клиента.
Во всех остальных случаях, когда у меня есть туннель IPSec в / из клиентской сети, я не использую предложение VPN от VPC, поскольку, как вы можете видеть выше, он действительно не идеален для этого. Вместо этого я завершаю туннель на экземпляре EC2 с эластичным IP-адресом, работающим под управлением Linux, Openswan и HAProxy.
Нумерация сети не имеет значения, потому что я назначаю неконфликтный адрес вторичному интерфейсу обратной связи на экземпляре шлюза и привязываю к нему HAProxy. Независимо от того, получаю ли я доступ к LDAP или HTTP-сервису клиента или они обращаются к одному из моих, мои машины видят обычный IP-адрес прокси, назначенный экземпляру VPC, но сеть клиента видит фальшивый неконфликтный адрес, который прокси использует для прослушивание подключений от клиента или установление исходящих подключений к клиенту внутри туннеля IPSec.
Таким образом, между моей сетью VPC и клиентом не существует фактической IP-маршрутизации - двусторонние TCP-соединения, поддерживаемые прокси-сервером на сервере шлюза, являются единственным путем из сети в сеть, в таком сценарии ... кстати, отлично работает на экземпляре класса t2.nano за 5 долларов в месяц.