nmcli daŭre petas la VPN-pasvorton: konservu la sekreton loke

Sama profilo, du seancoj: ĝi konektiĝas de la labortablo kaj pendas tra SSH ĉe peto, kiun nenio povas respondi. Nenio estas difektita kaj neniu agordo perdiĝis. NetworkManager petas la legitimilon de sekreta agento, kaj sekreta agento estas labortabla komponanto, kiu ne ekzistas en la seanco, kiun vi uzas.

Rulu la sekvan sinsekvon kaj la tunelo leviĝos sen grafika interfaco, kun la atento, ke konservi sekreton ŝanĝas, kiu povas uzi tiun profilon.

Konfirmu la diagnozon antaŭ ol ŝanĝi ion ajn

La diferenco inter interaga kaj neinteraga aktivigo estas la tuta diagnozo. Se nmcli --ask connection up sukcesas dum ordinara aktivigo haltas, la profilo estas ĝusta kaj la fonto de la sekreto mankas. Tiu unu komparo ŝparas al vi reverki funkciantan agordon.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

Legu la flagojn anstataŭ diveni ilin. Valoroj, kiuj signifas "demandu agenton", estas tio, kion vi serĉas, kaj la precizaj ŝlosilnomoj diferencas inter VPN-aldonaĵoj ĉar ili loĝas en la propra datena vortaro de la aldonaĵo. FortiSSL-profilo kaj IPsec-profilo ne nepre uzas la samajn nomojn, do laboru el la eligoj de via propra profilo.

Ankaŭ konfirmu, ke la aldonaĵpakaĵo por tiu protokolo estas instalita. Mankanta aldonaĵo montriĝas kiel nekonata konekttipo aŭ kiel aktiviga eraro, kiu diras nenion pri pasvortoj, kaj ĉasi la sekreton en tiu stato malŝparas la saman horon dufoje. Unu pakaĵdemando estas pli malmultekosta ol tuta posttagmezo da redaktado de ŝlosildosieroj.

Movu la sekreton en la ŝlosildosieron

La konekta dosiero loĝas sub /etc/NetworkManager/system-connections/. Sekretoj ne estas konservataj tie defaŭlte, kaj tio estas la senco de la flagoj, kiujn vi ĵus legis. Ŝanĝi flagon al nulo diras al NetworkManager, ke la valoro estas konservata kun la profilo anstataŭ petata ĉe aktivigo.

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

Por profilo kun du sekretoj la ŝablono ripetiĝas: unu flago por sekreto en la sekcio [vpn], kaj la valoroj en [vpn-secrets]. IPsec-profilo kutime portas antaŭe kunhavigitan ŝlosilon apud la uzanta legitimilo, kaj la aldonaĵo nomas ilin malsame ol ordinara pasvortkampo, do kopiu la ŝlosilnomojn el la eligo de vpn.data anstataŭ el blogaĵo, kiu uzis alian aldonaĵon. Unu malĝusta ŝlosilnomo produktas profilon, kiu ŝargiĝas kaj poste malsukcesas ĉe aŭtentigo, kio legiĝas ekzakte kiel malĝusta pasvorto. Komparu vian dosieron kun funkcianta profilo de la sama aldonaĵo antaŭ ol rekonekti.

Metu en citilojn valorojn, kiuj enhavas spacojn, citilojn aŭ dolarsignon. Valoro sen citiloj kun $ ene estos legata laŭvorte aŭ etendata laŭ tio, kie ĝi estas analizata, kaj la rezulta aŭtentiga malsukceso aspektas kiel malĝusta pasvorto.

Poste riparu la posedon kaj reĝimon de la dosiero. Ĉi tiujn ŝlosildosierojn legas privilegia servo, kaj dosiero, kiun aliaj uzantoj povas legi, estas traktata kiel nefidinda, kio estas la kutima kialo, ke redaktita profilo ŝajnas esti ignorata. Posedanto root, reĝimo 600, neniuj esceptoj.

Reŝargu, poste aktivigu

La dosiero estas legata kiam la konekto ŝargiĝas, do redakti ĝin ne sufiĉas. Reŝargu la profilojn kaj poste levu la konekton eksplicite.

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

Se la reŝargo ne kaptas la ŝanĝon, plena restartigo de la servo faras tion, kaj ekzistas raportoj pri ĝuste tio. Preferu la reŝargon kiam aliaj ligiloj gravas, ĉar restartigi la servon rompas ĉiun administratajn konektojn, kaj sur fora gastiganto tio povas fini vian seancon antaŭ ol la dezirata tunelo leviĝas.

Uzu la UUID kiam nomoj estas ambiguaj. Maŝinoj kun pluraj klientaj profiloj amasigas preskaŭ-duplikatojn, kaj aktivigi la malĝustan produktas malsukceson, kiu aspektas kiel legitimila problemo.

Kiam la konservita sekreto ne estas la problemo

FortiSSL-profilo povas malsukcesi eĉ kun ĝusta konservita legitimilo, ĉar la kliento neniam fidas la atestilon de la pordego. Tiu agordo ne estas en la ĉefa dialogo; ĝi estas malantaŭ la altnivelaj opcioj por la VPN, kie la resumo de la fidinda atestilo estas enigata. Se la protokolo mencias la atestilon anstataŭ la pasvorton, vi estas en ĉi tiu branĉo kaj neniu kvanto da redaktado de [vpn-secrets] helpos.

Du pliaj kontroloj apartenas ĉi tien. Konfirmu, ke la profilo ne estis importita el dosiero, kiu ankoraŭ montras al vojo, kiun la aldonaĵo ne povas legi, kaj konfirmu, ke la profilo estas la aktiva, ne malnova duplikato. Ambaŭ produktas aktivigajn malsukcesojn, kiuj legiĝas kiel aŭtentigaj eraroj.

Decidu, ĉu konservado estas akceptebla

Konservita PSK kaj pasvorto estas legelaj de io ajn, kio rulas kiel root sur tiu maŝino. Sur skatolo, kiun vi kontrolas, tio estas racia interŝanĝo por servo sen grafika interfaco. Sur kunhavigita gastiganto ĝi meritas konversacion, ĉar la profilo nun enhavas legitimilon, kiun antaŭe protektis la labortabla ŝlosilringo. Demandu, kiu alia povas atingi root sur tiu gastiganto antaŭ ol decidi, ne post kiam la ŝanĝo estas en loko.

Se politiko malpermesas konservitajn VPN-sekretojn, ne malfortigu la profilon por igi cron-taskon funkcii. Rulu la konekton el seanco, kiu havas agenton, aŭ uzu alian mekanismon por la aŭtomatigo.

Fine, notu, kiuj profiloj portas sekretojn, por ke neniu kopiu unu al tekkomputilo sen rimarki. Komento super la sekreta sekcio kun la dato kaj la kialo sufiĉas, kaj ĝi ŝparos al iu ĝenan revizion poste.