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.auth

Bağı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] -b

ProtectHome 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 showsWhich input failedWhere to look
A path that cannot be openedThe file the profile namesAskpass or login path, and the unit's working directory
A key decryption errorThe key passphraseFirst line of the askpass file, and read access for the runtime identity
AUTH_FAILED from the serverThe account credentialsLogin 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.

İlgili makaleler