لماذا تعجز حاوية macvlan عن الرد على عميل VPN

تخيّل مضيف Linux ينهي اتصال VPN ويشغّل أيضًا حاوية على شبكة macvlan. الشبكة المحلية هي 192.168.60.0/24، والحاوية تحمل 192.168.60.210، وعملاء VPN يأتون من 10.95.0.0/24. يصل العميل إلى الخدمة، ولا يعود الردّ أبدًا، وتبدو كل قاعدة جدار حماية على المضيف صحيحة. قيدان منفصلان ينتجان هذه الأعراض، وإصلاح أحدهما يترك الآخر في مكانه.

قيدان، عرَض واحد

القيد الأول هو العزل: لا يسمح سائق macvlan في Docker للحاوية بالتحدث إلى مضيفها عبر الواجهة الأم. فالحركة بين مكدّس المضيف والحاوية لا مسار لها، مهما كُتبت المسارات على المضيف.

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

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

ابنِ طبقة وصل على جانب المضيف، بأضيق نطاق

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

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

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

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

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

قرّر كيف يُحفظ المصدر

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

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

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

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

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

تحقّق من العميل، لا من المضيف

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

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

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

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

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