Ujian kill switch: ukur jurang, bukan hanya sambungan semula

Sambungan semula yang selesai dalam satu saat memberitahu anda klien itu pantas. Ia tidak memberitahu sama ada sesuatu terlepas semasa terowong mati. Sambungan semula yang mengambil satu minit memberitahu anda klien itu perlahan, dan masih tidak memberitahu sama ada trafik terus dibenarkan dalam jurang itu. Itu dua ukuran, dan ujian kill switch yang hanya melaporkan yang pertama belum menguji suisnya.

Dua pemerhatian, dua keputusan berasingan

Soalan ketersediaan mudah: bila terowong boleh digunakan semula, dan sama ada aplikasi terlindung memerlukan sambungan baharu untuk sampai ke sana. Soalan penguatkuasaan berbeza: paket mana yang meninggalkan mesin antara saat perlindungan jatuh dan saat ia kembali.

Jawab kedua-duanya dengan rekod berasingan. Satu baris menyatakan jurang berlangsung beberapa saat. Baris lain menyatakan sama ada permintaan tanpa perlindungan berjaya dalam jurang itu. Menggabungkannya menjadi satu lulus atau gagal menyembunyikan kes yang paling penting: sambungan semula pantas dengan kebocoran.

Bina prob yang boleh anda ukur masa

Gunakan permintaan yang tidak berbahaya, murah dan bebas daripada saluran kawalan terowong itu sendiri. Gelung di bawah mencetak cap masa, status HTTP dan masa berlalu sekali sesaat, dan ia gagal dengan kuat dan bukan tergantung:

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 kod keluar curl, bukan hanya status. 28 bermaksud permintaan kehabisan masa, begitulah laluan yang disekat kelihatan. 6 bermaksud penyelesaian nama gagal, iaitu penemuan berbeza dan selalunya lebih menarik. 200 dengan masa berlalu yang singkat semasa jurang bermaksud trafik dibenarkan keluar.

Tulis output ke fail dan simpannya. Sejarah terminal bukan bukti, dan bahagian yang menarik biasanya tiga baris di tengah.

Picu kegagalan sebenar, bukan yang kemas

Menyambung keluar dari menu klien sendiri menguji laluan kerjasama, di mana klien mempunyai masa untuk memasang peraturan penyekatannya. Bunuh proses itu sebaliknya, atau putuskan pautan di bawahnya, dan anda menguji laluan yang diambil oleh kegagalan sebenar.

Setiap pencetus melatih laluan kod yang berbeza. Gangguan di sebelah pelayan, kehilangan pautan setempat dan ranap klien masing-masing boleh meninggalkan keadaan berbeza, dan salah satunya mungkin kes yang akhirnya anda temui. Jalankan prob pada sekurang-kurangnya dua pencetus dan labelkan keputusan mengikut pencetus.

Baca log untuk melihat bagaimana trafik yang dibenarkan kelihatan

200 atau kegagalan sambungan pantas semasa jurang ialah kebocoran, ke arah mana pun ia menunjuk. Tamat masa sepanjang jurang ialah bentuk yang dijangka bagi dasar penyekatan. Penyelesaian nama yang berjaya sementara sambungan gagal menunjukkan penyelesai masih boleh dicapai, iaitu kebocoran jenis lain.

Soket sedia ada memerlukan kehati-hatian. Sesuatu program boleh terus menggunakan sambungan yang dibukanya sebelum pemutusan, jadi trafik yang kelihatan hidup mungkin tidak membuktikan laluan baharu dibenarkan. Senarai soket menunjukkan sama ada sambungan lebih tua daripada peristiwa itu:

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

Bandingkan masa mula soket dengan cap masa pemutusan. Sambungan yang lebih tua daripada gangguan ialah bukti penggunaan semula soket, bukan kebocoran, dan melaporkannya sebagai kegagalan menghantar orang seterusnya memburu pepijat yang tidak wujud.

Catat keputusan dalam bentuk yang bertahan selepas kemas kini

Catat pencetus, jurang dalam saat, sama ada mana-mana permintaan tidak disekat berjaya, sama ada penyelesaian nama berjaya, serta versi klien dan sistem pengendalian. Set lima fakta itu boleh dibandingkan antara keluaran, sesuatu yang tidak dapat dilakukan oleh satu perenggan prosa.

Jalankan semula ujian yang sama selepas kemas kini klien atau perubahan profil, kerana tingkah laku penyekatan ialah butiran pelaksanaan dan ia bergerak. Tujuan rekod ialah menyedari pergerakan itu sebelum ia menjadi insiden, bukan untuk memperakui klien sekali sahaja.