OpenVPN bir hizmet olduktan sonra client-config-dir yok sayılıyor

Tüneliniz açılıyor ve istemci bağlanıyor, ancak sabit adres ve o tek kullanıcı için tanımladığınız itilen yollar eksik. Günlükte “file not found” yazmıyor ve insanları sertifikaları yeniden üretmeye gönderen tam olarak bu. Bu durumların çoğunda daemon, test ettiğiniz kabuktan farklı bir dizinden çalışır ve client-config-dir hiçbir zaman varsaydığınız gibi çözülmedi. Düzeltme bir yol düzeltmesidir, kimlik bilgilerinin sıfırlanması değil.

Yapılandırmaya dokunmadan önce unit dosyasını okuyun

Düzenlediğiniz dosyadan değil, gerçekten çalışan süreçten başlayın. systemd'ye yürütme satırını, çalışma dizinini ve hangi hesaba düştüğünü sorun. Bu üç yanıt bu sınıftaki arızaların çoğunu açıklar:

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

Boş bir WorkingDirectory unit dosyasının / içinde başladığı anlamına gelir, bu yüzden göreli client-config-dir ccd /ccd altında aranır. O dizin neredeyse hiç var olmaz ve daemon yokluğunu ölümcül saymaz.

Bunu test sırasında kullandığınız etkileşimli başlatmayla karşılaştırın; orada kabuğunuzun geçerli dizini muhtemelen yapılandırma diziniydi. Aynı dosya, aynı anahtar sözcükler, iki farklı sonuç.

Göreli bir yol neye göre çözülür

Anahtar sözcük, seçenek kullanıldığı anda sürecin çalışma dizinine göre çözülür. Bu, “--config ile verdiğim yapılandırma dosyasının yanında” anlamına gelmez. OpenVPN bir yapılandırmayı mutlak bir yoldan memnuniyetle okur ve göreli değerleri yine de başka yerde çözer; buradaki tuzak tam olarak budur. OpenVPN 2.6 kılavuzu kuralı --client-config-dir ve yeniden --cd altında belirtir.

cd anahtar sözcüğü bu bağlamı diğer dosyalar okunmadan önce değiştirir, bu yüzden cd /etc/openvpn/server ve ardından client-config-dir ccd ayarlayan unit /etc/openvpn/server/ccd olarak çözülür. cd eklerseniz, yönergelerin sırasını kontrol edin ve aynı dosyadaki her diğer göreli başvuruyu etkilediğini unutmayın.

Yolu daemonun hesabı olarak gezin

Yol doğru olabilir ve yine de okunamaz. Yetki düşürüldükten sonra daemon artık root değildir, bu yüzden her üst dizin o hesap için arama izni, istemci dosyasının kendisi de okuma izni gerektirir. Bir üst dizinde tek bir eksik çalıştırma biti dosyayı gizlemeye yeter ve hata yalnızca sessizce varsayılan havuzu alan bir istemci olarak ortaya çıkar.

namei her bileşenin iznini sırayla yazdırır, bu da dizinleri tek tek denetlemekten hızlıdır:

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

Ardından okumayı kendiniz olarak değil hizmet hesabı olarak deneyin:

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

Unit chroot kullanıyorsa, dizin hapishanenin içinde bulunmalıdır ve yapılandırmadaki yol chroot uygulandıktan sonra yorumlanır. Konağın hapishane dışındaki bir dosyası içeriden görünmez.

Tahmin etmek yerine aramayı doğrulayın

Bir yeniden başlatma için günlük düzeyini yükseltin ve sunucunun istemciye özgü seçenekler hakkında ne dediğini okuyun. verb 4 düzeyinde daemon içe aktardığı istemci başına yapılandırmayı bildirir, bu yüzden eksik bir satır o bağlantı için hiçbir dosyanın okunmadığının doğrudan kanıtıdır.

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

Bunu boş bir bağlantı noktasında önplanda çalıştırın ve bir istemci bağlayın. Bu, systemd'yi tamamen resimden çıkarır: geçersiz kılmalar burada görünüp hizmet altında görünmüyorsa fark dosyada değil, unit bağlamındadır.

Hiçbir dosya eşleşmediğinde ne olması gerektiğine karar verin. ccd-exclusive olmadan istemci yalnızca genel havuz ayarlarıyla kabul edilir ve yukarıda açıklanan sessiz arıza budur. Onunla eksik bir dosya reddedilmiş bir bağlantıya dönüşür ve bu ret fark edilmesi daha kolay ama yük altında ayıklanması daha zordur.

Düzeltin, yeniden başlatın, doğrulayın

Dizini yapılandırmada mutlak yapın ve öyle bırakın. Göreli yollar yalnızca unit çalışma dizinini sabitlediğinde güvenlidir ve sabitlemek, birinin sonradan kaldıracağı ekstra hareketli bir parçadır.

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

Örneği yeniden başlatın, bilinen bir istemciyi yeniden bağlayın ve aldığı adresi ona itilen yollarla birlikte okuyun. Adres o istemcinin dosyasındaki ifconfig-push satırıyla eşleşiyorsa arama çalıştı. İstemci hâlâ genel havuza düşüyorsa günlük satır sayısına dönün: sıfır içe aktarma yolun ya da kimliğin yanlış olduğu anlamına gelir, yanlış içerikli tek bir içe aktarma ise daemonun okuduğundan farklı bir dosyayı düzenlediğiniz anlamına gelir.

Önceki unit ve yapılandırmayı birlikte geri yükleyerek geri dönün, sonra yeniden başlatın. Bunların hiçbiri için sertifikaların yeniden verilmesi gerekmez ve bir dizin sorununu kimlik bilgisi sorunu olarak ele almak, beş dakikalık bir düzeltmenin bakım penceresine dönüşmesinin yoludur.