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 източник оставя три конкуриращи се обяснения кое ще използва следващото повторно свързване. Изберете това, което наистина се запазва, редактирайте само него и отбележете в тикета кой файл сте приели за авторитетен. Следващият човек ще ви благодари за един ред произход.