Ĉu akredita dosiero aŭ administra ingo de OpenVPN: kion skripti

auth-user-pass kovras la kontan inviton; la administra ingo kovras ĉiujn kvar. Komparu la elmeton, la skriptan koston kaj kiel ĉiu fiaskas en servo.

Skripto, kiu startigas OpenVPN kaj neniam konektiĝas, kutime ne estas reta problemo: la kliento sidas ĉe invito sen terminalo por desegni ĝin. OpenVPN havas ekzakte du subtenatajn manierojn respondi tiun inviton sen homo, akreditan dosieron malantaŭ auth-user-pass kaj la administran ingon, kaj ili ne estas interŝanĝeblaj. La dosiero kostas unu direktivon kaj respondas unu inviton; la ingo respondas ĉiun inviton kaj donas al io ajn, kio povas malfermi loopback-pordon, nekontrolitan reg-kanalon. Kiu el ili apartenas al via deplojo dependas de tio, kiu invito efektive blokas, kaj de tio, kiun sekreton vi povas permesi resti en ripozo.

Nomu la inviton antaŭ ol elekti mekanismon

Kvar invitoj aspektas identaj sur terminalo. La konta paro venas de la PAM- aŭ auth-user-pass-verify-agordo de la servilo kaj estas respondata de auth-user-pass. Pasfrazo de privata ŝlosilo apartenas al la ŝlosila dosiero kaj estas legata per --askpass aŭ tajpata permane. PKCS#12-pakaĵo petas propran pasvorton. Prokura aŭtentikigo uzas la auth-dosieron, kiun prenas --http-proxy, ne la kontajn akreditaĵojn.

Kiam OpenVPN rulas kiel infano de systemd, PHP aŭ Node, ne estas terminalo, do iu ajn el tiuj blokas silente. La procezo sidas tie, la protokolo haltas post la ĉifra linio, kaj la unuo fine tempolimas; tiu silento estas kial homoj aldonas reprovan buklon aŭ sleep anstataŭ rigardi, kiu invito atendas. Nur la administra ingo povas respondi ĉiujn kvar. La akredita dosiero respondas la unuan kaj nenion alian.

auth-user-pass: unu dosiero, unu invito

La dosiero enhavas la uzantnomon en linio unu kaj la pasvorton en linio du, kaj nenion alian: neniuj citiloj, neniuj ŝlosilnomoj, neniuj komentoj. Agordu reĝimon 600 kaj faru la posedanton la konto, kiu rulas openvpn, kio por servo ofte estas dediĉita uzanto anstataŭ via ensaluto. Dosiero posedata de root sub /root estas la diferenco inter komando, kiu funkcias en via ŝelo, kaj unuo, kiu fiaskas ĉe lanĉo.

Du detaloj igas ĝustan dosieron invito. Redaktilo, kiu konservas CRLF, lasas karaban revenon gluita al la pasvorto, do la servilo malakceptas pasvorton, kiu en la dosiero aspektas ĝusta; kontrolu per cat -A aŭ od -c anstataŭ per la okulo. Kaj auth-user-pass sen argumento ene de la profilo signifas «demandu la uzanton» laŭ la dezajno, kion dua direktivo sur la komandlinio eble ne superregas, ĉar la profilo analiziĝas tie, kie ĝi kuŝas.

La ordo de opcioj estas la tria kaptilo, kaj ĝi dependas de la versio. Iuj OpenVPN 2.4-konstruoj ignoras --auth-user-pass, kiam ĝi aperas antaŭ --config, do la samaj du opcioj en la alia ordo konektiĝas. Metu la direktivon ene de la profilo, aŭ post --config sur la komandlinio, kaj grep la profilon por ĉiu apero antaŭ ol ŝanĝi ion alian.

auth-nocache apartenas al tiu mekanismo sed liveras nenion. Ĝi limigas, kiom longe la kliento tenas la akreditaĵon en memoro, kio helpas post paneo kaj tute ne, kiam la dosiero mankas. Rekonekto post sesia tempolimo ĉe la servila flanko relegas la dosieron, do akreditaĵo, kiu funkciis ĉe lanĉo, ankoraŭ povas eksvalidiĝi meze de la tago.

La administra ingo: ĉiu invito, pli da surfaco

Startigu la klienton kun aŭskultanto kaj eksplicite deklaru, ke invitoj raportiĝos sur ĝi, uzante la direktivojn dokumentitajn en la OpenVPN 2.6-manlibro:

management 127.0.0.1 3030
management-query-passwords

