Bør Windows VPN-adapteren vere privat eller offentleg?

Å setje ein Windows VPN-adapter til Privat er rett for ein bedriftstunnel og galt for ein kommersiell VPN-klient, og skilnaden er ikkje kosmetisk. Nettverkskategorien vel ein brannmurprofil, så éi endring slepp inn eit heilt regelsett på ein gong. Eg har sett eit påloggingsskript setje kvar uidentifisert adapter til Privat, noko som stille blottla fildeling på eit hotelltrådlaust nett. Tre vilkår avgjer svaret, og alle må vere oppfylte før du rører innstillinga.

Kva kategorien faktisk avgjer

Network Location Awareness byggjer ein signatur for kvart tilkopla nettverk frå det adapteren kan rapportere: gatewayadressa og MAC, DNS-suffikset, om ein domenekontrollør svarar, og om nettverket når internett. Windows knyter ein profil til signaturen, og brannmuren brukar deretter regelsettet for den profilen. Offentleg er reservevalet når identifiseringa feilar, og difor kan ein fungerande tunnel framleis bli merkt som uidentifisert nettverk.

Ein TUN- eller TAP-adapter gir vanlegvis identifiseringa svært lite å arbeide med. Tunnelpartnaren er ofte éi adresse i staden for ein gateway, DNS blir kanskje berre sendt inne i tunnelen, og adapteren har inga eiga standardrute. Etiketten som oppstår skildrar inndataa til brannmuren, ikkje helsa til tunnelen, og det er grunnen til at private profilreglar sluttar å stemme i det augneblinken VPN koplar til.

Vilkår éin: tunnelen er den betrudde vegen

Å velje Privat hevdar at alt som er tilgjengeleg gjennom dette grensesnittet er minst like påliteleg som ditt eige LAN, fordi oppdaging og innkommande reglar vil handsame subnettet som lokalt. For ein bedriftstunnel til eit administrert subnett med filtenarar og skrivarar held påstanden vanlegvis. Adapteren er ei dør inn til eit nettverk organisasjonen din kontrollerer, og maskina på den andre sida vart sleppt inn av same policy som sleppte inn di.

Ein kommersiell VPN-utgang består ikkje denne testen. Andre abonnentar deler utgangssubnettet, og å merke det Privat set nettverksoppdaging, LLMNR og NetBIOS-namneoppslag på eit segment fullt av framande. Splitta tunnel kan òg feile: når adapteren ber éi vertsrut til éin applikasjon, finst det ikkje noko betrodd subnett å snakke om, og kategoribytte gir deg ingenting.

Vilkår to: klassifiseringa overlever gjenkoplingar

Ein ny gateway eller DNS-suffiks gir ein ny signatur, og Windows tek ei fersk profilavgjerd for den. Ein eingongs Set-NetConnectionProfile varer difor til neste gjenkopling, ikkje for alltid. Kontroller profilen etter ei gjenkopling i staden for etter den første tilkoplinga, for det er då innstillinga fell tilbake av seg sjølv.

Det er tre måtar å gjere det varig. Den reinaste er policy: opne secpol.msc, gå til Network List Manager Policies og set plasseringstypen for nettverket, inkludert policyen for uidentifiserte nettverk, slik at profilen blir brukt av policy og ikkje av ein kommando. Den andre er eit skript per tilkopling eller ei planlagd oppgåve som køyrer PowerShell-cmdleten når tunnelen er oppe. Den tredje er det gamle rutetrikset, som gir identifiseringa ein gateway å undersøkje:

route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfile

Rutetrikset er ein omveg, ikkje ein klassifisering. Det bryt saman når metrikkforholdet endrar seg eller VPN-klienten skriv om ruter ved gjenkopling, og det endrar stille vegvalet for alt som fell tilbake til den andre standardruta.

Vilkår tre: du treng det private regelsettet

Privat inneheld vanlegvis fildeling og skrivardeling, nettverksoppdaging og gruppene for fjernadministrasjon. Viss oppgåva er å nå ei SMB-deling eller ein skrivar gjennom tunnelen, er det den eigentlege grunnen til å bytte kategori. Viss oppgåva er utgåande tilgang til éin webapplikasjon, er kategorien irrelevant: skriv den utgåande regelen, hald Offentleg og stopp der.

Les tabellen som utgangspunkt og kontroller deretter kva private reglar som faktisk er aktiverte på biletet ditt. Eit herda bilete kan ha fjerna fildeling heilt frå den private profilen, og då oppnår kategoribyttet ingenting før du legg regelen tilbake. Den kontrollen kostar éin kommando og sparer ein lang ettermiddag.

Endringa utan å utvide alt anna

Rett deg mot grensesnittindeksen, ikkje eit jokerteikn, og les lista før og etter:

Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfile

Lagra profilar ligg under NetworkList-nøkkelen i registeret, der verdien Category skil offentlege, private og domenenettverk. Det kan redigerast og er lett å gjere feil: du må endre oppføringa som svarar til den noverande signaturen til adapteren, ikkje ei eldre oppføring som ein tidlegare adresse la att. Ei utdatert oppføring ser rett ut i redigeringsprogrammet og gjer ingenting ved gjenkopling.

Uansett kva du gjer, ikkje lever eit skript som set kvar uidentifisert adapter til Privat. Det er éinlinjeversjonen av å opne oppdaging på usikra trådlaust. Viss du berre treng deling med tunnelsubnettet, hald profilen Offentleg og legg til avgrensa innkommande reglar for det eksterne adresseområdet til tunnelen; brannmurregelen er smalare enn kategorien.

Kontroller delinga, ikkje etiketten

Etter endringa, test ressursen sjølv i staden for å stole på etiketten:

Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.example

Viss delinga framleis feilar medan adapteren viser Privat, er kategorien ikkje lenger problemet ditt. Namneoppslag, ei manglande rute eller delingstillatingar vil gi same symptomet, og nok ei profilendring kan ikkje reparere nokon av dei. Kopla til på nytt éin gong og køyr Get-NetConnectionProfile igjen for å stadfeste at innstillinga heldt, og handsame deretter den resterande feilen som eit vanleg SMB-problem.

Sjekkliste: stadfest at tunnelen er ein administrert veg, at profilen overlever ei gjenkopling, at dei private reglane du treng finst på biletet, og at delinga blir løyst opp og svarar på port 445. Viss noko av dei tre første er feil, la adapteren stå på Offentleg og løys tilgangsproblemet med ein avgrensa regel.