Niyə OpenVPN müştəriniz bir vaxt aşımından sonra dayanır

Bazar ertəsi səhəri: cümə günü qalxan tunel getdi, interfeys hələ də siyahıda görünür və jurnalda heç kimin bunu fərq etdiyi yazılmır. Host onlayndır, panel yaşıldır və həftəsonu göndərdiyi hər şey bunun əvəzinə fiziki interfeysdən çıxıb. Burada iki müstəqil qərar çatışmır: biri müştəri prosesinin keçici nasazlıqdan sağ çıxıb-çıxmaması, digəri onun üstündəki nəyinsə prosesi çıxdıqdan sonra yenidən başladıb-başlatmaması barədədir. Yalnız birini düzəltmək digər boşluğu açıq qoyur.

Bölmənin həqiqətən nə etdiyindən başlayın, monitorinqin nə iddia etdiyindən deyil. systemctl status openvpn-client@office və journalctl -u openvpn-client@office -n 50 çıxış səbəbini və müştərinin getməzdən əvvəl yazdığı son sətri göstərir.

Proses heç kim fərq etməzdən əvvəl çıxdı

Xətasız yoxa çıxan müştəri adətən qəsdən çıxır. Bu davranışı xidmət meneceri deyil, profil müəyyən edir: ping-exit qarşı tərəf cavab verməyi dayandıran kimi prosesi bitirir, ping-restart isə prosesi saxlayır və onun içində yenidən qoşulur. Sessiya məhdudiyyətləri və fəaliyyətsizlik taymerləri kənardan eyni mənzərəni yaradır: nə tunel, nə də həyəcan.

İki ping direktivi bir profildə eyni vaxtda ola bilməz, ona görə birini seçin və seçimi qeyd edin. Serverə də baxın, çünki onun öz ping-exit müştərinin nə istəməsindən asılı olmayaraq sessiyanı bağlayır və bu qərarı kimin verdiyini yalnız server jurnalı yazır.

ping-exit və ping-restart arasında seçim

Özünü sağaltmalı olan noutbuk və ya uzaq sahə üçün ping-restart seçin, ölü tunelin prosesi dayandırması və başqa bir şeyin ona reaksiya verməsi lazım olan hallar üçün isə ping-exit saxlayın. Rəqəmlər əlaqədən daha az önəmlidir: ping 10 və ping-restart 60 birlikdə yoxlamadan əvvəl on saniyə, yenidən başlatmadan əvvəl altmış saniyə sükut deməkdir ki, bu itkili mobil kanalda aqressiv, kabeldə isə məqbuldur. Səbəbi sətrin yanında yazın, əks halda növbəti oxucu standart dəyərlərin qəsdən seçildiyini düşünəcək.

Sonra həqiqətən prosesin çıxdığını təsdiqləyin. Tunel ölü ikən aktiv olduğunu bildirən bölmə fərqli bir nasazlıqdır və aşağıda ayrıca baxılır.

Bölməni həqiqətən yenidən başladan nəzarət

systemd hostunda ən kiçik davamlı dəyişiklik bir drop-in faylıdır: Restart=on-failure və RestartSec=10 parametrləri /etc/systemd/system/[email protected]/restart.conf faylında. Drop-in yalnız systemd öz təriflərini yenidən yükləyəndə oxunur, ona görə sonra systemctl daemon-reload işə salın. Dəyərin yerinə çatdığını fərz etmək əvəzinə systemctl show -p Restart -p ExecMainStatus openvpn-client@office ilə yoxlayın. Fayl adındakı instans bölmənin həqiqətən yüklədiyi profil olmalıdır, yəni office üçün yazılmış fayl openvpn-client@home üçün heç nə etmir.

on-failure bir halı görməz: statusu sıfır olan təmiz çıxış. Bəzi sökülmə yolları belə bitir, ona görə təlimat səhifəsinin ifadəsinə güvənmək əvəzinə qeydə alınan statusu oxuyun. Müştəriniz sıfırla əl çəkirsə, sizə Restart=always lazımdır və bunun qiyməti odur ki, həqiqətən sınıq profil başlama dərəcəsi həddi işə düşənə və jurnal dolana qədər yenidən qayıdır.

Restart=always qəsdən dayandırmadan sonra da işə düşür. Texniki xidmət üçün systemctl stop istifadə edin və işləyərkən bölmə aşağı qalmalıdırsa, onu maskalayın.

Tunel aşağıda ikən sızmanı tutun

Nəzarət tunelin qayıtmasını təmin edir; tunel yox ikən trafikin çıxmasının qarşısını almır. persist-tun cihazı və marşrutlarını yenidən qoşulmalar arasında saxlayır, bu rahatdır və bir pəncərə açır. Cihaz qalır, marşrutlar hələ də ona yönəlir və paketlər qorunmadan və bildirilmədən axıb gedir. Bu siyasət seçimidir, neytral standart deyil.

Host ümumiyyətlə qorunmamış paket buraxa bilmirsə, bunu yalnız firewall təmin edə bilər. Tunel interfeysinə və VPN serverinin ünvanına icazə verib qalan hər şeyi atan çıxış qaydası müştəri öləndən sonra da qüvvədə qalır və müştərinin öz konfiqurasiyasında müştərinin daşımadığı trafiki süzə bilən heç nə yoxdur.

Müştəri qəsdən dayandıraraq bunu yoxlayın. systemctl stop openvpn-client@office, sonra curl -m 5 https://example.com işə salın; bu, fiziki kanal üzərindən uğur qazanmaq əvəzinə uğursuz olmalıdır. Uğurlu nəticə firewall qaydasının çatışmadığını və ya həddindən artıq icazəli olduğunu bildirir.

Yenidən qoşulun, tunelin yenidən trafik daşıdığını təsdiqləyin və yoxlamanı monitorinqə yalnız bundan sonra əlavə edin. Cron vasitəsilə ip addr ilə tun cihazının yoxlanması ən çox uğursuz olan nəzarətdir, çünki persist-tun ilə cihaz sessiyadan uzun yaşayır və yoxlama hər hansı trafik daşınmadığı halda sağlamlıq bildirir.