Статичний IP в Azure P2S VPN: чому змінюється адреса клієнта

Кожен клієнт Azure point-to-site отримує адресу з пулу під час автентифікації й зберігає її лише стільки, скільки триває це підключення. Немає ні таблиці резервування, ні зіставлення за користувачем, ні налаштування шлюзу, яке означало б «завжди давай цій людині 172.16.0.10». Саме цей єдиний механізм пояснює обидва симптоми, з якими люди стикаються пізніше: правило NSG, яке перестає збігатися з користувачем, з яким збігалося раніше, і список дозволів, який тихо пропускає машину, яку ніхто навмисно не додавав. Заміна правила розумнішим правилом IP не виправляє ні того, ні того, бо те, що правило називає, перепризначається за розкладом, який ви не контролюєте.

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

Що шлюз насправді робить, коли клієнт підключається

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

Розмір пулу приховує поведінку. Лабораторний пул на одну-дві адреси більший за кількість тестувальників виглядає детермінованим, бо той самий ноутбук зазвичай підключається в одному й тому ж порядку щоранку. Додайте третю машину, змініть розмір пулу або залиште сеанс підключеним на обід — і закономірність ламається. Адреса ніколи не була стабільною; стабільною була черга.

Будь-яка зміна конфігурації point-to-site також скидає простір оренди. Інший тип автентифікації, змінений розмір пулу, новий діапазон пулу або шлюз, який знесли й збудували заново, повертають клієнтів у пул, що більше не відповідає їхнім старим адресам. Ніщо в цій зміні не зачіпає ваш NSG, тому поломка виглядає самовільною.

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

NSG, прив'язаний до IP клієнта, насправді є правилом про порядок підключень

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

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

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

Оренда клієнта й адреса шлюзу — різні об'єкти

Більшість плутанини походить від одного слова. Шлюз має публічний IP, який відносно стабільний; клієнти мають приватні адреси з пулу, які такими не є. Для шлюзу VPN без зональної надлишковості публічний IP виділяється динамічно, але він переживає зміну розміру, скидання й планове обслуговування — він змінюється, коли сам шлюз видаляють і створюють заново. Зонально надлишкові та зональні SKU шлюзу використовують публічний IP рівня Standard, і це виділення має бути статичним.

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

Групові пули дають діапазон, проти якого варто писати правила

Virtual WAN point-to-site підтримує групи користувачів, і кожній групі можна призначити власний пул адрес клієнтів. Членство визначається удостоверенням, тому діапазон, у який потрапляє клієнт, стає передбачуваним: операції в одному діапазоні, підрядники в іншому, а діапазон — це те, що правило брандмауера або NSG може назвати без здогадів.

Отриманий набір правил має форму, яку можна переглянути:

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

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

Коли розгортання не може перейти на Virtual WAN

Багато шлюзів залишаються звичайними шлюзами VPN, і перехід на Virtual WAN — не мимолітна зміна. Практична відповідь — перенести рішення щодо кожного користувача з фільтра пакетів на те, що вже знає, хто користувач.

Удостоверення на рівні ресурсу — найдешевший варіант. Storage, SQL і Key Vault підтримують автентифікацію Entra ID із призначеннями ролей за користувачем або за групою, тому VPN має лише довести мережеву доступність. Хост переходу з іменованими обліковими записами робить ту саму роботу для адміністративних завдань, бо хост фіксує людину, а тунель лише переносить пакети. Реєстрація клієнтів у DNS і дозвіл імені замість номера піднімає правило на рівень вище. Удостоверення на рівні застосунку — суб'єкт сертифіката, твердження токена, членство в групі — працює, коли вирішувати просять застосунок, а не мережу.

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

Перевірте пул, перш ніж редагувати черговий список дозволів

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

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

Потім замкніть цикл у такому порядку:

• Підключіться з двох машин в обох порядках і порівняйте адреси; якщо вони можуть помінятися, жодне правило на основі адреси не безпечне.
• Перевірте, чи шлюз є Virtual WAN; якщо так, використовуйте групові пули замість правил на кожну адресу.
• Запитайте, що станеться, якщо правило збіжиться не з тією людиною; якщо відповідь — інцидент доступу, перенесіть контроль на удостоверення.
• Запишіть, який діапазон належить якій групі, у тому самому сховищі, що й визначення NSG.
• Повторно перевірте після будь-якої зміни пулу, автентифікації або шлюзу, бо ці зміни переписують зіставлення, не оголошуючи про це.