Kāpēc sāknēšanas laikā startētais VPN pakalpojums nevar nolasīt tavu atslēgu saišķi

Savienojums, kas strādā pēc pieteikšanās un neizdodas pirms tās, parasti nozīmē, ka sāknēšanas mēģinājums nevarēja iegūt slepenu vērtību, nevis to, ka serveris to noraidīja. Akreditācijas dati pastāv; konteksts, kas tos pieprasa, nepastāv. Šī vienīgā atšķirība ietaupa nevajadzīgu paroles atiestatīšanu.

Seko pieprasījumam: kaut kas sāk savienojumu, pirms pastāv darbvirsmas sesija, un slepeno datu krātuve, kas parasti atbild, vēl nav atslēgta. Abi konteksti nevienojas par to, kam pieder slepenā vērtība, un profils reģistrē, no kura no tiem tiek gaidīts to nodrošināt.

Ko sāknēšanas ceļš patiesībā pieprasa

Sāknēšanas laikā NetworkManager startē kā sistēmas pakalpojums bez lietotāja sesijas, bez sesijas D-Bus un bez atslēgta atslēgu saišķa. Savienojuma profilu joprojām var pacelt, bet tikai ar slepenajām vērtībām, kurām pakalpojums pats var piekļūt. Viss, kas pieder slepeno datu aģentam, gaida, līdz cilvēks pieteicas un aģents parādās. Pakalpojums dara tieši to, ko saka tā konfigurācija; mainīt ir jāmaina profilu.

Kļūme ir ierakstīta pašā savienojumā, nevis paslēpta atslēgu saišķī.

Savienojuma slepeno karodziņu lasīšana

Jautā savienojumam, ko tas gaida, nevis ko atceras darbvirsma. Karodziņu kolonna atbild uz jautājumu tieši, un tā pārdzīvo pārstartēšanu profila failā uz diska.

Sāc ar profilu sarakstu, tad pārliecinies, kurš savienojums ir iestatīts pacelties pats. Tad izdrukā vienu savienojumu un izlasi paroles karodziņus:

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"

Pirmā komanda apstiprina, kuri profili pastāv un vai kāds ir iestatīts automātiskai savienošanai, tieši tā arī sākas uzraudzības mēģinājums. Otrā atklāj karodziņu vērtības, un trešā parāda pakalpojumu sūdzamies, ka neviens aģents nav atbildējis uz konkrētu slepeno vērtību. Žurnāla rinda, kas nosauc slepeno vērtību kā aģentam piederošu, ir visa diagnoze vienā teikumā.

Kāpēc savienojuma pārvietošana sistēmas jomā maina atbildi

Lietotājam piederošs savienojums tiek aktivizēts šī lietotāja aģenta pakļautībā, tāpēc tas lieliski darbojas, tiklīdz darbvirsma ir augšā. Pārvietojot to sistēmas jomā, aģents tiek noņemts no ceļa, tāpēc tas pats profils uzvedas citādi, nemainot nevienu VPN konfigurācijas rindu.

Šī pārvietošana ir likumīgs dizains, un tā nes prasību: slepenajai vērtībai jābūt pieejamai sistēmas pakalpojumam. Tās glabāšana profilā, nodrošināšana ar sistēmas jomas akreditācijas datiem vai interaktīva pieprasījuma pieņemšana īstajā brīdī ir visas derīgas atbildes. Atstāt karodziņu 1 un cerēt — nav.

Privāta atslēga ar savu paroles frāzi pievieno otru slāni. Pat saglabāta konta parole neatvērs atslēgu, kurai vajadzīga paroles frāze, tāpēc pirms kaut ko mainīt pārbaudi, kādu slepeno vērtību patiesībā pieprasa neizdevušais posms.

Ko nedarīt un ko darīt tā vietā

Padarīt katru akreditācijas datu failu lasāmu visiem vai izslēgt autentifikāciju, lai pieprasījums nebūtu vajadzīgs, ir sāknēšanas neērtības maiņa pret pastāvīgu atklātību. Abi arī slēpj atkarību, nevis to atrisina, un nākamais attēla atjauninājums atgriež to pašu kļūmi.

Šajā posmā izmanto mehānismu, ko tava distribūcija dokumentē bezuzraudzības aktivizēšanai, tad pārliecinies, ka profila karodziņi tam atbilst. Pārbaudi rezultātu no tīras sāknēšanas, nevis no čaulas, kurai jau ir aģents. Pieraksti savienojuma īpašnieku, slepenās vērtības avotu un posmu, kam jāstrādā, lai vēlāka automātiskās palaišanas izmaiņa nevarētu klusi atgriezt atkarību no tā, ka kāds vispirms atslēdz darbvirsmu. Dokumentācija ir atšķirība starp salabotu pakalpojumu un to, kas nākamajā ceturksnī atkal salūzt.

Pārbaudi no kontrolētas tīras sāknēšanas, nevis no manuāla atkārtota mēģinājuma pēc pieteikšanās. Atkārtotais mēģinājums izdodas tā iemesla dēļ, kāpēc sāknēšanas mēģinājums neizdevās, un tieši šos pierādījumus ātrs tests iznīcina.