Aplicació VPN del proveïdor contra NetworkManager: qui posseeix l’estat?
Un perfil nomena un connector, no el comportament del client del proveïdor. Mapeu qui posseeix el registre, el DNS, el bloqueig i les actualitzacions abans de canviar un portàtil gestionat.
Importar un perfil no és el mateix que substituir un client. NetworkManager desa un tipus de connector juntament amb dades i secrets específics del connector, i el connector que posseeix aquest tipus decideix què pot fer la connexió. Tot el que l’aplicació del proveïdor superposa, des del registre fins al bloqueig permanent, viu fora del fitxer. Que el canvi sigui segur depèn de en quins d’aquests nivells confieu realment.
El fitxer nomena un connector, no un conjunt de funcions
La referència de paràmetres VPN de NetworkManager descriu un tipus de servei que selecciona el connector, a més d’un diccionari de dades opac i un diccionari de secrets que només interpreta el connector. El perfil és un contracte amb una implementació, no una descripció d’un comportament que qualsevol client pugui reproduir. Dos clients poden parlar el mateix protocol i tot i així diferir en què negocien i quins camins de dades habiliten. L’etiqueta del protocol us diu què és el túnel, mai què fa el client del voltant amb ell.
Així doncs, compareu requisits en lloc d’embolcalls. La pregunta no és si l’alternativa es connecta, perquè normalment pot; és si cada requisit que feia acceptable el client original sobreviu al trasllat. Escriviu aquests requisits abans d’instal·lar res, o la comparació es converteix en una cacera del que es trenqui primer.
Què afegeix l’aplicació del proveïdor al voltant del túnel
Els clients de proveïdor solen agrupar el registre i les comprovacions de postura del dispositiu, un flux de segon factor amb interfície pròpia, el bloqueig permanent, un canal d’actualitzacions i eines de suport. Part d’això se seu al costat del protocol, i part és un producte a part que només comparteix l’instal·lador. NetworkManager pot substituir el túnel i el seu encaminament, i els scripts de despatxador poden disparar accions quan canvia l’estat de la connexió. No reprodueix un motor de bloqueig, un flux de renovació de certificats ni una suposició sobre quin usuari pot aixecar la connexió.
Més components no vol dir més segur, i menys no vol dir més feble. La pregunta és quin component aplica la política que us han dit de seguir. Si un auditor pregunta què bloqueja el trànsit quan el túnel cau, la resposta ha de nomenar alguna cosa que ho faci de debò, i un perfil que només es connecta no és aquesta resposta.
On la propietat difereix de veritat
Llegiu-ho com un mapa de propietat i no com una llista de verificació, perquè les fallades de sota són buits de propietat i cap quantitat de configuració del client els tanca. Cada fila nomena el nivell, la banda que normalment el té avui i on el buit apareix primer.
| 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 |
Aparelleu cada fila amb una observació que pugueu repetir, no amb una sensació sobre el client. Un nom resolt pel resolutor previst, una ruta que desapareix quan el túnel s’atura i una connexió bloquejada després d’una caiguda simulada són tres observacions que juntes cobreixen la major part de la taula. Escriviu l’observació al costat del requisit que demostra, i guardeu les que han fallat, perquè una observació fallada és l’única part del registre que prediu el pròxim incident.
Canviar sense superposar la propietat
Executar alhora el client del proveïdor i una connexió de NetworkManager per al mateix servei és la manera més habitual que aquestes comparacions surtin malament. Tots dos instal·len rutes, tots dos poden definir el DNS i tots dos poden tocar l’estat del tallafoc. El que mesureu llavors és una tercera disposició que no coincideix amb el comportament documentat de cap dels dos clients.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"La primera ordre us diu si el perfil és o no un tipus VPN. La segona mostra el tipus de servei del connector i quins secrets s’hi guarden, cosa que importa quan s’espera una clau d’un agent en lloc del fitxer. El registre és on un connector que s’ha carregat però no ha pogut negociar ho dirà. Si cap de les tres no mostra cap problema, el buit és als nivells de política per sobre del túnel, no a la connexió.
Desconnecteu el client antic abans d’habilitar la connexió nova, manteniu els extrems i el compte idèntics, i anoteu quin component posseeix les rutes, els paràmetres del resolutor i el bloqueig. Aquesta nota és el que evita que la propera actualització acabi amb dos propietaris.