OpenVPN akreditācijas fails vai pārvaldības ligzda: ko skriptēt

Skripts, kas palaiž OpenVPN un nekad nepievienojas, parasti nav tīkla problēma: klients sēž pie uzvednes bez termināļa, uz kura to uzzīmēt. OpenVPN ir tieši divi atbalstīti veidi, kā atbildēt uz šo uzvedni bez cilvēka: akreditācijas fails aiz auth-user-pass un pārvaldības ligzda, un tie nav savstarpēji aizstājami. Fails maksā vienu direktīvu un atbild uz vienu uzvedni; ligzda atbild uz katru uzvedni un dod jebkam, kas spēj atvērt loopback portu, neautentificētu vadības kanālu. Kura no tām pieder jūsu izvietojumam, ir atkarīgs no tā, kura uzvedne faktiski bloķē, un no tā, kuru noslēpumu varat atļauties atstāt mierā.

Nosauciet uzvedni, pirms izvēlaties mehānismu

Četras uzvednes terminālī izskatās vienādi. Konta pāris nāk no servera PAM vai auth-user-pass-verify iestatījuma, un uz to atbild auth-user-pass. Privātās atslēgas parole pieder atslēgas failam un tiek nolasīta ar --askpass vai ievadīta ar roku. PKCS#12 pakotne pieprasa savu paroli. Starpniekservera autentifikācija izmanto auth failu, ko ņem --http-proxy, nevis konta akreditācijas datus.

Kad OpenVPN darbojas kā systemd, PHP vai Node bērns, termināļa nav, tāpēc jebkura no tām klusi bloķē. Process sēž tur, žurnāls apstājas pēc šifra rindas, un vienība galu galā pārsniedz laiku; šis klusums ir iemesls, kāpēc cilvēki pievieno atkārtošanas cilpu vai sleep, nevis skatās, kura uzvedne gaida. Uz visām četrām var atbildēt tikai pārvaldības ligzda. Akreditācijas fails atbild uz pirmo un ne uz ko citu.

auth-user-pass: viens fails, viena uzvedne

Fails satur lietotājvārdu pirmajā rindā un paroli otrajā, un neko citu: bez pēdiņām, bez atslēgu nosaukumiem, bez komentāra. Iestatiet 600 režīmu un padariet par īpašnieku kontu, kas palaiž openvpn, kas pakalpojumam bieži ir atsevišķs lietotājs, nevis jūsu pieteikšanās. Fails, kas pieder root, zem /root ir atšķirība starp komandu, kas strādā jūsu čaulā, un vienību, kas neizdodas palaišanas laikā.

Divas detaļas pārvērš pareizu failu uzvednē. Redaktors, kas saglabā CRLF, atstāj pie paroles pielipušu karietes atgriešanu, tāpēc serveris noraida paroli, kas failā izskatās pareiza; pārbaudiet ar cat -A vai od -c, nevis ar aci. Un profila iekšienē esošais auth-user-pass bez argumenta pēc dizaina nozīmē «jautā lietotājam», ko komandrindas otrā direktīva var arī nepārrakstīt, jo profils tiek parsēts tur, kur tas atrodas.

Opciju secība ir trešais slazds, un tā ir atkarīga no versijas. Dažas OpenVPN 2.4 būves ignorē --auth-user-pass, kad tas ir pirms --config, tāpēc tās pašas divas opcijas citā secībā pievienojas. Ievietojiet direktīvu profilā vai komandrindā aiz --config, un pirms kaut kā cita maiņas grep profilu par katru parādīšanos.

auth-nocache pieder šim mehānismam, bet neko nedod. Tas ierobežo, cik ilgi klients tur akreditācijas datus atmiņā, kas palīdz pēc avārijas un nemaz nepalīdz, kad faila nav. Atkārtots savienojums pēc servera sesijas taimauta nolasa failu vēlreiz, tāpēc akreditācijas dati, kas strādāja palaišanas laikā, joprojām var beigties dienas vidū.

Pārvaldības ligzda: katra uzvedne, vairāk virsmas

Palaidiet klientu ar klausītāju un skaidri paziņojiet, ka uzvednes tiks ziņotas uz tā, izmantojot direktīvas, kas dokumentētas OpenVPN 2.6 rokasgrāmatā:

