OpenVPN nenájde ca.crt, hoci sa profil načíta

Služba sa spustí, prečíta profil bez sťažnosti a potom spadne na riadku, ktorý vyzerá nesúvislo: nemôže otvoriť ca.crt. Na certifikáte sa nič nezmenilo a cesta k profilu v unit súbore je absolútna. Práve táto kombinácia je stopa. Cesta, ktorú ste zadali, určuje jeden súbor, a mená vnútri tohto súboru sa riešia úplne inde, takže spustenie, ktoré vyzerá plne kvalifikovane, môže stále čítať svoje kľúče z adresára, ktorý nikto nezamýšľal.

Zlyhanie má málo príčin a oplatí sa ich oddeliť v poradí: základný adresár, ktorý proces skutočne mal, kontext spustenia služby a oprávnenia či sandbox okolo súboru, keď je cesta už správna. Každá zanecháva inú stopu — v unit súbore, v procese a na súborovom systéme.

Cesta k profilu nie je základný adresár

Predstavte si proces, ktorý štartuje v /tmp a dostane /etc/vpn/prod/tenant-a.ovpn. Vnútri tohto profilu riadok ca ca.crt označuje relatívnu cestu. Nič v argumente, ktorý profil lokalizoval, toto meno neprepisuje, takže proces hľadá /tmp/ca.crt a hlási chýbajúci súbor.

Mätúce je poradie chýb. OpenVPN najprv parsuje konfiguráciu a otvára odkazované súbory, ako k nim dochádza, takže preklep v profile sa ohlási skôr, než sa dotkne akýkoľvek kľúč, zatiaľ čo chýbajúci certifikát sa objaví až keď parsovanie dôjde tak ďaleko. Profil, ktorý sa načíta, je teda dôkazom, že syntax je v poriadku, nie že súbory, ktoré pomenúva, boli nájdené.

Čo manuál oddeľuje: --config a --cd

Manuál OpenVPN 2.6 opisuje dve odlišné voľby. Jedna načítava konfiguračný súbor. Druhá mení adresár procesu predtým, než sa prečítajú konfigurácia, kľúč, skript a ďalšie súbory, a vyžaduje absolútny adresár bez odkazu na aktuálny.

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

Toto volanie je tvar, nie pokyn spustiť cudzí profil. Čo vám dáva, je determinizmus: základ pre každé relatívne meno v reťazci je uvedený v príkaze namiesto toho, aby sa dedil z akéhokoľvek shellu či správcu, ktorý proces spustil. Alternatíva je rovnako platná a pre službu často lepšia: nechajte pracovný adresár na pokoji a každý odkazovaný súbor urobte vnútri profilu absolútnym.

Čokoľvek si vyberiete, prejdite celý reťazec, nie prvé zlyhanie. Profil môže pritiahnuť iný konfiguračný súbor a relatívne mená vloženého súboru sa riešia voči rovnakému adresáru procesu, nie voči adresáru súboru, ktorý ich vložil. Cesty k logom, autentifikačné súbory a pomocné skripty sa riadia rovnakým pravidlom.

Služba štartuje inde

Interaktívny shell v adresári profilu nič nedokazuje o zabalenom unit súbore. Správcovia nastavujú vlastný pracovný adresár a obaľovací skript ho môže pred spustením binárky znovu zmeniť. Unit, ktorý zlyháva, je jediné spustenie, o ktorom má zmysel uvažovať.

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

Druhý príkaz ukazuje adresár, ktorý živý proces skutočne drží, a to je spoľahlivejšie než unit súbor, keď je v hre obal. Ak sa oba nezhodujú, odpoveďou je obal a unit je falošná stopa.

Po hľadaní: oprávnenia, chroot a sandbox

Správny základný adresár môže napriek tomu vydať rovnakú správu, pretože riešenie a prístup sú samostatné kroky. Proces potrebuje právo spustenia na každom nadradenom adresári a právo čítania súboru, a unit služby, ktorý skrýva časť súborového systému, mení, čo proces vôbec môže vidieť.

Tri bežné varianty dávajú totožnú chybu. Súbor je čitateľný len pre root, zatiaľ čo služba sa pred jeho otvorením vzdáva privilégií. Unit nastavuje ochranný pohľad na súborový systém, ktorý adresár profilu nezahŕňa. Démon beží s chrootom, takže cesta, ktorá existuje na hostiteľovi, v tomto pohľade neexistuje.

Diagnostikujte podľa vlastníctva súboru a identity procesu, nie uvoľňovaním oprávnení. Urobiť súkromný kľúč čitateľným pre všetkých, aby táto chyba utíchla, vymieňa hlasné zlyhanie za tiché, a kľúč je práve tá časť adresára, ktorú chcete ukázať najmenej.

Dokážte opravu vlastným spustením

Reštartujte skutočný unit z adresára nesúvisiaceho s profilom a sledujte ten istý štartovací riadok. Potom potvrďte, že proces počas behu drží zamýšľaný adresár a že načítaný certifikát je ten, ktorý očakávate.

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

Keď načítanie ciest uspeje, autentifikácia a smerovanie sú stále oddelené fázy s vlastnými zlyhaniami, a spojenie, ktoré sa zdvihne, ale neprepustí prevádzku, je iné vyšetrovanie. Oprava tu sa týka len toho, z ktorého adresára súbory prišli, a mala by byť viditeľná vo volaní, nie pamätaná tým, kto ho naposledy spustil ručne.

Ak je profil nasadzovaný správcom konfigurácie, dajte tam aj základný adresár alebo absolútne názvy súborov. Ručná oprava na jednom hostiteľovi je verzia tohto problému, ktorá sa vracia po ďalšej prestavbe.