Två VPN-klienter samtidigt: vem vinner standardrutten?

Att köra två VPN-klienter samtidigt är en routingdiskussion, inte en integritetsinställning. Den tunnel som äger den mer specifika rutten får trafiken, och den andra förblir ansluten men inaktiv. Företagsgatewayen ser då en anslutning som kommer från den personliga utgången, medan företagsklienten på din maskin fortfarande ser varje adapter. Att avgöra vilket av dessa två faktum som spelar roll är hela övningen.

Routtabellen väljer en enda vinnare

Fånga tabellen före och efter att företagsklienten startar, och läs gränssnittskolumnen i stället för bara destinationen. En vanlig standardrutt från den yttre tunneln är lätt att tränga undan, eftersom ett /1-par är mer specifikt än /0. Det bokstavliga paret 0.0.0.0/1 och 128.0.0.0/1 täcker hela IPv4-rymden i två halvor och slår varje enskild standardrutt. När det är installerat visas den yttre tunneln fortfarande som ansluten och bär ingenting.

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

Policyrouting kan åsidosätta huvudtabellen helt, så läs både reglerna och rutterna. En regel som skickar märkt trafik till en annan tabell vinner innan huvudtabellen ens konsulteras. Så kan en applikation stanna på den fysiska länken medan allt annat använder tunneln.

ip rule show

Windows avgör det med metrik

På Windows är vinnaren rutten med lägst metrik för destinationen, och två klienter kan båda installera en standardrutt med olika metrik. Läs tabellen och gränssnittskonfigurationen tillsammans, eftersom adaptern med lägre metrik inte alltid är den du förväntar dig. En klient som också sätter ett gränssnittsmetrik kan flytta standardrutten utan att lägga till en enda rutt. Adaptern som förlorar förblir på och tar helt enkelt emot ingenting.

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

Jämför de två utskrifterna och namnge gränssnittet som äger 0.0.0.0/0. Om båda klienterna gör anspråk på det avgör metrik, och därför kan ett test av anslutningsordningen se inkonsekvent ut mellan maskiner. Om ingen av utskrifterna visar en standardgateway körs klienten inte i full tunnel och kedjeargumentet är irrelevant.

Två observatörer, två olika vyer

Fjärrgatewayen ser en anslutning som kommer från den yttre utgången plus allt klienten vidarebefordrar in i sin tunnel. Den lokala klienten ser adaptrar, rutter och att det finns en annan tunnel, eftersom den körs med behörighet att skapa dem. Att skilja dessa vyer är poängen; att hävda att klienten inte kan märka det är det inte.

Anta att klienten kan räkna upp vad den vill, och planera i stället för gatewayens vy. En design som beror på att klienten förblir blind är en uppdatering från att gå sönder.

DNS och IPv6 är där kedjan läcker

DNS följer den resolverinställning som vinner, och det är inte nödvändigtvis den väg paketen tar. En företagsresolver som nås genom företagstunneln är förenlig med designen; en lokal resolver som nås utanför den är det inte, och den avslöjar namn som tunneln skulle dölja. IPv6 är den andra läckan: en dual-stack-värd fortsätter använda IPv6 mot destinationer som tunneln bara bär över IPv4. Kontrollera familjerna separat, eftersom en tunnel med bara IPv4 inte säger något om IPv6-rutter eller -resolvers.

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

Rätta resolvern och IPv6-rutten medvetet i stället för att stapla en andra tunnel ovanpå. Dubbel inkapsling kostar också MTU, så en mindre inre MTU är det första att prova när sidor hänger sig efter att kedjan är uppe. En resolver som svarar snabbt är inte bevis för att den är rätt.