client-config-dir se ignorira, potem ko je OpenVPN postal storitev

Vaš tunel se dvigne in odjemalec se poveže, vendar fiksni naslov in potisnjene poti, ki ste jih določili za tega enega uporabnika, manjkajo. V dnevniku ne piše “file not found”, in prav to pošilja ljudi ponovno ustvarjati potrdila. V večini teh primerov demon teče iz drugega imenika kot lupina, v kateri ste testirali, in client-config-dir ni bil nikoli razrešen tako, kot ste predpostavili. Popravek je popravek poti, ne ponastavitev poverilnic.

Preberite unit, preden se dotaknete konfiguracije

Začnite s procesom, ki resnično teče, ne z datoteko, ki ste jo uredili. Vprašajte systemd za vrstico zagona, delovni imenik in račun, na katerega preide. Ti trije odgovori pojasnijo večino okvar te vrste:

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

Prazen WorkingDirectory pomeni, da se unit začne v /, zato se relativni client-config-dir ccd išče v /ccd. Ta imenik skoraj nikoli ne obstaja in demon njegove odsotnosti ne šteje za usodno.

Primerjajte to z interaktivnim zagonom, ki ste ga uporabili med testiranjem, kjer je bil trenutni imenik vaše lupine verjetno konfiguracijski. Ista datoteka, iste ključne besede, dva različna rezultata.

Glede na kaj se razreši relativna pot

Ključna beseda se razreši glede na delovni imenik procesa v trenutku, ko se možnost uporabi. To ne pomeni “ob konfiguracijski datoteki, ki sem jo posredoval z --config”. OpenVPN bo z veseljem prebral konfiguracijo z absolutne poti in bo relativne vrednosti še vedno razrešil drugje, in prav v tem je past. Priročnik OpenVPN 2.6 navaja pravilo pod --client-config-dir in znova pod --cd.

Ključna beseda cd spremeni ta kontekst, preden se preberejo druge datoteke, zato se unit, ki nastavi cd /etc/openvpn/server in nato client-config-dir ccd, razreši v /etc/openvpn/server/ccd. Če dodate cd, preverite vrstni red direktiv in zapomnite si, da vpliva na vsako drugo relativno referenco v isti datoteki.

Pojdite po poti kot račun demona

Pot je lahko pravilna in vendar neberljiva. Po spustu privilegijev demon ni več root, zato vsak nadrejeni imenik potrebuje dovoljenje za iskanje za ta račun, sama odjemalčeva datoteka pa dovoljenje za branje. En manjkajoč bit izvajanja na nadrejenem imeniku je dovolj, da datoteko skrije, napaka pa se pokaže le kot odjemalec, ki tiho dobi privzeti bazen.

namei izpiše dovoljenja vsakega dela po vrsti, kar je hitreje kot preverjanje imenikov enega za drugim:

namei -l /etc/openvpn/server/ccd/client1

Nato preizkusite branje kot račun storitve in ne kot vi:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

Če unit uporablja chroot, mora imenik obstajati znotraj ječe, pot v konfiguraciji pa se razlaga po uporabi chroot. Datoteka, ki je na gostitelju zunaj ječe, je od znotraj nevidna.

Potrdite iskanje, namesto da ugibate

Dvignite raven dnevnika za en ponovni zagon in preberite, kaj strežnik pravi o možnostih, specifičnih za odjemalca. Pri verb 4 demon poroča o uvoženi konfiguraciji za vsakega odjemalca, zato je manjkajoča vrstica neposreden dokaz, da za to povezavo ni bila prebrana nobena datoteka.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

Zaženite to v ospredju na prostem vratih in povežite enega odjemalca. To popolnoma odstrani systemd s slike: če se prepisi pojavijo tukaj in ne pod storitvijo, je razlika v kontekstu unita, ne v datoteki.

Odločite, kaj naj se zgodi, ko se nobena datoteka ne ujema. Brez ccd-exclusive je odjemalec sprejet samo z globalnimi nastavitvami bazena, in to je tiha okvara, opisana zgoraj. Z njo manjkajoča datoteka postane zavrnjena povezava, in taka zavrnitev je lažje opaziti, a težje odpraviti pod obremenitvijo.

Popravite, znova zaženite, preverite

Naredite imenik v konfiguraciji absoluten in ga pustite takega. Relativne poti so varne le, kadar unit pritrdi delovni imenik, pritrditev pa je dodaten gibljiv del, ki ga bo nekdo pozneje odstranil.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

Znova zaženite primerek, znova povežite enega znanega odjemalca in preberite naslov, ki ga je prejel, skupaj s potmi, potisnjenimi proti njemu. Če se naslov ujema z vrstico ifconfig-push v datoteki tega odjemalca, je iskanje delovalo. Če odjemalec še vedno pristane v splošnem bazenu, se vrnite k številu vrstic v dnevniku: nič uvozov pomeni, da so pot ali identiteta napačne, en uvoz z napačno vsebino pomeni, da urejate drugo datoteko od tiste, ki jo bere demon.

Vrnite se z obnovitvijo prejšnjega unita in konfiguracije skupaj, nato znova zaženite. Potrdil za nič od tega ni treba ponovno izdati, in obravnavanje težave z imenikom kot težave s poverilnicami je pot, po kateri petminutni popravek postane servisno okno.