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 доказывает, что маршрут существует. Он не доказывает, что сервис выбрал именно его.