Du Windows-VPN-oj samtempe: kiu profilo retenas la defaŭltan itineron?

Enŝovu la duan tunelon kaj la unua silentas, dum ambaŭ klientoj ankoraŭ raportas sanan konekton. Windows havas nur unu defaŭltan itineron por doni, kaj ĉiu profilo, kiu postulas ĝin, prenas ĝin de la alia. La simptomo aspektas kiel paneo de VPN, sed ĝi estas itinera konkurado inter du profiloj. Decidu, kiu tunelo rajtas posedi tiun itineron, kaj la resto de la agordo sekvas.

Nur unu ero povas esti la plej bona defaŭlto

La IPv4-itinera tabelo tenas ununuran venkan itineron por celoj sen pli specifa kongruo. Profilo de VPN, kiu instalas sian propran, anstataŭigas la antaŭan tuj kiam ĝi konektiĝas, kaj trafiko, kiu antaŭe eniris la unuan tunelon, eliras nun tra la dua. La unua tunelo restas aktiva; malaperas ĉiu paketo, kiu uzus ĝin por ĝeneralaj celoj.

Statusaj ikonoj de la kliento ne povas montri tion. Ili raportas, ke tunelo estis starigita, ne kiuj prefiksoj ankoraŭ itiniras al ĝi, do la uzanto vidas du verdajn ikonojn kaj tempolimon en programo. Legi route print -4 dum la paneo estas pli informe ol iu ajn VPN-protokolo.

Nomtraduko estas dua, sendependa konflikto, kaj ripari nur la itineran tabelon ne solvos ĝin.

Kion la markobutono instalas kaj kion ĝi forigas

La opcio troviĝas en la adaptilaj propraĵoj de ĉiu profilo de VPN sub la altnivelaj agordoj de IPv4, formulita kiel uzi la defaŭltan enirejon en la fora reto. Ŝaltita, ĉiu konekto aldonas defaŭltan itineron tra la tunelo kaj starigas tiun interfacon en la vicon por ĝenerala trafiko. Malŝaltita, Windows konservas la itineron por la propra subreto de la tunelo kaj lasas la reston de la tabelo trankvila.

Ĝuste ĉe forigo de la markobutono plej multaj homoj blokiĝas. La fora ejo kutime havas pli ol unu prefikson, kaj neniu el tiuj prefiksoj estas ene de la adaptila subreto, do dosieraj serviloj kaj administraj adresoj ĉesas respondi. La markobutono ne rompis la tunelon; ĝi forigis la larĝan itineron, kiu kovris ĉion.

Miksitaj agordoj estas legitimaj kaj oftaj: entreprena profilo tenas la markobutonon kiel plenan tunelon, dum laboratoria profilo estas dividita, por ke ĝi ne povu anstataŭigi la entreprenan defaŭlton.

Elektu laŭ tio, kion ĉiu tunelo devas porti

Tri demandoj decidas la aranĝon. Ĉu ĉi tiu tunelo devas porti ordinaran interretan trafikon, aŭ nur adresojn ene de sia propra ejo? Ĉu la du ejoj uzas disajn privatajn gamojn? Kaj se la profilon administras dunganto, ĉu vi rajtas entute ŝanĝi ĝian itineran konduton?

Se unu tunelo devas esti plena, ĝi posedas la defaŭlton kaj la alia devas esti dividita. Se neniu bezonas ĝeneralan interretan trafikon, forigu la markobutonon en ambaŭ kaj lasu la fizikan adaptilon teni la defaŭlton. Se la gamoj interkovriĝas, haltu: 172.22.0.0/16 ne povas signifi unu maŝinon ĉe la entreprena flanko kaj alian ĉe la laboratoria flanko, kaj neniu markobutono solvas tion.

Notu la decidon apud la profilaj nomoj. Alie tria VPN aldonota venontkvarjare ripetos la esploradon de la komenco.

Aldonu la mankantajn prefiksojn kaj testu la rezulton

Por ĉiu dividita tunelo, aldonu la forajn gamojn eksplicite, uzante la samtavolan adreson montratan sur tiu adaptilo anstataŭ la publika adreso de la servilo:

> route add 172.22.0.0 mask 255.255.0.0 172.20.4.1
> route print -4
> Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric

Adaptilo PPP uzas sian samtavolan adreson kiel sekvan salton, dum adaptilo TAP kutime uzas la enirejon montratan sur tiu interfaco, do legu la adaptilajn detalojn anstataŭ kopii numeron el gvidilo. Aldonu la daŭrecan flagon nur post kiam la itinero pruviĝis ĝusta, kaj forigu malnovajn daŭrecajn erojn antaŭ ol aldoni anstataŭaĵojn. Administrataj klientoj povas instali kaj protekti siajn proprajn itinerojn, kaj tiam la posedanto de la profilo devas fari la ŝanĝon.

DNS postulas apartan trairon. Ambaŭ tuneloj povas puŝi tradukilojn, kaj Windows tenas liston por ĉiu interfaco kun prefera ordo, do nomo apartenanta al la dua reto povas esti sendita al la tradukilo de la unua reto. Rigardu, kion ĉiu adaptilo efektive ricevis, antaŭ ol elekti riparon:

> Get-DnsClientServerAddress -AddressFamily IPv4
> Resolve-DnsName files.corp.internal -Server 172.20.4.1

Politiko de nomtraduko por ĉiu domajno kutime pli bonas ol anstataŭigi la tutmondan tradukilan liston, ĉar tiun liston dividas ĉiu programo en la maŝino kaj silenta ŝanĝo movas nerilatajn serĉojn.

Akceptu la agordon per kvar kontroloj: unu rimedo en ĉiu fora reto atingebla per adreso, nomserĉo en ĉiu el ili, la interreta defaŭlto ankoraŭ montras al la fizika adaptilo, kaj fora labortabla seanco, kiu postvivas la ekfunkcion de la dua konekto.