Чаму адказы DNS64 змяняюцца, як толькі падключаецца VPN?

Адказы DNS64 апісваюць сеткавае ўладкаванне, а не ўласцівасць сервера. Рэзалвер сінтэзуе адрас IPv6 з адраса IPv4, і вынік працуе толькі там, дзе ў канцы гэтага прэфікса знаходзіцца транслятар. Увядзіце VPN у шлях, і гэтае ўладкаванне можа захавацца, змяніцца або перастаць быць праўдай у залежнасці ад трох умоў.

Гэтыя ўмовы — рэзалвер, які адказаў, маршрут, які мае ваша прылада да сінтэзаванага прэфікса, і тое, ці выконвае нешта на гэтым маршруце трансляцыю. Кожную з іх можна назіраць, і менавіта таму збой паддаецца дыягностыцы.

На што насамрэч паказвае сінтэзаваны запіс AAAA

Рэзалвер DNS64 адказвае на запыт AAAA для імені, якое падтрымлівае толькі IPv4, убудоўваючы адрас IPv4 у прэфікс, які ён наладжаны выкарыстоўваць, а агульнавядомы прэфікс для гэтай задачы — 64:ff9b::/96, як апісана ў RFC 6147. Для праграмы запіс выглядае як любы іншы запіс 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 не будзе працаваць для гэтага імя, што б ні рабіў кліент. Запіс ёсць, а маршруту няма — значыць, прэфікс не нясецца бягучым шляхам, і гэта рашэнне аб маршрутызацыі, а не збой рэзалвера. Маршрут ёсць, а запыт усё яшчэ не ўдаецца — гэта паказвае на сам транслятар, і гэта ўжо іншы ўласнік.

Запісвайце рэзалвер, сеткавы кантэкст і сямейства адрасоў побач з кожным вынікам. Менавіта гэтая нататка дазволіць наступнаму параўнанню аддзяліць змену рэзалвера ад змены маршрутызацыі.