Wake-on-LAN kupitia VPN haifanyi kazi? Tangazo haliwahi kuvuka

Unailaza mashine ya ofisini, unaunganisha VPN kutoka nyumbani, nayo inabaki imezimwa. Handaki limeinuka, maeneo ya kushiriki faili yanajibu, na ukurasa wa wake-on-LAN wa kipanga njia unaripoti kuwa umetuma ombi. Kila ishara inayoonekana inasema mtandao uko sawa, na ndiyo sababu kesi hii inachanganya: fremu ambayo ingeamsha mashine haifiki kamwe kwenye sehemu ilipo.

Dalili zinaelekeza kwenye subneti, si kwenye handaki

Ping kwa mwenyeji aliyelala inashindikana, na sehemu hiyo ni ya kawaida. Mashine iliyo katika hali ya kusubiri haina stack ya IP inayofanya kazi, kwa hiyo haiwezi kujibu ARP au ICMP, na hakuna usanidi wa handaki unaobadilisha hilo. Jaribio lenye manufaa ni kama mashine ya pili katika LAN hiyo hiyo inaamka, na kama ukurasa wa kuamsha wa kipanga njia wenyewe unafanya kazi kwa mwenyeji aliyeunganishwa nacho.

Jaribio katika sehemu hiyo hiyo likifaulu, hitilafu iko katika wigo. Mtumaji unaotumia anaishi kwenye kiolesura cha VPN, na pakiti anayounda ni tangazo kwa kiungo cha ndani, kwa hiyo inatoka kwenye kiolesura kisichofaa au haitoki kabisa. Handaki halijavunjika; linabeba aina isiyofaa ya trafiki. Gundua ni kiolesura gani mtumaji anachagua kabla ya kubadilisha mpangilio mmoja wa kipanga njia.

Magic packet ni fremu, si huduma

Mzigo huanza na kichwa kisichobadilika cha baiti sita 0xFF, kisha anwani ya maunzi ya kadi lengwa inarudiwa mara kumi na sita, kisha nenosiri la SecureOn la hiari la baiti nne. Watumaji kwa kawaida huifunga katika UDP kwenda bandari 7 au bandari 9, lakini namba ya bandari ni makubaliano kati ya mtumaji na kadi, si msikilizaji unaoweza kuunganishwa nao. Hakuna kinachosikiliza, na hakuna kinachojibu.

Kinachoamsha mashine ni kiolesura cha mtandao, ambacho huweka mzunguko mdogo ukiwa na nishati kutoka reli ya kusubiri wakati mfumo mzima umezimwa. Ndiyo sababu mpangilio lazima ustahimili upotevu kamili wa nishati na pia usingizi: ubao unaokata nishati ya kusubiri wakati wa kuzima hauna tena kadi ya kupokea chochote.

Kwa nini handaki lenye uelekezaji haliwezi kuifikisha

Kiolesura cha VPN chenye uelekezaji ni kiungo cha IP kutoka nukta hadi nukta kati ya anwani mbili za handaki. Kipo ili kubeba pakiti zinazoelekezwa kwa mwenzake, ndiyo sababu ping, SSH na maeneo ya kushiriki faili hufanya kazi kawaida kupitia hicho. Fremu ya tangazo haielekezwi kwa mwenzake huyo, na anwani ya tangazo iliyozuiliwa haipitishwi kamwe na kipanga njia kienyewe.

Kupitisha tangazo linaloelekezwa kwenye subneti ni uwezo wa makusudi wa kipanga njia ambao usanidi mwingi wa chaguo-msingi huuzima, na hata ukiwa umewashwa hufikisha kwenye subneti hiyo, si kwa kadi maalum iliyolala. Mwenyeji aliyelala pia hawezi kujibu ARP, kwa hiyo kipanga njia kinachojaribu kutatua anwani lengwa kabla ya kupitisha huitupa fremu hiyo wakati kinasubiri jibu ambalo halitakuja. Kipengele cha kufunga tuli kinarekebisha sehemu hiyo na kinaacha tatizo la wigo wa tangazo bila kuguswa. Kwa hiyo vikwazo viwili tofauti, na kuondoa kimoja hakufanyi lolote kwa kingine.

