Приватна IP-адреса Cloud SQL через VPN: маршрут, який ніхто не експортує

Багато команд вважають, що приватна IP-адреса Cloud SQL працює лише зсередини VPC, і це переконання тримається, бо збій виглядає як проблема бази даних. Google документує доступ із мереж, підключених через Cloud VPN або Cloud Interconnect. Цим мережам потрібен не особливий функціонал бази даних, а два обміни маршрутами, які легко залишити налаштованими наполовину. Тунель піднімається, обчислювальні інстанси відповідають, а з'єднання з базою йде в тайм-аут — саме та комбінація, що відправляє людей у неправильну консоль.

Міф: приватна IP означає приватна щодо VPC

Доступ до приватних сервісів — це VPC peering між вашою мережею та мережею виробника, що належить Google. Виділений для сервісу діапазон живе на боці виробника, і адреса інстансу знаходиться всередині нього. Саме через цей peering база даних у вашому проєкті може розташовуватися на адресі, до якої маршрутизує ваша VPC, хоча жодна ваша явна підмережа її не містить.

Оскільки це peering, він має й поведінку peering, включно з тією частиною, де користувацькі маршрути не переходять автоматично.

Міф: робочий тунель несе маршрут бази даних із собою

Два діапазони мають пережити подорож. Перший — клієнтський префікс: ваша локальна мережа повинна бути відома Cloud Router з конкретними префіксами, бо маршрут за замовчуванням не може дати імпорт, потрібний мережі виробника для зворотного шляху. Другий — виділений діапазон сервісу, який зовнішня сторона має вивчити, щоб її пакети до бази даних мали куди йти. Це різні маршрути, що підтримуються на різних межах, і виправлення одного залишає другий зламаним.

На боці Google це означає увімкнути Export custom routes на відповідних peering-з'єднаннях і додати виділений діапазон сервісу до анонсованих маршрутів Cloud Router для тунелю.

Зберігайте оголошення, які вже є. Додавання діапазону сервісу не повинно видаляти маршрути VPC, які той самий сеанс BGP несе для іншого трафіку, а набір оголошень, замінений цілком, — це другий збій, прихований за першим. Перевірте також чинні маршрути на зовнішньому пристрої, бо доступність VPN-шлюзу або іншої підмережі доводить лише транспорт.

Міф: Cloud SQL Auth Proxy вирішує проблему мережі

The Auth Proxy забезпечує підтримувану автентифікацію та зашифрований транспорт між вашим застосунком та інстансом. Він не створює маршрут. Проксі, запущений на хості без шляху до приватної мережі, зазнає невдачі так само, як зазнало б прямого з'єднання, а його журнали будуть менш корисними щодо причини. Перенесення проксі на хост, який має зв'язність, змінює те, яка ділянка шляху має працювати, і це справжнє проєктне рішення, а не обхідний маневр.

Чого він не робить — не дозволяє від'єднаному ноутбуку дістатися до інстансу, доступного лише приватно.

Міф: Private Service Connect підкоряється тим самим правилам

Private Service Connect використовує endpoint у вашій власній підмережі та схему DNS, яку контролюєте ви, тому маршрут до нього — звичайний маршрут до адреси, якою ви володієте. Налаштування експорту peering не застосовуються до цього дизайну, а копіювання peering-змін у розгортання PSC додає ризик, не додаючи доступності.

Обидва дають вам приватну адресу; схожість на цьому закінчується.

Перевіряйте шлях у правильному порядку

Із зовнішнього клієнта спершу перевірте TCP-ендпоінт бази даних. Завершене TCP-рукостискання означає, що маршрутизація, міжмережевий екран і слухач на місці, а наступний тест — дозволена автентифікована операція. Відмова в автентифікації в цей момент насправді добра новина, бо доводить, що слухач бази даних відповів. Тайм-аут ICMP майже нічого не каже про доступ до бази даних, бо багато шляхів його відкидають, спокійно передаючи TCP.

Якщо ваші клієнтські діапазони поза RFC 1918, перегляньте додаткові вимоги до експорту маршрутів і авторизації мережі, перш ніж дійти висновку, що дизайн не підтримується.

Запишіть чотири об'єкти разом із з'єднанням: зовнішній префікс, виділений діапазон сервісу, задіяні peering-з'єднання та маршрутизатор, що анонсує. Ці чотири пояснюють увесь приватний шлях і замінюють легенду про те, що Cloud SQL або завжди потребує проксі, або взагалі недосяжний через VPN.