Keyfile или Netplan: каде навистина се чува VPN профилот?

Наоѓањето на датотеката што ја увезовте е лесниот дел и често погрешен почеток. Важно е која датотека NetworkManager денес ја чита како зачувана врска, а тоа зависи од идентификаторот на врската и од конфигурацискиот бекенд што инсталираните пакети навистина го користат. Уредувањето на увозот пред да се одговори на тоа прашање е начинот на кој работен VPN станува две полуправилни конфигурации.

Увезената датотека не е зачуваниот профил

Три имиња лебдат околу секој VPN проблем: името на врската, името на датотеката што ја увезовте и виртуелниот интерфејс што се појавува кога тунелот ќе се крене. Ниту едно од нив не ја идентификува зачуваната конфигурација, а името на врската може да се уреди додека датотеката зад него го задржува својот првичен идентификатор.

Започнете со инвентар само за читање и изберете го саканиот VPN по идентификатор, а не по ознака:

nmcli -f NAME,UUID,TYPE connection show

Држете ги имињата на домаќините на крајните точки и ознаките за идентитет надвор од секој инвентар што го лепите во тикет. Корисниот дел се типот и идентификаторот; остатокот е контекст што на странец не му треба. Заматете го остатокот пред споделување и кажете дека сте го направиле тоа, за никој да не се прашува што значат празнините.

Локациите на keyfile не значат исто

Со нативниот keyfile приклучок, датотеките за врски можат да се појават во три директориуми, а разликата меѓу нив е постојаноста, не удобноста.

Уредувањето на копијата во време на извршување изгледа успешно до следното стартување, кога промената испарува и датотеката изгледа мистериозно вратена. Уредувањето на копијата што ја доставува пакетот работи додека надградбата не ја замени, што е побавна и збунувачка верзија на истата лекција.

Документацијата за keyfile додава детаљ што вреди да се почитува: тие датотеки можат да содржат приватни клучеви и лозинки, а NetworkManager игнорира секој keyfile што корисници други од root можат да го читаат или пишуваат. Проширувањето на дозволите на директориумот за да барате поставка го крши однесувањето при вчитување што сакавте да го испитате.

Кога Netplan ја поседува постојаноста

На Ubuntu, интеграцијата со NetworkManager опишана во документацијата на Netplan, достапна од 23.10, го менува местото каде живее трајната копија. За нетрајни врски таа запишува /etc/netplan/90-NM-<connection UUID>.yaml и генерира ефемерен NetworkManager профил под /run/NetworkManager/system-connections/.

Тоа е интеграција на дистрибуција, не правило за секое инсталирање на NetworkManager. Потврдете дека инсталираните пакети навистина ја користат пред да тргнете да барате YAML датотека. Запомнете и дека профилот во време на извршување може да биде генериран приказ на нешто друго, а не изворот што вреди да се уредува. Две команди проверка штедат еден час уредување на погрешната датотека.

Документираниот пример зачувува OpenVPN врска преку типот Netplan nm-devices со податоци за пренос на NetworkManager. Фактот што Netplan нема посебно толкување на одредено VPN поле не значи дека вашиот зачуван VPN е изгубен; тоа значи дека полето патува како непробојни податоци.

Преодните интерфејси не се профили

Активацијата создава привремени виртуелни врски и интерфејси што никогаш не биле наменети да останат. Интеграцијата намерно не запишува нова YAML датотека за секој од нив, па нивното отсуство во /etc/netplan не кажува ништо за тоа дали родителскиот профил е зачуван.

Ако ловите датотека што се појавува и исчезнува, веројатно гледате една од овие, а не вашата конфигурација. Проверете дали преживува рестартирање пред да извлечете каков било заклучок од нејзината содржина. Датотеката во време на извршување што исчезнува при рестартирање ви кажува дека никогаш не била изворот, и тоа едно набљудување ја пренасочува целата истрага. Исто така објаснува зошто уредувањето тогаш изгледаше успешно.

Тајни и сопственост

Профилот може да упатува на сертификат или клуч чуван сосема на друго место, а лозинката може да припаѓа на NetworkManager, да биде доставена од таен агент на корисничката сесија, или намерно да не биде зачувана. Затоа пронаоѓањето на една датотека решава многу малку за тоа што ќе бара стартувањето без надзор.

Прегледајте ги референците и знаменцата за тајни без да печатите тајни вредности. Најавата на работна површина може да го направи достапен агент што го немаше при подигнувањето, а копирањето на генерирана датотека во време на извршување не го репродуцира тој агент. Практичниот симптом е тунел што се поврзува кога некој ќе се најави и не успева кога машината стартува сама. Тој образец упатува на сопственост врз тајните, не на рутирање.

Правете ги одобрените промени преку менаџерот што ја поседува врската, потоа проверете го и зачуваниот идентификатор и ефективната врска. Држете еден траен сопственик, бидејќи независното уредување на увозот, генерираниот keyfile и YAML изворот остава три конкурентни објаснувања за тоа што ќе користи следното повторно поврзување. Изберете го она што навистина останува, уредете само тоа и забележете во тикетот која датотека сте ја третирале како авторитативна. Следниот човек ќе ви заблагодари за една линија потекло.