Адреса конфиденциальности IPv6 или список разрешений RDP: выберите компромисс

Удалённый доступ к рабочему столу работал месяц, а затем список разрешений перестал совпадать без какой-либо видимой причины. Хост не перемещался, и в брандмауэре ничего не редактировалось. Windows продолжает формировать временные адреса IPv6 со случайными идентификаторами интерфейса и отзывать их, поэтому адрес источника, который сервер видит в любой день, может быть тем, который никто не вписал в правило. Отключение этого поведения исправляет совпадение и одновременно превращает хост в долгоживущий идентификатор. Взвесьте альтернативы, прежде чем принять вторую половину.

Почему правило перестало совпадать

RFC 4941 описывает временные адреса: хост создаёт дополнительные адреса со случайными идентификаторами и отзывает их, что не даёт наблюдателю связать один хост между посещениями. Windows реализует это поведение, поэтому вчерашний адрес источника не обязательно сегодняшний. Предсказуемый адрес по-прежнему существует на интерфейсе; просто это не тот, который предпочитает исходящее соединение.

Поэтому сбой выглядит прерывистым, а не полным. Правило совпадает некоторое время после создания адреса, перестаёт совпадать, когда адрес отозван, и снова начинает совпадать после того, как кто-то его отредактирует. Мониторинг, сгруппированный по адресу источника, и проверки лицензий, привязанные к адресу хоста, ломаются по тому же графику. Правило, которое работает сразу после редактирования и отказывает три недели спустя, обычно именно это, а не перезагрузка брандмауэра.

Вариант первый: один стабильный адрес, меньше конфиденциальности

Обычное исправление отключает оба механизма ротации на хосте: netsh interface ipv6 set privacy state=disabled store=persistent и netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Добавьте store=active, если хотите, чтобы изменение вступило в силу без ожидания перезагрузки, и примите, что теперь вы сделали идентификатор предсказуемым в разных сетях.

Именно этой предсказуемости и должны были помешать расширения. Адрес, который следует за хостом из кафе в офис и домой, — удобный ключ фильтрации и столь же удобный ключ отслеживания, и второе свойство переживает заявку, которая попросила первое.

Вариант второй: разрешить префикс или имя

Разрешение /64 вместо полного адреса сохраняет ротацию нетронутой и соответствует более слабому, но часто честному утверждению: эта машина в моей домашней сети. Это перестаёт быть достаточным в тот момент, когда в таком префиксе оказываются хосты, которых вы бы не допустили, а в потребительском подключении это обычно меньший набор, чем люди предполагают. Имя, опубликованное через динамический DNS, проще в эксплуатации, потому что запись следует за хостом, и политика читается как идентичность, а не как диапазон, который растёт с каждым добавленным устройством.

Обоим вариантам нужен резолвер, которому сервер может доверять, и имя, которое нельзя тривиально подделать, поэтому относитесь к ним как к политическому решению об идентичности, а не как к косметическому изменению правила. Запишите, какой резолвер отвечает за это имя, потому что правило надёжно ровно настолько, насколько надёжна запись за ним.

Вариант третий: пусть туннель назначит адрес

Если соединение идёт через VPN, который вы контролируете, сервер может выдавать адрес из своего пула, и список разрешений тогда ссылается на значение, которое выбирает сервер, а не на то, которое предпочитает клиент. Это хорошо работает для управляемых клиентов и плохо для всего, что клиент может обойти, поэтому проверьте, какая сторона действительно побеждает в вашем развёртывании.

Полный перенос решения с адреса, на сертификат клиента или аутентифицированный шлюз, — это вариант, который масштабируется, потому что он перестаёт зависеть от значения, которое операционная система вправе изменить.

Выбирайте с оглядкой на стоимость отслеживания

Запишите четыре варианта против реального требования и выберите один, а не комбинируйте их. Если вы всё же отключаете конфиденциальность, ограничьте её хостом, которому она нужна, задокументируйте причину рядом с правилом и рассмотрите стабильную приватную адресацию из RFC 7217 там, где платформа её поддерживает, поскольку она сохраняет идентификатор на префикс, не раскрывая полученный из оборудования. Снова включите расширения, когда список разрешений будет заменён.

Запишите изменение рядом с правилом, которое оно поддерживает. Без этой заметки следующий администратор обнаружит хост с отключёнными расширениями конфиденциальности и без объяснения и включит их обратно во время уборки.