Pse një shërbim VPN që niset gjatë boot nuk mund të lexojë vargun tënd të çelësave

Një lidhje që funksionon pas hyrjes dhe dështon përpara saj zakonisht do të thotë që përpjekja gjatë boot nuk arriti të marrë një sekret, jo se serveri refuzoi një. Kredenciali ekziston; konteksti që e kërkon, jo. Ky dallim i vetëm kursen një rivendosje të panevojshme të fjalëkalimit.

Ndiq kërkesën: diçka nis lidhjen përpara se të ekzistojë një sesion desktopi, dhe depoja e sekreteve që zakonisht përgjigjet nuk është shkyçur ende. Dy kontekstet nuk pajtohen se kujt i përket sekreti, dhe profili regjistron se cili prej tyre pritet ta furnizojë.

Çfarë kërkon në të vërtetë rruga e boot

Gjatë boot, NetworkManager niset si shërbim sistemi pa sesion përdoruesi, pa D-Bus sesioni dhe pa varg çelësash të shkyçur. Një profil lidhjeje mund të ngrihet gjithsesi, por vetëm me sekrete që shërbimi mund t'i arrijë vetë. Çdo gjë që zotërohet nga një agjent sekretesh pret derisa një njeri të hyjë dhe agjenti të shfaqet. Shërbimi bën saktësisht atë që thotë konfigurimi i tij; profili është ai që duhet ndryshuar.

Dështimi është shkruar në lidhje, jo i fshehur në një varg çelësash.

Leximi i flamujve të sekreteve në një lidhje

Pyet lidhjen çfarë pret, jo çfarë mban mend desktopi. Kolona e flamujve i përgjigjet pyetjes drejtpërdrejt, dhe mbijeton rinisjet në skedarin e profilit në disk.

Fillo me listën e profileve, pastaj konfirmo cila lidhje është caktuar të ngrihet vetë. Pastaj eksporto një lidhje dhe lexo flamujt e fjalëkalimit:

nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show
nmcli connection show "Work VPN" | grep -i -E "password|secret|key"
journalctl -b -u NetworkManager --grep "secret"

Komanda e parë konfirmon cilat profile ekzistojnë dhe nëse një është caktuar për lidhje automatike, që është mënyra se si nis fare një përpjekje pa mbikëqyrje. E dyta zbulon vlerat e flamujve, dhe e treta tregon shërbimin duke u ankuar se asnjë agjent nuk u përgjigj për një sekret të caktuar. Një rresht log që e quan një sekret në pronësi të agjentit është e gjithë diagnoza në një fjali.

Pse zhvendosja e lidhjes në sferën e sistemit ndryshon përgjigjen

Një lidhje në pronësi të një përdoruesi aktivizohet nën agjentin e atij përdoruesi, prandaj funksionon në mënyrë të përsosur sapo desktopi të jetë lart. Zhvendosja e saj në sferën e sistemit e heq agjentin nga rruga, kështu që i njëjti profil sillet ndryshe pa ndryshuar asnjë rresht të konfigurimit të VPN.

Kjo zhvendosje është një dizajn legitim, dhe mbart një kërkesë: sekreti duhet të jetë i arritshëm nga shërbimi i sistemit. Ruajtja e tij në profil, furnizimi përmes një kredenciali të sferës së sistemit, ose pranimi i një kërkese interaktive në momentin e duhur janë të gjitha përgjigje të vlefshme. Të lësh flamurin 1 dhe të shpresosh, jo.

Një çelës privat me frazën e vet të fjalëkalimit shton një shtresë të dytë. As një fjalëkalim llogarie i ruajtur nuk do të hapë një çelës që kërkon një frazë fjalëkalimi, prandaj verifiko cilin sekret po kërkon në të vërtetë faza që dështon përpara se të ndryshosh ndonjë gjë.

Çfarë të mos bësh dhe çfarë të bësh në vend të tij

Të bësh çdo skedar kredencialesh të lexueshëm nga të gjithë, ose të çaktivizosh autentikimin që të mos nevojitet asnjë kërkesë, e këmben një shqetësim nisjeje me një ekspozim të përhershëm. Të dyja fshehin edhe varësinë në vend që ta zgjidhin, dhe përditësimi i ardhshëm i imazhit rikthen të njëjtin dështim.

Në atë fazë përdor mekanizmin që shpërndarja jote dokumenton për aktivizim pa mbikëqyrje, pastaj konfirmo se flamujt e profilit përputhen me të. Kontrollo rezultatin nga një boot i pastër, jo nga një shell që ka tashmë një agjent. Shkruaj pronarin e lidhjes, burimin e sekretit dhe fazën që duhet të funksionojë, që një ndryshim i mëvonshëm i nisjes automatike të mos mundë të rikthejë në heshtje një varësi nga dikush që hap fillimisht një desktop. Dokumentacioni është ndryshimi midis një shërbimi të rregulluar dhe një që prishet përsëri tremujorin e ardhshëm.

Testo nga një boot i pastër i kontrolluar, jo nga një ripërpjekje manuale pas hyrjes. Ripërpjekja ka sukses për arsyen pse përpjekja gjatë boot dështoi, dhe pikërisht atë provë shkatërron një test i shpejtë.