Android VPN IPv6 ile çalışıyor ama tarayıcı hâlâ IPv4 seçiyor

VPN açık, özel web arayüzü dizüstü bilgisayardan IPv6 üzerinden yanıt veriyor, ama Android telefon aynı sayfayı hâlâ IPv4 üzerinden açıyor ya da hiç yüklemiyor. AAAA kaydı var. Tünel bir IPv6 adresi bildiriyor. İstemcide yanlış görünen bir şey yok. Sonucu dört ayrı karar belirliyor: hangi çözümleyici yanıt verdi, VpnService Android'e ne bildirdi, tarayıcı hangi adres ailesini denemeye hazırdı ve bir paket gidiş-dönüş yolculuğunu tamamlayabiliyor mu. Varsayılan bir rota ekleyip belirtinin yer değiştirmesini ummak yerine bunları bu sırayla ele alın.

Adım 1: AAAA sorgusuna hangi çözümleyicinin yanıt verdiğini kanıtlayın

Android'in tek bir DNS yolu yok. Bir VPN kendi ağı için DNS sunucusu itebilir, sistem uygun gördüğü ana makine adları için Private DNS kullanabilir ve Chrome chrome://settings/security adresinden kendi şifreli çözümleyicisini çalıştırabilir. Tünelin 10.61.0.1 ittiği ama Private DNS'in bir genel sağlayıcıyı gösterdiği bir telefonda, özel bölgenizdeki adı o bölgeye sahip makine çözmez. Tarayıcı o ad üzerinde yetkisi olmayan bir çözümleyiciden yanıt alır ve onu yok sayar, hata metni ise DNS'ten hiç söz etmez.

Başka bir şeyi değiştirmeden önce tünelin çözümleyicisine doğrudan sorun. İlk iki komut Android'in etkin ağa hangi DNS sunucularını bağladığını ve Private DNS'in otomatik mi yoksa katı modda mı olduğunu gösterir; üçüncüsü telefondan değil, tünelin içindeki herhangi bir istemciden çalıştırılır.

adb shell dumpsys connectivity | grep -A3 "DnsAddresses"
adb shell settings get global private_dns_mode
nslookup -type=AAAA nas.lan 10.61.0.1

Adım 2: VpnService'in gerçekte ne bildirdiğini okuyun

Android tarafı çıkarım değil, açıktır. VpnService.Builder addAddress ile adres, addRoute ile rota, addDnsServer ile DNS sunucusu ekler ve allowFamily ile tüm tüneli tek bir adres ailesine kısıtlayabilir. allowFamily(AF_INET) çağırıp sonra bir IPv6 rotası ekleyen oluşturucu sisteme birbiriyle çelişen iki şey söylemiştir ve sistemin koruduğu şey aile kısıtlamasıdır. fd00:61::/64 kapsayan bir rota ile başka bir ön ekteki arayüz adresinin birleşmesi de benzer nedenle başarısız olur: adres vardır ama o rota için on-link değildir.

Uygulamadaki anahtara güvenmek yerine bildirimi okuyun. dumpsys netd tun arayüzüne bağlı adresleri ve rotaları yazdırır, dumpsys connectivity içindeki ağ başına LinkProperties ise DNS listesini ağın iddia ettiği ailelerin yanında gösterir.

adb shell ip -6 addr show tun0
adb shell ip -6 route show table all | grep tun0
adb shell dumpsys connectivity | grep -E "LinkAddresses|Routes"

tun arayüzünde IPv6 adresi varsa ama hizmetin ön ekiyle eşleşen bir rota yoksa, tarayıcı devreye girmeden IPv6 teslimi zaten bozulmuştur. Bu, denemeyi reddeden bir tarayıcıdan farklı bir hatadır ve farklı bir düzeltme gerektirir.

Adım 3: IPv6'yı denemeye karar veren tarayıcıdır

