Meshnet وDocker والصلاحية بينهما

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

الصلاحية تتعلق بنقطة نهاية المضيف، والترجمة تتعلق بـDocker، وتسجيل الدخول يتعلق بالتطبيق. ثلاثة قرارات، وثلاثة مواضع للنظر.

اتبع الوجهة بعد النشر

خذ مضيف Linux يعمل بـDocker وينشر المنفذ 80 لحاوية على منفذ المضيف 8080. يتصل نظير بعنوان الشبكة الخاص بالمضيف على 8080، فيقبل المضيف الاتصال، وتعيد ترجمة الوجهة كتابته نحو عنوان الجسر الخاص بالحاوية، وهو عادة شيء مثل 172.17.0.2 على المنفذ 80.

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

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

قرر مقدار الوصول المحلي الذي تمنحه الصلاحية

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

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

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

اختبر الصلاحية، لا العنوان وحده

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

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

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

اكتب النتيجة بمصطلحات النظام نفسه

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

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