WireGuard داخل فضاء أسماء الشبكة: لماذا بقي المقبس في مكانه

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

العَرَض: فضاء الأسماء صحيح، ولا حزم

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

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

هذا ليس خللًا في النقل، وليس إعدادًا خاطئًا للنظير. هذا ما تفعله تنفيذات النواة، ووثائق فضاءات الأسماء الخاصة بـ WireGuard تصف قاعدة الإنشاء مباشرة.

لماذا للمقبس مكان ميلاد

يمتلك جهاز WireGuard مقبس UDP واحد لنقله المشفّر، ويُفتَح ذلك المقبس في فضاء الأسماء الذي يُنشَأ فيه الجهاز. نقل الواجهة بأمر ربط ينقل الجهاز المرئي ويترك النقل حيث بدأ. عندئذ يكون للكائنين مالكَان مختلفان.

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

أنشئه حيث تريد المقبس

الحل هو إنشاء الجهاز داخل فضاء الأسماء الهدف بدلًا من إنشائه في الخارج ثم نقله. بافتراض أن فضاء أسماء معتمدًا موجود بالفعل وأن الاسم غير مستخدم:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

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

اقرأ جانبي المسار

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

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

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

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