mDNS وائر گارڈ پر: تین دروازے اس سے پہلے کہ peer جواب دے
Avahi کو موزوں انٹرفیس، گروپ تک راستہ اور منزل کا مالک peer چاہیے۔ تین دروازے، تین الگ جانچیں اور کوئی تقسیم نہیں۔
WireGuard ڈیوائس پر multicast پرچم لگانا انٹرفیس کو دریافت سافٹ ویئر کے لیے موزوں بناتا ہے، اور پرچم صرف یہی کرتا ہے۔ یہ پروٹوکول کو نہیں بتاتا کہ گروپ پیکٹ کہاں جانا چاہیے، اور کئی peers والی ڈیوائس پر کوئی ایک واضح جواب نہیں ہوتا۔ چل رہے ڈیمن اور دریافت شدہ سروس کے درمیان تین الگ دروازے کھڑے ہیں۔
اِنہیں ترتیب سے جانچیں، کیونکہ ایک سے گزرنا اگلے کے بارے میں کچھ نہیں بتاتا۔
پہلا دروازہ: پرچم اور ڈیمن کی پالیسی
لینکس WireGuard ڈیوائس ARP کے بغیر پوائنٹ ٹو پوائنٹ لنک کے طور پر بنائی جاتی ہے، اور طے شدہ طور پر multicast پرچم نہیں رکھتی۔ پرچم شامل کرنا مقامی انٹرفیس کی تبدیلی ہے، جو ڈیوائس کا انتظام کرنے والا کوئی بھی کرتا ہے۔ Avahi کا اس کے اوپر دنیا کا اپنا نظریہ ہے، اور اس کی طے شدہ پالیسی پوائنٹ ٹو پوائنٹ انٹرفیس مکمل طور پر چھوڑ دیتی ہے۔ اس لیے ایک پیکٹ کے حرکت کرنے سے پہلے دو آزاد اہلیت کی جانچیں لاگو ہوتی ہیں۔
لہٰذا ڈیمن کو واضح فیصلہ چاہیے، صرف چلتی ہوئی پروسیس نہیں۔ اس کے دستاویزی کنٹرولز میں allow-interfaces، deny-interfaces اور allow-point-to-point شامل ہیں، اور آخری وہ ترتیب ہے جسے لوگ نظر انداز کرتے ہیں۔
نیچے دی گئی جانچیں لنک کے پرچم، multicast راستہ اور یہ بتاتی ہیں کہ ڈیمن کی ترتیب بالکل پارس ہوتی ہے یا نہیں:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkکامیابی سے شروع ہوا ڈیمن ضروری نہیں کہ آپ کے لیے اہم انٹرفیس پر ساکٹ کھول چکا ہو۔ سروس کی حالت کو کوریج کے برابر سمجھنے کے بجائے اس کی مؤثر ترتیب پڑھیں۔
دوسرا دروازہ: گروپ تک راستہ
دوسرا دروازہ عام روٹنگ ہے۔ 224.0.0.251 پر بھیجا گیا پیکٹ باقی سب کی طرح فارورڈنگ جدول کی پیروی کرتا ہے، اور اگر جدول اسے طبعی LAN انٹرفیس سے باہر بھیجتا ہے تو کوئی WireGuard ترتیب اسے نہیں بدلے گی۔ پہلے راستہ درست کریں، پھر باقی تفتیش مختصر ہو جائے گی۔ کسی بھی peer کلید کو چھونے سے پہلے دیکھیں کہ کرنل گروپ پتے کے بارے میں کیا بتاتا ہے۔
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
کسی مخصوص راستے کے بغیر، کرنل لنک کی اپنی multicast سنبھالنے کی طرف لوٹ آتا ہے، اسی لیے طے شدہ صورت ہموار LAN پر درست دکھائی دیتی ہے اور اسی گروپ ٹریفک کے سرنگ سے باہر جانے کے لمحے غلط ہو جاتی ہے۔ ناکامی بھیجنے والے کی طرف سے خاموش ہے: استفسار کہیں جاتا ہے، اور جواب کبھی نہیں آتا۔
تیسرا دروازہ: WireGuard ہر پیکٹ کے لیے ایک peer چنتا ہے
WireGuard باہر جانے والا peer اجازت شدہ پتوں کے مجموعوں میں منزل تلاش کر کے چنتا ہے، اور لینکس کا ترسیلی راستہ یہ تلاش ہر پیکٹ کے لیے ایک بار کرتا ہے۔ نتیجہ ایک ہی ہوتا ہے، اور پیکٹ اسی peer کے لیے خفیہ کیا جاتا ہے۔ ایک ہی گروپ سابقہ کئی peers کی اجازت شدہ فہرستوں میں آنا رکنیت یا نقل پیدا نہیں کرتا؛ یہ ایک مبہم تلاش بناتا ہے جو اُن میں سے کسی ایک پر طے ہوتی ہے۔
دو سروں والے مخصوص لنک پر یہی وہ چیز ہے جو آپ چاہتے ہیں، کیونکہ جان بوجھ کر لے جایا جانے والا گروپ ٹریفک کے لیے صرف ایک مطلوبہ وصول کنندہ ہے۔ پانچ peers والے انٹرفیس پر یہ ایک حد ہے، خصوصیت نہیں، اور اصلاح کسی ایک peer کی ترتیب میں نہیں بلکہ ڈیزائن میں ہونی چاہیے۔
تقسیمی ڈیزائن کو واضح ریلے، الگ لنکس یا بالکل مختلف دریافت طریقہ چاہیے۔ ہر کلائنٹ گیٹ وے کو پنگ کر سکتا ہے اس لیے دو سروں والی ترکیب کو کثیر کلائنٹ حل کے طور پر شائع کرنا — اسی طرح یہ غلط طور پر نصب ہوتا ہے۔
آنے والی سمت الگ طریقے سے جانچی جاتی ہے: موصول شدہ پیکٹ کا ماخذ تصدیق شدہ peer کی اجازت شدہ فہرست کے اندر ہونا چاہیے۔ وہاں multicast منزل شامل کرنا بھیجنے والے کی حقیقی ماخذ ملکیت کی جگہ نہیں لیتا۔
انعکاس ایک حد ہے، پل نہیں
Avahi کا منعکس کنندہ اپنے منتخب کردہ انٹرفیسوں کے درمیان mDNS پیغامات کو اطلاقی سطح پر دوبارہ پیدا کرتا ہے۔ یہ نیٹ ورکس کے درمیان دریافت کی حد ہے، ایتھرنیٹ پل نہیں اور عام multicast راؤٹر نہیں۔ ایک ہی نیٹ ورکس سے جڑے دو منعکس کنندہ خوشی سے مکرر اعلانات کا حلقہ بنا دیتے ہیں۔
انعکاس سروس کے نام اور اُن کا میٹاڈیٹا دوسرے نیٹ ورک کے حوالے بھی کرتا ہے، جو روٹنگ کے فیصلے کی طرح رازداری کا فیصلہ بھی ہے۔ منتخب انٹرفیس محدود کریں، اور جہاں نصب شدہ ورژن معاونت کرے وہاں سروس فلٹر استعمال کریں، تاکہ صرف وہی اعلانات حد پار کریں جو مجاز صارف کو درکار ہیں۔
دریافت اور استعمال الگ نتائج رہتے ہیں۔ کلائنٹ ایسی سروس کا اعلان دیکھ سکتا ہے جس کا اعلان شدہ پتہ کلائنٹ کی جگہ سے ناقابل رسائی ہو، یا جس کا پورٹ اس کی رسائی پالیسی مسترد کرے۔ اعلان ظاہر ہونے کے بعد سروس کنکشن کی تصدیق کریں، اور اگر ایپلیکیشن مستحکم DNS نام یا واضح سرور پتہ معاونت کرتی ہے تو لنک مقامی دریافت بڑھانے کے بجائے اسی کو ترجیح دیں۔ خفیہ کلید روٹنگ کی وضاحت اُس منزل پر مبنی peer انتخاب کا احاطہ کرتی ہے جس پر یہ سب منحصر ہے۔