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