Tarnija VPN-rakendus versus NetworkManager: kellele kuulub olek?
Profiil nimetab pluginat, mitte tarnija kliendi käitumist. Kaardista, kellele kuuluvad registreerimine, DNS, blokeerimine ja uuendused, enne kui vahetad hallatud sülearvuti.
Profiili importimine ei ole sama mis kliendi asendamine. NetworkManager hoiab plugina tüüpi koos pluginapõhiste andmete ja saladustega ning plugin, kellele see tüüp kuulub, otsustab, mida ühendus suudab teha. Kõik, mida tarnija rakendus selle peale laduda, registreerimisest kuni püsiva blokeerimiseni, elab väljaspool faili. Kas vahetus on ohutu, sõltub sellest, millele neist kihtidest te tegelikult loote.
Fail nimetab pluginat, mitte funktsioonide kogumit
NetworkManageri VPN-i seadete viide kirjeldab teenusetüüpi, mis valib plugina, lisaks läbipaistmatut andmesõnastikku ja saladuste sõnastikku, mida tõlgendab ainult plugin. Profiil on leping ühe teostusega, mitte kirjeldus käitumisest, mida ükskõik milline klient suudab korrata. Kaks klienti võivad rääkida sama protokolli ja siiski erineda selles, mida nad läbiräägivad ja milliseid andmeradu nad lubavad. Protokolli silt ütleb sulle, mis tunnel on, mitte kunagi seda, mida ümbritsev klient sellega teeb.
Võrrelge seega nõudeid, mitte ümbrisi. Küsimus ei ole, kas alternatiiv suudab ühenduda, sest tavaliselt suudab; küsimus on, kas iga nõue, mis tegi algse kliendi vastuvõetavaks, jääb ülemineku järel püsima. Kirjutage need nõuded üles enne, kui midagi paigaldate, muidu muutub võrdlus jahiks selle järele, mis esimesena katkeb.
Mida tarnija rakendus tunnel ümber lisab
Tarnijate kliendid koondavad tavaliselt registreerimise ja seadme seisundi kontrollid, teise faktori voo oma liidesega, püsiva blokeerimise, uuenduskanali ja tugitööriistad. Osa sellest seisab protokolli kõrval ja osa on eraldi toode, mis lihtsalt jagab paigaldajat. NetworkManager suudab tunneli ja selle marsruutimise asendada ning dispatch-skriptid saavad ühenduse oleku muutumisel toiminguid käivitada. See ei taasta blokeerimismootorit, sertifikaadi uuendamise voogu ega eeldust selle kohta, milline kasutaja tohib ühenduse püsti panna.
Rohkem komponente ei tähenda turvalisemat ja vähem ei tähenda nõrgemat. Küsimus on, milline komponent rakendab seda poliitikat, mida teil kästiti järgida. Kui audiitor küsib, mis blokeerib liikluse, kui tunnel langeb, peab vastus nimetama midagi, mis seda tõesti teeb, ja profiil, mis ainult ühendub, ei ole see vastus.
Kus omandisuhe tegelikult erineb
Lugege seda omandisuhete kaardina, mitte kontrollnimekirjana, sest allpool olevad tõrked on omandisuhete lüngad ja ükski kliendi seadistus neid ei sulge. Iga rida nimetab kihi, poole, kes seda täna tavaliselt hoiab, ja koha, kus lünk esimesena välja tuleb.
| 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 |
Seostage iga rida vaatlusega, mida saate korrata, mitte kliendi kohta käiva tundega. Kavandatud resolveri kaudu lahendatud nimi, marsruut, mis kaob, kui tunnel peatub, ja blokeeritud ühendus simuleeritud katkestuse järel on kolm vaatlust, mis koos katavad suurema osa tabelist. Kirjutage vaatlus selle nõude kõrvale, mida see tõestab, ja hoidke alles need, mis ebaõnnestusid, sest ebaõnnestunud vaatlus on ainus osa kirjest, mis ennustab järgmist juhtumit.
Vahetamine kattuvate omandisuhete vältimisega
Tarnija kliendi ja sama teenuse NetworkManageri ühenduse korraga käitamine on kõige tavalisem viis, kuidas need võrdlused viltu lähevad. Mõlemad paigaldavad marsruute, mõlemad võivad seada DNS-i ja mõlemad võivad puutuda tulemüüri olekut. Mida te siis mõõdate, on kolmas korraldus, mis ei vasta kummagi kliendi dokumenteeritud käitumisele.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"Esimene käsk ütleb, kas profiil on üldse VPN-i tüüpi. Teine näitab plugina teenusetüüpi ja seda, millised saladused on salvestatud, mis loeb siis, kui võtit oodatakse agendilt, mitte failist. Journal on koht, kus plugin, mis laaditi, kuid ei suutnud läbi rääkida, seda ütleb. Kui ükski kolmest probleemi ei näita, asub lünk tunnelist kõrgemal poliitikakihtides, mitte ühenduses.
Ühendage vana klient lahti enne uue ühenduse lubamist, hoidke lõpp-punktid ja konto identsed ning kirjutage üles, milline komponent omab marsruute, resolveri seadeid ja blokeerimist. Just see märkus takistab järgmisel uuendusel lõppeda kahe omanikuga.