Kill switch, herhangi bir trafik akmadan önce VPN sunucusunu bloklar
Kill switch hangi aşamayı blokluyor: uç nokta araması, dış rota, dönüş yolu ve eskimiş eş istisnaları — tahmin yerine sayaçlarla.
Kill switch'ler insanların beklemediği bir yönde başarısız olur: tünel kapalıyken trafiği bloklamak için yapılmışlardır ve tüneli kuran paketlerin kendisi trafiktir. Bütün hata budur. Tünelden çıkmayan her şeyi düşüren bir kural kümesi, tüneli ayağa kaldıracak el sıkışmayı da düşürür, bu yüzden istemci döngü içinde yeniden dener ve hata ilk denetlenen aşamaya yazılır. Güvenlik duvarını genişletmeden önce üç aşamadan hangisinin reddedildiğini bulun: ad araması, eşe giden dış paket veya geri dönen yanıt.
Tünel ve kendi taşıması birbirine nasıl bağlıdır
VPN istemcisini tek bir soket yolunu paylaşan iki ağ durumu olarak okuyun. Tünel var olmadan önce istemci fiziksel bağdaştırıcıda soket açar ve şifreli çerçeveleri eşin adresine ve bağlantı noktasına gönderir. Ancak bu değiş tokuş başarılı olduktan sonra tünel aygıtını oluşturur ve yolları kurar. Kill switch ikinci durumla ilgili bir politikadır ve her ikisine de uygulanacak kadar geniş yazılmıştır.
Arayüz tabanlı kurallar olağan biçimdir: şunun üzerinden çıkanı kabul edin: tun0 veya wg0, çıkış yolunun geri kalanını düşürün. Bu formülasyon istemcinin sunucuya kendi bağlantısını muaf tutamaz, bu yüzden doğru uygulama o istisnayı açıkça ekler, kuralları elle yazarken siz de öyle yaparsınız. Windows ve macOS'ta uygulama başına kurallar arayüz yerine süreç eşleştirerek bunun bir kısmından kaçınır, ama sürecin yine de tünel var olmadan önce dışarı çıkması gerekir.
Üç aşama, gerçekleşme sırasına göre
İlk aşama çözümlemedir. Profil gerçek adres yerine ana bilgisayar adı sakladığında istemcinin bir şey göndermeden önce DNS yanıtına ihtiyacı vardır. DNS'i tünelin çözümleyicisine yönlendiren bir profil çıkmaz sokak yaratır: çözümleyiciye yalnızca aramanın etkinleştirmesi gereken tünel üzerinden ulaşılır. Tünel dışında çözümlemek veya uç noktayı bir adrese sabitlemek bu belirsizliği kaldırır.
İkinci aşama dış pakettir ve bu sırayla önce yönlendirmeyi sonra güvenlik duvarını atlatmalıdır. wireguard-tools, WireGuard için bunun yönlendirme yarısını kendi paketlerini işaretleyip yeni kurduğu varsayılan rotayı atlamaları için bir politika kuralı ekleyerek halleder; wg-quick kılavuz sayfası o kuralı ve kullandığı tabloyu açıklar. Bu yönlendirmeyi elle yeniden kurun ya da ikinci bir aracın kuralları yeniden yazmasına izin verin; işaretli paketler oluşturmaları gereken tünele geri gönderilebilir.
Üçüncü aşama dönüş yoludur. Yanıtsız bir el sıkışma dışa doğru düşürmenin kanıtı değildir; sunucunun giriş kuralıyla veya eşlemeyi unutan bir NAT aygıtıyla da eşit derecede tutarlıdır. İstemciye dokunmadan önce bunları ayırın.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
İstemciler algıladıkları belirtiyi günlüğe yazar, başarısız olan aşamayı değil, bu yüzden tablo genellikle günlükten hızlıdır.
Sayaçlar günlüklerden daha hızlı karar verir
Linux'ta, nft list ruleset veya iptables -vnL OUTPUT her kural için bir paket sayacı basar. Bir kez bağlanın, başarısız olmasına izin verin, sonra sayaçları yeniden okuyun. Sayacı hareket eden kural, el sıkışmanın çarptığı kuraldır; hiçbir yerde hiçbir şey hareket etmediyse paket güvenlik duvarına hiç ulaşmadı. Bir kural kümesinin kendi el sıkışmasını düşürdüğünü gördüm ve bunu yalnızca sayaçlar söyledi.
Güvenlik duvarına hiç ulaşmadı ile ana bilgisayardan hiç çıkmadı durumlarını ayırmak için arayüzün kendisini izleyin. ip -s link show dev wlan0 gönderilen paketleri bildirir ve tcpdump -ni wlan0 udp port 51820 çerçeveleri gösterir. İstemci yeniden denerken düz kalıyorsa arıza netfilter'ın üstündedir: eksik eş rotası, henüz var olmayan bir aygıta işaret eden politika kuralı veya istemcinin yuttuğu bir soket hatası.
İstisnaları belge adreslerinde test edin, örneğin 203.0.113.10, böylece bir hata başkasının ana bilgisayarını yoklayamaz.
Eskimiş uç nokta istisnası sunucu kesintisi gibi okunur
En yanıltıcı sürüm, eşin adresi değiştikten sonra ortaya çıkar: dinamik adres hizmeti onu taşıdı, ana bilgisayar yeniden kuruldu veya ağınızın çıkış adresi farklı. İstisna hâlâ eski adresi adlandırıyor, bu yüzden yenisine giden paketler düşürme kuralına çarpar. Aynı yapılandırma dün çalışıyordu ve bu yüzden insanlar sunucuyu incelemekle başlar.
Güvenlik duvarı kuralı içindeki bir ana bilgisayar adı sizi kurtarmaz. nftables'ta ad, kural kümesi yüklendiğinde çözülür, bu yüzden o anda var olan adresi sabitler ve gerçek bir adres gibi eskir. Kalıcı çözüm, uç nokta değiştiğinde istisnayı güncellemek ve onu dar tutmaktır: bir eş adresi, bir taşıma bağlantı noktası. Adres değişikliğine dayanacak kadar geniş bir aralık, ilgisiz trafiği de dışarı bırakacak kadar geniştir.
Kill switch sunucu ana bilgisayarında çalıştığında
Aynı bağımlılık diğer uçta da vardır ve orada gözden kaçırmak daha kolaydır. VPN sunucunuz olarak hizmet eden makine aynı zamanda kill switch'li bir masaüstü istemcisi veya dizüstü bilgisayardan kopyalanmış bir güvenlik duvarı profili çalıştırıyorsa, düşürme kuralları tünelleri sonlandıran hizmete uygulanır. İstemcinin el sıkışmasına verilen yanıtlar düşürülür, bu yüzden sunucu sağlıklı görünürken ve tünel arayüzü kullanılmadan dururken her istemci bağlanamaz.
Bu ana bilgisayarın düşürmeden önce üç dar kabule ihtiyacı vardır: fiziksel arayüzdeki dinleme bağlantı noktası, şifresi çözülmüş trafik için tünel arayüzü ve tünelden istemcilerin ulaşması gereken yere yönlendirme. Kurulu kümeyi şununla okuyun: nft list ruleset, iptables -S, veya pfctl -sr herhangi bir şeyi değiştirmeden önce, ve kaydedilmiş bir kural kümesinin yeniden başlatmayı atlattığını unutmayın, bu yüzden oradaki hata onu yaratan süreçten daha uzun yaşar.
Makineyi kapalı tutan kurtarma sırası
Profilden dışa doğru çalışın. İstemcinin kullandığı eş adresini ve bağlantı noktasını okuyun, ana bilgisayar adının tünel olmadan çözüldüğünü doğrulayın, sonra yalnızca fiziksel bağdaştırıcıda o adres ve bağlantı noktası için bir istisna ekleyin. Yeniden bağlanın ve gönderme sayacını izleyin; tamamlanan el sıkışma ikinci aşamanın düzeltildiğinin işaretidir.
Test ederken düşürme politikasının geri kalanını yerinde bırakın. Zararsız bir kontrol, ilgisiz bir belge adresine bağlantı denemek ve hâlâ zaman aşımına uğradığını doğrulamaktır; bu, kill switch'in kapalı değil çalıştığını gösterir. Tünel kararlı olduğunda istisnayı sıkılaştırın ve sırf pratik diye istemci ikilisi için kalıcı bir her şeye izin kuralı bırakmayın.
Tünel açılıp uygulama hâlâ başarısız olursa, kalan aşamalar bu değildir: bölünmüş DNS, MTU ve uygulama başına yönlendirme her biri bozuk trafikli bağlı bir tünel üretir ve her birinin ilk kontrolü farklıdır.