Due client VPN contemporaneamente: chi vince la rotta predefinita?

Eseguire due client VPN contemporaneamente è una discussione di routing, non un’impostazione sulla privacy. Il tunnel che possiede la rotta più specifica riceve il traffico, e l’altro resta connesso ma inattivo. Il gateway aziendale vede allora una connessione che arriva dall’uscita personale, mentre il client aziendale sulla tua macchina vede ancora ogni adattatore. Decidere quale dei due fatti conti è l’intero esercizio.

La tabella di routing sceglie un solo vincitore

Cattura la tabella prima e dopo l’avvio del client aziendale, e leggi la colonna dell’interfaccia invece della sola destinazione. Una rotta predefinita semplice dal tunnel esterno è facile da spostare, perché una coppia /1 è più specifica di /0. La coppia letterale 0.0.0.0/1 e 128.0.0.0/1 copre tutto lo spazio IPv4 in due metà e batte qualsiasi rotta predefinita singola. Una volta installata, il tunnel esterno appare ancora connesso e non trasporta nulla.

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

Il routing basato su policy può scavalcare del tutto la tabella principale, quindi leggi sia le regole sia le rotte. Una regola che invia il traffico marcato a un’altra tabella vince prima che la tabella principale venga consultata. È così che un’applicazione può restare sul collegamento fisico mentre tutto il resto usa il tunnel.

ip rule show

Windows decide con le metriche

Su Windows il vincitore è la rotta con la metrica più bassa per la destinazione, e due client possono entrambi installare una rotta predefinita con metriche diverse. Leggi la tabella e la configurazione dell’interfaccia insieme, perché l’adattatore con la metrica più bassa non è sempre quello che ti aspetti. Un client che imposta anche una metrica di interfaccia può spostare la predefinita senza aggiungere una singola rotta. L’adattatore che perde resta attivo e semplicemente non riceve nulla.

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

Confronta i due output e nomina l’interfaccia che possiede 0.0.0.0/0. Se entrambi i client la rivendicano, decide la metrica, ed è per questo che un test dell’ordine di connessione può sembrare incoerente tra macchine diverse. Se nessuno dei due output mostra un gateway predefinito, il client non gira in tunnel completo e l’argomento della catena è privo di senso.

Due osservatori, due viste diverse

Il gateway remoto vede una connessione che arriva dall’uscita esterna più tutto ciò che il client inoltra nel suo tunnel. Il client locale vede adattatori, rotte e l’esistenza di un altro tunnel, perché viene eseguito con i privilegi per crearli. Separare queste viste è il punto; affermare che il client non possa accorgersene non lo è.

Supponi che il client possa enumerare ciò che vuole, e progetta invece per la vista del gateway. Un progetto che dipende dal fatto che il client resti cieco è a un aggiornamento dalla rottura.

DNS e IPv6 sono dove la catena perde

Il DNS segue l’impostazione del resolver che vince, e non è necessariamente il percorso che prendono i pacchetti. Un resolver aziendale raggiunto attraverso il tunnel aziendale è coerente con il progetto; un resolver locale raggiunto fuori da esso non lo è, ed espone nomi che il tunnel doveva nascondere. IPv6 è la seconda perdita: un host dual-stack continua a usare IPv6 verso destinazioni che il tunnel trasporta solo su IPv4. Controlla le famiglie separatamente, perché un tunnel solo IPv4 non dice nulla sulle rotte o sui resolver IPv6.

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

Correggi il resolver e la rotta IPv6 deliberatamente invece di impilare un secondo tunnel sopra. Il doppio incapsulamento costa anche MTU, quindi una MTU interna più piccola è la prima cosa da provare quando le pagine si bloccano dopo l’attivazione della catena. Un resolver che risponde in fretta non è la prova che sia quello giusto.