Bør Windows VPN-adapteren være privat eller offentlig?

Å sette en Windows VPN-adapter til Privat er riktig for en bedriftstunnel og galt for en kommersiell VPN-klient, og forskjellen er ikke kosmetisk. Nettverkskategorien velger en brannmurprofil, så én endring slipper inn et helt regelsett på en gang. Jeg har sett et påloggingsskript sette hver uidentifisert adapter til Privat, noe som stille blottla fildeling på et hotelltrådløstnett. Tre betingelser avgjør svaret, og alle må være oppfylt før du rører innstillingen.

Hva kategorien faktisk avgjør

Network Location Awareness bygger en signatur for hvert tilkoblet nettverk fra det adapteren kan rapportere: gatewayadressen og MAC, DNS-suffikset, om en domenekontroller svarer, og om nettverket når internett. Windows knytter en profil til signaturen, og brannmuren bruker deretter regelsettet for den profilen. Offentlig er reservevalget når identifiseringen feiler, og derfor kan en fungerende tunnel fortsatt bli merket som uidentifisert nettverk.

En TUN- eller TAP-adapter gir vanligvis identifiseringen svært lite å arbeide med. Tunnelpartneren er ofte én adresse i stedet for en gateway, DNS sendes kanskje bare inne i tunnelen, og adapteren har ingen egen standardrute. Etiketten som oppstår beskriver brannmurens inndata, ikke tunnelens helse, og det er grunnen til at private profilregler slutter å stemme i det øyeblikket VPN kobler til.

Betingelse én: tunnelen er den betrodde veien

Å velge Privat hevder at alt som er tilgjengelig gjennom dette grensesnittet er minst like pålitelig som ditt eget LAN, fordi oppdaging og innkommende regler vil behandle subnettet som lokalt. For en bedriftstunnel til et administrert subnett med filservere og skrivere holder påstanden vanligvis. Adapteren er en dør inn til et nettverk organisasjonen din kontrollerer, og maskinen på den andre siden ble sluppet inn av samme policy som slapp inn din.

En kommersiell VPN-utgang består ikke denne testen. Andre abonnenter deler utgangssubnettet, og å merke det Privat setter nettverksoppdaging, LLMNR og NetBIOS-navneoppslag på et segment fullt av fremmede. Splittet tunnel kan også feile: når adapteren bærer én vertsrut til én applikasjon, finnes det ikke noe betrodd subnett å snakke om, og kategoribytte gir deg ingenting.

Betingelse to: klassifiseringen overlever gjentilkoblinger

En ny gateway eller DNS-suffiks gir en ny signatur, og Windows tar en fersk profilbeslutning for den. En engangs Set-NetConnectionProfile varer derfor til neste gjentilkobling, ikke for alltid. Kontroller profilen etter en gjentilkobling i stedet for etter den første tilkoblingen, for det er da innstillingen faller tilbake av seg selv.

Det er tre måter å gjøre det varig. Den reneste er policy: åpne secpol.msc, gå til Network List Manager Policies og angi plasseringstypen for nettverket, inkludert policyen for uidentifiserte nettverk, slik at profilen brukes av policy og ikke av en kommando. Den andre er et skript per tilkobling eller en planlagt oppgave som kjører PowerShell-cmdleten når tunnelen er oppe. Den tredje er det gamle rutetrikset, som gir identifiseringen en gateway å undersøke:

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

Rutetrikset er en omvei, ikke en klassifisering. Det bryter sammen når metrikkforholdet endres eller VPN-klienten skriver om ruter ved gjentilkobling, og det endrer stille veivalget for alt som faller tilbake til den andre standardruten.

Betingelse tre: du trenger det private regelsettet

Privat inneholder vanligvis fildeling og skriverdeling, nettverksoppdaging og gruppene for fjernadministrasjon. Hvis oppgaven er å nå en SMB-deling eller en skriver gjennom tunnelen, er det den egentlige grunnen til å bytte kategori. Hvis oppgaven er utgående tilgang til én webapplikasjon, er kategorien irrelevant: skriv den utgående regelen, behold Offentlig og stopp der.

Les tabellen som utgangspunkt og kontroller deretter hvilke private regler som faktisk er aktivert på ditt bilde. Et herdet bilde kan ha fjernet fildeling helt fra den private profilen, og da oppnår kategoribyttet ingenting før du legger regelen tilbake. Den kontrollen koster én kommando og sparer en lang ettermiddag.

Endringen uten å utvide alt annet

Rett deg mot grensesnittindeksen, ikke et jokertegn, og les listen før og etter:

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

Lagrede profiler ligger under NetworkList-nøkkelen i registeret, der verdien Category skiller offentlige, private og domenenettverk. Det kan redigeres og er lett å gjøre feil: du må endre oppføringen som samsvarer med adapterens nåværende signatur, ikke en eldre oppføring som en tidligere adresse la igjen. En utdatert oppføring ser riktig ut i redigeringsprogrammet og gjør ingenting ved gjentilkobling.

Uansett hva du gjør, ikke lever et skript som setter hver uidentifisert adapter til Privat. Det er énlinjeversjonen av å åpne oppdaging på usikret trådløst. Hvis du bare trenger deling med tunnelsubnettet, behold profilen Offentlig og legg til avgrensede innkommende regler for tunnelens eksterne adresseområde; brannmurregelen er smalere enn kategorien.

Kontroller delingen, ikke etiketten

Etter endringen, test ressursen selv i stedet for å stole på etiketten:

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

Hvis delingen fortsatt feiler mens adapteren viser Privat, er kategorien ikke lenger problemet ditt. Navneoppslag, en manglende rute eller delingstillatelser vil gi samme symptom, og nok en profilendring kan ikke reparere noen av dem. Koble til på nytt én gang og kjør Get-NetConnectionProfile igjen for å bekrefte at innstillingen holdt, og behandle deretter den resterende feilen som et vanlig SMB-problem.

Sjekkliste: bekreft at tunnelen er en administrert vei, at profilen overlever en gjentilkobling, at de private reglene du trenger finnes på bildet, og at delingen løses opp og svarer på port 445. Hvis noe av de tre første er feil, la adapteren stå på Offentlig og løs tilgangsproblemet med en avgrenset regel.