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.

Похожие статьи