To Windows-VPN-ar samstundes: kva profil held på standardruta?

Kople til den andre tunnelen, og den første blir stille, medan begge klientane framleis rapporterer ei sunn tilkopling. Windows har berre éi standardrute å gje, og kvar profil som krev henne, tek henne frå den andre. Symptomet ser ut som eit VPN-avbrot, men det er ein rutekamp mellom to profilar. Avgjer kva tunnel som skal eige den ruta, og resten av konfigurasjonen følgjer.

Berre éin oppføring kan vere den beste standardruta

IPv4-rutetabellen held éi einaste vinnande rute for destinasjonar utan eit meir spesifikt treff. Ein VPN-profil som installerer si eiga, erstattar den førre straks han koplar til, og trafikk som før gjekk inn i den første tunnelen, går no ut gjennom den andre. Den første tunnelen blir ståande; det som forsvinn, er kvar pakke som ville ha brukt han til generelle destinasjonar.

Klientstatusikon kan ikkje vise det. Dei rapporterer at ein tunnel vart etablert, ikkje kva prefiks som framleis blir ruta dit, så brukaren ser to grøne ikon og ein tidsavbrot i ein applikasjon. Å lese route print -4 under feilen er meir informativt enn kva VPN-logg som helst.

Namneoppslag er ein andre, uavhengig konflikt, og å rette berre rutetabellen vil ikkje løyse han.

Kva hakefeltet installerer, og kva det fjernar

Alternativet ligg i adaptereigenskapane til kvar VPN-profil under avanserte IPv4-innstillingar, formulert som bruk av standardgatewayen på fjernnettverket. Slått på legg kvar tilkopling til ei standardrute gjennom tunnelen og set det grensesnittet i køen for generell trafikk. Slått av held Windows på ruta for tunnelens eige subnett og lèt resten av tabellen vere i fred.

Det er ved å fjerne haka at dei fleste blir sitjande fast. Fjernstaden har vanlegvis meir enn eitt prefiks, og ingen av desse prefiksa ligg i subnettet til adapteren, så filtenarar og administrasjonsadresser sluttar å svare. Haka øydela ikkje tunnelen; ho fjerna den breie ruta som hadde dekt alt.

Blanda konfigurasjonar er legitime og vanlege: ein bedriftsprofil held haka som full tunnel, medan ein laboratorieprofil er delt slik at han ikkje kan fortrenge bedriftsstandarden.

Vel etter kva kvar tunnel må bere

Tre spørsmål avgjer oppsettet. Må denne tunnelen bere vanleg internettrafikk, eller berre adresser inne i sin eigen stad? Brukar dei to stadene skilde private område? Og om profilen blir administrert av ein arbeidsgjevar, har du i det heile lov til å endre ruteåtferda hans?

Om éin tunnel må vere full, eig han standardruta, og den andre må vere delt. Om ingen av dei treng generell internettrafikk, fjern haka på begge og læt den fysiske adapteren halde på standardruta. Om områda overlappar, stopp: 172.22.0.0/16 kan ikkje bety éi maskin på bedriftssida og ei anna på laboratoriesida, og ingen hake løyser det.

Skriv avgjerda ved sida av profilnamna. Elles vil ein tredje VPN lagd til neste kvartal gjenta granskinga frå byrjinga.

Legg til dei manglande prefiksa og test resultatet

For kvar delt tunnel, legg til fjernområda eksplisitt, og bruk partnaradressa som blir vist på den adapteren i staden for den offentlege serveradressa:

> 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

Ein PPP-adapter brukar partnaradressa som neste hopp, medan ein TAP-adapter vanlegvis brukar gatewayen som blir vist på det grensesnittet, så les adapterdetaljane i staden for å kopiere eit tal frå ein rettleiar. Legg til det vedvarande flagget først etter at ruta har vist seg rett, og slett gamle vedvarande oppføringar før du legg til erstatningar. Administrerte klientar kan installere og verne sine eigne ruter, og då må profileigaren gjere endringa.

DNS treng ein eigen runde. Begge tunnelane kan skyve resolvarar, og Windows held ei liste per grensesnitt med ein preferanserekkjefølgje, så eit namn som høyrer til det andre nettverket kan bli sendt til resolvaren til det første. Sjå kva kvar adapter faktisk fekk før du vel ei løysing:

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

Ein namneoppslagspolicy per domene er vanlegvis betre enn å erstatte den globale resolvarlista, fordi den lista blir delt av kvar applikasjon på maskina, og ei stille endring flyttar urelaterte oppslag.

Godta oppsettet med fire kontrollar: éin ressurs i kvart fjernnettverk nådd via adresse, eit namneoppslag i kvart, internettstandarden peikar framleis på den fysiske adapteren, og ein ekstern skrivebordøkt som overlever at den andre tilkoplinga kjem opp.