Неге VPN қосылған бойда DNS64 жауаптары өзгереді?

DNS64 жауаптары сервердің қасиетін емес, желілік орналасуды сипаттайды. Шешуші IPv4 мекенжайынан IPv6 мекенжайын синтездейді, ал нәтиже сол префикстің соңында аударғыш отырған жерде ғана жұмыс істейді. Жолға VPN әкелсеңіз, бұл орналасу үш шартқа байланысты сақталуы, өзгеруі немесе шындық болудан қалуы мүмкін.

Бұл шарттар — жауап берген шешуші, құрылғыңыздың синтезделген префикске дейінгі маршруты және сол маршрутта бірдеңе аударма жасай ма, жоқ па. Әрқайсысын байқауға болады, және дәл осы ақауды диагностикалауға мүмкіндік береді.

Синтезделген AAAA жазбасы шын мәнінде нені нұсқайды

DNS64 шешушісі тек IPv4-і бар атауға AAAA сұранысына IPv4 мекенжайын пайдалануға конфигурацияланған префикстің ішіне кірістіру арқылы жауап береді, және бұл жұмыстың белгілі префиксі — RFC 6147 құжатында сипатталған 64:ff9b::/96. Қолданба үшін жазба кез келген басқа AAAA жазбасындай көрінеді, және мәселенің мәні осында: тек IPv6-сы бар клиент меже ешқашан IPv6 болмағанын білмей байланысты көре алады. Содан кейін бұл байланыс жолдың қайсыбір жерінде екі отбасы арасында аударатын NAT64 функциясына байланысты. Сол аударғыш болмаса, синтезделген мекенжай сенімді көрінетін, бірақ еш жерге апармайтын меже болып қалады.

Сондықтан жазба бір уақытта екі нәрсені кодтайды: бастапқы IPv4 мекенжайын және аударғыш қолжетімді деген болжамды. Жауаптың өзінде тек біріншісі көрінеді.

Үш шарт оның әлі жұмыс істейтінін шешеді

Бірінші шарт — жазбаны қай шешуші жасағаны, өйткені конфигурацияланған DNS64 жоқ шешуші сол атауға ештеңе қайтармайды және қолданба басқаша сәтсіздікке ұшырайды. Екіншісі — құрылғыңыздың синтезделген префикске маршруты бар ма, өйткені жауап жарамды болуы мүмкін, ал оған барар жол жетіспеуі мүмкін. Үшіншісі — сол префикске ие аударғыш сіз қолданатын жолда ма, өйткені 64:ff9b::/96-ны басқа жаққа апаратын туннель басқа функцияға немесе ештеңеге жетпейді. Үшеуі де туннельге дейін орындалып, одан кейін сәтсіздікке ұшырауы мүмкін, сондықтан симптом кенеттен құлдырауға ұқсайды.

Оларды осы ретпен тексеріңіз. Жоқ жауап пен жоқ маршрут браузерде бірдей көрінеді, ал шешуші журналында мүлдем басқаша.

Шешуші өзгерсе, жауап та өзгереді

VPN клиенті көбіне өз шешушісін таңады немесе бүкіл сұраныс жолын өзі алады, ал ол шешуші ештеңе синтездемеуі мүмкін. Сонда тек IPv4-і бар атауларға сұраныстар AAAA жазбасын қайтармайды, мұны тек IPv6-сы бар клиент жете алмайтын атау ретінде бастан кешеді. Керісінше де болады: шынымен синтездейтін шешуші сізге туннельдік жолыңыз тасымайтын префикс бере алады.

Кэштеу мұны көруді қиындатады. Кеңсе желісінде алынған синтезделген жазба оны жасаған контекстен ұзақ өмір сүруі мүмкін, сондықтан клиент аударғышы енді қолжетімсіз мекенжайға қосылуды жалғастырады. Қазір жауап беріп жатқан шешушіге қараңыз, жазба сақталған кезде жауап бергенге емес. Ескі мен жаңа жауапты жазып алмай кэшті тазалау сізге қажет дәлелді жояды.

Сұраныс пен жолды бөлек тексеріңіз

Қолданбаны қоспастан бұрын атауды тікелей сұраңыз және қай сервер жауап бергенін жазып алыңыз. Төмендегі командалар AAAA жазбасын, қолданылып жатқан шешушіні және синтезделген префикске маршруттың бар-жоғын көрсетеді. Оларды туннель өшірулі күйде, содан кейін қайта қосулы күйде іске қосыңыз.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Нәтижелерді тізбек ретінде оқыңыз. AAAA жазбасының жоқтығы алдыңыздағы шешушінің синтездемейтінін білдіреді, сондықтан тек IPv6-сы бар жол сол атау үшін жұмыс істемейді, клиент не істесе де. Жазба бар, бірақ маршрут жоқ — префиксті қазіргі жол тасымайды, және бұл маршруттау шешімі, шешуші ақауы емес. Маршрут бар, бірақ сұраныс әлі де сәтсіз — бұл аударғыштың өзіне нұсқайды, ал ол басқа иесіне тиесілі.

Әр нәтиженің қасына шешушіні, желілік контексті және мекенжай отбасын жазыңыз. Келесі салыстыруға шешуші өзгерісін маршруттау өзгерісінен ажыратуға мүмкіндік беретін дәл осы жазба.