Google API через VPN: маршрутизируйте VIP, а не только подсеть

Подключитесь по SSH к локальному серверу, поднимите туннель, и частная ВМ отвечает; затем первый вызов Google API завершается неудачей из-за отсутствия маршрута. Подсеть ВМ и VIP-адреса API — разные назначения, поэтому маршрут к одному не выбирает другое. Три условия должны выполняться, чтобы частный вызов API заработал. Имя API должно разрешаться в VIP, префикс VIP должен анонсироваться через туннель, а VPC должен знать, как отправить ответ обратно. Ping ничего из этого не сообщает, и рабочая SSH-сессия к машине в подсети тоже.

VIP-адреса API — отдельные назначения

Google публикует выделенные VIP-адреса для доступа к API из локальной сети, и именно эти адреса ваш DNS должен возвращать для имён API. Оба — небольшие префиксы, и ни один не относится к пространству RFC 1918:

Адреса, выглядящие публичными, не означают, что маршрут должен покинуть туннель для обычного интернета. Префиксы существуют, чтобы локальный клиент достигал фронтендов Google по поддерживаемому пути, а не через произвольную точку выхода. Относитесь к ним как к назначениям, принадлежащим туннелю, а не как к хостам для проверки. Правило межсетевого экрана, написанное для выхода в интернет, обычно их отбрасывает, и это частая причина, почему вызов не удаётся ещё до начала.

DNS решает, какой конечный пункт вы достигнете

Направьте локальный резолвер на записи, которые Google документирует для выбранного конечного пункта, чтобы имена, нужные приложению, отвечали этим VIP. Простое googleapis.com не является инвентарём: у реестров пакетов, реестров контейнеров и коннекторов миграции есть свои документированные имена. Ограниченный VIP тоже несёт не каждый сервис, поэтому имя, которое разрешается, может оставаться неподдерживаемым. Запишите домены, с которыми приложение действительно связывается, прежде чем трогать резолвер.

Угадывание адреса ВМ в VPC вместо имени сервиса — не исправление, и обычно оно скрывает пробел в DNS, пока не упадёт другой клиент.

Анонсируйте префикс VIP, сохраните остальное

При подключении на основе BGP Cloud Router должен анонсировать выбранный префикс VIP, чтобы локальный маршрутизатор изучил этот диапазон через нужную сессию. Анонс только подсетей VPC не добавляет этот диапазон, и локальный маршрутизатор продолжает использовать свой путь по умолчанию для этих адресов. Префикс в таблице маршрутизации — единственное доказательство того, что анонс прошёл через сессию.

Сохраняйте существующие анонсы, пока добавляете новый, потому что параметры на уровне маршрутизатора и на уровне пира имеют разный охват, и замена набора может отозвать сети, которые уже работали. Затем проверяйте действующий анонс в каждой сессии, а не на маршрутизаторе целиком. Отсутствующий префикс и отозванный префикс выглядят с локальной стороны одинаково, поэтому именно вид сессии отделяет пропуск от регрессии.

Стороне VPC нужен собственный маршрут и обратный путь

Внутри VPC путь к VIP должен использовать шлюз интернета по умолчанию как следующий шаг, и, несмотря на название, этот трафик остаётся в сети Google. VPC также нужен маршрут обратно к локальному источнику через VPN, и это отдельный объект от анонсированного префикса. Учитывайте документированные региональные требования к маршрутизации, когда туннель и клиент находятся не в одном регионе.

Проверяйте обратный путь независимо, потому что работающее направление запроса может скрыть сломанное направление ответа. Два направления, два маршрута, и каждый отказывает со своим симптомом.

Проверьте запрос, затем прочитайте отказ

ICMP-эхо не получает ответа от этих VIP, поэтому неудачный ping ничего не доказывает, а удачный — очень мало. С реального клиента проверьте ответ имени и выбранный маршрут, затем отправьте авторизованный HTTPS-запрос к нужному сервису. Если запрос доходит до сервиса и отклоняется, посмотрите на учётные данные, IAM и любую применимую политику периметра сервиса.

Частная маршрутизация не даёт авторизации API и не меняет того, что разрешено идентичности. Успех транспорта и авторизованный ответ — отдельные результаты, и нужны оба. Держите также путь IPv6 явным, потому что настройка префиксов IPv4 ничего не говорит о клиенте, предпочитающем IPv6.

Руководство Google по Private Google Access из локальной сети охватывает записи DNS и требования к маршрутизации вместе, поэтому сравнивайте настройки резолвера и анонса с ним, а не с сообщением на форуме. Затем повторите тот же запрос и запишите ответ и маршрут в том же тикете.