OpenVPN xəta göstərmədən başlamır? Jurnala baxın

Əmr qayıdır, xidmət uğursuz görünür və terminala heç bir izah bənzəri çatmır. Bu sükut insanların «OpenVPN başlamır» dediyi simptomdur və demək olar ki, heç vaxt proqramın heç nə demədən öldüyü anlamına gəlmir. Bu, mesajın oxumadığınız bir kanala getdiyini və ya başlatdığınız şeyin konfiqurasiya etdiyiniz şey olmadığını bildirir. Profili şübhəli hesab etməyi dayandırdıqdan sonra hər iki hal bir dəqiqədən az müddətdə diaqnoz edilə bilər.

Çıxışı dörd yer udur: unit-in jurnalı, bağlantıya sahib olan plagin, tunelin digər ucu və işlədiyini düşündüyünüzdən fərqli bir binar. Hər birinin öz yoxlaması var.

Sükut doğru kanala baxmadığınız deməkdir

Ön planda çağırış terminalınıza çap edir. Unit jurnala çap edir və uğursuz unit heç nə yazmadan çıxa bilər, əgər nasazlıq onun necə başladılmasındadırsa, ona nə deyildiyində deyilsə. Bu fərq vacibdir: jurnalda heç bir qeyd yoxdursa, proses heç vaxt həqiqətən işləməyib; bir qeydi çıxış izləyirsə, deməli işləyib və nəyisə rədd edib.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Əlavə edin systemctl show -p Result -p ExecMainStatus openvpn-client@office təmiz çıxışı siqnaldan ayırmaq üçün. 1 statusu və Result=exit-code proqram qərarıdır; Result=signal və ya taym-aut əksinə mühitə işarə edir və profil redaktəsinin heç bir miqdarı bunları dəyişməyəcək. Hər şeyi yenidən başlatmadan əvvəl hər iki dəyəri qeyd edin, çünki yenidən başlatma onları yaradan keçici vəziyyəti silir.

İnstansiya adı yolun bir hissəsidir

Paketlənmiş şablon unit fayl yolu qəbul etmir. O, instansiya adı qəbul edir və həmin ad profili tapmaq üçün bir kataloqa əlavə olunur: office kimi həll olunur /etc/openvpn/client/office.conf Debian və Ubuntu paketlərində. office-v2.conf faylı @office kimi başladılanda heç vaxt oxunmur və unit səssizcə çıxır, çünki onun nöqteyi-nəzərindən görüləcək heç nə yox idi. Axtarış kataloqu müştəri və server rejimləri arasında fərqlənir, buna görə eyni səhv şablonları dəyişəndə tamamilə başqa yerə işarə edir.

Bu uyğunsuzluq səssiz nasazlığın ən çox yayılmış mənbəyidir və profildə görünmür, çünki profil qaydasındadır. Həqiqətən mövcud olanı sadalayın və iki adı hərf-hərf müqayisə edin, paketin gözlədiyi hər hansı uzantı da daxil olmaqla.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Əgər unit aktivdirsə, lakin heç bir instansiya siyahıda yoxdursa, aktivləşdirmənin özü sonradan adı dəyişdirilmiş bir ada istinad edə bilər. Düzgün instansiyanı yenidən aktivləşdirmək adətən kifayətdir və geridə qalan köhnə unit faylını silməyə dəyər ki, növbəti adamı çaşdırmasın. Qalmış unit faylı kiçik bir şeydir, amma sonradan kiməsə bir saata başa gəlir.

Plagin tunelə sahib olduqda, terminal heç nə görmür

Masaüstü appletindən başladılan bağlantıya NetworkManager sahibdir və onun OpenVPN çıxışı açıq saxladığınız hər hansı shell-ə deyil, həmin xidmətin jurnalına gedir. Müştərini əl ilə işlətmək və heç nə görməmək bu quruluşda gözləniləndir, çünki əl ilə işlədilən proses bağlantını daşıyan proses deyil.

Onu sahib olan xidməti jurnalda axtarın, sonra təhlili oxuya biləcəyiniz ətraflılıqla təkrar edin. Aşağıdakı iki əmr eyni nasazlığın fərqli sahiblərinə baxır.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

Ayrı işlətmə mesajları oxumaq üçündür, idarə olunan bağlantını əvəz etmək üçün deyil və ikisi sonradan fərqlənir: DNS inteqrasiyası, marşrutlar və ömür plaginiə aiddir. Ayrı işlətmədə təhlil səhvini düzəltmək, applet nəzarəti götürdükdən sonra ad həllini avtomatik düzəltmir, ona görə iki müşahidəni ayrı saxlayın.

İki binar, bir PATH

Əl ilə qurulub /usr/local altına quraşdırılan versiya shell çağırışında üstün gəlir, çünki /usr/local/sbin -dən əvvəl gəlir /usr/sbin default Ubuntu PATH-də. Unit sizin PATH-inizdən istifadə etmir; o, mütləq yolu bu parametrdə işlədir: ExecStart. Beləliklə, terminalınızda işləyən versiya və xidmət kimi uğursuz olan versiya həqiqətən fərqli proqramlar ola bilər.

Hər hansı bir şeyi yenidən qurmadan əvvəl ikisini müqayisə edin. Üçüncü əmr arqumenti həll edəndir.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Daha bir mühit fərqi eyni yerdə gizlənir. Paketlənmiş unit /run altında systemd-nin onun üçün yaratdığı işləmə kataloquna güvənir; həmin parametri buraxan əl ilə yazılmış əvəzedici unit tək bir fayl açmadan uğursuz ola bilər və nasazlıq OpenVPN mesajı olmayan ümumi bir imtina kimi görünür.

Müştərinin bildirə bilmədiyi nasazlıqlar

Bəzi nəticələr uzaq tərəfdə həll olunur. HTTP statusu ilə cavab verib bağlantını bağlayan şlüz öz vəziyyətini sizə bildirmişdir və faydalı növbəti addım yerli fayllarınız deyil, onun jurnalı və ya etimad məlumatının arxasındakı hesabdır. O ssenaridə yerli heç nə pozulmayıb və bunu kompensasiya etmək üçün profili redaktə etmək növbəti diaqnozu çətinləşdirir. Müştəri konfiqurasiyasına toxunmadan əvvəl həmin jurnalı oxuyun.

Daha bir səssiz hal düzgün işləyən müştəridir. Müştəri rejimli tunel heç vaxt portda dinləmir, buna görə açıq dinləyici gözləyən yoxlama heç nə bildirməyəcək və nasazlıq kimi görünəcək. Boş port siyahısından nəticə çıxarmadan əvvəl hansı rejimi başlatdığınızı təsdiqləyin.

Qatları sıra ilə işləyin: unit mövcuddurmu və instansiya adı düzdürmü, jurnala və ya --log faylına hər hansı şey çatdı, hansı binar və profil həqiqətən işlədi və nasazlıq yerli, yoxsa uzaqdır. Hər cavab bir qatı çıxarır. Profildən başlamaq, bəlkə də heç vaxt açılmamış faylı yenidən yazmaq deməkdir.