App Engine може дістатися до вашої бази даних VPN: що має збігтися

Твердження, що App Engine Standard не може дістатися приватної бази даних через Cloud VPN, — це залишок попереднього покоління платформи. Екземпляри Standard не отримують VPC-адреси, як деякі інші середовища виконання, але можуть надсилати egress через конектор Serverless VPC Access, розташований у вашій мережі. Щойно цей шлях існує, Cloud VPN і віддалений міжмережевий екран бачать трафік конектора як будь-яке інше джерело. Відмовляє рідко сама можливість. Це одне з трьох налаштувань, які так і не узгодили.

Звідки взялася стара відповідь

До появи конекторів практична відповідь справді була такою: Standard може спілкуватися лише з публічними кінцевими точками, і команди переходили на проксі-VM або інше середовище виконання, щоб це обійти. Платформа змінилася, фольклор ні. Багато порад в інтернеті досі відображають епоху, коли варіанта egress не було взагалі.

Виправлення вужче, ніж здається. Standard може дістатися приватної мережі, але лише через підтримувану інтеграцію egress і лише до тих призначень, які ця інтеграція справді перехоплює.

Спершу виберіть шлях egress

Саме конектор, прикріплений до сервісу, поміщає його трафік у VPC. Документація конектора перелічує регіональну вимогу й налаштування egress; конектор має існувати в регіоні сервісу й бути доступним для ідентичності, що виконує розгортання.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only надсилає приватні призначення в VPC, а все інше залишає на звичайному інтернет-шляху, що зазвичай і потрібно підключенню до бази даних. all-traffic широко проштовхує вихідний трафік через VPC, тож звичайні інтернет-виклики теж успадковують положення NAT і міжмережевого екрана VPC.

Локальне редагування файлу нічого не змінює до розгортання. Працююча версія зберігає конфігурацію, з якою її створили.

Адреса джерела — це конектор, а не ваш ноутбук

Тут минає більша частина часу налагодження. Віддалений шлюз VPN і міжмережевий екран бази даних мають допустити виділений конектору діапазон усередині VPC, а не адресу вашого офісу й не публічну адресу egress сервісу. Знайдіть цей діапазон у консолі, перш ніж написати хоч одне правило.

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

Тунель, який допускає лише підмережу VM, відкидатиме пакети конектора без корисної помилки, тому тайм-аут бази даних виглядає як проблема з обліковими даними.

DNS іде іншим шляхом

Ім'я хоста приватної бази даних має розв'язуватися в мережі, до якої доходить конектор, через піринг Cloud DNS або зону пересилання, доступну VPC. Розв'язання на вашій робочій станції нічого не доводить про розгорнутий сервіс, бо ваш ноутбук не використовує той резолвер.

Якщо ім'я зсередини VPC розв'язується в публічну адресу, ви збираєтеся налагоджувати не той міжмережевий екран.

URL Fetch не використовує конектор

Налаштування egress охоплює звичайні вихідні сокети середовища виконання, а застарілий сервіс URL Fetch не входить до цього шляху. Запит, виданий через urlfetch, ігнорує конектор, хоч би що казала конфігурація. Коли збійний виклик міститься в старішій бібліотеці, яка досі використовує URL Fetch, виправлення — перенести цей виклик на стандартний HTTP-клієнт.

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

Перевірте одним вузьким запитом

Розгорніть, потім виконайте одну дозволену операцію з базою даних із розгорнутої версії, спостерігаючи за віддаленим боком. Адреса джерела, яку фіксують база даних або шлюз VPN, має належати конектору. Якщо ні, запит так і не увійшов у VPC, і жодне налаштування тунелю це не виправить. Порівняйте її з діапазоном, який ви знайшли в консолі; розбіжність зазвичай означає, що версію обслуговує другий конектор.

Успішний запит із VM усередині VPC доводить, що маршрут існує. Він не доводить, що сервіс вибрав саме його.