To VPN-klientar samstundes: kven vinn standardruta?

Å køyre to VPN-klientar samstundes er ein rutingsdiskusjon, ikkje ein personvernsinnstilling. Den tunnelen som eig den meir spesifikke ruta, får trafikken, og den andre blir ståande tilkopla men ledig. Bedriftsgatewayen ser då ein tilkopling som kjem frå den personlege utgangen, medan bedriftsklienten på maskina di framleis ser kvar adapter. Å avgjere kva av desse to kjensgjerningane som betyr noko, er heile øvinga.

Rutetabellen vel éin vinnar

Ta opp tabellen før og etter at bedriftsklienten startar, og les grensesnittkolonnen i staden for berre målet. Ei vanleg standardrute frå den ytre tunnelen er lett å fortrenge, fordi eit /1-par er meir spesifikt enn /0. Det bokstavelege paret 0.0.0.0/1 og 128.0.0.0/1 dekkjer heile IPv4-rommet i to halvdelar og slår kvar einskild standardrute. Når det er installert, viser den ytre tunnelen framleis tilkopla og ber ingenting.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

Policy-ruting kan overstyre hovudtabellen heilt, så les både reglane og rutene. Ein regel som sender merkt trafikk til ein annan tabell, vinn før hovudtabellen i det heile blir rådspurd. Slik kan éin applikasjon bli på den fysiske lenkja medan alt anna brukar tunnelen.

ip rule show

Windows avgjer det med metrikkar

På Windows er vinnaren ruta med lågast metrikk for målet, og to klientar kan begge installere ei standardrute med ulike metrikkar. Les tabellen og grensesnittkonfigurasjonen saman, fordi adapteren med lågare metrikk ikkje alltid er den du ventar. Ein klient som òg set ein grensesnittmetrikk, kan flytte standardruta utan å leggje til ei einaste rute. Adapteren som tapar, blir ståande på og mottar rett og slett ingenting.

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

Samanlikn dei to utdata og namngje grensesnittet som eig 0.0.0.0/0. Viss begge klientane krev det, avgjer metrikken, og difor kan ein test av tilkoplingsrekkjefølgja sjå inkonsistent ut på tvers av maskiner. Viss ingen av utdata viser ein standardgateway, køyrer ikkje klienten i full tunnel, og argumentet om kjeda fell bort.

To observatørar, to ulike syn

Den eksterne gatewayen ser éin tilkopling som kjem frå den ytre utgangen, pluss alt klienten videresender inn i tunnelen sin. Den lokale klienten ser adapterar, ruter og at det finst ein annan tunnel, fordi han køyrer med rettar til å opprette dei. Å skilje desse syna er poenget; å hevde at klienten ikkje kan merke det, er det ikkje.

Gå ut frå at klienten kan liste opp kva han vil, og planlegg for synet til gatewayen i staden. Eit design som er avhengig av at klienten blir blind, er éi oppdatering unna å bryte saman.

DNS og IPv6 er der kjeda lek

DNS følgjer den resolvaren som vinn, og det er ikkje nødvendigvis vegen pakkane tek. Ein bedriftsresolvar som blir nådd gjennom bedriftstunnelen, er i tråd med designet; ein lokal resolvar som blir nådd utanfor, er det ikkje, og han avdekkjer namn tunnelen skulle skjule. IPv6 er den andre lekkasjen: ein dual-stack-vert held fram med å bruke IPv6 mot mål som tunnelen berre fraktar over IPv4. Sjekk familiane kvar for seg, fordi ein tunnel med berre IPv4 ikkje seier noko om IPv6-ruter eller -resolvarar.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

Rett opp resolvaren og IPv6-ruta med vilje i staden for å stable ein annan tunnel oppå. Dobbel innkapsling kostar òg MTU, så ein mindre indre MTU er det første du bør prøve når sidene heng etter at kjeda er oppe. Ein resolvar som svarar raskt, er ikkje bevis for at han er den rette.