Always-on VPN mi kill switch mi: aslında hangisini açtınız?

Always-on ve kill switch aynı ayar ekranında iki satır arayla durur, bu yüzden insanlar onları tek bir özelliğin iki adı sanır. Değiller. Always-on bir yeniden bağlanma politikasıdır: tüneli açılışta başlat, çökme veya ağ değişikliğinden sonra geri getir ve başarısız oldukça yeniden dene. Kill switch bir trafik politikasıdır: tünel kapalıyken hangi paketlerin makineden hâlâ çıkabileceğini adlandırır. Birincisini ikincisi olmadan açabilirsiniz ve çoğu platformda varsayılan sonuç bu boşluk sırasında trafiği yine dışarı bırakır.

Kontrol 1: blok kendi başına bir anahtar mı?

Android 10 ve sonrasında kayıtlı bir VPN profili, dişli simgesinin arkasında iki bağımsız anahtar açar: Always-on VPN ve Block connections without VPN. Kill switch yalnızca ikincisidir. Yalnızca always-on ile tünel kopmadan sonra gerçekten geri gelir ve isteğin ortasındaki herhangi bir uygulama bu olana kadar Wi-Fi ya da mobil veri üzerinden ağa ulaşabilir.

Yönetilen cihazlar aynı ayrımı ilke API'sinde korur. setAlwaysOnVpnPackage() paket adını ve lockdownEnabled bayrağını alır; paketi ayarlayıp bayrağı false bırakan bir yönetici kapalı bir cihaz değil kalıcı bir tünel kurmuştur. Konsoldaki ifade bu farkı nadiren görünür kılar.

Durumu konsoldan değil cihazdan okuyun: adb shell settings get global always_on_vpn_app ve adb shell settings get global always_on_vpn_lockdown. Birincisi null döndürürse platform düzeyinde hiçbir paket zorlanmıyor demektir; ikincisi 0 döndürürse platform hiçbir şeyi engellemiyordur. Android VPN kılavuzu bunları tek bir kip değil ayrı yetenekler olarak açıklar.

Kontrol 2: bloğu hangi katman sahipleniyor?

Etiketler istemcide, bloklar genellikle güvenlik duvarında yaşar, bu yüzden aynı sözcük her platformda başka anlama gelir. Aşağıdaki satırlar herhangi birine güvenmeden önce doğrulanmaya değer olanlar.

Windows, engellemeyen bir etiketin en açık örneğidir. Orada Always On tünelin kalıcılığını anlatır: makine kimlik doğrulaması için aygıt tüneli ve oturum açmış hesap için kullanıcı tüneli, profil XML'i veya Add-VpnConnection ile yapılandırılır. O profilde tünel yokken giden bir paketi durduran hiçbir şey yoktur ve giden filtreleme varsayılan olarak açık değildir, bu yüzden Wi-Fi'deki bir dizüstü VPN kapalıyken çalışmaya devam eder.

WireGuard da aynı şekilde bölünür, ama istemciye göre. WireGuard for Windows'ta her tünel için filtre kuralları kuran Block untunneled traffic seçeneği vardır; Linux araçlarında eşdeğer bir anahtar yoktur. wg-quick her AllowedIPs girdisi için bir yol ve bir fwmark kuralı ekler, wg-quick down ikisini de kaldırır, böylece fiziksel varsayılan yol tek paket kaybetmeden yeniden devralır.

Apple platformlarında always-on, gözetim altındaki cihazlar için bir yönetim profili özelliği olarak gelir ve onay kutusu değil on-demand kuralları olarak ifade edilir. Yükten yanıtlanması gereken soru, başarısız tünelin trafiği reddedip reddetmediği ya da yalnızca başka bir bağlantı isteyip istemediğidir. Menü başlığı bunu söylemez.

Kontrol 3: simgeyi değil boşluğu ölçün

Dört geçiş önemlidir ve her biri farklı biçimde başarısız olur: kimse oturum açmadan önceki açılış, uyku ve uyanma, Wi-Fi'den mobil veriye geçiş ve tünel arayüzünü yarı yapılandırılmış bırakan bir istemci çökmesi. Birinde temiz bir yeniden bağlanma diğer üçü hakkında hiçbir şey kanıtlamaz.

En ucuz test tüneli bilerek durdurur ve sonra çıkmayı dener. Tünel kapalıyken curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com komutunun 200 döndürmesi politikanın fail-open olduğu anlamına gelir; zaman aşımı ya da reddedilen bağlantı bir şeyin hâlâ engellediği anlamına gelir. ip route get 1.1.1.1 paketi taşıyacak arayüzü adlandırır, bu genellikle tepsi simgesinden daha bilgilendiricidir ve systemctl status wg-quick@wg0 arayüzün temiz biçimde kaldırılıp kaldırılmadığını gösterir.

Aynı kontrolü ağ değişirken ikinci bir pencerede çalıştırın, yalnızca oturduktan sonra değil. Kopma ile yeni deneme arasındaki aralık önemli olan kısımdır ve ad çözümlemesi trafiğin kaçtığını fark etmenin en hızlı yoludur: tünel kapalıyken yerel çözümleyici yanıt veriyorsa blok tam değildir.

Kontrol 4: kilitlemeden önce istisnalara karar verin

İki istisna yapısaldır. İstemci VPN sunucusunun kendisine ulaşmak zorundadır, bu yüzden her şeyi düşüren bir kural kümesi korumayı geri getirecek yeniden bağlanmayı da engeller. Captive portal da ayakta olmayan bir tünelden ulaşılamaz, bu yüzden otel Wi-Fi'sinde kilitli bir cihazın portalı açmak için belgelenmiş bir yolu olmalı, doğaçlama değil.

Asgari biçim, uç nokta izinli ve geri kalan her şey düşürülmüş:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

O uç nokta satırını sabit değil değişken olarak ele alın. Sağlayıcılar adresleri döndürür ve eski bir istisna, çalışan bir kill switch'in yeniden bağlanamayan bir cihaza dönüşmesinin olağan nedenidir. Yerel yazıcılar, NAS paylaşımları ve geliştirme hizmetleri aynı yazılı listeye girer, yoksa her biri ayrı bir destek talebinde keşfedilir.

Kontrol 5: gerçekte neyi kanıtladığınızı yazın

Dört sütunlu bir tablo tutun ve test ederek doldurun: durum, beklenen davranış, gözlenen davranış, kanıt. Satırlar kontrol 3'teki geçişler artı bir kasıtlı arızadır. Komut çıktısıyla dolduramadığınız satır test etmediğiniz satırdır ve yeniden bağlanma satırını geçip açılış satırında kalan bir cihaz, fazladan on dakikayı hak edecek kadar yaygındır.

Bunu bitmiş saymadan önce:

• Bloklama ayarının yeniden bağlanma ayarından ayrı olduğunu doğrulayın ve değerini cihazda okuyun.
• Bloğu hangi katmanın uyguladığını - istemci seçeneği, cihaz ilkesi veya güvenlik duvarı - ve o katmanın nerede yapılandırıldığını bilin.
• Bloğu kanıtlayan bir kontrol komutu tutun ve onu geçiş sırasında çalıştırın, sonrasında değil.
• İstisna listesini uç nokta dahil yazın ve kimin yenilediğini not edin.
• Yönetilen donanımda zorunlu ilkeyi kendi hâline bırakın; bloğu kaldırmak tüneli onarmak yerine gereksinimi değiştirir.