dnsmasq پورٹ 53 کو بائنڈ نہیں کر سکتا: وہ ساکٹ تلاش کریں جو اسے رکھے ہوئے ہے

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

اسی ترتیب سے پانچ مراحل: خرابی دوبارہ پیدا کریں، سننے والوں کی فہرست بنائیں، wildcard سمجھیں، کام تفویض کریں، پھر تصدیق کریں۔

مرحلہ 1: خرابی دوبارہ پیدا کریں اور پڑھیں

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

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

مرحلہ 2: مالکان کی فہرست بنائیں

پہلے ساکٹس کی فہرست بنائیں۔ ماخذ پورٹ 53 پر فلٹر دیکھنے کا اختیار ہونے پر دونوں ٹرانسپورٹ اور مالک عمل دکھاتا ہے:

ss -lntup 'sport = :53'

آؤٹ پٹ کو کالموں میں پڑھیں: ٹرانسپورٹ، مقامی پتہ، پورٹ، عمل۔ TCP سننے والا اور UDP سننے والا الگ ساکٹس ہیں، اس لیے ایک کو روکنے سے دوسرا خالی نہیں ہوتا۔ wildcard پتہ ہر انٹرفیس کو ڈھانپتا ہے، یعنی VPN پتہ پہلے ہی لیا ہوا ہے، اگرچہ کوئی سطر اس کا نام لے کر ذکر نہ کرے۔ اور عمل کا نام بتاتا ہے کہ یہ تقسیم کے زیر انتظام ریزالور ہے، کنٹینر ہے، یا پچھلے تجربے نے چلتا چھوڑا ہوا کوئی وجود ہے۔

مرحلہ 3: wildcard کا جال

bind-interfaces اختیار طے کرتا ہے کہ dnsmasq wildcard ساکٹ بائنڈ کرتا ہے یا ہر تشکیل شدہ انٹرفیس کے لیے ایک ساکٹ، جیسا کہ dnsmasq حوالہ بیان کرتا ہے۔ اس کے بغیر dnsmasq wildcard بائنڈ کر کے اس کی بجائے درخواستیں انٹرفیس کے مطابق فلٹر کر سکتا ہے، جو دوسرے ڈیمن کے wildcard رکھنے پر فوراً ناکام ہو جاتا ہے۔ Linux bind-dynamic شامل کرتا ہے، جو آغاز کے بعد بنائے گئے انٹرفیس سنبھالتا ہے، یہ اصل تشویش ہے جب VPN انٹرفیس صرف منسلک ہونے پر ظاہر ہو۔

اسی لیے مختلف انٹرفیس کے لیے تشکیل شدہ دکھنے والے دو ڈیمن پھر بھی ٹکراتے ہیں۔ ٹکراؤ نیت میں نہیں، ساکٹ میں ہے۔ بائنڈ کا طریقہ سوچ سمجھ کر منتخب کریں اور بدلنے سے پہلے اپنے ورژن کے لیے درج رویے کو پڑھیں۔

مرحلہ 4: کام تفویض کریں

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

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

مرحلہ 5: ساکٹ کی تصدیق کریں، پھر راستے کی

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

تین الگ نتائج جنہیں الگ رکھنا چاہیے: ساکٹ موجود ہے، کلائنٹ وہاں پہنچتا ہے، جواب درست ہے۔

کیا نہیں کرنا چاہیے

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

اگر مشین زیر انتظام ہے، ملکیت کا فیصلہ وہاں درج کریں جہاں اگلا منتظم اسے پائے۔ تصویر کے دوبارہ بننے پر پورٹ تصادم لوٹ آتے ہیں۔