Добавление правила разрешения для RDP не сужает доступ через VPN

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

Правило, которое вы добавляете, — не то правило, которое имеет значение

Windows Firewall оценивает все применимые правила входящих подключений в хранилищах политик, действующих для компьютера, а затем решает, совпадает ли какое-либо разрешение и перекрывает ли его какая-либо блокировка. Добавление правила добавляет разрешение; оно не удаляет и не уточняет уже существующие разрешения.

Поэтому вопрос никогда не в том, что вы добавили. Вопрос в том, что содержит действующая политика после объединения локальной политики, политики домена и значений профиля по умолчанию. Рабочую станцию с одним локальным правилом легко продумать; сервер, присоединённый к домену, — нет.

Поэтому администратор может внести внешне правильное изменение, проверить его с неправильной машины и заключить, что оно сработало. Исключённый источник так и не проверяли. Тест, доказывающий только успех, доказывает меньше половины того, ради чего делалось изменение.

Выясните, какой адрес видит сервер

Прежде чем что-либо ограничивать, пронаблюдайте один разрешённый сеанс на узле Windows и запишите адрес источника, который сообщает сервер. Это не всегда тот адрес, который клиент считает своим.

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

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

Фильтр брандмауэра не может восстановить идентичность, которую отбросила трансляция адресов, как бы аккуратно ни был введён адрес.

Смените владельца действующего правила

Изучите действующую политику входящих подключений и найдите каждое правило, которое сейчас пропускает трафик RDP, включая правила, в отображаемом имени которых никогда не упоминается порт 3389. Учитываются также правила, ограниченные службой и приложением, и транспорт UDP, который включают некоторые развёртывания RDP.

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

Эти команды находят активные правила, показывают фильтр адресов, привязанный к одному из них, и предварительно показывают изменение области:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

Имена правил здесь — заполнители того, что нашёл обзор, а флаг предварительного просмотра существует, чтобы опечатка в адресе не заперла вас снаружи сервера, который вы редактируете.

Сначала блокировать, потом разрешать — другая модель

Привычка из других брандмауэров — написать широкую блокировку, а затем узкое разрешение поверх неё. В Windows явная блокировка обычно побеждает разрешение, поэтому такой порядок создаёт службу, до которой никто не может добраться, вместо исключения для одного клиента. Результат — простой, который выглядит как сломанная служба RDP. На самом деле это ошибка приоритета, и исправление — убрать блокировку, а не добавить ещё одно разрешение.

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

Докажите это вторым источником

Проверьте с разрешённого клиента и из источника, который теперь должен не пройти. Одно успешное подключение доказывает лишь то, что разрешённый путь работает; оно ничего не говорит об исключении, которое вы только что сделали.

Повторите проверку через IPv6, если на сервере он включён, потому что намерение только для IPv4 может сосуществовать с широким разрешением IPv6, на которое никто не смотрел.

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