لماذا لا يستطيع حاوية Docker الوصول إلى المضيفات خلف الـ VPN

الحاوية التي لا تستطيع الوصول إلى أي شيء خلف VPN المؤسسة تعيش عادةً في مساحة أسماء شبكية مختلفة عن النفق. مسارات عميل المضيف وخوادم DNS وعلامات الجدار الناري تنتمي إلى حزمة المضيف، أما حاوية شبكة الجسر فلها حزمتها. هذه الحقيقة الواحدة تفسّر معظم البلاغات التي تصل إلى فريق المنصة، وهي أيضاً سبب أن عبارتي «الـ VPN معطّل» و«Docker يتجاوز الـ VPN» يمكن أن تكونا خاطئتين في الوقت نفسه. إعدادان مختلفان تماماً يختبئان خلف عرَض واحد، فحدّد أيّهما لديك قبل تغيير أي إعداد.

اكتشف أي مساحة أسماء تملك النفق

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

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

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

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

شبكة المضيف اختبار وليست تصميماً

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

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

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

جهاز tun والامتيازات التي يأتي بها

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

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

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

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

NAT الجسر يغيّر المصدر الذي يراه VPN

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

يمنح macvlan أو ipvlan الحاوية عنوان LAN بدلاً من ذلك، مما يساعد في اكتشاف LAN ويجعل الحاوية تبدو نظيراً على المقطع. كما يتجاوز نفق المضيف كلياً، لذا لن تصل حاوية كهذه إلى بادئات VPN فقط ما لم يكن VPN قابلاً للوصول من ذلك LAN أيضاً.

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

DNS يتبع الخفي لا النفق

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

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

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

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