Kill switch aktif: apa yang terjadi pada sesi TCP yang terbuka?

Tunnel putus, kill switch aktif, dan unduhan yang sudah tiga perempat selesai entah membeku atau langsung gagal. Kedua hasil itu berasal dari pilihan penegakan yang berbeda, bukan dari tingkat perlindungan yang berbeda. Paket yang dijatuhkan membuat koneksi menunggu, sedangkan paket yang ditolak menutupnya dan memberi tahu aplikasi. Memutuskan perilaku mana yang Anda inginkan adalah pertanyaan desain, dan mengujinya adalah latihan tersendiri.

Dijatuhkan, ditolak, dan di-reset itu berbeda

Aturan firewall yang menjatuhkan lalu lintas membuang paket dan tidak mengirim apa pun kembali, sehingga pengirim terus mengirim ulang sesuai timernya sendiri. Aturan yang menolak dengan reset TCP langsung menutup koneksi dan aplikasi melihat kesalahan. Sebagian besar kill switch menjatuhkan, karena penolakan akan mengungkap kebijakan dan karena menjatuhkan menyerupai perilaku jaringan yang mati.

Memblokir juga tidak sama dengan menutup soket. Aplikasi masih memegang deskriptor dalam keadaan terbentuk, dan hanya paketnya yang hilang. Itulah sebabnya halaman bisa duduk di spinner selama beberapa menit sementara sistem operasi bersikeras koneksi itu ada. Bacalah penegakan yang didokumentasikan alih-alih menyimpulkannya dari pesan aplikasi, karena kedua perilaku tampak seperti jaringan yang mati.

Apa yang dilakukan aplikasi selama jeda berlangsung

TCP mengirim ulang dengan jeda yang meningkat, dan anggaran percobaan ulang bawaan Linux habis sekitar seperempat jam, bukan dalam hitungan detik. Sampai saat itu soket tidak benar-benar terbuka maupun tertutup. Aplikasi dengan keepalive atau batas waktu permintaan sendiri sering menyerah lebih awal, itulah sebabnya dua program di mesin yang sama berperilaku berbeda selama satu gangguan.

Saat tunnel kembali, soket lokal tidak berubah tetapi jalurnya mungkin berubah. Alamat sumber publik baru menghasilkan empat-tuple yang berbeda di server, sehingga firewall stateful di sisi jauh tidak lagi cocok dengan sesi. Koneksi sudah mati meskipun klien tidak pernah melihat kesalahan.

Putuskan apakah pemulihan diperlukan

Pilih di antara dua kontrak. Entah sesi harus bertahan melewati jeda singkat, yang membutuhkan pengalamatan stabil dan server yang menyimpan statusnya, atau aplikasi harus menyambung ulang dengan bersih, yang membutuhkan logika percobaan ulang yang aman diulang. Apa pun di antaranya menghasilkan hasil terburuk: klien yang mengirim ulang apa yang sudah dicatat server, atau klien yang melaporkan keberhasilan untuk sesi yang tidak dapat dilihat siapa pun.

Pengalamatan stabil adalah bagian yang orang lupakan, karena penyambungan ulang yang mendarat di alamat publik berbeda membatalkan status sisi server bahkan ketika soket klien tampak sehat. Catat kontrak mana yang berlaku untuk setiap aplikasi, karena jarang semuanya cocok.

Periksa blokir dan pemulihan secara terpisah

Perlakukan perlindungan kebocoran dan ketahanan sesi sebagai dua properti, karena lulus yang satu tidak mengatakan apa pun tentang yang lain. Sesi yang bertahan bukan bukti bahwa lalu lintas langsung diblokir, dan sesi yang mati bukan bukti bahwa setiap rute langsung diblokir.

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

Gunakan operasi uji yang tidak berbahaya saat mengamati pemulihan, agar pengiriman ganda tidak menjadi insiden. Catat mode kegagalan yang benar-benar Anda lihat: apa yang ditampilkan aplikasi, apakah soket bertahan, dan kapan pulih dengan sendirinya.

Tuliskan perilaku yang diharapkan di samping aturan penegakan dan beri tanggal. Orang berikutnya yang mengubah aturan itu perlu tahu kontrak mana yang dijanjikan oleh penerapan.