Проксі-акаунт з автентифікацією за 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-шлюз надсилає трафік через транзитний або віртуальний приватний шлюз замість інтернет-шлюзу.

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

Схожі статті