OpenVPN nuk e gjen ca.crt edhe pse profili ngarkohet

Shërbimi nis, e lexon profilin pa asnjë ankesë dhe më pas vdes në një rresht që duket i palidhur: nuk mund të hapë ca.crt. Asgjë në certifikatë nuk ka ndryshuar, dhe rruga e profilit në skedarin unit është absolute. Pikërisht ai kombinim është shenja. Rruga që dhatë identifikon një skedar, dhe emrat brenda atij skedari zgjidhen diku tjetër krejt, kështu që një nisje që duket plotësisht e kualifikuar mund të lexojë ende çelësat e saj nga një drejtori që askush nuk e kishte për qëllim.

Dështimi ka pak shkaqe, dhe ia vlen t'i ndash sipas radhës: drejtoria bazë që procesi kishte në të vërtetë, konteksti i nisjes së shërbimit dhe lejet ose sandbox-i rreth skedarit kur rruga është tashmë e saktë. Secila lë një gjurmë të ndryshme — në unit, në proces dhe në sistemin e skedarëve.

Rruga e profilit nuk është drejtori bazë

Imagjinoni një proces që nis në /tmp dhe merr /etc/vpn/prod/tenant-a.ovpn. Brenda atij profili, rreshti ca ca.crt emërton një rrugë relative. Asgjë në argumentin që e gjeti profilin nuk e rishkruan atë emër, kështu që procesi kërkon /tmp/ca.crt dhe raporton një skedar që mungon.

Ajo që ngatërron është radha e gabimeve. OpenVPN e analizon konfigurimin së pari dhe hap skedarët e referuar ndërsa arrin në ta, kështu që një gabim shtypi në profil raportohet para se të preket ndonjë çelës, ndërsa një certifikatë që mungon shfaqet vetëm kur analiza arrin deri atje. Një profil që ngarkohet është pra provë se sintaksa është në rregull, jo se skedarët që emërton janë gjetur.

Çfarë ndan manuali: --config dhe --cd

Manuali i OpenVPN 2.6 përshkruan dy opsione të ndryshme. Njëri ngarkon një skedar konfigurimi. Tjetri ndryshon drejtorinë e procesit përpara se të lexohen konfigurimi, çelësi, skripti dhe skedarë të tjerë, dhe kërkon një drejtori absolute pa asnjë referencë ndaj asaj aktuale.

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

Ai thirrje është një formë, jo një udhëzim për të nisur profilin e dikujt tjetër. Ajo që jep është përcaktueshmëri: baza për çdo emër relativ në zinxhir deklarohet në komandë në vend që të trashëgohet nga çfarëdo shell-i ose menaxheri që nisi procesin. Alternativa është po aq e vlefshme dhe shpesh më e mirë për një shërbim: lëre drejtorinë e punës në paqe dhe bëje çdo skedar të referuar absolut brenda profilit.

Çfarëdo që të zgjidhni, auditojeni të gjithë zinxhirin dhe jo dështimin e parë. Një profil mund të tërheqë një skedar tjetër konfigurimi, dhe emrat relativë të skedarit të përfshirë zgjidhen ndaj të njëjtës drejtori procesi, jo ndaj drejtorisë së skedarit që i përfshiu. Rrugët e regjistrave, skedarët e autentikimit dhe skriptet ndihmëse ndjekin të njëjtin rregull.

Shërbimi nis diku tjetër

Një shell interaktiv në drejtorinë e profilit nuk provon asgjë për një unit të paketuar. Menaxherët vendosin drejtorinë e tyre të punës, dhe një skript mbështjellës mund ta ndryshojë përsëri përpara se të ekzekutohet binari. Uniti që dështon është e vetmja nisje për të cilën ia vlen të arsyetosh.

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

Komanda e dytë tregon drejtorinë që procesi i gjallë mban në të vërtetë, dhe kjo është më e besueshme sesa skedari unit kur ka një mbështjellës. Nëse të dy nuk përputhen, mbështjellësi është përgjigja dhe uniti është një gjurmë mashtruese.

Pas kërkimit: lejet, chroot dhe sandbox

Një drejtori bazë e saktë mund të prodhojë prapë të njëjtin mesazh, sepse zgjidhja dhe aksesi janë hapa të veçantë. Procesi ka nevojë për leje ekzekutimi në çdo drejtori prind dhe leje leximi në skedar, dhe një unit shërbimi që fsheh një pjesë të sistemit të skedarëve ndryshon atë që procesi mund të shohë fare.

Tre variante të zakonshme prodhojnë të njëjtin gabim. Skedari lexohet vetëm nga root, ndërsa shërbimi heq dorë nga privilegjet përpara se ta hapë. Uniti vendos një pamje mbrojtëse të sistemit të skedarëve që nuk përfshin drejtorinë e profilit. Daemoni punon me chroot, kështu që rruga që ekziston në host nuk ekziston brenda asaj pamjeje.

Diagnostikoni me pronësinë e skedarit dhe identitetin e procesit, jo duke i liruar lejet. Bërja e një çelësi privat të lexueshëm nga të gjithë për ta heshtur këtë gabim shkëmben një dështim të zhurmshëm me një të heshtur, dhe çelësi është pikërisht pjesa e drejtorisë që dëshironi më pak ta ekspozoni.

Provoni korrigjimin me nisjen tuaj

Rinisni unitin e vërtetë nga një drejtori pa lidhje me profilin dhe vëzhgoni të njëjtin rresht nisjeje. Më pas konfirmoni që procesi mban drejtorinë e synuar ndërsa punon, dhe që certifikata që ngarkoi është ajo që prisni.

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

Kur ngarkimi i rrugëve ka sukses, autentikimi dhe rrugëtimi mbeten faza të veçanta me dështimet e tyre, dhe një lidhje që ngrihet por nuk kalon trafik është një hetim tjetër. Korrigjimi këtu ka të bëjë vetëm me atë se nga cila drejtori erdhën skedarët, dhe duhet të jetë i dukshëm në thirrje në vend që ta mbajë mend ai që e ekzekutoi me dorë herën e fundit.

Nëse profili vendoset nga një menaxher konfigurimi, vendosni atje edhe drejtorinë bazë ose emrat absolutë të skedarëve. Një korrigjim manual në një host të vetëm është versioni i këtij problemi që kthehet pas rindërtimit të ardhshëm.