OpenVPN push-peer-info: žymėti klientus nesuteikiant prieigos

Diegimo žymos yra įprasta priežastis, kodėl žmonės griebiasi šios funkcijos: kiekvienas ryšys turėtų nešti ką nors panašaus į vietą ar vaidmenį, o serveris turėtų tai perskaityti nesugalvodamas antrojo kredencialų formato. Bendruomenės OpenVPN jau turi šį mechanizmą, ir jis mažas. Skausminga dalis yra lūkesčiai. Įprasto kintamojo nustatymas kliento profilyje nieko nedaro serveryje, o atvykusi reikšmė įrodo tik tai, kad klientas ją išsiuntė.

Tai veikiančio kelio, patikrinimo žingsnio, parodančio, kas iš tikrųjų atvyko, ir atsukimo, kuris nepalieka pusiau sukonfigūruoto kablio, vadovas. Nieko čia nereikia naujo sertifikato, naujo papildinio ar protokolo plėtinio.

Nustatykite kintamąjį ir įjunkite kelią

Kliento profilyje darbą atlieka dvi eilutės, ir abi būtinos. Be pirmosios nėra ko siųsti; be antrosios klientas apskritai nesiūlo bendraamžio informacijos. Tvarka nesvarbi, ir tai verta žinoti, nes dvi eilutės dažnai atsiduria skirtingose sugeneruoto profilio dalyse. Svarbu tai, kad abi išgyventų bet kokį profilio perrašymą prieš klientui jį perskaitant.

setenv UV_DEPLOY field-support
push-peer-info

UV_ priešdėlis nėra puošmena. Įprastas DEPLOY kintamasis lieka vietinis kliento procese ir niekada nepersiunčiamas, o forma su priešdėliu yra vardų erdvė, kurią protokolas rezervuoja vartotojo apibrėžtiems laukams. Palikite likusią patvirtinto profilio dalį nepakeistą ir prieš diegdami patikrinkite, ar diegiama kliento versija palaiko abi direktyvas.

Vienas praktinis patikrinimas priklauso čia, o ne pabaigoje: įsitikinkite, kad direktyva pasiekia kliento binarius failus ir jos nepraryja apvalkalas. Grafinis klientas, kuris pats generuoja komandų eilutę, arba valdymo sąsaja, kuri iš naujo įkelia išsaugotą profilį, gali išmesti eilutes, kurių neatpažįsta. Jei serveris nieko nemato, tai pirmoji vieta, kur reikėtų žiūrėti.

Perskaitykite lauką iš serverio kablio

Serverio pusėje gauta bendraamžio informacija validuojama ir įterpiama į ryšio darbo eigos aplinką, ir būtent tai leidžia ją perskaityti iš kablio be jokio jūsų protokolo darbo. Serveriui nereikia analizuoti valdymo kanalo ar ką nors saugoti už jus; reikšmė tiesiog yra ten, kol ryšys nustatomas. Minimalus client-connect scenarijus, įrašantis žymą šalia autentifikuoto vardo, atrodo taip.

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

Skaitykite kintamąjį per aplinką, o ne analizuodami žurnalą, ir visada suteikite jam numatytąją reikšmę. ${UV_DEPLOY:-unset} palaiko scenarijų veikiantį klientams, kurie niekada nesiunčia lauko, o tai įprasta būsena etapinio diegimo metu. Neišpilkite visos aplinkos į žurnalą, kad rastumėte vardą; joje yra daug daugiau nei žyma, įskaitant reikšmes, kurių neketinote išsaugoti.

Paleiskite scenarijų rankiniu būdu ir jis praneš unset apie viską, nes rankinė shell aplinka nenešioja ryšio aplinkos. Tai ne scenarijaus klaida ir ne įrodymas, kad lauko trūksta. Išbandykite jį per tikrą ryšį, vienintelį kontekstą, kuriame kintamasis egzistuoja.

Patikrinkite, kas iš tikrųjų atvyko

Prijunkite vieną klientą su žyma ir vieną be jos, tada perskaitykite failą. Pora yra testas: viena eilutė turėtų nešti reikšmę, o kita – numatytąją, ir abi turėtų įvardyti tą pačią autentifikuotą tapatybę, kurios tikitės.

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

Tos komentarų eilutės yra išvesties forma, o ne jūsų serverio transkripcija; skaitykite savo failą. Jei antrasis klientas taip pat rodo reikšmę, kintamasis nustatytas kur nors kitur aplinkoje, ir jūs skaitote pasenusį nustatymą, o ne bendraamžio lauką.

Patikrinkite ir serverio žurnalą dėl ryšio. Bendraamžio informacija gali ten pasirodyti, o tai patogu derinant ir priežastis laikyti reikšmes nuobodžias: jokių žmonių vardų, jokių bilietų numerių, nieko, ko nenorėtumėte, kad pamatytų žurnalo skaitytojas.

Traktuokite žymą kaip teiginį, o ne tapatybę

Bet kas, kas gali redaguoti kliento profilį, gali pakeisti žymą, o tai, kad tunelis autentifikuotas, žymos neįgalioja. Transportas saugo reikšmę kelyje; jis nepatvirtina teiginio. Autorizacija vis dar priklauso autentifikuotai tapatybei ir serverio valdomam registracijos įrašui, o žyma lyginama su tuo įrašu, kai tai svarbu.

Šis skirtumas nusprendžia, kur žymą galima naudoti. Geri naudojimo būdai yra nukreipti sesiją į tinkamą žurnalo failą, pasirinkti rodymo grupę prietaisų skydelyje arba pažymėti palaikymo sesiją, kad žmogus ją vėliau rastų. Blogi naudojimo būdai yra įleisti įrenginį į potinklį, pasirinkti užkardos taisyklę arba nuspręsti, kurių kliento duomenų sesija gali skaityti.

Validuokite reikšmę, kol ji nepasiekė kelio, užklausos ar shell komandos. Laukiamų eilučių leidžiamasis sąrašas pakanka diegimo žymai, ir tai nieko nekainuoja. Niekada neįterpkite bendraamžio pateiktos eilutės į shell komandų eilutę ir apribokite bet kokį saugomą stebėjimą sesija, o ne tunelio adresu, kurį kitas klientas naudos iš naujo.

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

Grąžinkite tvarkingai

Pašalinti funkciją yra du trynimai ir vienas patikrinimas. Pašalinkite eilutes setenv ir push-peer-info iš kliento profilio, tada pašalinkite arba išjunkite kablį ir jo žurnalo tikslą serveryje.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

Po to vėl prijunkite vieną klientą ir patvirtinkite, kad žurnalo eilutė nustojo rodytis. Kablys, kuris ir toliau suveikia po profilio pakeitimo, dažniausiai yra antras profilis, vis dar įdiegtas bandomajame įrenginyje, ir jį rasti dabar pigiau nei rasti audito metu.

Pabaigoje lieka maža, ribota sesijos metaduomenų dalis su dokumentuota kilme: klientas ją teigia, serveris ją įrašo, ir niekas apie prieigą nuo jos nepriklauso. Tai naudingoji funkcijos versija, ir jai pasiekti nereikia naujų kredencialų.