OpenVPN auth-user-pass: faili, stdin au ombi? Jinsi ya kuchagua

Mambo matatu yanaamua chanzo cha vitambulisho cha kutumia: kama mtu amekaa kwenye konsoli, kama siri inaweza kuishi kwenye diski, na kama mchakato mwingine unapaswa kujibu ombi. Ukichagua vibaya, mteja huripoti tatizo la stdin wakati neno la siri ni halali kabisa, na hilo hupeleka wengi kwa seva bila sababu. Chagua njia kwanza; ujumbe wa makosa una maana tu ukiwa unajua ni njia gani iliyoyazalisha.

Masharti matatu yanayoamua

Ombi la konsoli ni njia pekee inayohitaji mtu, kwa hiyo ndiyo pekee inayoshindwa kimya katika kitengo cha systemd au kontena. Ikiwa mtu aandaa mteja na kuandika neno la siri, hakuna faili inayohusika na hakuna kitu nyeti kinachoishia kwenye diski. Ikiwa mteja anaanza wakati wa boot, ombi hilo hilo linakuwa kusimama, na muda wa kumalizika kwa kawaida huonekana kama kushindwa kwa muunganisho kwa ujumla badala ya hitilafu ya vitambulisho.

Faili ya vitambulisho ni jibu sahihi wakati mchakato unaanza bila usimamizi na siri inaweza kuendelea kwenye diski chini ya seti iliyodhibitiwa ya ruhusa. Wakati siri haipaswi kuandikwa kabisa - sera ya hazina pekee, tokeni ya muda mfupi - unahitaji mtiririko ambao mteja anaweza kufungua, ambayo kwa vitendo inamaanisha badala ya mchakato au msaidizi anayeandika kwenye kielekezi cha faili. Kiolesura cha usimamizi kinashughulikia kesi ya nne: kidhibiti ambacho tayari kinasimamia mzunguko wa maisha ya handaki na kinaweza kujibu maswali kupitia soketi.

• Mtu kwenye konsoli, hakuna automatisering: ombi la mwingiliano.
• Kuanza bila usimamizi, siri inaweza kuhifadhiwa: faili ya vitambulisho yenye hali 0600.
• Kuanza bila usimamizi, siri haiwezi kuhifadhiwa: badala ya mchakato au fd ambayo wakala wa siri anaandika.
• Mchakato mwingine unamiliki mteja: kiolesura cha usimamizi.

Wakati majibu mawili yanafaa, chagua lile linaloweka siri nje ya argv na nje ya historia ya shell. Neno la siri linalopitishwa kama hoja ya programu linaweza kusomwa na mtumiaji yeyote wa ndani kupitia orodha ya michakato, na ufichuzi huo ni mgumu kuubatilisha.

Kila njia ya kuingiza inafanya nini kwa kweli

--auth-user-pass peke yake huuliza jina la mtumiaji na neno la siri kwenye konsoli. Ikapewa jina la faili, mteja huchukua mstari wa kwanza kama jina la mtumiaji na wa pili kama neno la siri; hakuna kinachotumia nukuu, maoni au sintaksia ya ufunguo-thamani. Hiyo ndiyo muundo wote, kwa hiyo yeyote anayeihariri akitarajia faili ya INI huivunja. Kizuizi cha <auth-user-pass> cha ndani kinahifadhi mistari hiyo miwili ndani ya wasifu, jambo linalofanya wasifu wenyewe kuwa siri na kuiweka katika darasa lile lile la utunzaji kama ufunguo wa faragha.

Njia nyingine mbili ni mtiririko na soketi. OpenVPN inahitaji tu kielekezi cha faili kinachosomeka, kwa hiyo itakubali badala ya mchakato, ingizo la /dev/fd linaloungwa mkono na bomba au jina la faili ambalo kwa kweli ni FIFO. Kiolesura cha usimamizi ni tofauti kwa asili: mteja huuliza mchakato wa usimamizi thamani badala ya kuzisoma yeye mwenyewe. Tofauti hiyo ni muhimu wakati wa kuunganisha tena: faili ya vitambulisho, FIFO ambayo msaidizi wa siri anaweza kuandika tena na kiolesura cha usimamizi vinaweza kutoa tena bila mtu; badala ya mchakato haiwezi, kwa sababu kielekezi kinatumika kwenye usomaji wa kwanza.

