Hvorfor din VPN-adapter bliver på den offentlige firewallprofil

Tunnelen er oppe, kontoen er godkendt mod domænet, og Windows mærker stadig forbindelsen som Offentlig. Derfor gælder en firewallregel skrevet til domæneprofilen ikke, og fildelingen forbliver utilgængelig. Det sædvanlige forsøg på en rettelse er at sætte adapteren til Privat, hvilket ændrer hvilke regler der gælder, uden at ændre noget ved godkendelsen. Både mærkatet og rettelsen misforstås bredt, og at skille dem ad kræver tre kommandoer.

Kontoen, der koblede sig på, er ikke netværkets kategori

Der træffes to forskellige beslutninger under en VPN-forbindelse, og de er lette at forveksle. Gatewayen afgør, om kontoen må forbinde. Windows afgør, hvordan det resulterende netværk skal klassificeres, og den klassificering styrer, hvilke firewallregler der gælder for interfacet.

En vellykket domænegodkendelse ved gatewayen er bevis om kontoen. Det er ikke bevis for, at endpointet har godkendt netværket mod en domænecontroller, og det er præcis, hvad domænekategorien repræsenterer.

Derfor kan en maskine være domænetilsluttet, forbinde med en domænekonto og stadig vise Offentlig. Klassificeringen er en lokal bestemmelse om netværket, ikke en udtalelse om de legitimationsoplysninger, der åbnede tunnelen. Kontoen kan være helt gyldig, mens mærkatet bliver, hvor det startede.

Tre kategorier, hvoraf du ikke kan angive én

Windows stiller tre kategorier til rådighed, og kun to af dem kan tildeles af en administrator. Den tredje afgøres af styresystemet, efter det med succes har godkendt netværket mod en domænecontroller.

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

Den tredje kommando fejler, og det er den dokumenterede adfærd og ikke et tilladelsesproblem. Cmdlet'ens egen reference angiver, at domænekategorien ikke kan tildeles på denne måde, fordi Windows udleder den af domænegodkendelse. At se fejlen er en nyttig bekræftelse på, at kategorien er en konsekvens og ikke en indstilling.

Læs den første kommando på det endpoint, hvis trafik blokeres. Gatewayens egen interfaceklassificering fortæller intet om, hvordan hver forbindende arbejdsstation klassificerede sin tunnel.

Regler følger den profil, de blev skrevet til

Når du kender kategorien, forklarer den manglende adgang sig normalt selv. Hver Windows Firewall-regel har et profilomfang, og en regel begrænset til domæne gælder ikke, når interfacet er offentligt. Tre kommandoer gør det til et svar i stedet for en teori, og den tredje fanger det tilfælde, hvor profilen aldrig var problemet:

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

Den anden kommando er den, der gør en vag rapport til en rettelse. Hvis reglen er begrænset til et interval af fjernadresser, der ikke omfatter VPN-puljen, hjælper det heller ikke at ændre profilen.

Kontroller også standardhandlingen for indgående trafik. På en maskine, hvor indgående trafik er blokeret som standard, giver en manglende tilladelsesregel tavshed i stedet for en afvisning. Fra klientsiden ser det identisk ud med en routingfejl, og derfor begynder så mange af disse sager med den forkerte antagelse.

Find ud af, hvilken maskine der håndhæver reglen

Før du ændrer en kategori, skal du fastslå, hvor blokeringen sker. Serveren, der hoster fildelingen, kan have sin egen firewall, og dens regler gælder for trafikken, der ankommer fra VPN-puljen, uanset hvordan klienten har mærket sin adapter. En afvisning der er usynlig for enhver lokal kommando, du kører, og klientsiden rapporterer kun, at ressourcen er utilgængelig. Test destinationens egne regler, før du rører klientens klassificering.

Test fra klienten til den specifikke port, og sammenlign derefter med en test fra en anden vært på samme VPN. Hvis begge fejler, er problemet ved destinationen eller på vejen. Hvis kun én fejler, er forskellen lokal for den maskine, og profilens kategori bliver en sandsynlig årsag.

Husk også retningen. En regel, der tillader indgående SMB, gør intet for en klient, hvis egen udgående regel blokerer den samme trafik. Fra et stifinder-vindue kan de to fejl ikke skelnes, så test hver retning separat, før du redigerer noget.

Hvad du skal gøre i stedet for at omdøbe alt

At gøre et uidentificeret netværk Privat for at tilfredsstille en bred regel er en reel ændring med reelle konsekvenser. Den private profil tillader typisk mere opdagelse og mere indgående trafik end den offentlige.

Hvis målet er at lade en bestemt tjeneste nå VPN-klienterne, skal du begrænse reglen efter fjernadresse i stedet for efter profil. Det udtrykker hensigten præcist, virker uanset klassificering og afhænger ikke af, at Windows gætter rigtigt om en virtuel adapter. Den overlever også en klientopdatering, der omklassificerer interfacet. Skriv puljen i reglen, og den næste person kan læse hensigten uden at spørge.

Hvis domænekategorien virkelig forventes og aldrig vises, er det en separat undersøgelse. Kontroller, at maskinen er domænetilsluttet, at den kan nå en domænecontroller gennem tunnelen, og at den sikre kanal er sund. De tre kommandoer besvarer det uden en enkelt registreringsændring:

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

De tre besvarer, om endpointet overhovedet kunne have godkendt netværket. Hvis det ikke kan nå en controller, bliver domænekategorien aldrig tildelt, uanset hvor mange gange adapteren nulstilles. Firewallreglen, du jagtede, var aldrig det egentlige problem, og mærkatet var et symptom på en brudt vej snarere end en årsag.