Leverandørens VPN-app kontra NetworkManager: hvem eier tilstanden?
En profil navngir en plugin, ikke leverandørklientens atferd. Kartlegg hvem som eier registrering, DNS, blokkering og oppdateringer før du bytter en administrert bærbar PC.
Å importere en profil er ikke det samme som å erstatte en klient. NetworkManager lagrer en plugintype sammen med pluginspesifikke data og hemmeligheter, og pluginen som eier den typen avgjør hva tilkoblingen kan gjøre. Alt leverandørens applikasjon legger oppå, fra registrering til permanent blokkering, lever utenfor filen. Om byttet er trygt avhenger av hvilke av disse lagene du faktisk regner med.
Filen navngir en plugin, ikke et funksjonssett
Referansen for VPN-innstillinger i NetworkManager beskriver en tjenestetype som velger pluginen, i tillegg til en ugjennomsiktig dataordbok og en hemmelighetsordbok som bare pluginen tolker. Profilen er en kontrakt med én implementasjon, ikke en beskrivelse av atferd som enhver klient kan gjenskape. To klienter kan snakke samme protokoll og likevel være ulike i hva de forhandler om og hvilke datastier de aktiverer. Et protokollnavn forteller deg hva tunnelen er, aldri hva klienten rundt gjør med den.
Sammenlign derfor krav i stedet for innpakninger. Spørsmålet er ikke om alternativet kan koble til, for det kan det som regel; det er om hvert krav som gjorde den opprinnelige klienten akseptabel overlever flyttingen. Skriv ned kravene før du installerer noe, ellers blir sammenligningen en jakt på det som ryker først.
Hva leverandørens app tilfører rundt tunnelen
Leverandørklienter samler vanligvis registrering og kontroll av enhetens tilstand, et tofaktorforløp med eget grensesnitt, permanent blokkering, en oppdateringskanal og støtteverktøy. Noe av dette står ved siden av protokollen, og noe er et separat produkt som bare deler en installasjonsfil. NetworkManager kan erstatte tunnelen og rutingen, og dispatcher-skript kan utløse handlinger når tilkoblingen endrer tilstand. Det gjenskaper likevel ikke en blokkeringsmotor, et sertifikatfornyelsesforløp eller en antakelse om hvilken bruker som får heise tilkoblingen.
Flere komponenter betyr ikke tryggere, og færre betyr ikke svakere. Spørsmålet er hvilken komponent som håndhever policyen du ble bedt om å følge. Hvis en revisor spør hva som blokkerer trafikk når tunnelen faller, må svaret navngi noe som faktisk gjør det, og en profil som bare kobler til er ikke det svaret.
Hvor eierskapet faktisk skiller seg
Les dette som et eierskapskart og ikke som en sjekkliste, fordi feilene nedenfor er eierskapshull og ingen mengde klientkonfigurasjon lukker dem. Hver rad navngir laget, siden som vanligvis holder det i dag, og hvor hullet 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 |
Koble hver rad til en observasjon du kan gjenta, ikke til en følelse av klienten. Et navn som er løst gjennom den tiltenkte resolveren, en rute som forsvinner når tunnelen stopper, og en blokkert tilkobling etter et simulert brudd er tre observasjoner som sammen dekker mesteparten av tabellen. Skriv observasjonen ved siden av kravet den beviser, og behold dem som feilet, for en feilet observasjon er den eneste delen av protokollen som forutsier neste hendelse.
Bytte uten overlappende eierskap
Å kjøre leverandørklienten og en NetworkManager-tilkobling for samme tjeneste samtidig er den vanligste måten disse sammenligningene går galt. Begge installerer ruter, begge kan sette DNS, og begge kan berøre brannmurens tilstand. Det du da måler er en tredje ordning som ikke samsvarer med noen av de to klientenes dokumenterte atferd.
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 forteller om profilen i det hele tatt er av VPN-typen. Den andre viser pluginens tjenestetype og hvilke hemmeligheter som er lagret, noe som betyr noe når en nøkkel forventes fra en agent i stedet for filen. Journalen er stedet der en plugin som ble lastet, men ikke klarte å forhandle, vil si det. Hvis ingen av de tre viser et problem, sitter hullet i policylagene over tunnelen og ikke i tilkoblingen.
Koble fra den gamle klienten før du aktiverer den nye tilkoblingen, hold endepunkter og konto identiske, og skriv ned hvilken komponent som eier ruter, resolverinnstillinger og blokkering. Den notatet er det som hindrer neste oppdatering i å ende med to eiere.