Twee VPN-clients tegelijk: wie wint de standaardroute?

Twee VPN-clients tegelijk laten draaien is een routingdiscussie, geen privacy-instelling. De tunnel die de specifiekere route bezit, ontvangt het verkeer, en de andere blijft verbonden maar inactief. De bedrijfsgateway ziet dan een verbinding die van de persoonlijke uitgang komt, terwijl de bedrijfsclient op je machine nog steeds elke adapter ziet. Bepalen welke van die twee feiten ertoe doet, is de hele oefening.

De routetabel kiest één winnaar

Leg de tabel vast voor en nadat de bedrijfsclient start, en lees de interfacekolom in plaats van alleen de bestemming. Een gewone standaardroute uit de buitenste tunnel is makkelijk te verdringen, omdat een /1-paar specifieker is dan /0. Het letterlijke paar 0.0.0.0/1 en 128.0.0.0/1 dekt de hele IPv4-ruimte in twee helften en verslaat elke enkele standaardroute. Zodra het is geïnstalleerd, toont de buitenste tunnel nog steeds verbonden en draagt niets.

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

Policy-routing kan de hoofdtabel volledig overschrijven, dus lees zowel de regels als de routes. Een regel die gemarkeerd verkeer naar een andere tabel stuurt, wint voordat de hoofdtabel wordt geraadpleegd. Zo kan één applicatie op de fysieke link blijven terwijl al het andere de tunnel gebruikt.

ip rule show

Windows beslist het met metrieken

Op Windows is de winnaar de route met de laagste metriek voor de bestemming, en twee clients kunnen allebei een standaardroute met verschillende metrieken installeren. Lees de tabel en de interfaceconfiguratie samen, want de adapter met de lagere metriek is niet altijd degene die je verwacht. Een client die ook een interfacemetriek instelt, kan de standaard verplaatsen zonder één route toe te voegen. De adapter die verliest blijft aan en ontvangt eenvoudigweg niets.

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

Vergelijk de twee uitvoer en noem de interface die 0.0.0.0/0 bezit. Als beide clients er aanspraak op maken, beslist de metriek, waardoor een test van de verbindingsvolgorde op verschillende machines inconsistent kan lijken. Als geen van beide uitvoer een standaardgateway toont, draait de client niet in volledige tunnel en is het ketenargument zinloos.

Twee waarnemers, twee verschillende beelden

De externe gateway ziet één verbinding die van de buitenste uitgang komt, plus alles wat de client zijn tunnel in stuurt. De lokale client ziet adapters, routes en het bestaan van een andere tunnel, omdat hij met rechten draait om ze te maken. Die beelden scheiden is het punt; beweren dat de client het niet kan merken is dat niet.

Ga ervan uit dat de client kan opsommen wat hij wil, en plan in plaats daarvan voor het beeld van de gateway. Een ontwerp dat ervan afhangt dat de client blind blijft, is één update van breken verwijderd.

DNS en IPv6 zijn waar de keten lekt

DNS volgt welke resolverinstelling dan ook wint, en dat is niet noodzakelijk het pad dat de pakketten nemen. Een bedrijfsresolver die via de bedrijfstunnel wordt bereikt, is consistent met het ontwerp; een lokale resolver die daarbuiten wordt bereikt niet, en die legt namen bloot die de tunnel moest verbergen. IPv6 is het tweede lek: een dual-stackhost blijft IPv6 gebruiken naar bestemmingen die de tunnel alleen over IPv4 draagt. Controleer de families apart, want een tunnel met alleen IPv4 zegt niets over IPv6-routes of -resolvers.

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

Herstel de resolver en de IPv6-route bewust in plaats van een tweede tunnel erbovenop te stapelen. Dubbele inkapseling kost ook MTU, dus een kleinere interne MTU is het eerste dat je moet proberen wanneer pagina's vastlopen nadat de keten omhoog is. Een resolver die snel antwoordt, is geen bewijs dat het de juiste is.