OpenVPN xidməti “Şəxsi açar parolu” sorğusunda dayanır: düzəltmə yolu

OpenVPN şəxsi açar parolunu yerli maşında soruşur, ona görə işlək giriş faylı ona heç vaxt cavab vermir. Xidmətdə yazmaq üçün terminal yoxdur, başlama ya asılır, ya da səbəbi deyil, çatışmayan girişi göstərən jurnal qeydi ilə uğursuz olur. Burada iki sirr iştirak edir və hər birinin unit yenidən başladılmazdan əvvəl öz oxuna bilən mənbəyi olmalıdır. Aşağıdakı addımlar onları ayırır, sonra hər faylı həqiqətən açan kimliyi yoxlayır.

İki sorğunu fərqləndirin

Açar parolu yerli şəxsi açarı deşifrə edir; hesab məlumatları sessiyanı serverə doğrulaşdırır. Onlar müxtəlif yerlərdən gəlir, müxtəlif anlarda uğursuz olur və müxtəlif mesajlar verir. Onları qarışdırmaq insanı parol sıfırlaması axtarmağa yönəldir, halbuki hesab heç iştirak etməmişdi. Hər hansı seçimi dəyişməzdən əvvəl sorğu mətnini oxuyun, çünki hansı sirrin çatışmadığına dair yeganə etibarlı işarə mətnin özüdür.

Community OpenVPN 2.x-də askpass açar parolunu birinci sətrində saxlayan faylı göstərir, auth-user-pass isə bir sətirdə istifadəçi adı, növbəti sətirdə parol olan faylı göstərir. Heç bir fayl digər seçimi ödəyə bilməz. Masaüstü tətbiq və ya NetworkManager profili hər ikisini öz sirr anbarında saxlaya bilər, komanda sətri müştərisi isə onu heç vaxt oxumur, ona görə hər hansı yolu yazmazdan əvvəl hansı müştərini konfiqurasiya etdiyinizi qeyd edin.

Hər iki seçimi oxuna bilən fayllara yönəldin

Hər iki girişi tələb edən profil sonda üç fayl istinadı ilə qalır: şifrələnmiş açar, onu açan parol və giriş cütü. Onları CA-ya və kimlik yoxlamalarına toxunmadan əlavə edin, çünki onlar serverin kim olduğunu müəyyən edir və bu problemin hissəsi deyil. Əgər yerləşdirmə hesab məlumatlarından heç istifadə etmirsə, auth-user-pass əlavə etmək heç kimin verə bilməyəcəyi bir giriş yaradır.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Arqumentsiz seçimlər yollu seçimlərdən fərqli davranır və bu fərq xidmətdə vacibdir. Arqumentsiz askpass hələ də konsolu oxuyur, yalnız istifadəçi adı olan auth-user-pass faylı isə hələ də parol sorğusunu gözlədik qoyur. Müştəri demonlaşdıqdan sonra terminaldan heç bir giriş istəyə bilmir, ona görə bu şəkildə qurulmuş xidmət qalxmır.

Mütləq yollar işçi qovluğu sualını aradan qaldırır, amma giriş hüququ vermir. Sahiblik, rejim və keçid ardınca gəlir və üçü də prosesin işlədiyi hesaba görə yoxlanılır.

Profildən əvvəl unit-in konfiqurasiyasını oxuyun

İnstansiyanın hansı konfiqurasiyanı yüklədiyini redaktə etdiyiniz fayl deyil, unit müəyyən edir. Onun komanda sətrini və bütün drop-in-lərini oxuyun, sonra işçi qovluğundan həqiqətən istifadə olunan profilə qədər izləyin. Başqa .ovpn faylına əlavə edilən parol istinadı bu instansiya üçün heç nəyi dəyişmir.

