Dos clients VPN alhora: qui guanya la ruta per defecte?
Dos clients VPN reclamen la ruta per defecte i només un guanya. Llegeix la mètrica, la parella /1 i la divisió del resolutor abans de triar un ordre de túnels.
Executar dos clients VPN alhora és una discussió d’encaminament, no un paràmetre de privadesa. El túnel que posseeix la ruta més específica rep el trànsit, i l’altre queda connectat però inactiu. La passarel·la corporativa veu llavors una connexió que arriba des de la sortida personal, mentre que el client corporatiu de la teva màquina encara veu tots els adaptadors. Decidir quina d’aquestes dues dades importa és tot l’exercici.
La taula d’encaminament tria un sol guanyador
Captura la taula abans i després que arrenqui el client corporatiu, i llegeix la columna d’interfície en lloc de només la destinació. Una ruta per defecte simple del túnel exterior és fàcil de desplaçar, perquè una parella /1 és més específica que /0. La parella literal 0.0.0.0/1 i 128.0.0.0/1 cobreix tot l’espai IPv4 en dues meitats i supera qualsevol ruta per defecte única. Un cop instal·lada, el túnel exterior encara es mostra connectat i no transporta res.
ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'L’encaminament per política pot anul·lar completament la taula principal, així que llegeix tant les regles com les rutes. Una regla que envia el trànsit marcat a una altra taula guanya abans que es consulti la taula principal. Així és com una aplicació pot quedar-se a l’enllaç físic mentre tota la resta fa servir el túnel.
ip rule showWindows ho decideix amb mètriques
A Windows, el guanyador és la ruta amb la mètrica més baixa per a la destinació, i dos clients poden instal·lar tots dos una ruta per defecte amb mètriques diferents. Llegeix la taula i la configuració de la interfície alhora, perquè l’adaptador amb la mètrica més baixa no sempre és el que esperes. Un client que també fixa una mètrica d’interfície pot moure la ruta per defecte sense afegir ni una sola ruta. L’adaptador que perd es queda encesa i simplement no rep res.
route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGatewayCompara les dues sortides i anomena la interfície que posseeix 0.0.0.0/0. Si tots dos clients la reclamen, decideix la mètrica, i per això una prova d’ordre de connexió pot semblar inconsistent entre màquines. Si cap de les dues sortides mostra una passarel·la per defecte, el client no funciona en túnel complet i l’argument de la cadena queda sense sentit.
Dos observadors, dues visions diferents
La passarel·la remota veu una connexió que arriba des de la sortida exterior més tot el que el client reenvia al seu túnel. El client local veu adaptadors, rutes i l’existència d’un altre túnel, perquè s’executa amb privilegis per crear-los. Separar aquestes visions és el punt; afirmar que el client no pot adonar-se’n no ho és.
Assumeix que el client pot enumerar el que vulgui i planifica per a la visió de la passarel·la. Un disseny que depèn que el client es quedi cec és a una actualització de trencar-se.
DNS i IPv6 són on la cadena s’escapa
El DNS segueix la configuració de resolutor que guanyi, i aquesta no és necessàriament el camí que fan els paquets. Un resolutor corporatiu assolit pel túnel corporatiu és coherent amb el disseny; un resolutor local assolit fora d’ell no ho és, i exposa noms que el túnel havia d’amagar. IPv6 és la segona fuita: un amfitrió de pila doble continua usant IPv6 cap a destinacions que el túnel només transporta per IPv4. Comprova les famílies per separat, perquè un túnel només d’IPv4 no diu res sobre rutes o resolutors IPv6.
ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'Corregeix el resolutor i la ruta IPv6 deliberadament en lloc d’apilar un segon túnel a sobre. L’encapsulament doble també costa MTU, així que una MTU interna més petita és el primer que cal provar quan les pàgines s’encallen després de muntar la cadena. Un resolutor que respon ràpid no és prova que sigui el resolutor correcte.