Чаму ваш адаптар VPN застаецца ў публічным профілі брандмаўэра

Тунэль працуе, уліковы запіс прайшоў аўтэнтыфікацыю ў дамене, а Windows усё яшчэ пазначае злучэнне як «Публічнае». Таму правіла брандмаўэра, напісанае для профілю дамена, не ўжываецца, і агульны дасяг застаецца недаступным. Звычайная спроба выпраўлення — пераключыць адаптар на «Прыватны», што змяняе набор правілаў, але нічога не змяняе ў аўтэнтыфікацыі. І пазначэнне, і выпраўленне шырока разумеюць няправільна, а каб іх раздзяліць, патрэбныя тры каманды.

Уліковы запіс, які падключыўся, — гэта не катэгорыя сеткі

Падчас злучэння VPN прымаюцца два розныя рашэнні, і іх лёгка зблытаць. Шлюз вырашае, ці можа ўліковы запіс падключыцца. Windows вырашае, як класіфікаваць атрыманую сетку, і менавіта гэтая класіфікацыя вызначае, якія правілы брандмаўэра ўжываюцца да інтэрфейса.

Паспяховая аўтэнтыфікацыя ў дамене на шлюзе — гэта доказ пра ўліковы запіс. Гэта не доказ таго, што канцавы пункт аўтэнтыфікаваў сетку ў кантролера дамена, а менавіта гэта і ўяўляе катэгорыя дамена.

Таму машына можа быць уключана ў дамен, падключацца з даменным уліковым запісам і ўсё роўна паказваць «Публічнае». Класіфікацыя — гэта лакальнае вызначэнне сеткі, а не сцвярджэнне пра ўліковыя даныя, якія адкрылі тунэль. Уліковы запіс можа быць цалкам сапраўдным, пакуль пазначэнне застаецца там, дзе пачалося.

Тры катэгорыі, адну з якіх вы не можаце задаць

Windows прапануе тры катэгорыі, і толькі дзве з іх можа прызначыць адміністратар. Трэцюю вызначае аперацыйная сістэма пасля таго, як паспяхова аўтэнтыфікуе сетку ў кантролера дамена.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

Трэцяя каманда не выконваецца, і гэта дакументаваныя паводзіны, а не праблема правоў. Даведка самога камплета сцвярджае, што катэгорыю дамена нельга прызначыць такім чынам, бо Windows выводзіць яе з аўтэнтыфікацыі ў дамене. Убачыць памылку карысна як пацверджанне таго, што катэгорыя — гэта вынік, а не налада.

Чытайце першую каманду на тым канцавым пункце, трафік якога блакуецца. Класіфікацыя ўласнага інтэрфейса шлюза нічога не кажа пра тое, як кожная працоўная станцыя класіфікавала свой тунэль.

Правілы ідуць за профілем, для якога напісаныя

Калі катэгорыя вядомая, недахоп доступу звычайна тлумачыць сябе сам. Кожнае правіла Windows Firewall мае вобласць профілю, і правіла, прызначанае для дамена, не ўжываецца, калі інтэрфейс публічны. Тры каманды ператвараюць гэта ў адказ, а не ў тэорыю, і трэцяя ловіць выпадак, калі профіль ніколі не быў праблемай:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Другая каманда — тая, што ператварае расплывістую справаздачу ў выпраўленне. Калі правіла прывязана да дыяпазону аддаленых адрасоў, які не ўключае пул VPN, змена профілю таксама не дапаможа.

Праверце таксама дзеянне па ўваходзе па змаўчанні. На машыне, дзе ўваход па змаўчанні заблакаваны, адсутнае правіла дазволу дае цішыню, а не адмову. З боку кліента гэта выглядае гэтак жа, як збой маршрутызацыі, і таму шмат такіх заявак пачынаецца з няправільнага меркавання.

Вызначце, якая машына ўжывае правіла

Перш чым змяняць катэгорыю, усталюйце, дзе адбываецца блакаванне. Сервер, які размяшчае агульны дасяг, можа мець уласны брандмаўэр, і яго правілы ўжываюцца да трафіку з пула VPN незалежна ад таго, як кліент назваў свой адаптар. Адмова там нябачная для любой лакальнай каманды, якую вы запускаеце, а кліенцкі бок паведамляе толькі пра недаступнасць рэсурсу. Праверце ўласныя правілы пункту прызначэння, перш чым кранаць класіфікацыю кліента.

Праверце ад кліента да пэўнага порта, а затым параўнайце з праверкай з іншага хоста ў тым жа VPN. Калі не ўдаецца і тое, і тое, праблема ў пункце прызначэння або на шляху. Калі не ўдаецца толькі адна, розніца лакальная для гэтай машыны, і катэгорыя профілю становіцца верагоднай прычынай.

Памятайце і пра кірунак. Правіла, якое дазваляе ўваходны SMB, нічога не робіць для кліента, уласнае правіла якога блакуе той жа трафік на выхадзе. З акна правадніка файлаў два збоі неадрозныя, таму правярайце кожны кірунак асобна, перш чым нешта змяняць.

Што рабіць замест таго, каб пераймяноўваць усё

Зрабіць невядомую сетку прыватнай, каб задаволіць шырокае правіла, — гэта рэальная змена з рэальнымі наступствамі. Прыватны профіль звычайна дазваляе большую выяўленасць і больш уваходнага трафіку, чым публічны.

Калі мэта — дазволіць пэўнай службе дасягаць кліентаў VPN, абмяжуйце правіла па аддаленым адрасе, а не па профілі. Гэта дакладна выражае намер, працуе незалежна ад класіфікацыі і не залежыць ад таго, ці правільна Windows здагадаецца пра віртуальны адаптар. Яно таксама перажывае абнаўленне кліента, якое перазначыць інтэрфейс. Запішыце пул у правіла, і наступны чалавек зможа прачытаць намер, не пытаючыся.

Калі катэгорыя дамена сапраўды чакаецца і ніколі не з’яўляецца, гэта асобнае расследаванне. Праверце, што машына ўключана ў дамен, што яна можа дасягнуць кантролера дамена праз тунэль і што бяспечны канал здаровы. Гэтыя тры каманды адказваюць на гэта без адзінай праўкі рэестра:

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

Гэтыя тры адказваюць, ці магла канцавы пункт наогул аўтэнтыфікаваць сетку. Калі ён не можа дасягнуць кантролера, катэгорыя дамена ніколі не будзе прызначана, колькі б разоў адаптар ні скідвалі. Правіла брандмаўэра, за якім вы гналіся, ніколі не было сапраўднай праблемай, а пазначэнне было сімптомам зламанага шляху, а не прычынай.