Due client VPN su un solo desktop: cosa va in conflitto e cosa funziona

Il secondo client si connette, le risorse del primo smettono di risolversi e il ticket dice che la VPN di lavoro ha rotto quella personale. Niente è rotto nel senso di un guasto: entrambi i client hanno fatto ciò per cui sono stati progettati, e la macchina ha una sola tabella di routing. Il conflitto riguarda quattro risorse che ogni client presume di possedere. Affrontatele in ordine e la correzione di solito diventa una scelta di progettazione più che una riparazione.

Passo 1: scoprite quale client possiede l’uscita

Leggete la decisione di uscita attuale prima di cambiare qualcosa. La ricerca di rotta per un indirizzo pubblico vi dice quale interfaccia e quale salto successivo userebbe un pacchetto adesso, e questa è la risposta a chi ha vinto. Confrontatela con i nomi delle interfacce create dai client, che di solito portano il nome del prodotto o del protocollo. Se la ricerca punta al tunnel che non vi aspettavate, avete già trovato il conflitto.

ip route get 1.1.1.1
ip route show default
route print

Alcuni client non sostituiscono affatto la route predefinita; aggiungono due metà, una per la metà inferiore dello spazio degli indirizzi e una per quella superiore, che insieme coprono tutto. Questo lascia visibile la route predefinita originale e fa sembrare corretta una riparazione manuale mentre il traffico esce ancora dal tunnel. Leggete la metrica e la lunghezza del prefisso, non solo la presenza di una voce predefinita.

Fermatevi se entrambi i client rivendicano lo stesso prefisso con la stessa metrica. Il kernel ne sceglierà uno, e l’altro apparirà connesso pur non trasportando nulla.

Passo 2: controllate il resolver e i prefissi sovrapposti

Il DNS è il secondo conflitto e produce un sintomo distintivo: i nomi falliscono mentre gli indirizzi funzionano. Ogni client impone il proprio resolver, e l’ultimo che scrive vince per le query successive. Chiedete al servizio di risoluzione cosa usa per collegamento invece di leggere la pagina delle impostazioni del client.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Poi confrontate i prefissi privati usati dalle due reti. Se entrambi i lati assegnano dallo stesso intervallo, nessun accorgimento lato client lo risolverà, perché la macchina non può dire quale destinazione 10.0.0.0/8 appartiene a quale tunnel. Un lato deve essere rinumerato o tradotto, e questa è una conversazione con i proprietari della rete, non un cambio di configurazione. La sovrapposizione è l’unico conflitto in cui la risposta onesta è che il progetto deve cambiare.

Fermatevi qui se i prefissi si sovrappongono. Tutto il resto di questo elenco presuppone che non si sovrappongano.

Passo 3: scegliete uno schema di separazione che regga

Gli schemi affidabili evitano di eseguire due client sulla stessa tabella di routing. Un solo client con una policy di split tunnel che raggiunge entrambe le reti private è il più semplice, a patto che le destinazioni non si sovrappongano e il proprietario della policy sia d’accordo. Una macchina virtuale o un namespace di rete è il passo successivo, perché ciascuno ottiene la propria tabella e il proprio resolver.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Un namespace offre la stessa separazione di una macchina virtuale senza il secondo sistema operativo, ma ha bordi ruvidi: il dispositivo del tunnel deve esservi spostato, e l’applicazione deve essere avviata al suo interno. Un dispositivo fisico separato è spesso l’opzione meno sorprendente per una VPN personale accanto a un client di lavoro gestito. Impilare un tunnel dentro un altro non è uno schema di separazione; l’estremità interna deve restare raggiungibile attraverso il tunnel esterno, e la disposizione aggiunge sopra problemi di MTU e latenza.

Scegliete uno schema e annotate perché. Mescolare un namespace per un’applicazione con uno split tunnel per il resto ricrea il conflitto originale in una forma più difficile da diagnosticare.

Passo 4: verificate entrambe le reti dalla stessa sessione

Provate una risorsa su ciascuna rete privata dall’ambiente in cui l’applicazione gira davvero, non dalla vostra shell se l’app gira dentro un namespace. Controllate insieme l’interfaccia di uscita, l’indirizzo risolto e il codice di risposta, perché un successo su uno dei tre può nascondere un guasto sugli altri. Ripetete dopo un riavvio, perché l’ordine in cui partono i client decide chi vince. È quell’ordine che le persone dimenticano di annotare.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Annotate le versioni dei client, le interfacce, lo stato del resolver e i prefissi di ciascuna rete. Quando un client si aggiorna e cambia il suo comportamento di routing, quell’annotazione è la differenza tra una correzione di cinque minuti e una ricostruzione. La persona successiva non condividerà la vostra memoria su quale tunnel è salito per primo.

L’elenco è completo quando sapete nominare l’interfaccia che possiede la route predefinita, il resolver che usa ogni nome, lo schema che separa il secondo tunnel e il risultato di una richiesta per rete dopo un riavvio. Qualunque cosa in meno è una configurazione che oggi funziona per caso.