OpenVPN auth-user-pass: dosiero, stdin aŭ instigo? Kiel elekti

Tri aferoj decidas, kiun identigan fonton vi uzu: ĉu persono sidas ĉe la konzolo, ĉu la sekreto rajtas loĝi sur la disko, kaj ĉu alia procezo devas respondi la instigon. Se vi elektas malbone, la kliento raportas stdin-problemon dum la pasvorto estas tute valida, kaj tio senkiale sendas la plej multajn al la servilo. Elektu la vojon unue; la erarmesaĝoj havas sencon nur kiam vi scias, kiu vojo ilin kreis.

La tri kondiĉoj, kiuj tion decidas

La konsola instigo estas la sola vojo, kiu bezonas homon, do la sola, kiu silente malsukcesas en systemd-unuo aŭ ujo. Se persono lanĉas la klienton kaj tajpas la pasvorton, neniu dosiero partoprenas kaj nenio sentema alvenas sur la diskon. Se la kliento lanĉiĝas ĉe ekstarto, la sama instigo fariĝas pendado, kaj la tempolimo kutime aperas kiel ĝenerala konekta fiasko anstataŭ kiel identiga eraro.

Identiga dosiero estas la ĝusta respondo kiam la procezo lanĉiĝas senprizorge kaj la sekreto rajtas postvivi sur la disko sub kontrolita aro de permesoj. Kiam la sekreto tute ne rajtas esti skribita - politiko nur-koncerneja, mallongdaŭra ĵetono - vi bezonas fluon, kiun la kliento povas malfermi, kio praktike signifas procezan anstataŭigon aŭ helpanton skribantan en dosierpriskribilon. La administra interfaco kovras la kvaran kazon: regilo, kiu jam administras la vivciklon de la tunelo kaj povas respondi demandojn per soketo.

• Homo ĉe la konzolo, sen aŭtomatigo: interaga instigo.
• Senprizorga ekstarto, la sekreto rajtas esti konservita: identiga dosiero kun modo 0600.
• Senprizorga ekstarto, la sekreto ne rajtas esti konservita: proceza anstataŭigo aŭ fd, en kiun skribas sekreta agento.
• Alia procezo posedas la klienton: administra interfaco.

Kiam du respondoj taŭgas, preferu tiun, kiu tenas la sekreton ekster argv kaj ekster la ŝela historio. Pasvorto pasigita kiel programa argumento estas legebla de ĉiu loka uzanto per la proceza listo, kaj tiu elmontro estas malfacile malfarebla.

Kion ĉiu eniga vojo efektive faras

--auth-user-pass sola petas uzantnomon kaj pasvorton ĉe la konzolo. Donite dosiernomon, la kliento prenas linion unu kiel la uzantnomon kaj linion du kiel la pasvorton; nenio subtenas citilojn, komentojn aŭ ŝlosil-valoran sintakson. Tio estas la tuta formato, do ĉiu, kiu redaktas ĝin atendante INI-dosieron, difektas ĝin. Enlinia bloko <auth-user-pass> tenas la samajn du liniojn ene de la profilo, kio igas la profiton mem sekreto kaj metas ĝin en la saman traktan klason kiel privata ŝlosilo.

La aliaj du vojoj estas fluo kaj soketo. OpenVPN bezonas nur legeblan dosierpriskribilon, do ĝi akceptos procezan anstataŭigon, tuban /dev/fd-eron aŭ dosiernomon, kiu estas fakte FIFO. La administra interfaco estas malsama laŭ naturo: la kliento demandas superrigardan procezon pri la valoroj anstataŭ legi ilin mem. Tiu diferenco gravas ĉe rekonekto: identiga dosiero, FIFO en kiun sekreta helpanto povas denove skribi, kaj la administra interfaco povas reliveri sen persono; proceza anstataŭigo ne povas, ĉar la priskribilo eluziĝas ĉe la unua legado.

La dosiero devas esti ekzakte du linioj

Du fiaskmanieroj kovras la plej multajn difektitajn identigajn dosierojn. Vindozo-redaktilo lasas CRLF-finaĵojn, la karageda reveno fariĝas parto de la pasvorto, kaj la servilo malakceptas valoron, kiu ekrane ŝajnas ĝusta. Malplena dua linio - malplena linio tie, kie apartenas la pasvorto - lasas la klienton kun malplena pasvorto, kiun la servilo malakceptas eĉ kvankam la valoro ekrane aspektas ĝusta. Plia nova linio post la pasvorto estas sendanĝera. Skribu la dosieron el la ŝelo, ne el redaktilo, kaj kontrolu la bajtojn:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

La vojo same gravas kiel la enhavo. Relativa vojo solviĝas kontraŭ la labora dosierujo de la procezo, kiu por servo malofte estas la dosierujo, kie vi testis. Uzu absolutan vojon, igi la dosieron posedaĵo de la konto, kiu rulas la klienton, kaj tenu modon 0600 por ke grupo kaj aliuloj ne povu legi ĝin. La manlibro de OpenVPN 2.6 listigas la akceptitajn formojn de la direktivo; kontrolu ĝin antaŭ ol elpensi trian.

Testu la dosieron antaŭ ol kulpi la servilon. Ruli openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 presas, ĉu la dosiero malfermiĝis kaj, poste, ĉu la identigoj estis akceptitaj, kio diras al vi, kiun tavolon ŝanĝi poste.

Fluoj, stdin kaj la eraroj, kiujn ili produktas

