Docker: لا توجد مجموعات عناوين محددة مسبقًا متبقية أثناء جلسة VPN

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

أكّد ما فشل قبل أن تغيّر أي شيء

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

دوّن إصدار Engine في التذكرة في الوقت نفسه. كل استدلال في بقية هذا الدليل مرتبط بالإصدار، وأي ادعاء بلا إصدار مجرد إشاعة.

أحصِ التخصيصات الموجودة لديك بالفعل

اسرد الشبكات ثم افحص المهم منها: docker network ls يليه docker network inspect NETWORK_NAME. اقرأ شبكات IPAM الفرعية والحاويات المرتبطة بكل منها. عدة مشاريع Compose تستهلك كتلًا أكثر مما توحي به أعداد حاوياتها، لأن كل مشروع يميل إلى إنشاء شبكته الافتراضية الخاصة. الحاوية المتوقفة لا تحرر تخصيص شبكتها.

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

اكتب العدد. إنه خط الأساس الذي يخبرك هل ساعد التغيير التالي.

قارن رؤية الخفي للمسارات

يمكن أن يؤثر VPN في اختيار المرشحين، لكن التنفيذ الدقيق هو ما يحدد الكيفية. في Moby 28.2.2 على Linux، يجمع InferReservedNetworks عناوين خوادم الأسماء وبعض مسارات IPv4 على الوصلة، وهو لا يحجز ببساطة كل مسار من كل جدول. كما تستبعد مسارات الوصلة المجمّعة عنوان وجهة غير محدد، لذا فمسار 0.0.0.0/1 وحده لا يحجز كل عنوان. وقد تتقاطع بادئة واسعة أخرى على الوصلة، مثل 128.0.0.0/1، مع نطاقي المرشحين المعتادين 172 و192.

قارن ip -4 route show table all قبل اتصال VPN وبعده، على مضيف الخفي. الفرق هو الدليل، والإصدار هو نطاق الادعاء.

لا تعمّم استدلالات إصدار واحد على كل إصدار. وهكذا يتحول جواب منتدى إلى تغيير في السياسة.

اختر أصغر إصلاح يجدي

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

تغيير default-address-pools سياسة أوسع بشأن التخصيصات المستقبلية. اختر أساسًا غير متعارض وحجمًا مخصصًا مناسبًا، ودمجه مع إعدادات الخفي القائمة، وخطط لأثر إعادة التشغيل الموثق. الشبكات القائمة لا يُعاد ترقيمها بصمت.

لا تعطّل دفع مسارات الشركة لتحقيق نجاح التخصيص. خطة عناوين صريحة تحل عادةً المشكلة المحلية دون إضعاف سياسة إلزامية.

اقبل التخصيص والتوجيه بشكل منفصل

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

احتفظ بفرق المسارات وعدد المجموعة مع سجل التغيير، لأن تحديث عميل VPN التالي قد يغيّر الأول دون أن يمس Docker.

يكتمل الدليل عندما يستطيع شخص آخر تكرار هذين الفحصين والحصول على الجواب نفسه.