Bör Windows VPN-adaptern vara privat eller offentlig?
Avgör med tre tester om en Windows VPN-adapter hör till den privata profilen: betrodd väg, stabil klassificering och regler du faktiskt behöver.
Att ställa in en Windows VPN-adapter på Privat är rätt för en företagstunnel och fel för en kommersiell VPN-klient, och skillnaden är inte kosmetisk. Nätverkskategorin väljer en brandväggsprofil, så en enda ändring släpper in ett helt regelverk på en gång. Jag har sett ett inloggningsskript sätta varje oidentifierad adapter på Privat, vilket tyst blottade fildelning i ett hotelltrådlöst nät. Tre villkor avgör svaret, och alla måste gälla innan du rör inställningen.
Vad kategorin faktiskt avgör
Network Location Awareness bygger en signatur för varje anslutet nätverk utifrån vad adaptern kan rapportera: gatewayadressen och MAC, DNS-suffixet, om en domänkontrollant svarar och om nätverket når internet. Windows kopplar en profil till signaturen, och brandväggen tillämpar sedan regelverket för den profilen. Offentlig är reservvalet när identifieringen misslyckas, och därför kan en fungerande tunnel fortfarande märkas som oidentifierat nätverk.
En TUN- eller TAP-adapter ger vanligtvis identifieringen mycket lite att arbeta med. Tunnelpartnern är ofta en enda adress i stället för en gateway, DNS skickas kanske bara inne i tunneln, och adaptern har ingen egen standardrutt. Etiketten som uppstår beskriver brandväggens indata, inte tunnelns hälsa, och det är därför regler för den privata profilen slutar matcha i samma ögonblick som VPN ansluter.
Villkor ett: tunneln är den betrodda vägen
Att välja Privat hävdar att allt som går att nå via detta gränssnitt är minst lika pålitligt som ditt eget LAN, eftersom upptäckt och inkommande regler kommer att behandla subnätet som lokalt. För en företagstunnel till ett hanterat subnät med filservrar och skrivare gäller påståendet oftast. Adaptern är en dörr in i ett nätverk som din organisation kontrollerar, och maskinen på andra sidan släpptes in av samma policy som släppte in din.
En kommersiell VPN-utgång klarar inte detta test. Andra abonnenter delar utgångssubnätet, och att märka det som Privat sätter nätverksupptäckt, LLMNR och NetBIOS-namnlösning på ett segment fullt av främlingar. Delad tunnel kan också misslyckas: när adaptern bär en enda värdrutt till en applikation finns inget betrott subnät att tala om, och kategoribytet ger dig ingenting.
Villkor två: klassificeringen överlever återanslutningar
En ny gateway eller ett nytt DNS-suffix ger en ny signatur, och Windows fattar ett nytt profilbeslut för den. En engångs Set-NetConnectionProfile håller därför till nästa återanslutning, inte för alltid. Kontrollera profilen efter en återanslutning i stället för efter den första anslutningen, för det är då inställningen faller tillbaka av sig själv.
Det finns tre sätt att göra det varaktigt. Det renaste är policy: öppna secpol.msc, gå till Network List Manager Policies och ange platstypen för nätverket, inklusive policyn för oidentifierade nätverk, så att profilen tillämpas av policy i stället för av ett kommando. Det andra är ett skript per anslutning eller en schemalagd uppgift som kör PowerShell-cmdleten när tunneln är uppe. Det tredje är det gamla rutt-tricket, som ger identifieringen en gateway att undersöka:
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfileRutt-tricket är en kringgång, inte en klassificering. Det går sönder när metric-förhållandet ändras eller VPN-klienten skriver om rutter vid återanslutning, och det ändrar tyst vägvalet för allt som faller tillbaka på den andra standardrutten.
Villkor tre: du behöver det privata regelverket
Privat innehåller vanligtvis fildelning och skrivardelning, nätverksupptäckt och grupperna för fjärradministration. Om uppgiften är att nå en SMB-delning eller en skrivare genom tunneln är det den egentliga anledningen att byta kategori. Om uppgiften är utgående åtkomst till en webbapplikation är kategorin irrelevant: skriv den utgående regeln, behåll Offentlig och stanna där.
| Scenario | Category | Why |
|---|---|---|
| Corporate tunnel to a file server or printer | Private | Private rules carry the sharing you need |
| Commercial VPN for privacy | Public | The exit subnet is shared with strangers |
| Split tunnel with a single host route | Public | No trusted subnet and an unstable signature |
| Site-to-site tunnel to a branch LAN | Private | The far subnet is managed like the local one |
| Lab adapter you control end to end | Private | Discovery helps and nothing else is exposed |
Läs tabellen som utgångspunkt och kontrollera sedan vilka privata regler som faktiskt är aktiverade på din avbildning. En härdad avbildning kan ha tagit bort fildelning helt från den privata profilen, och då uppnår kategoribytet ingenting förrän du lägger tillbaka regeln. Den kontrollen kostar ett kommando och sparar en lång eftermiddag.
Ändringen utan att vidga allt annat
Rikta in dig mot gränssnittsindexet, inte ett jokertecken, och läs listan före och efter:
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfileSparade profiler ligger under NetworkList-nyckeln i registret, där värdet Category skiljer offentliga, privata och domännätverk. Det går att redigera och är lätt att göra fel: du måste ändra posten som matchar adapterns nuvarande signatur, inte en äldre post som en tidigare adress lämnade kvar. En inaktuell post ser korrekt ut i redigeraren och gör ingenting vid återanslutning.
Vad du än gör, släpp inte ett skript som sätter varje oidentifierad adapter på Privat. Det är enradsversionen av att öppna upptäckt på ett osäkert trådlöst nät. Om du bara behöver delning med tunnelsubnätet, behåll profilen Offentlig och lägg till avgränsade inkommande regler för tunnelns avlägsna adressområde; brandväggsregeln är snävare än kategorin.
Kontrollera delningen, inte etiketten
Efter ändringen, testa resursen själv i stället för att lita på etiketten:
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.exampleOm delningen fortfarande misslyckas medan adaptern visar Privat är kategorin inte längre ditt problem. Namnlösning, en saknad rutt eller delningsbehörigheter ger samma symptom, och ännu ett profilbyte kan inte reparera något av dem. Anslut igen en gång och kör Get-NetConnectionProfile på nytt för att bekräfta att inställningen höll, och behandla sedan det återstående felet som ett vanligt SMB-problem.
Checklista: bekräfta att tunneln är en hanterad väg, att profilen överlever en återanslutning, att de privata regler du behöver finns på avbildningen och att delningen löses upp och svarar på port 445. Om något av de tre första är falskt, låt adaptern stå på Offentlig och lös åtkomstproblemet med en avgränsad regel.