VPN Android berjalan pada IPv6, tetapi pelayar masih memilih IPv4
Jejaki empat peringkat tempat alamat IPv6 peribadi hilang: penyelesai, pengisytiharan VpnService, semakan calon pelayar dan penghantaran laluan.
VPN aktif, antara muka web peribadi menjawab melalui IPv6 dari komputer riba, dan telefon Android masih membuka halaman yang sama melalui IPv4 atau enggan memuatkannya sama sekali. Rekod AAAA wujud. Terowong melaporkan alamat IPv6. Tiada apa yang kelihatan salah pada klien. Empat keputusan berasingan menentukan hasilnya: penyelesai mana yang menjawab, apa yang diisytiharkan VpnService kepada Android, keluarga alamat mana yang pelayar sanggup cuba, dan sama ada paket boleh membuat perjalanan pergi balik. Kerjakan mengikut urutan itu daripada menambah laluan lalai dan berharap simptom berpindah.
Langkah 1: buktikan penyelesai mana yang menjawab pertanyaan AAAA
Android tidak mempunyai satu laluan DNS. VPN boleh menolak pelayan DNS untuk rangkaiannya, sistem boleh menggunakan Private DNS untuk nama hos yang dianggapnya layak, dan Chrome boleh menjalankan penyelesainya yang disulitkan sendiri dari chrome://settings/security. Pada telefon yang terowongnya menolak 10.61.0.1 tetapi Private DNS menunjuk kepada penyedia awam, nama dalam zon peribadi anda tidak diselesaikan oleh mesin yang memiliki zon itu. Pelayar menerima jawapan daripada penyelesai tanpa kuasa ke atas nama itu dan menganggapnya tiada, dan teks ralat tidak pernah menyebut DNS.
Tanya penyelesai terowong secara langsung sebelum mengubah apa-apa lagi. Dua arahan pertama menunjukkan pelayan DNS mana yang dilampirkan Android pada rangkaian aktif dan sama ada Private DNS dalam mod automatik atau ketat; yang ketiga dijalankan dari mana-mana klien di dalam terowong, bukan dari telefon.
adb shell dumpsys connectivity | grep -A3 "DnsAddresses"
adb shell settings get global private_dns_mode
nslookup -type=AAAA nas.lan 10.61.0.1
Langkah 2: baca apa yang sebenarnya diisytiharkan VpnService
Sisi Android bersifat eksplisit, bukan disimpulkan. VpnService.Builder menambah alamat dengan addAddress, laluan dengan addRoute, pelayan DNS dengan addDnsServer, dan boleh mengehadkan seluruh terowong kepada satu keluarga alamat dengan allowFamily. Pembina yang memanggil allowFamily(AF_INET) dan kemudian menambah laluan IPv6 telah memberitahu sistem dua perkara yang bercanggah, dan sekatan keluarga itulah yang dikekalkan sistem. Laluan yang meliputi fd00:61::/64 digabungkan dengan alamat antara muka dalam awalan lain gagal atas sebab yang serupa: alamat itu wujud, tetapi ia bukan on-link untuk laluan tersebut.
Baca pengisytiharan itu daripada mempercayai togol dalam aplikasi. dumpsys netd mencetak alamat dan laluan yang dilampirkan pada antara muka tun, dan LinkProperties bagi setiap rangkaian dalam dumpsys connectivity menunjukkan senarai DNS di sebelah keluarga yang didakwa rangkaian.
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"
Jika antara muka tun mempunyai alamat IPv6 tetapi tiada laluan sepadan dengan awalan perkhidmatan, penghantaran IPv6 sudah rosak sebelum pelayar terlibat. Itu pepijat berbeza daripada pelayar yang enggan mencuba, dan ia memerlukan pembaikan yang berbeza.
Langkah 3: pelayar yang memutuskan sama ada hendak mencuba IPv6
Chromium tidak menggunakan setiap rekod AAAA yang diterimanya. Penyelesai hosnya membawa semakan kebolehsampaian IPv6 dan penapisan calon yang boleh menggugurkan atau merendahkan keutamaan IPv6 apabila rangkaian dinilai tidak mampu membawanya, dan sumber penyelesai menunjukkan kuar itu bersama syarat di sekelilingnya. Logiknya bergantung pada versi dan bendera, dan itulah sebabnya dua telefon pada terowong yang sama boleh berkelakuan berbeza. Sebaik sahaja calon wujud, Happy Eyeballs menyabungkan keluarga bagi setiap sambungan, jadi laluan IPv6 yang menjawab perlahan masih boleh kalah kepada IPv4 yang menjawab pantas.
Perhatikan keputusan itu daripada membuat andaian. Sesi yang dirakam melalui chrome://net-export dan dimainkan semula dalam pemapar netlog menunjukkan setiap penyelesaian dan keluarga yang dipilih; chrome://net-internals/#dns menunjukkan hasil yang dicache. Penyelesaian yang hanya mengembalikan rekod A untuk nama yang mempunyai AAAA pada penyelesai anda sendiri menunjuk terus ke peringkat ini.
Langkah 4: sahkan paket boleh membuat perjalanan pergi balik
Pemilihan alamat bukan penghantaran. Android menyimpan jadual penghalaan dan peraturan dasar bagi setiap rangkaian yang memilih jadual mengikut fwmark, jadi laluan yang kelihatan dalam jadual utama bukan semestinya laluan yang digunakan soket. Membaca peraturan dan meminta kernel menyelesaikan destinasi untuk alamat sumber memisahkan kedua-duanya.
adb shell ip -6 rule show
adb shell ip -6 route get fd00:61::20 from fd00:61::10
Keluaran route get itulah yang menjawab soalan. Jika ia menamakan tun0 tetapi paket masih mati, beralih kepada MTU terowong dan penghantaran ke hadapan IPv6 gerbang daripada kembali kepada telefon.
Mengapa menambah ::/0 biasanya memburukkan keadaan
Menambah ::/0 mengubah dakwaan terowong daripada satu awalan kepada setiap destinasi IPv6. Pada telefon itu boleh memenuhi kuar kebolehsampaian, kerana alamat ujian di luar awalan anda kini kelihatan boleh dihalakan. Ia tidak mencipta kapasiti huluan IPv6 pada gerbang, dan banyak gerbang rumah langsung tiada pautan atas IPv6 yang berfungsi. Hasilnya ialah lubang hitam untuk IPv6 awam: nama yang dahulu jatuh kembali ke IPv4 kini tergantung, dan halaman peribadi mungkin kelihatan lebih baik hanya kerana kuar itu mengukur sesuatu yang lain.
Ada juga kos dasar. Dengan ::/0 di dalam terowong, semua trafik IPv6 keluar melalui VPN, termasuk trafik yang pemilik rangkaian tidak pernah bersetuju untuk bawa. Perlakukan itu sebagai keputusan penggunaan dengan pemilik bernama, bukan langkah penyahpepijatan yang anda ambil pada pukul 1 pagi.
Urutan kerja yang menamatkannya
Sahkan jawapan AAAA datang daripada penyelesai yang memegang zon, baca keadaan VpnService dan netd untuk antara muka tun, ambil surih net-export untuk melihat sama ada Chromium menggugurkan calon itu, kemudian uji perjalanan pergi balik dengan ip -6 route get. Betulkan lapisan yang benar-benar gagal dan biarkan dasar pemisahan itu. Jika nama peribadi memerlukan jawapan berbeza daripada nama awam, itulah kegunaan split tunneling.
Catatkan build telefon, versi pelayar dan penyelesai yang anda tanyai. Ketiga-tiga fakta itu menjadikan "IPv6 is broken" sesuatu yang boleh dihasilkan semula oleh orang seterusnya.