Kapatma betiği mi güvenlik duvarı kuralı mı: sızıntıyı hangisi durdurur?
Bağlantı kesilirken arayüzleri indirmek kaba bir yöntemdir ve çoğu zaman yetkisiz çalışır. Düşüşten sonra da geçerli kalan ve boşluğu kapatan bir güvenlik duvarı kuralıyla karşılaştırın.
İki tasarım aynı şeyi vaat eder: tünel düştüğünde hiçbir şey açık biçimde dışarı çıkmaz. Biri kapatma sırasında bir betik çalıştırıp arayüzleri keser. Diğeri güvenlik duvarı kuralını yürürlükte bırakır ve VPN istemcisinden hiçbir şey istemez. Kimin eyleme geçme yetkisi olduğu, boşluk sırasında ne olduğu ve makinenin sonrasında nasıl yeniden çevrimiçi olduğu bakımından ayrılırlar. Onları bu üç noktada karşılaştırmak hangisinin daha katı olduğunu tartışmaktan daha faydalıdır.
Aynı iş, iki mekanizmayla
İstemci, profil betik çalıştırmaya izin veriyorsa tünel kalkarken ve indirilirken kancalar çalıştırabilir. Bu kanca istemcinin yaşam döngüsü içinde, bağlantının kapandığı anda çalışır. Güvenlik duvarı kuralı ise sisteme aittir ve istemcinin çalışıp çalışmadığını, çöküp çökmediğini ya da öldürülüp öldürülmediğini umursamaz.
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
O tablo bütün argümandır. Yalnızca düzgün kapanışta çalışan bir betik, sizi en az endişelendiren durumu kapsar; önemli olan durum çökme ya da ağın kaybolmasıdır ve ikisi de temiz bir indirme sağlamaz.
İndirme kancasının yapabildikleri ve yapamadıkları
Belgelenen desen ağ arayüzlerini dolaşır ve loopback dışındaki her şeyi indirir. Fiziksel aygıt indirildiğinde tünelin dışına hiçbir şey kaçamaz ve amaç tam olarak budur.
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
done
Ayrıca yerel ağı, makinenin barındırdığı her hizmeti ve sorunu düzeltmek için kullanacağınız yolu da indirir. Dizüstü bilgisayarda kablosuz aygıt bazen sonradan elle değiştirilmeyi gerektirir, böylece kısa bir kesinti onarım oturumuna dönüşür. Daha kötüsü, kancaya bunların hiçbirini yapma izni verilmeyebilir: istemci yetkileri bıraktığında indirme betiği yetkisiz hesapta çalışır ve her arayüz değişikliği, kimsenin günlüğü okumadığı anda yazılan bir izin hatasıyla başarısız olur.
Kancaya güvenmeden önce istemcinin nasıl başlatıldığını denetleyin. root olarak elle çalıştırıldığında çalışan bir betik, açılışta başlayan hizmet hakkında hiçbir şey kanıtlamaz.
Güvenlik duvarı kuralı neyi farklı yapar
Yalnızca tünel trafiğine izin veren bir kural, istemci süreci ortadan kalktığında çalışmaya devam eder, çünkü çekirdek o sürece bağlı değildir. Kural aynı zamanda daha dardır: yalnızca eşleştiği akışları engeller ve loopback, yerel alt ağ ile kurtarma yolunu kendi hâline bırakır, bu yüzden makineyi çıkmazda bırakmaz.
Bedel, kuralın ana makinenin güvenlik duvarına sahip olan kişi tarafından yazılması ve sürdürülmesi gerektiğidir ve kural istemcinin gerçekten oluşturduğu tünel aygıtını adlandırmalıdır. Bu, kural ile profilin birlikte sürdürülmesi gerektiği anlamına gelir; yeniden adlandırılmış bir arayüz her şeyi engelleyen ve hiçbir şey açıklamayan bir güvenlik duvarı bırakır.
Hiçbir mekanizma diğerini gereksiz kılmaz. Düzenlemeden sonra hiç yeniden yüklenmeyen bir güvenlik duvarı kuralı, hiç çalışmayan bir betik kadar hayalidir.
Boşluk olup olmadığına persist-tun karar verir
Tünel aygıtı bir bağlantı kesintisini atlattığında ona giden yollar da atlatır. Trafik o zaman yönlendirilmek yerine düşürülür, böylece varsayılan yol fiziksel ağ geçidine geri dönmez. Sızıntıyı herhangi bir güvenlik duvarı kuralı devreye girmeden önce bile olasılık dışı bırakan davranış budur.
Bu ayar olmadan aygıt yollarla birlikte kaldırılır ve varsayılan yol yeniden fiziksel ağ geçidini gösterebilir. Bunu yapıp yapmayacağı platforma ve istemciye bağlıdır ve tam da bu yüzden durum varsayılmak yerine gözlemlenmelidir. Ayarı kill switch'in parçası olarak görün, performans seçeneği olarak değil.
Yeniden bağlanma yolunu canlı tutun, sonra dört durumu sınayın
Katı bir engelleme istemcinin yeniden bağlanmasını da önleyebilir, çünkü geri kalan her şey reddedilirken istemcinin fiziksel ağ geçidi üzerinden sunucuya bir yola hâlâ ihtiyacı vardır. Tünel kalkmadan önce o tek adres için bir ana makine yolu kurun ve önce adı çözün, çünkü ihtiyaç duyduğunuzda DNS engellenmiş olabilir.
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0
Sonra etiketi değil durumları doğrulayın. Dört anı bilerek yaşayın: tünelsiz soğuk başlangıç, sağlıklı oturum, kimsenin istemediği bir düşüş ve toparlandıktan sonraki oturum. Her anda varsayılan yolu okuyun ve çıkış adresi görünen bir istek yapın. Tünel aşağıdayken pes eden bir uygulama, bir e-posta istemcisi ya da güncelleyici hakkında hiçbir şey söylemez, bu yüzden son denetimi tek bir arka plan uygulamasıyla yineleyin. Kuralı, arayüz adlarını ve kurtarma adımlarını yazın, çünkü kimsenin doğrulayamadığı bir kill switch yalnızca söylentidir.