Ошибка безопасности Letsencrypt ISPConfig 3 в Firefox

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 и клиентскими сетями TCP нет фактической маршрутизации IP, поддерживаемой Прокси-сервер, работающий на сервере шлюза, является единственным путем из сети в сеть в таком сценарии ... который, кстати, отлично работает на классе экземпляров t2.nano за 5 долларов в месяц.