OpenVPN client-connect xətası: disconnect təmizliyi zəmanətlidirmi?
Rədd edilən müştəri firewall qaydasını və ya yazılmış qeydi geri qaytarmır. Callback müqaviləsini hook-un özünün yerinə yetirməli olduğu rollback ilə müqayisə edin.
Sıfırdan fərqli çıxış edən client-connect skripti OpenVPN-in müştərini rədd etməsinə səbəb olur və operatorlar adətən uyğun client-disconnect skriptinin hər şeyi təmizlədiyini güman edirlər. Çox vaxt o, heç işə düşmür, çünki disconnect emalı connect mərhələsinin nəyi tamamlaya bildiyindən asılıdır. Rəddi və rollback-i bir mexanizm kimi qəbul etmək uğursuz girişi sızmış firewall qaydasına və ya sahibsiz qeydə çevirən şeydir. Bunlar iki ayrı öhdəlikdir və yalnız biri avtomatikdir. Serveri arxada vəziyyət qoymaqda günahlandırmazdan əvvəl hook-un öz çıxış yolunu oxuyun.
Sıfırdan fərqli çıxış müştərini rədd edir; işinizi geri qaytarmır
client-connect-in çıxış statusu qəbul qərarıdır. Sıfır qəbul deməkdir, başqa hər şey instansiyanın tam qurulmadan əvvəl sökülməsi deməkdir. Bu müqavilədə heç nə skriptin xarici dünyada artıq nə etdiyini yoxlamır. Əgər skript iptables qaydası əlavə edib, sətir yazıb və ya sayğac artırıbsa, bu dəyişikliklər rədddən sonra da qalır.
Eyni asimmetriya plaginlərə də aiddir, çünki bir instansiya üçün bir neçə connect funksiyası işləyə bilər. Sonrakı uğursuzluq əvvəlki uğuru geriyə dönük ləğv etmir və əvvəlki funksiyanın qardaş funksiyanın uğursuz olduğunu öyrənmək imkanı yoxdur.
Rədd avtomatikdir, təmizlik deyil
OpenVPN 2.6 təlimatı client-disconnect emalını əvvəlki connect emalının uğurla tamamlanmasına bağlayır. Sənədləşdirilmiş bir istisna kaskad zəncirləri əhatə edir: əgər bir connect addımı artıq uğur qaytarıbsa, instansiya sökülərkən uyğun disconnect addımları yenə də işləyir, hətta sonrakı connect addımı uğursuz olsa belə. Bu istisna dardır və neçə callback-in qurulduğundan asılıdır, buna görə bir shell skriptini sınaqdan keçirmək zəncir haqqında sizə heç nə demir.
Dizayn etməzdən əvvəl real konfiqurasiyanı xəritələndirin: hansı skript, hansı plagin və hansı sıra ilə işləyirlər. Aşağıdakı cədvəl yarımçıq qalmış quruluşun arxada nə buraxdığını göstərir.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
Hər sətir müştəri üçün eyni, host üçün fərqli şəkildə bitir. Müştəri hansının baş verdiyini deyə bilməz, ona görə hook uğursuzluq statusunu qaytarmazdan əvvəl etdiklərini geri qaytarmalıdır.
Uğursuz olan skriptin içində kompensasiya edin
Ortaq vəziyyətə toxunmazdan əvvəl hər şeyi yoxlayın: sertifikat sahələrini, ünvanın mövcudluğunu, müştərinin aid olduğu qrupu. Ən ucuz rədd heç bir ayrıma olmadan baş verən rədddir. Quraşdırma bir neçə xarici əməliyyatı əhatə etdikdə, hansılarının tamamlandığını qeyd edin və uğursuzluq statusunu qaytarmazdan əvvəl onları tərs qaydada geri qaytarın.
Konkret hal: skript hər müştəri üçün firewall girişi yaradır, sonra onu təsvir edən vəziyyət sətrini yazmaqda uğursuz olur. Uğursuz budaq yenicə yaratdığı girişi silməli və sonra sıfırdan fərqli çıxış etməlidir. Heç vaxt planlaşdırılmaya biləcək disconnect hadisəsini gözləmək qaydanın nəzərdə tutulduğu sessiyadan daha uzun yaşamasının yoludur.
Kompensasiyanı idempotent və sahibli edin
Təmizlik iki dəfə işə salına bilməli və nəyi silə biləcəyi barədə dəqiq olmalıdır. Əvvəlki cəhdin gec hadisəsi yalnız ortaq adı və ya təkrar istifadə edilmiş tunel ünvanını paylaşdıqları üçün daha yeni sessiyanın ayrımasını silməməlidir. Xüsusi tutacağı və ya əməliyyat identifikatorunu resursla birlikdə qeyd edin və adla deyil, həmin açarla silin. Verilənlər bazası tranzaksiyaları yalnız verilənlər bazasının öz dəyişikliklərində kömək edir; bu sərhəddən kənarda olan firewall qaydası açıq kompensasiya addımı tələb edir.
Prosesin dəyişikliklə təmizlik arasında ölə biləcəyini fərz edin və xarici vəziyyəti qəbul edilmiş müştəri siyahısı ilə cədvəl üzrə müqayisə edən bir barışdırıcı əlavə edin.
Həqiqətən fərqlənən üç yolu sınaqdan keçirin
Üç halı məşq edin: heç nə ayrılmadan əvvəl rədd, qismən ayrımdan sonra rədd və sonradan bitən normal qəbul edilmiş sessiya. Bu üçlük fərqli log sətirləri və fərqli qalıqlar yaradır. Hər birindən sonra xarici vəziyyəti yoxlayın, yalnız müştərinin uğursuzluq mesajını deyil, çünki müştərinin uğursuzluğu üç halın ikisində gözlənilən nəticədir.
Hook mərhələsini, çıxış statusunu və nəyin ayrıldığını və ya buraxıldığını, etimad məlumatlarını çıxarmaqla qeyd edin. Yaradılan resursun adını çəkən hook jurnalı sızmış qaydanı altı ay sonra tapıla bilən edən şeydir.