Maeneo matatu yanayofikia kadi kwa kweli

Kila mpangilio unaoweza kufanya kazi huweka fremu katika sehemu ya lengo, na hutofautiana kwa kiasi wanachosumbua mtandao:

1. Weka kifaa kinachowaka kila wakati katika sehemu lengwa. Kipanga njia, NAS au sanduku dogo la Linux linalobaki na nishati linaweza kutuma fremu hapo hapo mara tu unapolifikia kwa handaki, na hakuna kinachobadilika kwenye VPN.
2. Acha kipanga njia kienyewe kitume fremu. Firmware nyingi hutoa ukurasa wa kuamsha unaotuma kutoka daraja la LAN, na hiyo hufanya kazi maadamu lengo lipo kwenye daraja hilo na si nyuma ya kipanga njia cha pili.
3. Unganisha maeneo kwa daraja kwa handaki la aina ya TAP wakati matangazo yanapaswa kuvuka kwa kweli. Hii inaunganisha vikoa viwili vya matangazo, ikileta dhoruba za matangazo, mpango mmoja wa anwani na kila itifaki ya ugunduzi inayoona maeneo yote mawili kwa wakati mmoja.

Chaguo la kwanza ndilo linalopaswa kupewa kipaumbele kwa mashine moja. La tatu ni uamuzi wa usanifu wa mtandao wenye gharama endelevu, kwa hiyo lichukulie hivyo, si kama suluhisho la haraka kwa kompyuta moja ya mezani.

Andika ni msaidizi gani anayetuma fremu na iko kwenye daraja au VLAN gani. Msaidizi anayetuma kutoka kiolesura kisichofaa hutoa rekodi kamili na mashine isiyoamka kamwe, na mchanganyiko huo hutumia mchana mzima.

Hakiki kutuma kabla ya kumlaumu mteja

Angalia kadi lengwa kwanza, kwa sababu hakuna mtumaji anayeweza kuamsha kadi isiyo tayari. Amri hapa chini inasoma hali za kuamsha zinazotumika na za sasa, ambapo thamani ya sasa g inamaanisha magic packet imewashwa:

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

Endesha rekodi kwa msaidizi wakati utumaji unaendelea, na uisome badala ya kudhani mafanikio. Fremu inayoondoka kwenye daraja sahihi na MAC lengwa ya tangazo ndiyo ushahidi pekee kwamba utumaji ulifanya kazi; ikiwa rekodi ni tupu, mtumaji alichagua kiolesura kingine na jaribio lililobaki halina maana. Mtumaji anayeunda fremu mbichi badala ya datagram ya UDP haoani na chujio hilo, kwa hiyo angalia umbo gani chombo chako kinatumia kabla ya kuhitimisha kuwa hakuna kilichotumwa.

Kwenye Windows ukaguzi sawa wa kadi ni powercfg /devicequery wake_armed, unaoorodhesha vifaa vinavyoruhusiwa kuamsha mfumo. Kidapta cha mtandao kinachokosekana kwenye orodha hiyo kitapuuza kila pakiti inayotumwa kwacho, fremu ionekane sawa kiasi gani kwenye kebo.

Kisha thibitisha kuamka wenyewe na ufuatiliaji. Mashine inayowaka lakini inabaki isifikiki kwa jina inahitaji anwani tuli na rekodi ya DNS, kwa sababu utatuzi wa majina kwa tangazo bado hauvuki handaki. Kuamsha bila waya ni uwezo tofauti na usioaminika zaidi kuliko toleo la waya, kwa hiyo lijaribu katika sehemu hiyo hiyo kabla ya kuhusisha VPN. Andika jina la kiolesura na mwenyeji wa msaidizi kwenye tiketi, kwa sababu hitilafu inayofuata kwa kawaida inahusu ukweli huo huo wa mbili.