VPN द्वारे झोपलेल्या घरातील पीसीला जागवणे: पॅकेट कुठून येते

तुम्ही कनेक्ट करता, राउटर उत्तर देतो, आणि डेस्कटॉप अंधाराच राहतो। टनेल ठीक आहे; मशीनला जागवणारे पॅकेट मशीन जिथे ऐकते त्या सेगमेंटपर्यंत कधीच पोहोचले नाही। राउटरपासून मागच्या दिशेने मार्ग चालत गेल्यास ते कुठे मरते ते दिसते।

तीन उपकरणांची तीन कामे। त्यांना एकत्र मिसळणे हेच जागवण्याचा प्रयत्न अनंत फिरत राहण्याचे नेहमीचे कारण आहे।

दूरच्या क्लायंटपासून सुरुवात करा आणि मार्ग अनुसरा

हॉटेलच्या नेटवर्कवरून तुम्ही घरातील राउटरशी जोडता, जे या चित्रातील एकमेव नेहमी सुरू असलेला टोकबिंदू आहे। तुमच्या लॅपटॉपवर टाइप केलेली जागवण्याची विनंती सामान्य टनेल रहदारी बनते, तुम्ही सांगितलेल्या कोणत्याही गंतव्याकडे पाठवली जाते। तेच गंतव्य पुढील सर्व गोष्टी ठरवते।

जर तुम्ही ते घरातील राउटरच्या LAN पत्त्यावर magic-packet पोर्टवर पाठवले असेल, तर राउटर डेटाग्राम स्वीकारू शकतो आणि घरातील सेगमेंटवर कधीही फ्रेम सोडणार नाही, कारण तिथे काहीही तो पोर्ट ऐकत नाही। जर तुम्ही ते टनेलच्या आत प्रसारित करता, तर ते टनेल इंटरफेसवर थांबते। राउट केलेले टनेल घरातील वायरिंगच्या थर 2 चा विस्तार नाही। मार्ग पायरीपायरीने अनुसरा आणि बंद गल्ली स्पष्ट होते।

हे ठरवणाऱ्या तपासणीसाठी दूरच्या बाजूने एक आदेश आणि घराच्या बाजूने एक आदेश लागतो। विनंती पाठवा, नंतर फ्रेमसाठी घरातील सेगमेंट पाहा।

प्रेषकाला घरातील सेगमेंटवर हलवा

टनेलद्वारे प्रमाणीकरण झाल्यावर राउटर स्वतः जागवण्याचे काम करू शकतो। OpenWrt अशा Wake-on-LAN सेवेचे दस्तऐवजीकरण करते जी उपकरणावर चालते आणि फ्रेम स्थानिकपणे सोडते, आणि हेच नेमके आवश्यक स्वरूप आहे: बाहेर दूरचे प्रमाणीकरण, आत स्थानिक प्रसारण।

ही व्यवस्था जागवण्याचे कार्य सार्वजनिक इंटरनेटपासून दूर ठेवते। इंटरनेटवर नवीन काहीही उघड होत नाही, कारण ट्रिगर तुम्ही आधीच विश्वास ठेवता त्या VPN वरून जातो। पर्याय, पोर्ट-फॉरवर्ड केलेली जागवण्याची सेवा, थोडी सोय इंटरनेटकडे तोंड असलेल्या अशा टोकबिंदूच्या बदल्यात देते जो कोणीही तपासू शकतो।

वर्तुळाकार अवलंबित्वाला स्पष्ट नाव देणे योग्य आहे। डेस्कटॉपवर स्थापित VPN क्लायंट त्या डेस्कटॉपला जागवू शकत नाही, कारण क्लायंट प्रक्रियेला मशीन सुरू असणे आवश्यक आहे। दूरचा प्रवेशबिंदू राउटरवर किंवा नेहमी सुरू असलेल्या दुसऱ्या बॉक्सवर ठेवा, आणि डेस्कटॉप फक्त लक्ष्य राहू द्या।

टनेलला दोष देण्यापूर्वी लक्ष्य तपासा

हा भाग हार्डवेअर ठरवते, VPN नाही, आणि पॉवर स्थिती तो सर्वात आधी ठरवते। अडॅप्टरने जागवण्यास समर्थन द्यावे, फर्मवेअरने झोपेत अडॅप्टरला वीज द्यावी, आणि ऑपरेटिंग सिस्टमने ते अनुमत करण्यासाठी कॉन्फिगर केलेले असावे। स्थगित मशीन बंद केलेल्या मशीनपेक्षा वेगळी बाब आहे, आणि दोन्ही भिंतीवर वीज बंद केलेल्या मशीनपेक्षा वेगळी आहेत। यादीच्या उर्वरित भागावर काम करण्यापूर्वी ही स्थिती निकाली काढा।

फ्रेम प्रत्यक्षात घेणाऱ्या अडॅप्टरवरून हार्डवेअर पत्ता वाचा। Ethernet आणि Wi-Fi दोन्ही असलेल्या डेस्कटॉपला बऱ्याचदा दोन पत्ते असतात, आणि त्यापैकी फक्त एकच जागवण्यास सक्षम असू शकतो। वायरलेस जागवणे ही स्वतःच्या फर्मवेअर आवश्यकता असलेली वेगळी क्षमता आहे, म्हणून चालणारे Ethernet जागवणे Wi-Fi वरून जागवण्याबद्दल काहीही सांगत नाही।

आधी स्थानिक मार्ग सिद्ध करा। त्याच स्विचवरील दुसऱ्या उपकरणावरून magic packet पाठवा आणि मशीन वर येताना पाहा। ते अयशस्वी झाल्यास टनेल डीबगिंगच्या कोणत्याही प्रमाणात मदत होणार नाही, आणि दोष फर्मवेअर, अडॅप्टर सेटिंग्ज किंवा पॉवर स्थितीत आहे।

जागल्यानंतर हव्या त्या सेवेशी कनेक्ट व्हा

जागवणे म्हणजे दूरस्थ प्रवेश नाही। मशीन पुन्हा सुरू झाल्यावरही तिला तिच्या सेवा बूट कराव्या लागतात, पत्ता घ्यावा लागतो आणि तुम्हाला खरोखर आवश्यक असलेले सत्र स्वीकारावे लागते। जागवणे अयशस्वी झाले असा निष्कर्ष काढण्यापूर्वी तिला त्या स्थितीपर्यंत पोहोचण्यास वेळ द्या।

# remote side: trigger the wake through the already-authenticated tunnel
ssh [email protected] 'wol -i br-lan 3c:7a:8f:2b:11:04'

# home side: is the target answering on the LAN?
ping -c 3 10.10.0.42
arp -n 10.10.0.42

arp ओळच उपयुक्त आहे। अपूर्णावरून खऱ्या हार्डवेअर पत्त्यावर बदलणारी नोंद म्हणजे मशीन पुन्हा सुरू झाली आणि उत्तर दिले; जी विनंती कधीच सुटत नाही ती तुम्ही पोहोचू पाहत असलेल्या सेवेकडे नाही, तर जागवण्याच्या टप्प्याकडे निर्देश करते।

तुमच्या नोट्समध्ये टप्पे वेगळे करा: जागवणे, बूट, सेवा। दुसऱ्या टप्प्यातील अपयश चॅट विंडोमधून पहिल्या टप्प्यातील अपयशासारखेच दिसते, आणि फक्त स्थानिक पुरावा त्यांना वेगळे करतो।