Acil durdurma anahtarı yalnızca IPv4'ü engeller: IPv6 neden hâlâ dışarı çıkıyor

Tünel düşer, acil durdurma anahtarı devreye girdiğini bildirir ve bir indirme devam eder. IPv4 kurallarında hiçbir şey bozuk değildir. Uygulama yalnızca o kuralların hiçbir zaman yazılmadığı bir yola geçmiştir.

Çift yığınlı cihazların iki bağımsız çıkışı vardır. Bunlardan birini engellemek yarım engellemedir.

İki kural kümesi, iki varsayılan

Linux'ta iptables ve ip6tables ayrı politikalara sahip ayrı tablolardır. IPv4 tablosunun INPUT ve OUTPUT zincirlerini DROP'a ayarlamak, varsayılanı genellikle ACCEPT olan IPv6 tablosunda hiçbir şeyi değiştirmez. Aynı ayrım nftables'ta da vardır; orada bir aileyi inceleyip kurallarınızı yalnızca birinin taşıdığını görebilirsiniz. Bu asimetri normaldir ve bütün sorun da budur.

Bu yüzden bir acil durdurma anahtarı eksiksiz görünüp kısmen davranabilir. IPv4 kurallarını yazan betik çalıştı, sayaçlar artıyor, günlük satırı görünüyor ve bir IPv6 paketi fiziksel arayüzden tamamen dokunulmadan çıkıyor.

İstemcinizin gerçekte ne kurduğunu okuyun, pazarlama sayfasının ne vaat ettiğini değil. Bazı istemciler IPv6'yı tünele yönlendirir, bazıları bilerek engeller, bazıları ise platform düzeyindeki bir kilit başka bir kural uygularken onu olduğu gibi bırakır. Burada güvenilecek tek kaynak satıcının belgeleridir.

Arayüz yapılandırması size ne söyler

wg-quick'in kılavuz sayfası örnek yapılandırmasında IPv6 kuralları içerir ve nedeni tam olarak bu boşluktur. Örnek süs değildir. Yalnızca IPv4 kuralları ikinci aileyi açık bırakacağı için vardır.

Bir örneğin yarısını kopyalamak, bir politikanın yarısını üretir. Bu, bu sızıntının en yaygın kaynağıdır. Bir blog yazısı örneği uzunluk nedeniyle kısalttı. Kısaltılmış sürüm daha sonra herkesin yeniden kullandığı şablon oldu.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

İkinci komut izin veren bir politika yazdırırken birincisi DROP yazdırıyorsa, istemciye dokunmadan cevabı buldunuz. Bu asimetri hatadır.

Tek bir aramanın tüm hikâye olmamasının nedeni

Tek bir ad hem A kaydı hem de AAAA kaydı döndürebilir ve uygulamaların hepsi aynı şekilde seçmez. Bir tarayıcı ağ sunduğunda IPv6'yı tercih edip başarısızlıkta geri dönebilirken, arka plan eşitlemesi veya güncelleyici kendi çözümleyicisini ve kendi tercihini kullanır. Bu nedenle IPv4 üzerinden tek bir başarılı test tek bir yolu kanıtlar, politikayı değil.

Ağ geçişleri de yanıtı değiştirir. Başka bir Wi-Fi ağına katılmak, uykudan uyanmak veya hücresele geçmek cihaza yeni bir IPv6 öneki verebilir ve ofis LAN'ında yeterli görünen politika bunu kapsamayabilir.

Tünelin kapalı olduğu durumu test edin

Bağlıyken test etmek tünelin çalıştığını söyler. İlginç test, kullanılamaz durumdur, çünkü o zaman acil durdurma anahtarının tutması gerekir. Tüneli bilerek durdurun, ardından koruduğunuz uygulamadan önemli hedefleri deneyin.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Her iki aile de kapalı biçimde başarısız olmalıdır. IPv4 isteği zaman aşımına uğrar ve IPv6 isteği bir durum kodu döndürürse, politika eksiktir ve tüneli ne kadar yeniden test etseniz de bu değişmez.

O testte belgelenmiş istisnaları da koruyun. Yerel ağ keşfi, bir DHCP yenilemesi veya VPN uç noktasına giden önyükleme yolu erişilebilir kalmalı olabilir ve bu istisnalar bir kesinti sırasında keşfedilmek yerine politikada adlandırılmalıdır. Tünel geri gelemediği için başarısız olan bir sızıntı testi güvenlik bulgusu değil, bağlantı bulgusudur.