Hansı OpenVPN nüsxəsi əslində PiVPN profilini istifadə edir?

PiVPN server konfiqurasiyası və müştəri profili yazır, sonra çıxır; o, heç vaxt trafikinizi daşıyan prosesə çevrilmir. Buna görə uğursuz əl sıxışması, səhv son nöqtəyə qoşulan müştəri və ya yenidən başlatmadan sonra səhv qayıdan xidmət quraşdırıcının menyularından izah edilə bilməz. Bu simptomlar hazırda işləyən OpenVPN demonuna, həmin demonun həqiqətən yüklədiyi konfiqurasiyaya və ona yönəldilmiş jurnala aiddir. Dörd yalnız-oxuma əmri bunu adətən həll edir və heç biri sertifikatlarınızı və ya açarlarınızı dəyişmir.

Köməkçi və demon fərqli obyektlərdir

Qarışıqlığı izah etmək asandır: bir qovluq həm köməkçinin yaratdığı faylı, həm demonun oxuduğu faylı, həm də bəzən hər ikisinin köhnə surətini saxlayır. Köməkçi təminat skriptidir. Paketləri quraşdırır, unit faylları yazır və müştəri profili çap edir, sonra işi bitir. Qalan şey xidmət menecerindəki qeyd və əmr sətridir.

systemd hostunda qovluq siyahısından deyil, aktiv unitdən başlayın. Ad qablaşdırmadan asılıdır: Debian və Raspberry Pi OS obrazları adətən openvpn-server@server kimi şablon nüsxəsi təqdim edir, köhnə quraşdırmalar isə openvpn@server istifadə edir. Fayl adından təxmin etmək əvəzinə menecerdən hansının işlədiyini soruşun.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Baxın ExecStart= sətrinə o çıxışda. O, icra edilən faylı və menecerin həqiqətən başlatdığı seçimləri, o cümlədən hər hansı --config yoluna; yaxınlıqda duran və heç bir əmrin istinad etmədiyi konfiqurasiya faylı işləyən tunelin hissəsi deyil.

Demonun həll etdiyi konfiqurasiya zəncirini izləyin

OpenVPN parametrlər üçün qovluğu skan etmir. O, --config ilə ötürülən faylı oxuyur, hər hansı config direktivini izləyir və sonra əmr sətri seçimlərini tətbiq edir. 2.6 təlimatı həmin sıranı izah edir və iki fayl port, cihaz və ya şifrə barədə fərqli danışdıqda bu vacib olur.

Əvvəlcə faktiki çağırışı çıxarın, sonra kimliyi və əlçatanlığı təyin edən direktivlərə baxın. Hər iki əmr yalnız-oxumadır və canlı serverdə təhlükəsizdir, baxmayaraq ki, ikincisi açıq biletdə istəməyəcəyiniz yolları çap edir.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Ev qovluğundakı .ovpn faylı müştəri artefaktıdır. Server demonu onu heç vaxt oxumur, ona görə də server tərəfində əl sıxışması nasazlığını düzəltmək üçün həmin faylı redaktə etmək heç nəyə nail olmur.

Daxiletmələr digər tələdir. config sətri ikinci bir faylı cəlb edir və onun seçimləri həmin nöqtədə emal olunur, buna görə sonrakı tək dəyərli direktiv əsas faylın dediyi görünən şeyi üstələyə bilər. Görünən fayl düzgün görünürsə və demon yenə də başqa cür davranırsa, heç nəyi dəyişməzdən əvvəl daxil edilmiş faylı oxuyun.

Jurnalı prosesə uyğunlaşdırın, yadda saxladığınız xətaya deyil

İki jurnal təyinatı geniş yayılmışdır və yalnız biri jurnaldır. log-append quraşdırılanda demon həmin fayla yazır və jurnal başlanğıc sətirlərindən başqa az şey saxlayır. O olmadan, journalctl hadisə mənbəyidir.

journalctl -u openvpn-server@server -n 80 --no-pager

Bir qoşulma cəhdini bir zaman pəncərəsi ilə əlaqələndirin. Müştərinin son nöqtəsini qeyd edin, sonra eyni saniyələrdən server hadisələrini oxuyun. Sertifikat mübadiləsinə heç vaxt çatmayan TLS əl sıxışması əlçatanlığa və ya protokol uyğunsuzluğuna işarə edir, autentifikasiya imtinası isə tunel parametrləri artıq razılaşdırıldıqdan sonra gəlir.

Köhnə jurnal qeydi beş dəqiqə əvvəl endirdiyiniz profil haqqında heç nə sübut etmir. Müştəri faylını yenidən yaradın, bir dəfə qoşulun və yalnız həmin cəhd zamanı görünən sətirləri oxuyun.

Son ümumi xəta yerinə ilk konkret nasazlığı qeyd edin. Bağlama xətası, cavabsız xarici mübadilə, sertifikat imtinası və hesab imtinası hər biri sizi fərqli qata yönəldir və sondakı gözləmə vaxtı çox vaxt yuxarıdakı faydalı hadisəni gizlədir.

Tuneli yenidən qurmaq diaqnostik addım deyil

Cəlbedici qısa yol ikinci, daha sadə tunel qurmaqdır: statik açar, sertifikat yoxdur, əlavə autentifikasiya yoxdur. Çox vaxt qoşulacaq və yalnız iki hostun aralarında UDP və ya TCP ötürə bildiyini sübut edəcək. Sertifikatla təsdiqlənən yerləşdirmənin niyə uğursuz olduğu barədə heç nə demir və saxlamanız istənilən təhlükəsizlik modelini sakitcə əvəz edir.

Eyni şey tls-auth və ya tls-crypt seçimini söndürməyə, verify-x509-name yoxlamasını yumşaltmağa və ya yaşıl status üçün ikinci faktoru atmağa da aiddir. Doğrulama çıxarıldığı üçün qoşulan tunel fərqli bir sistemdir, təmir edilmiş sistem deyil.

Jurnalın göstərdiyi qatda bir məhdud dəyişiklik edin, eyni uniti yenidən başladın və tək qoşulma cəhdini təkrarlayın. Bu, müqayisəni dürüst saxlayır və geri qaytara bildiyiniz bir dəyişiklik buraxır.

Növbəti şəxsə nə verməli

Dörd faktı hələ əlinizdəykən yazın: openvpn --version çıxışındakı OpenVPN versiyası, aktiv olan unit, daxiletmələri ilə konfiqurasiya zənciri və bir cəhdi əhatə edən jurnal pəncərəsi. Bu dördü qeyri-müəyyən şikayəti təkrarlana bilən işə çevirir.

Paylaşmadan əvvəl redaktə edin. Şəxsi açarlar, auth-user-pass faylları, statik açar materialı və tam müştəri paketləri biletə aid deyil; seçim adları və zəncirin forması adətən ikinci cüt göz üçün kifayətdir.

Zəncir bütövdürsə və jurnal hələ də şəbəkəyə işarə edirsə, növbəti addım müştəri ilə server arasındakı yoldur başqa quraşdırma deyil. Bu, hekayənin köməkçinin heç vaxt sahib olmadığı hissəsidir.