Tunelis veikia, paskyra autentifikuota domene, o Windows vis tiek žymi ryšį kaip viešą. Todėl domeno profiliui parašyta užkardos taisyklė netaikoma, o bendrinamas aplankas lieka nepasiekiamas. Įprastas taisymo bandymas yra nustatyti adapterį į privatų, o tai pakeičia, kurios taisyklės galioja, bet nieko nekeičia autentifikacijoje. Ir žymėjimas, ir taisymas plačiai suprantami neteisingai, o juos atskirti reikia trijų komandų.

Prisijungusi paskyra nėra tinklo kategorija

VPN ryšio metu priimami du skirtingi sprendimai, ir juos lengva supainioti. Šliuzas nusprendžia, ar paskyra gali prisijungti. Windows nusprendžia, kaip klasifikuoti gaunamą tinklą, ir ši klasifikacija lemia, kurios užkardos taisyklės taikomos sąsajai.

Sėkminga domeno autentifikacija šliuze yra įrodymas apie paskyrą. Tai ne įrodymas, kad galinis taškas autentifikavo tinklą domeno valdikliui, ir būtent tai reiškia domeno kategorija.

Todėl mašina gali būti prijungta prie domeno, jungtis domeno paskyra ir vis tiek rodyti viešą. Klasifikacija yra vietinis sprendimas apie tinklą, o ne teiginys apie kredencialus, kurie atidarė tunelį. Paskyra gali būti visiškai galiojanti, kol žymėjimas lieka ten, kur prasidėjo.

Trys kategorijos, iš kurių vienos negalite nustatyti

Windows pateikia tris kategorijas, ir tik dvi iš jų gali priskirti administratorius. Trečiąją nustato operacinė sistema po to, kai sėkmingai autentifikuoja tinklą domeno valdikliui.

CategoryHow it is assignedWhat it affects
PublicDefault for unidentified networks, or set manuallyRules scoped to the public profile
PrivateSet manually, or by the user on a trusted networkRules scoped to the private profile
DomainAuthenticatedDetermined by Windows after domain authenticationRules scoped to the domain profile
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

Trečioji komanda nepavyksta, ir tai yra dokumentuotas elgesys, o ne leidimų problema. Pačios komandos nuoroda teigia, kad domeno kategorijos taip priskirti negalima, nes Windows ją išveda iš domeno autentifikacijos. Klaidos pamatymas yra naudingas patvirtinimas, kad kategorija yra pasekmė, o ne nustatymas.

Perskaitykite pirmąją komandą tame galiniame taške, kurio srautas blokuojamas. Šliuzo pačios sąsajos klasifikacija nieko nepasako apie tai, kaip kiekviena jungianti darbo stotis klasifikavo savo tunelį.

Taisyklės laikosi profilio, kuriam buvo parašytos

Kai žinote kategoriją, trūkstama prieiga paprastai paaiškėja savaime. Kiekviena Windows Firewall taisyklė turi profilio apimtį, o domenui apribota taisyklė negalioja, kai sąsaja yra vieša. Trys komandos tai paverčia atsakymu, o ne teorija, ir trečioji pagauna atvejį, kai profilis niekada nebuvo problema:

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

Antroji komanda yra ta, kuri neaiškią ataskaitą paverčia taisymu. Jei taisyklė apribota nuotolinių adresų diapazonui, kuriame nėra VPN telkinio, profilio keitimas taip pat nepadės.

Patikrinkite ir numatytąjį įeinančio srauto veiksmą. Mašinoje, kur įeinantis srautas pagal numatytuosius nustatymus blokuojamas, trūkstama leidimo taisyklė sukuria tylą, o ne atmetimą. Kliento pusėje tai atrodo identiškai kaip maršrutizavimo gedimas, todėl tiek daug šių bilietų prasideda neteisinga prielaida.

Nustatykite, kuri mašina taiko taisyklę

Prieš keisdami kategoriją, nustatykite, kur vyksta blokavimas. Serveris, kuriame talpinamas bendrinimas, gali turėti savo užkardą, o jos taisyklės taikomos srautui, ateinančiam iš VPN telkinio, nepriklausomai nuo to, kaip klientas pavadino savo adapterį. Atmetimas ten yra nematomas jokiai vietinei komandai, kurią vykdote, o kliento pusė tik praneša, kad išteklius nepasiekiamas. Išbandykite paskirties vietos pačios taisykles, prieš liesdami kliento klasifikaciją.

Išbandykite iš kliento į konkretų prievadą, tada palyginkite su testu iš kito to paties VPN kompiuterio. Jei abu nepavyksta, problema yra paskirties vietoje arba kelyje. Jei nepavyksta tik vienas, skirtumas yra vietinis tai mašinai, ir profilio kategorija tampa tikėtina priežastimi.

Turėkite omenyje ir kryptį. Taisyklė, leidžianti įeinantį SMB, nieko neduoda klientui, kurio pati išeinančioji taisyklė blokuoja tą patį srautą. Iš failų naršyklės lango dviejų gedimų neįmanoma atskirti, todėl bandykite kiekvieną kryptį atskirai, prieš ką nors redaguodami.

Ką daryti vietoj to, kad viską pervadintumėte

Neatpažinto tinklo pavertimas privačiu, kad būtų patenkinta plati taisyklė, yra tikras pokytis su tikromis pasekmėmis. Privatus profilis paprastai leidžia daugiau aptikimo ir daugiau įeinančio srauto nei viešasis.

Jei tikslas yra leisti konkrečiai paslaugai pasiekti VPN klientus, apribokite taisyklę pagal nuotolinį adresą, o ne pagal profilį. Tai tiksliai išreiškia ketinimą, veikia nepriklausomai nuo klasifikacijos ir nepriklauso nuo to, ar Windows teisingai atspėja apie virtualų adapterį. Tai taip pat išgyvena kliento atnaujinimą, kuris iš naujo klasifikuoja sąsają. Įrašykite telkinį į taisyklę, ir kitas žmogus galės perskaityti ketinimą neprašydamas.

Jei domeno kategorijos tikrai tikimasi ir ji niekada neatsiranda, tai atskiras tyrimas. Patikrinkite, ar mašina prijungta prie domeno, ar ji pasiekia domeno valdiklį per tunelį ir ar saugus kanalas sveikas. Šios trys komandos atsako į tai be vieno registro pakeitimo:

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

Šios trys atsako, ar galinis taškas apskritai galėjo autentifikuoti tinklą. Jei jis negali pasiekti valdiklio, domeno kategorija niekada nebus priskirta, kad ir kiek kartų adapteris būtų atstatytas. Užkardos taisyklė, kurios vijotės, niekada nebuvo tikroji problema, o žymėjimas buvo sulaužyto kelio simptomas, o ne priežastis.

Susiję straipsniai