Hvorfor VPN-adapteren din blir værende på den offentlige brannmurprofilen

Tunnelen er oppe, kontoen er autentisert mot domenet, og Windows merker fortsatt tilkoblingen som offentlig. Derfor gjelder ikke en brannmurregel skrevet for domeneprofilen, og filutdelingen forblir utilgjengelig. Det vanlige reparasjonsforsøket er å sette adapteren til Privat, noe som endrer hvilke regler som gjelder, uten å endre noe ved autentiseringen. Både etiketten og reparasjonen misforstås i stor grad, og å skille dem krever tre kommandoer.

Kontoen som koblet til er ikke nettverkets kategori

Under en VPN-tilkobling tas to forskjellige beslutninger, og de er lette å forveksle. Gatewayen avgjør om kontoen får koble til. Windows avgjør hvordan det resulterende nettverket skal klassifiseres, og den klassifiseringen bestemmer hvilke brannmurregler som gjelder for grensesnittet.

Vellykket domeautentisering ved gatewayen er bevis om kontoen. Det er ikke bevis for at endepunktet har autentisert nettverket mot en domenekontroller, og det er nettopp det domenekategorien representerer.

Derfor kan en maskin være domenetilsluttet, koble til med en domenekonto og likevel vise offentlig. Klassifiseringen er en lokal avgjørelse om nettverket, ikke en uttalelse om legitimasjonen som åpnet tunnelen. Kontoen kan være helt gyldig mens etiketten blir der den startet.

Tre kategorier, hvorav du ikke kan angi én

Windows tilbyr tre kategorier, og bare to av dem kan tildeles av en administrator. Den tredje avgjøres av operativsystemet etter at det har autentisert nettverket mot en domenekontroller.

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

Den tredje kommandoen feiler, og det er den dokumenterte oppførselen og ikke et tillatelsesproblem. Referansen til selve kommandoen sier at domenekategorien ikke kan tildeles på denne måten, fordi Windows utleder den fra domeautentisering. Å se feilen er en nyttig bekreftelse på at kategorien er en konsekvens og ikke en innstilling.

Les den første kommandoen på endepunktet der trafikken blokkeres. Gatewayens egen grensesnittklassifisering sier ingenting om hvordan hver tilkoblende arbeidsstasjon klassifiserte tunnelen sin.

Regler følger profilen de ble skrevet for

Når du kjenner kategorien, forklarer den manglende tilgangen seg vanligvis selv. Hver Windows-brannmurregel har et profilomfang, og en regel begrenset til domene gjelder ikke når grensesnittet er offentlig. Tre kommandoer gjør det til et svar i stedet for en teori, og den tredje fanger tilfellet der profilen aldri 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 andre kommandoen er den som gjør en vag rapport om til en reparasjon. Hvis regelen er begrenset til et område med eksterne adresser som ikke omfatter VPN-poolen, hjelper det heller ikke å endre profilen.

Kontroller også standardhandlingen for innkommende trafikk. På en maskin der innkommende trafikk er blokkert som standard, gir en manglende tillatelsesregel stillhet i stedet for en avvisning. Fra klientsiden ser det identisk ut med en rutingfeil, og derfor starter så mange av disse sakene med den feilaktige antakelsen.

Finn ut hvilken maskin som håndhever regelen

Før du endrer en kategori, må du fastslå hvor blokkeringen skjer. Serveren som er vert for utdelingen, kan ha sin egen brannmur, og reglene gjelder for trafikken som kommer fra VPN-poolen, uansett hvordan klienten merket adapteren sin. En avvisning der er usynlig for hver lokal kommando du kjører, og klientsiden rapporterer bare at ressursen ikke er tilgjengelig. Test destinasjonens egne regler før du rører klientens klassifisering.

Test fra klienten til den konkrete porten, og sammenlign deretter med en test fra en annen vert på samme VPN. Hvis begge feiler, er problemet ved destinasjonen eller på veien. Hvis bare én feiler, er forskjellen lokal for den maskinen, og profilkategorien blir en sannsynlig årsak.

Husk retningen også. En regel som tillater innkommende SMB, gjør ingenting for en klient der den egne utgående regelen blokkerer den samme trafikken. Fra et filutforsker-vindu kan de to feilene ikke skilles, så test hver retning separat før du redigerer noe.

Hva du bør gjøre i stedet for å merke alt på nytt

Å gjøre et uidentifisert nettverk privat for å tilfredsstille en bred regel er en reell endring med reelle konsekvenser. Den private profilen tillater vanligvis mer oppdagelse og mer innkommende trafikk enn den offentlige.

Hvis målet er å la en bestemt tjeneste nå VPN-klientene, bør du begrense regelen etter ekstern adresse i stedet for etter profil. Det uttrykker intensjonen presist, fungerer uavhengig av klassifisering og er ikke avhengig av at Windows gjetter riktig om en virtuell adapter. Den overlever også en klientoppdatering som reklassifiserer grensesnittet. Skriv poolen inn i regelen, så kan neste person lese intensjonen uten å spørre.

Hvis domenekategorien virkelig forventes og aldri dukker opp, er det en egen undersøkelse. Kontroller at maskinen er domenetilsluttet, at den kan nå en domenekontroller gjennom tunnelen, og at den sikre kanalen er sunn. Disse tre kommandoene svarer på det uten én eneste registerendring:

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

Disse tre svarer på om endepunktet i det hele tatt kunne ha autentisert nettverket. Hvis det ikke kan nå en kontroller, blir domenekategorien aldri tildelt, uansett hvor mange ganger adapteren tilbakestilles. Brannmurregelen du jaget, var aldri det egentlige problemet, og etiketten var et symptom på en brutt vei, ikke en årsak.