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 लाइन नै उपयोगी हो। अपूर्णबाट वास्तविक हार्डवेयर ठेगानामा बदलिने प्रविष्टिको अर्थ मेसिन पुनः सुरु भयो र जवाफ दियो भन्ने हो; कहिल्यै नटुंगिने अनुरोध तपाईं पुग्न खोज्नुभएको सेवातर्फ होइन, उठाउने चरणतर्फ सङ्केत गर्छ।

तपाईंका नोटमा चरणहरू छुट्याउनुहोस्: उठाउने, बुट, सेवा। दोस्रो चरणको असफलता च्याट विन्डोबाट पहिलो चरणको असफलताजस्तै देखिन्छ, र स्थानीय प्रमाणले मात्र तिनलाई छुट्याउँछ।