To VPN-klienter samtidig: hvem vinner standardruten?

Å kjøre to VPN-klienter samtidig er en rutingsdiskusjon, ikke en personverninnstilling. Den tunnelen som eier den mer spesifikke ruten, får trafikken, og den andre blir stående tilkoblet men ledig. Bedriftsgatewayen ser da en tilkobling som kommer fra den personlige utgangen, mens bedriftsklienten på maskinen din fortsatt ser hver adapter. Å avgjøre hvilken av disse to kjensgjerningene som betyr noe, er hele øvelsen.

Rutetabellen velger én vinner

Ta opp tabellen før og etter at bedriftsklienten starter, og les grensesnittkolonnen i stedet for bare målet. En vanlig standardrute fra den ytre tunnelen er lett å fortrenge, fordi et /1-par er mer spesifikt enn /0. Det bokstavelige paret 0.0.0.0/1 og 128.0.0.0/1 dekker hele IPv4-rommet i to halvdeler og slår enhver enkelt standardrute. Når det er installert, viser den ytre tunnelen fortsatt tilkoblet og bærer ingenting.

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

Policy-ruting kan overstyre hovedtabellen helt, så les både reglene og rutene. En regel som sender merket trafikk til en annen tabell, vinner før hovedtabellen i det hele tatt blir konsultert. Slik kan én applikasjon bli på den fysiske lenken mens alt annet bruker tunnelen.

ip rule show

Windows avgjør det med metrikker

På Windows er vinneren ruten med lavest metrikk for målet, og to klienter kan begge installere en standardrute med ulike metrikker. Les tabellen og grensesnittkonfigurasjonen sammen, fordi adapteren med lavere metrikk ikke alltid er den du forventer. En klient som også setter en grensesnittmetrikk, kan flytte standardruten uten å legge til en eneste rute. Adapteren som taper, blir stående på og mottar rett og slett ingenting.

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

Sammenlign de to utdataene og navngi grensesnittet som eier 0.0.0.0/0. Hvis begge klientene krever det, avgjør metrikken, og derfor kan en test av tilkoblingsrekkefølgen se inkonsistent ut på tvers av maskiner. Hvis ingen av utdataene viser en standardgateway, kjører ikke klienten i full tunnel, og argumentet om kjeden faller bort.

To observatører, to forskjellige syn

Den eksterne gatewayen ser én tilkobling som kommer fra den ytre utgangen, pluss alt klienten videresender inn i tunnelen sin. Den lokale klienten ser adaptere, ruter og at det finnes en annen tunnel, fordi den kjører med rettigheter til å opprette dem. Å skille disse synene er poenget; å hevde at klienten ikke kan merke det, er det ikke.

Anta at klienten kan liste opp hva den vil, og planlegg for gatewayens syn i stedet. Et design som avhenger av at klienten forblir blind, er én oppdatering unna å bryte sammen.

DNS og IPv6 er der kjeden lekker

DNS følger den resolverinnstillingen som vinner, og det er ikke nødvendigvis veien pakkene tar. En bedriftsresolver som nås gjennom bedriftstunnelen, er i tråd med designet; en lokal resolver som nås utenfor den, er det ikke, og den avslører navn tunnelen skulle skjule. IPv6 er den andre lekkasjen: en dual-stack-vert fortsetter å bruke IPv6 mot mål som tunnelen bare frakter over IPv4. Sjekk familiene hver for seg, fordi en tunnel med bare IPv4 ikke sier noe om IPv6-ruter eller -resolvere.

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

Rett opp resolveren og IPv6-ruten med vilje i stedet for å stable en annen tunnel oppå. Dobbel innkapsling koster også MTU, så en mindre indre MTU er det første du bør prøve når sidene henger etter at kjeden er oppe. En resolver som svarer raskt, er ikke bevis for at den er den riktige.