To Windows-VPN-er samtidig: hvilken profil beholder standardruten?

Koble til den andre tunnelen, og den første blir stille, mens begge klientene fortsatt rapporterer en sunn forbindelse. Windows har bare én standardrute å gi, og hver profil som krever den, tar den fra den andre. Symptomet ser ut som et VPN-avbrudd, men det er en rutekamp mellom to profiler. Bestem hvilken tunnel som skal eie den ruten, og resten av konfigurasjonen følger.

Bare én oppføring kan være den beste standardruten

IPv4-rutetabellen holder én enkelt vinnende rute for destinasjoner uten en mer spesifikk treff. En VPN-profil som installerer sin egen, erstatter den forrige så snart den kobler til, og trafikk som før gikk inn i den første tunnelen, går nå ut gjennom den andre. Den første tunnelen blir stående; det som forsvinner, er enhver pakke som ville ha brukt den til generelle destinasjoner.

Klientstatusikoner kan ikke vise det. De rapporterer at en tunnel ble etablert, ikke hvilke prefikser som fortsatt rutes dit, så brukeren ser to grønne ikoner og en tidsavbrudd i en applikasjon. Å lese route print -4 under feilen er mer informativt enn noen VPN-logg.

Navneoppslag er en andre, uavhengig konflikt, og å rette bare rutetabellen vil ikke løse den.

Hva haket installerer, og hva det fjerner

Alternativet ligger i hver VPN-profils adapteregenskaper under avanserte IPv4-innstillinger, formulert som bruk av standardgatewayen på fjernnettverket. Slått på legger hver tilkobling til en standardrute gjennom tunnelen og setter det grensesnittet i køen for generell trafikk. Slått av beholder Windows ruten for tunnelens eget subnett og lar resten av tabellen være i fred.

Det er ved å fjerne haket at de fleste blir sittende fast. Fjernstedet har vanligvis mer enn ett prefiks, og ingen av disse prefiksene ligger i adapterens subnett, så filservere og administrasjonsadresser slutter å svare. Haket ødela ikke tunnelen; det fjernet den brede ruten som hadde dekket alt.

Blandede konfigurasjoner er legitime og vanlige: en bedriftsprofil beholder haket som full tunnel, mens en laboratorieprofil er delt slik at den ikke kan fortrenge bedriftens standardrute.

Velg etter hva hver tunnel må bære

Tre spørsmål avgjør oppsettet. Må denne tunnelen bære vanlig internettrafikk, eller bare adresser inne i sitt eget nettsted? Bruker de to stedene atskilte private områder? Og hvis profilen administreres av en arbeidsgiver, har du i det hele tatt lov til å endre ruteoppførselen?

Hvis én tunnel må være full, eier den standardruten, og den andre må være delt. Hvis ingen av dem trenger generell internettrafikk, fjern haket på begge og la den fysiske adapteren beholde standardruten. Hvis områdene overlapper, stopp: 172.22.0.0/16 kan ikke bety én maskin på bedriftssiden og en annen på laboratoriesiden, og ingen hakeløsning avgjør det.

Skriv ned beslutningen ved siden av profilnavnene. Ellers vil en tredje VPN lagt til neste kvartal gjenta undersøkelsen fra begynnelsen.

Legg til de manglende prefiksene og test resultatet

For hver delt tunnel, legg til fjernområdene eksplisitt, og bruk partneradressen som vises på den adapteren i stedet for serverens offentlige adresse:

> 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

En PPP-adapter bruker partneradressen som neste hopp, mens en TAP-adapter vanligvis bruker gatewayen som vises på det grensesnittet, så les adapterdetaljene i stedet for å kopiere et tall fra en veiledning. Legg til det vedvarende flagget først etter at ruten har vist seg riktig, og slett gamle vedvarende oppføringer før du legger til erstatninger. Administrerte klienter kan installere og beskytte sine egne ruter, og da må profileieren gjøre endringen.

DNS trenger en egen runde. Begge tunnelene kan skyve resolvere, og Windows holder en liste per grensesnitt med en preferanserekkefølge, så et navn som hører til det andre nettverket kan bli sendt til det første nettverkets resolver. Se hva hver adapter faktisk mottok før du velger en løsning:

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

En navneoppslagspolicy per domene er vanligvis bedre enn å erstatte den globale resolverlisten, fordi den listen deles av hver applikasjon på maskinen, og en stille endring flytter urelaterte oppslag.

Godta oppsettet med fire kontroller: én ressurs i hvert fjernnettverk nådd via adresse, et navneoppslag i hver, internettstandarden peker fortsatt på den fysiske adapteren, og en eksternt skrivebord-økt som overlever at den andre tilkoblingen kommer opp.