Å leggje til ein RDP-løyveregel gjer ikkje VPN-tilgangen din trongare

Planen høyrest rimeleg ut: lat den eksisterande løyva for Eksternt skrivebord vera, og legg til ei lita for den einaste VPN-klienten som skal ha tilgang. Windows Firewall fungerer ikkje slik. Reglar er ikkje ei ordna liste der den mest spesifikke oppføringa vinn, og ei smal løyve ved sida av ei brei endrar ingenting, fordi den breie slepp framleis inn alle han alt sleppte inn. Å gjera tenesta trongare tyder å redigera løyva som alt gjer jobben.

Regelen du legg til er ikkje regelen som betyr noko

Windows Firewall vurderer alle gjeldande innkomande reglar i policy-lagra som gjeld for maskinen, og avgjer deretter om ei løyve passar og om ei blokkering overstyrer ho. Å leggje til ein regel legg til ei løyve; han fjernar eller presiserer ikkje løyva som alt finst.

Så spørsmålet er aldri kva du la til. Det er kva den effektive policyen inneheld etter at lokal policy, domenepolicy og profilens standardverdiar er slått saman. Ein arbeidsstasjon med ein lokal regel er lett å tenkje gjennom; ein tenar knytt til eit domene er det ikkje.

Derfor kan ein administrator gjera ei endring som ser rett ut, testa ho frå feil maskin og konkludera med at ho virka. Kjelda som vart utelaten, vart aldri testa. Ein test som berre provar suksess, provar mindre enn halvparten av det endringa var meint for.

Finn ut kva adresse tenaren ser

Før du avgrensar noko, observer éin tillaten økt på Windows-verten og noter kjeldeadressa tenaren rapporterer. Det er ikkje alltid adressa klienten trur han har.

Viss VPN-gatewayen bevarer klientadresser, ser tenaren tunneladressa til klienten, og ein adresseavgrensa regel gir meining. Viss gatewayen omset, kjem kvar klient som adressa til gatewayen, og avgrensing til den adressa gir tilgang til kvar klient bak henne. Då er regelen presis om det gale.

Desse to designa treng ulike svar. Det første kan uttrykkjast i ein brannmurregel; det andre må handhevast der identiteten framleis finst, altså i sjølve VPN-en eller i ein autentisert gateway framfor tenesta.

Eit brannmurfilter kan ikkje gjenoppretta ein identitet som nettverksomsetjinga kasta, uansett kor nøye adressa er skriven.

Endre eigaren av den effektive regelen

Undersøk den effektive innkomande policyen og finn kvar regel som for tida tillèt RDP-trafikk, inkludert reglar der visingsnamnet aldri nemner port 3389. Tenestavgrensa og applikasjonsavgrensa reglar tel òg, og det same gjer UDP-transporten som enkelte RDP-distribusjonar slår på.

Rediger deretter dei eksisterande reglane gjennom lageret som eig dei. Ei lokal endring av ein regel som domenepolicyen òg definerer, kan bli slått saman, oversett eller overstyrt, og det er verdt å vite kva som skjer før du stolar på han.

Desse kommandoane finn dei aktive reglane, viser adressefilteret som er knytt til ein av dei, og førehandsvarker ei endring av omfanget:

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

Regelnamna her er plasshaldarar for det gjennomgangen fann, og førehandsvarsflagget finst for at ein skrivefeil i ei adresse ikkje skal låse deg ute frå tenaren du redigerer.

Blokker-fyrst-tillat-så er ein annan modell

Vanen frå andre brannmurar er å skriva ei brei blokkering og deretter ei smal løyve over henne. I Windows vinn ei eksplisitt blokkering vanlegvis over ei løyve, så den rekkjefølgja gir ei teneste ingen når fram til i staden for eit unntak for éin klient. Resultatet er eit avbrot som ser ut som ei øydelagd RDP-teneste. Det er eigenleg ein prioritetsfeil, og rettinga er å fjerna blokkeringa i staden for å leggja til endå ei løyve.

Hald standardoppførselen for blokkering av innkomande trafikk på dei aktive profilane, og gjer i staden dei konkrete løyva trongare. Det lèt maskinen sitja att med éin forståeleg haldning i staden for to motstridande reglar der samspelet avheng av prioritetsdetaljar.

Prov det med ei andre kjelde

Test frå den tillatne klienten og frå ei kjelde som no skal feila. Éin vellukka tilkopling provar berre at den tillatne vegen verkar; ho seier ingenting om utelatinga du nettopp gjorde.

Gjenta testen over IPv6 viss tenaren har det slått på, fordi ei meining berre for IPv4 kan finnast saman med ei brei IPv6-løyve som ingen har sett på.

Til slutt, hald autentisering skild frå nåbarheit. Nettverksnivåautentisering, kontorettar og påloggingsavgrensingar avgjer framleis kven som kan bruka økta, og brannmuren avgjer berre kven som kan spørja. Å fjerna ein eining seinare bør fjerna både VPN-registreringa og denne nettverksløyva, elles vil adressa du avgrensa ein gong tilhøyra nokon andre.