VPN sızıntısını düzeltmek için IPv6 kapatılsın mı? Bunun yerine politikayı belirleyin

IPv6 aralığından bir adres test sayfasında görünüyor, tünel onu açıkça taşımıyor ve internetteki en popüler tavsiye IPv6'yı her yerde kapatmak. Bu komut paneli gerçekten susturuyor. Ancak erişim ağının bağlı olabileceği bir protokolü de kaldırıyor ve adresin gerçek bir sızıntı mı, bir link-local arayüz adresi mi yoksa işini yapan bir çözümleyici mi olduğunu bilmeden sizi bırakıyor. Doğru kontrolü üç koşul belirler ve bunlardan yalnızca biri engellemeye götürür.

Aracın gerçekte neyi ölçtüğünü belirleyin

En yaygın yanlış alarm, fe80: ile başlayan ve makinenin IPv6 üzerinden internete ulaşıp ulaşmadığına bakılmaksızın IPv6 yetenekli her arayüzde bulunan link-local adrestir. Arayüz listelerinde ve bazı uygulama tanılamalarında görünür ve trafik yolunuz hakkında hiçbir şey söylemez.

İkinci yanlış alarm, fc00::/7 içindeki benzersiz yerel adrestir; bu, ağ içinde kullanılan özel bir aralıktır. Ana makinenin sahip olduğu her adresi yazdıran bir araç onu memnuniyetle genel adresin yanına listeler. Hızlı okuyan biri buna sızıntı der ve sonra var olmayan bir sorunla bir saat geçirir.

Üçüncüsü hiç de yanlış alarm değildir. Tünelin dışında internete ulaşan genel adres gerçek sızıntıdır ve herhangi bir karar vermeden önce onu ölçmeye değer:

ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co

İlk komut genel bir adres yazdırırsa ve üçüncüsü tünelin olmayan genel bir IPv6 adresi döndürürse, tünelin dışında gerçek bir yolunuz var. Birincisi link-local girdilerden başka bir şey yazdırmıyorsa, düzeltilecek bir sızıntı hiç olmamıştır.

Kontrolü üç koşul belirler

Karar "IPv6 iyi" ya da "IPv6 kötü" değildir. Karar, üç durumdan hangisinde olduğunuzdur ve her birinin doğru yanıtı farklıdır, yanılırsanız bedeli de farklıdır.

İlk satır insanların genellikle kastettiği şeydir ve meşrudur. Çıkışı IPv6 desteklemeyen bir istemci, ana makinenin kendi IPv6 trafiğini sessizce dışarı bırakmamalıdır, çünkü bu belgelenmiş çift yığın sızıntısıdır. Mesele bunu ilan edilmiş bir politika olarak engellemek, çekirdekte bir protokolü kapatmak değildir. Görünen sonuç aynıdır ve yalnızca biri daha sonra gözden geçirilebilir.

Üçüncü satır, genel tavsiyenin etkin biçimde zararlı hale geldiği yerdir. Mobil operatörler ve bazı ev bağlantıları IPv4 hedefleri için çeviri ile IPv6-only ağlar işletir. Orada IPv6'yı kaldırırsanız ağın sunduğu tek taşımayı kaldırırsınız, bu da ayıkladığınız arızadan çok daha kötü bir kesinti üretir.

Çıkışta IPv6 yoksa bilerek engelleyin

İstemcinin kendi mekanizmasını tercih edin, çünkü tam olarak tünel ayaktayken uygulanır ve düştüğünde geri alınır. OpenVPN bunun için bir seçeneğe sahiptir ve iptables diğer istemciler için eşdeğer bir kurala sahiptir:

block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable

Direktif profile aittir; kural, gözden geçirip kaldırabileceğiniz bir güvenlik duvarına aittir. İkisi de kapalı olarak başarısız olur, istediğiniz budur ve ikisi de yapılandırma farkında görünür, bir başlangıç betiğine gömülmüş çekirdek sysctl'i görünmez.

Neden orada olduğunu kaydedin. Yorumu olmayan bir engelleme kuralını IPv6'yı başka bir şey için gereksinen bir sonraki kişi kaldırır ve sonra sızıntı sessizce geri döner.

Çıkış IPv6 taşıyorsa yönlendirin ve iki aileyi de test edin

Sunucu destekliyorsa IPv6 taşımak daha iyi yanıttır ve çok daha zor değildir. Gereksinim, tünel arayüzünün o ailede bir adrese sahip olması ve onun varsayılan rotasının fiziksel arayüzün dışına değil tünelin içine işaret etmesidir:

ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.co

Rota sorgusu belirleyici testtir: tünel arayüzünü adlandırıyorsa IPv6 trafiği taşınıyor demektir. Ardından iki curl çağrısı her ailenin ne gördüğünü doğrular ve bunları karşılaştırmak, iki yolun artık aynı çıkıştan ayrıldığını kanıtlamanın yoludur.

Başarılı bir bağlantıda durmayın. Tüneli yeniden bağlayın ve tekrar kontrol edin, çünkü sunucu yalnızca başlangıç yapılandırmasında gönderiyorsa itilen IPv6 rotası yeniden kurulumda kaybolabilir. Ardından dışlanan bir hedefi kontrol edin, çünkü bölünmüş tünel kuralları iki ailenin en sık ayrıştığı yerdir.

Erişim ağı yalnızca IPv6 ise dokunmayın

Bazı ağlar yalnızca IPv6 sağlar ve cihazın IPv4 hizmetlerine operatör tarafındaki bir çeviri mekanizmasıyla ulaşmasını bekler. Böyle bir makinede IPv6'yı kapatmak güvenlik iyileştirmesi değildir; herhangi bir şeye giden tek yolu kaldırır. Bu, kimsenin ihtiyaç duymadığı bir test sonucu uğruna kendi kendinize açtığınız bir kesintidir.

Bu hatanın belirtisi belirgin ve nahoştur: tünel kuruluyor gibi görünür, ad çözümlemesi çalışır ve hiçbir şey yüklenmez. Bunu bir IPv6 değişikliğinden sonra görürseniz ayarı hemen geri yükleyin ve tanılamaya başka bir yerde devam edin.

Ne seçerseniz seçin, kararı profilde veya güvenlik duvarında açık tutun, çıkışın gerçekte neyi desteklediğine bağlayın ve RFC 7359 çift yığın tartışması nın betimlediği çift yığın davranışını not edin. İlan edilmiş bir engelleme politikadır. Kapatılmış bir protokol, kimsenin denetleyemeyeceği bir dolambaçlı yoldur ve test sayfasından ikisi de aynı görünür.