Чому Azure Point-to-Site VPN не змінює вашу публічну IP-адресу

Я підключаю клієнт Azure VPN на ноутбуці з Windows, відкриваю сторінку відлуння адреси й бачу ту саму публічну адресу, яку видав мій домашній маршрутизатор. Тим часом машина переходу на 10.20.0.4 відповідає, а ім'я приватної кінцевої точки розв'язується, отже тунель не зламаний. Шлюз «точка — сайт» робить саме те, що каже його конфігурація за замовчуванням: передає приватні префікси, а все інше лишає на локальному каналі. Отримання вихідної адреси, що належить Azure, — це зміна схеми маршрутизації, а не ремонт.

Що шлюз оголошує за замовчуванням

Шлюз передає маршрути для адресного простору віртуальної мережі, а також для пірингових мереж, де дозволено транзит через шлюз, і локальних префіксів, вивчених через з'єднання «сайт — сайт» або BGP. У цьому наборі немає 0.0.0.0/0. Ваша операційна система тримає маршрут за замовчуванням на Wi-Fi або Ethernet, тому пакет до публічного API взагалі не потрапляє в тунель.

Адреса, яку клієнт отримує всередині тунелю, — це приватна оренда з пулу «точка — сайт». Вона ідентифікує клієнта для ресурсів у VNet; це не адреса, яку може побачити інтернет, і вона ніколи не з'явиться як джерело вихідного запиту до API SaaS. Запис у списку дозволених, побудований навколо цієї оренди, не може працювати, скільки б ви не чекали її появи в журналах постачальника.

Розділений тунель і примусове тунелювання поряд

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

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

Змусьте тунель нести маршрут за замовчуванням

На шлюзі віртуальної мережі підтримуваний спосіб спрямувати весь інтернет-трафік клієнта в тунель — додати власні маршрути до конфігурації «точка — сайт». Дві половини покривають весь простір IPv4, і кожна є конкретнішою за локальний маршрут за замовчуванням, тож клієнт віддає їм перевагу, нічого не видаляючи:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Цей рядок ілюстративний, а не готовий для копіювання: спершу отримайте об'єкт шлюзу за допомогою Get-AzVirtualNetworkGateway і підставте його замість GWOBJ, а перед запуском переконайтеся, що SKU та модель розгортання приймають власні маршрути. Ті самі префікси є на порталі на сторінці конфігурації «точка — сайт», і це безпечніше місце, щоб їх задати, якщо ви ще не керуєте шлюзом скриптом.

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

У захищеному центрі віртуальної WAN еквівалент — маршрут за замовчуванням у таблиці маршрутів центру, пов'язаній зі шлюзом «точка — сайт», а трафік приймає Azure Firewall у центрі. Брандмауер перекладає з'єднання в бік інтернету у власні публічні IP-адреси, і саме з цього перекладу походить нова вихідна адреса. Коли брандмауер має кілька публічних IP, будь-яка з них може з'явитися як джерело, тому список дозволених має містити всі.

Обидві схеми вище — IPv4. Два префікси /1 нічого не роблять для IPv6, а підтримка IPv6 у «точка — сайт» настільки вузька, що комбінацію варто перевірити, перш ніж обіцяти паритет.

Перевірте маршрут, потім вихід

Після перевстановлення пакета й повторного підключення переконайтеся, що клієнт справді встановив половини. У Windows Get-NetRoute -DestinationPrefix 0.0.0.0/1 і такий самий запит для 128.0.0.0/1 мають назвати інтерфейс тунелю, а route print показує обидва поруч із вашим початковим маршрутом за замовчуванням. У Linux ip route show має перелічити два префікси; якщо ні, профіль їх так і не переніс.

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

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

Коли лишити розділений тунель у спокої

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

Вдавайтеся до нього, коли вимога сформульована в термінах виходу: партнер має бачити фіксовану адресу Azure, безпека хоче, щоб з'єднання журналювалися й перевірялися, або дані мають виходити через одну контрольовану точку. Навіть тоді схема дає кожному користувачеві спільний вихід, тож відповідальність за користувача має йти від ідентичності в застосунку, а не від адреси джерела.

Перш ніж закрити зміну, підтвердьте чотири речі: встановлений пакет клієнта — новий, два маршрути /1 стоять на інтерфейсі тунелю, приватний пункт призначення ще відповідає, і журнал віддаленої служби показує адресу брандмауера.