Att lägga till en RDP-tillåtelseregel minskar inte din VPN-åtkomst

Planen låter rimlig: låt den befintliga tillåtelsen för Fjärrskrivbord vara och lägg till en liten för den enda VPN-klient som ska ha åtkomst. Windows Firewall fungerar inte så. Regler är inte en ordnad lista där den mest specifika posten vinner, och en smal tillåtelse bredvid en bred ändrar ingenting, eftersom den breda fortfarande släpper in alla den redan släppte in. Att snäva in tjänsten innebär att redigera den tillåtelse som redan gör jobbet.

Regeln du lägger till är inte regeln som spelar roll

Windows Firewall utvärderar alla tillämpliga inkommande regler i de principarkiv som gäller för datorn och avgör sedan om någon tillåtelse matchar och om någon blockering åsidosätter den. Att lägga till en regel lägger till en tillåtelse; den tar inte bort eller preciserar de tillåtelser som redan finns.

Så frågan är aldrig vad du lade till. Det är vad den effektiva principen innehåller efter att lokal princip, domänprincip och profilens standardvärden har slagits samman. En arbetsstation med en lokal regel är lätt att resonera kring; en server som är ansluten till en domän är det inte.

Därför kan en administratör göra en ändring som ser korrekt ut, testa den från fel dator och dra slutsatsen att den fungerade. Källan som uteslöts testades aldrig. Ett test som bara bevisar framgång bevisar mindre än hälften av det ändringen var avsedd för.

Ta reda på vilken adress servern ser

Innan du avgränsar något, observera en tillåten session på Windows-värden och notera källadressen som servern rapporterar. Det är inte alltid adressen som klienten tror att den har.

Om VPN-gatewayen bevarar klientadresser ser servern klientens tunneladress, och en adressavgränsad regel är meningsfull. Om gatewayen översätter kommer varje klient in som gatewayens adress, och avgränsning till den adressen ger åtkomst till varje klient bakom den. Då är regeln exakt om fel sak.

Dessa två konstruktioner behöver olika svar. Den första kan uttryckas i en brandväggsregel; den andra måste genomdrivas där identiteten fortfarande finns, det vill säga i själva VPN:et eller i en autentiserad gateway framför tjänsten.

Ett brandväggsfilter kan inte återställa en identitet som nätverksöversättningen kastade, hur noggrant adressen än skrivs.

Byt ägare till den effektiva regeln

Granska den effektiva inkommande principen och hitta varje regel som för närvarande tillåter RDP-trafik, inklusive regler vars visningsnamn aldrig nämner port 3389. Regler som är avgränsade till tjänst och program räknas också, liksom den UDP-transport som vissa RDP-distributioner aktiverar.

Redigera sedan de befintliga reglerna via det arkiv som äger dem. En lokal ändring av en regel som även domänprincipen definierar kan slås samman, ignoreras eller skrivas över, och det är värt att veta vilket som sker innan du förlitar dig på den.

Dessa kommandon hittar de aktiva reglerna, visar adressfiltret som är kopplat till en av dem och förhandsgranskar en ändring av omfånget:

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

Regelnamnen här är platshållare för det granskningen hittade, och förhandsgranskningsflaggan finns så att ett skrivfel i en adress inte låser dig ute från servern du redigerar.

Blockera-först-tillåt-sedan är en annan modell

Vanan från andra brandväggar är att skriva en bred blockering och sedan en smal tillåtelse ovanpå den. I Windows vinner en explicit blockering vanligtvis över en tillåtelse, så den ordningen ger en tjänst som ingen kan nå i stället för ett undantag för en klient. Resultatet är ett avbrott som ser ut som en trasig RDP-tjänst. Det är egentligen ett prioritetsfel, och rättelsen är att ta bort blockeringen i stället för att lägga till ännu en tillåtelse.

Behåll standardbeteendet för blockering av inkommande trafik på de aktiva profilerna och snäva i stället in de konkreta tillåtelserna. Det lämnar datorn med en begriplig hållning i stället för två motstridiga regler vars samspel beror på prioritetsdetaljer.

Bevisa det med en andra källa

Testa från den tillåtna klienten och från en källa som nu borde misslyckas. En enda lyckad anslutning bevisar bara att den tillåtna vägen fungerar; den säger ingenting om uteslutningen du just gjorde.

Upprepa testet över IPv6 om servern har det aktiverat, eftersom en avsikt som bara gäller IPv4 kan samexistera med en bred IPv6-tillåtelse som ingen har tittat på.

Slutligen, håll autentisering åtskild från nåbarhet. Autentisering på nätverksnivå, kontobehörigheter och inloggningsbegränsningar avgör fortfarande vem som får använda sessionen, och brandväggen avgör bara vem som får fråga. Att ta bort en enhet senare bör ta bort både dess VPN-registrering och denna nätverksbehörighet, annars kommer adressen du avgränsade en dag att tillhöra någon annan.