Leverandørens VPN-app kontra NetworkManager: hvem ejer tilstanden?
En profil navngiver et plugin, ikke leverandørklientens adfærd. Kortlæg, hvem der ejer tilmelding, DNS, blokering og opdateringer, før du skifter en administreret bærbar.
At importere en profil er ikke det samme som at erstatte en klient. NetworkManager gemmer en plugintype sammen med pluginspecifikke data og hemmeligheder, og det plugin, der ejer den type, afgør, hvad forbindelsen kan gøre. Alt, hvad leverandørens applikation lægger ovenpå, fra tilmelding til permanent blokering, lever uden for filen. Om skiftet er sikkert, afhænger af, hvilke af disse lag du faktisk regner med.
Filen navngiver et plugin, ikke et funktionssæt
Referencen for VPN-indstillinger i NetworkManager beskriver en tjenestetype, der vælger pluginnet, plus en uigennemsigtig dataordbog og en hemmelighedsordbog, som kun pluginnet fortolker. Profilen er en kontrakt med én implementering, ikke en beskrivelse af adfærd, som enhver klient kan genskabe. To klienter kan tale samme protokol og stadig være forskellige i, hvad de forhandler, og hvilke datastier de aktiverer. Et protokolnavn fortæller dig, hvad tunnelen er, aldrig hvad den omgivende klient gør ved den.
Sammenlign derfor krav frem for indpakninger. Spørgsmålet er ikke, om alternativet kan forbinde, for det kan det som regel; det er, om hvert krav, der gjorde den oprindelige klient acceptabel, overlever flytningen. Skriv kravene ned, før du installerer noget, ellers bliver sammenligningen en jagt på det, der først brækker.
Hvad leverandørens app tilføjer omkring tunnelen
Leverandørklienter samler typisk tilmelding og kontrol af enhedens tilstand, et tofaktorforløb med egen grænseflade, permanent blokering, en opdateringskanal og supportværktøjer. Noget af det står ved siden af protokollen, og noget er et separat produkt, der blot deler en installationsfil. NetworkManager kan erstatte tunnelen og dens routing, og dispatcher-script kan udløse handlinger, når forbindelsen skifter tilstand. Det genskaber ikke en blokeringsmotor, et certifikatfornyelsesforløb eller en antagelse om, hvilken bruger der må rejse forbindelsen.
Flere komponenter betyder ikke mere sikkert, og færre betyder ikke svagere. Spørgsmålet er, hvilken komponent der håndhæver den politik, du blev bedt om at følge. Hvis en revisor spørger, hvad der blokerer trafik, når tunnelen falder, skal svaret navngive noget, der faktisk gør det, og en profil, der kun forbinder, er ikke det svar.
Hvor ejerskabet faktisk adskiller sig
Læs dette som et ejerskabskort snarere end en tjekliste, fordi fejlene nedenfor er ejerskabshuller, og ingen mængde klientkonfiguration lukker dem. Hver række navngiver laget, den side der normalt holder det i dag, og hvor hullet viser sig 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 |
Kobl hver række til en observation, du kan gentage, frem for en fornemmelse af klienten. Et navn opløst gennem den tilsigtede resolver, en rute der forsvinder, når tunnelen stopper, og en blokeret forbindelse efter et simuleret afbrud er tre observationer, der tilsammen dækker det meste af tabellen. Skriv observationen ved siden af det krav, den beviser, og behold dem, der fejlede, for en fejlet observation er den eneste del af optegnelsen, der forudsiger den næste hændelse.
Skift uden overlappende ejerskab
At køre leverandørklienten og en NetworkManager-forbindelse for den samme tjeneste samtidig er den mest almindelige måde, disse sammenligninger går galt. Begge installerer ruter, begge kan sætte DNS, og begge kan røre firewallens tilstand. Det, du så måler, er en tredje ordning, der ikke passer til nogen af de to klienters dokumenterede adfærd.
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 kommando fortæller, om profilen overhovedet er en VPN-type. Den anden viser pluginets tjenestetype og hvilke hemmeligheder der er gemt, hvilket betyder noget, når en nøgle forventes fra en agent i stedet for filen. Journalen er stedet, hvor et plugin, der blev indlæst, men ikke kunne forhandle, vil sige det. Hvis ingen af de tre viser et problem, sidder hullet i politiklagene over tunnelen snarere end i forbindelsen.
Afbryd den gamle klient, før du aktiverer den nye forbindelse, hold endepunkter og konto identiske, og skriv ned, hvilken komponent der ejer ruter, resolverindstillinger og blokering. Den note er det, der forhindrer den næste opdatering i at ende med to ejere.