Bakit hindi mabasa ng VPN service na nagsisimula sa boot ang iyong keyring

Ang koneksyong gumagana pagkatapos ng login at nabibigo bago iyon ay karaniwang nangangahulugang hindi nakakuha ng secret ang pagtatangka sa boot, hindi na tinanggihan ng server ang isa. Umiiral ang credential; wala ang kontekstong humihingi nito. Ang nag-iisang pagkakaibang iyon ay nagtitipid ng hindi kailangang pag-reset ng password.

Sundin ang kahilingan: may nagsisimula ng koneksyon bago pa umiral ang desktop session, at ang imbakan ng secret na karaniwang sumasagot ay hindi pa nakabukas. Hindi nagkakasundo ang dalawang konteksto kung kanino ang secret, at itinatala ng profile kung alin sa kanila ang inaasahang magbibigay nito.

Ano ba talaga ang hinihingi ng boot path

Sa boot, nagsisimula ang NetworkManager bilang system service na walang user session, walang session D-Bus at walang nakabukas na keyring. Maaari pa ring iangat ang isang connection profile, ngunit gamit lamang ang mga secret na kayang abutin ng serbisyo mismo. Ang anumang pag-aari ng secret agent ay naghihintay hanggang may tao na mag-login at lumitaw ang agent. Ginagawa ng serbisyo ang eksaktong sinasabi ng configuration nito; ang profile ang kailangang baguhin.

Nakasulat ang kabiguan sa koneksyon, hindi nakatago sa keyring.

Pagbasa ng mga secret flag sa isang koneksyon

Tanungin ang koneksyon kung ano ang inaasahan nito, hindi kung ano ang natatandaan ng desktop. Direktang sinasagot ng column ng flag ang tanong, at nakakaligtas ito sa mga reboot sa profile file sa disk.

Magsimula sa listahan ng profile, pagkatapos ay tiyakin kung aling koneksyon ang nakatakdang umangat nang mag-isa. Pagkatapos ay i-dump ang isang koneksyon at basahin ang mga flag ng password:

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"

Kinukumpirma ng unang utos kung aling mga profile ang umiiral at kung may isang nakatakda sa autoconnect, na siyang paraan kung paano nagsisimula ang isang pagtatangkang walang pagmamatyag. Inilalantad ng pangalawa ang mga halaga ng flag, at ipinapakita ng pangatlo ang serbisyong nagrereklamo na walang agent na sumagot para sa isang partikular na secret. Ang log line na tumatawag sa isang secret na pag-aari ng agent ay ang buong diagnosis sa isang pangungusap.

Bakit binabago ng paglipat ng koneksyon sa system scope ang sagot

Ang koneksyong pag-aari ng user ay ina-activate sa ilalim ng agent ng user na iyon, kaya perpekto itong gumagana kapag nakataas na ang desktop. Ang paglipat nito sa system scope ay nag-aalis ng agent sa landas, kaya kakaiba ang kilos ng parehong profile nang walang binagong isang linya ng configuration ng VPN.

Ang paglipat na iyon ay lehitimong disenyo, at may dalang kahilingan: dapat maabot ng system service ang secret. Ang pag-iimbak nito sa profile, pagbibigay nito sa pamamagitan ng credential sa system scope, o pagtanggap ng interactive na prompt sa tamang sandali ay lahat ng wastong sagot. Ang iwanan ang flag 1 at umasa ay hindi.

Ang pribadong key na may sariling passphrase ay nagdadagdag ng ikalawang layer. Kahit ang nakaimbak na password ng account ay hindi magbubukas ng key na humihingi ng passphrase, kaya tiyakin kung aling secret ang hinihingi ng nabibigong yugto bago magbago ng anuman.

Ano ang hindi dapat gawin, at ano ang dapat gawin sa halip

Ang gawing nababasa ng lahat ang bawat credential file, o i-disable ang authentication para hindi na kailanganin ang prompt, ay ipinagpapalit ang abala sa pagsisimula sa permanenteng pagkakalantad. Itinatago rin ng dalawa ang dependency sa halip na lutasin ito, at ibinabalik ng susunod na pag-update ng image ang parehong kabiguan.

Sa yugtong iyon gamitin ang mekanismong idinodokumento ng iyong distribution para sa activation na walang pagmamatyag, pagkatapos ay tiyakin na tumutugma rito ang mga flag ng profile. Suriin ang resulta mula sa malinis na boot, hindi mula sa shell na mayroon nang agent. Isulat ang may-ari ng koneksyon, ang pinagmulan ng secret at ang yugtong dapat gumana, upang hindi maipasok muli nang tahimik ng susunod na pagbabago sa autostart ang dependency sa taong magbubukas muna ng desktop. Ang dokumentasyon ang pagkakaiba ng naayos na serbisyo at ng isang masisira muli sa susunod na quarter.

Subukan mula sa kontroladong malinis na boot, hindi mula sa manu-manong pagsubok muli pagkatapos ng login. Nagtagumpay ang pagsubok muli dahil sa dahilan kung bakit nabigo ang pagtatangka sa boot, at iyon mismo ang ebidensiyang sinisira ng mabilis na pagsubok.