Docker: VPN سیشن کے دوران کوئی پہلے سے متعین پتوں کا پول باقی نہیں رہتا

ناکامی مخصوص ہے: Docker کو نئے پل نیٹ ورک کے لیے قابلِ قبول خودکار سب نیٹ نہیں مل رہا۔ اس کا مطلب یہ نہیں کہ مشین کے پتے ختم ہو گئے ہیں، اور نہ یہ کہ VPN خراب ہے۔ تشخیص کا فیصلہ دو سوال کرتے ہیں: ڈیمون کون سے امیدوار بلاک دیکھ سکتا ہے، اور اس ماحول میں اس کا تقسیم کنندہ ان میں سے کون سے خارج کرتا ہے۔ انہیں اسی ترتیب سے نمٹائیں، کیونکہ پہلے سوال کا جواب آنے تک دوسرے سوال کا کوئی مطلب نہیں۔

کچھ بھی بدلنے سے پہلے تصدیق کریں کہ کیا ناکام ہوا

نیچے دیے گئے مراحل اسی ہوسٹ سے چلائیں جو ڈیمون چلاتا ہے۔ دور کے سیاق و سباق سے بات کرنے والا شیل کسی دوسری مشین کی وضاحت کر رہا ہے، اور یہی ایک غلطی ایک گھنٹہ ضائع کر سکتی ہے۔

اسی وقت ٹکٹ میں Engine ورژن بھی درج کریں۔ اس رہنما کے باقی حصے کی ہر ہیورسٹک ورژن سے منسلک ہے، اور ورژن کے بغیر دعویٰ محض افواہ ہے۔

وہ تقسیمیں گنیں جو آپ کے پاس پہلے سے ہیں

نیٹ ورکس کی فہرست بنائیں، پھر اہم لوگوں کا معائنہ کریں: docker network ls، پھر docker network inspect NETWORK_NAME۔ ان کے IPAM سب نیٹ اور ہر ایک سے منسلک کنٹینر پڑھیں۔ کئی Compose منصوبے اپنے کنٹینر کی تعداد سے ظاہر ہونے سے زیادہ بلاک استعمال کرتے ہیں، کیونکہ ہر منصوبہ اپنا ڈیفالٹ نیٹ ورک بنانے کی طرف مائل ہوتا ہے۔ رکا ہوا کنٹینر اپنے نیٹ ورک کی تقسیم جاری نہیں کرتا۔

پول کی ترتیب بھی جانچیں، کیونکہ ڈیفالٹ پول کی ایک بنیادی حد اور فی نیٹ ورک سابقہ جسامت ہوتی ہے۔ فی نیٹ ورک بڑی تقسیمیں دستیاب بلاک جلدی ختم کر دیتی ہیں، اور یہ گنجائش کی حقیقت ہے، روٹنگ کا مسئلہ نہیں۔

گنتی لکھ لیں۔ یہی بنیادی لکیر ہے جو بتاتی ہے کہ اگلی تبدیلی نے مدد کی یا نہیں۔

ڈیمون راستوں کو کیسے دیکھتا ہے اس کا موازنہ کریں

VPN امیدواروں کے انتخاب پر اثر ڈال سکتا ہے، لیکن کیسے، یہ درست عمل درآمد طے کرتا ہے۔ Linux پر Moby 28.2.2 میں، InferReservedNetworks نیم سرور پتے اور بعض on-link IPv4 راستے جمع کرتا ہے، اور ہر جدول کے ہر راستے کو سادہ طور پر محفوظ نہیں کرتا۔ جمع کیے گئے لنک راستے غیر متعین منزل کے پتے کو بھی خارج کرتے ہیں، اس لیے صرف ایک 0.0.0.0/1 راستہ تمام پتے محفوظ نہیں کرتا۔ کوئی دوسرا وسیع on-link سابقہ، مثلاً 128.0.0.0/1، مانوس 172 اور 192 امیدوار حدود کو کاٹ سکتا ہے۔

VPN جڑنے سے پہلے اور بعد میں ip -4 route show table all کا ڈیمون کے ہوسٹ پر موازنہ کریں۔ فرق ہی ثبوت ہے، اور ورژن ہی دعوے کا دائرہ۔

ایک ریلیز کی ہیورسٹک کو تمام ریلیز پر عام نہ کریں۔ اسی طرح کوئی فورم جواب پالیسی کی تبدیلی بن جاتا ہے۔

وہ سب سے چھوٹی درستی منتخب کریں جو کام کرے

اگر تصدیق شدہ غیر استعمال شدہ نیٹ ورک آپ کو درکار بلاک رکھتا ہے، تو وسیع تراش خراش کے بجائے مالک کے ساتھ اس کی ہدف شدہ ریٹائرمنٹ کی منصوبہ بندی کریں۔ نئے نیٹ ورک کے لیے، واضح طور پر جائزہ لیا گیا غیر استعمال شدہ سب نیٹ خودکار انتخاب پر انحصار مکمل طور پر ٹال دیتا ہے۔ اس سب نیٹ کو پھر بھی حقیقی Docker، LAN اور مطلوبہ VPN منزلوں سے بچنا ہوگا، کیونکہ نجی کا مطلب محفوظ نہیں۔ کسی حقیقی دور دراز سابقے کو روٹ کرنا تقسیم کی خرابی کو ٹوٹی رسائی سے بدل دے گا۔

default-address-pools بدلنا مستقبل کی تقسیموں کے بارے میں وسیع تر پالیسی ہے۔ کوئی غیر متصادم بنیاد اور مناسب تقسیم شدہ جسامت منتخب کریں، اسے موجودہ ڈیمون ترتیبات کے ساتھ ضم کریں، اور دستاویزی ری اسٹارٹ اثر کی منصوبہ بندی کریں۔ موجودہ نیٹ ورک خاموشی سے دوبارہ شمار نہیں کیے جاتے۔

تقسیم کی کامیابی کے لیے کمپنی کے راستوں کی ترسیل بند نہ کریں۔ واضح پتوں کا منصوبہ عام طور پر لازمی پالیسی کو کمزور کیے بغیر مقامی مسئلہ حل کر دیتا ہے۔

تقسیم اور روٹنگ کو الگ الگ قبول کریں

تبدیلی کے بعد، Docker نے واقعی جو سب نیٹ بنایا اس کا معائنہ کریں اور ایپلیکیشن کے VPN اور مقامی انحصارات جانچیں۔ کامیاب تقسیم اور چلنے کے دوران درست روٹنگ دو الگ قبولیتی جانچیں ہیں، اور پہلی کا پاس ہونا دوسری کے لیے ثبوت نہیں۔ اگر ایپ سرنگ کے پیچھے موجود وسیلے تک نہیں پہنچ سکتی، تو آپ کو روٹنگ کا مسئلہ ہے جسے پول کی خرابی چھپا رہی تھی۔ دونوں نتائج ٹکٹ میں درج کریں۔

راستوں کا فرق اور پول کی گنتی تبدیلی کے ریکارڈ کے ساتھ رکھیں، کیونکہ اگلی VPN کلائنٹ اپ ڈیٹ Docker کو چھوئے بغیر پہلے کو بدل سکتی ہے۔

رہنما تب مکمل ہوتا ہے جب کوئی اور ان دونوں جانچوں کو دہرا کر وہی جواب حاصل کر لے۔