namespace میں شروع کیا گیا Firefox نے URL کو موجودہ انسٹینس کے حوالے کر دیا

ایک کمانڈ VPN namespace کے اندر چلتی ہے، Firefox کی ونڈو نمودار ہوتی ہے، اور صفحہ پھر بھی عام کنکشن سے باہر جاتا ہے۔ راؤٹنگ سیٹ اپ شاید پہلی چیز نہیں ہے جسے دوبارہ بنانا چاہیے۔ جانچیں کہ کمانڈ نے وہی براؤزر انسٹینس بنایا جس کی آپ توقع رکھتے تھے، یا URL اس انسٹینس کو دے دیا جو پہلے سے کہیں اور چل رہا تھا۔ یہی فرق نتیجہ کو ایک ہی قدم میں سمجھاتا ہے اور nftables کا ایک گھنٹہ بچاتا ہے۔

اشارہ یہ ہے کہ ونڈو فوراً نمودار ہوتی ہے، بغیر کسی ٹھنڈی شروعات کے۔

نئی ونڈو نیا انسٹینس نہیں ہے

ڈیسک ٹاپ ایپلیکیشنز معمول کے مطابق موجودہ عمل کو دوبارہ استعمال کرتی ہیں۔ ایک نیٹ ورک namespace کے اندر کا لانچر پہلے سے چل رہے وصول کنندہ کو اس namespace میں منتقل نہیں کرتا، کیونکہ وصول کنندہ کبھی لانچ کا حصہ نہیں تھا۔ Firefox کا ریموٹ کنٹرول رویہ پروفائلز سے جڑا ہے: پہلے سے استعمال ہو رہے پروفائل کے خلاف لانچ کرنے پر آرگیومنٹس اس کے مالک کو ملتے ہیں۔ نئی ونڈو حقیقی ہے؛ نیا نیٹ ورک راستہ نہیں۔

نجی براؤزنگ اور نئی ونڈو کا اختیار نیٹ ورک علیحدگی کے کنٹرول نہیں ہیں۔

ایسا کوئی کمانڈ لائن فلیگ بھی نہیں ہے جو صرف ونڈو موڈ پر اثر ڈالے۔ اگر پروفائل مصروف ہے تو درخواست اس عمل کے پاس جاتی ہے جو اس کا مالک ہے، اور وہ عمل وہی namespace برقرار رکھتا ہے جس میں اس نے آغاز کیا تھا۔

مختلف پروفائل پر مختلف انسٹینس نافذ کریں

براؤزر کے معاون پروفائل ورک فلو سے بنایا گیا مخصوص پروفائل استعمال کریں اور اسے واضح طور پر اسی پروفائل کے ساتھ لانچ کریں۔ جو Firefox بلڈز اسے معاونت کرتے ہیں، وہاں --new-instance موجودہ انسٹینس کے اندر ونڈو کے بجائے نیا انسٹینس مانگتا ہے۔ نصب شدہ بلڈ کی اپنی مدد کا آؤٹ پٹ دیکھیں، کیونکہ دستیاب فلیگز ورژن کے مطابق مختلف ہوتے ہیں۔

ایک ہی زندہ پروفائل کو بیک وقت کھولنے کی کوشش نہ کریں، اور «پروفائل استعمال میں ہے» والی وارننگ کو لاک فائلیں حذف کرنے کی ہدایت نہ سمجھیں۔

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

جانچیں کہ کون سا عمل ٹریفک اٹھا رہا ہے

Linux پر، کسی عمل کا نیٹ ورک namespace اس کے namespace لنک سے نظر آتا ہے۔ اسے اس عمل کے لیے پڑھیں جو آپ کے خیال میں درخواست کر رہا ہے، پھر اس عمل کے لیے جو واقعی کر رہا ہے۔

readlink /proc/ACTUAL_PID/ns/net

براؤزر کئی عمل چلاتے ہیں، اس لیے شناخت اہم ہے: کنکشن بنانے والا مواد کا عمل وہ نہ ہو جسے آپ نے پہلے جانچا تھا۔ لنک کا موازنہ اس namespace سے کریں جس کا آپ نے ارادہ کیا تھا، اور ایک نئی، بے ضرر درخواست سے تصدیق کریں جسے آپ ایک انسٹینس سے منسوب کر سکیں۔ منسوب کرنا ہی پورا امتحان ہے۔ اگر آپ نہیں بتا سکتے کہ کس عمل نے کنکشن بنایا، تو آپ نے namespace کا امتحان نہیں کیا۔

جب namespace واقعی غلط ہو

کبھی کبھی لانچر واقعی ناکام ہوتا ہے اور نیا انسٹینس غلط namespace میں شروع ہوتا ہے۔ اس خدمت یا ریپر کو جانچیں جس نے اسے پیدا کیا، کیونکہ کوئی یونٹ یا ڈیسک ٹاپ اندراج سیشن بس کے ذریعے دوبارہ چلنے پر namespace کھو سکتا ہے۔ پھر براؤزر کو قصوروار ٹھہرانے سے پہلے درست namespace کے اندر کے شیل سے دوبارہ امتحان کریں۔ ایک وقت میں ایک متغیر ہی اسے تشخیص کے قابل رکھنے کا واحد طریقہ ہے۔

ڈسپلے شیئر کرنا resolver بھی شیئر نہیں کرتا۔

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