Aplicația VPN a furnizorului versus NetworkManager: cine deține starea?
Un profil numește un plugin, nu comportamentul clientului furnizorului. Cartografiați cine deține înregistrarea, DNS-ul, blocarea și actualizările înainte de a schimba un laptop administrat.
Importarea unui profil nu este același lucru cu înlocuirea unui client. NetworkManager stochează un tip de plugin împreună cu date și secrete specifice pluginului, iar pluginul care deține acel tip decide ce poate face conexiunea. Tot ce aplicația furnizorului suprapune, de la înregistrare până la blocarea permanentă, trăiește în afara fișierului. Dacă trecerea este sigură depinde de straturile pe care vă bazați cu adevărat.
Fișierul numește un plugin, nu un set de funcții
Referința setărilor VPN din NetworkManager descrie un tip de serviciu care selectează pluginul, plus un dicționar de date opac și un dicționar de secrete pe care doar pluginul le interpretează. Profilul este un contract cu o singură implementare, nu o descriere a unui comportament pe care orice client îl poate reproduce. Doi clienți pot vorbi același protocol și totuși diferi în ce negociază și în ce căi de date activează. Eticheta unui protocol vă spune ce este tunelul, niciodată ce face clientul din jur cu el.
Comparați așadar cerințe, nu ambalaje. Întrebarea nu este dacă alternativa se poate conecta, pentru că de obicei poate; este dacă fiecare cerință care făcea clientul original acceptabil supraviețuiește mutării. Notați acele cerințe înainte de a instala ceva, altfel comparația devine o vânătoare a ceea ce se rupe primul.
Ce adaugă aplicația furnizorului în jurul tunelului
Clienții furnizorilor grupează de obicei înregistrarea și verificările de postură ale dispozitivului, un flux cu al doilea factor cu interfață proprie, blocarea permanentă, un canal de actualizări și instrumente de suport. O parte stă lângă protocol, iar o parte este un produs separat care doar partajează un instalator. NetworkManager poate înlocui tunelul și rutarea acestuia, iar scripturile de dispecer pot declanșa acțiuni când starea conexiunii se schimbă. Nu reproduce însă un motor de blocare, un flux de reînnoire a certificatelor sau o presupunere despre ce utilizator poate ridica conexiunea.
Mai multe componente nu înseamnă mai sigur, iar mai puține nu înseamnă mai slab. Întrebarea este care componentă aplică politica pe care vi s-a spus să o urmați. Dacă un auditor întreabă ce blochează traficul când tunelul cade, răspunsul trebuie să numească ceva ce chiar face asta, iar un profil care doar se conectează nu este acel răspuns.
Unde proprietatea diferă de fapt
Citiți asta ca o hartă a proprietății, nu ca o listă de verificare, pentru că defecțiunile de mai jos sunt goluri de proprietate și nicio cantitate de configurare a clientului nu le închide. Fiecare rând numește stratul, partea care îl deține de obicei astăzi și locul unde golul apare primul.
| 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 |
Atribuiți fiecărui rând o observație pe care o puteți repeta, nu o impresie despre client. Un nume rezolvat prin resolverul dorit, o rută care dispare când tunelul se oprește și o conexiune blocată după o întrerupere simulată sunt trei observații care împreună acoperă cea mai mare parte a tabelului. Scrieți observația lângă cerința pe care o dovedește și păstrați-le pe cele eșuate, pentru că o observație eșuată este singura parte a înregistrării care prezice următorul incident.
Trecerea fără suprapunerea proprietății
Rularea simultană a clientului furnizorului și a unei conexiuni NetworkManager pentru același serviciu este cel mai obișnuit mod în care aceste comparații merg prost. Ambele instalează rute, ambele pot seta DNS-ul și ambele pot atinge starea firewallului. Ce măsurați atunci este o a treia aranjare care nu corespunde comportamentului documentat al niciunuia dintre cei doi clienți.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"Prima comandă vă spune dacă profilul este măcar de tip VPN. A doua arată tipul de serviciu al pluginului și ce secrete sunt stocate, ceea ce contează când se așteaptă o cheie de la un agent în locul fișierului. Jurnalul este locul unde un plugin care s-a încărcat dar nu a putut negocia va spune asta. Dacă niciuna dintre cele trei nu arată o problemă, golul este în straturile de politică de deasupra tunelului, nu în conexiune.
Deconectați clientul vechi înainte de a activa noua conexiune, păstrați identice punctele finale și contul, și notați ce componentă deține rutele, setările resolverului și blocarea. Acea notă este ceea ce împiedică următoarea actualizare să se încheie cu doi proprietari.