Elastic IP в EC2 — не приватна VPN-адреса інстансу

Інстанс має приватну адресу, Elastic IP пов'язаний з нею, і маршрут для цього публічного /32 додається до VPN у надії, що ці два стануть одним і тим самим. Не стають. Elastic IP — це трансляція, яка виконується поза гостем, інтернет-шлюзом, над трафіком, що йде інтернет-шляхом. Операційна система гостя ніколи не бачить цю адресу налаштованою на інтерфейсі. Додавання її на тунельний інтерфейс не відтворює трансляцію вище й створює другу, суперечливу ідентичність для тієї самої машини.

Дві адреси, один інстанс

Мережевий інтерфейс інстансу тримає приватну адресу всередині VPC, і це та адреса, яку знає гість. Elastic IP пов'язаний з тим самим інтерфейсом, але живе на публічному боці відображення.

Усе, що досягає інстансу через інтернет, приходить трансльованим на приватну адресу. Усе, що інстанс надсилає в інтернет, виходить з Elastic IP як джерелом, знову через цю трансляцію.

Усередині гостя існує одна адреса. Ззовні — дві. Ця асиметрія пояснює більшість плутанини в цій галузі. Гість не може налаштувати те, що транслює шлюз. Він може відповідати лише на тій адресі, яку справді має.

Що насправді робить інтернет-шлюз

Документація AWS про інтернет-шлюз описує схему: інстанс знає свою приватну адресу IPv4, а шлюз забезпечує відповідну трансляцію в публічний IPv4 або Elastic IP для трафіку на інтернет-шляху.

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

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

Чому трюк із тунельним інтерфейсом не працює

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

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

Адреса ніколи не була проблемою. Проблемою був вибір шляху.

Три цілі, три схеми

Якщо мета — публічна кінцева точка VPN, Elastic IP є правильним інструментом: віддалені партнери підключаються до неї через інтернет, а шифрований транспорт завершується на інстансі. Внутрішній трафік застосунку потім використовує приватну адресу.

Якщо мета — приватний доступ до застосунку, призначенням є приватна адреса або приватне DNS-ім'я, яке на неї розв'язується, і маршрут VPN, група безпеки та зворотний шлях мають усі збігатися. Elastic IP у такій схемі взагалі не фігурує.

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

Перевірте обраний шлях

Для приватного доступу переконайтеся, що маршрут VPN покриває приватний префікс, таблиця маршрутів VPC повертає трафік у тунель, група безпеки дозволяє джерело клієнта, а власний брандмауер клієнта дозволяє відповідь. Потім перевірте один реальний запит замість ping.

Для публічного доступу переконайтеся в інтернет-виході клієнта, маршрутизації публічного входу та його політиці безпеки. Чи може клієнт VPN досягти публічної кінцевої точки через тунель, залежить від правил виходу й брандмауера тунелю, а не від зв'язку Elastic IP.

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