Настройка VPN между проектами GCP для доступа к подсети SQL Engine

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

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

Все хорошо, удалось все настроить.

Теперь один из проектов посвящен «хранилищу»: для нас это означает базы данных, корзины для статистических данных, к которым можно получить доступ, и т. Д.

Я создал первую базу данных mySQL (2-го поколения), чтобы начать тестирование, и заметил, что единственный доступный вариант для доступа к базам данных SQL с внутренних IP-адресов - это подсеть «родительский проект».

Я понял, что SQL Engine создает подсеть, предназначенную именно для этого. Это тоже написано в документации, глупый я. Нет проблем, я снимаю его, включаю Private Service Connection, создаю выделенный диапазон IP-адресов в управлении VPC и настраиваю его для экспорта маршрутов.

Затем я вернулся к SQL Engine и создал новую базу данных. Как и ожидалось, у нового IP-адреса был назначен ранее назначенный диапазон IP-адресов.

Теперь я ожидал, что каждая одноранговая сеть также сможет видеть подсеть SQL, но, очевидно, нет. Опять RDFM ты глупый гусь. Там тоже было написано.

Я активировал бронзовую подписку на поддержку с помощью GCP, чтобы получить некоторые рекомендации, но я получил повторное «создание туннеля vpn между двумя проектами», что немного разочаровало меня, так как концепция Peered VPC настолько хороша.

Но в любом случае, давайте тогда сделаем это.

Я создал туннель, указывающий на шлюз в проекте, в котором будут кластеры K8s, и наоборот. Панель управления сообщает мне, что туннель установлен, но, по-видимому, есть проблема с настройками bgp, потому что они навсегда зависли на "Ожидании однорангового узла" с обеих сторон.

На данный момент я ищу все, что связано с BGP, но все, что я могу найти, это то, как он работает теоретически, для чего он используется, какие номера ASM зарезервированы и т. Д. И т. Д.

Мне действительно нужно, чтобы кто-то указал на очевидное и сказал мне, что я здесь напортачил, так что:

Это VPN-туннель в проектах, в которых размещены базы данных:  введите описание изображения здесь

И это VPN-туннель в проекте, где будут развертываться продукты, которым необходим доступ к базам данных. введите здесь описание изображения

Любая помощь приветствуется!


person Claudio    schedule 13.01.2020    source источник
comment
Какой архитектуры вы хотите достичь? ресурс A - ›VPN -› проект B - ›Частный IP Cloud SQL? Вы хотите, чтобы ресурс A достиг Cloud SQL, размещенного в проекте B. Я прав?   -  person guillaume blaquiere    schedule 13.01.2020
comment
да, @guillaumeblaquiere. Мы пытаемся сделать частный IP-адрес SQL доступным в ресурсе A. SQL Engine находится на ресурсе B.   -  person Claudio    schedule 13.01.2020


Ответы (3)


Вы не можете достичь того, чего хотите, с помощью VPN или пиринга VPC. На самом деле в VPC есть правило, исключающее транзитивность пиринга , описанное в части ограничения < / а>

Только одноранговые сети могут взаимодействовать. Транзитивный пиринг не поддерживается. Другими словами, если сеть VPC N1 является одноранговой с N2 и N3, но N2 и N3 не подключены напрямую, сеть VPC N2 не может взаимодействовать с сетью VPC N3 через пиринг сети VPC.

Теперь возьмите то, чего хотите достичь. Когда вы используете частный IP-адрес Cloud SQL, вы создаете пиринг между вашим VPC и VPC Cloud SQL. И у вас есть еще один пиринг (или VPN-туннель) для механизма SQL.

SQL Engine -> Пиринг -> Проект -> Пиринг -> Cloud SQL

Так не получится.

Но вы можете использовать общий VPC. Создайте общий VPC, добавьте в него 2 ваших проекта, создайте общую подсеть для SQL Engine и пиринга Cloud SQL. Это должно сработать.

Но будь осторожен. Все функции VPC недоступны при использовании общего VPC. Например, бессерверный соединитель VPC еще не совместим с Это.

Надеюсь на эту помощь!

person guillaume blaquiere    schedule 13.01.2020
comment
Спасибо, Гийом, это кажется наиболее оптимизированным решением. Я принял ответ @marcelp, так как он более уместен для моего вопроса, но я буду иметь в виду вариант Shared VPN и поэкспериментировать с ним! - person Claudio; 14.01.2020
comment
Нет проблем, я ответил на вашу глобальную цель. Я тоже не сетевой администратор и не люблю проблемы с сетью! И я хотел, чтобы вы не тратили слишком много времени на бесполезные решения! - person guillaume blaquiere; 14.01.2020
comment
Несмотря на то, что я обратился в службу поддержки Google (100 фунтов стерлингов в месяц) и последовал их предложению о создании VPN (отсюда и этот вопрос), по-видимому, вы были правы, поскольку туннель VPN в любом случае не позволяет мне получить доступ к подсети SQL Engine. Вот вам и платная поддержка. Я собираюсь изучить предложенное вами решение Shared VPC. - person Claudio; 14.01.2020

Что касается статуса BGP «Ожидание однорангового узла» в вашем VPN-туннеле, я считаю, что это связано с настроенным IP-адресом BGP облачного маршрутизатора и IP-адресом однорангового узла BGP. При настройке IP-адрес BGP облачного маршрутизатора для tunnel1 будет IP-адресом BGP Peer для tunnel2, а IP-адрес BGP Peer для tunnel1 будет IP-адресом BGP Router для tunnel2.

Что касается вашего сценария, IP-адрес для stage-tunnel-to-cerberus должен быть: IP-адрес маршрутизатора BGP: 169.254.1.2 и IP-адрес узла BGP: 169.254.1.1

Это должно перевести ваш статус сеанса BGP туннелей VPN в «BGP установлен».

person Marcel P    schedule 13.01.2020
comment
Большое спасибо. Это была ошибка. На cerberus ip 169.254.0.1/169.254.0.1 уже использовался другим туннелем с локальной сетью и не мог видеть конфигурацию в локальной сети, я думал, что адрес BGP был только чем-то для внутренней маршрутизации запросы. Как я уже сказал, это не сетевой опыт (но я в первую очередь беру книги). Спасибо еще раз! - person Claudio; 14.01.2020

Исходная настройка в вопросе OP должна работать, т.е.

Network 1 <--- (VPN) ---> Network 2 <--- (Peered) ---> CloudSQL network

(network и пиринг создается GCP)

Тогда ресурс в Network 1 сможет получить доступ к MySQL экземпляру, созданному в CloudSQLz сети.

person KenLy.LDK    schedule 22.03.2020