соединение aws vpc с vpc с openvpn

Транзит маршрутизируемого IP-трафика через VPC не поддерживается одноранговыми соединениями.

Пиринговое соединение не дает того уровня подключения, который вы могли бы ожидать от VPN или других межсетевых соединений, с которыми вы, возможно, знакомы.

Рассмотрим этот пример из документации (с незначительным переформатированием для ясности), который, по общему признанию, не описывает точно вашу ситуацию, но способствует пониманию более серьезной проблемы.

У вас есть пиринговое соединение VPC между VPC A и VPC B (pcx-aaaabbbb) и между VPC A и VPC C (pcx-aaaacccc).

Между VPC B и VPC C установлено пиринговое соединение VPC.

Вы не можете маршрутизировать пакеты напрямую из VPC B в VPC C через VPC A.

http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/invalid-peering-configurations.html#transitive-peering

Это часть структуры пиринга VPC - это функция, влияющая только на экземпляры в двух VPC - они могут получить доступ друг к другу. Другие ресурсы в VPC, такие как NAT и Интернет-шлюзы, конечные точки службы VPC (для S3), прямое подключение и аппаратная VPN, не доступны через пиринг.

tl; dr: Пиринг VPC не обеспечивает никакой IP-маршрутизации или подключения за пределами экземпляров EC2 в VPC с прямым пирингом.

Таким образом, приведенное выше не является идеальным объяснением, поскольку в задокументированном примере все три VPC, конечно, находятся в одном регионе, но к вашей конфигурации применимы аналогичные принципы.

Проблема не столько в том, что VPC-1 не может связаться с VPC-4 через туннель к VPC-3 (трафик может приходить, а может и не приходить), а скорее в том, что VPC-4 не имеет абсолютно никакого способа отправить ответ. VPC-4 не может передавать VPC-3 на пути к чему-то внешнему по отношению к VPC-3 (VPC-1).

Точно так же это было причиной моего вопроса о возможности подключения между VPC-2 и VPC-3. VPC-2 не может передавать VPC-1 на пути к адресам доступа в VPC-3.

Входящий трафик, связанный с удаленной сетью, никогда не попадает на туннельный сервер, потому что нет механизма для перехода через VPC, а трафик на туннельный сервер - хотя, возможно, не документирован как таковой - все еще является случаем транзита.

У вас была бы такая же проблема, если бы между VPC-1 и внешним корпоративным центром обработки данных был аппаратный VPN VPC. Это соединение VPN не обеспечит доступ из внешнего центра обработки данных к чему-либо за пределами VPC-1, независимо от какого-либо пиринга. То же самое и с AWS Direct Connect.

Анализируя это только с точки зрения интерфейса API / консоли, подумайте о том, как вы отправляете трафик через одноранговое соединение: вы создаете маршрут, отправляющий префикс внешнего IP-адреса от одного VPC к другому, создавая запись в таблице маршрутов, используя идентификатор однорангового соединения в качестве цели. .

Но что происходит, когда этот трафик поступает в одноранговый VPC? Какая таблица маршрутов к нему применяется?

Это вопрос с подвохом, потому что нет открытая таблица маршрутов применяется к трафику, входящему через одноранговое соединение VPC - единственные маршруты, доступные для этого входящего трафика, - это неявный локальный маршрут, который делает экземпляры доступный.

Трафик, адресованный чему-то другому, кроме экземпляра (или службы, работающей в экземпляре, например RDS), - когда он поступает в одноранговый VPC - некуда деваться, и он отбрасывается.

Логическим обходным решением было бы попытаться направить трафик через пиринговое соединение к экземпляру, действующему как маршрутизатор ... почти так же, как вы маршрутизируете трафик к экземпляру NAT - путем установки пункта назначения в таблице маршрутов на экземпляр -id или связанный с ним эластичный сетевой интерфейс (ENI).

Внизу страницы документации, упомянутой выше, мы находим ограничение одним предложением для такой практики:

Точно так же, если VPC A имеет устройство NAT, которое обеспечивает доступ в Интернет экземплярам в частных подсетях в VPC A, экземпляры в VPC B не могут использовать устройство NAT для доступа в Интернет.

Это, вероятно, менее ясно, чем могло бы быть для тех, кто не знаком с типичными конфигурациями VPC, но это ограничение на самом деле более точно объясняет, почему конфигурация, предложенная в исходном вопросе, не работает.

Вы настраиваете подсеть для использования экземпляра NAT, создавая маршрут в таблице маршрутов подсети для отправки определенного внешнего префикса (обычно 0.0.0.0/0, но это может быть подмножество) самому экземпляру или его эластичному сетевому интерфейсу, по ID.

Но в пределах региона, если вы попытаетесь направить трафик на ENI экземпляра в одноранговом VPC через таблицы маршрутизации, это не удастся:

Error: route table rtb-xxxxxxxx and interface eni-xxxxxxxx belong to different networks
(Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameterValue;
Request ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)

Таким образом, интуитивно понятный обходной путь также недоступен.

Я могу найти только три решения:

• Больше туннели, как и тот, который вы уже создали между VPC-1 и VPC-3. По сути, вам нужна полная сетка OpenVPN (или другого решения для туннелирования) между всеми VPC, которые должны обмениваться трафиком, кроме тех, с которыми вы пианились. Это решение, которое я реализовал. В каждой зоне доступности у меня есть сервер OpenVPN, у которого есть туннели ко всем другим зонам доступности в зарубежных регионах. Вам не обязательно понадобится по одному для каждой зоны доступности - только один для каждого VPC будет удовлетворять требованию, но туннели между каждой парой зон доступности обеспечат отказоустойчивость от изоляции всего VPC из-за потери одной зоны доступности.

• Источник NAT от туннельного сервера. Этот ужасно грязный. У вас есть туннель между VPC-1 и VPC-3, а VPC-3 связан с VPC-4, поэтому вы можете направлять трафик от VPC-1 на сервер туннеля в VPC-1 через таблицы маршрутов VPC в VPC- 1, а затем отправить его через туннель в VPC-3, где он мог бы принять исходный IP-адрес экземпляра туннеля в VPC-3 через iptables конфигурация. Все, что туннельная машина в VPC-3 может получить доступ в VPC-4, затем станет доступным для всего в VPC-1, которому разрешен доступ к туннельному серверу.

• Сервисный прокси или NAT-серверы в VPC-3, доступном из VPC-1, который либо выполняет пересылку TCP-соединений на уровне 4, либо NAT как источника, так и назначения трафика между адресами VPC-1 и адресами VPC-4, так что VPC-4 видит трафик как поступающий из адрес VPC-3, и VPC-1 видит, что трафик идет с адреса VPC-3. Это похоже на вышеприведенное, но обеспечивает лучший контроль доступа через группы безопасности, поскольку это не доступ по принципу «все или ничего», как того требует предыдущий вариант ... но все же беспорядочное решение.

Самая чистая конфигурация - это полная сеть туннелей между всеми вашими VPC (или всеми вашими зонами доступности, за исключением зон доступности в том же VPC или любых зон, с которыми осуществляется прямая связь).