Moet je Windows-VPN-adapter privé of openbaar zijn?
Bepaal met drie tests of een Windows-VPN-adapter bij het privéprofiel hoort: vertrouwd pad, stabiele classificatie en regels die je echt nodig hebt.
Een Windows-VPN-adapter op Privé zetten is juist voor een bedrijfstunnel en onjuist voor een commerciële VPN-client, en het verschil is niet cosmetisch. De netwerkcategorie kiest een firewallprofiel, dus één wijziging laat in één keer een hele regelset door. Ik heb een aanmeldscript gezien dat elke niet-geïdentificeerde adapter op Privé zette, waardoor bestand delen op een hotel-wifinetwerk stil werd blootgelegd. Drie voorwaarden bepalen het antwoord, en alle moeten gelden voordat je de instelling aanraakt.
Wat de categorie feitelijk bepaalt
Network Location Awareness bouwt voor elk verbonden netwerk een handtekening uit wat de adapter kan melden: het gatewayadres en de MAC, het DNS-achtervoegsel, of een domeincontroller antwoordt en of het netwerk internet bereikt. Windows koppelt een profiel aan die handtekening, en de firewall past daarna de regelset voor dat profiel toe. Openbaar is de terugvaloptie als identificatie mislukt, waardoor een werkende tunnel nog steeds als niet-geïdentificeerd netwerk kan worden aangeduid.
Een TUN- of TAP-adapter geeft identificatie meestal heel weinig om mee te werken. De tunnelpartner is vaak één adres in plaats van een gateway, DNS wordt misschien alleen binnen de tunnel doorgegeven, en de adapter heeft geen eigen standaardroute. Het resulterende label beschrijft de invoer van de firewall, niet de gezondheid van de tunnel, en daarom stoppen regels van het privéprofiel met matchen op het moment dat de VPN verbindt.
Voorwaarde één: de tunnel is het vertrouwde pad
Privé kiezen stelt dat alles wat via deze interface bereikbaar is minstens zo betrouwbaar is als je eigen LAN, omdat ontdekking en inkomende regels dat subnet als lokaal behandelen. Voor een bedrijfstunnel naar een beheerd subnet met fileservers en printers geldt die stelling meestal. De adapter is een deur naar een netwerk dat je organisatie beheert, en de machine aan de andere kant is toegelaten door hetzelfde beleid dat de jouwe toeliet.
Een commerciële VPN-uitgang slaagt niet voor deze test. Andere abonnees delen het uitgangssubnet, en het Privé markeren zet netwerkontdekking, LLMNR en NetBIOS-naamresolutie op een segment vol vreemden. Split tunneling kan ook falen: wanneer de adapter één hostroute naar één toepassing draagt, is er geen vertrouwd subnet om over te praten, en de categoriewijziging levert je niets op.
Voorwaarde twee: de classificatie overleeft herverbindingen
Een nieuwe gateway of DNS-achtervoegsel levert een nieuwe handtekening op, en Windows neemt daarvoor een nieuwe profielbeslissing. Een eenmalige Set-NetConnectionProfile houdt dus tot de volgende herverbinding stand, niet voor altijd. Controleer het profiel na een herverbinding en niet na de eerste verbinding, want dan valt de instelling vanzelf terug.
Er zijn drie manieren om het blijvend te maken. De schoonste is beleid: open secpol.msc, ga naar Network List Manager Policies en stel het locatietype voor het netwerk in, inclusief het beleid voor niet-geïdentificeerde netwerken, zodat het profiel door beleid wordt toegepast en niet door een opdracht. De tweede is een script per verbinding of een geplande taak die de PowerShell-cmdlet uitvoert zodra de tunnel staat. De derde is de oude routetruc, die identificatie een gateway geeft om te onderzoeken:
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfileDe routetruc is een omweg, geen classificatie. Hij breekt wanneer de metriekverhouding verandert of de VPN-client bij herverbinding routes herschrijft, en hij verandert stil de padkeuze voor alles wat op de tweede standaardroute valt.
Voorwaarde drie: je hebt de privéregelset nodig
Privé bevat meestal Bestands- en printerdeling, Netwerkontdekking en de groepen voor extern beheer. Als de taak is om via de tunnel een SMB-share of een printer te bereiken, is dat de echte reden om de categorie te wijzigen. Als de taak uitgaande toegang tot één webapplicatie is, is de categorie irrelevant: schrijf de uitgaande regel, houd Openbaar en stop daar.
| 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 |
Lees de tabel als uitgangspunt en controleer dan welke privéregels op jouw image werkelijk zijn ingeschakeld. Een gehard image heeft bestandsdeling misschien helemaal uit het privéprofiel verwijderd, en dan bereikt de categoriewijziging niets tot je de regel terugzet. Die controle kost één opdracht en bespaart een lange middag.
De wijziging doorvoeren zonder al het andere te verbreden
Mik op de interface-index, niet op een jokerteken, en lees de lijst voor en na:
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfileOpgeslagen profielen leven onder de registersleutel NetworkList, waar de waarde Category openbare, privé- en domeinnetwerken scheidt. Het is te bewerken en makkelijk fout te doen: je moet de vermelding wijzigen die bij de huidige handtekening van de adapter past, niet een oudere vermelding die een vorig adres heeft achtergelaten. Een verouderde vermelding ziet er in de editor correct uit en doet bij herverbinding niets.
Wat je ook doet, lever geen script uit dat elke niet-geïdentificeerde adapter op Privé zet. Dat is de onelinerversie van ontdekking openzetten op onbetrouwbaar draadloos. Als je alleen deling met het tunnelsubnet nodig hebt, houd het profiel Openbaar en voeg beperkte inkomende regels toe voor het externe adresbereik van de tunnel; de firewallregel is smaller dan de categorie.
Controleer de share, niet het label
Test na de wijziging de resource zelf in plaats van het label te vertrouwen:
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.exampleAls de share nog steeds faalt terwijl de adapter Privé toont, is de categorie niet langer je probleem. Naamresolutie, een ontbrekende route of sharemachtigingen geven hetzelfde symptoom, en nog een profielwijziging kan geen daarvan repareren. Verbind één keer opnieuw en voer Get-NetConnectionProfile opnieuw uit om te bevestigen dat de instelling standhield, en behandel daarna de resterende fout als een gewoon SMB-probleem.
Checklist: bevestig dat de tunnel een beheerd pad is, dat het profiel een herverbinding overleeft, dat de benodigde privéregels op de image staan en dat de share resolveert en antwoordt op poort 445. Als een van de eerste drie onwaar is, laat de adapter dan op Openbaar en los het toegangsprobleem op met een beperkte regel.