அலுவலகக் கணினியை உறங்க வைக்கிறீர்கள், வீட்டிலிருந்து 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 ஐ ஈடுபடுத்துவதற்கு முன்பே அதே பிரிவில் அதைச் சோதியுங்கள். டிக்கெட்டில் இடைமுகப் பெயரையும் உதவியாளரின் புரவலனையும் எழுதுங்கள், ஏனெனில் அடுத்த குறைபாடு பொதுவாக அதே இரு உண்மைகளைப் பற்றியதாக இருக்கும்.

தொடர்புடைய கட்டுரைகள்