Moet jou Windows-VPN-aanpasser privaat of publiek wees?
Bepaal of 'n Windows-VPN-aanpasser by die privaat profiel hoort met drie toetse: 'n vertroude pad, stabiele klassifikasie en reëls wat jy werklik nodig het.
Om 'n Windows-VPN-aanpasser op Privaat te stel, is reg vir 'n korporatiewe tonnel en verkeerd vir 'n kommersiële VPN-kliënt, en die verskil is nie net kosmeties nie. Die netwerkkategorie kies 'n firewall-profiel, so een verandering laat 'n hele stel reëls tegelyk toe. Ek het gesien hoe 'n aanmeldskrip elke ongeïdentifiseerde aanpasser op Privaat stel, wat stilweg lêerdeling op 'n hotel se draadlose netwerk blootgelê het. Drie voorwaardes bepaal die antwoord, en almal moet geld voordat jy aan die instelling raak.
Wat die kategorie werklik bepaal
Network Location Awareness bou 'n handtekening vir elke gekoppelde netwerk uit wat die aanpasser kan rapporteer: die poortadres en MAC, die DNS-agtervoegsel, of 'n domeinbeheerder antwoord, en of die netwerk die internet bereik. Windows heg 'n profiel aan daardie handtekening, en die firewall pas dan die reëlstel vir daardie profiel toe. Publiek is die terugval wanneer identifisering misluk, en daarom kan 'n werkende tonnel steeds as Ongeïdentifiseerde netwerk gemerk word.
'n TUN- of TAP-aanpasser gee identifisering gewoonlik baie min om mee te werk. Die tonnel-eweknie is dikwels 'n enkele adres eerder as 'n poort, DNS word miskien net binne die tonnel gestuur, en die aanpasser het geen verstekroete van sy eie nie. Die resulterende etiket beskryf die firewall-invoer, nie die gesondheid van die tonnel nie, en dit is die rede waarom privaatprofiel-reëls ophou pas die oomblik wanneer die VPN koppel.
Voorwaarde een: die tonnel is die vertroude pad
Om Privaat te kies, beweer dat alles wat deur hierdie koppelvlak bereikbaar is, ten minste so betroubaar soos jou eie LAN is, want ontdekking en inkomende reëls sal daardie subnet as plaaslik behandel. Vir 'n korporatiewe tonnel na 'n bestuurde subnet met lêerservers en drukkers geld die bewering gewoonlik. Die aanpasser is 'n deur na 'n netwerk wat jou organisasie beheer, en die masjien aan die ander kant is toegelaat deur dieselfde beleid wat joune toegelaat het.
'n Kommersiële VPN-uitgang slaag nie hierdie toets nie. Ander intekenare deel die uitgang-subnet, en om dit Privaat te merk plaas netwerkontdekking, LLMNR en NetBIOS-naamresolusie op 'n segment vol vreemdelinge. Gesplete tonneling kan dit ook laat misluk: wanneer die aanpasser 'n enkele gasheervoete na een toepassing dra, is daar geen vertroude subnet om van te praat nie, en die kategorieverandering bring jou niks.
Voorwaarde twee: die klassifikasie oorleef herverbindings
'n Nuwe poort of DNS-agtervoegsel lewer 'n nuwe handtekening, en Windows maak 'n vars profielbesluit daaroor. 'n Eenmalige Set-NetConnectionProfile oorleef dus tot die volgende herverbinding, nie vir ewig nie. Kontroleer die profiel ná 'n herverbinding eerder as ná die eerste koppeling, want dit is wanneer die instelling vanself terugval.
Daar is drie maniere om dit te laat hou. Die skoonste is beleid: maak secpol.msc oop, gaan na Network List Manager Policies en stel die liggingstipe vir die netwerk, insluitend die beleid vir ongeïdentifiseerde netwerke, sodat die profiel deur beleid toegepas word eerder as deur 'n opdrag. Die tweede is 'n per-koppeling-skrip of geskeduleerde taak wat die PowerShell-cmdlet laat loop nadat die tonnel opkom. Die derde is die ou roete-truuk, wat identifisering 'n poort gee om te ondersoek:
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfileDie roete-truuk is 'n regstelling, nie 'n klassifikasie nie. Dit breek wanneer die metriekverhouding verander of die VPN-kliënt roetes by herverbinding herskryf, en dit verander stilweg padkeuse vir enigiets wat na die tweede verstekroete terugval.
Voorwaarde drie: jy het die privaat reëlstel nodig
Privaat dra gewoonlik Lêer- en Drukkersdeling, Netwerkontdekking en die groep vir afstandadministrasie. As die taak is om 'n SMB-deel of 'n drukker deur die tonnel te bereik, is dit die werklike rede om die kategorie te verander. As die taak uitgaande toegang na een webtoepassing is, is die kategorie irrelevant: skryf die uitgaande reël, hou Publiek, 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 die tabel as 'n beginpunt en kyk dan watter privaat reëls werklik op jou bou geaktiveer is. 'n Geharde beeld het miskien lêerdeling heeltemal uit die privaat profiel verwyder, en dan bereik die kategorieverandering niks totdat jy die reël terugvoeg. Daardie kontrole neem een opdrag en spaar 'n lang middag.
Maak die verandering sonder om alles anders te verbreed
Mik die koppelvlak-indeks, nie 'n wildcard nie, en lees die lys voor en ná:
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfileGestoor profiele woon onder die NetworkList-sleutel in die register, waar die Category-waarde publieke, private en domeinnetwerke skei. Om dit te wysig is moontlik en maklik om verkeerd te doen: jy moet die inskrywing verander wat by die aanpasser se huidige handtekening pas, nie 'n ouer inskrywing wat deur 'n vorige adres agtergelaat is nie. 'n Verouderde inskrywing lyk korrek in die redigeerder en doen niks by herverbinding nie.
Wat jy ook al doen, moet nie 'n skrip lewer wat elke ongeïdentifiseerde aanpasser op Privaat stel nie. Dit is die eenreël-weergawe van ontdekking oopmaak op onbetroubare draadloos. As jy deling net met die tonnel-subnet nodig het, hou die profiel Publiek en voeg beperkte inkomende reëls by wat tot die tonnel se afgeleë adresreeks beperk is; die firewall-reël is smaller as die kategorie.
Verifieer die deel, nie die etiket nie
Toets ná die verandering die hulpbron self eerder as om die etiket te vertrou:
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.exampleAs die deel steeds misluk terwyl die aanpasser Privaat wys, is die kategorie nie meer jou probleem nie. Naamresolusie, 'n ontbrekende roete of deeltoestemmings sal dieselfde simptoom lewer, en om die profiel weer te verander kan nie een daarvan herstel nie. Herverbind een keer en laat Get-NetConnectionProfile weer loop om te bevestig dat die instelling gehou het, en werk dan die oorblywende fout as 'n gewone SMB-probleem.
Kontrolelys: bevestig die tonnel is 'n bestuurde pad, bevestig die profiel oorleef 'n herverbinding, bevestig die privaat reëls wat jy nodig het bestaan op die beeld, en bevestig die deel resolveer en antwoord op poort 445. As enige van die eerste drie onwaar is, los die aanpasser op Publiek en los die toegangsprobleem eerder met 'n beperkte reël op.