OpenVPN hizmeti özel anahtar parolasını sorarken takılıyor: nasıl düzeltilir
Hizmetin terminali yoktur, bu yüzden şifrelenmiş anahtar askpass ve okunabilir bir dosya gerektirir. Anahtarın parolasını sunucu oturum açmasından ayırın ve unit’i denetleyin.
OpenVPN özel anahtarın parolasını yerel makinede sorar, bu yüzden çalışan bir oturum açma dosyası buna asla yanıt vermez. Bir hizmette yazacak terminal yoktur ve başlatma ya takılır ya da nedeni değil girdiyi adlandıran bir journal kaydıyla başarısız olur. İki gizli değer devrededir ve her biri unit yeniden başlatılmadan önce kendi okunabilir kaynağına ihtiyaç duyar. Aşağıdaki akış bunları ayırır, ardından her dosyayı gerçekten açan kimliği denetler.
İki istemi ayırt edin
Anahtarın parolası yerel özel anahtarın şifresini çözer; hesap kimlik bilgileri oturumu sunucuya doğrular. Farklı yerlerden gelirler, farklı anlarda başarısız olurlar ve farklı iletiler üretirler. Bunları karıştırmak, hesap hiç devrede değilken insanları parola sıfırlama aramaya gönderir. Herhangi bir seçeneği değiştirmeden önce istemin metnini okuyun, çünkü ifade hangi gizli değerin eksik olduğuna dair tek güvenilir ipucudur.
Community OpenVPN 2.x’te askpass anahtarın parolasını ilk satırında tutan dosyayı, auth-user-pass ise bir satırda kullanıcı adını ve sonraki satırda parolayı tutan dosyayı belirtir. İki dosyadan hiçbiri diğer seçeneği karşılayamaz. Bir masaüstü uygulaması veya NetworkManager profili ikisini kendi gizli deposunda tutabilir; komut satırı istemcisi bunu hiç okumaz, bu yüzden herhangi bir yol yazmadan önce hangi istemciyi yapılandırdığınızı not edin.
İki seçeneği de okunabilir dosyalara yönlendirin
Her iki girdiye ihtiyaç duyan bir profil sonunda üç dosya başvurusuyla kalır: şifrelenmiş anahtar, onu açan parola ve oturum açma çifti. Bunları CA’ya ve kimlik denetimlerine dokunmadan ekleyin, çünkü onlar sunucunun kim olduğunu belirler ve bu sorunun parçası değildir. Dağıtım hesap kimlik bilgilerini hiç kullanmıyorsa auth-user-pass eklemek kimsenin sağlayamayacağı bir girdi yaratır.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authBağımsız değişkensiz seçenekler yollu seçeneklerden farklı davranır ve bir hizmette bu fark önemlidir. Bağımsız değişkensiz bir askpass hâlâ konsolu okur ve yalnızca kullanıcı adı içeren bir auth-user-pass dosyası hâlâ bir parola istemini bekletir. İstemci daemonlaştığında terminalden hiç girdi isteyemez, bu yüzden böyle yapılandırılmış bir hizmet ayağa kalkmaz.
Mutlak yollar çalışma dizini sorusunu ortadan kaldırır ama erişim vermez. Ardından sahiplik, mod ve geçiş gelir; üçü de sürecin çalıştığı hesaba göre denetlenir.
Profilden önce unit’in yapılandırmasını okuyun
Örneğin hangi yapılandırmayı yükleyeceğine, düzenlediğiniz dosya değil unit karar verir. Komut satırını ve tüm drop-in dosyalarını okuyun, sonra çalışma dizinini izleyerek gerçekten kullanılan profile ulaşın. Başka bir .ovpn dosyasına eklenen parola başvurusu bu örnek için hiçbir şeyi değiştirmez.
Üç salt okunur komut bunun çoğunu yanıtlar. Birincisi unit’i ve tüm drop-in dosyalarını, ikincisi süreci bağlayan kimliği ve sandbox ayarlarını, üçüncüsü ise son başlatmanın gerçekte neyden yakındığını yazdırır. Ana makinede var olan örnek adını kullanın:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome ve profilin kendi user, group ve chroot seçeneklerine dikkat edin. Ev dizini altındaki bir dosya kabuğunuzda okunabilir, ev dizinleri gizlendiğinde ise hizmetin içinde görünmez olabilir. systemd’nin başlattığı hesap her zaman anahtarı sonunda açan hesap değildir.
Çalışma zamanı kimliğinin iki dosyayı da açabildiğini kanıtlayın
Modu okumak yeterli değildir, çünkü yoldaki her dizinin aynı kimlik tarafından geçilebilir olması gerekir. Yolu bileşen bileşen yürüyün, sonra sürecin kullandığı hesap olarak açmayı deneyin. root’a ait ve modu 600 olan bir dosya yalnızca süreç hâlâ root iken çalışır; birçok profilin yaptığı yetki düşürmesinden sonra bu doğru değildir. İki komut geçişi ve açmayı kapsar:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableİlk komut her bileşenin modunu yazdırır ve hesabın geçemediği yerde başarısız olur; ikincisi tek önemli soruyu yanıtlar: çalışma zamanı kimliği dosyayı okumak için açabilir mi. İkisi de dosya içeriğini yazdırmaz ve dosya bir parola tuttuğunda asıl mesele budur. Oturum açma dosyası için testi yineleyin, çünkü ikisi sıklıkla farklı sahiplikle saklanır.
Süreç chroot veya kısıtlı bir namespace kullanıyorsa aynı testi o görünümün içinden çalıştırın, yoksa yanıt yanlış dosya sistemini tanımlar. Gizli bir ev dizini altında saklanan parola, unit dışında geçip içinde başarısız olan testin olağan örneğidir.
İlk başlatmayı, ardından yeniden bağlanmayı denetleyin
Örneği bir kez başlatın ve sonuncuyu değil ilk hatayı okuyun. Eksik girdi dosyası, başarısız anahtar şifre çözme ve sunucudan gelen AUTH_FAILED üç ayrı olay ve üç ayrı onarımdır. Bir izin uyarısını düzeltmek anahtarın açılıp açılmadığı hakkında hiçbir şey kanıtlamaz.
Journal satırı üç durumdan hangisinde olduğunuzu söyler. Onarım hangi girdinin başarısız olduğuna göre belirlenir:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Sonra gerçekten ihtiyaç duyduğunuz yaşam döngüsünü test edin: önyüklemede başlatma ve desteklenen her yeniden bağlanma, yalnızca kabuğunuzdan elle başlatma değil. auth-nocache ile girdiler ilk kullanımdan sonra atılır, bu yüzden sonraki yeniden bağlanma hâlâ okunabilir bir kaynağa ihtiyaç duyar. Masaüstü oturum açmasında açılan anahtarlık, herhangi biri oturum açmadan önce başlamış bir hizmet için kullanılamaz ve elle yapılan testin geçip yeniden başlatmanın başarısız olmasının olağan nedeni budur. İlk başlatma başarılı olup sonraki yeniden bağlanma başarısız olursa, izinleri yeniden değiştirmeden önce yeniden bağlanma olayı için journal’ı okuyun.
Parolayı anahtarın yanında saklamak şifrelemenin size kazandırdığını azaltır, bu yüzden o dosyayı ve yedeklerini kısıtlayın. Anahtarın parolasını kaldırmayı eksik girdinin onarımı değil, ayrı bir kimlik bilgisi kararı olarak ele alın. İnsan onayına veya etkileşimli MFA’ya bağlı bir dağıtım, desteklenen aracısına veya yönetim entegrasyonuna ihtiyaç duyar; kalıcı olarak saklanan tek kullanımlık kod eşdeğer bir yedek değildir.