Додавањето правило за дозвола за 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 и оваа мрежна дозвола, инаку адресата што ја ограничивте еден ден ќе му припаѓа на некој друг.