آپ tun0 کو درست زون میں شامل کرتے ہیں، ایپلیکیشن کام کرنے لگتی ہے، اور اگلے دوبارہ منسلک ہونے پر یہ اصلاح بھاپ بن کر اُڑ جاتی ہے۔ وہی کمانڈ دوبارہ چلانا کام کرتا ہے، جس سے لگتا ہے کہ firewalld بھول گیا۔ وہ بھولا نہیں؛ اُس انٹرفیس پر زیادہ مضبوط دعویٰ رکھنے والی کوئی چیز نے اُسے دوبارہ تفویض کیا۔

زون اُس وقت تک قائم رہتا ہے جب تک انٹرفیس دوبارہ نہ بنے

کسی انٹرفیس کے لیے firewalld زون کی تفویض ایک بائنڈنگ ہے، اور بائنڈنگز انٹرفیس آبجیکٹ کے ساتھ جڑی ہوتی ہیں جیسا وہ اب موجود ہے۔ وہ VPN کلائنٹ جو ڈیوائس کو توڑ کر دوبارہ بناتا ہے نیا آبجیکٹ پیدا کرتا ہے، اور نیا وہیں سے شروع ہوتا ہے جو تفویض کرنے والا جزو کہتا ہے۔ نشان ہر پیکٹ پر نہیں بلکہ ہر دوبارہ منسلک ہونے پر دہرانے کی وجہ یہی ہے۔

یہی منطق ری بوٹ کے رویے کی بھی وضاحت کرتی ہے: رن ٹائم بائنڈنگز ری اسٹارٹ سے نہیں بچتیں، اور مستقل بائنڈنگز صرف اُن ڈیوائسز پر لاگو ہوتی ہیں جنہیں firewalld اپنا سمجھتا ہے۔

کچھ بھی بدلنے سے پہلے معلوم کریں کہ کون سا جزو زون تفویض کرتا ہے۔

کچھ بھی بدلنے سے پہلے تین چیزیں پڑھیں

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

ہر مرحلے پر ڈیوائس کا اصل نام بھی درج کریں، کیونکہ آج tun0 پر اُترنے والی ٹنل کل tun1 پر اُتر سکتی ہے۔

عام نام پر محفوظ بائنڈنگ شناخت کی جانچ نہیں ہے، اور دو منٹ کا ریکارڈ ایک گھنٹے کا اندازہ بچاتا ہے۔

جب NetworkManager کنکشن کا مالک ہو

اگر NetworkManager VPN کنکشن کا انتظام کرتا ہے، تو اُس کی پروفائل زون رکھتی ہے اور کنکشن فعال ہونے پر اُسے firewalld کو دیتی ہے۔ اُسی ڈیوائس کے لیے firewalld کی مستقل انٹرفیس بائنڈنگ پھر نظر انداز کی جا سکتی ہے، کیونکہ مالک NetworkManager ہے۔ زون کو کنکشن پر مقرر کریں، اور یقینی بنائیں کہ آپ VPN پروفائل میں ترمیم کر رہے ہیں، کوئی غیر متعلق جسمانی کنکشن یا عارضی ریکارڈ نہیں۔

اُس خصوصیت کو بدلنا فعال کنکشن پر فوراً اثر ڈال سکتا ہے۔

انتظام کا راستہ دستیاب رکھیں اور لاگو کرنے سے پہلے منزل زون کی پالیسی پڑھیں۔ ifcfg فائل کے ZONE میدان میں ترمیم صرف وہیں درست ہے جہاں وہ فائل اب بھی ترتیب کا ماخذ ہے۔

جب firewalld بائنڈنگ کا مالک ہو

جان بوجھ کر مستحکم انٹرفیس نام والی تنہا ٹنل کے لیے مستقل انٹرفیس تبدیلی ہی درست ذریعہ ہے۔ اُسے آپ کی تعیناتی جو دوبارہ لوڈنگ یا لائف سائیکل استعمال کرتی ہے اُس کے ذریعے لاگو کریں، پھر رن ٹائم حالت دیکھیں، کیونکہ صرف مستقل تدوین فعال ہونے کی نہیں بلکہ ارادے کی وضاحت کرتی ہے۔ دونوں اُتنے وقت تک مختلف رہ سکتے ہیں جتنا دوبارہ لوڈنگ میں لگتا ہے۔

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

صرف ایپلیکیشن کے چلنے کے لیے انٹرفیس کو trusted میں نہ پھینکیں۔

دوبارہ لوڈنگ، دوبارہ منسلک ہونے اور ری بوٹ کی جانچ کریں

تبدیلی صرف اُس وقت مکمل ہوتی ہے جب وہ تینوں برداشت کر لے۔

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

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

مالک، قدر اور متوقع نتیجہ رن بک میں لکھیں، اور اگلی دوبارہ تفویض قابلِ وضاحت ہوگی۔

متعلقہ مضامین