To VPN-klienter på én gang: hvem vinder standardruten?

At køre to VPN-klienter på én gang er en rutingsdiskussion, ikke en privathedsindstilling. Den tunnel, der ejer den mest specifikke rute, får trafikken, og den anden forbliver forbundet, men uvirksom. Den virksomhedsgateway ser så en forbindelse, der ankommer fra den personlige udgang, mens virksomhedsklienten på din maskine stadig ser hver adapter. At afgøre, hvilken af de to kendsgerninger der betyder noget, er hele øvelsen.

Rutetabellen vælger én vinder

Tag tabellen før og efter virksomhedsklienten starter, og læs interfacekolonnen i stedet for kun destinationen. En almindelig standardrute fra den ydre tunnel er let at fortrænge, fordi et /1-par er mere specifikt end /0. Det bogstavelige par 0.0.0.0/1 og 128.0.0.0/1 dækker hele IPv4-rummet i to halvdele og slår enhver enkelt standardrute. Når det er installeret, viser den ydre tunnel stadig forbundet og bærer intet.

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

Policy-routing kan tilsidesætte hovedtabellen helt, så læs både reglerne og ruterne. En regel, der sender markeret trafik til en anden tabel, vinder, før hovedtabellen overhovedet konsulteres. Det er sådan, en applikation kan blive på det fysiske link, mens alt andet bruger tunnelen.

ip rule show

Windows afgør det med metrikker

På Windows er vinderen den rute med den laveste metrik for destinationen, og to klienter kan begge installere en standardrute med forskellige metrikker. Læs tabellen og interfacekonfigurationen sammen, fordi adapteren med den lavere metrik ikke altid er den, du forventer. En klient, der også sætter en interfacemetrik, kan flytte standardruten uden at tilføje en enkelt rute. Den tabende adapter forbliver oppe og modtager simpelthen intet.

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

Sammenlign de to output og navngiv det interface, der ejer 0.0.0.0/0. Hvis begge klienter gør krav på det, afgør metrikken, og derfor kan en test af forbindelsesrækkefølgen se inkonsistent ud på tværs af maskiner. Hvis ingen af outputtene viser en standardgateway, kører klienten ikke full-tunnel, og kædeargumentet er uden betydning.

To observatører, to forskellige syn

Den fjernede gateway ser én forbindelse ankomme fra den ydre udgang plus alt, hvad klienten videresender til sin tunnel. Den lokale klient ser adaptere, ruter og eksistensen af en anden tunnel, fordi den kører med rettigheder til at oprette dem. At skille disse syn er pointen; at hævde, at klienten ikke kan bemærke det, er ikke.

Antag, at klienten kan opregne, hvad den vil, og planlæg i stedet for gatewayens syn. Et design, der afhænger af, at klienten forbliver blind, er én opdatering fra at bryde.

DNS og IPv6 er der, hvor kæden lækker

DNS følger den resolverindstilling, der vinder, og det er ikke nødvendigvis den vej, pakkerne tager. En virksomhedsresolver, der nås gennem virksomhedstunnelen, er konsistent med designet; en lokal resolver, der nås uden om den, er ikke, og den afslører navne, som tunnelen skulle skjule. IPv6 er den anden læk: en dual-stack-vært bliver ved med at bruge IPv6 mod destinationer, som tunnelen kun bærer over IPv4. Kontroller familierne hver for sig, fordi en IPv4-only-tunnel intet siger om IPv6-ruter eller -resolvere.

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

Ret resolveren og IPv6-ruten bevidst i stedet for at stable en anden tunnel ovenpå. Dobbelt indkapsling koster også MTU, så en mindre indre MTU er det første, du bør prøve, når siderne hænger, efter kæden er oppe. En resolver, der svarer hurtigt, er ikke bevis for, at den er den rigtige resolver.