Kial via VPN-adaptilo restas ĉe la publika fajroŝirma profilo

La tunelo funkcias, la konto aŭtentiĝis kontraŭ la domajno, kaj Windows ankoraŭ markas la konekton kiel Publika. Sekve regulo de la fajroŝirmo skribita por la domajna profilo ne aplikiĝas, kaj la dosierkunhavigo restas neatingebla. La kutima riparprovo estas agordi la adaptilon al Privata, kio ŝanĝas, kiuj reguloj validas, sen ŝanĝi ion pri la aŭtentikigo. Kaj la marko kaj la riparo estas vaste miskomprenataj, kaj ilia apartigo postulas tri komandojn.

La konto, kiu konektiĝis, ne estas la kategorio de la reto

Dum VPN-konekto okazas du malsamaj decidoj, kaj ilin facile konfuzi. La pordego decidas, ĉu la konto rajtas konektiĝi. Windows decidas, kiel klasifiki la rezultan reton, kaj tiu klasifiko difinas, kiuj fajroŝirmaj reguloj aplikiĝas al la interfaco.

Sukcesa domajna aŭtentikigo ĉe la pordego estas pruvo pri la konto. Ĝi ne estas pruvo, ke la finpunkto aŭtentikigis la reton kontraŭ domajna regilo, kaj ĝuste tion reprezentas la domajna kategorio.

Tial maŝino povas esti domajne aliĝinta, konektiĝi per domajna konto kaj tamen montri Publika. La klasifiko estas loka determino pri la reto, ne aserto pri la legitimajoj, kiuj malfermis la tunelon. La konto povas esti tute valida dum la marko restas tie, kie ĝi komenciĝis.

Tri kategorioj, unu el kiuj ne estas agordebla

Windows prezentas tri kategoriojn, kaj nur du el ili povas esti asignitaj de administranto. La trian decidas la operaciumo post kiam ĝi sukcese aŭtentikigas la reton kontraŭ domajna regilo.

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

La tria komando malsukcesas, kaj tio estas la dokumentita konduto, ne permisa problemo. La referenco de la komando mem diras, ke la domajna kategorio ne povas esti asignita tiel, ĉar Windows derivas ĝin el domajna aŭtentikigo. Vidi la eraron estas utila konfirmo, ke la kategorio estas sekvo, ne agordo.

Legu la unuan komandon ĉe la finpunkto, kies trafiko estas blokata. La klasifiko de la propra interfaco de pordego diras al vi nenion pri tio, kiel ĉiu konektiĝanta laborstacio klasifikis sian tunelon.

Reguloj sekvas la profilon, por kiu ili estis skribitaj

Post kiam vi konas la kategorion, la mankanta aliro kutime mem klarigas sin. Ĉiu regulo de Windows Firewall portas profilamplekson, kaj regulo limigita al domajno ne validas, kiam la interfaco estas publika. Tri komandoj igas tion respondo anstataŭ teorio, kaj la tria kaptas la kazon, kiam la profilo neniam estis la problemo:

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

La dua komando estas tiu, kiu transformas malklaran raporton en riparon. Se la regulo estas limigita al gamo de foraj adresoj, kiu ne inkluzivas la VPN-akvujon, ankaŭ ŝanĝo de la profilo ne helpos.

Kontrolu ankaŭ la defaŭltan agon por envenanta trafiko. Sur maŝino, kie envenanta trafiko estas blokata defaŭlte, mankanta permesa regulo produktas silenton anstataŭ rifuzon. De la klienta flanko tio aspektas idente al vojiga fiasko, kaj pro tio tiom multaj el ĉi tiuj biletoj komenciĝas per la malĝusta supozo.

Determinu, kiu maŝino trudas la regulon

Antaŭ ol ŝanĝi kategorion, establu, kie la blokado okazas. La servilo, kiu gastigas la kunhavigon, povas havi propran fajroŝirmon, kaj ĝiaj reguloj aplikiĝas al la trafiko alvenanta el la VPN-akvujo sendepende de tio, kiel la kliento markis sian adaptilon. Rifuzo tie estas nevidebla por ĉiu loka komando, kiun vi rulas, kaj la klienta flanko nur raportas, ke la rimedo ne estas disponebla. Testu la proprajn regulojn de la celo antaŭ ol tuŝi la klasifikon de la kliento.

Testu de la kliento al la konkreta pordo, poste komparu kun testo de alia gastiganto en la sama VPN. Se ambaŭ malsukcesas, la problemo estas ĉe la celo aŭ sur la vojo. Se nur unu malsukcesas, la diferenco estas loka al tiu maŝino, kaj la profila kategorio fariĝas verŝajna kaŭzo.

Memoru ankaŭ la direkton. Regulo, kiu permesas envenantan SMB, faras nenion por kliento, kies propra eliranta regulo blokas la saman trafikon. El fenestro de dosieresplorilo la du fiaskoj estas nedistingeblaj, do testu ĉiun direkton aparte antaŭ ol redakti ion.

Kion fari anstataŭ renomi ĉion

Igi neidentigitan reton Privata por kontentigi larĝan regulon estas reala ŝanĝo kun realaj sekvoj. La privata profilo kutime permesas pli da malkovro kaj pli da envenanta trafiko ol la publika.

Se la celo estas lasi specifan servon atingi la VPN-klientojn, limigu la regulon laŭ fora adreso anstataŭ laŭ profilo. Tio esprimas la intencon precize, funkcias sendepende de la klasifiko kaj ne dependas de tio, ĉu Windows ĝuste divenas pri virtuala adaptilo. Ĝi ankaŭ postvivas klientan ĝisdatigon, kiu reklasifikas la interfacon. Skribu la akvujon en la regulon, kaj la sekva persono povos legi la intencon sen demandi.

Se la domajna kategorio estas vere atendata kaj neniam aperas, tio estas aparta esploro. Kontrolu, ĉu la maŝino estas domajne aliĝinta, ĉu ĝi povas atingi domajnan regilon tra la tunelo kaj ĉu la sekura kanalo estas sana. Tiuj tri komandoj respondas tion sen eĉ unu redakto de la registrejo:

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

Tiuj tri respondas, ĉu la finpunkto entute povus aŭtentikigi la reton. Se ĝi ne povas atingi regilon, la domajna kategorio neniam estos asignita, kiom ajn da fojoj la adaptilo estos restarigita. La fajroŝirma regulo, kiun vi postkuris, neniam estis la vera problemo, kaj la marko estis simptomo de rompita vojo, ne kaŭzo.