App VPN del fornitore o NetworkManager: a chi appartiene lo stato?
Un profilo nomina un plugin, non il comportamento del client del fornitore. Mappate chi possiede registrazione, DNS, blocco e aggiornamenti prima di cambiare un portatile gestito.
Importare un profilo non è la stessa cosa di sostituire un client. NetworkManager memorizza un tipo di plugin insieme a dati e segreti specifici del plugin, e il plugin che possiede quel tipo decide cosa può fare la connessione. Tutto ciò che l’applicazione del fornitore sovrappone, dalla registrazione al blocco permanente, vive fuori dal file. Che il passaggio sia sicuro dipende da quali di questi livelli vi affidate davvero.
Il file nomina un plugin, non un insieme di funzioni
Il riferimento alle impostazioni VPN di NetworkManager descrive un tipo di servizio che seleziona il plugin, oltre a un dizionario di dati opaco e a un dizionario di segreti che solo il plugin interpreta. Il profilo è un contratto con un’implementazione, non la descrizione di un comportamento che qualsiasi client può riprodurre. Due client possono parlare lo stesso protocollo e differire comunque in ciò che negoziano e nei percorsi dati che abilitano. L’etichetta di un protocollo dice cos’è il tunnel, mai cosa ne fa il client intorno.
Confrontate quindi requisiti, non involucri. La domanda non è se l’alternativa possa connettersi, perché di solito può; è se ogni requisito che rendeva accettabile il client originale sopravviva al trasferimento. Scrivete quei requisiti prima di installare qualsiasi cosa, altrimenti il confronto diventa una caccia a ciò che si rompe per primo.
Cosa aggiunge l’applicazione del fornitore intorno al tunnel
I client dei fornitori raggruppano di solito registrazione e controlli di postura del dispositivo, un flusso a secondo fattore con interfaccia propria, blocco permanente, un canale di aggiornamento e strumenti di supporto. Parte di ciò sta accanto al protocollo, e parte è un prodotto separato che condivide solo un installer. NetworkManager può sostituire il tunnel e il suo routing, e gli script del dispatcher possono attivare azioni quando lo stato della connessione cambia. Non riproduce però un motore di blocco, un flusso di rinnovo dei certificati né un’ipotesi su quale utente possa alzare la connessione.
Più componenti non significa più sicuro, e meno non significa più debole. La domanda è quale componente applica la politica che vi è stato detto di seguire. Se un revisore chiede cosa blocca il traffico quando il tunnel cade, la risposta deve nominare qualcosa che lo faccia davvero, e un profilo che si limita a connettersi non è quella risposta.
Dove la proprietà differisce davvero
Leggete questo come una mappa di proprietà e non come una lista di controllo, perché i guasti qui sotto sono lacune di proprietà e nessuna quantità di configurazione del client le chiude. Ogni riga nomina il livello, la parte che di solito lo detiene oggi e dove la lacuna compare per prima.
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
Accoppiate ogni riga a un’osservazione che potete ripetere, non a una sensazione sul client. Un nome risolto tramite il resolver previsto, una rotta che scompare quando il tunnel si ferma e una connessione bloccata dopo un’interruzione simulata sono tre osservazioni che insieme coprono la maggior parte della tabella. Scrivete l’osservazione accanto al requisito che dimostra, e conservate quelle fallite, perché un’osservazione fallita è l’unica parte del verbale che prevede il prossimo incidente.
Passare senza sovrapporre la proprietà
Eseguire insieme il client del fornitore e una connessione NetworkManager per lo stesso servizio è il modo più comune in cui questi confronti vanno storti. Entrambi installano rotte, entrambi possono impostare il DNS ed entrambi possono toccare lo stato del firewall. Quello che misurate allora è un terzo assetto che non corrisponde al comportamento documentato di nessuno dei due client.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"Il primo comando dice se il profilo è almeno di tipo VPN. Il secondo mostra il tipo di servizio del plugin e quali segreti sono memorizzati, cosa che conta quando una chiave è attesa da un agente invece che dal file. Il registro è il punto in cui un plugin caricato ma incapace di negoziare lo dirà. Se nessuno dei tre mostra un problema, la lacuna sta nei livelli di politica sopra il tunnel, non nella connessione.
Scollegate il vecchio client prima di abilitare la nuova connessione, mantenete identici endpoint e account, e annotate quale componente possiede rotte, impostazioni del resolver e blocco. Quella nota è ciò che impedisce al prossimo aggiornamento di finire con due proprietari.