Android VPN IPv6 işləyir, amma brauzer yenə IPv4 seçir

VPN işləyir, şəxsi veb interfeys noutbukdan IPv6 üzərindən cavab verir, Android telefon isə həmin səhifəni hələ də IPv4 üzərindən açır və ya ümumiyyətlə yükləməkdən imtina edir. AAAA qeydi mövcuddur. Tunel IPv6 ünvanı bildirir. Müştəridə heç nə səhv görünmür. Nəticəni dörd ayrı qərar müəyyən edir: hansı həlledicinin cavab verdiyi, VpnService-in Android-ə nə bildirdiyi, brauzerin hansı ünvan ailəsini sınamağa hazır olduğu və paketin gediş-dönüş edə bilib-bilmədiyi. Defolt marşrut əlavə edib simptomun yerini dəyişməsinə ümid etmək əvəzinə, onları bu sıra ilə işləyin.

Addım 1: AAAA sorğusuna hansı həlledicinin cavab verdiyini sübut edin

Android-də tək bir DNS yolu yoxdur. VPN öz şəbəkəsi üçün DNS serveri itələyə bilər, sistem uyğun hesab etdiyi host adları üçün Private DNS istifadə edə bilər, Chrome isə chrome://settings/security ünvanından öz şifrələnmiş həlledicisini işlədə bilər. Tunelin 10.61.0.1 itələdiyi, lakin Private DNS-in açıq provayderə yönəldiyi telefonda şəxsi zonanızdakı ad zonaya sahib olan maşın tərəfindən həll edilmir. Brauzer həmin ad üzərində səlahiyyəti olmayan həlledicidən cavab alır və onu itkin hesab edir, xəta mətnində isə DNS heç xatırlanmır.

Başqa heç nəyi dəyişməzdən əvvəl tunelin həlledicisindən birbaşa soruşun. İlk iki əmr Android-in aktiv şəbəkəyə hansı DNS serverlərini qoşduğunu və Private DNS-in avtomatik, yoxsa ciddi rejimdə olduğunu göstərir; üçüncüsü telefondan deyil, tunelin içindəki istənilən müştəridən işlədilir.

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

Addım 2: VpnService-in həqiqətən nə bildirdiyini oxuyun

Android tərəfi çıxarılan deyil, açıq şəkildə bildiriləndir. VpnService.Builder ünvanları addAddress ilə, marşrutları addRoute ilə, DNS serverlərini addDnsServer ilə əlavə edir və bütün tuneli allowFamily ilə bir ünvan ailəsi ilə məhdudlaşdıra bilər. allowFamily(AF_INET) çağırıb sonra IPv6 marşrutu əlavə edən qurucu sistemə iki zidd şey demişdir və sistemin saxladığı ailə məhdudiyyətidir. fd00:61::/64 əhatə edən marşrutun başqa prefiksdə olan interfeys ünvanı ilə birləşməsi də bənzər səbəbdən uğursuz olur: ünvan mövcuddur, lakin o marşrut üçün on-link deyil.

Tətbiqdəki açarı etibar etmək əvəzinə bəyannaməni oxuyun. dumpsys netd tun interfeysinə bağlı ünvanları və marşrutları çap edir, dumpsys connectivity daxilində hər şəbəkə üzrə LinkProperties isə DNS siyahısını şəbəkənin iddia etdiyi ailələrin yanında göstərir.

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 interfeysi IPv6 ünvanı daşıyır, lakin xidmət prefiksinə heç bir marşrut uyğun gəlmirsə, brauzer işə qarışmadan əvvəl IPv6 çatdırılması artıq pozulub. Bu, sınamaqdan imtina edən brauzerdən fərqli bir xətadır və fərqli düzəliş tələb edir.

Addım 3: IPv6-nı ümumiyyətlə sınamağı brauzer qərarlaşdırır

