OpenVPN auth-user-pass: skrá, stdin eða beiðni? Hvernig á að velja

Þrír hlutir ráða því hvaða skírteinauppsprettu þú átt að nota: hvort manneskja situr við stjórnborðið, hvort leyndarmálið má lifa á disknum og hvort annað ferli þarf að svara beiðninni. Veldu rangt og biðlarinn tilkynnir stdin-vandamál þótt lykilorðið sé fullkomlega gilt, sem sendir flest fólk á netþjóninn án ástæðu. Veldu slóðina fyrst; villuboðin hafa aðeins merkingu þegar þú veist hvaða slóð framleiddi þau.

Þrjú skilyrðin sem ráða þessu

Beiðnin í stjórnborðinu er eina slóðin sem þarf manneskju, svo hún er eina slóðin sem bregst hljóðlega í systemd einingu eða gámi. Ef manneskja ræsir biðlarann og slær inn lykilorðið er engin skrá í hlut og ekkert viðkvæmt lendir á disknum. Ef biðlarinn ræsist við ræsingu verður sama beiðni að stöðvun, og tímatakmörkin birtast venjulega sem almenn tengingarvilla frekar en skírteinavilla.

Skrá með skírteinum er rétta svarið þegar ferlið ræsist án eftirlits og leyndarmálið má lifa á disknum undir stýrðu setti heimilda. Þegar leyndarmálið má alls ekki skrifa - stefna um aðeins hvelfingu, skammtíma tákn - þarftu streymi sem biðlarinn getur opnað, sem í reynd þýðir ferlisstaðgöngu eða hjálpara sem skrifar í skráarlýsingu. Stjórnviðmótið nær yfir fjórða tilfellið: stýring sem stjórnar þegar lífsferli göngunnar og getur svarað spurningum í gegnum socket.

• Manneskja við stjórnborðið, engin sjálfvirkni: gagnvirk beiðni.
• Ræsing án eftirlits, leyndarmálið má geyma: skrá með skírteinum í ham 0600.
• Ræsing án eftirlits, leyndarmálið má ekki geyma: ferlisstaðganga eða fd sem leyndarmálaumboðsmaður skrifar í.
• Annað ferli á biðlarann: stjórnviðmót.

Þegar tvö svör passa skaltu velja það sem heldur leyndarmálinu utan við argv og utan við sögu shellsins. Lykilorð sem er sent sem forritarök er læsilegt fyrir hvern staðbundinn notanda í gegnum ferlalistann, og erfitt er að afturkalla þá afhjúpun.

Hvað hver inntaksslóð gerir í raun

--auth-user-pass ein og sér biður um notandanafn og lykilorð í stjórnborðinu. Með skráarheiti tekur biðlarinn fyrstu línuna sem notandanafn og aðra línuna sem lykilorð; ekkert styður gæsalappir, athugasemdir eða lykil-gildis setningu. Þetta er allt sniðið, svo hver sem breytir því í von um INI-skrá eyðileggur það. Innfellt <auth-user-pass> blokk heldur sömu tveimur línum inni í sniðinu, sem gerir sniðið sjálft að leyndarmáli og setur það í sama meðferðarflokk og einkalykil.

Hinar tvær slóðir eru streymi og socket. OpenVPN þarf aðeins læsilega skráarlýsingu, svo hún tekur ferlisstaðgöngu, pípustuttri /dev/fd færslu eða skráarheiti sem er í raun FIFO. Stjórnviðmótið er öðruvísi að eðlisfari: biðlarinn spyr eftirlitsferli um gildin í stað þess að lesa þau sjálfur. Sá munur skiptir máli við endurtengingu: skrá með skírteinum, FIFO sem leyndarmálahjálpari getur skrifað í aftur og stjórnviðmótið geta endurveitt án manneskju; ferlisstaðganga getur það ekki, því lýsingin eyðist við fyrstu lestur.

Skráin verður að vera nákvæmlega tvær línur

Tveir bilunarhamir ná yfir flestar brotnar skírteinaskrár. Ritstjóri í Windows skilur eftir CRLF-endingar, vagnsendingin verður hluti lykilorðsins og netþjónninn hafnar gildi sem lítur rétt út á skjánum. Tóm önnur lína - tóm lína þar sem lykilorðið á að vera - skilur biðlarann eftir með tómt lykilorð, sem netþjónninn hafnar þótt gildið á skjánum líti rétt út. Auka ný lína eftir lykilorðið er skaðlaus. Skrifaðu skrána úr shellinu, ekki úr ritstjóra, og athugaðu bætin:

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

Slóðin skiptir jafn miklu máli og innihaldið. Afstæð slóð er leyst gagnvart vinnumöppu ferlisins, sem fyrir þjónustu er sjaldan mappan þar sem þú prófaðir. Notaðu algera slóð, láttu skrána vera í eigu reikningsins sem keyrir biðlarann og haltu ham 0600 svo hópur og aðrir geti ekki lesið hana. OpenVPN 2.6 handbókin telur upp viðteknu form skipunarinnar; athugaðu hana áður en þú finnur upp þriðja formið.

Prófaðu skrána áður en þú kennir netþjóninum um. Keyrsla openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 prentar hvort skráin var opnuð og síðar hvort skírteinin voru samþykkt, sem segir þér hvaða lag á að breyta næst.

