Kill switch testi: yalnız yenidən qoşulmanı deyil, boşluğu ölçün

Bir saniyədə bitən yenidən qoşulma klientin sürətli olduğunu deyir. Tünel söndüyü müddətdə nəyinsə çıxıb-çıxmadığını demir. Bir dəqiqə çəkən yenidən qoşulma klientin yavaş olduğunu deyir və yenə də boşluqda birbaşa trafikə icazə verilib-verilmədiyini demir. Bunlar iki ölçmədir və yalnız birincisini bildirən kill switch testi açarı sınamamışdır.

İki müşahidə, iki ayrı hökm

Əlçatanlıq sualı sadədir: tünel nə vaxt yenidən işlək oldu və qorunan tətbiq ora çatmaq üçün yeni bağlantıya ehtiyac duydu. İcra sualı isə fərqlidir: qoruma düşdüyü andan geri qayıtdığı ana qədər hansı paketlər maşından çıxdı.

Onlara ayrı qeydlərlə cavab verin. Bir sətir boşluğun müəyyən sayda saniyə davam etdiyini deyir. Başqa bir sətir həmin boşluqda qorunmayan sorğunun uğur qazanıb-qazanmadığını deyir. Onları tək bir keçdi və ya kəsildi nəticəsinə birləşdirmək ən vacib halı, yəni sızma ilə birlikdə sürətli yenidən qoşulmanı gizlədir.

Vaxtını ölçə biləcəyiniz bir zond qurun

Elə bir sorğu seçin ki zərərsiz, ucuz və tünelin öz idarə kanalından asılı olmasın. Aşağıdakı dövr saniyədə bir dəfə vaxt damğası, HTTP statusu və keçən vaxtı çap edir və asılı qalmaq əvəzinə uca səslə uğursuz olur:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

Yalnız statusu deyil, curl çıxış kodlarını oxuyun. 28 sorğunun vaxtının bitdiyini bildirir, bloklanmış yol belə görünür. 6 ad həllinin uğursuz olduğunu bildirir, bu fərqli tapıntıdır və çox vaxt daha maraqlısıdır. Boşluq zamanı kiçik keçən vaxtla gələn 200 trafikə çölə çıxmağa icazə verildiyini bildirir.

Çıxışı fayla yazın və saxlayın. Terminalın geri sürüşdürülməsi sübut deyil və maraqlı hissə adətən ortadakı üç sətirdir.

Səliqəli deyil, real nasazlıq yaradın

Klientin öz menyusundan ayırmaq kooperativ yolu sınayır: klientin bloklama qaydalarını quraşdırmağa vaxtı olur. Əvəzində prosesi öldürün və ya alt qatdakı linki qoparın, o zaman real nasazlığın getdiyi yolu sınayırsınız.

Hər tetikleyici fərqli kod yolunu işlədir. Server tərəfində kəsinti, lokal link itkisi və klient qəzası hər biri fərqli vəziyyət qoya bilər və onlardan biri ehtimal ki, sonda rastlaşacağınız haldır. Zondu ən azı iki tetikleyici üzərində işlədin və nəticələri tetikleyiciyə görə etiketləyin.

Giriş jurnalını icazəli trafikin forması baxımından oxuyun

Boşluq zamanı 200 və ya sürətli bağlantı uğursuzluğu sızmadır, hansı istiqamətə baxsa da. Boşluq boyu vaxt bitmələri bloklama siyasətinin gözlənilən formasıdır. Bağlantılar uğursuz olarkən ad həllinin uğur qazanması həlledicinin hələ də əlçatan olduğunu göstərir, bu başqa növ sızma.

Mövcud soketlər diqqət tələb edir. Proqram ayırmadan əvvəl açdığı bağlantını işlətməyə davam edə bilər, ona görə canlı görünən trafik yeni yolun icazəli olduğunu sübut etməyə bilər. Soket siyahısı bağlantının hadisədən əvvəl olub-olmadığını göstərir:

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

Soketin başlama vaxtını ayırmanın vaxt damğası ilə müqayisə edin. Kəsintidən daha köhnə bağlantı sızma deyil, soketin təkrar istifadəsi sübutudur və bunu uğursuzluq kimi bildirmək növbəti adamı mövcud olmayan xətanı axtarmağa göndərir.

Nəticəni yeniləmədən sonra da qalan formada qeyd edin

Tetikleyicini, saniyələrlə boşluğu, bloklanmamış hər hansı sorğunun uğur qazanıb-qazanmadığını, ad həllinin uğur qazanıb-qazanmadığını və klient ilə əməliyyat sistemi versiyalarını yazın. Bu beş fakt dəsti buraxılışlar arasında müqayisə oluna bilər, bir paraqraf mətn bunu edə bilməz.

Klient yeniləməsindən və ya profil dəyişikliyindən sonra eyni testi təkrar işlədin, çünki bloklama davranışı tətbiq detallıdır və dəyişir. Qeydin məqsədi dəyişikliyi insidentə çevrilməzdən əvvəl görməkdir, klienti bir dəfə sertifikatlaşdırmaq deyil.