Дві публічні IP на одній Azure VPN VM: яка за що відповідає

Дві публічні IP на одній Azure VPN VM створюють очікування, яке рідко справджується: адреса, до якої підключаються клієнти, буде й адресою, яку бачать сайти. Цей результат дають три незалежні рішення, і лише перше стосується слухача тунелю. Друге — це джерело в гостьовій системі для переспрямованого клієнтського трафіку, а третє — метод виходу Azure, застосовний до цього джерела. Змініть одне, і два інші залишаться на місці, тож вирішуйте кожне явно.

Рішення 1: де закінчується тунель

Публічна IP Azure пов'язана з конфігурацією приватної IP на NIC; це не адреса, яку ви додаєте всередині гостьової операційної системи. Читайте відповідність, а не припускайте її: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Яку б приватну адресу не повернув цей запит, саме її гість і повинен фактично мати.

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

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

Рішення 2: яке джерело використовує переспрямований клієнт

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

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

Рішення 3: який метод виходу Azure перемагає

Microsoft документуєпорядок пріоритету вихідного трафіку: застосовний маршрут до пристрою або шлюзу має пріоритет, а підключення підмережі через NAT Gateway має пріоритет над публічною IP рівня екземпляра на відповідному шляху. Саме через цей порядок трансляція в 10.20.0.5 не доводить, що сайт побачить 198.51.100.20. Читайте чинну таблицю маршрутів, зв'язок із NAT Gateway і публічну IP NIC разом, перш ніж прийняти проєкт виходу.

Тримайтепараметр переспрямування NIC в Azureокремо від переспрямування в Linux. Прапорець хмари дозволяє пакети, джерело або призначення яких не призначено NIC; він не вмикає net.ipv4.ip_forward, і налаштування гостя не дає дозволу хмари.

У сокета тунелю своє рішення про джерело

Address WireGuard під wg-quick призначає адресу інтерфейсу WireGuard; це не інструкція зовнішньої прив'язки UDP. Джерело зашифрованого сокета йде за таблицею маршрутів, тому політичний маршрут або другий маршрут за замовчуванням може перемістити його, не торкаючись адреси інтерфейсу.OpenVPN: опція local і UDP multihome поводяться так само: вони стосуються слухача та його відповідей, а не інтернет-джерела кожного переспрямованого клієнта.

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

Що приймати і в якому порядку

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

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