OpenVPN nu găsește ca.crt deși profilul se încarcă

Serviciul pornește, citește profilul fără nicio obiecție și apoi moare pe o linie care pare fără legătură: nu poate deschide ca.crt. Nimic la certificat nu s-a schimbat, iar calea profilului din fișierul unit este absolută. Exact această combinație este indiciul. Calea pe care ați dat-o localizează un fișier, iar numele din interiorul acelui fișier sunt rezolvate cu totul altundeva, așa că o lansare care pare complet calificată poate citi în continuare cheile dintr-un director pe care nimeni nu l-a intenționat.

Eșecul are puține cauze și merită separate în ordine: directorul de bază pe care procesul îl avea de fapt, contextul de lansare al serviciului și permisiunile sau sandbox-ul din jurul fișierului odată ce calea este corectă. Fiecare lasă o urmă diferită — în unit, în proces și pe sistemul de fișiere.

Calea profilului nu este un director de bază

Imaginați-vă un proces care pornește în /tmp și primește /etc/vpn/prod/tenant-a.ovpn. În interiorul acelui profil, linia ca ca.crt numește o cale relativă. Nimic din argumentul care a localizat profilul nu rescrie acel nume, așa că procesul caută /tmp/ca.crt și raportează un fișier lipsă.

Derutantă este ordinea erorilor. OpenVPN analizează mai întâi configurația și deschide fișierele referite pe măsură ce ajunge la ele, așa că o greșeală de tastare din profil este raportată înainte de a fi atinsă vreo cheie, în timp ce un certificat lipsă apare abia când analiza ajunge acolo. Un profil care se încarcă este deci dovada că sintaxa este corectă, nu că fișierele pe care le numește au fost găsite.

Ce separă manualul: --config și --cd

Manualul OpenVPN 2.6 descrie două opțiuni distincte. Una încarcă un fișier de configurare. Cealaltă schimbă directorul procesului înainte de a citi configurația, cheia, scriptul și alte fișiere, și cere un director absolut fără nicio referire la cel curent.

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

Acel apel este o formă, nu o instrucțiune de a lansa profilul altcuiva. Ce oferă este determinism: baza fiecărui nume relativ din lanț este declarată în comandă în loc să fie moștenită de la orice shell sau manager care a pornit procesul. Alternativa este la fel de validă și adesea mai bună pentru un serviciu: lăsați directorul de lucru în pace și faceți absolut fiecare fișier referit din profil.

Orice ați alege, auditați întregul lanț și nu primul eșec. Un profil poate atrage un alt fișier de configurare, iar numele relative ale fișierului inclus sunt rezolvate față de același director al procesului, nu față de directorul fișierului care le-a inclus. Căile jurnalelor, fișierele de autentificare și scripturile auxiliare urmează aceeași regulă.

Serviciul pornește în altă parte

Un shell interactiv în directorul profilului nu dovedește nimic despre o unitate împachetată. Managerii își stabilesc propriul director de lucru, iar un script înfășurător îl poate schimba din nou înainte de a rula binarul. Unitatea care eșuează este singura lansare despre care merită să raționăm.

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

A doua comandă arată directorul pe care procesul viu îl deține de fapt, iar acesta este mai de încredere decât fișierul unit atunci când există un înfășurător. Dacă cele două nu sunt de acord, înfășurătorul este răspunsul, iar unitatea este o urmă falsă.

După căutare: permisiuni, chroot și sandbox

Un director de bază corect poate produce în continuare același mesaj, fiindcă rezolvarea și accesul sunt pași separați. Procesul are nevoie de permisiune de execuție pe fiecare director părinte și de citire pe fișier, iar o unitate de serviciu care ascunde o parte a sistemului de fișiere schimbă ce poate vedea procesul.

Trei variante obișnuite produc aceeași eroare. Fișierul este lizibil doar pentru root, în timp ce serviciul renunță la privilegii înainte de a-l deschide. Unitatea setează o vedere protectoare a sistemului de fișiere care nu include directorul profilului. Demonul rulează cu chroot, așa că calea care există pe gazdă nu există în acea vedere.

Diagnosticați după proprietatea fișierului și identitatea procesului, nu prin relaxarea permisiunilor. A face o cheie privată lizibilă pentru toți ca să potoliți această eroare schimbă un eșec zgomotos pe unul silențios, iar cheia este exact partea directorului pe care vreți cel mai puțin să o expuneți.

Dovediți corectarea cu propria lansare

Reporniți unitatea reală dintr-un director fără legătură cu profilul și urmăriți aceeași linie de pornire. Apoi confirmați că procesul deține directorul dorit în timp ce rulează și că certificatul încărcat este cel așteptat.

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

Când încărcarea căilor reușește, autentificarea și rutarea rămân etape separate cu eșecurile lor, iar o conexiune care se ridică dar nu lasă trafic să treacă este altă investigație. Corectarea de aici privește doar din ce director au venit fișierele și ar trebui să fie vizibilă în apel, nu ținută minte de cel care l-a rulat manual ultima dată.

Dacă profilul este implementat de un manager de configurare, puneți acolo și directorul de bază sau numele absolute ale fișierelor. O corectare manuală pe o singură gazdă este versiunea acestei probleme care revine după următoarea reconstrucție.