VPN kill switch yeniden başlatmaya dayanır mı? Nasıl doğrulanır

Yeniden başlatma, insanların kill switch'i test etmek için en sık kullandığı yöntemdir ve en sık yalan söyleyen testtir. İstemcideki onay kutusu yalnızca bir tercihtir; önemli olan, ağ yığınının ayağa kalktığı an ile tünelin gerçekten kurulduğu an arasında bir şeyin bloklamayı dayatıp dayatmadığıdır. Windows'ta bu şey genellikle Windows Filtering Platform'daki bir filtredir, Linux'ta bir birimin yüklediği kural kümesi, macOS'ta pf çapası, Android'de sistemin kendi her-zaman-açık ve kilitleme bayraklarıdır. Bu düzenlemeler yeniden başlatma boyunca çok farklı davranır ve yalnızca platform düzeyindekiler kimse oturum açamadan önce yerindedir.

Yeniden başlatma üç ayrı soru sorar

Soruyu bölün. Birincisi, ilke diskte önyükleme sırasında bir şeyin okuduğu bir biçimde var mı? İkincisi, bu okuyucu herhangi bir trafik dışarı çıkmadan önce çalışıyor mu? Üçüncüsü, ilke sizin için önemli olan trafiği kapsıyor mu, yani her süreci, iki adres ailesini ve DNS'i de. Birincisine evet ve ikincisine hayır demek, insanların yeniden başlatmaya dayanmayan kill switch olarak bildirdiği arızayı aynen üretir: başlangıçta trafik birkaç saniye dışarı sızar ve biri bakmaya gidene kadar kimse fark etmez.

Katmanları ayrı tutun. Kaydedilmiş bir güvenlik duvarı kural kümesi, önyüklemede başlayan bir hizmet ve istemci tercihi üç farklı ömre sahip üç farklı nesnedir. Tercih yeniden başlatmalara dayanır çünkü bir yapılandırma dosyasındaki değerdir. Paketleri bloklayan tek şey kurallardır ve o kurallar kendilerini tutan çekirdekle birlikte kaybolur.

Bloklamayı geri getiren nesneyi bulun

Linux'ta netfilter kuralları çekirdekte yaşar. Siz düzenlemediyseniz önyüklemede hiçbir şey onları geri yazmaz: iptables-save artı netfilter-persistent, nftables.service şunu yükler: /etc/nftables.conf, ya da kendi betiğinizi çalıştıran bir systemd birimi. Neyin etkin olduğunu kontrol edin, neyi yapılandırdığınızı hatırladığınızı değil.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Önyüklemeden birkaç saniye sonra boş bir kural kümesi başlıktaki sorunun yanıtıdır. Windows'ta istemci hizmetine nasıl başladığını sorun, ardından tünel kapalıyken platform filtresinin durumunu dökün.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

İkinci komut wfpstate.xml dosyasını geçerli dizine yazar. İstemci bağlanmadan önce var olan bloklama eylemli filtreleri arayın. Base Filtering Engine önyüklemede erken başlar ve kalıcı bayrakla eklenen filtreleri geri yükler, bu yüzden bazı kill switch'ler herhangi bir istemci penceresi yokken trafiği bloklar, bazıları ise bloklamaz. macOS'ta sudo pfctl -s info pf'in etkin olup olmadığını bildirir, sudo pfctl -s rules nelerin yüklü olduğunu gösterir ve VPN istemcileri genellikle kurallarını ana kümeye değil bir çapaya bağlar. utun3 adını veren bir kural, sonraki önyüklemeden sonra başka bir arayüze işaret edebilir, çünkü o numara çalışma zamanında atanır.

Ağın yükselmesi ile tünelin yükselmesi arasındaki boşluğu izleyin

Tehlikeli aralık tüm yeniden başlatma değil, boşluktur. Arayüz bir anda kiralama ve varsayılan rota alır, VPN hizmeti başka bir anda başlar ve tünel daha da geç kimlik doğrular; bazen ancak kullanıcı oturum açtıktan ve bir kimlik bilgisi aracısı çalıştıktan sonra. Bloklama en son uygulanırsa boşluktaki her şey açık olarak dışarı çıkar.

