VPN-app van de leverancier versus NetworkManager: wie bezit de toestand?
Een profiel noemt een plug-in, niet het gedrag van de leveranciersclient. Breng in kaart wie inschrijving, DNS, blokkering en updates bezit voordat u een beheerde laptop omzet.
Een profiel importeren is niet hetzelfde als een client vervangen. NetworkManager bewaart een plug-intype samen met plug-inspecifieke gegevens en geheimen, en de plug-in die dat type bezit bepaalt wat de verbinding kan doen. Alles wat de applicatie van de leverancier erbovenop legt, van inschrijving tot permanente blokkering, leeft buiten het bestand. Of de overstap veilig is, hangt af van op welke van die lagen u werkelijk vertrouwt.
Het bestand noemt een plug-in, geen functieset
De referentie voor VPN-instellingen van NetworkManager beschrijft een diensttype dat de plug-in kiest, plus een ondoorzichtig gegevenswoordenboek en een geheimenwoordenboek die alleen de plug-in interpreteert. Het profiel is een contract met één implementatie, geen beschrijving van gedrag dat elke client kan nabootsen. Twee clients kunnen hetzelfde protocol spreken en toch verschillen in wat ze onderhandelen en welke gegevenspaden ze inschakelen. Een protocolnaam vertelt u wat de tunnel is, nooit wat de omringende client ermee doet.
Vergelijk dus eisen in plaats van omhulsels. De vraag is niet of het alternatief kan verbinden, want dat kan het meestal; ze is of elke eis die de oorspronkelijke client aanvaardbaar maakte, de verhuizing overleeft. Schrijf die eisen op voordat u iets installeert, anders wordt de vergelijking een jacht op wat het eerst breekt.
Wat de leveranciersapp rond de tunnel toevoegt
Leveranciersclients bundelen meestal inschrijving en apparaatpostuurcontroles, een tweefactorstroom met eigen interface, permanente blokkering, een updatekanaal en ondersteuningstools. Een deel daarvan staat naast het protocol, en een deel is een apart product dat alleen een installer deelt. NetworkManager kan de tunnel en de routering ervan vervangen, en dispatcherscripts kunnen acties afvuren wanneer de verbinding van toestand verandert. Het reproduceert echter geen blokkeerengine, geen certificaatvernieuwingsproces en geen aanname over welke gebruiker de verbinding mag opbrengen.
Meer componenten betekent niet veiliger, en minder betekent niet zwakker. De vraag is welke component het beleid handhaaft dat u werd gezegd te volgen. Als een auditor vraagt wat verkeer blokkeert wanneer de tunnel wegvalt, moet het antwoord iets noemen dat het werkelijk doet, en een profiel dat alleen verbindt is dat antwoord niet.
Waar het eigenaarschap werkelijk verschilt
Lees dit als een eigenaarschapkaart en niet als een checklist, want de storingen hieronder zijn eigenaarschapsgaten en geen enkele hoeveelheid clientconfiguratie dicht ze. Elke rij noemt de laag, de kant die hem vandaag meestal houdt, en waar de leemte zich het eerst toont.
| 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 |
Koppel elke rij aan een observatie die u kunt herhalen, niet aan een gevoel over de client. Een naam die via de bedoelde resolver is opgelost, een route die verdwijnt wanneer de tunnel stopt, en een geblokkeerde verbinding na een gesimuleerde onderbreking zijn drie observaties die samen het grootste deel van de tabel dekken. Schrijf de observatie naast de eis die ze bewijst, en bewaar de mislukte, want een mislukte observatie is het enige deel van het verslag dat het volgende incident voorspelt.
Omzetten zonder overlappend eigenaarschap
De leveranciersclient en een NetworkManager-verbinding voor dezelfde dienst tegelijk laten lopen is de meest voorkomende manier waarop deze vergelijkingen misgaan. Beide installeren routes, beide kunnen DNS zetten en beide kunnen de firewalltoestand aanraken. Wat u dan meet is een derde opstelling die met het gedocumenteerde gedrag van geen van beide clients overeenkomt.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"De eerste opdracht vertelt of het profiel überhaupt een VPN-type is. De tweede toont het diensttype van de plug-in en welke geheimen zijn opgeslagen, wat telt wanneer een sleutel van een agent in plaats van uit het bestand wordt verwacht. Het journaal is de plek waar een plug-in die is geladen maar niet kon onderhandelen dat zegt. Als geen van de drie een probleem toont, zit de leemte in de beleidslagen boven de tunnel en niet in de verbinding.
Koppel de oude client los voordat u de nieuwe verbinding inschakelt, houd eindpunten en account identiek, en noteer welke component routes, resolverinstellingen en blokkering bezit. Die notitie is wat voorkomt dat de volgende update met twee eigenaren eindigt.