VPN مزدوج المكدس: العميل يختار عائلة العنوان، لا أنت
اسم واحد، عائلتان، مساران مختلفان. قد يكون النفق سليمًا ويظل الطلب يفشل لأن العميل اختار مرشحًا لم توجّهه قط.
النفق قائم، ومواقع IPv4 تُحمَّل، واسم مضيف واحد تنتهي مهلته. الاستنتاج الفوري أن VPN معطوب أو أن بيانات الاعتماد خاطئة، وليس أي منهما صحيحًا عادة. أعاد الاسم عنوان IPv4 وعنوان IPv6 معًا، فاختار التطبيق أحدهما، ولم يكن لدى أحد المرشحين مسار عامل. اتخذ العميل قرار اختيار؛ والنفق ببساطة لم يغطِّ ما اختاره.
الاختيار ليس وعدًا بالتغطية
اختيار العنوان الافتراضي، كما هو موصوف في RFC 6724، يحدد أي زوج من المصدر والوجهة يفضّله المضيف عندما تتوفر عدة خيارات. ويضيف Happy Eyeballs استراتيجية اتصال فوق ذلك: يبدأ المحاولات على العائلتين ويحتفظ بأول من يستجيب، حتى لا ينتظر المستخدم عائلة معطوبة إلى أن تنتهي مهلتها.
لا تُنشئ أي من الآليتين مسارًا. فإذا كان نفقك يحمل IPv4 فقط، يظل مرشح AAAA وجهة مشروعة قد يحاولها العميل، ويظهر الفشل على هيئة تحميل بطيء لا خطأ، لأن المتصفح رجع إلى البديل. يبلّغ المستخدم عن موقع بطيء لا معطوب، وتَرِث تذكرة الدعم ذلك الغموض. أعد إنتاج المشكلة بعائلة ثابتة يصبح التقرير محددًا.
لهذا الرجوع يتباين العَرَض بين التطبيقات. المتصفح يخفي التأخير؛ أما عميل سطر الأوامر بعائلة ثابتة فيُظهر لك الفشل الحقيقي فورًا.
حدّد العائلة التي استخدمها الطلب فعليًا
ابدأ بالاسم لا بالنفق. استعلم عن نوعي السجلات ودوّن ما عاد:
dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.comإذا نجح طلب v4 وفشل طلب v6، فقد أعدت إنتاج المشكلة في شكل يمكنك تنقيحه. وإذا نجح كلاهما من الصدفة وظل المتصفح يفشل، فافحص محلّل التطبيق نفسه أو إجابة مخزّنة قبل أن تمس النفق.
احتفظ بالعائلة والوجهة في ملاحظاتك. التذكرة التي تقول إن الموقع لا يُحمَّل عبر VPN لا يستطيع أحد التحقق منها، أما تذكرة تقول إن AAAA يفشل وA يعمل فتشير إلى مسار محدد.
افحص المسار الخاص بتلك العائلة
بالنسبة للعائلة الفاشلة، اسأل النواة عن المسار الذي ستستخدمه وقارنه بعناوين النفق المضبوطة. على Linux، يعرض ip -6 route get للوجهة الواجهة والمصدر اللذين سيُختاران.
ثم افحص النفق نفسه. تحمل أقران WireGuard قائمة عناوين IP مسموحة، ولا يقول أي إدخال لـ 0.0.0.0/0 شيئًا عن IPv6. فإذا لم تكن في قائمة القرين بادئة IPv6، فلا سبب لدى العميل لإرسال حركة AAAA إلى النفق، وتغادر الحزمة عبر ما يفعله المضيف لولا ذلك.
تستحق قواعد الجدار الناري وسياسة NAT الفحص نفسه لكل عائلة. القاعدة المكتوبة لـ IPv4 لا تغطي IPv6 على أي منصة، وهذا هو السبب الأكثر شيوعًا لنجاح عائلة وفشل الأخرى.
لا تعطّل IPv6 لتجعل لقطة الشاشة بسيطة
تعطيل IPv6 على مستوى النظام سيجعل العَرَض يختفي ويتركك بلا تشخيص. كما أنه يكسر أي وجهة تعمل بـ IPv6 فقط، ويخفي العلة نفسها عن التطبيق التالي. وإذا كان جهاز ما لا ينبغي له فعلًا استخدام IPv6، فتلك سياسة متعمدة لها مالك واختبار. أما تعطيله أثناء حادثة فليس أيًّا منهما.
قرّر ما ينبغي للعميل فعله بالعائلة واضبطه صراحةً: مرّرها عبر النفق، أو احجبها بطريقة مدعومة بحيث لا يعرض الاختيار مرشحًا غير قابل للوصول. كلا التصميمين مشروع. أما التعطيل الشامل فليس كذلك، لأنه ليس تصميمًا أصلًا.
ما الذي يجب تدوينه في التذكرة
سجّل أربعة أشياء: اسم المضيف، والعائلة التي فشلت، والمسار الذي اختارته النواة، ونتيجة طلب خاص بتلك العائلة. هذه المجموعة تكفي لشخص آخر لإعادة إنتاج الفشل دون تخمين أي المسارين قصدت.
قواعد اختيار العنوان في RFC 6724 تشرح لماذا فضّل العميل المرشح الذي فضّله، ويشرح RFC 8305 سلوك التسابق الذي أخفى التأخير. لا أحد منهما سيوجّه حزمة نيابة عنك، وهذا هو الجزء الذي على النفق فعله.