Uygulama kill switch'i ile güvenlik duvarı kill switch'i: her biri neyi engeller

Bir özellik listesindeki kill switch, tünel düştüğünde ne olacağı hakkında neredeyse hiçbir şey söylemez. Bir uygulama seçili süreçleri kapatır, bir başkası işletim sistemi sınırında paket filtreleri kurar, üçüncüsü ise yalnızca yeniden bağlanmayı dener. Fark, arızedan sonraki saniyelerde ortaya çıkar, ayarlar ekranında değil. Bu denetimleri sırayla yapın ve dürüstçe yanıtlayamadığınız ilkinde durun, çünkü gerçek kapsamınız orada biter.

Önce uygulama mekanizmasını adlandırın

Süreç sonlandırma, uygulamanın yaşam döngüsünün bir özelliğidir. Algılanan bir tünel arızasından sonra seçili programları bulur ve kapatır. Ana süreç olmayan her şey hayatta kalır: yardımcı hizmetler, arka plan eşitlemesi ve bir saniye sonra başlatılan her uygulama kendi yaşam döngüsüne ve kendi zamanlamasına sahiptir.

Paket filtreleme işletim sisteminin bir özelliğidir. İzin verilen yolu izlemeyen trafiği reddeder; bu daha güçlü bir vaattir, ancak yalnızca kuralın gerçekten eşleştiği ölçüde. Adres ailesi, arayüz, hariç tutulan uygulamalar ve istisnalar buna karar verir, istemcideki etiket değil.

Engelleme istemciden daha uzun yaşıyor mu?

Şu sırayla dört soru sorun: çökmede, elle çıkışta, oturum kapatmada ve yeniden başlatmada ne olur. İstemcinin kendi yönettiği bir kural genellikle düzgün kapanma sırasında kaldırılır ve çoğu zaman çökmeden sonra kalır. Platform deposuna kurulan bir kural tersini yapabilir: hem istemciyi hem de bazen kaldırmayı atlatır.

İstemciyi uzun bir indirmenin ortasında kapatın ve aktarımın durup durmadığına bakın.

Standart delikleri arayın

IPv6 ilkidir. IPv4 adresleri için yazılmış bir kural IPv6 trafiğini etkilemez ve birçok istemci yalnızca v4 yarısını yazar. İkincisi arayüzdür: USB tethering, ikinci bir Wi-Fi adaptörü ve hücresel modem, birincil bağlantıyla sınırlı bir kurala dahil olmayabilir. Hariç tutulan uygulamalar ve yerel ağ istisnaları üçüncüsüdür.

Windows'ta anahtara güvenmek yerine kurulu kuralları okuyabilirsiniz: Get-NetFirewallRule -DisplayName '*VPN*' ve netsh wfp show filters ikisi de neyin var olduğunu gösterir. Linux'ta iptables -S, ip6tables -S ve nft list ruleset yaygın durumları kapsar ve üçünü karşılaştırmak asıl meseledir.

DNS her zamanki sızıntıdır

UDP 53 açıkken TCP'yi engellemek, her ana makine adı sorgusunu hâlâ yanıtlayan çok ikna edici bir kill switch verir. Aynı durum DNS başka bir arayüzdeki çözümleyiciye verildiğinde veya istemci yalnızca v4'ü engellediğinde ve çözümleyici v6 üzerinden erişilebilir olduğunda da geçerlidir.

Tünel kapalıyken bilinen bir adı çözün ve yanıt gelip gelmediğine bakın. Geliyorsa, durum simgesi ne derse desin trafik tamamen engellenmemiştir.

Anahtarı değil, geçişi test edin

VPN'i kendi menüsünden kapatmak düzgün bir kapanmadır ve düzgün durumu her uygulama iyi yönetir. Önemli olan geçiş kaba olandır: tünel sürecini öldürün, ağı çekin, sunucunun yanıt vermeyi bırakmasına izin verin. Sonra bir istek başlatın ve başarısız mı olduğuna yoksa sessizce fiziksel bağlantıyı mı kullandığına bakın.

Bir dizüstü bilgisayardan alınan sonuç telefona veya yönlendiriciye geçmez. Farklı platform API'leri, farklı varsayılanlar ve Android'de fark çarpıcıdır: engellemeli always-on modu istemci değil sistem uygular, bu yüzden istemci çalışmadığında da çalışmaya devam eder. Android VPN rehberi bu ayrımı açıklar.

Geri dönüş yolu bırakın

Sistem düzeyinde engellemenin tersi bir arıza modu vardır. İstemciden daha uzun yaşayan filtreler, kaldırma işleminden sonra makineyi tamamen ağsız bırakabilir; bu da belirgin nedeni olmayan bir destek çağrısıdır. Platform kuralları yazan herhangi bir kill switch'i etkinleştirmeden önce nasıl kaldırıldığını not edin ve satıcının onarım yolunu bulabileceğiniz yerde tutun.

İstemciniz için çökme, IPv6, DNS ve geçiş denetimlerini yanıtlayamıyorsanız, onu bilinen boşlukları olan uygulama düzeyinde bir anahtar olarak görün ve buna göre planlayın.