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

Одна схема AWS IPv4 такова:

private worker → public NAT gateway → internet gateway → proxy service → destination

У публичного NAT-шлюза есть связанный Elastic IP. Для трафика, отправляемого через интернет-шлюз VPC, AWS преобразует частный адрес NAT-шлюза в этот Elastic IP. Поэтому удалённый прокси может авторизовать этот публичный адрес выхода вместо частного адреса каждого воркера.

Направьте интернет-трафик нужных воркеров через запланированный шлюз и зарегистрируйте возможные публичные адреса выхода в прокси-сервисе. Если развёртывание использует несколько NAT-шлюзов или дополнительные адреса выхода, учитывайте каждый путь, по которому может пойти парк.

Источник, который принимает прокси, — это одно отношение адресов. Адрес выхода прокси, который видит назначение, — другое. Выдача аккаунту стабильного IP подключения не заставляет сервис использовать этот IP как выход.

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

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

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