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 ను జోక్యం చేసుకోకముందే అదే సెగ్మెంటులో దాన్ని పరీక్షించండి. టికెట్‌లో ఇంటర్‌ఫేస్ పేరు మరియు సహాయకుడి హోస్ట్ రాయండి, ఎందుకంటే తర్వాతి లోపం సాధారణంగా అదే రెండు వాస్తవాలకు సంబంధించి ఉంటుంది.

సంబంధిత వ్యాసాలు