Faili lazima iwe mistari miwili hasa

Mifumo miwili ya kushindwa inashughulikia faili nyingi za vitambulisho zilizovunjika. Kihariri cha Windows huacha miisho ya CRLF, kurudi kwa gari kunakuwa sehemu ya neno la siri, na seva inakataa thamani inayoonekana sahihi kwenye skrini. Mstari wa pili tupu - mstari tupu mahali neno la siri linapaswa kuwa - humwacha mteja na neno la siri tupu, ambalo seva inakataa ingawa thamani kwenye skrini inaonekana sahihi. Mstari mpya wa ziada baada ya neno la siri hauna madhara. Andika faili kutoka shell, si kutoka kihariri, na kagua baiti:

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

Njia ni muhimu kama maudhui. Njia jamaa hutatuliwa kuhusiana na saraka ya kazi ya mchakato, ambayo kwa huduma mara chache ni saraka uliyojaribu. Tumia njia kamili, fanya faili kuwa mali ya akaunti inayoendesha mteja, na uweke hali 0600 ili kikundi na wengine wasiweze kuisoma. Mwongozo wa OpenVPN 2.6 unaorodhesha aina zinazokubalika za agizo; uangalie kabla ya kubuni ya tatu.

Jaribu faili kabla ya kulaumu seva. Kuendesha openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 huchapisha kama faili ilifunguliwa na baadaye kama vitambulisho vilikubaliwa, jambo linalokuambia tabaka gani la kubadilisha baadaye.

Mitiririko, stdin na makosa inayozalisha

Kupitisha neno la siri kupitia bomba ni jambo la kwanza wengi hujaribu na ndiyo njia yenye mshangao mwingi. Badala ya mchakato inafanya kazi kwa sababu mteja anahitaji tu kielekezi kinachosomeka: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Kupitisha /dev/stdin hufanya kazi tu wakati stdin bado imefunguliwa na inasomeka wakati mteja anauliza, jambo ambalo si kweli katika bomba ambalo tayari limeitumia.

ERROR: could not read Auth username from stdin ina sababu mbili tofauti. Kwa baadhi ya wateja wa 2.3.x ujumbe ulitoka kwa kasoro ya utunzaji wa stdin ambayo matoleo ya 2.3 ya baadaye yalirekebisha, kwa hiyo mteja wa zamani hivyo huboresha tu kwa kuboresha toleo. Kwa mteja wa sasa maneno hayo hayo yanamaanisha mteja aliomba ingizo la konsoli na stdin haikuwa terminal - hasa hali iliyo katika kitengo cha systemd, kazi ya cron au kontena iliyoanzishwa bila -t.

auth-nocache inaongeza mzunguko wa tatu unaoonekana kama neno la siri lililovunjika. Inatupa vitambulisho kutoka kumbukumbu baada ya matumizi, kwa hiyo kuunganisha tena kunakosababishwa na mabadiliko ya mtandao hakuna cha kucheza tena na ombi linarejea. Hilo ni agizo linalofanya kazi kama lilivyoundwa. auth-nocache hubadilisha kile mteja anahifadhi kwenye kumbukumbu, si kile seva au mtoa utambulisho anafikiria kuhusu akaunti, kwa hiyo marekebisho yote ni kutoa tena faili hilo hilo, lililosomwa tena wakati wa kuanzisha upya - na kwa muunganisho unaosimamiwa utoaji huo unapaswa kuja kutoka hazina ya siri iliyoidhinishwa, si neno la siri lililo kwenye script.

