OpenVPN neranda ca.crt, nors profilis įkeliamas

Paslauga paleidžiama, perskaito profilį be jokių priekaištų ir tada miršta eilutėje, kuri atrodo nesusijusi: ji negali atidaryti ca.crt. Sertifikate niekas nepasikeitė, o profilio kelias unit faile yra absoliutus. Būtent šis derinys yra užuomina. Jūsų perduotas kelias nurodo vieną failą, o to failo viduje esantys pavadinimai sprendžiami visai kitur, todėl visiškai kvalifikuotai atrodantis paleidimas vis tiek gali skaityti savo raktus iš katalogo, kurio niekas neketino.

Nesėkmė turi nedaug priežasčių, ir verta jas atskirti eilės tvarka: bazinis katalogas, kurį procesas iš tikrųjų turėjo, paslaugos paleidimo kontekstas ir teisės ar smėlio dėžė aplink failą, kai kelias jau teisingas. Kiekviena palieka skirtingą pėdsaką — unit faile, procese ir failų sistemoje.

Profilio kelias nėra bazinis katalogas

Įsivaizduokite procesą, kuris pradedamas /tmp kataloge ir gauna /etc/vpn/prod/tenant-a.ovpn. To profilio viduje eilutė ca ca.crt nurodo santykinį kelią. Niekas argumente, kuriuo buvo rastas profilis, neperrašo to pavadinimo, todėl procesas ieško /tmp/ca.crt ir praneša apie trūkstamą failą.

Painiausias dalykas yra klaidų eilė. OpenVPN pirmiausia analizuoja konfigūraciją ir atidaro nurodytus failus jiems pasiekus, todėl rašybos klaida profilyje pranešama anksčiau, nei paliečiamas koks nors raktas, o trūkstamas sertifikatas pasirodo tik tada, kai analizė ten pasiekia. Taigi įkeliamas profilis yra sintaksės teisingumo įrodymas, o ne tai, kad jame nurodyti failai buvo rasti.

Ką vadovas atskiria: --config ir --cd

OpenVPN 2.6 vadove aprašomi du skirtingi parametrai. Vienas įkelia konfigūracijos failą. Kitas pakeičia proceso katalogą prieš nuskaitant konfigūraciją, raktą, scenarijų ir kitus failus, ir reikalauja absoliutaus katalogo be jokios nuorodos į dabartinį.

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

Šis iškvietimas yra forma, o ne nurodymas paleisti svetimą profilį. Ką jis duoda, tai determinizmas: kiekvieno santykinio pavadinimo grandinėje bazė nurodoma komandoje, o ne paveldima iš apvalkalo ar tvarkyklės, kuri paleido procesą. Alternatyva taip pat galioja ir paslaugai dažnai geresnė: palikite darbinį katalogą ramybėje ir padarykite kiekvieną nurodytą failą absoliutų profilio viduje.

Kad ir ką pasirinktumėte, tikrinkite visą grandinę, o ne pirmąją nesėkmę. Profilis gali įtraukti kitą konfigūracijos failą, o įtraukto failo santykiniai pavadinimai sprendžiami to paties proceso katalogo atžvilgiu, o ne failo, kuris juos įtraukė, katalogo atžvilgiu. Žurnalų keliai, autentifikavimo failai ir pagalbiniai scenarijai laikosi tos pačios taisyklės.

Paslauga paleidžiama kitur

Interaktyvus apvalkalas profilio kataloge nieko neįrodo apie supakuotą unit. Tvarkyklės nustato savo darbinį katalogą, o apvalkalo scenarijus gali jį vėl pakeisti prieš paleidžiant binariją. Nepavykstantis unit yra vienintelis paleidimas, apie kurį verta samprotauti.

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

Antroji komanda parodo katalogą, kurį gyvas procesas iš tikrųjų laiko, ir tai patikimiau nei unit failas, kai dalyvauja apvalkalas. Jei abu nesutampa, atsakymas yra apvalkalas, o unit yra klaidinantis pėdsakas.

Po paieškos: teisės, chroot ir smėlio dėžė

Teisingas bazinis katalogas vis tiek gali duoti tą patį pranešimą, nes sprendimas ir prieiga yra atskiri žingsniai. Procesui reikia vykdymo teisės kiekviename tėviniame kataloge ir skaitymo teisės faile, o paslaugos unit, kuris slepia dalį failų sistemos, pakeičia tai, ką procesas apskritai gali matyti.

Trys įprasti variantai duoda identišką klaidą. Failas skaitomas tik root, o paslauga prieš jį atidarydama atsisako privilegijų. Unit nustato apsauginį failų sistemos vaizdą, kuris neapima profilio katalogo. Daimonas veikia su chroot, todėl kelias, kuris egzistuoja pagrindiniame kompiuteryje, tame vaizde neegzistuoja.

Diagnozuokite pagal failo savininką ir proceso tapatybę, o ne atlaisvindami teises. Privataus rakto padarymas skaitomo visiems, kad ši klaida nutiltų, keičia garsią nesėkmę tylia, o raktas yra būtent ta katalogo dalis, kurią mažiausiai norite atskleisti.

Įrodykite pataisymą savo paleidimu

Paleiskite iš naujo tikrą unit iš katalogo, nesusijusio su profiliu, ir stebėkite tą pačią paleidimo eilutę. Tada patvirtinkite, kad procesas veikdamas laiko numatytą katalogą, ir kad įkeltas sertifikatas yra tas, kurio tikitės.

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

Kai kelių įkėlimas pavyksta, autentifikavimas ir maršrutizavimas vis dar yra atskiri etapai su savo nesėkmėmis, o ryšys, kuris pakyla, bet nepraleidžia jokio srauto, yra kitas tyrimas. Pataisymas čia susijęs tik su tuo, iš kurio katalogo atėjo failai, ir jis turėtų būti matomas iškvietime, o ne prisimenamas to, kas paskutinį kartą paleido jį rankiniu būdu.

Jei profilis diegiamas konfigūracijos tvarkykle, ten pat įdėkite bazinį katalogą arba absoliučius failų pavadinimus. Rankinis pataisymas viename pagrindiniame kompiuteryje yra šios problemos versija, kuri grįžta po kito perrinkimo.