Kill switch devreye giriyor: açık TCP oturumlarına ne olur?

Tünel düşer, kill switch devreye girer ve dörtte üçü tamamlanmış bir indirme ya donar ya da hemen başarısız olur. Bu iki sonuç, farklı koruma düzeylerinden değil, farklı uygulama tercihlerinden kaynaklanır. Düşürülen bir paket bağlantıyı beklemeye bırakır, reddedilen bir paket ise onu kapatır ve uygulamaya bildirir. Hangi davranışı istediğinize karar vermek bir tasarım sorusudur ve bunu test etmek ayrı bir alıştırmadır.

Düşürme, reddetme ve sıfırlama farklıdır

Trafiği düşüren bir güvenlik duvarı kuralı paketi atar ve hiçbir şey geri göndermez, bu yüzden gönderen kendi zamanlayıcılarıyla yeniden göndermeye devam eder. TCP reset ile reddeden bir kural bağlantıyı hemen kapatır ve uygulama bir hata görür. Çoğu kill switch düşürür, çünkü reddetme politikayı açığa çıkarır ve düşürme ölü bir ağın davranışına benzer.

Engellemek, soketi kapatmakla aynı şey değildir. Uygulama hâlâ kurulmuş durumda bir tanımlayıcı tutar ve yalnızca paketler eksiktir. Bu yüzden işletim sistemi bağlantının var olduğunda ısrar ederken bir sayfa dakikalarca bir yükleniyor göstergesinde kalabilir. Uygulamanın mesajından çıkarım yapmak yerine belgelenmiş uygulama politikasını okuyun, çünkü her iki davranış da ağ çökmüş gibi görünür.

Boşluk sürerken uygulama ne yapar

TCP artan gecikmelerle yeniden gönderir ve Linux'un varsayılan yeniden deneme bütçesi saniyeler içinde değil, yaklaşık çeyrek saatte dolar. O zamana kadar soket ne yararlı biçimde açıktır ne de kapalıdır. Kendi keepalive'ı veya istek zaman aşımı olan uygulamalar genellikle daha erken pes eder, bu yüzden aynı makinedeki iki program tek bir kesinti sırasında farklı davranır.

Tünel geri geldiğinde yerel soket değişmez ama yol değişmiş olabilir. Yeni bir genel kaynak adresi sunucuda farklı bir dörtlü üretir, bu yüzden karşı taraftaki durum bilgili güvenlik duvarı artık oturumla eşleşmez. İstemci hiç hata görmemiş olsa da bağlantı ölmüştür.

Toparlanmanın gerekli olup olmadığına karar verin

İki sözleşme arasında seçim yapın. Ya oturum kısa bir boşluğu atlatmalıdır, bu da kararlı adresleme ve durumunu koruyan bir sunucu gerektirir, ya da uygulama temiz biçimde yeniden bağlanmalıdır, bu da yinelenmesi güvenli bir yeniden deneme mantığı gerektirir. Arada kalan her şey en kötü sonucu üretir: sunucunun zaten kaydettiğini yeniden gönderen bir istemci ya da kimsenin göremediği bir oturum için başarı bildiren bir istemci.

Kararlı adresleme, insanların unuttuğu kısımdır, çünkü farklı bir genel adrese inen bir yeniden bağlanma, istemcinin soketi sağlıklı görünse bile sunucu tarafındaki durumu geçersiz kılar. İki sözleşmeden hangisinin her uygulama için geçerli olduğunu yazın, çünkü nadiren hepsi uyuşur.

Engellemeyi ve toparlanmayı ayrı ayrı kontrol edin

Sızıntı korumasını ve oturumun hayatta kalmasını iki özellik olarak ele alın, çünkü birini geçmek diğeri hakkında hiçbir şey söylemez. Hayatta kalan bir oturum, doğrudan trafiğin engellendiğinin kanıtı değildir ve ölen bir oturum, her doğrudan yolun engellendiğinin kanıtı değildir.

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'

Toparlanmayı gözlemlerken zararsız bir test işlemi kullanın, böylece yinelenen bir gönderim olaya dönüşmesin. Gerçekte gördüğünüz arıza biçimini kaydedin: uygulamanın ne gösterdiğini, soketin hayatta kalıp kalmadığını ve kendi kendine ne zaman toparlandığını.

Beklenen davranışı uygulama kuralının yanına yazın ve tarih atın. O kuralı değiştirecek sonraki kişi, dağıtımın iki sözleşmeden hangisini vaat ettiğini bilmelidir.