Dous clientes VPN á vez: quen gaña a ruta predeterminada?

Executar dous clientes VPN á vez é unha discusión de encamiñamento, non un axuste de privacidade. O túnel que posúe a ruta máis específica recibe o tráfico, e o outro queda conectado pero inactivo. A pasarela corporativa ve entón unha conexión que chega desde a saída persoal, mentres que o cliente corporativo da túa máquina segue vendo cada adaptador. Decidir cal destes dous feitos importa é todo o exercicio.

A táboa de rutas escolle un único gañador

Captura a táboa antes e despois de que arrinque o cliente corporativo, e le a columna de interface en lugar de só o destino. Unha ruta predeterminada simple do túnel exterior é fácil de desprazar, porque un par /1 é máis específico que /0. O par literal 0.0.0.0/1 e 128.0.0.0/1 cobre todo o espazo IPv4 en dúas metades e supera calquera ruta predeterminada única. Unha vez instalado, o túnel exterior segue mostrándose conectado e non transporta nada.

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

O encamiñamento por políticas pode anular por completo a táboa principal, así que le tanto as regras como as rutas. Unha regra que envía o tráfico marcado a outra táboa gaña antes de que se consulte a táboa principal. Así é como unha aplicación pode quedar na ligazón física mentres todo o demais usa o túnel.

ip rule show

Windows decídeo con métricas

En Windows o gañador é a ruta coa métrica máis baixa para o destino, e dous clientes poden instalar ambos unha ruta predeterminada con métricas distintas. Le a táboa e a configuración da interface xuntas, porque o adaptador coa métrica máis baixa non sempre é o que esperas. Un cliente que tamén fixa unha métrica de interface pode mover a predeterminada sen engadir nin unha soa ruta. O adaptador que perde queda activo e simplemente non recibe nada.

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

Compara as dúas saídas e nomea a interface que posúe 0.0.0.0/0. Se ambos os clientes a reclaman, decide a métrica, e por iso unha proba de orde de conexión pode parecer inconsistente entre máquinas. Se ningunha das saídas mostra unha pasarela predeterminada, o cliente non funciona en túnel completo e o argumento da cadea queda sen sentido.

Dous observadores, dúas visións distintas

A pasarela remota ve unha conexión que chega desde a saída exterior máis todo o que o cliente reenvía ao seu túnel. O cliente local ve adaptadores, rutas e a existencia doutro túnel, porque se executa con privilexios para crealos. Separar esas visións é o punto; afirmar que o cliente non pode decatarse non o é.

Supón que o cliente pode enumerar o que queira e planifica para a visión da pasarela. Un deseño que depende de que o cliente siga cego está a unha actualización de romper.

DNS e IPv6 son onde a cadea perde

O DNS segue o axuste de resolutor que gañe, e ese non é necesariamente o camiño que toman os paquetes. Un resolutor corporativo acadado polo túnel corporativo é coherente co deseño; un resolutor local acadado fóra del non o é, e expón nomes que o túnel debía ocultar. IPv6 é a segunda fuga: un host de dobre pila segue usando IPv6 cara a destinos que o túnel só transporta por IPv4. Comproba as familias por separado, porque un túnel só de IPv4 non di nada sobre rutas ou resolutores IPv6.

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

Corrixe o resolutor e a ruta IPv6 a propósito en lugar de apilar un segundo túnel enriba. A encapsulación dobre tamén custa MTU, así que unha MTU interna máis pequena é o primeiro que hai que probar cando as páxinas se atascan tras levantar a cadea. Un resolutor que responde rápido non é proba de que sexa o correcto.