Wake-on-LAN per VPN neveikia? Transliacija niekada neperžengia

Užmigdote biuro kompiuterį, iš namų įjungiate VPN, o jis lieka išjungtas. Tunelis pakeltas, failų bendrinimai atsako, o maršrutizatoriaus wake-on-LAN puslapis praneša, kad užklausa išsiųsta. Kiekvienas matomas signalas sako, kad tinklas tvarkingas, ir būtent todėl šis atvejis klaidina: kadras, kuris pažadintų kompiuterį, niekada nepasiekia segmento, kuriame jis yra.

Simptomai rodo potinklį, o ne tunelį

Ping į miegančią sistemą nepavyksta, ir ta dalis normalu. Kompiuteris budėjimo režime neturi veikiančio IP kamino, todėl negali atsakyti nei į ARP, nei į ICMP, ir jokia tunelio konfigūracija to nepakeis. Naudingas testas — ar pabunda antras kompiuteris tame pačiame LAN ir ar veikia paties maršrutizatoriaus žadinimo puslapis prijungtam prie jo kompiuteriui.

Kai testas tame pačiame segmente pavyksta, problema yra aprėptyje. Siuntėjas, kurį naudojate, gyvena VPN sąsajoje, o paketas, kurį jis konstruoja, yra transliacija vietinei jungčiai, todėl išeina ne per tą sąsają arba visai neišeina. Tunelis nesugadintas; jis perduoda ne tą srauto tipą. Išsiaiškinkite, kokią sąsają siuntėjas pasirenka, prieš keisdami bent vieną maršrutizatoriaus nustatymą.

Magic packet yra kadras, o ne paslauga

Naudingoji dalis prasideda fiksuota šešių baitų 0xFF antrašte, tada tikslinės plokštės aparatinis adresas, pakartotas šešiolika kartų, tada neprivalomas keturių baitų SecureOn slaptažodis. Siuntėjai tai paprastai įvynioja į UDP į 7 arba 9 prievadą, bet prievado numeris yra susitarimas tarp siuntėjo ir plokštės, o ne klausanti paslauga, prie kurios galima prisijungti. Niekas neklauso ir niekas neatsako.

Kompiuterį žadina tinklo sąsaja, kuri laiko nedidelę grandynų dalį maitinamą iš budėjimo magistralės, kol likusi sistema išjungta. Todėl nustatymas turi išgyventi ir visišką maitinimo praradimą, ir miegą: pagrindinė plokštė, kuri išjungiant nutraukia budėjimo maitinimą, nebeturi plokštės, galinčios ką nors priimti.

Kodėl maršrutizuotas tunelis negali to pristatyti

Maršrutizuota VPN sąsaja yra taškas-į-tašką IP jungtis tarp dviejų tunelio adresų. Ji egzistuoja tam, kad perduotų paketus, adresuotus partneriui, ir todėl ping, SSH bei failų bendrinimai per ją veikia įprastai. Transliacijos kadras nėra adresuotas tam partneriui, o apribotasis transliacijos adresas niekada nepersiunčiamas maršrutizatoriaus be atskiro nurodymo.

Potinkliui nukreiptos transliacijos persiuntimas yra sąmoninga maršrutizatoriaus galimybė, kurią dauguma numatytųjų konfigūracijų išjungia, ir net tada ji pristatoma tam potinkliui, o ne konkrečiai miegančiai plokštei. Miegančioji sistema taip pat negali atsakyti į ARP, todėl maršrutizatorius, kuris prieš persiuntimą bando išspręsti tikslinį adresą, kadrą numeta, kol laukia atsakymo, kuris niekada neateis. Statinis susiejimo įrašas sutvarko tą dalį ir palieka transliacijos aprėpties problemą nepaliestą. Taigi du atskiri apribojimai, ir vieno pašalinimas nieko neduoda kitam.

Trys vietos, kurios iš tikrųjų pasiekia plokštę

Kiekviena veikianti schema padeda kadrą į tikslo segmentą, ir jos skiriasi tuo, kiek trikdo tinklą:

1. Padėkite į tikslinį segmentą įrenginį, kuris visada įjungtas. Maršrutizatorius, NAS ar maža Linux dėžutė, kuri lieka maitinama, gali transliuoti kadrą vietoje, kai tik pasieksite ją per tunelį, ir VPN niekas nesikeičia.
2. Leiskite maršrutizatoriui pačiam išsiųsti kadrą. Daugelis programinės įrangos versijų siūlo žadinimo puslapį, kuris siunčia iš LAN tilto, ir tai veikia tol, kol tikslas yra ant to tilto, o ne už antro maršrutizatoriaus.
3. Sujunkite vietas tiltu su TAP tipo tuneliu, kai transliacijos tikrai turi pereiti. Tai sujungia du transliacijos domenus, atnešdamas transliacijos audras, vieną adresavimo planą ir kiekvieną aptikimo protokolą, matantį abi vietas vienu metu.

Pirmasis variantas yra tas, kurį verta rinktis vienam kompiuteriui. Trečiasis yra tinklo projektavimo sprendimas su nuolatinėmis sąnaudomis, todėl traktuokite jį kaip tokį, o ne kaip greitą taisymą vienam darbalaukiui.

Užrašykite, kuris padėjėjas siunčia kadrą ir ant kurio tilto ar VLAN jis yra. Padėjėjas, siunčiantis ne per tą sąsają, duoda tobulą įrašą ir kompiuterį, kuris niekada nepabunda, o toks derinys kainuoja popietę.

Patikrinkite siuntimą, prieš kaltindami klientą

Pirmiausia patikrinkite tikslinę plokštę, nes joks siuntėjas nepažadins plokštės, kuri neparengta. Toliau pateikta komanda nuskaito palaikomus ir dabartinius žadinimo režimus, kur dabartinė g reikšmė reiškia, kad magic packet įjungtas:

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

Paleiskite įrašą padėjėju, kol vyksta siuntimas, ir perskaitykite jį, o ne darykite prielaidą apie sėkmę. Kadras, paliekantis tinkamą tiltą su transliacijos tiksliniu MAC, yra vienintelis įrodymas, kad siuntimas pavyko; jei įrašas tuščias, siuntėjas pasirinko kitą sąsają ir likusi testo dalis neturi prasmės. Siuntėjas, kuris konstruoja neapdorotą kadrą, o ne UDP datagramą, netelpa į tą filtrą, todėl patikrinkite, kokią formą naudoja jūsų įrankis, prieš darydami išvadą, kad nieko neišsiųsta.

Windows sistemoje atitinkama plokštės patikra yra powercfg /devicequery wake_armed, kuri išvardija įrenginius, kuriems leidžiama žadinti sistemą. Tinklo adapteris, kurio tame sąraše nėra, ignoruos kiekvieną jam siunčiamą paketą, kad ir kaip teisingai kadras atrodytų laide.

Tada patvirtinkite patį pažadinimą ir tęsinį. Kompiuteriui, kuris įsijungia, bet lieka nepasiekiamas pagal vardą, reikia statinio adreso ir DNS įrašo, nes vardų sprendimas transliacija vis dar neperžengia tunelio. Belaidis žadinimas yra atskira ir daug mažiau patikima galimybė nei laidinė versija, todėl išbandykite jį tame pačiame segmente, prieš apskritai įtraukdami VPN. Įrašykite į užklausą sąsajos pavadinimą ir padėjėjo mazgą, nes kitas gedimas paprastai susijęs su tais pačiais dviem faktais.