حاويات Windows وVPN: لماذا تتعطل الشبكة المحلية
تعتمد حاوية Windows على جدول توجيه المضيف، لذا فإن أي VPN يحجب الشبكة الفرعية المحلية يأخذ معه بادئة الحاوية. أما وضع Linux فيسلك مسارًا آخر.
على حاسوب محمول واحد، مع اتصال عميل VPN واحد، تستمر حاويات Linux في التحدث مع بعضها وتتوقف حاويات Windows. الصورة ليست المتغير؛ بل المسار الذي تسلكه الحزم إلى المضيف هو المتغير. حاويات Windows على الشبكة الافتراضية تستعير جدول توجيه المضيف وترجمته، لذا فإن أي سياسة تغيّر توجيه المضيف تغيّرها هي أيضًا. تحقق من ذلك ببحث عن المسار قبل إعادة تثبيت أي شيء.
أين تدخل حزم حاوية Windows إلى المضيف
تحصل حاوية على الشبكة الافتراضية nat على عنوان من بادئة خدمة Host Networking Service، عادةً في مكان ما داخل 172.16.0.0/12، وتصل إلى المضيف عبر محول ظاهري. يملك المضيف المسار الخاص بتلك البادئة ويترجم حركة المرور نحو المحول النشط. لا توجد آلة افتراضية منفصلة في منتصف ذلك المسار.
هذا التصميم هو ما يجعل الفشل آليًا. عندما ترسل الحاوية حزمة، يجري المضيف بحثًا عن المسار الخاص ببادئة الحاوية. وأي مسار يفوز هو المكان الذي تذهب إليه الحزمة، ولا رأي للحاوية في ذلك.
ما يغيّره عميل VPN في ذلك المسار
غالبًا ما يثبّت العميل المؤسسي مجموعة واسعة من المسارات وعامل تصفية يمنع الوصول إلى الشبكة الفرعية المحلية أثناء تشغيل النفق. القصد دفاعي: يجب ألا تصل شبكة محلية مخترقة إلى جهاز محمي. الأثر الجانبي هو أن مسار المضيف إلى بادئة الحاوية لم يعد شبكة NAT المحلية.
بدلًا من ذلك، يطابق البحث النفق وتُسلَّم الحزمة إلى البوابة التي لم تسمع قط بعنوان الحاوية ذلك. يفشل Ping، وتنتهي مهلة التطبيق، وتبدو الحاوية معطلة بينما تلمع أيقونة VPN. تحقق من جدول المضيف أثناء الاتصال وسيظهر المسار المنافس.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
لماذا تتصرف حاويات Linux بشكل مختلف
يشغّل محرك Linux الحاويات داخل آلة افتراضية خفيفة، ويتم فتح الاتصالات الصادرة من تلك الآلة بواسطة وكيل على جانب المضيف نيابةً عن الحاوية. المضيف هو من يبدأ المقبس، لذا لا تنطبق عليه قاعدة VPN الخاصة ببادئة الحاوية بالطريقة نفسها، ويستمر عبء العمل في الوصول إلى الشبكة.
يفسّر هذا الفرق أيضًا لماذا لا تنتقل وصفات Linux. تُمنح حاوية Linux التي تحتاج إلى نفقها الخاص جهاز TUN بالإضافة إلى قدرة NET_ADMIN. لا تكشف حاويات Windows عن أي واجهة كجهاز، لذا لا يوجد لتلك الطريقة مقابل على ذلك الجانب.
أثبت المسار ثم اختر تصميمًا
اجمع الأدلة من المضيف لا من الحاوية، لأن المضيف هو من يجري البحث:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"شغّل مخرجات المسار مرة قبل اتصال VPN ومرة بعده. إذا أشارت بادئة الحاوية في المخرجات الثانية إلى محول النفق، فإن التشخيص مكتمل ولن تساعد إعادة تشغيل الحاويات.
الخيار الأول قرار سياسي: اسأل مالك الشبكة إن كان يمكن السماح بالوصول إلى LAN المحلية لهذا الجهاز. تعرض عدة عملاء مؤسسيين ذلك كإعداد، لكنه يضعف حدًا مقصودًا. اطلبه كاستثناء موثّق له مالك وتاريخ مراجعة. المفتاح الخاص بكل جهاز الذي لا يعود إليه أحد هو كيف تختفي سياسة دفاعية بهدوء.
حيث يجب أن تصمد السياسة، انقل عبء العمل بدلًا من محاربة المسار. شبكة شفافة بشبكة فرعية وبوابة صريحتين تضع الحاويات على الرابط المحلي، ويعمل عبء عمل Linux خلف وكيل الآلة الافتراضية، و آلة افتراضية منفصلة مع عميلها الخاص تحتفظ بسياساتها الخاصة. اختر واحدًا عن قصد واختبره من داخل الحاوية، لأن طلب المستخدم ينشأ هناك.