Kill switch diaktifkan: apa yang berlaku pada sesi TCP yang terbuka?

Terowong terputus, kill switch diaktifkan, dan muat turun yang sudah tiga perempat siap sama ada membeku atau gagal serta-merta. Kedua-dua hasil ini datang daripada pilihan penguatkuasaan yang berbeza, bukan daripada tahap perlindungan yang berbeza. Paket yang digugurkan membiarkan sambungan menunggu, manakala paket yang ditolak menutupnya dan memberitahu aplikasi. Memutuskan tingkah laku mana yang anda mahu ialah persoalan reka bentuk, dan mengujinya ialah latihan berasingan.

Digugurkan, ditolak dan di-reset adalah berbeza

Peraturan firewall yang menggugurkan trafik membuang paket dan tidak menghantar apa-apa balik, jadi penghantar terus menghantar semula mengikut pemasa sendiri. Peraturan yang menolak dengan reset TCP menutup sambungan serta-merta dan aplikasi melihat ralat. Kebanyakan kill switch menggugurkan, kerana penolakan akan mendedahkan dasar itu dan kerana pengguguran menyerupai tingkah laku rangkaian yang mati.

Menyekat juga bukan sama dengan menutup soket. Aplikasi masih memegang deskriptor dalam keadaan terjalin, dan hanya paket yang hilang. Itulah sebabnya halaman boleh duduk pada pemutar selama beberapa minit sementara sistem pengendalian berkeras bahawa sambungan itu wujud. Baca penguatkuasaan yang didokumenkan dan bukannya membuat andaian daripada mesej aplikasi, kerana kedua-dua tingkah laku kelihatan seperti rangkaian yang mati.

Apa yang aplikasi lakukan sepanjang jurang itu

TCP menghantar semula dengan kelewatan yang meningkat, dan belanjawan cubaan semula lalai Linux tamat sekitar suku jam, bukan dalam beberapa saat. Sehingga itu soket itu tidak terbuka dengan berguna dan tidak tertutup. Aplikasi yang mempunyai keepalive atau had masa permintaan sendiri sering menyerah lebih awal, itulah sebabnya dua program pada mesin yang sama berkelakuan berbeza semasa satu gangguan.

Apabila terowong kembali, soket tempatan tidak berubah tetapi laluannya mungkin berubah. Alamat sumber awam yang baharu menghasilkan empat-tuple yang berbeza di pelayan, jadi firewall berkeadaan di sebelah jauh tidak lagi sepadan dengan sesi itu. Sambungan itu mati walaupun klien tidak pernah melihat ralat.

Tentukan sama ada pemulihan diperlukan

Pilih antara dua kontrak. Sama ada sesi mesti bertahan melepasi jurang pendek, yang memerlukan pengalamatan stabil dan pelayan yang menyimpan keadaannya, atau aplikasi mesti menyambung semula dengan bersih, yang memerlukan logik cubaan semula yang selamat diulang. Apa-apa di antaranya menghasilkan hasil terburuk: klien yang menghantar semula apa yang pelayan sudah rekod, atau klien yang melaporkan kejayaan untuk sesi yang tiada siapa dapat lihat.

Pengalamatan stabil ialah bahagian yang orang lupa, kerana sambungan semula yang mendarat pada alamat awam berbeza membatalkan keadaan sebelah pelayan walaupun soket klien kelihatan sihat. Catat kontrak mana yang terpakai pada setiap aplikasi, kerana jarang semuanya sepadan.

Periksa sekatan dan pemulihan secara berasingan

Anggap perlindungan kebocoran dan kelangsungan sesi sebagai dua sifat, kerana lulus satu tidak memberitahu apa-apa tentang yang lain. Sesi yang bertahan bukan bukti bahawa trafik langsung disekat, dan sesi yang mati bukan bukti bahawa setiap laluan langsung disekat.

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 ujian yang tidak berbahaya semasa memerhati pemulihan, supaya penghantaran berganda tidak menjadi insiden. Catat mod kegagalan yang anda benar-benar lihat: apa yang dipaparkan oleh aplikasi, sama ada soket bertahan, dan bila ia pulih dengan sendirinya.

Tulis tingkah laku yang dijangka di sebelah peraturan penguatkuasaan dan tarikhkannya. Orang seterusnya yang mengubah peraturan itu perlu tahu kontrak mana yang dijanjikan oleh penggunaan.