Hindi gumagana ang Wake-on-LAN sa VPN? Hindi kailanman tumatawid ang broadcast

Pinapatulog mo ang makina sa opisina, kinokonekta ang VPN mula sa bahay, at nananatili itong patay. Nakaangat ang tunel, sumasagot ang mga file share, at iniuulat ng pahina ng wake-on-LAN ng router na naipadala nito ang kahilingan. Sinasabi ng bawat nakikitang senyales na maayos ang network, at iyon mismo ang dahilan kung bakit nakakalito ang kasong ito: ang frame na magpapagising sa makina ay hindi kailanman nakakarating sa segment kung saan ito naroroon.

Itinuturo ng mga sintomas ang subnet, hindi ang tunel

Nabibigo ang ping sa natutulog na host, at normal ang bahaging iyon. Ang makinang nasa standby ay walang tumatakbong IP stack, kaya hindi ito makasasagot sa ARP o ICMP, at walang configuration ng tunel ang makakapagpabago niyon. Ang kapaki-pakinabang na pagsubok ay kung nagigising ang pangalawang makina sa parehong LAN, at kung gumagana ang pahina ng paggising ng router para sa host na nakasaksak dito.

Kapag pumasa ang pagsubok sa parehong segment, nasa saklaw ang depekto. Ang sender na ginagamit mo ay nabubuhay sa interface ng VPN, at ang packet na binubuo nito ay broadcast para sa lokal na link, kaya lumalabas ito sa maling interface o hindi lumalabas talaga. Hindi sira ang tunel; nagdadala ito ng maling uri ng trapiko. Alamin kung aling interface ang pinipili ng sender bago mo baguhin ang kahit isang setting ng router.

Ang magic packet ay isang frame, hindi serbisyo

Nagsisimula ang payload sa fixed na header na anim na byte 0xFF, pagkatapos ay inuulit nang labing-anim na beses ang hardware address ng target na card, pagkatapos ay ang opsyonal na SecureOn password na apat na byte. Karaniwang binabalot ito ng mga sender sa UDP papunta sa port 7 o port 9, ngunit ang port number ay kasunduan sa pagitan ng sender at card, hindi listener na maaaring konektahan. Walang nakikinig, at walang sumasagot.

Ang nagpapagising sa makina ay ang network interface, na nagpapanatili ng kaunting circuitry na may kuryente mula sa standby rail habang patay ang natitirang sistema. Kaya dapat survivin ng setting ang buong pagkawala ng kuryente at pati na rin ang pagtulog: ang board na pumuputol sa standby power kapag pinatay ay wala nang card na makakatanggap ng anuman.

Bakit hindi ito maihahatid ng routed tunnel

Ang routed VPN interface ay isang point-to-point IP link sa pagitan ng dalawang tunnel address. Umiiral ito upang magdala ng mga packet na nakaindresse sa peer, at kaya normal ang ping, SSH at file share sa pamamagitan nito. Ang broadcast frame ay hindi nakaindresse sa peer na iyon, at ang limited broadcast address ay hindi kailanman ipinapasa ng router nang kusa.

Ang pagpapasa ng broadcast na nakatuon sa subnet ay sinadyang kakayahan ng router na pinapatay ng karamihan sa default na configuration, at kahit nakabukas ito ay naghahatid sa subnet na iyon, hindi sa partikular na natutulog na card. Hindi rin makasasagot sa ARP ang natutulog na host, kaya ang router na sinusubukang i-resolve ang target address bago magpasa ay itinatapon ang frame habang naghihintay ng sagot na hindi darating. Inaayos ng static binding entry ang bahaging iyon at hinahayaang hindi ginalaw ang problema sa saklaw ng broadcast. Kaya dalawang magkahiwalay na limitasyon, at ang pag-aalis ng isa ay walang ginagawa para sa isa.

Tatlong paglalagay na talagang nakakaabot sa card

Inilalagay ng bawat gumaganang kaayusan ang frame sa segment ng target, at nagkakaiba sila sa lawak ng pang-aabala sa network:

1. Maglagay ng device na laging nakabukas sa target segment. Ang router, NAS o maliit na Linux box na nananatiling may kuryente ay makakapagpadala ng frame nang lokal kapag naabot mo ito sa tunel, at walang nagbabago sa VPN.
2. Hayaan ang router mismo ang magpadala ng frame. Maraming firmware ang nag-aalok ng pahina ng paggising na nagpapadala mula sa LAN bridge, at gumagana ito hangga't nasa bridge na iyon ang target at wala sa likod ng pangalawang router.
3. I-bridge ang mga site gamit ang TAP-style na tunel kapag talagang kailangang tumawid ang broadcast. Pinagsasama nito ang dalawang broadcast domain, kasama ang mga broadcast storm, isang plano ng address at bawat discovery protocol na nakikita ang dalawang site nang sabay.

Ang unang opsyon ang dapat unahin para sa isang makina. Ang ikatlo ay desisyon sa disenyo ng network na may tuloy-tuloy na gastos, kaya ituring mo itong ganoon, hindi bilang mabilisang lunas para sa isang desktop.

Itala kung aling katulong ang nagpapadala ng frame at sa aling bridge o VLAN ito naroon. Ang katulong na nagpapadala sa maling interface ay nagbibigay ng perpektong capture at makinang hindi kailanman nagigising, at ang kombinasyong iyon ay kumakain ng isang hapon.

I-verify ang pagpapadala bago sisihin ang kliyente

Suriin muna ang target card, dahil walang sender ang makakapagising ng card na hindi armado. Binabasa ng utos sa ibaba ang mga sinusuportahang at kasalukuyang wake mode, kung saan ang kasalukuyang halaga ng g ay nangangahulugang nakabukas ang 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

Patakbuhin ang capture sa katulong habang nangyayari ang pagpapadala, at basahin ito sa halip na ipalagay na tagumpay. Ang frame na lumalabas sa tamang bridge na may broadcast na target MAC ay ang tanging ebidensiyang gumana ang pagpapadala; kung walang laman ang capture, pumili ang sender ng ibang interface at walang kabuluhan ang natitirang pagsubok. Ang sender na gumagawa ng raw na frame sa halip na UDP datagram ay hindi umaayon sa filter na iyon, kaya tingnan kung anong anyo ang ginagamit ng iyong tool bago magpasiya na walang naipadala.

Sa Windows ang katumbas na pagsusuri ng card ay powercfg /devicequery wake_armed, na naglilista ng mga device na pinapayagang gisingin ang sistema. Ang network adapter na wala sa listahang iyon ay hindi papansinin ang bawat packet na ipinadala dito, gaano man kawasto ang frame sa kable.

Pagkatapos ay kumpirmahin ang paggising mismo at ang kasunod. Ang makinang bubukas ngunit nananatiling hindi maabot sa pangalan ay kailangan ng static na address at DNS record, dahil ang pag-resolve ng pangalan sa broadcast ay hindi pa rin tumatawid sa tunel. Ang wireless na paggising ay hiwalay at mas hindi mapagkakatiwalaang kakayahan kaysa sa wired na bersyon, kaya subukan ito sa parehong segment bago isangkot ang VPN. Isulat ang pangalan ng interface at ang host ng katulong sa ticket, dahil ang susunod na sira ay karaniwang tungkol sa parehong dalawang katotohanan.