Яку вихідну IP використовує шлюз NAT в AWS у напрямку до VPN?

Ви відкриваєте консоль VPC, бо партнер запитав, який діапазон джерела надійде через VPN «сайт-сайт». Сторінка шлюзів NAT показує публічний шлюз із приєднаним Elastic IP, і спокуса — надіслати цю адресу й рухатися далі. Це правильна відповідь для інтернет-шляху і неправильна для шляху через VPN, а різниця в тому, на який шлюз указує таблиця маршрутів. Пройдіть маршрут, перш ніж писати список дозволених адрес.

Почніть зі сторінки шлюзів NAT, а не зі списку дозволених адрес

Сторінка шлюзів NAT повідомляє підмережу, тип і Elastic IP, і цих трьох полів достатньо для початку. Чого вона не повідомляє — шляху, яким трафік іде далі. Це випливає з таблиць маршрутів, приєднаних до підмережі шлюзу NAT.

Спочатку прочитайте тип, бо публічний чи приватний визначає, чи з’явиться пізніше в ланцюжку інтернет-шлюз. Потім прочитайте підмережу, бо саме там міститься другий маршрут.

Простежте два перетворення

І публічні, і приватні шлюзи NAT перетворюють приватне джерело IPv4 робочого навантаження на власну приватну адресу IPv4 шлюзу NAT. Це перше перетворення відбувається незалежно від типу. Друге перетворення — те, про яке забувають: публічний шлюз NAT передає трафік інтернет-шлюзу, який зіставляє адресу з приєднаним Elastic IP.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

На приватному шляху в ланцюжку немає інтернет-шлюзу. Коли трафік виходить через транзитний шлюз або віртуальний приватний шлюз, посібник зі шлюзів NAT документує приватну адресу шлюзу NAT як джерело, яке отримує віддалена сторона. Саме цю адресу партнер має дозволити, а не Elastic IP.

Шлях через VPN зазвичай показує приватну адресу

Для робочого навантаження в 10.20.1.0/24, що досягає префікса партнера, таблиця маршрутів підмережі навантаження вказує на шлюз NAT, а таблиця маршрутів підмережі шлюзу NAT — на шлях приватного шлюзу. Обидва переходи важливі, і лише другий визначає, що бачить партнер. Якщо в підмережі NAT немає маршруту до шляху через VPN, пакет ніколи не надійде, і це інша несправність, ніж хибна адреса джерела.

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

Коли друге перетворення змінює відповідь

AWS також пропонує явне, відповідне зіставлення NAT «один до одного» на приєднанні транзитного шлюзу. Це зіставлення може ще раз перетворити джерело, перш ніж віддалений сервіс його побачить, і це не поведінка за замовчуванням, яка лише маршрутизує. Оскільки його треба налаштовувати навмисно, ставтеся до нього як до проєктного винятку, а не як до чогось, що ви отримуєте випадково. Якщо ніхто у вашій команді не пам’ятає, що його ввімкнув, вважайте, що його немає, доки не прочитаєте приєднання.

Якщо ваш проєкт його використовує, список дозволених адрес має описувати підсумкове зіставлення, а не адресу шлюзу NAT. Така сама обережність стосується шляхів доступності: коли бере участь кілька адрес шлюзів, очікуваний набір джерел — це об’єднання, а не одна представницька адреса. Запишіть, до якого перетворення належить кожна адреса, бо список без походження неможливо перевірити пізніше.

Приватному шлюзу NAT не можна дати інтернет-сервіс, спрямувавши його на інтернет-шлюз; AWS документує, що такий трафік відкидається. Виберіть тип за повним шляхом, а не за словом VPN у вимозі.

Напишіть контракт, за яким ваш партнер може діяти

Придатний контракт має чотири частини: напрямок, з якого ініціюються потоки, перетворена ідентичність, яку побачить партнер, зворотний маршрут для цієї ідентичності та застосовний обсяг захисту. Потоки шлюзу NAT ініціюються з підтримуваного боку джерела, тому це не служба перенаправлення вхідних портів для розкриття приватного навантаження. Сказати це вголос заздалегідь запобігає проєктному огляду, у якому кожна сторона вважала, що почала інша.

Перетворення купує полегшення від перекриття адрес і передбачувану політику джерел, а вам коштує індивідуальної ідентичності навантаження в журналах партнера. Якщо аудиту потрібне приписування за кожним навантаженням, тримайте цю ідентичність на рівні застосунку, а не намагайтеся відновити її з перетвореної адреси джерела.

Потім перевірте обидві таблиці маршрутів після будь-якої зміни, бо нове приєднання або повторно пов’язана підмережа тихо переписує відповідь.