لماذا تتغير إجابات 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 فقط لن ينجح لذلك الاسم أيًّا كان ما يفعله العميل. وجود السجل دون مسار يعني أن البادئة لا يحملها المسار الحالي، وهذا قرار توجيه لا خطأ مُرحِّل. ووجود المسار مع استمرار فشل الطلب يشير إلى المُترجِم نفسه، وذلك يخص مالكًا آخر.

سجّل المُرحِّل وسياق الشبكة وعائلة العناوين بجانب كل نتيجة. هذه الملاحظة هي ما يتيح للمقارنة التالية فصل تغير المُرحِّل عن تغير التوجيه.