OpenVPNek ez du ca.crt aurkitzen, profila kargatzen den arren

Zerbitzua abiarazi, profila kexarik gabe irakurri eta gero loturarik ez duela dirudien lerro batean hiltzen da: ezin du ca.crt ireki. Ziurtagirian ezer ez da aldatu, eta unit fitxategiko profilaren bidea absolutua da. Konbinazio hori da arrastoa. Eman duzun bideak fitxategi bat kokatzen du, eta fitxategi horren barruko izenak erabat beste leku batean ebazten dira, beraz, guztiz kualifikatuta dirudien abiarazte batek inork nahi ez zuen direktorio batetik irakur ditzake bere gakoak.

Hutsegiteak kausa gutxi ditu, eta merezi du ordenan bereiztea: prozesuak benetan zuen oinarrizko direktorioa, zerbitzuaren abiarazte-testuingurua eta fitxategiaren inguruko baimenak edo sandboxa bidea zuzena denean. Bakoitzak arrasto ezberdina uzten du — unit fitxategian, prozesuan eta fitxategi-sisteman.

Profilaren bidea ez da oinarrizko direktorioa

Imajinatu /tmp-en hasten den eta /etc/vpn/prod/tenant-a.ovpn jasotzen duen prozesua. Profil horren barruan, ca ca.crt lerroak bide erlatiboa izendatzen du. Profila kokatu zuen argumentuan ezerk ez du izen hori berridazten, beraz prozesuak /tmp/ca.crt bilatzen du eta falta den fitxategi baten berri ematen du.

Nahastean jartzen duena erroreen ordena da. OpenVPN konfigurazioa lehenengo analizatzen du eta erreferentziatutako fitxategiak iristen denean irekitzen ditu, beraz profileko akats tipografiko bat edozein gakori ukitu aurretik jakinarazten da, eta falta den ziurtagiria analisia hara iristean soilik agertzen da. Beraz, kargatzen den profil bat sintaxia ondo dagoelako froga da, ez izendatzen dituen fitxategiak aurkitu direlako.

Zer bereizten duen eskuliburuak: --config eta --cd

OpenVPN 2.6 eskuliburuak bi aukera desberdin deskribatzen ditu. Batek konfigurazio fitxategi bat kargatzen du. Besteak prozesuaren direktorioa aldatzen du konfigurazioa, gakoa, scripta eta beste fitxategiak irakurri aurretik, eta unekoari erreferentziarik egiten ez dion direktorio absolutua eskatzen du.

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

Dei hori forma bat da, ez beste norbaiten profila abiarazteko jarraibidea. Emaiten dizuna determinismoa da: kateko izen erlatibo bakoitzaren oinarria komandoan adierazten da, prozesua abiarazi zuen shell edo kudeatzailerik heredatu ordez. Alternatiba berdin baliozkoa da eta sarritan hobea zerbitzu batentzat: utzi laneko direktorioa bakean eta egin profilaren barruko erreferentziatutako fitxategi guztiak absolutuak.

Nahi duzuna aukeratu, auditatu kate osoa eta ez lehen hutsegitea. Profil batek beste konfigurazio fitxategi bat ekar dezake, eta sartutako fitxategiaren izen erlatiboak prozesuaren direktorio beraren arabera ebazten dira, ez zituzten sartu zituen fitxategiaren direktorioaren arabera. Erregistroen bideak, autentifikazio fitxategiek eta script laguntzaileek arau bera jarraitzen dute.

Zerbitzua beste leku batean hasten da

Profilaren direktorioko shell interaktibo batek ez du ezer frogatzen paketatutako unit bati buruz. Kudeatzaileek beren laneko direktorioa ezartzen dute, eta bilgarri script batek berriro alda dezake binarioa exekutatu aurretik. Huts egiten duen unita da arrazoitzeko merezi duen abiarazte bakarra.

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

Bigarren komandoak prozesu bizia benetan atxikitzen ari den direktorioa erakusten du, eta hori unit fitxategia baino fidagarriagoa da bilgarria tartean dagoenean. Biak bat ez badatoz, bilgarria da zure erantzuna eta unita arrasto faltsua.

Bilaketaren ondoren: baimenak, chroot eta sandboxa

Oinarrizko direktorio zuzen batek mezu bera eman dezake oraindik, ebazpena eta sarbidea urrats bereiziak baitira. Prozesuak exekuzio baimena behar du guraso direktorio bakoitzean eta irakurketa baimena fitxategian, eta fitxategi-sistemaren zati bat ezkutatzen duen zerbitzu unit batek aldatzen du prozesuak zer ikus dezakeen.

Hiru aldaera arruntek errore bera sortzen dute. Fitxategia root-ek bakarrik irakur dezake, zerbitzuak pribilegioak uzten dituen bitartean ireki aurretik. Unitak fitxategi-sistemaren ikuspegi babesle bat ezartzen du, profilaren direktorioa barne hartzen ez duena. Daemona chroot-ekin exekutatzen da, beraz ostalarian existitzen den bidea ez da ikuspegi horren barruan existitzen.

Diagnostikatu fitxategiaren jabetzarekin eta prozesuaren identitatearekin, ez baimenak lasaituta. Gako pribatu bat denek irakurgarri egitea errore hau isilarazteko huts egite ozena isil batekin trukatzea da, eta gakoa direktorioaren erakutsi nahi duzun zatirik txikiena da.

Froga ezazu konponketa zeure abiaraztearekin

Berrabiarazi benetako unita profilarekin zerikusirik ez duen direktorio batetik eta begiratu abiarazte-lerro bera. Gero egiaztatu prozesuak kudeatzen duen direktorioa atxikitzen duela eta kargatu duen ziurtagiria espero duzuna dela.

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

Bideen karga arrakastatsua denean, autentifikazioa eta bideratzea oraindik etapa bereiziak dira, beren hutsegiteekin, eta altxatzen baina trafikorik pasatzen ez duen konexioa beste ikerketa bat da. Hemengo konponketa fitxategiak zein direktorioetatik etorri ziren soilik da, eta deian ikusgai egon beharko luke, azken aldiz eskuz exekutatu zuenak gogoratu ordez.

Profila konfigurazio kudeatzaile batekin zabaltzen bada, jarri oinarrizko direktorioa edo fitxategi-izen absolutuak han ere. Ostalari bakarrean eskuz egindako konponketa hurrengo berreraikuntzaren ondoren itzultzen den arazo honen bertsioa da.