Kill switch testi: boşluğu ölçün, yalnızca yeniden bağlanmayı değil

Hızlı bir yeniden bağlanma istemcinin hızlı olduğunu kanıtlar. Boşluk sırasında makineden ne çıktığını, kullandığınız tetikleyiciyle birlikte kaydedin, yoksa test yalnızca yarısını ölçmüş olur.

Bir saniyede biten yeniden bağlanma, istemcinin hızlı olduğunu söyler. Tünel kapalıyken bir şeyin kaçıp kaçmadığını söylemez. Bir dakika süren yeniden bağlanma, istemcinin yavaş olduğunu söyler ve boşlukta doğrudan trafiğe izin verilip verilmediğini yine söylemez. Bunlar iki ölçümdür ve yalnızca ilkini bildiren bir kill switch testi anahtarı test etmemiştir.

İki gözlem, iki ayrı hüküm

Kullanılabilirlik sorusu basittir: tünel ne zaman yeniden kullanılabilir oldu ve korunan uygulama oraya ulaşmak için yeni bir bağlantıya ihtiyaç duydu mu. Yaptırım sorusu farklıdır: koruma düştüğü an ile geri geldiği an arasında hangi paketler makineden çıktı.

Bunları ayrı kayıtlarla yanıtlayın. Bir satır boşluğun belirli sayıda saniye sürdüğünü söyler. Başka bir satır o boşlukta korumasız bir isteğin başarılı olup olmadığını söyler. İkisini tek bir geçti veya kaldı sonucunda birleştirmek en çok önem taşıyan durumu gizler: sızıntıyla birlikte hızlı bir yeniden bağlanma.

Zamanını ölçebileceğiniz bir sonda kurun

Şu isteği kullanın: zararsız, ucuz ve tünelin kendi denetim kanalından bağımsız. Aşağıdaki döngü saniyede bir kez zaman damgası, HTTP durumu ve geçen süreyi yazdırır ve asılı kalmak yerine yüksek sesle başarısız 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ızca durumu değil, curl çıkış kodlarını okuyun. 28 isteğin zaman aşımına uğradığını gösterir, engellenmiş bir yol böyle görünür. 6 ad çözümlemesinin başarısız olduğunu gösterir; bu başka bir bulgudur ve genellikle daha ilginçtir. Boşluk sırasında kısa geçen süreyle gelen 200, trafiğin dışarı çıkmasına izin verildiğini gösterir.

Çıktıyı bir dosyaya yazın ve saklayın. Terminal kaydırma geçmişi kanıt değildir ve ilginç kısım genellikle ortadaki üç satırdır.

Düzenli değil, gerçek bir arıza tetikleyin

İstemcinin kendi menüsünden bağlantıyı kesmek işbirlikçi yolu test eder; istemcinin engelleme kurallarını kurmaya zamanı olur. Bunun yerine süreci öldürün ya da alttaki bağlantıyı koparın; o zaman gerçek bir arızanın izlediği yolu test edersiniz.

Her tetikleyici farklı bir kod yolu çalıştırır. Sunucu tarafında bir kesinti, yerel bağlantı kaybı ve istemci çökmesi her biri farklı durum bırakabilir ve bunlardan biri sonunda karşılaşacağınız durum olma olasılığı yüksektir. Sondayı en az iki tetikleyici üzerinde çalıştırın ve sonuçları tetikleyiciye göre etiketleyin.

İzin verilen trafiğin nasıl göründüğünü kayıttan okuyun

Boşluk sırasında bir 200 veya hızlı bir bağlantı hatası, hangi yöne bakarsa baksın bir sızıntıdır. Boşluk boyunca zaman aşımları, bir engelleme politikasının beklenen biçimidir. Bağlantılar başarısız olurken ad çözümlemesinin başarılı olması, çözümleyicinin hâlâ erişilebilir olduğunu düşündürür; bu başka tür bir sızıntıdır.

Mevcut soketler dikkat gerektirir. Bir program, bağlantı kesilmeden önce açtığı bağlantıyı kullanmaya devam edebilir; bu yüzden canlı görünen trafik yeni bir yolun izinli olduğunu kanıtlamayabilir. Soket listesi bir bağlantının olaydan önce olup olmadığını gösterir:

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

Soketin başlangıç zamanını bağlantı kesilmesinin zaman damgasıyla karşılaştırın. Arızadan daha eski bir bağlantı, sızıntı değil soket yeniden kullanımının kanıtıdır ve bunu arıza olarak bildirmek sıradaki kişiyi var olmayan bir hatayı aramaya gönderir.

Sonucu bir güncellemeyi atlatan bir biçimde kaydedin

Tetikleyiciyi, saniye cinsinden boşluğu, engellenmemiş herhangi bir isteğin başarılı olup olmadığını, ad çözümlemesinin başarılı olup olmadığını ve istemci ile işletim sistemi sürümlerini yazın. Bu beş olgudan oluşan küme sürümler arasında karşılaştırılabilir; bir paragraf düz yazı bunu yapamaz.

İstemci güncellemesinden veya profil değişikliğinden sonra aynı testi yeniden çalıştırın, çünkü engelleme davranışı bir uygulama ayrıntısıdır ve yer değiştirir. Kaydın amacı, hareketi bir olaya dönüşmeden fark etmektir; istemciyi bir kez sertifikalandırmak değil.

İlgili makaleler