Chromium aldığı her AAAA kaydını kullanmaz. Ana makine çözümleyicisi, ağ IPv6'yı taşıyamaz sayıldığında onu düşürebilecek veya önceliğini azaltabilecek IPv6 erişilebilirlik denetimleri ve aday süzme taşır ve çözümleyici kaynak kodu bu sınamayı çevresindeki koşullarla birlikte gösterir. Mantık sürüme ve bayraklara bağlıdır, aynı tüneldeki iki telefonun farklı davranmasının nedeni tam olarak budur. Adaylar oluştuktan sonra Happy Eyeballs bağlantı başına aileleri yarıştırır, bu yüzden yavaş yanıt veren bir IPv6 yolu hızlı yanıt veren IPv4'e karşı hâlâ kaybedebilir.

Kararı çıkarsamak yerine gözleyin. chrome://net-export ile kaydedilip netlog görüntüleyicide yeniden oynatılan bir oturum her çözümü ve seçilen aileyi gösterir; chrome://net-internals/#dns önbelleğe alınmış sonuçları gösterir. Kendi çözümleyicinizde AAAA'sı olan bir ad için yalnızca A kaydı döndüren bir çözüm doğrudan bu aşamaya işaret eder.

Adım 4: paketin gidiş-dönüş yolculuğunu tamamlayabildiğini doğrulayın

Adres seçimi teslim değildir. Android ağ başına yönlendirme tabloları ve fwmark ile tablo seçen ilke kuralları tutar, bu yüzden ana tabloda görünen bir rota otomatik olarak soketin kullandığı rota değildir. Kuralları okumak ve çekirdekten kaynak adres için hedefi çözmesini istemek bu ikisini ayırır.

adb shell ip -6 rule show
adb shell ip -6 route get fd00:61::20 from fd00:61::10

Soruyu yanıtlayan route get çıktısıdır. tun0 diyorsa ve paketler ölmeye devam ediyorsa telefondan geri dönmek yerine tünelin MTU'suna ve geçidin IPv6 yönlendirmesine geçin.

Neden ::/0 eklemek genellikle durumu kötüleştirir

::/0 eklemek tünelin iddiasını tek bir ön ekten her IPv6 hedefine değiştirir. Telefonda bu bir erişilebilirlik sınamasını karşılayabilir, çünkü ön ekinizin dışındaki bir test adresi artık yönlendirilebilir görünür. Ancak geçitte IPv6 yukarı akım kapasitesi yaratmaz ve birçok ev geçidinde çalışan bir IPv6 yukarı bağlantısı hiç yoktur. Sonuç, genel IPv6 için bir kara deliktir: eskiden IPv4'e düşen adlar artık askıda kalır ve özel sayfa daha iyi görünebilir çünkü sınama başka bir şeyi ölçmektedir.

Bir ilke maliyeti de var. Tünelde ::/0 varken tüm IPv6 trafiği VPN'den çıkar, ağ sahibinin taşımayı hiç kabul etmediği trafik dahil. Bunu adı konmuş bir sahibi olan bir kurulum kararı olarak ele alın, gece 1'de aldığınız bir hata ayıklama adımı olarak değil.

Bunu bitiren çalışma sırası

AAAA yanıtının bölgeye sahip çözümleyiciden geldiğini doğrulayın, tun arayüzü için VpnService ve netd durumunu okuyun, Chromium'un adayı düşürüp düşürmediğini görmek için bir net-export izi alın ve ardından gidiş-dönüşü ip -6 route get ile sınayın. Gerçekten başarısız olan katmanı düzeltin ve bölme ilkesine dokunmayın. Özel adlar genel adlardan farklı yanıt gerektiriyorsa split tunneling tam bunun içindir.

Telefonun yapısını, tarayıcı sürümünü ve sorguladığınız çözümleyiciyi not edin. Bu üç olgu "IPv6 is broken" ifadesini bir sonraki kişinin yeniden üretebileceği bir şeye dönüştürür.