حركة IPv6 التي تتجاوز الـVPN: العثور على المسار المسرِّب

صفحتا اختبار تتناقضان: إحداهما تبلّغ عنوان المزوّد عبر النفق، والثانية تبلّغ بادئة منزلك، والاستنتاج الظاهر أن الـVPN يسرّب. هذا الاستنتاج يتخطى خطوة، لأن التقريرين خاضا قرارَي توجيه مختلفين ولم يكن يُفترض أن يدخل النفق إلا واحد منهما. الفجوة عادةً حقيقية، وهي مشكلة تغطية لا نفق معطوب. ثلاثة أسئلة تحسم الأمر: أي تدفق خرج فعلاً، وأي مسار اختاره النواة له، وأي سلوك قصده العميل.

اعمل بهذا الترتيب. الإجابة عنها بغير ترتيب تُنتج جدالاً طويلاً حول ما إذا كان العميل معطوبًا، بينما الجواب الحقيقي أن شيئًا لم يثبّت مسار IPv6 قط.

أي تدفق خرج فعلاً، وعلى أي محوّل

ابدأ باختبار يسمّي العائلة التي استخدمها، ثم دوّن التطبيق وشبكة الوصول والملف الشخصي النافذ وما إذا كان الاتصال يوفّر IPv6 أصلاً. هذه الحقائق الأربع هي ما يجعل تشغيلين قابلين للمقارنة، والرابعة هي التي ينساها الناس: شبكة بلا بادئة v6 لا يمكنها تسريب v6، وشبكة تضيف واحدة لاحقًا تغيّر الجواب.

أرسل طلبًا واحدًا لكل عائلة بدل تحميل صفحة وقراءة نتيجتها. قد تخلط صفحة واحدة موارد v6 وv4، وقد يتصرف خلفية معينة بشكل مختلف عن التبويب أمامك، وقد تعيش إجابة مخزّنة أطول من تغيير الشبكة الذي تحاول اختباره. ثبّت الوجهة التي تختبرها ودوّنها، حتى يقيس تشغيل مكرر الشيء نفسه.

قراءة المسار الذي اختارته النواة

جدول المسارات يجيب عن السؤال الذي لا يستطيع المتصفح الإجابة عنه. اسأل النظام إلى أين تتجه وجهة محددة، وأدرج قواعد السياسة إلى جانب الافتراضي الظاهر، لأن أياً منهما قد يتجاوزه:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

البادئة الأكثر تحديدًا هي السبب المعتاد لبقاء وجهة خارج النفق بينما يبقى كل شيء آخر داخله، وقاعدة سياسة يمكنها فعل الشيء نفسه بأولوية أعلى من أي مسار. اقرأ المقياس أيضًا، لأن مدخلين للبادئة نفسها يُحسمان بالمقياس لا بترتيبهما على الشاشة. في Windows القائمة المكافئة هي Get-NetRoute -AddressFamily IPv6، مرتبة حسب المقياس لتطابق ترتيب القرار. القاعدة التي تبدو صحيحة في الجدول قد تخسر أمام قاعدة سياسة برقم أقل، ولهذا تنتمي قائمة القواعد إلى الجملة نفسها التي تنتمي إليها قائمة المسارات.

من أين تأتي سياسة IPv6 عند العميل

يمكن أن يُبنى العميل على نقل v6 عبر النفق، أو رفضه، أو السماح باستثناء مسمّى، وهذه النوايا الثلاث تُنتج ثلاث نتائج صحيحة مختلفة. اقرأ الملف الشخصي وتوثيق العميل نفسه قبل أن تسمّي ملاحظة ما تسريبًا، لأن عميلاً يحجب v6 بينما لا يزال نظام التشغيل يرسل اكتشاف الجيران على الوصلة الفيزيائية يتصرف كما صُمِّم.

التطبيق المستبعد عمدًا من النفق حالة مختلفة عن عائلة لم يحملها النفق قط. الأول قرار يخص برنامجًا واحدًا، والثاني فجوة في التغطية، ويختلف الإصلاح تبعًا لذلك. اقرأ قائمة البرامج المستبعدة عند العميل قبل البحث عن مسار لم يكن مقصودًا أن يوجد.

مراقبة دقيقة، حين يختلف الجدول

حين يكون استعلام المسار ملتبسًا، يمكن لمراقبة واحدة على واجهة المضيف أن تحسمه، لكن فقط إذا كانت موجهة إلى السؤال. حركة المرور إلى نقطة نهاية الـVPN نفسها ستعبر المحوّل الفيزيائي بحكم التصميم؛ المهم هو ما إذا كان تدفق التطبيق، المعنون في مكان آخر تمامًا، يظهر هناك أيضًا. احصر الالتقاط في الوجهة التي تختبرها بدل جمع كل شيء.

الالتقاط الواسع يكشف قدرًا أكبر بكثير من حركة المرور الشخصية مما تتطلبه المسألة الواحدة. وهو يجيب عن السؤال بوضوح أقل أيضًا، لأن التدفق الذي يهمك يصل مدفونًا في سيل من الاتصالات غير ذات الصلة. احصر في الوجهة المختبرة، وتوقف بعد حفنة من الحزم، واحذف الالتقاط.

ثلاث طرق لسدّ الفجوة

انقل العائلة عبر النفق، أو احجبها عند العميل عندما يتعذر على النفق حملها، أو سجّل استثناءً متعمدًا مع مالك وتاريخ مراجعة. كل خيار دفاع مقبول، والشيء الوحيد غير المقبول هو ترك الخيار ضمنيًا، لأن الخيار الضمني هو ما يكون عليه التسريب فعلاً. إن لم يكن للنفق مخرج v6 إطلاقًا، فإن رفض v6 عند العميل صادق وقابل للاختبار معًا. المهم أن يُكتب الخيار حيث سيجده الشخص التالي، لا أن يُستنتج من السلوك بعد ستة أشهر.

أعد الفحص بعد إعادة الاتصال وبعد التنقل بين الشبكات، لأن مسارًا ثبت للوصلة السابقة قد يبقى بعد التغيير. ثم سجّل الوجهة والمسار المختار وسياسة العميل والعائلة التي استخدمها الاختبار، حتى يقرأ الشخص التالي قرارًا بدل إعادة استنتاجه. RFC 7359 يوثّق تسريب المسار المزدوج كمشكلة تصميم لا كخطأ برمجي، وهو المرجع الذي تستشهد به عندما يدّعي أحدهم أن نفق v4 العامل يغطي كل شيء.