Tubi la pasvorton estas la unua afero, kiun plej multaj provas, kaj la vojo kun la plej multaj surprizoj. Proceza anstataŭigo funkcias, ĉar la kliento bezonas nur legeblan priskribilon: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Pasigi /dev/stdin funkcias nur kiam stdin estas ankoraŭ malfermita kaj legebla en la momento, kiam la kliento demandas, kio ne veras en tubaro, kiu jam konsumis ĝin.

ERROR: could not read Auth username from stdin havas du malsamajn kaŭzojn. Ĉe iuj 2.3.x-klientoj la mesaĝo venis de stdin-traktada difekto, kiun pli postaj 2.3-eldonoj riparis, do tiom malnova kliento pliboniĝas nur per ĝisdatigo. Ĉe nuntempa kliento la sama vortumo signifas, ke la kliento petis konsolan enigon kaj stdin ne estis terminalo - ĝuste la situacio en systemd-unuo, cron-tasko aŭ ujo lanĉita sen -t.

auth-nocache aldonas trian buklon, kiu aspektas kiel difektita pasvorto. Ĝi forĵetas la identigojn el la memoro post uzo, do rekonekto kaŭzita de reta ŝanĝo havas nenion por reludi kaj la instigo revenas. Tio estas la direktivo laboranta kiel projektite. auth-nocache ŝanĝas tion, kion la kliento tenas en la memoro, ne tion, kion la servilo aŭ la identecprovizanto pensas pri la konto, do la tuta ripeto estas reliveri la saman dosieron, relegitan ĉe restartigo - kaj por administrata konekto tiu livero devus veni el la aprobita sekrettenejo, ne el pasvorto en skripto.

La administra interfaco kiam alia procezo posedas la instigon

Regilo, kiu jam superrigardas la tunelon, povas ankaŭ respondi ĝiajn demandojn. Lanĉu la klienton kun --management 127.0.0.1 7505, legu la statliniojn, kaj observu >PASSWORD:Need 'Auth' username/password. La regilo respondas per username "Auth" alice sekvata de password "Auth" ... sur apartaj komandlinioj. La ĵetono 'Auth' eĥas la identigilon el la peto kaj devas kongrui, alie la respondo estas ignorata kaj la kliento atendas.

La kosto estas stata maŝino, kiun vi nun posedas: konekta ordo, klientaj restartigoj, kaj loka soketo, kiun aliaj uzantoj sur la gastiganto ne rajtas atingi. Tion, kion vi aĉetas, estas identigo liverita dum plenumtempo, sen dosiero sur la disko kaj sen instigo, kiu povas pendi. Se nenio alia en via stako jam parolas la protokolon, tiu ĉi vojo aldonas komponanton prizorgendan.

Fiaskoj, kiuj aspektas kiel identigaj problemoj

TLS-manpremo, kiu neniam finiĝas, aŭ VERIFY ERROR: depth=0, error=certificate signature failure, estas fida problemo kaj okazas antaŭ ol iu ajn uzantnomo estas legata. Kliento proto tcp direktita al UDP-auskultanto fiaskas en la sama loko: la pakaĵoj neniam atingas la aŭtentigan fazon, do ĉiu pasvorto ŝajnas malĝusta pro asocio. Tenu la atestilan kontrolon ŝaltita antaŭ ol la identigo estas sendata; konata instigo diras nenion pri tio, kiu ricevas la pasvorton. Kontrolu la atestilan ĉenon, la komunan nomon kaj la transporton antaŭ ol tuŝi la identigon.

Ŝelaj cimoj en la skripto, kiu kunmetas la profiton, estas la alia falsa spuro. Mankanta spaco ene de [ ! -f "$file" ] produktas command not found, la skripto haltas frue, la profilo neniam estas rekonstruita, kaj la kliento ekas kun la antaŭa. Tiu eraro apartenas al la ŝelo, ne al aŭtentigo, kaj neniu kvanto da retajpado de la pasvorto forigos ĝin.

Ne ĉiu instigo en tiu ĉi fluo estas tiu ĉi identigo. Pasfrazo de privata ŝlosilo, HTTP-prokura ensaluto kaj la serva pasvorto estas tri malsamaj sekretoj petataj en malsamaj fazoj, kaj ŝlosilan pasfrazon kutime traktas la kliento aŭ agento anstataŭ auth-user-pass. Se la instigo aperas antaŭ ol la TLS-sesio staras, vi respondas la malĝustan demandon kaj nenia konta restarigo helpos. Post kiam la malĝusta instigo estas ekskludita, la ceteraj kontroloj komenciĝas ĉe la plej frua tavolo:

• Legu la unuan protokolan eraron, ne la lastan identigan linion: TLS, poste aŭtentigo, poste push.
• Konfirmu, ke la dosiero estas du linioj, havas neniujn karagedajn revenojn, kaj estas referencata per absoluta vojo.
• Konfirmu, ke la profilo kaj la komandlinio ne malkongruas pri la direktivo.
• Apartigu "identigoj akceptitaj" de "trafiko fluas" - enkursigo kaj DNS estas pli posta tavolo.

Kiam la kliento atingas la push-fazon, ĉesu rigardi la identigojn kaj komencu legi la itinerojn kaj DNS-servilojn, kiujn la servilo sendis. Tio estas la sekva problemo, kaj ĝi havas nenion komunan kun la pasvorto, kiun vi ĵus riparis.