Прокси акаунт с удостоверяване по 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 шлюз изпраща трафик през транзитен или виртуален частен шлюз вместо през интернет шлюза.

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

Подобни статии