Kial VPN-servo startigita ĉe la praŝarĝo ne povas legi vian ŝlosilringon

Konekto, kiu funkcias post ensaluto kaj malsukcesas antaŭ ĝi, kutime signifas, ke la praŝarĝa provo ne povis akiri sekreton, ne ke la servilo rifuzis unu. La legitimilo ekzistas; la kunteksto, kiu petas ĝin, ne. Tiu sola distingo ŝparas senbezonan restarigon de pasvorto.

Sekvu la peton: io startigas la konekton antaŭ ol ekzistas labortabla seanco, kaj la sekreta konservejo, kiu kutime respondas, ankoraŭ ne estas malŝlosita. La du kuntekstoj malkonsentas pri tio, kiu posedas la sekreton, kaj la profilo registras, kiu el ili devas liveri ĝin.

Kion la praŝarĝa vojo fakte petas

Ĉe la praŝarĝo, NetworkManager startas kiel sistema servo sen uzanta seanco, sen seanca D-Bus kaj sen malŝlosita ŝlosilringo. Konekta profilo tamen povas esti levita, sed nur per sekretoj, kiujn la servo povas atingi mem. Ĉio posedata de sekreta agento atendas, ĝis homo ensalutos kaj la agento aperos. La servo faras ĝuste tion, kion diras ĝia agordo; la profilo estas tio, kio devas ŝanĝiĝi.

La malsukceso estas skribita en la konekton, anstataŭ kaŝita en ŝlosilringo.

Legi la sekretajn flagojn de konekto

Demandu la konekton, kion ĝi atendas, ne kion la labortablo memoras. La flaga kolumno respondas la demandon rekte, kaj ĝi postvivas restartigojn en la profila dosiero sur la disko.

Komencu per la profila listo, poste konfirmu, kiu konekto estas agordita por leviĝi mem. Poste elŝutu unu konekton kaj legu la pasvortajn flagojn:

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"

La unua komando konfirmas, kiuj profiloj ekzistas kaj ĉu unu estas agordita por aŭtomata konektado, kio estas kiel senzorga provo komenciĝas entute. La dua malkaŝas la flagajn valorojn, kaj la tria montras la servon plendanta, ke neniu agento respondis por donita sekreto. Protokola linio, kiu nomas sekreton agent-posedata, estas la tuta diagnozo en unu frazo.

Kial movi la konekton al sistema amplekso ŝanĝas la respondon

Konekto posedata de uzanto aktiviĝas sub la agento de tiu uzanto, tial ĝi funkcias perfekte post kiam la labortablo leviĝis. Movi ĝin al sistema amplekso forigas la agenton el la vojo, do la sama profilo kondutas alie sen ŝanĝi eĉ unu linion de VPN-agordo.

Tiu movo estas legitima dezajno, kaj ĝi portas postulon: la sekreto devas esti atingebla de la sistema servo. Konservi ĝin en la profilo, provizi ĝin per legitimilo de sistema amplekso aŭ akcepti interagan instigon je la ĝusta momento estas ĉiuj validaj respondoj. Lasi flagon 1 kaj esperi ne estas.

Privata ŝlosilo kun propra pasfrazo aldonas duan tavolon. Eĉ konservita konta pasvorto ne malŝlosos ŝlosilon, kiu postulas pasfrazon, do kontrolu, kiun sekreton la malsukcesanta etapo fakte petas, antaŭ ol ŝanĝi ion.

Kion ne fari kaj kion fari anstataŭe

Fari ĉiun legitimilan dosieron legebla por ĉiuj aŭ malŝalti aŭtentikigon tiel, ke instigo ne necesas, interŝanĝas startan ĝenon kontraŭ permanenta elmeto. Ambaŭ ankaŭ kaŝas la dependon anstataŭ solvi ĝin, kaj la sekva bilda ĝisdatigo reenkondukas la saman malsukceson.

Uzu la mekanismon, kiun via distribuo dokumentas por senzorga aktivigo ĉe tiu etapo, poste konfirmu, ke la flagoj de la profilo kongruas kun ĝi. Kontrolu la rezulton el pura praŝarĝo, ne el ŝelo, kiu jam havas agenton. Notu la posedanton de la konekto, la fonton de la sekreto kaj la etapon, kiu devas funkcii, por ke posta ŝanĝo de aŭtostarto ne povu silente reenkonduki dependecon de tio, ke iu unue malŝlosu labortablon. Dokumentado estas la diferenco inter riparita servo kaj unu, kiu denove rompiĝas en la venonta kvaronjaro.

Testu el kontrolita pura praŝarĝo, ne el permana reprovo post ensaluto. La reprovo sukcesas pro la kialo, pro kiu la praŝarĝa provo malsukcesis, kaj ĝuste tiun pruvon rapida testo detruas.