VPN पर Wake-on-LAN काम नहीं कर रहा? ब्रॉडकास्ट कभी पार नहीं होता

टनल चालू है और शेयर जवाब देते हैं, फिर भी मशीन सोई रहती है। magic packet लक्ष्य के अपने सेगमेंट में ही भेजना होता है, इसलिए वहाँ एक सहायक रखें।

आप ऑफ़िस की मशीन को सुलाते हैं, घर से VPN लगाते हैं, और वह बंद ही रहती है। टनल चालू है, फ़ाइल शेयर जवाब देते हैं, और राउटर का wake-on-LAN पेज बताता है कि उसने अनुरोध भेज दिया है। हर दिखने वाला संकेत कहता है कि नेटवर्क ठीक है, और इसी वजह से यह मामला उलझा देता है: जो फ़्रेम मशीन को जगाएगा वह कभी उस सेगमेंट तक नहीं पहुँचता जिसमें वह है।

लक्षण सबनेट की ओर इशारा करते हैं, टनल की ओर नहीं

सोए हुए होस्ट पर पिंग विफल होता है, और वह हिस्सा सामान्य है। स्टैंडबाय में मशीन का कोई चालू IP स्टैक नहीं होता, इसलिए वह ARP या ICMP का जवाब नहीं दे सकती, और कोई टनल कॉन्फ़िगरेशन यह नहीं बदलता। उपयोगी जाँच यह है कि क्या उसी LAN में दूसरी मशीन जागती है, और क्या राउटर का अपना जगाने वाला पेज उस होस्ट के लिए काम करता है जो उससे जुड़ा हो।

जैसे ही उसी सेगमेंट में जाँच पास होती है, गड़बड़ी दायरे में है। आप जो भेजने वाला इस्तेमाल कर रहे हैं वह VPN इंटरफ़ेस पर रहता है, और जो पैकेट वह बनाता है वह स्थानीय लिंक के लिए ब्रॉडकास्ट है, इसलिए वह गलत इंटरफ़ेस से निकलता है या बिल्कुल नहीं निकलता। टनल खराब नहीं है; वह गलत तरह का ट्रैफ़िक ढो रहा है। राउटर की एक भी सेटिंग बदलने से पहले पता लगाएँ कि भेजने वाला कौन सा इंटरफ़ेस चुनता है।

magic packet एक फ़्रेम है, सेवा नहीं

पेलोड छह बाइट के स्थिर हेडर 0xFF से शुरू होता है, फिर लक्ष्य कार्ड का हार्डवेयर पता सोलह बार दोहराया जाता है, फिर चार बाइट का वैकल्पिक SecureOn पासवर्ड आता है। भेजने वाले इसे आमतौर पर UDP में लपेटकर पोर्ट 7 या पोर्ट 9 पर भेजते हैं, पर पोर्ट नंबर भेजने वाले और कार्ड के बीच एक परंपरा है, ऐसा सुनने वाला नहीं जिससे जुड़ा जा सके। कोई नहीं सुनता, और कोई जवाब नहीं देता।

मशीन को नेटवर्क इंटरफ़ेस जगाता है, जो स्टैंडबाय रेल से थोड़ी सर्किट्री को बिजली देता रहता है जबकि बाकी सिस्टम बंद रहता है। इसलिए सेटिंग को पूरी बिजली जाने और नींद, दोनों झेलने पड़ते हैं: ऐसा बोर्ड जो बंद होते समय स्टैंडबाय बिजली काट दे, उसके पास अब कोई कार्ड नहीं बचता जो कुछ पाए।

रूटेड टनल इसे क्यों नहीं पहुँचा सकता

रूटेड VPN इंटरफ़ेस दो टनल पतों के बीच एक बिंदु-से-बिंदु IP लिंक है। वह पीयर को संबोधित पैकेट ढोने के लिए है, इसलिए पिंग, SSH और फ़ाइल शेयर उसके ज़रिये सामान्य रूप से चलते हैं। ब्रॉडकास्ट फ़्रेम उस पीयर को संबोधित नहीं है, और सीमित ब्रॉडकास्ट पता राउटर कभी अपने आप आगे नहीं भेजता।

सबनेट की ओर ब्रॉडकास्ट आगे भेजना राउटर की जानबूझकर रखी क्षमता है जिसे ज़्यादातर डिफ़ॉल्ट कॉन्फ़िगरेशन बंद रखते हैं, और तब भी वह उसी सबनेट तक पहुँचाता है, किसी खास सोए कार्ड तक नहीं। सोया होस्ट 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 डेटाग्राम की जगह कच्चा फ़्रेम बनाता है वह उस फ़िल्टर पर नहीं बैठता, इसलिए यह नतीजा निकालने से पहले कि कुछ नहीं भेजा गया, देखें कि आपका औज़ार कौन सी शक्ल इस्तेमाल करता है।

Windows में कार्ड की बराबर जाँच powercfg /devicequery wake_armed है जो उन उपकरणों की सूची देती है जिन्हें सिस्टम जगाने की अनुमति है। उस सूची से गायब नेटवर्क अडैप्टर उसे भेजे गए हर पैकेट को नज़रअंदाज़ करेगा, चाहे फ़्रेम तार पर कितना ही सही दिखे।

फिर खुद जगने और आगे के काम की पुष्टि करें। जो मशीन चालू होती है मगर नाम से अगम्य रहती है उसे स्थिर पता और DNS रिकॉर्ड चाहिए, क्योंकि ब्रॉडकास्ट से नाम हल करना अब भी टनल पार नहीं करता। बेतार जगाना अलग और तार वाले संस्करण से कहीं कम भरोसेमंद क्षमता है, इसलिए VPN को शामिल करने से पहले उसी सेगमेंट में उसे आज़माएँ। टिकट में इंटरफ़ेस का नाम और सहायक का होस्ट लिखें, क्योंकि अगली खराबी आमतौर पर उन्हीं दो तथ्यों से जुड़ी होती है।

संबंधित लेख