Можно ли маршрутизировать исходящий трафик Google Cloud Functions через несколько меняющихся IP-адресов?

Question

Мое приложение использует облачную функцию (2-го поколения), запускающую несколько экземпляров и запускаемую PubSub, для отправки исходящих запросов на сайты клиентов (по сути, для синтетического мониторинга).

Однако платформа, на которой размещено несколько из этих сайтов, имеет защиту от ботов, и компания сказала мне, что у них нет возможности внести для нее IP-адреса в белый список, поэтому было бы лучше, если бы я чередовал IP-адреса (т. е. Функция выбирает/присваивает IP при создании).

Cloud NAT, по-видимому, является рекомендацией для настройки статических внешних IP-адресов, но добавление нескольких IP-адресов не будет циклически переключаться между ними, пока они не достигнут пределов TCP-соединений.

У балансировщиков нагрузки может быть способ сделать это, но, судя по тому, что я обнаружил, исходящий трафик по-прежнему маршрутизируется через Cloud NAT и использует назначенный там IP-адрес.

Есть ли другой способ отправлять запросы к облачным функциям с разных IP-адресов?

Answer 1

• Создание бессерверного соединителя VPC
• Создайте шлюз Cloud NAT и включите в него подсеть , назначенную для бессерверного соединителя VPC.
• Настройте свою облачную функцию для использования бессерверного соединителя VPC для всего исходящего трафика .

Теперь эта конкретная облачная функция, использующая этот конкретный коннектор VPC, будет маршрутизировать исходящий трафик через этот конкретный облачный шлюз NAT.

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

• myCloudFunction1 — использует бессерверный соединитель VPC 1 и шлюз Cloud NAT 1.
• myCloudFunction2 — использует разъем 2 и шлюз 2.
• myCloudFunction3 — использует разъем 3 и шлюз 3.

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

• myCloudFunction — ваша исходная функция, но вместо подключения к конечному пункту назначения вы циклически подключаетесь к одной из трех облачных функций в качестве прокси-сервера.
• myProxyFunction1 — простой HTTP-прокси, который просто пересылает запрос, та же конфигурация, что и myCloudFunction1 выше .
• myProxyFunction2 — та же конфигурация, что и myCloudFunction2.
• myProxyFunction3 — та же конфигурация, что и myCloudFunction3.