To Windows-VPN’er på én gang: hvilken profil beholder standardruten?

Tilslut den anden tunnel, og den første bliver tavs, mens begge klienter stadig rapporterer en sund forbindelse. Windows har kun én standardrute at give, og hver profil, der kræver den, tager den fra den anden. Symptomet ligner et VPN-nedbrud, men det er en rutekamp mellem to profiler. Beslut, hvilken tunnel der skal eje den rute, og resten af konfigurationen følger.

Kun én post kan være den bedste standardrute

IPv4-rutetabellen rummer én enkelt vindende rute til destinationer uden et mere specifikt match. En VPN-profil, der installerer sin egen, erstatter den foregående, så snart den opretter forbindelse, og trafik, der plejede at gå ind i den første tunnel, forlader nu gennem den anden. Den første tunnel forbliver oppe; det, der forsvinder, er enhver pakke, der ville have brugt den til generelle destinationer.

Klientstatusikoner kan ikke vise det. De rapporterer, at en tunnel blev etableret, ikke hvilke præfikser der stadig ruter mod den, så brugeren ser to grønne ikoner og en timeout i en applikation. At læse route print -4 under fejlen er mere informativt end enhver VPN-log.

Navneopløsning er en anden, uafhængig konflikt, og det løser den ikke kun at rette rutetabellen.

Hvad hakket installerer, og hvad det fjerner

Indstillingen findes i hver VPN-profils adapteregenskaber under avancerede IPv4-indstillinger, formuleret som brug af standardgatewayen på fjernnetværket. Aktiveret tilføjer hver forbindelse en standardrute gennem tunnelen og stiller den grænseflade i kø til generel trafik. Deaktiveret beholder Windows ruten til tunnelens eget undernet og lader resten af tabellen være.

Det er ved at fjerne hakket, at de fleste går i stå. Fjernstedet har normalt mere end ét præfiks, og ingen af disse præfikser ligger inden for adapterens undernet, så filservere og administrationsadresser holder op med at svare. Hakket brød ikke tunnelen; det fjernede den brede rute, der havde dækket alt.

Blandede konfigurationer er legitime og almindelige: en virksomhedsprofil beholder hakket som fuld tunnel, mens en laboratorieprofil er opdelt, så den ikke kan fortrænge virksomhedens standardrute.

Vælg efter, hvad hver tunnel skal bære

Tre spørgsmål afgør opstillingen. Skal denne tunnel bære almindelig internettrafik, eller kun adresser inde i dens eget område? Bruger de to områder adskilte private intervaller? Og hvis profilen administreres af en arbejdsgiver, har du så overhovedet lov til at ændre dens ruteadfærd?

Hvis én tunnel skal være fuld, ejer den standardruten, og den anden skal være opdelt. Hvis ingen af dem har brug for generel internettrafik, fjern hakket på begge og lad den fysiske adapter beholde standardruten. Hvis intervallerne overlapper, stop: 172.22.0.0/16 kan ikke betyde én maskine på virksomhedssiden og en anden på laboratoriesiden, og intet hak løser det.

Skriv beslutningen ved siden af profilnavnene. Ellers gentager en tredje VPN, der tilføjes næste kvartal, undersøgelsen fra begyndelsen.

Tilføj de manglende præfikser, og test resultatet

Tilføj fjernintervallerne eksplicit for hver opdelt tunnel, og brug peer-adressen, der vises på den adapter, 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 bruger sin peer-adresse som næste hop, mens en TAP-adapter normalt bruger gatewayen, der vises på den grænseflade, så læs adapteroplysningerne i stedet for at kopiere et tal fra en vejledning. Tilføj det persistente flag først, når ruten har vist sig korrekt, og slet gamle persistente poster, før du tilføjer erstatninger. Administrerede klienter kan installere og beskytte deres egne ruter, og så skal profilejeren foretage ændringen.

DNS kræver en separat gennemgang. Begge tunneler kan skubbe resolvere, og Windows holder en liste per grænseflade med en præferenceorden, så et navn, der hører til det andet netværk, kan blive sendt til det første netværks resolver. Se, hvad hver adapter faktisk modtog, før du vælger en løsning:

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

En navneopløsningspolitik per domæne er normalt bedre end at erstatte den globale resolverliste, fordi den liste deles af alle programmer på maskinen, og en stille ændring flytter urelaterede opslag.

Accepter opsætningen med fire kontroller: én ressource i hvert fjernnetværk nået via adresse, et navneopslag i hver, internetstandardruten peger stadig på den fysiske adapter, og en fjernskrivebordssession, der overlever, at den anden forbindelse kommer op.