VPN-appen frå leverandøren mot NetworkManager: kven eig tilstanden?
Ein profil namngjev ein plugin, ikkje åtferda til klienten frå leverandøren. Kartlegg kven som eig registrering, DNS, blokkering og oppdateringar før du byter ein administrert berbar PC.
Å importere ein profil er ikkje det same som å erstatte ein klient. NetworkManager lagrar ein plugintype saman med pluginspesifikke data og løyndomar, og pluginen som eig den typen avgjer kva tilkoplinga kan gjere. Alt leverandøren sin applikasjon legg oppå, frå registrering til permanent blokkering, lever utanfor fila. Om bytet er trygt avheng av kva av desse laga du faktisk reknar med.
Fila namngjev ein plugin, ikkje eit funksjonssett
Referansen for VPN-innstillingar i NetworkManager skildrar ein tenestetype som vel pluginen, i tillegg til ei ugjennomsiktig dataordbok og ei løyndomsordbok som berre pluginen tolkar. Profilen er ein kontrakt med éin implementasjon, ikkje ei skildring av åtferd som kvar klient kan gjenskape. To klientar kan snakke same protokoll og likevel vere ulike i kva dei forhandlar om og kva datastiar dei slår på. Eit protokollnamn fortel deg kva tunnelen er, aldri kva klienten rundt gjer med han.
Samanlikn derfor krav i staden for innpakkingar. Spørsmålet er ikkje om alternativet kan kople til, for det kan det som regel; det er om kvart krav som gjorde den opphavlege klienten akseptabel overlever flyttinga. Skriv ned krava før du installerer noko, elles blir samanlikninga ei jakt på det som ryker først.
Kva appen frå leverandøren tilfører rundt tunnelen
Leverandørklientar samlar vanlegvis registrering og kontroll av tilstanden til eininga, eit tofaktorforløp med eige grensesnitt, permanent blokkering, ein oppdateringskanal og støtteverktøy. Noko av dette står ved sida av protokollen, og noko er eit separat produkt som berre deler ein installasjonsfil. NetworkManager kan erstatte tunnelen og rutinga, og dispatcher-skript kan utløyse handlingar når tilkoplinga endrar tilstand. Det gjer likevel ikkje ein blokkeringsmotor, eit sertifikatfornyingsforløp eller ei føresetnad om kven brukar som får heise tilkoplinga.
Fleire komponentar tyder ikkje tryggare, og færre tyder ikkje svakare. Spørsmålet er kva komponent som handhevar policyen du vart beden om å følgje. Viss ein revisor spør kva som blokkerer trafikk når tunnelen fell, må svaret namngje noko som faktisk gjer det, og ein profil som berre koplar til er ikkje det svaret.
Kvar eigarskapet faktisk skil seg
Les dette som eit eigarskapskart og ikkje som ei sjekkliste, fordi feila nedanfor er eigarskapshol og inga mengd klientkonfigurasjon lukkar dei. Kvar rad namngjev laget, sida som vanlegvis held det i dag, og kvar holet viser seg først.
| 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 |
Kople kvar rad til ein observasjon du kan gjenta, ikkje til ei kjensle av klienten. Eit namn som er løyst gjennom den tiltenkte resolveren, ei rute som forsvinn når tunnelen stoppar, og ei blokkert tilkopling etter eit simulert brot er tre observasjonar som saman dekkjer det meste av tabellen. Skriv observasjonen ved sida av kravet han beviser, og behald dei som feila, for ein feila observasjon er den einaste delen av protokollen som føreser neste hending.
Byte utan overlappande eigarskap
Å køyre leverandørklienten og ei NetworkManager-tilkopling for same teneste samstundes er den vanlegaste måten desse samanlikningane går gale. Begge installerer ruter, begge kan setje DNS, og begge kan røre tilstanden til brannmuren. Det du då måler er ei tredje ordning som ikkje svarar til den dokumenterte åtferda til nokon av dei to klientane.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"Den første kommandoen fortel om profilen i det heile er av VPN-typen. Den andre viser tenestetypen til pluginen og kva løyndomar som er lagra, noko som tel når ein nøkkel blir venta frå ein agent i staden for fila. Journalen er staden der ein plugin som vart lasta, men ikkje klarte å forhandle, vil seie det. Viss ingen av dei tre viser eit problem, sit holet i policylaga over tunnelen og ikkje i tilkoplinga.
Kople frå den gamle klienten før du aktiverer den nye tilkoplinga, hald endepunkt og konto identiske, og skriv ned kva komponent som eig ruter, resolverinnstillingar og blokkering. Det notatet er det som hindrar neste oppdatering i å ende med to eigarar.