Aynı anda iki VPN uygulaması: hangi kill switch gerçekten geçerli?

İki VPN istemcisi yan yana çalışabilir, ancak kill switch’leri tek bir politikada birleşmez. Her istemci kendi tüneli için kurallar kurar ve hiçbiri diğerinin varlığını bilmez. Bunu önce bir iş istemcisi bağlıyken yaşadım: ikinci uygulama el sıkışmasını tamamlayamadı, on dakika „Connecting“ durumunda kaldı ve ilk tünel her şeyi sessizce taşıdı. İkinci uygulamanın korunup korunmadığı üç koşula bağlıdır, iki simgenin de Bağlandı demesine değil.

Bir kill switch gerçekte neyle sınırlıdır

İşletim sisteminde tek bir kill switch bayrağı yoktur. Böyle bir şey reklam eden istemci bir kural kümesi kurar: tünelimden çıkmayan her şeyi düşür ve tünel kaybolduğunda çoğu zaman fail closed davran. Linux’ta bu genellikle bir nftables veya iptables zinciridir, Windows’ta bir dizi Windows Filtering Platform filtresi, Android ve iOS’ta tünel hizmetinin kendi yönlendirmesi artı VPN olmadan bağlantıları engelleyen sistem ayarıdır. Android VPN kılavuzu, platform görüşünü istiyorsanız bu hizmet modelini anlatır.

Kapsam, önemli olan kısımdır. „Yalnızca wg0 çıkış arayüzündeki paketlere izin ver“ gibi bir kural, ikinci bir tünelin olup olmadığını umursamaz. Başka bir istemci wg1’i kaldırırsa, ilk istemcinin kuralları bu paketleri sıradan trafik olarak ele alır: genellikle düşürülür, bazen izin verilir. Her iki durumda da karar veren ilk istemcidir ve ikinci bir uygulamanın beklediğinden haberi yoktur.

Kimin kapsandığına karar veren üç koşul

Her kombinasyonu listelemek zorunda değilsiniz. Üç soru bunu birkaç dakikada çözer.

1. Platform ikinci bir tünele hiç izin veriyor mu? Çoğu Android telefon ve iPhone, kullanıcı profili başına yalnızca bir etkin VPN hizmetine izin verir, bu yüzden ikinci uygulama hiçbir zaman tünel tutmaz ve hiçbir şey uygulamaz. Tek bir politika alırsınız: yeri kazanan uygulamadan.
2. Varsayılan yolu hangi süreç sahipleniyor? Windows, macOS ve Linux iki tüneli rahatlıkla taşır. Varsayılan yol, onu en son veya daha iyi metrikle yapılandıran istemciye aittir ve diğer istemci bağlı ama boştur. Linux’ta wg-quick’in varsayılan yol modu, özel bir tablo ve fwmark kuralıyla ilke tabanlı yönlendirme kullanır, bu yüzden ikinci bir wg-quick tüneli birinciyi değiştirmek yerine rakip bir kural ekler.
3. İkinci istemci kendi sunucusuna ulaşabiliyor mu? İlk kill switch varsayılan olarak reddediyorsa, ikinci uygulamanın dış uç noktası yalnızca bir başka düşürülmüş hedeftir. Sessizce yeniden dener ve hiçbir zaman hata bildirmez.

Kısa sürüm, destek başlıkları için:

Bu satırlardan ikisi sistem tepsisindeki simgeden aynı görünür, bu yüzden simge burada mevcut en kötü kanıttır.

Önce ne bozulur ve nasıl görünür

Diğeri sağlıklıyken „Connecting“ durumunda takılan bir istemci neredeyse her zaman uç nokta açlığıdır: çalışan kill switch, ikinci istemcinin kendi sunucusuna giden el sıkışmasını düşürür. Bunu ucuza doğrulamak için ilk istemcinin engelleme kurallarını bir deneme boyunca duraklatın. İkinci hemen bağlanırsa soru yanıtlanmıştır.

DNS ikinci arızadır. İstemciler çözümleyici yapılandırmasını kendi arayüzleri için ayarlar ve bazıları küresel listeyi doğrudan üzerine yazar. İki tünel de açıkken sorgular bir taraftan çıkarken çözümleyici diğer tarafa ait olabilir. Uygulamalardan birini kapatın ve hayatta kalan erişilemez bir ad sunucusu tutar: sayfalar bir dakika takılır ve sonra yeniden çözülür, VPN ise hâlâ bağlı görünür.

Üçüncüsü rota dalgalanmasıdır. Yeniden bağlanmalar varsayılan yolu yeniden sıralar ve arayüze bağlı bir kill switch bunu izlemez. Bir an önce tünelin içinde olan trafik şimdi bir düşürme kuralına uyar; kullanıcı tarafında bu, rastgele çalışmayı bırakan bir VPN gibi okunur.

Gerçekte hangi politikanın yürürlükte olduğunu doğrulayın

Bunu zararsız trafikle yapın, eksikliğini çekeceğiniz bir şeyle değil.

Linux’ta çekirdeğe kimin kazandığını ve güvenlik duvarının neye bağlandığını sorun. ip -4 route show default çıkışa sahip tüneli adlandırır. ip rule show ilke tabanlı yönlendirmenin oyunda olup olmadığını gösterir. sudo nft list ruleset | grep -n oifname düşürmelerin bir arayüz adına, bir işarete mi yoksa tüm çıkış zincirine mi bağlı olduğunu gösterir.

Windows’ta aynı hikâye rota metriğinde ve filtre listesinde yaşar: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric ve Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS’ta netstat -rn -f inet | head -5 ve scutil --dns | head -20.

Sonra insanların atladığı adımı yapın: tüneli bilerek durdurun ve başarısız olmasını beklediğiniz trafiğin gerçekten başarısız olduğunu doğrulayın. Bağlı bir simge arayüz durumudur, uygulama değil.

İki istemci ne zaman yanlış tasarımdır

İkinci uygulamanın arkasındaki tek gereksinim daha fazla korumaysa onu kaldırın. Etkileşen iki engelleme politikası birden az öngörülebilirdir ve her yeniden bağlanma, hiçbir satıcının test etmediği bir duruma düşme şansıdır.

Gerçekten zincirleme gerekiyorsa, örneğin ticari bir atlama üzerinden erişilen bir kurumsal ağ geçidi, tek bir uygulama noktası olan bir tasarım seçin. Bu genellikle aynı varsayılan yol için yarışan iki masaüstü uygulaması değil, zinciri destekleyen bir yönlendirici veya tek bir istemci anlamına gelir. Yönetilen bir cihazda izin verilen istemciyi koruyun ve geri kalan her şeyi kapsam dışı sayın, tepside ne gösterirse göstersin.

Her ikisini de tutmadan önce kontrol listesi

Listeyi sırayla işleyin; başarısız olan ilk madde düzeltilmesi gerekendir.

• Varsayılan yolu ve çözümleyiciyi tam olarak bir istemcinin sahiplendiğini doğrulayın.
• İkinci istemci açık olsun istiyorsanız sunucusunun uç noktasına açıkça izin verin ve her istemci güncellemesinden sonra yeniden kontrol edin.
• Tünellerden biri düştüğünde beklenen sonucu yazın ve tam o durumu test edin.
• Yeniden başlatmadan sonra, başlatma sırası farklıyken hata yolunu kontrol edin.
• Yönetilen bir profilde durun ve bir şey eklemeden önce sahibine sorun.

Üçüncü adım başarısız olursa dürüst yanıt, size yalnızca bir istemcinin politika verdiğidir. Hangisine güvendiğinize karar verin ve diğerini bırakın.