Статический 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.
• Повторно проверьте после любого изменения пула, аутентификации или шлюза, потому что эти изменения переписывают сопоставление, не объявляя об этом.