WireGuard AllowedIPs: المسار الذي لم يضفه NetworkManager أبدًا

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

ينفّذ wg-quick الاثنين دون أن يُطلب منه ذلك. كما يثبّت دعم WireGuard المدمج في NetworkManager مسارات الأقران افتراضيًا، ما يضيّق دائرة الشك إلى خيار معطّل، أو جدول توجيه مختلف، أو إعدادات جُلبت عبر شيء آخر.

تأكّد من النفق قبل مطاردة المسار

wg show يطبع الواجهة والقرين ونقطة الطرف وعمر أحدث مصافحة، ويؤكّد ip addr show وجود العنوان. المصافحة الحديثة تعني أن المفاتيح ونقطة الطرف ومسار UDP تعمل. وكل ما هو معطوب يقع بعدها: التوجيه أو الترشيح أو تحليل الأسماء.

ثم اسأل النواة عمّا ستفعله بوجهة حقيقية لا بوجهة افتراضية: ip route get 10.42.7.9. تذكر الإجابة الواجهة الصادرة وعنوان المصدر الذي ستحمله الحزمة. وعندما تذكر المحوّل الفيزيائي، فإن الحزمة لا تدخل النفق أبدًا مهما بدت المصافحة سليمة.

AllowedIPs مرشّح وقائمة مسارات

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

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

اسأل عمّا إذا كانت مسارات الأقران مفعّلة أصلًا

اقرأ الإعداد قبل أن تعدّل أي شيء: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. عندما يقرأ peer-routes قيمة no، فإن الإصلاح المدعوم هو nmcli connection modify work-wg wireguard.peer-routes yes، يتبعه إعادة اتصال. أما إضافة مسار ثابت فتعمل حتى التنشيط التالي ثم تختفي بهدوء. وهذا الاختفاء هو الدليل: المسار الذي يعود كل صباح كلغز لا يثبّته الملف.

إذا كان الخيار مفعّلًا بالفعل، فتحقّق مما إذا كانت البادئة تعيش في جدول آخر عبر ip route show table all | grep 10. المسار في جدول غير الجدول الرئيسي ليس ناقصًا، بل هو غير مرئي لعملية بحث لا تراجع إلا الجدول الرئيسي. أصلح توجيه السياسة بدلًا من تكديس إدخال مكرّر فوقه.

أضف البادئة إلى الاتصال لا إلى النظام العامل

في محرّر الاتصال، تحمل صفحة WireGuard القرين وقائمة AllowedIPs الخاصة به، وتحمل صفحة IPv4 مسارات إضافية. والمسار المضاف هناك يبقى بعد إعادة الاتصال لأنه ينتمي إلى الملف. وعلى سطر الأوامر يكون المكافئ بإلحاق مسار بالاتصال بصيغة البوابة الفارغة، ثم إنزال الاتصال وإعادته كي يُطبَّق التغيير.

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

الأنفاق المنقسمة تحدّدها قائمة البادئات

لا يوجد مفتاح للنفق المنقسم؛ قائمة البادئات هي القرار. القرين الذي له نطاق لشبكة المكتب المحلية ونطاق لشبكة مختبر يرسل تلك الوجهات بالضبط عبر النفق ويترك كل شيء آخر كما هو. والمضيف الواحد يحتاج /32، والنطاقات المتداخلة في موقعين تحتاج بادئات مضيف حتى يعيد أحدهم ترقيم شبكة فرعية.

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

مالك واحد لجدول التوجيه

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

عندما يجب أن يتبع الانقسام محوّلًا فيزيائيًا لا وجهة، تكون قد انتقلت إلى توجيه السياسة، وتوجيه السياسة يحتاج مؤلفًا واحدًا أيضًا. تحقّق بإعادة ip route get، ثم بالوصول إلى مضيف داخل البادئة البعيدة بشيء يطبع عنوان المصدر الذي اختاره. وافحص IPv6 وDNS بشكل منفصل إذا كان الملف يحمل أيًّا منهما.