Die plan klink redelik: laat die bestaande Remote Desktop-toelating alleen en voeg 'n klein een by vir die enkele VPN-kliënt wat toegang behoort te hê. Windows Firewall werk nie so nie. Reëls is nie 'n geordende lys waar die mees spesifieke inskrywing wen nie, en 'n smal toelating langs 'n breë toelating verander niks, want die breë een laat steeds almal toe wat dit al toegelaat het. Om die diens te vernou beteken om die toelating te wysig wat reeds die werk doen.

Die reël wat jy byvoeg is nie die reël wat saak maak nie

Windows Firewall evalueer alle toepaslike inkomende reëls oor die beleidstore wat op die masjien van toepassing is, en besluit dan of enige toelating pas en of enige blokkering dit oorheers. Om 'n reël by te voeg voeg 'n toelating by; dit verwyder of kwalifiseer nie die toelatings wat reeds daar is nie.

Die vraag is dus nooit wat jy bygevoeg het nie. Dit is wat die effektiewe beleid bevat nadat plaaslike beleid, domeinbeleid en die profielverstekke saamgevoeg is. 'n Werkstasie met een plaaslike reël is maklik om te beredeneer; 'n bediener wat by 'n domein aangesluit is, is nie.

Dit is ook hoekom 'n administrateur 'n korrek-voorkomende verandering kan maak, dit van die verkeerde masjien kan toets en kan aflei dat dit gewerk het. Die uitgeslote bron is nooit getoets nie. 'n Toets wat net sukses bewys, bewys minder as die helfte van waarvoor die verandering bedoel was.

Vind uit watter adres die bediener sien

Voordat jy enigiets beperk, waarneem een toegelate sessie by die Windows-gasheer en teken die bronadres aan wat die bediener rapporteer. Dit is nie altyd die adres wat die kliënt glo hy het nie.

As die VPN-gateway kliëntadresse bewaar, sien die bediener die tonneladres van die kliënt, en 'n adresbeperkte reël is betekenisvol. As die gateway vertaal, kom elke kliënt as die gateway-adres aan, en beperking tot daardie adres verleen toegang aan elke kliënt daaragter. Die reël is dan presies oor die verkeerde ding.

Daardie twee ontwerpe het verskillende antwoorde nodig. Die eerste kan in 'n firewall-reël uitgedruk word; die tweede moet afgedwing word waar identiteit steeds bestaan, dit is die VPN self of 'n geauthentiseerde gateway voor die diens.

'n Firewall-filter kan nie 'n identiteit herwin wat netwerkvertaling weggegooi het nie, maak nie saak hoe noukeurig die adres getik is nie.

Verander die eienaar van die effektiewe reël

Ondersoek die effektiewe inkomende beleid en vind elke reël wat tans RDP-verkeer toelaat, insluitend reëls wie se vertoonnaam nooit poort 3389 noem nie. Diensbeperkte en toepassingbeperkte reëls tel ook, en so ook die UDP-vervoer wat sommige RDP-ontplooiings aktiveer.

Wysig dan die bestaande reëls via watter store dit ook al besit. 'n Plaaslike wysiging aan 'n reël wat domeinbeleid ook definieer, kan saamgevoeg, geïgnoreer of oorskryf word, en dit is die moeite werd om te weet watter van dié voor die tyd gebeur voordat jy daarop staatmaak.

Hierdie opdragte vind die aktiewe reëls, wys die adresfilter wat aan een gekoppel is, en voorskou 'n omvangverandering:

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

Die reëlname hier is plekhouers vir wat die hersiening gevind het, en die voorskou-vlag bestaan sodat 'n tikfout in 'n adres jou nie uitsluit van die bediener wat jy wysig nie.

Blokkeer-dan-toelaat is 'n ander model

Die gewoonte van ander firewalls is om 'n breë blokkering te skryf en dan 'n smal toelating bo dit. Op Windows wen 'n eksplisiete blokkering gewoonlik bo 'n toelating, so daardie ordening lewer 'n diens wat niemand kan bereik nie eerder as 'n uitsondering vir een kliënt. Die resultaat is 'n onderbreking wat soos 'n stukkende RDP-diens lyk. Dit is eintlik 'n voorrangfout, en die regstelling is om die blokkering te verwyder eerder as om nog 'n toelating by te voeg.

Hou die verstek inkomende blokkeergedrag op die aktiewe profiele en beperk eerder die spesifieke toelatings. Dit laat die masjien met een verstaanbare houding eerder as twee teenstrydige reëls wie se interaksie van voorrangbesonderhede afhang.

Bewys dit met 'n tweede bron

Toets van die toegelate kliënt en van 'n bron wat nou behoort te misluk. 'n Enkele suksesvolle verbinding bewys net dat die toegelate pad werk; dit sê niks oor die uitsluiting wat jy pas gemaak het nie.

Herhaal die toets oor IPv6 as die bediener dit geaktiveer het, want 'n slegs-IPv4-bedanking kan saambestaan met 'n wye IPv6-toelating waarna niemand gekyk het nie.

Laastens, hou verifikasie apart van bereikbaarheid. Netwerkvlak-verifikasie, rekeningregte en aanmeldbeperkings besluit steeds wie die sessie mag gebruik, en die firewall besluit net wie mag vra. Om later 'n toestel te verwyder, moet beide sy VPN-inskrywing en hierdie netwerklating verwyder word, anders sal die adres wat jy beperk het uiteindelik aan iemand anders behoort.

Verwante artikels