لماذا يقطع مسار النفق الكامل الخادم الذي يحمله

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

مسار يأكل نقله الخاص

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

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

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

ثبّت الاستثناء قبل المسار الافتراضي

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

معظم العملاء يفعلون هذا دون مطالبة. OpenVPN يبحث عن العنوان البعيد ويثبته قبل إعادة كتابة البوابة الافتراضية، وخيار route-delay لديه موجود للمنصات التي تتسابق فيها هذه التسلسلية. أما wg-quick فيسلك طريقًا مختلفًا تمامًا، بوضع علامات على الحزم والرجوع إلى قاعدة سياسة بدلًا من إضافة استثناء. آليات مختلفة، متطلب واحد: على الحزمة الخارجية أن تفلت من النفق الذي تنشئه.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

مخرجات البحث هي اختبار القبول. عليها أن تسمّي الجهاز الفيزيائي والقفزة التالية الفيزيائية. ظهور جهاز نفق في هذا الجواب يعني أن الاستثناء مفقود أو وضع بعد شيء يتجاوزه.

الصورة المعكوسة على الخادم

الفخ نفسه ينتظر على الجانب الآخر، معكوسًا. أعطِ الخادم مسارًا افتراضيًا عبر نفق آخر، أو ادفع إليه مسارًا يغطي العناوين العامة للعملاء، وستكتسب ردوده عادة السير في الاتجاه الخطأ.

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

استثناءات يظل النفق يسرقها

حفنة من المهام تحتاج الإنترنت المفتوح حتى والنفق يملك المسار الافتراضي، وكل واحدة منها تحتاج استثناءها الخاص. محدّث DNS الديناميكي هو عادة أول ما ينكسر.

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

الاستثناء الذي لم يكتبه أحد هو استثناء ستسقطه إعادة البناء التالية بصمت.

أثبته بعد إعادة الاتصال، لا قبله

اختبر ثلاث وجهات، لا واحدة: نقطة النهاية، وعنوانًا خاصًا خلف النفق، وعنوانًا عامًا بعده. بحث ناجح واحد لا يقول شيئًا تقريبًا عن الاثنين الآخرين.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

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