Статический IP для доступа к API машинного обучения GCP через поток gRPC через HTTP / 2

Question

Мы живем за корпоративным прокси / брандмауэром, который может использовать только статические правила IP, а не FQDN. Для нашего проекта нам нужно получить доступ к Google Speech To Text API: https://speech.googleapis.com. Если это происходит за пределами корпоративной сети, мы используем для этого поток gRPC через HTTP / 2.

Идеальный сценарий выглядит следующим образом:
Corporate network -> static IP in GCP -> forwarded gRPC stream to speech.googleapis.com

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

В качестве альтернативы мы думали использовать вывод nslookup speech.googleapis.com диапазонов IP-адресов и обновлять его ежедневно, хотя это выглядит довольно «грязно».

Я знаю, что мы можем настроить вычислительный движокресурс / VM и перенаправить трафик, но это действительно не кажется элегантным решением. Предпочтительно, мы можем достичь этого с помощью существующих сетевых компонентов GCP.

Большое спасибо за любые указатели!

Answer 1

Нашли решение благодаря умным сетевым инженерам из Google, разместившим здесь для дальнейшего использования:

Вы можете использовать CNAME во внутреннем DNS, чтобы указать * .googleapis.com на private.googleapis.com. Эта запись в общедоступном DNS указывает на два общедоступных IP-адреса (199.36.153.8/30), которые недоступны из общедоступного Интернета, но только через VPN-туннель или облачное соединение.

Так что, если настройка VPN-туннеля для проекта в GCP возможна (и это должно быть довольно просто, см. https://cloud.google.com/vpn/docs/how-to/creating-static-vpns),, тогда это должно решить проблему.

Answer 2

Google не публикует блок CIDR для использования. Вы будете ежедневно испытывать горе, пытаясь внести в белый список IP-адреса. Большинство API-сервисов Google обслуживаются Global Frontend (GFE). Для маршрутизации трафика используются заголовки узлов HTTP, а не IP-адреса, что приведет к сбою маршрутизации.

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

Решение. Поговорите с поставщиком брандмауэра.