Questo plugin di NetworkManager può eseguire due VPN contemporaneamente?

Nella lista delle connessioni ci sono due voci VPN, entrambe dicono connesso, e solo una trasporta il traffico che vi aspettavate. Oppure la seconda rifiuta del tutto di partire, e nessuno sa dire se il colpevole sia il plugin, il client o una politica dimenticata. Le affermazioni su un limite di una sola VPN descrivono implementazioni particolari, e le implementazioni differiscono. Esaminate prima la capacità, poi il coordinamento.

Contate i profili salvati, poi le attivazioni

Un profilo salvato è un oggetto di configurazione, e una connessione attiva è un'istanza in esecuzione. La lista fonde visivamente i due concetti, per questo entrambi i rapporti suonano veri. Iniziate nominando gli oggetti esatti con i loro UUID, perché il nome mostrato non è unico e un vecchio import condivide spesso un'etichetta con una voce più recente. Poi controllate separatamente la lista delle connessioni attive e vedete quali UUID compaiono. Solo allora sapete se state confrontando due configurazioni o due tunnel vivi.

Attivare due volte lo stesso UUID è un terzo caso, e non è concorrenza. È una riattivazione di una sola istanza.

Leggete i metadati del plugin stesso

Ogni plugin VPN fornisce un piccolo file di metadati che il gestore legge, e questi file possono dichiarare se il plugin supporta più connessioni contemporaneamente. Leggete il file installato su questa macchina invece di ripetere ciò che un progetto upstream scrive adesso, perché è il pacchetto della distribuzione a decidere che cosa avete davvero. Lo stesso controllo vale per protocollo: una risposta per un plugin non dice nulla su un altro. Annotate la versione del pacchetto accanto al risultato, così che un confronto successivo significhi qualcosa.

I vecchi consigli su un limite di una sola VPN descrivevano integrazioni più datate. Non è né sempre vero né sicuro darlo per fisso, e il file davanti a voi lo risolve localmente.

Concorrente non significa coordinato

Che due plugin partano con successo dimostra la capacità, non il progetto. Due tunnel che offrono entrambi una rotta predefinita si faranno concorrenza, e quello che ha installato la sua rotta per ultimo di solito vince senza annunciarlo. Gli intervalli privati sovrapposti hanno lo stesso problema in forma più piccola.

Decidete quali destinazioni appartengono a quale profilo prima di attivare qualsiasi cosa. Rinominare un profilo non distingue le destinazioni.

Il DNS sceglie un vincitore, che lo facciate o no

Le impostazioni del resolver sono per profilo, e quando due sono attivi l'ordine di risoluzione è deciso da politica e priorità anziché dall'intenzione. Il profilo salito per ultimo può possedere in silenzio ogni nome aziendale.

Assignate ogni spazio dei nomi privato al resolver che deve rispondere per esso, e impostate la preferenza di instradamento deliberatamente invece di affidarvi all'ordine. Poi provate un nome da ogni spazio con entrambi i tunnel attivi, e di nuovo con uno dei due disconnesso. Un resolver che funziona solo finché entrambi i tunnel sono attivi è un progetto che sorprenderà qualcuno nel momento peggiore possibile.

Distribuite in un ordine fisso e ispezionate fra i passi

Attivate un profilo, ispezionate lo stato delle sue rotte e del resolver, poi attivate il secondo e ispezionate di nuovo. Confrontare i due stati vi dice che cosa è cambiato e quale profilo possiede che cosa. Non attivate entrambi e poi diagnosticate il risultato.

Provate ogni risorsa necessaria attraverso il tunnel che deve trasportarla, poi disconnesse un profilo e confermate che l'altro conserva le sue rotte, il suo DNS e il suo comportamento di guasto previsto. Se il plugin distribuito davvero non può fare ciò che serve, scegliete un aggiornamento supportato o un'alternativa esplicitamente isolata invece di far rivivere un protocollo obsoleto accanto al gestore. Un secondo tunnel separato che nessuno gestisce non è isolamento; è un'altra fonte di rotte sorprendenti.