Google Cloud, GC Site-to-Site VPN, OpenVPN, разные подсети: лучший способ подключить A к B?

Извините, название не очень...

У меня есть подсеть Google Cloud (GC) VPC 10.1.1.0/24 в регионе A, в которой есть сервер доступа OpenVPN по адресу 10.1.1.2. Сервер доступа OpenVpn обеспечивает удаленный доступ для клиентов за пределами облака. Клиентам выделяется IP из подсети 192.168.3.0/24, а методом маршрутизации может быть либо NAT, либо маршрутизация (настройки Open VPN Access Server).

У меня есть VPN-шлюз GC (классический) в регионе B и еще один VPN-шлюз GC (классический) в регионе C.

Туннели от удаленных сайтов к VPN-шлюзам GC «диктуются» удаленным сайтом, т. е. метод маршрутизации основан на политике, и удаленный сайт решает, какой должна быть облачная (локальная) подсеть. Так:

Политика для туннеля от удаленного сайта B к VPN-шлюзу B GC: 10.2.2.0/24 (удаленный) <-> 172.18.22.0/24.

Политика туннеля от удаленной стороны C до VPN-шлюза C GC: 10.3.3.0/24 (удаленный) <-> 172.18.23.0/24.

Следовательно, чтобы трафик направлялся на удаленный сайт B/сайт C, необходимо, чтобы у него был источник внутри 172.18.22.0/24/172.18.23.0/24 соответственно.

Итак, вопрос в том, как удаленному клиенту лучше всего получить доступ к удаленным сетям B и C? Я рассматривал возможность внедрения экземпляров в подсетях B и C, на которых работают клиенты OpenVPN, которые могли бы обеспечить доступ к удаленным сетям через NAT... но мне также нужно, чтобы удаленная сеть могла достичь подсети A. Я рассмотрел возможность размещения A. , B и C в разных VPC, чтобы сервер доступа OpenVPN мог иметь сетевые интерфейсы для каждого VPC и маршрутизировать трафик с помощью NAT. Это имеет некоторые проблемы с масштабированием... количество экземпляров ограничено 8 интерфейсами. Кроме того, мне понадобится 1 GC VPN GW на каждую подсеть/туннель. Я уверен, что есть и другие вопросы, которые я не учел. Все это, если честно, какой-то бардак. К сожалению, я не могу запросить другой метод маршрутизации с удаленных сайтов (B и C), а также не могу запросить определенные подсети для облачной части туннеля на основе политики.

Любая помощь будет принята с благодарностью!

1 ответ

Описываемая проблема не дает ясности относительно типа предпринимаемой попытки подключения или требуемых источников, пунктов назначения и направлений трафика, что заставляет меня предполагать следующие сценарии:

Сценарий 1 :
(i) Упомянутые подсети GCP находятся в одном VPC, и предпринимаются попытки подключения от удаленных клиентов и удаленных сайтов.
(ii) Удаленные клиенты, подключающиеся к подсети A через соединение OpenVPN.
(iii) Удаленные сайты B и C, подключающиеся к подсетям B и C соответственно.
(iv) Удаленные клиенты пытаются подключиться к подсетям B и C.

В этом случае вам необходимо убедиться, что правило брандмауэра, разрешающее трафик внутри сети, присутствует со следующей конфигурацией:

Направление — входное
действие при совпадении — Разрешить
диапазоны IP — [диапазон IP вашего GCP VPC]
Протокол и порты — tcp:0-65535Udp:0-65535
Приоритет Icmp — 65534
Принудительное применение — включено

Это правило брандмауэра обеспечит поток трафика между вашими подсетями внутри вашего VPC, независимо от регионов, что облегчит вам настройку, при которой ваши удаленные клиенты могут достигать подсети B или подсети C через подсеть A, а ваш удаленный локальный сайт может достигать подсети A. через подсеть B или подсеть C.

Сценарий 2:
(i) Упомянутые подсети GCP находятся в одних и тех же разных VPC и попытках подключения от удаленных клиентов и удаленных сайтов.
(ii) Удаленные клиенты, подключающиеся к подсети A через соединение OpenVPN.
(iii) Удаленные сайты B и C, подключающиеся к подсетям B и C соответственно.
(iv) Удаленные клиенты пытаются подключиться к подсетям B и C.

В этом случае сначала вам необходимо подключить ваши VPC с помощью любой из следующих служб GCP:

Пиринг VPC. Пиринг сетей VPC позволяет подключать сети VPC, чтобы рабочие нагрузки в разных сетях VPC могли обмениваться данными внутри. Инструкции по созданию пиринга VPC см. здесь: https://cloud.google.com/vpc/docs/using-vpc-peering .

Облачный VPN. Хотя в основном он используется для подключения локальных сетей к GCP VPC, облачный VPN также может использоваться для соединения различных GCP VPC друг с другом. Инструкции по установке VPN-подключений между GCP VPC см. здесь: https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn2 .

При подключении VPC ваши удаленные клиенты могут подключаться к подсети B или подсети C через подсеть A, а ваш удаленный локальный сайт может подключаться к подсети A через подсеть B или подсеть C.

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

Другие вопросы по тегам