Kvifor VPN-adapteren din blir verande på den offentlege brannmurprofilen

Tunnelen er oppe, kontoen er autentisert mot domenet, og Windows merkar framleis tilkoplinga som offentleg. Difor gjeld ikkje ein brannmurregel skriven for domeneprofilen, og filutdelinga blir verande utilgjengeleg. Det vanlege reparasjonsforsøket er å setja adapteren til Privat, noko som endrar kva reglar som gjeld, utan å endra noko ved autentiseringa. Både etiketten og reparasjonen blir misforstått i stor grad, og å skilja dei krev tre kommandoar.

Kontoen som kopla til er ikkje kategorien til nettet

Under ei VPN-tilkopling blir to ulike avgjerder tekne, og dei er lette å forveksla. Gatewayen avgjer om kontoen får kopla til. Windows avgjer korleis det resulterande nettet skal klassifiserast, og den klassifiseringa bestemmer kva brannmurreglar som gjeld for grensesnittet.

Vellykka domeautentisering ved gatewayen er prov om kontoen. Det er ikkje prov for at endepunktet har autentisert nettet mot ein domenekontrollar, og det er nettopp det domenekategorien representerer.

Difor kan ein maskin vere domenetilknytt, kopla til med ein domenekonto og likevel visa offentleg. Klassifiseringa er ei lokal avgjerd om nettet, ikkje ei utsegn om legitimasjonen som opna tunnelen. Kontoen kan vere heilt gyldig medan etiketten blir der han starta.

Tre kategoriar, der du ikkje kan setja éin

Windows tilbyr tre kategoriar, og berre to av dei kan tildelast av ein administrator. Den tredje blir avgjord av operativsystemet etter at det har autentisert nettet mot ein domenekontrollar.

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 feilar, og det er den dokumenterte åtferda og ikkje eit løyveproblem. Referansen til sjølve kommandoen seier at domenekategorien ikkje kan tildelast på denne måten, fordi Windows leier han ut frå domeautentisering. Å sjå feilen er ei nyttig stadfesting på at kategorien er ei fylgje og ikkje ei innstilling.

Les den første kommandoen på endepunktet der trafikken blir blokkert. Gatewayen si eiga grensesnittklassifisering seier ingenting om korleis kvar tilkoplande arbeidsstasjon klassifiserte tunnelen sin.

Reglar fylgjer profilen dei vart skrivne for

Når du kjenner kategorien, forklarar den manglande tilgangen seg vanlegvis sjølv. Kvar Windows-brannmurregel har eit profilområde, og ein regel avgrensa til domene gjeld ikkje når grensesnittet er offentleg. Tre kommandoar gjer det til eit svar i staden for ein teori, og den tredje fangar 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 gjer ein vag rapport om til ein reparasjon. Viss regelen er avgrensa til eit område med eksterne adresser som ikkje omfattar VPN-poolen, hjelper det heller ikkje å endra profilen.

Kontroller også standardhandlinga for innkommande trafikk. På ein maskin der innkommande trafikk er blokkert som standard, gir ein manglande løyveregel stilla i staden for ei avvising. Frå klientsida ser det identisk ut med ein rutefeil, og difor startar så mange av desse sakene med den feilaktige føresetnaden.

Finn ut kva maskin som handhevar regelen

Før du endrar ein kategori, må du fastslå kvar blokkeringa skjer. Tenaren som er vert for utdelinga, kan ha sin eigen brannmur, og reglane hans gjeld for trafikken som kjem frå VPN-poolen, uansett korleis klienten merka adapteren sin. Ei avvising der er usynleg for kvar lokal kommando du køyrer, og klientsida rapporterer berre at ressursen ikkje er tilgjengeleg. Test dei eigne reglane til destinasjonen før du rører klassifiseringa til klienten.

Test frå klienten til den konkrete porten, og samanlikn deretter med ein test frå ein annan vert på same VPN. Viss begge feilar, er problemet ved destinasjonen eller på vegen. Viss berre éin feilar, er skilnaden lokal for den maskinen, og profilkategorien blir ei sannsynleg årsak.

Hugs retninga også. Ein regel som lèt innkommande SMB gjennom, gjer ingenting for ein klient der den eigne utgåande regelen blokkerer den same trafikken. Frå eit filutforskar-vindauge kan dei to feila ikkje skiljast, så test kvar retning separat før du redigerer noko.

Kva du bør gjera i staden for å merka alt på nytt

Å gjera eit uidentifisert nett privat for å tilfredsstilla ein brei regel er ei reell endring med reelle fylgjer. Den private profilen lèt vanlegvis til meir oppdaging og meir innkommande trafikk enn den offentlege.

Viss målet er å la ein bestemd teneste nå VPN-klientane, bør du avgrensa regelen etter ekstern adresse i staden for etter profil. Det uttrykkjer intensjonen presist, fungerer uavhengig av klassifisering og er ikkje avhengig av at Windows gissar rett om ein virtuell adapter. Han overlever også ein klientoppdatering som reklassifiserer grensesnittet. Skriv poolen inn i regelen, så kan neste person lese intensjonen utan å spørja.

Viss domenekategorien verkeleg er venta og aldri dukkar opp, er det ei eiga undersøking. Kontroller at maskinen er domenetilknytt, at han kan nå ein domenekontrollar gjennom tunnelen, og at den sikre kanalen er sunn. Desse tre kommandoane svarar på det utan éi einaste registerendring:

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

Desse tre svarar på om endepunktet i det heile kunne ha autentisert nettet. Viss det ikkje kan nå ein kontrollar, blir domenekategorien aldri tildelt, uansett kor mange gonger adapteren blir nullstilt. Brannmurregelen du jaga, var aldri det eigentlege problemet, og etiketten var eit symptom på ein broten veg, ikkje ei årsak.