VPN күйүк, жеке веб интерфейс ноутбуктан IPv6 аркылуу жооп берет, ал эми Android телефон ошол эле баракты дагы эле IPv4 аркылуу ачат же аны жүктөөдөн баш тартат. AAAA жазуусу бар. Туннель IPv6 дарегин билдирет. Кардарда эч нерсе туура эмес көрүнбөйт. Жыйынтыкты төрт өзүнчө чечим аныктайт: кайсы чечүүчү жооп берди, VpnService Androidге эмнени жарыялады, браузер кайсы даректер үй-бүлөсүн сынап көрүүгө даяр болду жана пакет барып-кайта алабы. Демейки маршрут кошуп, белгинин жылышына үмүт кылуунун ордуна ушул тартипте иштеңиз.

1-кадам: AAAA суроосуна кайсы чечүүчү жооп бергенин далилдеңиз

Androidде DNSтин бир жолу жок. VPN өз тармагы үчүн DNS серверин түртүп жибере алат, система ылайыктуу деп эсептеген хост аттары үчүн Private DNS колдоно алат, ал эми Chrome chrome://settings/security дарегинен өзүнүн шифрленген чечүүчүсүн иштете алат. Туннель 10.61.0.1 түртүп, бирок Private DNS коомдук провайдерди көрсөткөн телефондо жеке аймагыңыздагы атты ошол аймакка ээ машина чечпейт. Браузер ошол атка ыйгарым укугу жок чечүүчүдөн жооп алып, аны жок деп эсептейт, ал эми ката текстинде DNS эч качан аталбайт.

Башка нерсени өзгөртүүдөн мурун туннелдин чечүүчүсүнөн түз сураңыз. Алгачкы эки буйрук Android активдүү тармакка кайсы DNS серверлерин кошконун жана Private DNS автоматтык же катуу режимде экенин көрсөтөт; үчүнчүсү телефондон эмес, туннелдин ичиндеги каалаган кардардан иштейт.

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

2-кадам: VpnService чындыгында эмнени жарыялаганын окуңуз

Android тарабы божомол эмес, ачык. VpnService.Builder addAddress аркылуу даректерди, addRoute аркылуу маршруттарды, addDnsServer аркылуу DNS серверлерин кошот жана allowFamily аркылуу бүт туннелди бир даректер үй-бүлөсү менен чектей алат. allowFamily(AF_INET) чакырып, кийин IPv6 маршрутун кошкон куруучу системага эки карама-каршы нерсе айтты, ал эми система үй-бүлө чектөөсүн сактайт. fd00:61::/64 камтыган маршрут башка префикстеги интерфейс дареги менен кошулганда ушундай эле себептен ишке ашпайт: дарек бар, бирок ал ошол маршрут үчүн on-link эмес.

Колдонмодогу которгучка ишенүүнүн ордуна декларацияны окуңуз. dumpsys netd tun интерфейсине тиркелген даректерди жана маршруттарды басып чыгарат, ал эми dumpsys connectivity ичиндеги тармак боюнча LinkProperties DNS тизмесин тармак жарыялаган үй-бүлөлөрдүн жанында көрсөтөт.

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 интерфейсинде IPv6 дареги бар, бирок кызматтын префиксине эч бир маршрут дал келбесе, браузер кийлигишээрден мурун эле IPv6 жеткирүү бузулган. Бул сынап көрүүдөн баш тарткан браузерден башка ката жана башка түзөтүүнү талап кылат.

3-кадам: IPv6ны таптакыр сынап көрүүнү браузер чечет

Chromium алган ар бир AAAA жазуусун колдонбойт. Анын хост чечүүчүсүндө IPv6 жеткиликтүүлүгүн текшерүү жана талапкерлерди чыпкалоо бар, алар тармак аны ташууга жөндөмсүз деп бааланса, IPv6ны таштап салышы же артыкчылыгын төмөндөтүшү мүмкүн, ал эми чечүүчүнүн баштапкы коду ошол текшерүүнү айланасындагы шарттар менен көрсөтөт. Логика версияга жана флагларга көз каранды, ошондуктан бир туннелдеги эки телефон башкача жүрүшү мүмкүн. Талапкерлер пайда болгондон кийин Happy Eyeballs ар бир туташуу үчүн үй-бүлөлөрдү жарыштырат, ошондуктан жай жооп берген IPv6 жолу тез жооп берген IPv4гө утулушу мүмкүн.

Чечимди божомолдобой, байкаңыз. chrome://net-export аркылуу жазылган жана netlog көрүүчүсүндө кайра ойнотулган сессия ар бир чечүүнү жана тандалган үй-бүлөнү көрсөтөт; chrome://net-internals/#dns кэштеги жыйынтыктарды көрсөтөт. Өз чечүүчүңүздө AAAA бар ат үчүн гана A жазууларын кайтарган чечүү ушул баскычты түз көрсөтөт.

4-кадам: пакет барып-кайта аларын текшериңиз

Даректи тандоо жеткирүү эмес. Android тармак боюнча маршруттоо таблицаларын жана саясат эрежелерин кармайт, алар таблицаны fwmark боюнча тандашат, ошондуктан негизги таблицада көрүнгөн маршрут сокет колдонгон маршрут экенине кепилдик жок. Эрежелерди окуу жана ядродон булак дареги үчүн барар жерди чечүүнү суроо ушул экөөнү ажыратат.

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

Суроого route get чыгарылышы жооп берет. Эгер ал tun0 деп көрсөтсө, ал эми пакеттер дагы эле өлүп жатса, телефонго кайтуунун ордуна туннелдин MTUсуна жана шлюздун IPv6 багыттоосуна өтүңүз.

::/0 кошуу эмнеге көбүнчө абалды начарлатат

::/0 кошуу туннелдин талабын бир префикстен ар бир IPv6 барар жерине өзгөртөт. Телефондо бул жеткиликтүүлүк текшерүүсүн канааттандырышы мүмкүн, анткени префиксиңизден сырттагы сыноо дареги эми маршрутталгандай көрүнөт. Бирок бул шлюзде IPv6нын жогорку агым сыйымдуулугун жаратпайт, ал эми көптөгөн үй шлюздөрүндө такыр иштеген IPv6 жогорку каналы жок. Жыйынтык коомдук IPv6 үчүн кара көңдөй: мурун IPv4гө түшкөн аттар эми илинип калат, ал эми жеке барак текшерүү башка нерсени өлчөгөндүктөн гана жакшыраак көрүнүшү мүмкүн.

Саясаттын баасы да бар. Туннелде ::/0 болсо, бардык IPv6 трафиги VPN аркылуу чыгат, анын ичинде тармак ээси ташууга эч качан макул болбогон трафик. Муну аталган ээси бар жайгаштыруу чечими катары караңыз, түнкү саат 1де кабыл алынган жөндөө кадамы катары эмес.

Муну бүтүргөн иш тартиби

AAAA жообу аймакка ээ чечүүчүдөн келерин ырастаңыз, tun интерфейси үчүн VpnService жана netd абалын окуңуз, Chromium талапкерди таштап салдыбы деп көрүү үчүн net-export изин алыңыз, анан ip -6 route get менен барып-кайтууну текшериңиз. Чындыгында ишке ашпаган катмарды түзөтүңүз жана бөлүү саясатына тийбеңиз. Жеке аттарга коомдук аттардан башка жооп керек болсо, split tunneling ушуга арналган.

Телефондун buildин, браузердин версиясын жана сиз сураган чечүүчүнү жазып алыңыз. Бул үч факт "IPv6 is broken" дегенди кийинки адам кайталай алган нерсеге айландырат.

Тектеш макалалар