Üç yalnız-oxuma əmri bunun çoxuna cavab verir. Birincisi unit-i və bütün drop-in-ləri, ikincisi prosesi məhdudlaşdıran kimliyi və sandbox ayarlarını, üçüncüsü isə son başlamanın əslində nədən şikayət etdiyini çap edir. Hostda mövcud olan instansiya adını istifadə edin:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

ProtectHome-a və profilin öz user, group və chroot seçimlərinə diqqət yetirin. Ev qovluğu altındakı fayl sizin shell-inizdə oxuna bilər və ev qovluqları gizlədildikdən sonra xidmətin içində görünməz olur. systemd-nin başladığı hesab həmişə açarı sonda açan hesab deyil.

İşləmə kimliyinin hər iki faylı aça bildiyini sübut edin

Rejimi oxumaq kifayət deyil, çünki yoldakı hər qovluq eyni kimlik tərəfindən keçilə bilməlidir. Yolu komponent-komponent addımlayın, sonra prosesin istifadə etdiyi hesabla açmanı sınayın. Sahibi root olan və rejimi 600 olan fayl yalnız proses hələ root ikən işləyir, bir çox profilin etdiyi imtiyaz endirilməsindən sonra isə bu doğru deyil. İki əmr keçidi və açmanı əhatə edir:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

Birinci əmr hər komponentin rejimini çap edir və hesabın keçə bilmədiyi yerdə uğursuz olur; ikincisi yeganə vacib suala cavab verir: işləmə kimliyi faylı oxumaq üçün aça bilirmi. Heç biri fayl məzmununu çap etmir və fayl parol saxladıqda əsas məqam da budur. Giriş faylı üçün testi təkrarlayın, çünki ikisi çox vaxt fərqli sahibliklə saxlanılır.

Proses chroot və ya məhdud namespace istifadə edirsə, eyni testi həmin görünüşün içindən keçirin, əks halda cavab səhv fayl sistemini təsvir edir. Gizli ev qovluğu altında saxlanan parol, unit xaricində keçib içində uğursuz olan testin adi nümunəsidir.

Əvvəlcə ilk başlamanı, sonra yenidən qoşulmanı yoxlayın

İnstansiyanı bir dəfə başladın və sonuncu deyil, ilk uğursuzluğu oxuyun. Çatışmayan giriş faylı, uğursuz açar deşifrəsi və server tərəfindən AUTH_FAILED üç fərqli hadisə və üç fərqli düzəlişdir. İcazə xəbərdarlığını düzəltmək açarın açıldığını sübut etmir.

Jurnal sətri hansının olduğunu deyir. Düzəliş hansı girişin uğursuz olduğundan irəli gəlir:

Sonra həqiqətən ehtiyacınız olan həyat dövrünü sınayın: yükləmə zamanı başlama və dəstəklənən istənilən yenidən qoşulma, yalnız shell-dən əl ilə başlatma deyil. auth-nocache ilə girişlər ilk istifadədən sonra atılır, ona görə sonrakı yenidən qoşulma yenə oxuna bilən mənbə tələb edir. Masaüstü girişində açılan açar halqası, hər kəs daxil olmadan əvvəl başlamış xidmət üçün mövcud deyil və əl testinin keçib yenidən yükləmənin uğursuz olmasının adi səbəbi budur. İlk başlama uğurlu olub sonrakı yenidən qoşulma uğursuz olursa, icazələri yenidən dəyişməzdən əvvəl yenidən qoşulma hadisəsi üçün jurnalı oxuyun.

Parolu açarın yanında saxlamaq şifrələmənin sizə verdiyini azaldır, ona görə həmin faylı və onun ehtiyat nüsxələrini məhdudlaşdırın. Açar parolunun silinməsini çatışmayan girişin düzəlişi deyil, ayrı bir etimad qərarı kimi qəbul edin. İnsan təsdiqindən və ya interaktiv MFA-dan asılı olan yerləşdirmə öz dəstəklənən agentini və ya idarəetmə inteqrasiyasını tələb edir; daimi saxlanan birdəfəlik kod ekvivalent əvəz deyil.