Даданне правіла дазволу 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, і гэты дазвол сеткі, інакш адрас, які вы абмежавалі, з часам будзе належаць камусьці іншаму.