El bash, tenu la konekton sur libera dosierpriskribo kaj respondu laŭ invita nomo anstataŭ laŭ pozicio, ĉar rekonekto povas demandi en alia ordo:

exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
  case "$line" in
    *"Need 'Auth' username/password"*)
      echo 'username "Auth" alice' >&3
      echo 'password "Auth" secret' >&3 ;;
    *"Need 'Private Key' password"*)
      echo 'password "Private Key" secret' >&3 ;;
  esac
done

La limo estas la transporto. La administra protokolo estas plata teksto super TCP sur loopback, do la aŭskultanto ne rajtas esti publikigita sur LAN- aŭ tuneladreso por ke fora regilo atingus ĝin; fora regilo signifas SSH-plusendadon, ne pli vastan bindon. La komunuma demono ankaŭ akceptas unu administran klienton samtempe, do GUI aŭ monitoro ne povas dividi la ingon kun via skripto. La dua konekto estas rifuzata, ne vicigata, kaj la paneo aspektas kiel skripto, kiu surdiĝis.

Tiu ingo ankaŭ estas reg-kanalo. Sen administra pasvorto, io ajn, kio povas konektiĝi al 127.0.0.1:3030, povas legi staton, mortigi la tunelon aŭ mem respondi inviton. La administra pasvorto kaj la akredita dosiero estas sekretoj de la sama klaso, kaj ambaŭ meritas la saman zorgon.

Kiu taŭgas por la deplojo

Elektu la akreditan dosieron, kiam la sola invito estas la konta paro, la kliento rulas kiel servo kun stabila posedanto, kaj vi povas teni 600-dosieron ekster sekurkopioj, kiujn vi ne kontrolas. Elektu la administran ingon, kiam ŝlosila pasfrazo aŭ PKCS#12-pasvorto estas en ludo, kiam la ĉirkaŭaĵo jam kontrolas la procezon, aŭ kiam vi bezonas observi staton kaj invitojn dum vi sencimigas rekonekton.

Du kondiĉoj movas la decidon. Se la ĉirkaŭaĵo estas /bin/sh, systemd-unuo, kiu vokas la binaraĵon rekte, aŭ minimuma ujo, la inga gluo nur por bash ne disponeblas kaj la dosiero estas la pli malmultekosta respondo. Se la sekreto ofte rotacias, neniu dosiero estas bona hejmo por ĝi: demandu ŝlosilringon el malgranda ĉirkaŭaĵo kaj lasu la unuon voki la ĉirkaŭaĵon, kio tenas rotacion en unu loko kaj la pasvorton ekster la ŝela historio.

Proceza anstataŭigo staras inter la du kaj apartenas al neniu. La unuliniaĵo sube funkcias ĉar bash vastigas ĝin antaŭ ol openvpn startas, ne ĉar la kliento komprenas la sintakson:

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

Ĝi rompiĝas sub /bin/sh, en unuo, kiu preterpasas la ŝelon, kaj en bildoj sen bash aŭ /dev/fd. Konservu ĝin por interagaj testoj, neniam kiel la kontrakto, de kiu servo dependas.

Protektu la sekreton, poste kontrolu el la protokolo

Ambaŭ mekanismoj lasas sekreton legeblan de la OpenVPN-procezo. Neniam metu la pasvorton sur la komandlinion aŭ en la unuan dosieron, kie ps kaj systemctl montras ĝin al ĉiu loka uzanto; transdonu la vojon al la dosiero, ne la valoron en ĝi. Kie atestiloj povas anstataŭigi la kontan paron, tio forigas la kategorion de invito anstataŭ kaŝi ĝin.

Ĝusta rulo montras la invitosekvencon kompletiĝi kaj la sesion atingi «Initialization Sequence Completed». Se la kliento haltas ĉe la sama invito, la kongruo malsukcesis: presu la ĝustajn liniojn, kiujn la ingo sendis, kontrolu citilojn kaj la invitan nomon, kaj riparu la ŝablonon anstataŭ aldoni sleep. Tunelo, kiu raportas sukceson kaj portas nenion, estas enkursiga aŭ push-problemo, ne akredita.

Poste testu la rekonekton, ne nur la unuan starton. Forigu la sesion ĉe la servila flanko aŭ atendu ĝian tempolimon; la kliento demandas denove, kaj ĝuste tie dosiero, kiu aspektis ĝusta ĉe lanĉo, montras, ĉu ĝi ankoraŭ estas legebla de la konto, kiu rekonektiĝas.

Rilataj artikoloj