Verskaffertoepassing teenoor NetworkManager: wie besit die toestand?
'n Profiel noem 'n plugin, nie die verskaffer se kliëntgedrag nie. Karteer wie eienaarskap het oor inskrywing, DNS, blokkering en opdaterings voordat jy 'n bestuurde skootrekenaar oorskakel.
Om 'n profiel in te voer is nie dieselfde as om 'n kliënt te vervang nie. NetworkManager stoor 'n tipe plugin saam met plugin-spesifieke data en geheimenisse, en die plugin wat daardie tipe besit, bepaal wat die verbinding kan doen. Alles wat die verskaffer se toepassing daarbo bou, van inskrywing tot altyd-aan-blokkering, leef buite die lêer. Of die oorskakeling veilig is, hang daarvan af watter van daardie lae jy werklik gebruik.
Die lêer noem 'n plugin, nie 'n stel funksies nie
Die VPN-instellingsverwysing van NetworkManager beskryf 'n dienstipe wat die plugin kies, plus 'n ondeursigtige datastruktuur en 'n geheimenisstruktuur wat net die plugin vertolk. Die profiel is 'n kontrak met een implementering, nie 'n beskrywing van gedrag wat enige kliënt kan naboots nie. Twee kliënte kan dieselfde protokol praat en steeds verskil in wat hulle onderhandel en watter datapaaie hulle aktiveer. 'n Protokolnaam sê vir jou wat die tonnel is, nooit wat die omliggende kliënt daarmee doen nie.
Vergelyk dan eerder vereistes as wikkels. Die vraag is nie of die alternatief kan koppel nie, want dit kan gewoonlik; die vraag is of elke vereiste wat die oorspronklike kliënt aanvaarbaar gemaak het, die skuif oorleef. Skryf daardie vereistes neer voordat jy iets installeer, anders word die vergelyking 'n jag na wat eerste breek.
Wat die verskaffertoepassing rondom die tonnel byvoeg
Verskafferkliënte bundel gewoonlik inskrywing en toestelkontroles van die toestel, 'n tweedefaktor-vloei met sy eie koppelvlak, altyd-aan-blokkering, 'n opdateringskanaal en ondersteuningsgereedskap. Sommige daarvan sit langs die protokol, en sommige is 'n aparte produk wat bloot 'n installeerder deel. NetworkManager kan die tonnel en sy roetes vervang, en dispatcher-skripte kan aksies uitvoer wanneer die verbinding van toestand verander. Dit reproduseer nie 'n blokkeringsenjin, 'n sertifikaatvernuwingswerkvloei of 'n aanname oor watter gebruiker die verbinding mag opbring nie.
Meer komponente beteken nie veiliger nie, en minder beteken nie swakker nie. Die vraag is watter komponent die beleid afdwing wat jy opdrag gekry het om te volg. As 'n ouditeur vra wat verkeer blokkeer wanneer die tonnel val, moet die antwoord iets noem wat dit werklik doen, en 'n profiel wat net koppel is nie daardie antwoord nie.
Waar eienaarskap werklik verskil
Lees dit as 'n eienaarskapskaart eerder as 'n kontrolelys, want die foute hieronder is gapings in eienaarskap en geen hoeveelheid kliëntkonfigurasie sluit hulle nie. Elke ry noem die laag, die kant wat dit vandag gewoonlik hou, en waar die gaping eerste wys.
| 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 |
Pas elke ry met 'n waarneming wat jy kan herhaal, eerder as 'n gevoel oor die kliënt. 'n Naam wat deur die bedoelde resolver opgelos word, 'n roete wat verdwyn wanneer die tonnel stop, en 'n geblokkeerde verbinding ná 'n gesimuleerde onderbreking is drie waarnemings wat saam die meeste van die tabel dek. Skryf die waarneming langs die vereiste wat dit bewys, en hou die wat gefaal het, want 'n mislukte waarneming is die enigste deel van die rekord wat die volgende voorval voorspel.
Oorskakel sonder oorvleuelende eienaarskap
Om die verskafferkliënt en 'n NetworkManager-verbinding vir dieselfde diens gelyktydig te laat loop, is die mees algemene manier waarop hierdie vergelykings verkeerd gaan. Albei installeer roetes, albei kan DNS stel, en albei kan firewalltoestand raak. Wat jy dan meet, is 'n derde reëling wat met geen van die twee kliënte se gedokumenteerde gedrag ooreenstem nie.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"Die eerste opdrag sê of die profiel hoegenaamd 'n VPN-tipe is. Die tweede wys die plugin-dienstipe en watter geheimenisse gestoor word, wat saak maak wanneer 'n sleutel van 'n agent eerder as uit die lêer verwag word. Die joernaal is waar 'n plugin wat gelaai het maar nie kon onderhandel nie, dit sal sê. As nie een van die drie 'n probleem wys nie, sit die gaping in die beleidslae bo die tonnel eerder as in die verbinding.
Ontkoppel die ou kliënt voordat jy die nuwe verbinding aktiveer, hou eindpunte en rekening identies, en skryf neer watter komponent eienaar is van roetes, resolver-instellings en blokkering. Daardie nota is wat keer dat die volgende opdatering met twee eienaars eindig.