Skal din Windows VPN-adapter være privat eller offentlig?

At sætte en Windows VPN-adapter til Privat er rigtigt for en virksomhedstunnel og forkert for en kommerciel VPN-klient, og forskellen er ikke kosmetisk. Netværkskategorien vælger en firewallprofil, så én ændring lukker et helt regelsæt ind på én gang. Jeg har set et logon-script sætte enhver uidentificeret adapter til Privat, hvilket stille blotlagde fildeling på et hoteltrådløsnet. Tre betingelser afgør svaret, og alle skal være opfyldt, før du rører indstillingen.

Hvad kategorien egentlig afgør

Network Location Awareness bygger en signatur for hvert tilsluttet netværk ud fra det, adapteren kan rapportere: gatewayadressen og MAC, DNS-suffikset, om en domænecontroller svarer, og om netværket når internettet. Windows knytter en profil til signaturen, og firefallen anvender derefter regelsættet for den profil. Offentlig er fallback, når identifikationen fejler, og derfor kan en fungerende tunnel stadig blive mærket som uidentificeret netværk.

En TUN- eller TAP-adapter giver normalt identifikationen meget lidt at arbejde med. Tunnelmakkeren er ofte en enkelt adresse i stedet for en gateway, DNS sendes måske kun inde i tunnelen, og adapteren har ingen egen standardrute. Det resulterende mærke beskriver firewallens input, ikke tunnelens tilstand, og det er grunden til, at private profilregler holder op med at matche i det øjeblik, VPN'en forbinder.

Betingelse et: tunnelen er den betroede vej

At vælge Privat hævder, at alt, der kan nås gennem denne grænseflade, mindst er lige så troværdigt som dit eget LAN, fordi registrering og indgående regler vil behandle det subnet som lokalt. For en virksomhedstunnel til et administreret subnet med filservere og printere holder påstanden normalt. Adapteren er en dør ind til et netværk, din organisation styrer, og maskinen på den anden side blev lukket ind af samme politik, som lukkede din ind.

En kommerciel VPN-udgang består ikke denne prøve. Andre abonnenter deler udgangssubnettet, og at mærke det Privat sætter netværksregistrering, LLMNR og NetBIOS-navneopløsning på et segment fuld af fremmede. Split tunneling kan også fejle: når adapteren bærer en enkelt værtsrute til én applikation, er der ingen betroet subnet at tale om, og kategoriskiftet køber dig intet.

Betingelse to: klassificeringen overlever genopkoblinger

En ny gateway eller DNS-suffiks giver en ny signatur, og Windows træffer en frisk profilbeslutning for den. En engangs Set-NetConnectionProfile holder derfor til den næste genopkobling, ikke for evigt. Kontroller profilen efter en genopkobling frem for efter den første forbindelse, for det er der, indstillingen falder tilbage af sig selv.

Der er tre måder at gøre det varigt. Den reneste er politik: åbn secpol.msc, gå til Network List Manager Policies, og angiv placeringstypen for netværket, inklusive politikken for uidentificerede netværk, så profilen anvendes af politik i stedet for af en kommando. Den anden er et script for hver forbindelse eller en planlagt opgave, der kører PowerShell-cmdletten, når tunnelen er oppe. Den tredje er det gamle ruttrick, som giver identifikationen en gateway at undersøge:

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

Ruttricket er en omvej, ikke en klassificering. Det bryder sammen, når metrikforholdet ændres, eller VPN-klienten omskriver ruter ved genopkobling, og det ændrer stille vejvalget for alt, der falder tilbage til den anden standardrute.

Betingelse tre: du har brug for det private regelsæt

Privat bærer normalt Fildeling og Printerdeling, Netværksregistrering og grupperne til fjernadministration. Hvis opgaven er at nå et SMB-share eller en printer gennem tunnelen, er det den egentlige grund til at skifte kategori. Hvis opgaven er udgående adgang til én webapplikation, er kategorien irrelevant: skriv den udgående regel, behold Offentlig, og stop der.

Læs tabellen som udgangspunkt, og kontroller derefter, hvilke private regler der faktisk er aktiveret på dit build. Et hærdet image kan helt have fjernet fildeling fra den private profil, og så opnår kategoriskiftet intet, før du tilføjer reglen igen. Den kontrol koster én kommando og sparer en lang eftermiddag.

Ændringen uden at udvide alt andet

Ret dig mod grænsefladeindekset, ikke et wildcard, og læs listen før og efter:

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

Gemte profiler ligger under NetworkList-nøglen i registreringsdatabasen, hvor værdien Category adskiller offentlige, private og domænenetværk. Det kan redigeres og er let at gøre forkert: du skal ændre den post, der matcher adapterens nuværende signatur, ikke en ældre post efterladt af en tidligere adresse. En forældet post ser korrekt ud i editoren og gør intet ved genopkobling.

Uanset hvad du gør, må du ikke udrulle et script, der sætter enhver uidentificeret adapter til Privat. Det er énlinjesversionen af at åbne registrering på usikret trådløst. Hvis du kun har brug for deling med tunnelsubnettet, behold profilen Offentlig og tilføj afgrænsede indgående regler for tunnelens fjerne adresseområde; firewallreglen er snævrere end kategorien.

Kontroller sharet, ikke mærket

Efter ændringen skal du teste ressourcen selv i stedet for at stole på mærket:

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

Hvis sharet stadig fejler, mens adapteren viser Privat, er kategorien ikke længere dit problem. Navneopløsning, en manglende rute eller sharetilladelser vil give samme symptom, og endnu et profilskift kan ikke reparere nogen af dem. Genopkobl én gang og kør Get-NetConnectionProfile igen for at bekræfte, at indstillingen holdt, og arbejd derefter den resterende fejl som et almindeligt SMB-problem.

Tjekliste: bekræft, at tunnelen er en administreret vej, at profilen overlever en genopkobling, at de private regler, du har brug for, findes på imaget, og at sharet opløses og svarer på port 445. Hvis noget af de første tre er falsk, lad adapteren blive på Offentlig, og løs adgangsproblemet med en afgrænset regel.