کنٹینر میں vpnc کے روٹ فلش انتباہ کیوں ظاہر ہوتا ہے

نئے کنٹینر کے لاگز اکثر /proc/sys/net/ipv4/route/flush کے بارے میں Read-only file system شکایت پر ختم ہوتے ہیں، اور اُس لائن کو ایسی ٹنل کا ذمہ دار ٹھہرایا جاتا ہے جو مکمل صحت مند ہو سکتی ہے۔ اُس کے پیچھے کی تحریر کرنل کی اُس اندراج کو نشانہ بناتی ہے جو IPv4 روٹ کیش ختم ہونے کے بعد کوئی مفید کام نہیں کرتی۔ کنٹینر کے اندر /proc/sys صرف پڑھنے کے طور پر ماؤنٹ ہوتا ہے، اس لیے کسی بھی قدر کی آمد سے پہلے ہی ری ڈائریکشن مسترد ہو جاتی ہے اور شیل وہ مستردی چھاپتا ہے۔ فعال ٹنل یہ انتباہ اُس وقت تک چھاپ سکتی ہے جب تک پرانی لائن اسکرپٹ میں رہے، اور --privileged تحریر کو کبھی بامعنی نہیں بناتا۔

اسکرپٹ کیا فلش کرنا چاہتی تھی

پرانے کنکشن اسکرپٹس کیش کی صفائی پر ختم ہوتے تھے: کرنل کی کنٹرول فائل میں قدر لکھنا اور IPv4 اسٹیک سے اپنا روٹنگ کیش چھوڑنے کی درخواست کرنا، تاکہ پرانی اندراجات کی میعاد ختم ہونے کا انتظار کیے بغیر نیا ٹنل روٹ منتخب ہو۔ فائل /proc/sys/net/ipv4/ کے تحت مخاطب تھی، جس نے عمل کو روٹنگ کمانڈ کی بجائے شیل ری ڈائریکشن بنا دیا۔ کرنل 3.6 نے وہ کیش ہٹا دیا، اور ساتھ ہی فلش کے وجود کی وجہ بھی۔ موجودہ ڈیٹا راستے میں کوئی چیز اُس تحریر پر منحصر نہیں۔

اندراج خود ایک پرانی صرف لکھنے والی فائل کے طور پر بچا رہا، اس لیے جو اسکرپٹ اب بھی اُس میں لکھتی ہے وہ حقیقی راستے اور حقیقی اجازت کی جانچ تک پہنچتی ہے۔ ہوسٹ پر تحریر کامیابی واپس کرتی ہے اور کچھ نہیں بدلتی۔ کنٹینر میں وہی ری ڈائریکشن صرف پڑھنے والے /proc/sys سے ٹکراتی ہے اور EROFS کے ساتھ ناکام ہوتی ہے، جسے شیل صرف پڑھنے والے فائل سسٹم کے پیغام کے طور پر چھاپتا ہے۔ جن کرنلز میں راستہ واقعی موجود نہیں، وہاں الفاظ No such file or directory ہو جاتے ہیں، اور نتیجہ نہیں بدلتا۔

دونوں خرابیاں مختلف باتیں کہتی ہیں، اور فرق واضح رکھنے کے قابل ہے۔ Read-only file system کا مطلب ہے کہ کرنل کسی اندراج تک پہنچا اور تحریر سے انکار کیا؛ No such file or directory کا مطلب ہے کہ اندراج جا چکا ہے۔ کوئی پیغام ٹنل ڈیوائس، راستوں یا نام کے حل کے بارے میں رپورٹ نہیں کرتا، اس لیے کوئی بھی زیادہ اختیار کا جواز نہیں بن سکتا۔

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

اختیار شامل کرنے سے پہلے ماؤنٹ اور راستہ جانچیں

تین مطالعے سطحی انتباہ کو حقیقی ناکامی سے الگ کرتے ہیں: کیا نصب شدہ اسکرپٹ اب بھی لائن رکھتی ہے، /proc/sys کیسے ماؤنٹ ہے، اور ایپلیکیشن کی ٹریفک واقعی کہاں جاتی ہے۔ اُنہیں اُسی کنٹینر نیم اسپیس میں یا جس ہوسٹ پر انتباہ ظاہر ہوا وہاں چلائیں، کیونکہ غیر متعلق مشین پر جانچ کسی اور سوال کا جواب دیتی ہے۔

grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10

grep کا جواب دکھنے سے کمزور ہے، کیونکہ ملنا لائن کے وجود کو ثابت کرتا ہے، یہ نہیں کہ وہ بغیر حفاظت کے چلتی ہے؛ دیکھ بھال والی اسکرپٹ تحریر کو ایسی حفاظت کے اندر رکھ سکتی ہے جو اُسے چھوڑ دیتی ہے۔ findmnt -no OPTIONS /proc/sys ماؤنٹ کا فیصلہ براہ راست کرتا ہے، اور اُس آؤٹ پٹ میں ro کا مطلب ہے کہ اُس نقطے کے نیچے ہر تحریر مسترد ہے، اسکرپٹ کچھ بھی کرے۔ پھر راستے کی تلاش دکھاتی ہے کہ ایپلیکیشن کو درکار منزل ٹنل انٹرفیس سے حل ہوتی ہے یا کنٹینر کے ڈیفالٹ گیٹ وے سے۔ ڈیفالٹ گیٹ وے منتخب کرنے والی تلاش کا مطلب ہے کہ ٹنل اوپر آ گئی اور اُس میں کچھ روٹ نہیں ہو رہا، جو روٹنگ کا مسئلہ ہے، اختیار کا نہیں۔

اصلاح واقعی کہاں سے آتی ہے

دیکھ بھال والی اصلاح کنٹینر کے جھنڈوں میں نہیں، اسکرپٹ میں رہتی ہے۔ upstream vpnc-script نے یہ بدل دیا ہے کہ وہ اِس عمل کو کیسے سنبھالتا ہے، اس لیے امیج کے اندر کی نقل کا موجودہ upstream سے موازنہ کریں اور جس پیکج یا امیج بلڈ سے یہ ملتا ہے اُس کے ذریعے اپ ڈیٹ کریں۔ چلتے کنٹینر کے اندر ہاتھ سے تدوین شدہ فائل قابلِ جائزہ نہیں اور اگلی بلڈ تک نہیں رہتی۔

--privileged کی دستاویز ہے کہ وہ تمام صلاحیتیں اور آلات تک وسیع رسائی دیتا ہے، جو کچھ نہ بدلنے والے پیغام کے لیے بڑی رعایت ہے، اس لیے اگر واقعی کوئی صلاحیت غائب ہے تو اُس کا نام لیں۔ اپ ڈیٹ کے بعد راستے کی تلاش دہرائیں اور ایپلیکیشن کو ٹنل استعمال کرنے دیں، کیونکہ خاموش لاگ اور فعال کنکشن الگ نتائج ہیں۔