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 संलग्न गर्नुअघि त्यही खण्डमा परीक्षण गर्नुहोस्। टिकटमा इन्टरफेसको नाम र सहयोगीको होस्ट लेख्नुहोस्, किनकि अर्को खराबी प्रायः तीही दुई तथ्यसँग सम्बन्धित हुन्छ।

सम्बन्धित लेखहरू