VPN کے ذریعے Wake-on-LAN کام نہیں کر رہا؟ براڈکاسٹ کبھی پار نہیں ہوتا

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

آپ دفتر کی مشین کو سلا دیتے ہیں، گھر سے VPN لگاتے ہیں، اور وہ بند ہی رہتی ہے۔ ٹنل قائم ہے، فائل شیئرز جواب دیتے ہیں، اور روٹر کا wake-on-LAN صفحہ بتاتا ہے کہ اس نے درخواست بھیج دی ہے۔ ہر نظر آنے والا اشارہ کہتا ہے کہ نیٹ ورک ٹھیک ہے، اور اسی لیے یہ معاملہ الجھن میں ڈالتا ہے: وہ فریم جو مشین کو جگائے گا، کبھی اس سیگمنٹ تک نہیں پہنچتا جس میں وہ موجود ہے۔

علامات ذیلی نیٹ ورک کی طرف اشارہ کرتی ہیں، ٹنل کی طرف نہیں

سوئی ہوئی میزبان کو پنگ ناکام ہوتا ہے، اور یہ حصہ معمول ہے۔ اسٹینڈ بائی میں موجود مشین کا کوئی چل رہا IP اسٹیک نہیں ہوتا، اس لیے وہ ARP یا ICMP کا جواب نہیں دے سکتی، اور کوئی ٹنل ترتیب اسے نہیں بدلتی۔ مفید جانچ یہ ہے کہ کیا اسی LAN میں دوسری مشین جاگتی ہے، اور کیا خود روٹر کا جگانے والا صفحہ اس میزبان کے لیے کام کرتا ہے جو اس سے جڑا ہو۔

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

magic packet ایک فریم ہے، کوئی سروس نہیں

پے لوڈ چھ بائٹ کے مقررہ ہیڈر 0xFF سے شروع ہوتا ہے، پھر ہدف کارڈ کا ہارڈویئر پتہ سولہ بار دہرایا جاتا ہے، پھر چار بائٹ کا اختیاری SecureOn پاس ورڈ آتا ہے۔ بھیجنے والے عموماً اسے UDP میں لپیٹ کر پورٹ 7 یا پورٹ 9 پر بھیجتے ہیں، مگر پورٹ نمبر بھیجنے والے اور کارڈ کے درمیان ایک رجحان ہے، ایسا سننے والا نہیں جس سے جڑا جا سکے۔ کوئی نہیں سنتا، اور کوئی جواب نہیں دیتا۔

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

روٹ شدہ ٹنل اسے کیوں نہیں پہنچا سکتا

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

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

تین ایسی جگہیں جو واقعی کارڈ تک پہنچتی ہیں

ہر قابل عمل ترتیب فریم کو ہدف کے سیگمنٹ میں رکھتی ہے، اور وہ اس بات میں مختلف ہیں کہ نیٹ ورک کو کتنا پریشان کرتی ہیں:

  1. ہدف سیگمنٹ میں ہمیشہ روشن رہنے والا آلہ رکھیں۔ روٹر، NAS یا چھوٹا لینکس بکس جو بجلی پر رہے، فریم کو مقامی طور پر بھیج سکتا ہے جیسے ہی آپ ٹنل سے اس تک پہنچیں، اور VPN میں کچھ نہیں بدلتا۔
  2. روٹر کو خود فریم بھیجنے دیں۔ بہت سی فرم ویئر جگانے والا صفحہ دیتی ہیں جو LAN پل سے بھیجتا ہے، اور یہ تب تک چلتا ہے جب تک ہدف اسی پل پر ہو، دوسرے روٹر کے پیچھے نہ ہو۔
  3. جب براڈکاسٹ واقعی پار جانا ضروری ہو تو مقامات کو TAP قسم کے ٹنل سے پل کریں۔ یہ دو براڈکاسٹ ڈومین ملا دیتا ہے، ساتھ براڈکاسٹ طوفان، ایک ہی پتہ منصوبہ اور ہر دریافت پروٹوکول جو دونوں مقامات کو بیک وقت دیکھتا ہے۔

پہلا اختیار ایک مشین کے لیے ترجیحی ہے۔ تیسرا مسلسل لاگت والا نیٹ ورک ڈیزائن کا فیصلہ ہے، اس لیے اسے ایسا ہی سمجھیں، ایک ڈیسک ٹاپ کے لیے فوری حل نہ سمجھیں۔

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

کلائنٹ کو الزام دینے سے پہلے بھیجنے کی تصدیق کریں

پہلے ہدف کارڈ دیکھیں، کیونکہ کوئی بھیجنے والا ایسی کارڈ کو نہیں جگا سکتا جو تیار نہ ہو۔ نیچے دیا گیا حکم تائید شدہ اور موجودہ جگانے کے طریقے پڑھتا ہے، جہاں موجودہ g قدر کا مطلب ہے کہ magic packet روشن ہے:

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

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

ونڈوز میں کارڈ کی مساوی جانچ powercfg /devicequery wake_armed ہے جو ان آلات کی فہرست دیتی ہے جنہیں نظام جگانے کی اجازت ہے۔ اس فہرست سے غائب نیٹ ورک اڈاپٹر ہر اس پیکٹ کو نظر انداز کرے گا جو اسے بھیجا جائے، چاہے فریم تار پر کتنا ہی درست دکھے۔

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

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