Додавання правила дозволу для 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, і цей мережевий дозвіл, інакше адреса, яку ви обмежили, колись належатиме комусь іншому.

Схожі статті