nmcli spør stadig om VPN-passordet: lagre hemmelegheita lokalt

Same profil, to økter: han koplar til frå skrivebordet og heng over SSH på ein førespurnad som ingenting kan svare på. Ingenting er øydelagt, og ingen innstilling er tapt. NetworkManager ber ein hemmelegheitsagent om legitimasjonen, og ein hemmelegheitsagent er ein skrivebordskomponent som ikkje finst i økta du brukar.

Køyr sekvensen nedanfor, og tunnelen kjem opp utan skjerm, med atterhald om at lagring av ei hemmelegheit endrar kven som kan bruke profilen.

Stadfest diagnosen før du endrar noko

Skilnaden mellom interaktiv og ikkje-interaktiv aktivering er heile diagnosen. Viss nmcli --ask connection up lukkast medan ei vanleg aktivering heng, er profilen riktig, og kjelda til hemmelegheita manglar. Den eine samanlikninga sparer deg for å skrive om ein fungerande konfigurasjon.

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

Les flagga i staden for å gjette på dei. Verdiar som tyder "spør ein agent", er det du leitar etter, og dei nøyaktige nøkkelnamna varierer mellom VPN-programtillegg fordi dei bur i programtillegget sitt eige dataordbok. Ein FortiSSL-profil og ein IPsec-profil brukar ikkje nødvendigvis dei same namna, så arbeid ut frå utdata frå din eigen profil.

Stadfest òg at programtilleggspakken for den protokollen er installert. Eit manglande programtillegg viser seg som ein ukjend tilkoplingstype eller som ein aktiveringsfeil som ikkje seier noko om passord, og å jage hemmelegheita i den tilstanden kastar bort den same timen to gonger. Éin pakkeførespurnad er billegare enn ein heil ettermiddag med å redigere nøkkelfiler.

Flytt hemmelegheita inn i nøkkelfila

Tilkoplingsfila ligg under /etc/NetworkManager/system-connections/. Hemmelegheiter blir ikkje lagra der som standard, og det er poenget med flagga du nettopp las. Å setje eit flagg til null fortel NetworkManager at verdien er lagra med profilen i staden for å bli spurd om ved aktivering.

[vpn]
password-flags=0

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

For ein profil med to hemmelegheiter blir mønsteret gjenteke: eitt flagg per hemmelegheit i [vpn]-delen, og verdiane i [vpn-secrets]. Ein IPsec-profil har vanlegvis ein førehandsdelt nøkkel ved sida av brukarlegitimasjonen, og programtillegget namngir dei annleis enn eit vanleg passordfelt, så kopier nøkkelnamna frå vpn.data-utdata i staden for frå eit blogginnlegg som brukte eit anna programtillegg. Eitt feil nøkkelnamn gir ein profil som blir lasta og deretter feilar ved autentisering, noko som les nøyaktig som eit feil passord. Samanlikn fila di med ein fungerande profil frå same programtillegg før du koplar til igjen.

Set anførselsteikn rundt verdiar som inneheld mellomrom, anførselsteikn eller eit dollarteikn. Ein verdi utan anførselsteikn med eit $ i seg blir lesen bokstaveleg eller utvida avhengig av kvar han blir parsa, og autentiseringsfeilen som følgjer ser ut som eit feil passord.

Ret deretter eigarskap og modus for fila. Desse nøkkelfilene blir lesne av ein privilegert teneste, og ei fil som andre brukarar kan lese, blir handsama som upåliteleg, som er den vanlege grunnen til at ein redigert profil ser ut til å bli ignorert. Eigaren root, modus 600, ingen unntak.

Last inn på nytt, og aktiver deretter

Fila blir lesen når tilkoplinga blir lasta, så det er ikkje nok å redigere henne. Last inn profila på nytt og løft deretter tilkoplinga eksplisitt.

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

Viss innlastinga ikkje fangar opp endringa, gjer ein full omstart av tenesta det, og det finst rapportar om nettopp dette. Føretrekk innlastinga når andre lenkjer betyr noko, fordi omstart av tenesta bryt kvar administrert tilkopling, og på ein ekstern vert kan det avslutte økta di før tunnelen du ville ha, er oppe.

Bruk UUID når namna er tvitydige. Maskinar med fleire kundeprofilar samlar nesten-duplikat, og aktivering av feil gir ein feil som ser ut som eit problem med legitimasjonen.

Når den lagra hemmelegheita ikkje er problemet

Ein FortiSSL-profil kan feile sjølv med riktig lagra legitimasjon fordi klienten aldri stolar på sertifikatet til gatewayen. Innstillinga er ikkje i hovuddialogen; ho ligg bak avanserte val for VPN, der samandraget av det betrudde sertifikatet blir lagt inn. Viss loggen nemner sertifikatet i staden for passordet, er du i denne greina, og inga mengd redigering av [vpn-secrets] hjelper.

To kontrollar til høyrer heime her. Stadfest at profilen ikkje vart importert frå ei fil som framleis peikar på ein bane programtillegget ikkje kan lese, og stadfest at profilen er den aktive og ikkje ein utdatert duplikat. Begge gir aktiveringsfeil som les som autentiseringsfeil.

Avgjer om lagring er akseptabelt

Ein lagra PSK og eit passord kan lesast av alt som køyrer som root på den maskinen. På ein maskin du kontrollerer, er det eit rimeleg bytte for ei teneste utan skjerm. På ein delt vert fortener det ein samtale, fordi profilen no inneheld legitimasjon som tidlegare var verna av skrivebordets nøkkelring. Spør kven andre som kan nå root på den verten før du bestemmer deg, ikkje etter at endringa er på plass.

Viss policyen forbyr lagra VPN-hemmelegheiter, må du ikkje svekkje profilen for å få ein cron-jobb til å verke. Køyr tilkoplinga frå ei økt som har ein agent, eller bruk ein annan mekanisme for automatiseringa.

Til slutt, noter kva profilar som ber hemmelegheiter, slik at ingen kopierer ein til ein berbar PC utan å merke det. Ein kommentar over hemmelegheitsdelen med datoen og grunnen er nok, og han sparer nokon for ein pinleg gjennomgang seinare.