management 127.0.0.1 3030
management-query-passwords

No bash turiet savienojumu uz rezerves faila deskriptora un atbildiet pēc uzvednes nosaukuma, nevis pozīcijas, jo atkārtots savienojums var jautāt citā secībā:

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

Robeža ir transports. Pārvaldības protokols ir atklāts teksts pa TCP uz loopback, tāpēc klausītāju nedrīkst publicēt LAN vai tuneļa adresē, lai attālināts kontrolieris tam piekļūtu; attālināts kontrolieris nozīmē SSH pāradresāciju, nevis plašāku piesaisti. Kopienas dēmons arī pieņem tikai vienu pārvaldības klientu vienlaikus, tāpēc GUI vai monitors nevar dalīt ligzdu ar jūsu skriptu. Otrais savienojums tiek noraidīts, nevis ielikts rindā, un kļūme izskatās kā apkurlis skripts.

Šī ligzda ir arī vadības kanāls. Bez pārvaldības paroles jebkas, kas spēj savienoties ar 127.0.0.1:3030, var lasīt statusu, nogalināt tuneli vai pats atbildēt uz uzvedni. Pārvaldības parole un akreditācijas fails ir vienas klases noslēpumi, un abi ir pelnījuši vienādu rūpību.

Kura piestāv izvietojumam

Izvēlieties akreditācijas failu, kad vienīgā uzvedne ir konta pāris, klients darbojas kā pakalpojums ar stabilu īpašnieku, un jūs varat turēt 600 failu ārpus dublējumkopijām, kuras nekontrolējat. Izvēlieties pārvaldības ligzdu, kad spēlē ir atslēgas parole vai PKCS#12 parole, kad ietvars jau uzrauga procesu, vai kad jums jāvēro statuss un uzvednes, atkļūdojot atkārtotu savienojumu.

Divi nosacījumi pabīda lēmumu. Ja ietvars ir /bin/sh, systemd vienība, kas izsauc bināro failu tieši, vai minimāls konteiners, tikai bash paredzētā ligzdas līme nav pieejama un fails ir lētākā atbilde. Ja noslēpums bieži rotē, neviens fails nav labs nams tam: pajautājiet atslēgu gredzenu no maza ietvara un ļaujiet vienībai izsaukt ietvaru, kas tur rotāciju vienā vietā un paroli ārpus čaulas vēstures.

Procesu aizstāšana stāv starp abiem un nepieder nevienam. Vienas rindas komanda zemāk darbojas tāpēc, ka bash to izvērš pirms openvpn starta, nevis tāpēc, ka klients saprot sintaksi:

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

Tā lūzt zem /bin/sh, vienībā, kas apiet čaulu, un attēlos bez bash vai /dev/fd. Glabājiet to interaktīvai testēšanai, nekad kā līgumu, no kura pakalpojums ir atkarīgs.

Aizsargājiet noslēpumu, tad pārbaudiet žurnālā

Abi mehānismi atstāj noslēpumu, ko OpenVPN process var nolasīt. Nekad nelieciet paroli komandrindā vai vienības failā, kur ps un systemctl rāda to katram vietējam lietotājam; nododiet ceļu uz failu, nevis vērtību tajā. Kur sertifikāti var aizstāt konta pāri, tas noņem uzvednes kategoriju, nevis to slēpj.

Pareiza izpilde parāda uzvedņu secības pabeigšanu un sesijas sasniegšanu «Initialization Sequence Completed». Ja klients apstājas pie tās pašas uzvednes, saskaņošana neizdevās: izdrukājiet precīzās rindas, ko ligzda nosūtīja, pārbaudiet pēdiņas un uzvednes nosaukumu, un izlabojiet modeli, nevis pievienojiet sleep. Tunelis, kas ziņo par panākumiem un neko nepārvadā, ir maršrutēšanas vai push problēma, nevis akreditācijas datu.

Pēc tam pārbaudiet atkārtotu savienojumu, ne tikai pirmo palaišanu. Nometiet servera sesiju vai nogaidiet tās taimautu; klients jautā vēlreiz, un tieši tur fails, kas palaišanas laikā izskatījās pareizs, parāda, vai tas joprojām ir lasāms kontam, kas pievienojas atkārtoti.