GUI’nin açtığı profilde OpenVPN servisi başarısız oluyor: beş kontrol
Aynı profil, farklı başlatıcı. Çalışma dizinini, hizmet hesabını, şifreli dosya özniteliğini, sahibi ve son olarak sarmalayıcıyı kontrol edin.
İki başlatıcı aynı makinede aynı profili açar ve yalnızca GUI bağlanır. Dosya sağlamdır ve yükleyici muhtemelen sorunsuzdur; fark, her başlatıcının openvpn.exe için verdiği bağlamdır. Çalışma dizini, hesap kimliği ve dosya öznitelikleri bu bağlamla birlikte taşınır. Bunları bu sırayla kontrol edin ve hatayı açıklayan ilkinde durun.
Hangi başlatıcının başarısız olduğunu doğrulayın
Bölünmeyi kanıtlayarak başlayın. Aynı profil yoluyla GUI bağlanıyor da servis bağlanmıyorsa, dosyayı birileri okuyabiliyordur ve soru kimin, nereden okuduğuna dönüşür. İkisi de başarısız olursa profil bozuktur ve bunların hiçbiri geçerli değildir. Servisin adını ve yüklemekle görevlendirildiği tam profili yazın.
Kendi otomatik başlatma dizinine yönlendirilen bir servis, bir düzenleyicide açık tuttuğunuz dosyayı yüklemiyor olabilir. Servis yapılandırmasındaki yolu GUI’deki yol ile karakter karakter karşılaştırın, çünkü sonda kalan bir klasör adı ya da farklı bir sürücü harfi sizi yanlış dala göndermeye yeter.
Göreli yollar nerede çözülür
Bir yardımcı betiği veya ca.crt dosyasını çıplak adla referans veren profil, sürecin bulunduğu yere göre bir arama ister. GUI yapılandırma klasöründe başlar, dolayısıyla o adlar çözülür. Servis yöneticisi tarafından başlatılan bir servisin böyle bir başlangıç noktası yoktur ve herhangi bir sertifika okunmadan önce arama başarısız olur. Aynı profilin bir başlatıcıda çalışıp diğerinde çalışmamasının nedeni budur.
Sarmalayıcıya başlayacağı bir dizin verin ya da her referansı mutlak yapın. GUI bağlamını bir komut satırında yeniden üretmek şöyle görünür:
openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"
Bu komutta ayrıntı düzeyini yükseltmek, denenen tam yolu gösterir. İzinleri değiştirmeden önce bunu yapın, çünkü eksik bir dosya ile reddedilen bir okuma farklı düzeltmeler gerektirir. Varsayılan günlük bunları ayırt etmez. Tek bir ek bayrak bir saatlik tahminden kurtarır.
Servis kimliği okuyamadığında
Bir servis sizin kimliğinizle değil, bir sistem kimliğiyle çalışır. Kullanıcınıza tam denetim verip başka kimseye vermeyen bir ACL, sizin oturumunuzda kusursuz çalışırken orada başarısız olur. Eşlenmiş bir sürücüde ya da kimlik doğrulamalı bir paylaşımda tutulan profil de aynı nedenle başarısız olur. Başka bir şeye bakmadan önce dosyanın izinlerini doğrulayın.
Kontrol, etkin izinlerin okunması artı servis kimliği olarak denenmiş bir okumadır. İlk kısmı yükseltilmiş bir komut isteminden çalıştırın:
icacls "C:\VPN\profiles\office\office.ovpn"
Ardından aynı okumayı servis kimliği olarak deneyin, örneğin Sysinternals’tan psexec -s -i ile, ve dosyanın açılıp açılmadığını izleyin. Açılmıyorsa hiçbir yol düzeltmesi yardımcı olmaz. ACL’yi düzeltin ya da profili servis kimliğinin okuyabildiği bir konuma taşıyın.
Dosya düzeyinde şifreleme ikinci ve daha nadir durumdur. Encrypting File System özniteliğiyle işaretlenmiş bir profil, onu şifreleyen kullanıcı için saydam olarak çözülür ve servis hesabı için okunamaz kalır. Aynı dosyanın sizin düzenleyicinizde açılıp servis altında açılmamasının nedeni budur.
Öznitelik yükseltilmiş bir komut isteminden görünür ve onu kontrol etmek profili açmaz. İki komutu da çalıştırın ve çıktıyı okuyun:
cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"
Özniteliği temizlemek dosyayı okunabilir yapar ve taşıdığı korumayı da kaldırır. Profilin korunması gerekiyorsa, kullanıcı başına şifrelemeye güvenmek yerine gizli malzemeyi servis kimliğinin açık bir izni olduğu yere koyun. Böyle bir düzen bir parola değişikliğini atlatır ve erişimi dosyayı şifreleyen kişi dışında birinin de denetlemesini sağlar.
Tünelin sahibinin kim olacağına karar vermek
GUI bir parola sorabilir ve sertifikayı kullanıcı deposundan okuyabilir. Servis ikisini de yapamaz, bu yüzden etkileşimli bir sırra bağlı profil, yollar ne kadar düzeltilirse düzeltilsin gözetimsiz asla başlamaz. Bu sınır bir tasarım kararıdır, etrafından dolanılacak bir kusur değil. Başka bir şeyi değiştirmeden önce tek bir sahip seçin.
Tünel oturum açmadan önce ayakta olmak zorundaysa, servise gözetimsiz bir kimlik bilgisi kaynağı ve profilin kendi kopyasını verin. Yalnızca masadayken var olması gerekiyorsa, onu GUI’de tutun ve servis kopyasını kaldırın. İkisi birden, bağdaştırıcı çakışmaları ve yinelenen rotalar üreten yapılandırmadır.
Bu çakışma genellikle tek bir bağdaştırıcı için çarpışan iki sahip olarak değil, bir yapılandırma hatası olarak teşhis edilir. Olay günlüğü bir sürecin TAP aygıtını açmakta başarısız olduğunu gösterir; bu izin sorunu gibi görünür ama değildir. Önce sahipleri sayın.
Servis sarmalayıcısı gerçekte neyi başlatır
Servisin giriş noktası, kendi sakladığı parametreleri okuyup ardından openvpn.exe dosyasını başlatan küçük bir sarmalayıcıdır. Olay günlüğündeki komut satırı beklentinizle çeliştiğinde, incelenmesi gereken şey o değerlerdir. Yeniden yükleme onları varsayılana döndürür ve kanıtları yok eder. Önce onları okuyun.
Değerler kayıt defterinde servisin kendi anahtarının altında yaşar ve sc qc servis yöneticisinin başlatacağı ikili yolunu gösterir. Herhangi birini düzenlemeden önce bu yolu sarmalayıcının sakladığı yapılandırmayla karşılaştırın.
Sarmalayıcıyı kontrol ettiğiniz bir betikle değiştirmek daha müdahaleci olur, ama etkin komut satırını tek okunabilir dosyaya indirger. Yeniden başlatmayla bitirin, ardından ilk başarılı başlangıç satırı görünene kadar profil başına günlüğü okuyun. “Çalışıyor” servis durumu yalnızca sarmalayıcının çıkmadığı anlamına gelir; bu, alt süreci hemen öldüğünde de doğrudur.