Приложение VPN от доставчика срещу NetworkManager: кой притежава състоянието?
Профилът именува плъгин, а не поведението на клиента на доставчика. Направете карта кой притежава регистрацията, DNS, блокирането и обновяванията, преди да смените управляван лаптоп.
Импортирането на профил не е същото като смяна на клиент. NetworkManager съхранява тип плъгин заедно със специфични за плъгина данни и тайни, и плъгинът, който притежава този тип, решава какво може да прави връзката. Всичко, което приложението на доставчика добавя отгоре, от регистрацията до постоянното блокиране, живее извън файла. Дали смяната е безопасна зависи от това на кои от тези слоеве наистина разчитате.
Файлът именува плъгин, а не набор от функции
Справочникът за настройките на VPN на NetworkManager описва тип услуга, който избира плъгина, плюс непрозрачен речник с данни и речник с тайни, които тълкува само плъгинът. Профилът е договор с една реализация, а не описание на поведение, което всеки клиент може да възпроизведе. Два клиента могат да говорят по един и същ протокол и пак да се различават по това какво договарят и кои пътища за данни включват. Етикетът на протокола ви казва какво е тунелът, но никога какво прави с него обкръжаващият клиент.
Затова сравнявайте изисквания, а не обвивки. Въпросът не е дали алтернативата се свързва, защото обикновено може; въпросът е дали всяко изискване, което е правила оригиналния клиент приемлив, оцелява при преместването. Запишете тези изисквания, преди да инсталирате каквото и да е, иначе сравнението се превръща в търсене на това, което ще се счупи първо.
Какво добавя приложението на доставчика около тунела
Клиентите на доставчици обикновено обединяват регистрация и проверки на състоянието на устройството, поток за втори фактор със собствен интерфейс, постоянно блокиране, канал за обновявания и инструменти за поддръжка. Част от това стои до протокола, а част е отделен продукт, който просто споделя инсталатор. NetworkManager може да замени тунела и маршрутизацията му, а скриптовете на диспечера могат да задействат действия при промяна на състоянието на връзката. Той не възпроизвежда машина за блокиране, процес за подновяване на сертификат или допускане кой потребител може да вдигне връзката.
Повече компоненти не означава по-безопасно, а по-малко не означава по-слабо. Въпросът е кой компонент налага политиката, която са ви казали да следвате. Ако одитор попита какво блокира трафика, когато тунелът падне, отговорът трябва да назове нещо, което наистина го прави, и профил, който само се свързва, не е този отговор.
Къде собствеността наистина се различава
Четете това като карта на собствеността, а не като контролен списък, защото отказите по-долу са пропуски в собствеността и никакво количество конфигурация на клиента не ги затваря. Всеки ред назовава слоя, страната, която обикновено го държи днес, и къде пропускът се появява първо.
| 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 |
Свържете всеки ред с наблюдение, което можете да повторите, а не с усещане за клиента. Име, разрешено чрез предвидения резолвер, маршрут, който изчезва, когато тунелът спре, и блокирана връзка след симулирано прекъсване са три наблюдения, които заедно покриват по-голямата част от таблицата. Запишете наблюдението до изискването, което доказва, и запазете неуспешните, защото неуспешното наблюдение е единствената част от записа, която предсказва следващия инцидент.
Превключване без припокриваща се собственост
Едновременното пускане на клиента на доставчика и на връзка NetworkManager за същата услуга е най-честият начин тези сравнения да се объркат. И двете инсталират маршрути, и двете може да задават DNS, и двете може да пипат състоянието на защитната стена. Това, което после измервате, е трета подредба, която не отговаря на документираното поведение на нито един от двата клиента.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"Първата команда ви казва дали профилът изобщо е от тип VPN. Втората показва типа услуга на плъгина и кои тайни са запазени, което има значение, когато ключ се очаква от агент, а не от файла. Журналът е мястото, където плъгин, който се е заредил, но не е успял да договори, ще го каже. Ако нито една от трите не показва проблем, пропускът е в слоевете на политиката над тунела, а не във връзката.
Изключете стария клиент, преди да включите новата връзка, запазете крайните точки и акаунта еднакви и запишете кой компонент притежава маршрутите, настройките на резолвера и блокирането. Тази бележка е това, което спира следващото обновяване да завърши с двама собственици.