नेमस्पेस में शुरू किया गया Firefox URL को मौजूदा इंस्टेंस को सौंप दिया
ब्राउज़र का एक कमांड URL किसी दूसरे नेमस्पेस में पहले से चल रही प्रक्रिया को सौंप सकता है। रूटिंग को छूने से पहले पुष्टि करें कि कौन सा इंस्टेंस अनुरोध कर रहा है।
एक कमांड VPN नेमस्पेस के अंदर चलता है, Firefox की विंडो दिखाई देती है, और पेज फिर भी सामान्य कनेक्शन से बाहर जाता है। रूटिंग सेटअप शायद पहली चीज़ नहीं है जिसे फिर से बनाना चाहिए। जाँचें कि कमांड ने वही ब्राउज़र इंस्टेंस बनाया जिसकी आपको उम्मीद थी, या URL उस इंस्टेंस को सौंप दिया जो पहले से कहीं और चल रहा था। यही अंतर नतीजे को एक ही कदम में समझाता है और nftables के एक घंटे बचाता है।
संकेत यह है कि विंडो तुरंत दिखाई देती है, बिना किसी ठंडी शुरुआत के।
नई विंडो नया इंस्टेंस नहीं है
डेस्कटॉप ऐप्लिकेशन नियमित रूप से मौजूदा प्रक्रिया का फिर से उपयोग करते हैं। एक नेटवर्क नेमस्पेस के अंदर का लॉन्चर पहले से चल रहे प्राप्तकर्ता को उस नेमस्पेस में नहीं ले जाता, क्योंकि प्राप्तकर्ता कभी लॉन्च का हिस्सा नहीं था। Firefox का रिमोटिंग व्यवहार प्रोफ़ाइल से जुड़ा है: पहले से इस्तेमाल हो रही प्रोफ़ाइल के विरुद्ध लॉन्च करने पर आर्ग्युमेंट उसके मालिक को मिलते हैं। नई विंडो असली है; नया नेटवर्क पथ नहीं।
निजी ब्राउज़िंग और नई-विंडो विकल्प नेटवर्क अलगाव के नियंत्रण नहीं हैं।
ऐसा कोई कमांड-लाइन फ़्लैग भी नहीं है जो केवल विंडो मोड को प्रभावित करे। अगर प्रोफ़ाइल व्यस्त है, तो अनुरोध उस प्रक्रिया के पास जाता है जो उसका मालिक है, और वह प्रक्रिया वही नेमस्पेस बनाए रखती है जिसमें उसने शुरुआत की थी।
अलग प्रोफ़ाइल पर अलग इंस्टेंस ज़बरदस्ती बनाएँ
ब्राउज़र के समर्थित प्रोफ़ाइल वर्कफ़्लो से बनी समर्पित प्रोफ़ाइल इस्तेमाल करें और उसे स्पष्ट रूप से उसी प्रोफ़ाइल के साथ लॉन्च करें। जो Firefox बिल्ड इसे समर्थित करते हैं, वहाँ --new-instance मौजूदा इंस्टेंस के अंदर विंडो के बजाय नया इंस्टेंस माँगता है। इंस्टॉल किए गए बिल्ड का अपना सहायता आउटपुट देखें, क्योंकि उपलब्ध फ़्लैग संस्करण के अनुसार बदलते हैं।
एक ही जीवित प्रोफ़ाइल को एक साथ खोलने की कोशिश न करें, और «प्रोफ़ाइल उपयोग में है» चेतावनी को लॉक फ़ाइलें हटाने का निर्देश न मानें।
ब्राउज़र को उसके सामान्य गैर-root उपयोगकर्ता के अधीन भी चलाएँ। नेटवर्क सेटअप को अक्सर प्रशासनिक अधिकार चाहिए, और ब्राउज़र को वही अधिकार देना लुभावना है क्योंकि वह उसी प्रयोग का हिस्सा है। ग्राफ़िकल ब्राउज़र को उनकी ज़रूरत नहीं है, और उसे root के रूप में चलाने से प्रोफ़ाइल और अनुमति की अलग श्रेणी की समस्याएँ बनती हैं। विशेषाधिकार और नेटवर्क पथ को दो स्वतंत्र निर्णय रखें।
जाँचें कि कौन सी प्रक्रिया ट्रैफ़िक ले जाती है
Linux पर किसी प्रक्रिया का नेटवर्क नेमस्पेस उसकी नेमस्पेस लिंक से दिखाई देता है। इसे उस प्रक्रिया के लिए पढ़ें जो आपके अनुसार अनुरोध कर रही है, और फिर उस प्रक्रिया के लिए जो वास्तव में कर रही है।
readlink /proc/ACTUAL_PID/ns/net
ब्राउज़र कई प्रक्रियाएँ चलाते हैं, इसलिए पहचान मायने रखती है: कनेक्शन बनाने वाली कंटेंट प्रक्रिया वह न हो जिसे आपने पहले जाँचा था। लिंक की तुलना उस नेमस्पेस से करें जिसका आपने इरादा किया था, और एक नए, हानिरहित अनुरोध से पुष्टि करें जिसे आप एक इंस्टेंस को मान सकें। एट्रिब्यूशन ही पूरा परीक्षण है। अगर आप नहीं बता सकते कि किस प्रक्रिया ने कनेक्शन बनाया, तो आपने नेमस्पेस का परीक्षण नहीं किया।
जब नेमस्पेस वाकई गलत हो
कभी-कभी लॉन्चर वाकई विफल हो जाता है और नया इंस्टेंस गलत नेमस्पेस में शुरू होता है। उस सेवा या रैपर को जाँचें जिसने उसे जन्म दिया, क्योंकि एक यूनिट या डेस्कटॉप एंट्री सत्र बस के ज़रिए फिर से चलने पर नेमस्पेस खो सकती है। फिर ब्राउज़र को दोष देने से पहले सही नेमस्पेस के अंदर के शेल से दोबारा परीक्षण करें। एक बार में एक चर ही इसे निदानयोग्य बनाए रखने का एकमात्र तरीका है।
डिस्प्ले साझा करने से रिज़ॉल्वर भी साझा नहीं होता।
अगर प्रक्रिया सही नेमस्पेस में है और नाम समाधान अब भी विफल होता है,उसके रिज़ॉल्वर परिवेश को अलग समस्या के रूप में जाँचें। कोई दूसरा रूटिंग बदलाव किसी ऐसे अनुरोध को स्थानांतरित नहीं कर सकता जो शुरू होने से पहले ही गलत इंस्टेंस को सौंप दिया गया था।