OpenVPN ne trovas ca.crt eĉ kvankam la profilo ŝargiĝas

La servo startas, legas la profilon sen plendo, kaj poste mortas ĉe linio, kiu ŝajnas sensignifa: ĝi ne povas malfermi ca.crt. Nenio pri la atestilo ŝanĝiĝis, kaj la profila vojo en la unit-dosiero estas absoluta. Ĝuste tiu kombinaĵo estas la signo. La vojo, kiun vi donis, lokigas unu dosieron, kaj la nomoj ene de tiu dosiero estas solvataj tute aliloke, do lanĉo, kiu aspektas plene kvalifikita, povas ankoraŭ legi siajn ŝlosilojn el dosierujo, kiun neniu intencis.

La malsukceso havas malmultajn kaŭzojn, kaj indas apartigi ilin laŭ ordo: la baza dosierujo, kiun la procezo efektive havis, la lanĉa kunteksto de la servo, kaj la permesoj aŭ sablujo ĉirkaŭ la dosiero post kiam la vojo estas ĝusta. Ĉiu lasas alian spuron — en la unit-dosiero, en la procezo kaj en la dosiersistemo.

La profila vojo ne estas baza dosierujo

Imagu procezon, kiu startas en /tmp kaj ricevas /etc/vpn/prod/tenant-a.ovpn. En tiu profilo, la linio ca ca.crt nomas relativan vojon. Nenio en la argumento, kiu lokigis la profilon, reskribas tiun nomon, do la procezo serĉas /tmp/ca.crt kaj raportas mankantan dosieron.

Konfuzas la ordo de la eraroj. OpenVPN unue analizas la agordon kaj malfermas referencitajn dosierojn dum ĝi atingas ilin, do tajperaro en la profilo estas raportata antaŭ ol iu ajn ŝlosilo estas tuŝata, dum mankanta atestilo aperas nur kiam la analizo tiom antaŭeniras. Profilo, kiu ŝargiĝas, do estas pruvo, ke la sintakso estas en ordo, ne ke la dosieroj, kiujn ĝi nomas, estis trovitaj.

Kion la manlibro apartigas: --config kaj --cd

La manlibro de OpenVPN 2.6 priskribas du apartajn opciojn. Unu ŝargas agordan dosieron. La alia ŝanĝas la procezan dosierujon antaŭ ol agordo, ŝlosilo, skripto kaj aliaj dosieroj estas legataj, kaj ĝi postulas absolutan dosierujon sen ia referenco al la nuna.

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

Tiu alvoko estas formo, ne instrukcio lanĉi ies alies profilon. Kion ĝi donas al vi, estas determineco: la bazo por ĉiu relativa nomo en la ĉeno estas dirita en la komando anstataŭ heredita de iu ajn ŝelo aŭ administrilo, kiu startigis la procezon. La alternativo same validas kaj ofte pli bonas por servo: lasu la laboran dosierujon trankvila kaj faru ĉiun referencitan dosieron absoluta ene de la profilo.

Kion ajn vi elektos, kontrolu la tutan ĉenon anstataŭ la unuan malsukceson. Profilo povas entiri alian agordan dosieron, kaj la relativaj nomoj de la inkludita dosiero estas solvataj kontraŭ la sama proceza dosierujo, ne kontraŭ la dosierujo de la dosiero, kiu inkludis ilin. Protokolaj vojoj, aŭtentigaj dosieroj kaj helpaj skriptoj sekvas la saman regulon.

La servo startas aliloke

Interaga ŝelo en la profila dosierujo pruvas nenion pri pakaĵa unit-dosiero. Administriloj starigas sian propran laboran dosierujon, kaj ĉirkaŭa skripto povas ŝanĝi ĝin denove antaŭ ol la binaraĵo ruliĝas. La unit-dosiero, kiu malsukcesas, estas la sola lanĉo, pri kiu indas rezonadi.

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

La dua komando montras la dosierujon, kiun la vivanta procezo efektive tenas, kaj tio estas pli fidinda ol la unit-dosiero, kiam ĉirkaŭaĵo estas implikita. Se la du malkonsentas, la ĉirkaŭaĵo estas via respondo kaj la unit-dosiero estas falsa spuro.

Post la serĉo: permesoj, chroot kaj sablujo

Ĝusta baza dosierujo ankoraŭ povas produkti la saman mesaĝon, ĉar solvado kaj aliro estas apartaj paŝoj. La procezo bezonas plenumpermeson sur ĉiu gepatra dosierujo kaj legpermeson sur la dosiero, kaj serva unit-dosiero, kiu kaŝas parton de la dosiersistemo, ŝanĝas tion, kion la procezo entute povas vidi.

Tri oftaj variantoj produktas identan eraron. La dosiero estas legebla nur de root, dum la servo demetas privilegiojn antaŭ ol malfermi ĝin. La unit-dosiero starigas protektan vidon de la dosiersistemo, kiu ne inkludas la profilan dosierujon. La demono ruliĝas kun chroot, do la vojo, kiu ekzistas sur la gastiganto, ne ekzistas ene de tiu vido.

Diagnozu per la posedanto de la dosiero kaj la identeco de la procezo, ne per malstreĉigo de permesoj. Fari privatan ŝlosilon legebla por ĉiuj por silentigi ĉi tiun eraron interŝanĝas laŭtan malsukceson kontraŭ silenta, kaj la ŝlosilo estas ĝuste tiu parto de la dosierujo, kiun vi plej malmulte volas elmeti.

Pruvu la riparon per la propra lanĉo

Restartigu la veran unit-dosieron el dosierujo senrilata al la profilo kaj observu la saman startlinion. Poste konfirmu, ke la procezo tenas la celitan dosierujon dum ĝi ruliĝas, kaj ke la atestilo, kiun ĝi ŝargis, estas la atendita.

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

Kiam ŝargado de vojoj sukcesas, aŭtentigo kaj enkursigado ankoraŭ estas apartaj etapoj kun propraj malsukcesoj, kaj konekto, kiu leviĝas sed trapasas neniun trafikon, estas alia esploro. La riparo ĉi tie temas nur pri tio, el kiu dosierujo la dosieroj venis, kaj ĝi devus esti videbla en la alvoko anstataŭ memorebla de tiu, kiu laste ruligis ĝin permane.

Se la profilon disigas agorda administrilo, metu la bazan dosierujon aŭ la absolutajn dosiernomojn ankaŭ tie. Permana riparo sur unu gastiganto estas la versio de ĉi tiu problemo, kiu revenas post la sekva rekonstruo.