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 गुंतवण्यापूर्वी त्याच सेगमेंटमध्ये ती तपासा। तिकिटात इंटरफेसचे नाव आणि मदतनीसाचा होस्ट लिहा, कारण पुढील बिघाड सहसा त्याच दोन गोष्टींशी संबंधित असतो।

संबंधित लेख