Streymi, stdin og villurnar sem þau framleiða

Að pípa lykilorðinu inn er það fyrsta sem flestir prófa og slóðin með flestum óvart. Ferlisstaðganga virkar því biðlarinn þarf aðeins læsilega lýsingu: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Að senda /dev/stdin virkar aðeins þegar stdin er enn opið og læsilegt á þeirri stundu sem biðlarinn spyr, sem er ekki rétt í pípun sem þegar hefur eytt því.

ERROR: could not read Auth username from stdin hefur tvær aðskildar orsakir. Á sumum 2.3.x biðlurum kom skilaboðið frá galla í meðferð stdin sem síðari 2.3 útgáfur lagaðu, svo svo gamall biðlari batnar aðeins með uppfærslu. Á núverandi biðlara þýðir sama orðalag að biðlarinn bað um inntak í stjórnborði og stdin var ekki stjórnstöð - nákvæmlega staðan í systemd einingu, cron verkefni eða gámi sem ræstur var án -t.

auth-nocache bætir við þriðju lykkjunni sem lítur út eins og brotið lykilorð. Það hendir skírteinunum úr minninu eftir notkun, svo endurtenging sem netbreyting veldur hefur ekkert til að spila aftur og beiðnin snýr aftur. Þetta er skipunin sem virkar eins og henni var ætlað. auth-nocache breytir því sem biðlarinn heldur í minninu, ekki því sem netþjónninn eða auðkennisveitandinn hugsar um reikninginn, svo alla lagfæringin er að endurveita sömu skrá, endurlesna við endurræsingu - og fyrir stýrða tengingu ætti sú veiting að koma frá samþykktu leyndarmálageymslunni, ekki lykilorði í skriftu.

Stjórnviðmótið þegar annað ferli á beiðnina

Stýring sem þegar hefur eftirlit með göngunni getur líka svarað spurningum hennar. Ræstu biðlarann með --management 127.0.0.1 7505, lestu stöðulínurnar og fylgstu með >PASSWORD:Need 'Auth' username/password. Stýringin svarar með username "Auth" alice og síðan password "Auth" ... á aðskildum skipanalínum. 'Auth' táknið endurtekur auðkennið úr beiðninni og verður að passa, annars er svarinu hunsað og biðlarinn bíður.

Kostnaðurinn er stöðuvél sem þú átt núna: röð tenginga, endurræsingar biðlarans og staðbundið socket sem aðrir notendur á hýsilnum mega ekki ná til. Það sem þú kaupir er skírteini sem veitt er á keyrslutíma, án skráar á disknum og án beiðni sem getur stöðvast. Ef ekkert annað í staflanum þínum talar þegar samskiptareglurnar, bætir þessi slóð við hluta sem þarf að viðhalda.

Bilanir sem líta út eins og skírteinavandamál

TLS handaband sem klárast aldrei, eða VERIFY ERROR: depth=0, error=certificate signature failure, er traustsvandamál og gerist áður en nokkurt notandanafn er lesið. proto tcp biðlari sem beint er að UDP hlustanda bregst á sama stað: pakkarnir ná aldrei auðkenningarstiginu, svo hvert lykilorð lítur rangt út vegna tengingar. Haltu skírteinisstaðfestingu áður en skírteinið er sent; kunnugleg beiðni segir ekkert um hver fær lykilorðið. Athugaðu skírteinakeðjuna, algenga nafnið og flutninginn áður en þú snertir skírteinið.

Shell-villur í skriftunni sem setur sniðið saman eru hina falsa slóðin. Vantar bil inni í [ ! -f "$file" ] framleiðir command not found, skriftan stöðvast snemma, sniðið er aldrei endurbyggt og biðlarinn ræsist með því fyrra. Sú villa tilheyrir shellinu, ekki auðkenningunni, og engin endurskrifun lykilorðsins hreinsar hana.

Ekki er hver beiðni í þessu flæði þetta skírteini. Lykilorð einkalykils, innskráning HTTP milliþjóns og lykilorð þjónustunnar eru þrjú mismunandi leyndarmál sem beðið er um í mismunandi áföngum, og lykilorð lykils er venjulega meðhöndlað af biðlaranum eða umboðsmanni frekar en auth-user-pass. Ef beiðnin birtist áður en TLS lotan er komin upp ertu að svara rangri spurningu og engin endurstilling reiknings hjálpar. Þegar röngu beiðninni hefur verið eytt byrja eftirfarandi athuganir á elsta laginu:

• Lestu fyrstu samskiptaregluvilluna, ekki síðustu skírteinilínuna: TLS, svo auðkenning, svo push.
• Staðfestu að skráin sé tvær línur, hafi engar vagnsendingar og sé vísuð með algerri slóð.
• Staðfestu að sniðið og skipanalínan stangist ekki á um skipunina.
• Aðskildu "skírteini samþykkt" frá "umferð streymir" - leiðsögn og DNS eru síðara lag.

Þegar biðlarinn nær push áfanganum skaltu hætta að horfa á skírteinin og byrja að lesa leiðirnar og DNS-netþjónana sem netþjónninn sendi. Það er næsta vandamál, og það hefur ekkert með lykilorðið að gera sem þú lagaðir rétt í þessu.