UFW استثنا برائے VPN جب اینڈ پوائنٹ کا پتہ بدل جائے

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

سرنگ دوبارہ جڑتی ہے، پھر کچھ باہر نہیں جاتا

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

جو پتہ کوئی عوامی تلاش واپس کرتی ہے اسے جما دینا آج کام کرنے دیتا ہے اور کل کو ٹوٹا چھوڑ دیتا ہے۔ یہ ایک بار کی ترمیم ہے، دیکھ بھال کی پالیسی نہیں۔

وہ استثنا بیان کریں جس کا آپ واقعی ارادہ رکھتے ہیں

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

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

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

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

اسے ایک ورک فلو کی طرح تازہ کریں

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

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

کلائنٹ کی منتقلی کو اس کے معاون دوبارہ جڑنے کے راستے سے دیکھیں اور تصدیق کریں کہ اس نے کون سا دور دراز پتہ چنا۔ صرف DNS کی تازہ کاری موجودہ ساکٹ کو نہیں ہلاتی، اور اینڈ پوائنٹ کی استقامت کی ترتیب ریکارڈ بدلنے کے بہت بعد تک کلائنٹ کو پرانے پیر پر رکھ سکتی ہے۔

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

پرانی اجازت کو جان بوجھ کر واپس لیں

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

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

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