systemd sunucularında sırayı tahmin etmek yerine okuyun. VPN ve güvenlik duvarı birimlerinde systemctl cat komutunu çalıştırın ve After= ile Before= karşısında network-pre.target veya network-online.target arayın. network-online.target sonrasında sıralanan güvenlik duvarı birimi arayüze kaybeder; network-pre.target tarafından istenen ve ondan önce sıralanan birim kazanır. Windows'ta eşdeğer sorular hizmetin başlangıç türü ve bağımlılıklarıdır, çünkü Manual olarak ayarlanmış bir hizmet önyükleme zamanı sürecini bloklayamaz. Gereksiniminiz oturum açmadan önceki trafiği içeriyorsa bunu yalnızca cihaz düzeyinde bir düzenleme karşılar: Always On VPN cihaz tüneli makine sertifikasıyla kimlik doğrular ve kullanıcı oturum açmadan önce bağlanır, ve Microsoft cihaz tüneli yapılandırmasını belgeler kullanıcı tünelinden ayrı olarak. Android diğer yolu izler, her zaman açık VPN'i zorunlu kılar ve o olmadan bağlantıları uygulama sürecinden değil sistemden bloklar.

Testi çalıştırın, ardından iki zaman çizelgesini karşılaştırın

Sızsa bile hiçbir maliyeti olmayan bir hedefle yeniden başlatın ve durumu boşluktan sonra değil boşluk sırasında kaydedin. En temiz yöntem bir önyükleme sondayıcısıdır: platformun izin verdiği en erken anda başlayan, varsayılan rotayı ve güvenlik duvarı durumunu kaydeden, kısa bir zaman aşımıyla bir istek deneyen ve yerel bir dosyaya satır ekleyen oneshot birimi veya zamanlanmış görev. Bu kaydı journalctl -b -u veya sistem günlüğünden gelen VPN hizmeti başlangıç zamanıyla karşılaştırın.

Ardından olağan testi yapın: tünel açık, bağlantıyı kesin, doğrudan trafiğin bloklanıp bloklanmadığına bakın, geri yükleyin. İkincisini geçip birincisinde başarısız olmak normal sonuçtur ve dayatmanın istemci tarafında olduğunu, istemci bağlandığında uygulandığını, önyüklemede değil, gösterir. En son denetlediğim makinede bloklama bir NetworkManager dağıtıcı betiğinden geliyordu: mevcut ve doğru ve arayüz yükselmeden önceki saniyeler için işe yaramaz. Her iki sonucu da yazın, çünkü yeniden başlatmaya dayanmak ancak hangi katmanın hangi andan itibaren dayandığını söylediğinizde bir anlam taşır.

Geri dönüş yolunuzu kesmeden boşluğu kapatın

Önyüklemede bloklama yoksa ikinci bir istemci kuralı eklemek yerine dayatmayı bir katman aşağı indirin. Kural kümesini kaydedin ve ağ kullanılabilir olmadan önce sıralanan bir birimden yükleyin, ve o birimin koruması gereken bir DNS sorgusuna veya ağ bağlamasına ihtiyaç duymadığından emin olun. Kapsam zaman kadar önemlidir: kullanıcı kimliğine veya bir cgroup'a uyan kurallar her sistem servisini bloklamanın dışında bırakır ve yalnızca IPv4 ile ilgilenen bir küme IPv6 ve DNS'i erişilebilir bırakır.

Kendinize bir geri dönüş yolu bırakın. Önyüklemede her şeyi bloklayıp sonra kimlik doğrulayamayan bir makinenin hiç ağı yoktur ve düzeltme bloklamayı silmek değil kimlik bilgisini veya sırayı onarmaktır. Yerel konsol için belgelenmiş bir yordam ve tünelin gerçekten ihtiyaç duyduğu şeyler için dar, bilinçli bir istisna tutun, örneğin sunucu adresi ve tünel yokken kullanılan çözümleyici.

Bu düzenlemeye güvenmeden önce dört şeyi sırayla doğrulayın. İlke önyüklemenin okuduğu yerde saklanır. O okuyucu arayüz kullanılabilir olmadan önce çalışır. Bloklama iki adres ailesini ve DNS'i kapsar. VPN bloklama etkinken hâlâ kimlik doğrulayabilir. Dördü de geçerli olduğunda yeniden başlatma hiçbir şeyi değiştirmez.