nmcli постоянно пита за паролата на VPN: запазете тайната локално

Същият профил, две сесии: свързва се от работния плот и забива през SSH на подкана, на която нищо не може да отговори. Нищо не е счупено и нито една настройка не е загубена. NetworkManager иска идентификационните данни от агент за тайни, а агентът за тайни е компонент на работния плот, който не съществува в сесията, която използвате.

Изпълнете последователността по-долу и тунелът ще се вдигне без графичен интерфейс, с уговорката, че запазването на тайна променя кой може да използва този профил.

Потвърдете диагнозата, преди да редактирате каквото и да е

Разликата между интерактивното и неинтерактивното активиране е цялата диагноза. Ако nmcli --ask connection up успее, докато обикновеното активиране забива, профилът е правилен и източникът на тайната липсва. Това единствено сравнение ви спестява пренаписването на работеща конфигурация.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

Четете флаговете, вместо да ги гадаете. Стойностите, които означават "питай агент", са това, което търсите, а точните имена на ключове се различават между добавките за VPN, защото живеят в собствения речник с данни на добавката. Профил FortiSSL и профил IPsec не използват непременно едни и същи имена, затова работете от изхода на собствения си профил.

Също така потвърдете, че пакетът на добавката за този протокол е инсталиран. Липсващата добавка се показва като неизвестен тип връзка или като грешка при активиране, която не казва нищо за паролите, а гоненето на тайната в това състояние прахосва същия час два пъти. Една заявка за пакет е по-евтина от цял следобед редактиране на файлове с ключове.

Преместете тайната във файла с ключове

Файлът за връзка живее под /etc/NetworkManager/system-connections/. Тайните не се пазят там по подразбиране и това е смисълът на флаговете, които току-що прочетохте. Промяната на флаг на нула казва на NetworkManager, че стойността се съхранява с профила, вместо да се иска при активиране.

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

За профил с две тайни моделът се повтаря: един флаг на тайна в секцията [vpn] и стойностите в [vpn-secrets]. Профилът IPsec обикновено носи предварително споделен ключ заедно с потребителските идентификационни данни, а добавката ги именува различно от обикновено поле за парола, затова копирайте имената на ключовете от изхода на vpn.data, а не от публикация в блог, използвала друга добавка. Едно грешно име на ключ създава профил, който се зарежда и след това се проваля при удостоверяване, което изглежда точно като грешна парола. Сравнете файла си с работещ профил от същата добавка, преди да се свържете отново.

Слагайте в кавички стойности, които съдържат интервали, кавички или знак за долар. Стойност без кавички със знак $ в нея ще бъде прочетена буквално или разгърната в зависимост от това къде се анализира, а получената грешка при удостоверяване изглежда като грешна парола.

След това оправете собствеността и режима на файла. Тези файлове с ключове се четат от привилегирована услуга и файл, който други потребители могат да четат, се третира като ненадежден, което е обичайната причина редактиран профил да изглежда пренебрегнат. Собственик root, режим 600, без изключения.

Презаредете, после активирайте

Файлът се чете при зареждане на връзката, така че редактирането му не е достатъчно. Презаредете профилите и след това вдигнете връзката изрично.

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

Ако презареждането не улови промяната, пълното рестартиране на услугата го прави и има съобщения точно за това. Предпочитайте презареждането, когато други връзки са важни, защото рестартирането на услугата прекъсва всяка управлявана връзка, а на отдалечен хост това може да сложи край на сесията ви, преди желаният тунел да е вдигнат.

Използвайте UUID, когато имената са двусмислени. Машините с няколко клиентски профила натрупват почти дубликати и активирането на грешния създава отказ, който изглежда като проблем с идентификационните данни.

Когато запазената тайна не е проблемът

Профил FortiSSL може да се провали дори с правилни запазени идентификационни данни, защото клиентът никога не се доверява на сертификата на шлюза. Тази настройка не е в главния диалог; тя е зад разширените опции за VPN, където се въвежда отпечатъкът на доверения сертификат. Ако журналът споменава сертификата, а не паролата, вие сте в този клон и никакво редактиране на [vpn-secrets] няма да помогне.

Тук принадлежат още две проверки. Потвърдете, че профилът не е импортиран от файл, който все още сочи към път, който добавката не може да прочете, и че профилът е активният, а не остарял дубликат. И двете дават откази при активиране, които се четат като грешки при удостоверяване.

Решете дали запазването е приемливо

Запазените PSK и парола могат да бъдат прочетени от всичко, което работи като root на тази машина. На машина, която контролирате, това е разумна сделка за услуга без графичен интерфейс. На споделен хост това заслужава разговор, защото профилът сега съдържа идентификационни данни, които преди са били защитени от ключодържателя на работния плот. Попитайте кой друг може да достигне root на този хост, преди да решите, а не след като промяната е на място.

Ако политиката забранява запазени тайни за VPN, не отслабвайте профила, за да проработи задача на cron. Стартирайте връзката от сесия, която има агент, или използвайте друг механизъм за автоматизацията.

Накрая, запишете кои профили носят тайни, за да не копира някой един на лаптоп, без да забележи. Коментар над секцията с тайни с датата и причината е достатъчен и ще спести на някого неудобно ревю по-късно.