Aplicación VPN do provedor fronte a NetworkManager: quen posúe o estado?
Un perfil nomea un complemento, non o comportamento do cliente do provedor. Traza quen posúe o rexistro, o DNS, o bloqueo e as actualizacións antes de cambiar un portátil xestionado.
Importar un perfil non é o mesmo que substituír un cliente. NetworkManager garda un tipo de complemento xunto con datos e segredos específicos do complemento, e o complemento que posúe ese tipo decide que pode facer a conexión. Todo o que a aplicación do provedor superpón, desde o rexistro ata o bloqueo permanente, vive fóra do ficheiro. Que o cambio sexa seguro depende de en que capas desas confías de verdade.
O ficheiro nomea un complemento, non un conxunto de funcións
A referencia de axustes de VPN de NetworkManager describe un tipo de servizo que selecciona o complemento, ademais dun dicionario de datos opaco e un dicionario de segredos que só interpreta o complemento. O perfil é un contrato cunha implementación, non unha descrición dun comportamento que calquera cliente poida reproducir. Dous clientes poden falar o mesmo protocolo e aínda así diferir no que negocian e en que rutas de datos habilitan. A etiqueta dun protocolo diche que é o túnel, nunca que fai o cliente de arredor con el.
Compara, pois, requisitos en lugar de envoltorios. A pregunta non é se a alternativa pode conectarse, porque normalmente pode; é se cada requisito que facía aceptable o cliente orixinal sobrevive á mudanza. Escribe eses requisitos antes de instalar nada, ou a comparación convértese nunha caza do que rompa primeiro.
Que engade a aplicación do provedor arredor do túnel
Os clientes de provedor adoitan agrupar o rexistro e as comprobacións de postura do dispositivo, un fluxo de segundo factor coa súa propia interface, o bloqueo permanente, unha canle de actualizacións e ferramentas de soporte. Parte diso senta xunto ao protocolo, e parte é un produto aparte que só comparte un instalador. NetworkManager pode substituír o túnel e o seu enrutamento, e os scripts de despachador poden disparar accións cando a conexión cambia de estado. Non reproduce un motor de bloqueo, un fluxo de renovación de certificados nin unha suposición sobre que usuario pode levantar a conexión.
Máis compoñentes non significa máis seguro, e menos non significa máis feble. A pregunta é que compoñente aplica a política que che dixeron que seguises. Se un auditor pregunta que bloquea o tráfico cando o túnel cae, a resposta ten que nomear algo que de verdade o faga, e un perfil que só conecta non é esa resposta.
Onde a propiedade difire de verdade
Le isto como un mapa de propiedade e non como unha lista de verificación, porque os fallos de abaixo son ocos de propiedade e ningunha cantidade de configuración do cliente os pecha. Cada fila nomea a capa, o lado que normalmente a ten hoxe e onde o oco aparece primeiro.
| 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 |
Emparella cada fila cunha observación que poidas repetir, non cunha sensación sobre o cliente. Un nome resolvido polo resolutor previsto, unha ruta que desaparece cando o túnel se detén e unha conexión bloqueada tras unha caída simulada son tres observacións que xuntas cobren a maior parte da táboa. Escribe a observación xunto ao requisito que demostra, e conserva as que fallaron, porque unha observación fallida é a única parte do rexistro que predí o seguinte incidente.
Cambiar sen superpór a propiedade
Executar á vez o cliente do provedor e unha conexión de NetworkManager para o mesmo servizo é a forma máis habitual de que estas comparacións saian mal. Ambos instalan rutas, ambos poden fixar o DNS e ambos poden tocar o estado da devasa. O que mides entón é unha terceira disposición que non coincide co comportamento documentado de ningún dos dous clientes.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"O primeiro comando diche se o perfil é sequera de tipo VPN. O segundo mostra o tipo de servizo do complemento e que segredos están gardados, o que importa cando se espera unha chave dun axente en lugar do ficheiro. O rexistro é onde un complemento que se cargou pero non puido negociar o dirá. Se ningún dos tres mostra un problema, o oco está nas capas de política por riba do túnel e non na conexión.
Desconecta o cliente antigo antes de habilitar a conexión nova, mantén idénticos os extremos e a conta, e anota que compoñente posúe as rutas, os axustes do resolutor e o bloqueo. Esa nota é o que impide que a próxima actualización acabe con dous propietarios.