VPN-ի միջոցով Wake-on-LAN-ը չի աշխատում? Հաղորդումը երբեք չի անցնում

Դուք գրասենյակի մեքենան քնեցնում եք, տնից միանում VPN-ին, և այն մնում է անջատված։ Թունելը բարձրացված է, ֆայլային համօգտագործումները պատասխանում են, իսկ երթուղիչի wake-on-LAN էջը հաղորդում է, որ հարցումն ուղարկել է։ Յուրաքանչյուր տեսանելի ազդանշան ասում է, որ ցանցը կարգին է, և հենց դրա համար է այս դեպքը շփոթեցնող: շրջանակը, որը կարթնացներ մեքենան, երբեք չի հասնում այն սեգմենտին, որտեղ այն գտնվում է։

Ախտանշանները ցույց են տալիս ենթացանցը, ոչ թե թունելը

Ping-ը քնած հոսթին չի անցնում, և այդ մասը նորմալ է։ Սպասման ռեժիմում գտնվող մեքենան աշխատող IP կույտ չունի, ուստի չի կարող պատասխանել ARP-ին կամ ICMP-ին, և ոչ մի թունելի կարգավորում դա չի փոխում։ Օգտակար փորձարկումն այն է, թե արդյոք արթնանում է նույն LAN-ի երկրորդ մեքենան, և արդյոք աշխատում է հենց երթուղիչի արթնացման էջը դրան միացված հոսթի համար։

Հենց նույն սեգմենտում փորձարկումն անցնում է, խնդիրը տարածության մեջ է։ Ձեր օգտագործած ուղարկողը ապրում է VPN ինտերֆեյսում, և այն փաթեթը, որը նա կառուցում է, հեռարձակում է տեղական կապի համար, ուստի դուրս է գալիս սխալ ինտերֆեյսով կամ ընդհանրապես դուրս չի գալիս։ Թունելը կոտրված չէ; այն կրում է սխալ տեսակի հոսք։ Պարզեք, թե որ ինտերֆեյսն է ընտրում ուղարկողը, նախքան երթուղիչի թեկուզ մեկ կարգավորում փոխելը։

Magic packet-ը շրջանակ է, ոչ ծառայություն

Բեռը սկսվում է վեց բայթանոց ֆիքսված վերնագրով, 0xFF, ապա թիրախ քարտի ապարատային հասցեն կրկնվում է տասնվեց անգամ, ապա գալիս է ընտրովի չորս բայթանոց SecureOn գաղտնաբառ։ Ուղարկողները սովորաբար սա փաթաթում են UDP-ի մեջ 7 կամ 9 պորտին, սակայն պորտի համարը ուղարկողի և քարտի միջև պայմանավորվածություն է, ոչ թե լսող ծառայություն, որին կարելի է միանալ։ Ոչինչ չի լսում, և ոչինչ չի պատասխանում։

Մեքենային արթնացնում է ցանցային ինտերֆեյսը, որը սպասման ավտոբուսից սնուցում է սխեմաների փոքր մասը, քանի դեռ համակարգի մնացած մասը անջատված է։ Այդ պատճառով կարգավորումը պետք է դիմանա և՛ ամբողջական էլեկտրաէներգիայի կորստին, և՛ քնին: մայրական տախտակը, որն անջատելիս կտրում է սպասման սնուցումը, այլևս քարտ չունի, որը ինչ-որ բան կընդունի։

Ինչու երթուղավորված թունելը չի կարող այն հասցնել

Երթուղավորված VPN ինտերֆեյսը կետ-կետ IP կապ է երկու թունելի հասցեների միջև։ Այն գոյություն ունի զուգընկերոջն ուղղված փաթեթներ կրելու համար, և դրա պատճառով ping-ը, SSH-ը և ֆայլային համօգտագործումները դրա միջով սովորաբար են վարվում։ Հեռարձակման շրջանակը ուղղված չէ այդ զուգընկերոջը, և սահմանափակ հեռարձակման հասցեն երթուղիչի կողմից երբեք ինքնաբերաբար չի փոխանցվում։

Ենթացանցին ուղղված հեռարձակման փոխանցումը երթուղիչի դիտավորյալ հնարավորությունն է, որը անջատում են լռելյայն կարգավորումների մեծ մասը, և նույնիսկ այդ դեպքում այն հասցվում է այդ ենթացանցին, ոչ թե կոնկրետ քնած քարտի։ Քնած հոսթը նաև չի կարող պատասխանել ARP-ին, ուստի երթուղիչը, որը մինչ փոխանցումը փորձում է լուծել թիրախ հասցեն, գցում է շրջանակը, մինչ սպասում է պատասխանի, որը երբեք չի գա։ Ստատիկ կապակցման գրառումը շտկում է այդ մասը և անձեռնմխելի է թողնում հեռարձակման տարածության խնդիրը։ Այսպիսով՝ երկու առանձին սահմանափակում, և մեկի վերացումը ոչինչ չի անում մյուսի համար։

Երեք տեղաբաշխում, որոնք իսկապես հասնում են քարտին

Ցանկացած աշխատունակ դասավորություն շրջանակը դնում է թիրախի սեգմենտում, և դրանք տարբերվում են նրանով, թե որքան են խանգարում ցանցին:

1. Թիրախ սեգմենտում տեղադրեք սարք, որը միշտ միացված է։ Երթուղիչը, NAS-ը կամ փոքր Linux տուփը, որը մնում է սնուցված, կարող է շրջանակը տեղայնորեն ուղարկել, հենց որ թունելով հասնեք դրան, և 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-ն ընդհանրապես գործի դնելը։ Գրեք տոմսում ինտերֆեյսի անունը և օգնականի հոսթը, քանի որ հաջորդ խափանումը սովորաբար վերաբերում է նույն երկու փաստերին։