Kiolesura cha usimamizi wakati ombi linamilikiwa na mchakato mwingine

Kidhibiti ambacho tayari kinasimamia handaki kinaweza pia kujibu maswali yake. Anzisha mteja kwa --management 127.0.0.1 7505, soma mistari ya hali, na fuatilia >PASSWORD:Need 'Auth' username/password. Kidhibiti hujibu kwa username "Auth" alice ikifuatiwa na password "Auth" ... kwenye mistari tofauti ya amri. Tokeni ya 'Auth' hurudia kitambulisho kutoka ombi na lazima ilingane, vinginevyo jibu linapuuzwa na mteja anasubiri.

Gharama ni mashine ya hali ambayo sasa unamiliki: mpangilio wa miunganisho, kuanzisha upya mteja, na soketi ya ndani ambayo watumiaji wengine kwenye mwenyeji hawapaswi kuifikia. Unachonunua ni kitambulisho kinachotolewa wakati wa utekelezaji, bila faili kwenye diski na bila ombi linaloweza kusimama. Ikiwa hakuna kingine kwenye stack yako kinachozungumza itifaki hii tayari, njia hii inaongeza sehemu inayohitaji matengenezo.

Kushindwa kunakoonekana kama matatizo ya vitambulisho

Kupeana mikono kwa TLS ambako hakukamiliki kamwe, au VERIFY ERROR: depth=0, error=certificate signature failure, ni tatizo la uaminifu na hutokea kabla ya jina lolote la mtumiaji kusomwa. Mteja wa proto tcp unaoelekezwa kwa msikilizaji wa UDP unashindwa mahali pale pale: pakiti hazifikii awamu ya uthibitishaji, kwa hiyo kila neno la siri linaonekana lisilo sahihi kwa uhusiano. Weka uthibitishaji wa cheti umewashwa kabla vitambulisho kutumwa; ombi linalojulikana halisemi chochote kuhusu nani anapokea neno la siri. Kagua mnyororo wa vyeti, jina la kawaida na usafirishaji kabla ya kugusa vitambulisho.

Makosa ya shell kwenye script inayokusanya wasifu ni alama nyingine ya uongo. Nafasi inayokosekana ndani ya [ ! -f "$file" ] huzalisha command not found, script inasimama mapema, wasifu haujengwi upya kamwe, na mteja unaanza na ule wa awali. Hitilafu hiyo ni ya shell, si ya uthibitishaji, na hata uandike neno la siri mara ngapi haifutiki.

Si kila ombi katika mtiririko huu ni kitambulisho hiki. Kifungu cha siri cha ufunguo wa faragha, kuingia kwa proksi ya HTTP na neno la siri la huduma ni siri tatu tofauti zinazoombwa katika awamu tofauti, na kifungu cha siri cha ufunguo kwa kawaida hushughulikiwa na mteja au wakala badala ya auth-user-pass. Ikiwa ombi linaonekana kabla ya kikao cha TLS kusimama, unajibu swali lisilo sahihi na hakuna kuweka upya akaunti kutasaidia. Ombi lisilo sahihi likiondolewa, ukaguzi uliobaki huanza kutoka tabaka la mapema zaidi:

• Soma hitilafu ya kwanza ya itifaki, si mstari wa mwisho wa vitambulisho: TLS, kisha uthibitishaji, kisha push.
• Thibitisha kuwa faili ni mistari miwili, haina kurudi kwa gari na imerejelewa kwa njia kamili.
• Thibitisha kuwa wasifu na mstari wa amri havikinzani kuhusu agizo.
• Tenganisha "vitambulisho vimekubaliwa" na "trafiki inapita" - uelekezaji na DNS ni tabaka la baadaye.

Mteja anapofikia awamu ya push, acha kuangalia vitambulisho na anza kusoma njia na seva za DNS ambazo seva ilituma. Hilo ni tatizo linalofuata, na halina uhusiano wowote na neno la siri ulilorekebisha hivi punde.