OpenVPN, profil yüklense de ca.crt dosyasını bulamıyor

Hizmet başlar, profili hiçbir şikâyet olmadan okur ve sonra ilgisiz görünen bir satırda ölür: ca.crt dosyasını açamaz. Sertifikada hiçbir şey değişmemiştir ve unit dosyasındaki profil yolu mutlaktır. Tam da bu bileşim ipucudur. Verdiğiniz yol tek bir dosyayı bulur, o dosyanın içindeki adlar ise tamamen başka bir yerde çözülür, bu yüzden tam nitelikli görünen bir başlatma bile anahtarlarını kimsenin amaçlamadığı bir dizinden okuyor olabilir.

Başarısızlığın az sayıda nedeni vardır ve bunları sırayla ayırmakta yarar var: sürecin gerçekte sahip olduğu temel dizin, hizmetin başlatma bağlamı ve yol doğru olduğunda dosyanın çevresindeki izinler veya sandbox. Her biri farklı bir iz bırakır — unit dosyasında, süreçte ve dosya sisteminde.

Profil yolu bir temel dizin değildir

/tmp içinde başlayan ve /etc/vpn/prod/tenant-a.ovpn alan bir süreç düşünün. O profilin içinde ca ca.crt satırı göreli bir yol belirtir. Profili bulan argümanda hiçbir şey bu adı yeniden yazmaz, bu yüzden süreç /tmp/ca.crt arar ve eksik dosya bildirir.

Kafa karıştıran şey hataların sırasıdır. OpenVPN önce yapılandırmayı ayrıştırır ve başvurulan dosyaları onlara ulaştıkça açar; bu yüzden profildeki bir yazım hatası herhangi bir anahtara dokunulmadan bildirilirken eksik sertifika ancak ayrıştırma oraya vardığında ortaya çıkar. Yani yüklenen bir profil sözdiziminin doğru olduğunun kanıtıdır, adını verdiği dosyaların bulunduğunun değil.

Kılavuzun ayırdığı şey: --config ve --cd

OpenVPN 2.6 kılavuzu iki ayrı seçenek tanımlar. Biri bir yapılandırma dosyası yükler. Diğeri yapılandırma, anahtar, betik ve diğer dosyalar okunmadan önce sürecin dizinini değiştirir ve geçerli dizine hiçbir gönderme yapmayan mutlak bir dizin ister.

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

Bu çağrı bir biçimdir, başkasının profilini başlatma talimatı değil. Size verdiği şey belirliliktir: zincirdeki her göreli adın temeli, süreci başlatan herhangi bir kabuk veya yöneticiden miras alınmak yerine komutta belirtilir. Alternatif de aynı ölçüde geçerlidir ve bir hizmet için çoğu zaman daha iyidir: çalışma dizinini olduğu gibi bırakın ve profilin içindeki her başvurulan dosyayı mutlak yapın.

Hangisini seçerseniz seçin, ilk hatayı değil tüm zinciri denetleyin. Bir profil başka bir yapılandırma dosyasını çekebilir ve eklenen dosyanın göreli adları, kendilerini ekleyen dosyanın dizinine değil aynı süreç dizinine göre çözülür. Günlük yolları, kimlik doğrulama dosyaları ve yardımcı betikler aynı kurala uyar.

Hizmet başka bir yerde başlar

Profil dizinindeki etkileşimli bir kabuk, paketlenmiş bir unit hakkında hiçbir şey kanıtlamaz. Yöneticiler kendi çalışma dizinlerini belirler ve bir sarmalayıcı betik ikili çalışmadan önce onu yeniden değiştirebilir. Başarısız olan unit, üzerinde akıl yürütmeye değer tek başlatmadır.

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

İkinci komut, canlı sürecin gerçekte tuttuğu dizini gösterir ve bir sarmalayıcı işin içindeyken bu, unit dosyasından daha güvenilirdir. İkisi uyuşmuyorsa yanıt sarmalayıcıdır ve unit yanıltıcı bir izdir.

Aramanın ardından: izinler, chroot ve sandbox

Doğru bir temel dizin yine de aynı iletiyi üretebilir, çünkü çözümleme ve erişim ayrı adımlardır. Sürecin her üst dizinde çalıştırma iznine ve dosyada okuma iznine ihtiyacı vardır ve dosya sisteminin bir bölümünü gizleyen bir hizmet unit’i, sürecin neyi görebileceğini baştan değiştirir.

Üç yaygın varyant aynı hatayı üretir. Dosya yalnızca root tarafından okunabilirken hizmet, dosyayı açmadan önce ayrıcalıklardan vazgeçer. Unit, profil dizinini içermeyen koruyucu bir dosya sistemi görünümü ayarlar. Daemon chroot ile çalışır, bu yüzden ana makinede var olan yol o görünümün içinde yoktur.

İzinleri gevşetmek yerine dosyanın sahipliği ve sürecin kimliğiyle teşhis edin. Bu hatayı susturmak için özel bir anahtarı herkesin okuyabildiği hâle getirmek, gürültülü bir başarısızlığı sessiz olanla değişir ve anahtar, dizinin en az açığa çıkarmak istediğiniz parçasıdır.

Düzeltmeyi kendi başlatmanızla kanıtlayın

Gerçek unit’i profille ilgisiz bir dizinden yeniden başlatın ve aynı açılış satırını izleyin. Ardından sürecin çalışırken amaçlanan dizini tuttuğunu ve yüklediği sertifikanın beklediğiniz olduğunu doğrulayın.

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

Yol yüklemesi başarılı olduğunda, kimlik doğrulama ve yönlendirme hâlâ kendi başarısızlıkları olan ayrı aşamalardır ve bağlantı kurulup trafik geçmiyorsa bu başka bir incelemedir. Buradaki düzeltme yalnızca dosyaların hangi dizinden geldiğiyle ilgilidir ve son kez elle çalıştıranın aklında kalması yerine çağrıda görünmelidir.

Profil bir yapılandırma yöneticisi tarafından dağıtılıyorsa temel dizini veya mutlak dosya adlarını oraya da koyun. Tek bir ana makinede elle yapılan düzeltme, sonraki yeniden derlemeden sonra geri dönen bu sorunun sürümüdür.