Twee Windows-VPN’s gelyktydig: watter profiel hou die verstek?

Koppel die tweede tonnel in en die eerste word stil, terwyl albei kliënte steeds ’n gesonde verbinding rapporteer. Windows het net een verstekroete om weg te gee, en elke profiel wat daarop aanspraak maak, neem dit van die ander een af. Die simptoom lyk soos ’n VPN-onderbreking, maar dit is ’n roetewedstryd tussen twee profiele. Besluit watter tonnel daardie roete moet besit, en die res van die opstelling volg.

Net een inskrywing kan die beste verstek wees

Die IPv4-roetetabel hou slegs een wenroete vir bestemmings sonder ’n meer spesifieke passing. ’n VPN-profiel wat sy eie roete installeer, vervang die vorige een sodra dit koppel, en verkeer wat vroeër in die eerste tonnel ingegaan het, verlaat nou deur die tweede. Die eerste tonnel bly op; wat verdwyn, is enige pakkie wat dit vir algemene bestemmings sou gebruik het.

Kliëntstatusikone kan dit nie wys nie. Hulle rapporteer dat ’n tonnel gevestig is, nie watter prefikse nog daarnatoe roeteer nie, so die gebruiker sien twee groen ikone en ’n tyduit op ’n toepassing. Om route print -4 tydens die fout te lees, is meer insiggewend as enige VPN-log.

Naamresolusie is ’n tweede, onafhanklike konflik, en om net die roetetabel reg te maak, sal dit nie oplos nie.

Wat die merkblokkie installeer, en wat dit verwyder

Die opsie sit in elke VPN-profiel se adaptereienskappe onder IPv4-gevorderde instellings, geformuleer as die gebruik van die verstekpoort op die afgeleë netwerk. Geaktiveer, voeg elke verbinding ’n verstekroete deur die tonnel by en plaas daardie koppelvlak in die ry vir algemene verkeer. Gedeaktiveer, hou Windows die roete vir die tonnel se eie subnet en laat die res van die tabel alleen.

Dit is by die skoonmaak daarvan dat die meeste mense vashaak. Die afgeleë terrein het gewoonlik meer as een prefuks, en nie een van daardie prefikse is binne die adapter-subnet nie, so lêerbedieners en bestuursadresse hou op antwoord. Die merkblokkie het nie die tonnel gebreek nie; dit het die breë roete verwyder wat alles gedek het.

Gemengde opstellings is regmatig en algemeen: ’n korporatiewe profiel hou die merkblokkie as ’n volle tonnel, terwyl ’n laboratoriumprofiel gesplit is sodat dit nie die korporatiewe verstek kan verdring nie.

Kies volgens wat elke tonnel moet dra

Drie vrae bepaal die reëling. Moet hierdie tonnel gewone internetverkeer dra, of net adresse binne sy eie terrein? Gebruik die twee terreine onsamehangende private reekse? En as die profiel deur ’n werkgewer bestuur word, mag jy hoegenaamd aan sy roetegedrag verander?

As een tonnel vol moet wees, besit dit die verstek en die ander moet gesplit wees. As geen van die twee algemene internetverkeer nodig het nie, maak die merkblokkie op albei skoon en laat die fisiese adapter die verstek hou. As die reekse oorvleuel, stop: 172.22.0.0/16 kan nie een masjien aan die korporatiewe kant en ’n ander aan die laboratoriumkant beteken nie, en geen merkblokkie los dit op nie.

Teken die besluit langs die profielname aan. ’n Derde VPN wat volgende kwartaal bygevoeg word, sal andersins die ondersoek van die begin af herhaal.

Voeg die ontbrekende prefikse by en toets die resultaat

Voeg vir elke gesplete tonnel die afgeleë reekse eksplisiet by, met die eweknie-adres wat op daardie adapter gewys word eerder as die openbare bedieneradres:

> 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

’n PPP-adapter gebruik sy eweknie-adres as die volgende sprong, terwyl ’n TAP-adapter gewoonlik die poort gebruik wat op daardie koppelvlak gewys word, so lees die adapterbesonderhede eerder as om ’n nommer uit ’n gids te kopieer. Voeg die aanhoudende vlag eers by nadat die roete as korrek bewys is, en verwyder ou aanhoudende inskrywings voordat jy vervangings byvoeg. Bestuurde kliënte mag hul eie roetes installeer en beskerm, in welke geval die profieleienaar die verandering moet maak.

DNS het ’n aparte deurloop nodig. Albei tonnele kan oplossers stoot, en Windows hou ’n lys per koppelvlak met ’n voorkeurorde, so ’n naam wat aan die tweede netwerk behoort, kan na die eerste netwerk se oplosser gestuur word. Kyk wat elke adapter werklik ontvang het voordat jy ’n oplossing kies:

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

’n Naamresolusiebeleid per domein is gewoonlik beter as om die globale oplosserlys te vervang, want daardie lys word deur elke toepassing op die masjien gedeel en om dit stilweg te verander, verskuif onverwante opsoektogte.

Aanvaar die opstelling met vier kontroles: een hulpbron in elke afgeleë netwerk wat per adres bereik word, ’n naamsoektog in elkeen, die internetverstek wat nog na die fisiese adapter wys, en ’n afgeleë lessenaarsessie wat die tweede verbinding se opkoms oorleef.