Ĉu via Windows VPN-adaptilo estu privata aŭ publika?

Agordi Windows VPN-adaptilon al Privata estas ĝuste por entreprena tunelo kaj malĝuste por komerca VPN-kliento, kaj la diferenco ne estas kosmetika. La reta kategorio elektas fajroŝirman profilon, do unu ŝanĝo samtempe enlasas tutan regulan aron. Mi vidis ensalutan skripton agordi ĉiun neidentigitan adaptilon al Privata, kio kviete elmetis dosierkunhavigon en hotela sendrata reto. Tri kondiĉoj decidas la respondon, kaj ĉiuj devas validi antaŭ ol vi tuŝos la agordon.

Kion la kategorio efektive decidas

Network Location Awareness konstruas subskribon por ĉiu konektita reto el tio, kion la adaptilo povas raporti: la pordega adreso kaj MAC, la DNS-sufikso, ĉu domajna regilo respondas kaj ĉu la reto atingas la interreton. Windows ligas profilon al tiu subskribo, kaj poste la fajroŝirmilo aplikas la regulan aron por tiu profilo. Publika estas la rezerva varianto kiam identigo malsukcesas, kaj tial funkcianta tunelo povas resti etikedita kiel neidentigita reto.

TUN- aŭ TAP-adaptilo kutime donas al identigo tre malmulte da informoj. La tunela kunulo ofte estas unu adreso anstataŭ pordego, DNS eble estas puŝata nur ene de la tunelo, kaj la adaptilo havas neniun propran implicitan vojon. La rezulta etikedo priskribas la enigon de la fajroŝirmilo, ne la sanon de la tunelo, kaj tial reguloj de la privata profilo ĉesas kongrui en la momento, kiam la VPN konektiĝas.

Kondiĉo unu: la tunelo estas la fidinda vojo

Elekti Privata asertas, ke ĉio atingebla tra ĉi tiu interfaco estas almenaŭ same fidinda kiel via propra LAN, ĉar malkovro kaj envenantaj reguloj traktos tiun subreton kiel lokan. Por entreprena tunelo en administritan subreton kun dosieraj serviloj kaj printiloj, la aserto kutime validas. La adaptilo estas pordo en reton, kiun via organizo kontrolas, kaj la maŝino aliflanke estis akceptita per la sama politiko, kiu akceptis vian.

Komerca VPN-eliro malsukcesas ĉi tiun provon. Aliaj abonantoj kunhavas la eliran subreton, kaj marki ĝin Privata metos retan malkovron, LLMNR kaj NetBIOS-nomrezolvon sur segmenton plenan de fremduloj. Dividita tunelado ankaŭ povas malsukcesi: kiam la adaptilo portas unu solan gastigan vojon al unu aplikaĵo, ne estas fidinda subreto pri kiu paroli, kaj la kategoria ŝanĝo aĉetas al vi nenion.

Kondiĉo du: la klasifiko postvivas rekonektojn

Nova pordego aŭ DNS-sufikso produktas novan subskribon, kaj Windows faras novan profilan decidon por ĝi. Do unufoja Set-NetConnectionProfile daŭras ĝis la sekva rekonekto, ne eterne. Kontrolu la profilon post rekonekto, ne post la unua konekto, ĉar tiam la agordo mem revenas.

Estas tri manieroj igi tion daŭra. La plej pura estas politiko: malfermu secpol.msc, iru al Network List Manager Policies kaj agordu la lokan tipon por la reto, inkluzive de la politiko por neidentigitaj retoj, por ke la profilo aplikiĝu per politiko anstataŭ per komando. La dua estas skripto por konekto aŭ planita tasko, kiu rulas la PowerShell-cmdleton post kiam la tunelo leviĝas. La tria estas la malnova artifiko de vojo, kiu donas al identigo pordegon por esplori:

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

La voja artifiko estas provizora solvo, ne klasifiko. Ĝi rompiĝas kiam la metrika rilato ŝanĝiĝas aŭ la VPN-kliento reverkas vojojn ĉe rekonekto, kaj ĝi kviete ŝanĝas voj-elekton por ĉio, kio falas al la dua implicita vojo.

Kondiĉo tri: vi bezonas la privatan regulan aron

Privata kutime portas Dosier- kaj Printilkunhavigon, Retan Malkovron kaj la grupojn de fora administrado. Se la tasko estas atingi SMB-kunhavaĵon aŭ printilon tra la tunelo, tio estas la vera kialo ŝanĝi la kategorion. Se la tasko estas elira aliro al unu reta aplikaĵo, la kategorio estas nereleva: skribu la eliran regulon, konservu Publika, kaj haltu tie.

Legu la tabelon kiel deirpunkton, poste kontrolu, kiuj privataj reguloj efektive estas ebligitaj en via bildo. Hardita bildo eble tute forigis dosierkunhavigon el la privata profilo, kaj tiam la kategoria ŝanĝo atingas nenion ĝis vi reenmetos la regulon. Tiu kontrolo kostas unu komandon kaj ŝparas longan posttagmezon.

Fari la ŝanĝon sen larĝigi ĉion alian

Celu la interfacan indekson, ne ĵokeron, kaj legu la liston antaŭe kaj poste:

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

Konservitaj profilioj loĝas sub la ŝlosilo NetworkList en la registrejo, kie la valoro Category apartigas publikajn, privatajn kaj domajnajn retojn. Redakti ĝin eblas kaj facile erareblas: vi devas ŝanĝi la eron kongruan al la nuna subskribo de la adaptilo, ne pli malnovan eron lasitan de antaŭa adreso. Malnova ero aspektas ĝusta en la redaktilo kaj faras nenion ĉe rekonekto.

Kion ajn vi faras, ne liveru skripton, kiu agordas ĉiun neidentigitan adaptilon al Privata. Tio estas la unulinia versio de malfermi malkovron en nefidinda sendrata reto. Se vi bezonas kunhavigon nur kun la tunela subreto, konservu la profilon Publika kaj aldonu limigitajn envenantajn regulojn por la fora adresaro de la tunelo; la fajroŝirma regulo estas pli mallarĝa ol la kategorio.

Kontrolu la kunhavaĵon, ne la etikedon

Post la ŝanĝo, testu la rimedon mem anstataŭ fidi la etikedon:

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

Se la kunhavaĵo ankoraŭ malsukcesas dum la adaptilo montras Privata, la kategorio ne plu estas via problemo. Nomrezolvo, mankanta vojo aŭ kunhavigaj permesoj produktos la saman simptomon, kaj plia profila ŝanĝo ne povas ripari iun el ili. Rekonektu unufoje kaj rerulu Get-NetConnectionProfile por konfirmi, ke la agordo teniĝis, poste traktu la restan fiaskon kiel ordinaran SMB-problemon.

Kontrollisto: konfirmu, ke la tunelo estas administrita vojo, ke la profilo postvivas rekonekton, ke la privataj reguloj, kiujn vi bezonas, ekzistas en la bildo, kaj ke la kunhavaĵo rezolviĝas kaj respondas sur pordo 445. Se iu el la unuaj tri estas malvera, lasu la adaptilon sur Publika kaj solvu la aliran problemon per limigita regulo.