Du Windows VPN vienu metu: kuris profilis išlaiko numatytąjį maršrutą?

Prijunkite antrą tunelį ir pirmasis nutyla, nors abu klientai vis dar praneša apie sveiką ryšį. Windows turi duoti tik vieną numatytąjį maršrutą, ir kiekvienas profilis, kuris jo reikalauja, atima jį iš kito. Simptomas atrodo kaip VPN gedimas, bet tai maršrutų varžybos tarp dviejų profilių. Nuspręskite, kuris tunelis turi valdyti tą maršrutą, ir likusi konfigūracija seks paskui.

Tik vienas įrašas gali būti geriausias numatytasis

IPv4 maršrutų lentelė laiko vieną nugalėjusį maršrutą paskirties vietoms, neturinčioms konkretesnio atitikmens. VPN profilis, įdiegiantis savąjį, pakeičia ankstesnį vos prisijungęs, o srautas, kuris anksčiau įeidavo į pirmą tunelį, dabar išeina per antrą. Pirmas tunelis lieka aktyvus; dingsta bet koks paketas, kuris būtų jį naudojęs bendroms paskirtims.

Kliento būsenos piktogramos to parodyti negali. Jos praneša, kad tunelis buvo nustatytas, o ne kurie priešdėliai dar nukreipiami į jį, todėl vartotojas mato dvi žalias piktogramas ir laukimo pabaigą kažkurioje programoje. route print -4 skaitymas gedimo metu informatyvesnis už bet kokį VPN žurnalą.

Vardų sprendimas yra antras, nepriklausomas konfliktas, ir vien maršrutų lentelės taisymas jo neišspręs.

Ką žymimasis langelis įdiegia ir ką pašalina

Parinktis yra kiekvieno VPN profilio adapterio ypatybėse, išplėstiniuose IPv4 nustatymuose, ir suformuluota kaip numatytojo šliuzo naudojimas nuotoliniame tinkle. Įjungta, kiekvienas ryšys prideda numatytąjį maršrutą per tunelį ir įstato tą sąsają į bendro srauto eilę. Išjungta, Windows palieka tunelio paties potinklės maršrutą ir nejudina likusios lentelės.

Būtent nuimant žymimąjį langelį dauguma žmonių įstringa. Nuotolinėje vietoje paprastai yra daugiau nei vienas priešdėlis, ir nė vienas iš jų nėra adapterio potinklėje, todėl failų serveriai ir valdymo adresai nustoja atsakinėti. Žymimasis langelis nesugadino tunelio; jis pašalino platųjį maršrutą, kuris buvo viską apėmęs.

Mišrios konfigūracijos yra teisėtos ir įprastos: įmonės profilis palieka žymimąjį langelį kaip pilną tunelį, o laboratorijos profilis yra skaidomas, kad negalėtų išstumti įmonės numatytojo.

Rinkitės pagal tai, ką kiekvienas tunelis turi perduoti

Trys klausimai nulemia išdėstymą. Ar šis tunelis turi perduoti įprastą interneto srautą, ar tik savo svetainės viduje esančius adresus? Ar abi vietos naudoja nesusikertančius privačius diapazonus? Ir jei profilį valdo darbdavys, ar jums apskritai leidžiama keisti jo maršrutizavimo elgseną?

Jei vienas tunelis turi būti pilnas, jis valdo numatytąjį, o kitas turi būti skaidomas. Jei nė vienam nereikia bendro interneto srauto, nuimkite žymimąjį langelį abiejuose ir leiskite fiziniam adapteriui išlaikyti numatytąjį. Jei diapazonai persidengia, sustokite: 172.22.0.0/16 negali reikšti vienos mašinos įmonės pusėje ir kitos laboratorijos pusėje, ir joks žymimasis langelis to neišspręs.

Užrašykite sprendimą prie profilių pavadinimų. Priešingu atveju trečias VPN, pridėtas kitą ketvirtį, pakartos tyrimą nuo pradžių.

Pridėkite trūkstamus priešdėlius ir patikrinkite rezultatą

Kiekvienam skaidomam tuneliui aiškiai pridėkite nuotolinius diapazonus, naudodami tame adapteryje rodomą partnerio adresą, o ne viešą serverio adresą:

> 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

PPP adapteris naudoja savo partnerio adresą kaip kitą šuolį, o TAP adapteris paprastai naudoja toje sąsajoje rodomą šliuzą, todėl skaitykite adapterio duomenis, o ne kopijuokite skaičių iš vadovo. Nuolatinę vėliavėlę pridėkite tik tada, kai maršrutas įrodytas kaip teisingas, o senus nuolatinius įrašus ištrinkite prieš pridėdami pakaitalus. Valdomi klientai gali įdiegti ir apsaugoti savo maršrutus, ir tokiu atveju pakeitimą turi atlikti profilio savininkas.

DNS reikia atskiro ėjimo. Abu tuneliai gali stumti resolverius, o Windows laiko sąsajai skirtą sąrašą su pirmumo tvarka, todėl antrojo tinklo vardas gali būti nusiųstas pirmojo tinklo resolveriui. Prieš rinkdamiesi sprendimą pažiūrėkite, ką kiekvienas adapteris iš tikrųjų gavo:

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

Domenui skirtos vardų sprendimo taisyklės paprastai geresnės už pasaulinio resolverių sąrašo pakeitimą, nes tą sąrašą dalijasi kiekviena mašinoje esanti programa, o tylus jo pakeitimas perstumia nesusijusias užklausas.

Priimkite sąranką su keturiais patikrinimais: vienas išteklius kiekviename nuotoliniame tinkle, pasiekiamas adresu, vardų paieška kiekviename, interneto numatytasis vis dar rodo į fizinį adapterį, ir nuotolinio darbalaukio sesija, kuri išlieka antram ryšiui atsistačius.