بے حالت VPN کنارے کی فائر وال پر DNS کا جواب کیوں ناکام ہوتا ہے

سرنگ قائم ہے، کلائنٹ VPN ہوسٹ تک پہنچ سکتے ہیں، مگر ہوسٹ کچھ بھی حل نہیں کر سکتا۔ اس کی اپنی جانے والی استفساریں انٹرفیس سے صاف نکل جاتی ہیں، اس لیے نقص واپسی کے راستے میں ہے: اوپر کے کنارے پر، جو آنے والی ٹریفک کو یہ یاد رکھے بغیر چھانتا ہے کہ ہوسٹ نے ابھی کیا بھیجا۔ سرنگ کی پورٹ کی اجازت اس تبادلے کو بالکل بیان نہیں کرتی۔ DNS استفسار کا جواب الگ بہاؤ ہے، اور اگر کنارہ بے حالت ہے تو واپس آنے کی اجازت کسی نے نہیں دی۔

دونوں تبادلے ایک ہی تبادلہ نہیں ہیں

ٹوپل لکھیں اور غلطی واضح ہو جاتی ہے۔ درخواست کی منزل پورٹ جواب کی ماخذ پورٹ بن جاتی ہے، جو پورٹ 53 کے لیے آنے والا قاعدہ شامل کرتے وقت زیادہ تر لوگوں کے تصور کے عین خلاف ہے:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

منزل پورٹ 53 کا تقاضا کرنے والا آنے والا قاعدہ ہوسٹ پر چلنے والے DNS سننے والے کو بھیجی گئی ٹریفک بیان کرتا ہے، اور یہ بالکل الگ خدمت ہے۔ وہ پتے دستاویزی مثالیں ہیں، اور ماخذ پورٹ کلائنٹ ہر استفسار کے لیے چنتا ہے، اس لیے یہ ایسی قدر نہیں جسے قاعدے میں نقل کر کے یہ توقع رکھی جائے کہ کام جاری رہے گا۔

بے حالت کنارہ بمقابلہ حالت والی ہوسٹ فائر وال

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

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

اجازت کو پورٹ نمبر کے گرد نہیں، پروٹوکول کے گرد بنائیں

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

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

کسی بھی ماخذ پورٹ 53 کی اجازت کیوں حل نہیں ہے

جو قاعدہ ہر اس چیز کو قبول کرتا ہے جو ماخذ پورٹ 53 ہونے کا دعویٰ کرے، وہ ایسا قاعدہ ہے جو بھیجنے والا ہیڈر فیلڈ میں لکھے وہی قبول کرتا ہے۔ پورٹ نمبر بھیجنے والے کی تصدیق نہیں کرتا اور یہ ثابت نہیں کرتا کہ پے لوڈ درست جواب ہے، اس لیے قاعدہ حل کو زیادہ قابلِ بھروسا بنائے بغیر ہوسٹ کی نمائش کو وسیع کرتا ہے۔ رسائی فہرست آسان بنانے کے لیے انہیں بند کرنے کے بجائے ماخذ کی پابندیاں اور کلائنٹ کی اپنی جوابی جانچ، بشمول ماخذ پورٹ کی تصادفییت، برقرار رکھیں۔

اگر حل کنندہ آپ کی کنٹرول کردہ خدمت ہے تو اسے اس کے پتوں تک محدود کرنا کافی ہے۔ اگر یہ عوامی حل کنندہ ہے تو ان پتوں تک محدود کریں جنہیں آپ نے منظور کیا اور انہیں قاعدے کی تفسیر میں لکھیں۔

درست حد پر، درست سمت میں تصدیق کریں

اسی استفسار کے لیے ہوسٹ اور کنارے پر گرفت کریں، اور پیکٹ کی گنتی کے بجائے ٹوپل کا موازنہ کریں۔ ایسی استفسار جو دونوں طرف نظر آئے مگر ہوسٹ کی طرف جواب نظر نہ آئے، آنے والے چھاننے والے کی طرف اشارہ کرتی ہے؛ جو استفسار صرف ہوسٹ کی طرف نظر آئے وہ راستہ بندی یا خود حل کنندہ کی طرف اشارہ کرتی ہے۔ اگر آپ کے پاس صرف UDP کی اجازت ہے تو TCP استفسار کے ساتھ دہرائیں، کیونکہ پہلا امتحان وہی خلا نہیں دیکھ سکتا۔

اسے درست کرنا ہوسٹ کو واقعی درکار DNS تبادلہ مکمل کرتا ہے۔ یہ ہوسٹ کو عوامی حل کنندہ نہیں بناتا، آگے بھیجے گئے VPN بہاؤ کی اجازت نہیں دیتا، اور یہ ثابت نہیں کرتا کہ DNS ہی کسی غیر متعلق سرنگ مسئلے کا سبب تھا۔