Cloud Run до локального VPN: налаштування прямого виходу VPC

Тунель Cloud VPN не розміщує Cloud Run у мережі. Підключіть сервіс до потрібної підмережі, маршрутизуйте його діапазон джерел, потім перевірте цю ревізію.

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

Підключіть ревізію до налагодження тунелю

Cloud Run підтримує прямий вихід VPC, який розміщує трафік сервісу в підмережі вашої VPC без конектора Serverless VPC Access. Для наявного сервісу оновлення виглядає так:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Замініть заповнювачі, перегляньте, що розгортання робить із живим трафіком, і виберіть підмережу в регіоні сервісу з достатньою ємністю адрес і правильними мережевими дозволами.

Виберіть режим виходу, що відповідає призначенню

private-ranges-only надсилає призначення, які класифікує як приватні, через VPC. Це не означає «все, що доступне через VPN», і ця прогалина з'являється, коли локальний сервіс перебуває в діапазоні, який налаштування так не класифікує. Якщо призначення не покрито, all-traffic — інший документований режим, і він надсилає все через VPC, включно з публічними залежностями сервісу. Вибирайте свідомо і запишіть наслідок у журнал змін.

Сервіс, який уже використовує конектор, потребує міграції, а не перемикача, тому плануйте її, а не налаштовуйте обидва варіанти.

Маршрутизуйте джерело Cloud Run, а не джерело віртуальної машини

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

За динамічної маршрутизації перевірте, що Cloud Router насправді оголошує і що імпортує VPC, включно з будь-якою налаштованою політикою оголошень. Маршрут, який існує в консолі, але не вибраний для цього призначення, рівнозначний відсутності маршруту.

Три умови, які мають виконуватися всі

Робочий шлях потребує всього переліченого, і кожна умова відмовляє по-своєму:

  • Маршрут у VPC до локального префікса через передбачене підключення Cloud VPN.
  • Зворотний маршрут на локальній стороні для підмережі Cloud Run.
  • Область захисту міжмережевого екрана та IPsec, що дозволяє джерело, призначення і порт.

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

Не додавайте одну тимчасову адресу Cloud Run до списку дозволених. Використовуйте діапазон підмережі та схему авторизації, що підходить застосунку.

Перевірте ревізію, що обслужила запит

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

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

Відкат і чого це не робить

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

Ця схема охоплює з'єднання, які ініціює Cloud Run, та їхні відповіді. Вона не дає локальній мережі адресований сокет усередині сервісу, бо зовнішній вплив усередину — це рішення ingress.

Схожі статті