নেমস্পেসে চালু হওয়া Firefox URL-টি একটি বিদ্যমান ইনস্ট্যান্সকে দিয়েছে

একটি কমান্ড VPN নেমস্পেসের ভিতরে চলে, একটি Firefox উইন্ডো দেখা যায়, আর পৃষ্ঠাটি তবুও সাধারণ সংযোগ দিয়েই বেরিয়ে যায়। রাউটিং সেটআপ সম্ভবত প্রথমে নতুন করে বানানোর জিনিস নয়। দেখুন কমান্ডটি আপনার প্রত্যাশিত ব্রাউজার ইনস্ট্যান্স তৈরি করেছে, নাকি URL-টি এমন একটিকে দিয়েছে যা আগে থেকেই অন্য কোথাও চলছিল। এই পার্থক্যই এক ধাপে ফলাফল ব্যাখ্যা করে আর nftables-এ এক ঘণ্টা বাঁচায়।

লক্ষণ হলো উইন্ডোটি সঙ্গে সঙ্গে দেখা যায়, কোনো কোল্ড স্টার্ট ছাড়াই।

নতুন উইন্ডো মানেই নতুন ইনস্ট্যান্স নয়

ডেস্কটপ অ্যাপ্লিকেশনগুলো নিয়মিতভাবে বিদ্যমান প্রক্রিয়া পুনরায় ব্যবহার করে। একটি নেটওয়ার্ক নেমস্পেসের ভিতরের লঞ্চার আগে থেকেই চলমান কোনো গ্রহীতাকে সেই নেমস্পেসে সরায় না, কারণ গ্রহীতাটি কখনোই লঞ্চের অংশ ছিল না। Firefox-এর রিমোটিং আচরণ প্রোফাইলের সঙ্গে যুক্ত: আগেই ব্যবহৃত হচ্ছে এমন প্রোফাইলের বিরুদ্ধে লঞ্চ করলে আর্গুমেন্টগুলো তার মালিকের কাছে যায়। নতুন উইন্ডোটি সত্যি; নতুন নেটওয়ার্ক পথটি নয়।

প্রাইভেট ব্রাউজিং আর নতুন-উইন্ডো অপশন নেটওয়ার্ক বিচ্ছিন্নকরণের নিয়ন্ত্রণ নয়।

শুধু উইন্ডো মোডে প্রভাব ফেলা কমান্ড-লাইন ফ্ল্যাগও তা নয়। প্রোফাইল দখল করা থাকলে অনুরোধটি তার মালিক প্রক্রিয়ার কাছে যায়, আর সেই প্রক্রিয়া যে নেমস্পেসে শুরু হয়েছিল সেটিই ধরে রাখে।

আলাদা প্রোফাইলে আলাদা ইনস্ট্যান্স জোর করুন

ব্রাউজারের সমর্থিত প্রোফাইল ওয়ার্কফ্লো দিয়ে তৈরি একটি নিবেদিত প্রোফাইল ব্যবহার করুন এবং স্পষ্টভাবে সেই প্রোফাইল দিয়েই লঞ্চ করুন। যে Firefox বিল্ডগুলো এটি সমর্থন করে, সেখানে --new-instance বিদ্যমান একটির ভিতরে উইন্ডোর বদলে নতুন ইনস্ট্যান্স চায়। ইনস্টল করা বিল্ডের নিজের সাহায্য আউটপুট দেখুন, কারণ উপলব্ধ ফ্ল্যাগ সংস্করণভেদে আলাদা।

একই জীবন্ত প্রোফাইল একসঙ্গে খোলার চেষ্টা করবেন না, আর «প্রোফাইল ব্যবহৃত হচ্ছে» সতর্কতাকে লক ফাইল মুছে ফেলার নির্দেশ হিসেবে নেবেন না।

ব্রাউজারটিকে তার সাধারণ নন-রুট ব্যবহারকারীর অধীনেও চালান। নেটওয়ার্ক সেটআপের প্রায়ই প্রশাসনিক অধিকার লাগে, আর একই পরীক্ষার অংশ বলে ব্রাউজারকেও সেই অধিকার দিতে প্রলুব্ধ হয়। গ্রাফিক্যাল ব্রাউজারের তা লাগে না, আর root হিসেবে চালালে প্রোফাইল ও অনুমতির আলাদা শ্রেণির সমস্যা তৈরি হয়। বিশেষাধিকার আর নেটওয়ার্ক পথকে দুটি স্বতন্ত্র সিদ্ধান্ত হিসেবে রাখুন।

কোন প্রক্রিয়া ট্র্যাফিক বহন করছে তা দেখুন

Linux-এ কোনো প্রক্রিয়ার নেটওয়ার্ক নেমস্পেস তার নেমস্পেস লিংকের মাধ্যমে দৃশ্যমান। আপনি যে প্রক্রিয়া অনুরোধ করছে মনে করেন তার জন্য এটি পড়ুন, তারপর যে প্রক্রিয়া সত্যিই করছে তার জন্য।

readlink /proc/ACTUAL_PID/ns/net

ব্রাউজার একাধিক প্রক্রিয়া চালায়, তাই পরিচয় গুরুত্বপূর্ণ: সংযোগ তৈরি করা কনটেন্ট প্রক্রিয়াটি আপনার প্রথমে পরীক্ষা করা প্রক্রিয়া নাও হতে পারে। লিংকটিকে আপনার অভীষ্ট নেমস্পেসের সঙ্গে মিলিয়ে দেখুন, আর একটি নতুন, নিরীহ অনুরোধ দিয়ে নিশ্চিত করুন যা আপনি একটি ইনস্ট্যান্সের সঙ্গে যুক্ত করতে পারেন। অ্যাট্রিবিউশনই পুরো পরীক্ষা। কোন প্রক্রিয়া সংযোগটি তৈরি করেছে তা বলতে না পারলে আপনি নেমস্পেস পরীক্ষা করেননি।

যখন নেমস্পেস সত্যিই ভুল

কখনো কখনো লঞ্চারটি সত্যিই ব্যর্থ হয় আর নতুন ইনস্ট্যান্সটি ভুল নেমস্পেসে শুরু হয়। যে সার্ভিস বা র‍্যাপার এটি জন্ম দিয়েছে তা দেখুন, কারণ একটি ইউনিট বা ডেস্কটপ এন্ট্রি সেশন বাসের মাধ্যমে পুনরায় চলার সময় নেমস্পেস হারাতে পারে। তারপর ব্রাউজারকে দোষ দেওয়ার আগে সঠিক নেমস্পেসের ভিতরের একটি শেল থেকে আবার পরীক্ষা করুন। একবারে একটি চলকই এটিকে নির্ণয়যোগ্য রাখার একমাত্র উপায়।

ডিসপ্লে ভাগ করলে রিজলভারও ভাগ হয় না।

যদি প্রক্রিয়াটি সঠিক নেমস্পেসে থাকে আর নাম রেজলিউশন তবুও ব্যর্থ হয়,এর রিজলভার পরিবেশকে আলাদা সমস্যা হিসেবে খতিয়ে দেখুন। আরেকটি রাউটিং পরিবর্তন এমন একটি অনুরোধ সরাতে পারে না যা শুরুর আগেই ভুল ইনস্ট্যান্সকে দেওয়া হয়েছিল।