Uji kill switch: ukur celahnya, bukan hanya koneksi ulangnya

Koneksi ulang yang selesai dalam satu detik memberi tahu Anda bahwa klien cepat. Itu tidak memberi tahu apakah ada yang bocor saat terowongan mati. Koneksi ulang yang memakan satu menit memberi tahu Anda bahwa klien lambat, dan tetap tidak memberi tahu apakah lalu lintas langsung diizinkan di celah itu. Itu dua pengukuran, dan uji kill switch yang hanya melaporkan yang pertama belum menguji sakelarnya.

Dua pengamatan, dua putusan terpisah

Pertanyaan ketersediaan sederhana: kapan terowongan bisa dipakai lagi, dan apakah aplikasi yang dilindungi perlu koneksi baru untuk sampai ke sana. Pertanyaan penegakan berbeda: paket mana yang meninggalkan mesin antara saat perlindungan jatuh dan saat perlindungan kembali.

Jawab keduanya dengan catatan terpisah. Satu baris menyebut celah berlangsung sekian detik. Baris lain menyebut apakah permintaan tanpa perlindungan berhasil selama celah itu. Menggabungkannya jadi satu lulus atau gagal menyembunyikan kasus yang paling penting: koneksi ulang cepat dengan kebocoran.

Bangun probe yang bisa Anda ukur waktunya

Pakai permintaan yang tidak berbahaya, murah, dan tidak bergantung pada kanal kendali terowongan itu sendiri. Loop di bawah mencetak stempel waktu, status HTTP, dan waktu berlalu sekali per detik, dan ia gagal dengan keras alih-alih menggantung:

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

Baca kode keluar curl, bukan hanya status. 28 berarti permintaan kehabisan waktu, begitulah jalur yang diblokir terlihat. 6 berarti resolusi nama gagal, yang merupakan temuan berbeda dan sering lebih menarik. 200 dengan waktu berlalu singkat selama celah berarti lalu lintas diizinkan keluar.

Tulis keluaran ke berkas dan simpan. Riwayat terminal bukan bukti, dan bagian menariknya biasanya tiga baris di tengah.

Picu kegagalan nyata, bukan yang rapi

Memutus koneksi dari menu klien sendiri menguji jalur kooperatif, di mana klien punya waktu memasang aturan pemblokirannya. Bunuh prosesnya sebagai gantinya, atau putuskan tautan di bawahnya, dan Anda menguji jalur yang diambil kegagalan nyata.

Setiap pemicu melatih jalur kode berbeda. Gangguan di sisi server, kehilangan tautan lokal, dan kerusakan klien masing-masing dapat meninggalkan keadaan berbeda, dan salah satunya kemungkinan besar adalah kasus yang akhirnya Anda temui. Jalankan probe pada setidaknya dua pemicu dan beri label hasil menurut pemicu.

Baca log untuk melihat bagaimana lalu lintas yang diizinkan tampak

200 atau kegagalan koneksi cepat selama celah adalah kebocoran, ke arah mana pun ia menunjuk. Waktu habis sepanjang celah adalah bentuk yang diharapkan dari kebijakan pemblokiran. Resolusi nama yang berhasil sementara koneksi gagal menunjukkan resolver masih terjangkau, yang merupakan kebocoran jenis lain.

Soket yang sudah ada perlu kehati-hatian. Suatu program dapat terus memakai koneksi yang dibukanya sebelum pemutusan, jadi lalu lintas yang tampak hidup mungkin tidak membuktikan jalur baru diizinkan. Daftar soket menunjukkan apakah koneksi lebih tua daripada peristiwa:

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

Bandingkan waktu mulai soket dengan stempel waktu pemutusan. Koneksi yang lebih tua daripada gangguan adalah bukti pemakaian ulang soket, bukan kebocoran, dan melaporkannya sebagai kegagalan mengirim orang berikutnya berburu bug yang tidak ada.

Catat hasilnya dalam bentuk yang bertahan melewati pembaruan

Catat pemicunya, celah dalam detik, apakah ada permintaan tak terblokir yang berhasil, apakah resolusi nama berhasil, serta versi klien dan sistem operasi. Himpunan lima fakta itu dapat dibandingkan antar rilis, sesuatu yang tidak bisa dilakukan satu paragraf prosa.

Jalankan lagi uji yang sama setelah pembaruan klien atau perubahan profil, karena perilaku pemblokiran adalah detail implementasi dan ia bergeser. Inti catatan adalah menyadari pergeseran itu sebelum menjadi insiden, bukan mensertifikasi klien sekali saja.