Tre modi per lavorare su più VPN senza confusione

Due tunnel cliente, un portatile e una scheda del browser ancora connessa dove non dovrebbe. La parte difficile del lavoro su più reti private non è connettersi; è sapere a quale contesto appartiene una finestra quando si cambia. Uno spazio di lavoro risponde a questa domanda: un'identità, un insieme di applicazioni, una politica del resolver e un posto dove guardare quando qualcosa viene risolto male. In una brutta giornata è la differenza tra una correzione di cinque minuti e una fuga di dati.

Decidete se il lavoro è simultaneo

Se la risposta è no, fermatevi qui e usate la disposizione più semplice disponibile. Una connessione approvata alla volta, connessa e disconnessa tramite il client che possiede il profilo, elimina un'intera classe di guasti prima che uno di essi possa verificarsi.

È la simultaneità ad aumentare il costo: prefissi sovrapposti, due politiche del resolver e due insiemi di stato delle applicazioni vanno separati deliberatamente, non dal tempo.

Scrivete il requisito con onestà, perché voler evitare una riconnessione non è lo stesso che aver bisogno di entrambe le reti insieme.

Il sequenziale è la disposizione più economica

Il lavoro sequenziale non richiede infrastruttura aggiuntiva, e la sua modalità di guasto è una sessione obsoleta invece di un conflitto di routing. La disciplina sta nel passaggio: terminate l'operazione, chiudete ciò che tiene una connessione, disconnettete e confermate la connessione successiva prima di iniziare a lavorare.

Una scheda del browser o un terminale che resta aperto non porta con sé il proprio contesto di rete. La sua richiesta successiva va dove la macchina instrada ora, che può essere l'altro cliente.

Etichettate i profili per cliente invece che per protocollo, e tenete visibile il proprietario delle credenziali nel nome del profilo. Un profilo chiamato work2 non dice nulla a nessuno nel momento di un cambio frettoloso.

Il vantaggio di questa disposizione è che è verificabile. In ogni istante c'è un solo contesto di rete, e il registro mostra quando è cambiato.

Uno spazio di lavoro per cliente costa l'isolamento

Una macchina virtuale o un ambiente di sviluppo remoto per cliente mette il client, le applicazioni e i nomi in un solo posto. Il cambio diventa un cambio di finestra invece di un cambio di rete, e i due contesti non possono filtrarsi l'uno nell'altro attraverso una rotta smarrita.

Non è gratis. Ora mantenete due o tre sistemi, li aggiornate e decidete dove vivono file e credenziali. La macchina virtuale raggiunge anche Internet tramite l'host, quindi il suo percorso esterno resta quello del vostro portatile.

Verificate che il client e qualsiasi politica sullo stato del dispositivo consentano quell'ambiente prima di costruirci sopra l'abitudine. Un client che rifiuta di funzionare in una macchina virtuale è un fatto da scoprire presto.

Un gateway condiviso è infrastruttura

Un router separato che trasporta traffico selezionato trasforma il problema in progettazione di rete. Funziona bene quando più persone hanno bisogno della stessa rete cliente, e fallisce quando qualcuno lo tratta come una scatola magica che tiene ogni cliente separato.

Un gateway che cambia il suo tunnel attivo è un unico contesto condiviso con una coda, non più reti indipendenti. Nominate chi può modificarlo, quali sorgenti serve e cosa succede quando due persone hanno bisogno di client diversi nello stesso momento. Senza quella risposta il gateway diventa una fonte di interruzioni che nessuno possiede. Diventa anche il posto dove qualcuno disattiva in silenzio un controllo per rispettare una scadenza.

Scrivete il passaggio in un registro

Il registro non deve essere sofisticato; deve essere abbastanza specifico che qualcun altro possa seguirlo. Su Linux, un namespace è la versione tecnica della stessa idea, con le proprie interfacce e la propria tabella di routing.

Questi comandi creano un namespace, eseguono un comando al suo interno e mostrano quali connessioni il client desktop tiene attualmente:

sudo ip netns add customer-a
sudo ip netns exec customer-a ip route
nmcli connection show --active

Le applicazioni vanno ancora avviate dentro il namespace, e la configurazione del resolver al suo interno è un file separato. Isolare le interfacce non isola gli appunti, l'agente SSH o una condivisione montata, e sono queste le fughe che la gente dimentica.

Scegliete la disposizione più piccola che preserva la separazione di cui avete davvero bisogno, e mantenete visibile la transizione: il titolo della finestra, il prompt del terminale, il nome del profilo e il proprietario delle credenziali devono coincidere prima che venga inviata qualsiasi richiesta privata.