حلقة المسار الافتراضي في WireGuard: العثور على مسار نقطة النهاية

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

تأكّد من الحلقة قبل تغيير أي مسار

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

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

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

اقرأ مسار نقطة النهاية، لا مسار النفق

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

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

استعد مسار نقطة النهاية بتغيير واحد متسق

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

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

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

تحقّق، ثم احتفظ بطريق للعودة

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

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

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