Защо вашият 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

Тези три отговарят дали крайната точка изобщо е могла да удостовери мрежата. Ако не може да достигне контролер, категорията на домейна никога няма да бъде зададена, колкото и пъти да се нулира адаптерът. Правилото на защитната стена, което сте преследвали, никога не е било истинският проблем, а обозначението е било симптом на счупен път, а не причина.