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. Стартувајте ја врската од сесија што има агент или користете друг механизам за автоматизација.

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