Chromium aldığı hər AAAA qeydini istifadə etmir. Onun host həlledicisi IPv6 əlçatanlıq yoxlamaları və namizəd filtrləməsi daşıyır ki, bunlar şəbəkə IPv6-nı daşımaq qabiliyyətində olmadıqda onu atə və ya prioritetini aşağı sala bilər, və həlledici mənbəyi həmin yoxlamanı ətrafındakı şərtlərlə birlikdə göstərir. Məntiq versiyadan və bayraqlardan asılıdır — iki telefonun eyni tuneldə fərqli davranmasının səbəbi də məhz budur. Namizədlər yarandıqdan sonra Happy Eyeballs hər bağlantı üzrə ailələri yarışdırır, buna görə yavaş cavab verən IPv6 yolu sürətli cavab verən IPv4-ə yenə də məğlub ola bilər.

Qərarı çıxarmaq əvəzinə onu izləyin. chrome://net-export vasitəsilə qeydə alınan və netlog görüntüləyicisində təkrar oxudulan sessiya hər həlli və seçilmiş ailəni göstərir; chrome://net-internals/#dns keşlənmiş nəticələri göstərir. Öz həlledicinizdə AAAA olan ad üçün yalnız A qeydləri qaytaran həll birbaşa bu mərhələyə işarə edir.

Addım 4: paketin gediş-dönüş edə bildiyini yoxlayın

Ünvan seçimi çatdırılma deyil. Android hər şəbəkə üzrə marşrut cədvəlləri və fwmark ilə cədvəl seçən siyasət qaydaları saxlayır, buna görə əsas cədvəldə görünən marşrut avtomatik olaraq soketin istifadə etdiyi marşrut deyil. Qaydaları oxumaq və kerneldən mənbə ünvanı üçün təyinatı həll etməyi xahiş etmək bu ikisini ayırır.

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

route get çıxışı suala cavab verən çıxışdır. tun0 adlandırırsa və paketlər hələ də ölürsə, telefona qayıtmaq əvəzinə tunel MTU-suna və gateway-in IPv6 yönləndirməsinə keçin.

::/0 əlavə etmək niyə adətən vəziyyəti pisləşdirir

::/0 əlavə etmək tunelin iddiasını bir prefiksdən hər IPv6 təyinatına dəyişir. Telefonda bu, əlçatanlıq yoxlamasını təmin edə bilər, çünki prefiksinizdən kənarda olan test ünvanı artıq marşrutlaşdırıla bilən görünür. Bu, gateway-də IPv6 yuxarı axın tutumu yaratmır və bir çox ev gateway-ində ümumiyyətlə işləyən IPv6 yuxarı axını yoxdur. Nəticə açıq IPv6 üçün qara dəlikdir: əvvəllər IPv4-ə düşən adlar indi asılı qalır və şəxsi səhifə yalnız yoxlamanın başqa bir şeyi ölçdüyü üçün daha yaxşı görünə bilər.

Siyasət xərci də var. Tuneldə ::/0 olduqda bütün IPv6 trafiki VPN-dən çıxır, o cümlədən şəbəkə sahibinin daşımağa heç vaxt razılaşmadığı trafik. Bunu gecə saat 1-də verdiyiniz sazlama addımı kimi deyil, adı çəkilmiş sahibi olan yerləşdirmə qərarı kimi qəbul edin.

Bunu bitirən iş sırası

AAAA cavabının zonaya sahib həlledicidən gəldiyini təsdiqləyin, tun interfeysi üçün VpnService və netd vəziyyətini oxuyun, Chromium namizədi atıb-atmadığını görmək üçün net-export izi çəkin, sonra gediş-dönüşü ip -6 route get ilə yoxlayın. Həqiqətən uğursuz olan qatı düzəldin və split siyasətinə toxunmayın. Şəxsi adlar açıq adlardan fərqli cavab tələb edirsə, split tunneling məhz bunun üçündür.

Telefonun buraxılışını, brauzerin versiyasını və sorğu verdiyiniz həllediciyi qeyd edin. Bu üç fakt "IPv6 is broken" ifadəsini növbəti şəxsin təkrarlaya biləcəyi bir şeyə çevirir.