Aldoni permesregulon por RDP ne mallarĝigas vian VPN-aliron

La plano sonas razone: lasu la ekzistantan permeson por Malproksima Labortablo kaj aldonu malgrandan por la sola VPN-kliento, kiu devus havi aliron. Windows Firewall ne funkcias tiel. Reguloj ne estas ordigita listo, en kiu venkas la plej specifa ero, kaj mallarĝa permeso apud larĝa permeso ŝanĝas nenion, ĉar la larĝa ankoraŭ enlasas ĉiujn, kiujn ĝi jam enlasis. Mallarĝigi la servon signifas redakti la permeson, kiu jam faras la laboron.

La regulo, kiun vi aldonas, ne estas la regulo, kiu gravas

Windows Firewall taksas ĉiujn aplikeblajn envenajn regulojn en la konservejoj de politikoj, kiuj validas por la maŝino, poste decidas, ĉu iu permeso kongruas kaj ĉu iu blokado superregas ĝin. Aldoni regulon aldonas permeson; ĝi ne forigas nek precizigas la permesojn jam ekzistantajn.

Do la demando neniam estas, kion vi aldonis. Ĝi estas, kion enhavas la efektiva politiko post kiam loka politiko, domajna politiko kaj la profilaj defaŭltoj estas kunfanditaj. Laborejon kun unu loka regulo facile pripensi; servilon aliĝintan al domajno ne.

Tial ankaŭ administranto povas fari ŝanĝon, kiu aspektas ĝusta, testi ĝin de la malĝusta maŝino kaj konkludi, ke ĝi funkciis. La ekskludita fonto neniam estis testita. Testo, kiu pruvas nur sukceson, pruvas malpli ol duonon de tio, por kio la ŝanĝo estis farita.

Eltrovu, kiun adreson la servilo vidas

Antaŭ ol limigi ion ajn, observu unu permesitan seancon ĉe la Windows-gastiganto kaj notu la fontan adreson, kiun la servilo raportas. Ĝi ne ĉiam estas la adreso, kiun la kliento kredas havi.

Se la VPN-enirejo konservas klientajn adresojn, la servilo vidas la tunelan adreson de la kliento, kaj adreso-limigita regulo havas sencon. Se la enirejo tradukas, ĉiu kliento alvenas kiel la adreso de la enirejo, kaj limigo al tiu adreso donas aliron al ĉiu kliento malantaŭ ĝi. Tiam la regulo estas preciza pri la malĝusta afero.

Tiuj du dezajnoj bezonas malsamajn respondojn. La unua povas esti esprimita en fajroŝirma regulo; la dua devas esti trudita tie, kie identeco ankoraŭ ekzistas, tio estas en la VPN mem aŭ en aŭtentikigita enirejo antaŭ la servo.

Fajroŝirma filtrilo ne povas reakiri identecon, kiun reta tradukado forĵetis, kiom ajn zorge la adreso estas tajpita.

Ŝanĝu la posedanton de la efektiva regulo

Inspektu la efektivan envenan politikon kaj trovu ĉiun regulon, kiu nuntempe permesas RDP-trafikon, inkluzive regulojn, kies montrata nomo neniam mencias havenon 3389. Reguloj limigitaj al servo kaj al aplikaĵo ankaŭ validas, kaj same la UDP-transporto, kiun iuj RDP-enkondukoj ebligas.

Poste redaktu la ekzistantajn regulojn per tiu konservejo, kiu posedas ilin. Loka redakto de regulo, kiun ankaŭ difinas domajna politiko, povas esti kunfandita, ignorita aŭ superskribita, kaj indas scii, kiu el tiuj okazas antaŭ ol fidigi ĝin.

Tiuj ĉi komandoj trovas la aktivajn regulojn, montras la adresan filtrilon ligitan al unu el ili kaj antaŭprezentas ŝanĝon de amplekso:

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

La regulnomoj ĉi tie estas anstataŭigiloj por tio, kion trovis la revizio, kaj la antaŭprezenta flago ekzistas por ke tajperaro en adreso ne ŝlosu vin ekster la servilon, kiun vi redaktas.

Unue bloki, poste permesi estas alia modelo

La kutimo el aliaj fajroŝirmiloj estas skribi larĝan blokadon kaj poste mallarĝan permeson super ĝi. En Windows eksplicita blokado ĝenerale venkas super permeso, do tiu ordo kreas servon, kiun neniu povas atingi, anstataŭ escepton por unu kliento. La rezulto estas interrompo, kiu aspektas kiel difektita RDP-servo. Ĝi estas fakte eraro de prioritato, kaj la korekto estas forigi la blokadon anstataŭ aldoni alian permeson.

Konservu la defaŭltan blokadan konduton de envena trafiko sur la aktivaj profiloj kaj anstataŭe mallarĝigu la konkretajn permesojn. Tio lasas la maŝinon kun unu komprenebla sinteno anstataŭ du kontraŭdiraj reguloj, kies interago dependas de detaloj de prioritato.

Pruvu tion per dua fonto

Testu de la permesita kliento kaj de fonto, kiu nun devus malsukcesi. Unu sola sukcesa konekto pruvas nur, ke la permesita vojo funkcias; ĝi diras nenion pri la ekskludo, kiun vi ĵus faris.

Ripetu la teston per IPv6 se la servilo havas ĝin ebligita, ĉar intenco nur por IPv4 povas kunekzisti kun larĝa IPv6-permeso, kiun neniu rigardis.

Fine, tenu aŭtentikigon aparte de atingeblo. Aŭtentikigo je reta nivelo, kontaj rajtoj kaj ensalutaj limigoj ankoraŭ decidas, kiu rajtas uzi la seancon, kaj la fajroŝirmilo decidas nur, kiu rajtas demandi. Forigo de aparato poste devus forigi kaj ĝian VPN-registriĝon kaj ĉi tiun retan permeson, alie la adreso, kiun vi limigis, iam apartenos al iu alia.