Настройка VPN между проектами GCP для доступа к подсети SQL Engine - PullRequest
0 голосов
/ 13 января 2020

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

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

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

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

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

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

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

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

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

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

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

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

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

Это VPN-туннель на проектах, в которых размещены базы данных: enter image description here

И это VPN-туннель в проекте, в котором будут развернуты продукты, для доступа к базам данных. enter image description here

Любая помощь очень ценится!

Ответы [ 3 ]

1 голос
/ 13 января 2020

Вы не можете достичь того, чего хотите, с помощью VPN или VP C Peering. Фактически в VP C существует правило, которое избегает транзитивности однорангового доступа , описанное в части ограничения

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

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

SQL Engine -> Пиринг -> Проект -> Пиринг -> Облако SQL

Вот так вы не можете.

Но вы можете использовать shared VP C. Создайте общий VP C, добавьте в него 2 проекта, создайте общий su bnet для SQL Engine и пиринга Cloud SQL. Это должно сработать.

Но будьте осторожны. Все функции VP C недоступны с общим VP C. Например, безсерверный VP C разъем еще не совместим с ним.

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

1 голос
/ 13 января 2020

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

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

Это должно поставить сеанс BGP в туннелях VPN статус в «BGP установлен».

0 голосов
/ 22 марта 2020

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

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

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

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

...