Wake-on-LAN yfir VPN virkar ekki? Sendilagið kemst aldrei yfir

Þú setur skrifstofuvélina í svefn, hringir VPN heiman frá þér, og hún helst slökkt. Tunnillinn er uppi, skráadeilingar svara, og wake-on-LAN-síða routersins segir að hann hafi sent beiðnina. Sérhvert sýnilegt merki segir að netið sé í lagi, og einmitt þess vegna er þetta mál ruglingslegt: ramminn sem myndi vekja vélina nær aldrei því segmenti sem hún stendur á.

Einkennin benda á subnettið, ekki tunnilinn

Ping mistekst fyrir sofandi hýsilinn, og sá hluti er eðlilegur. Vél í standby er með enga keyrandi IP-stöflun, getur því ekki svarað ARP eða ICMP, og engin tunnilstilling breytir því. Gagnlega prófið er hvort önnur vél á sama LAN vaknar, og hvort eigin wake-síða routersins virki fyrir hýsil sem er tengdur við hann.

Þegar prófið innan sama segments heppnast er gallinn í umfangi. Sendandinn sem þú notar býr á VPN-viðmótinu, og pakkinn sem hann byggir er broadcast fyrir staðbundnu hlekkinn, svo hann fer út um rangt viðmót eða hvergi. Tunnillinn er ekki bilaður; hann ber ranga tegund af umferð. Finndu út hvaða viðmót sendandinn velur áður en þú breytir einni einustu routerstillingu.

Magic packet er rammi, ekki þjónusta

Farmurinn byrjar á föstum haus úr sex 0xFF-bætum, svo vélbúnaðarfangi markkortsins sextán sinnum, svo valfrjálst SecureOn-lykilorð úr fjórum bætum. Sendendur pakka þessu venjulega í UDP á port 7 eða port 9, en portnúmerið er samkomulag milli sendanda og korts, ekki hlustandi sem þú getur tengst. Ekkert hlustar, og ekkert svarar.

Það sem vekur vélina er netviðmótið, sem heldur litlum hluta rafrása undir spennu frá standby-skinnunni meðan restin af kerfinu er slökkt. Þess vegna verður stillingin að lifa af bæði algjöru rafmagnsleysi og svefni: móðurborð sem sleppir standby-spennunni við slokknun á ekkert kort eftir til að taka við neinu.

Hvers vegna beinleiðis tunnill getur ekki skilað því

Beinleiðis VPN-viðmót er punkt-í-punkt IP-hlekkur milli tveggja tunnilfanga. Hann er til að bera pakka sem eru stílaðir á jafningjann, og þess vegna haga ping, SSH og skráadeilingar sér eðlilega í gegnum hann. Broadcast-rammi er ekki stílaður á þann jafningja, og takmörkuðu broadcast-fanginu er ekki framsent af router án frekari fyrirvara.

Að framsenda subnetsbeint broadcast er viljandi routereiginleiki sem flestar sjálfgefnar stillingar slökkva á, og jafnvel þá skilar það á það subnet en ekki á tiltekið sofandi kort. Sofandi hýsill getur heldur ekki svarað ARP, svo router sem reynir að leysa markfangið fyrir framsendingu sleppir rammanum meðan hann bíður svars sem kemur aldrei. Statísk binding leysir þann hluta og lætur broadcast-umfangs vandamálið ósnortið. Tvær aðskildar takmarkanir þá, og að losna við aðra gerir ekkert fyrir hina.

Þrjár staðsetningar sem ná raunverulega til kortsins

Sérhver starfhæf uppsetning setur rammann á segment marksins, og þær eru ólíkar að því hversu mikið af netinu þær trufla:

1. Settu tæki sem er alltaf á á marksegmentið. Router, NAS eða lítill Linux-kassi sem helst á getur sent rammann á staðnum þegar þú nærð honum í gegnum tunnilinn, og ekkert við VPN-ið breytist.
2. Láttu routerinn senda rammann sjálfur. Margt fastbúnaður býður wake-síðu sem sendir frá LAN-brúnni, sem virkar svo lengi sem markið situr á þeirri brú og ekki bak við annan router.
3. Brýrðu staðina með TAP-tunnli þegar broadcasts verða virkilega að fara yfir. Það sameinar tvö broadcast-lén, með broadcast-stormum, einni fangáætlun og hverju uppgötvunarprotokolli sem sér báða staði í einu.

Fyrsti valmöguleikinn er sá sem ætti að vera fyrir einni vél. Sá þriðji er netkerfishönnunarákvörðun með viðvarandi kostnaði, svo meðhöndlaðu hann sem slíkan og ekki sem skjóta lausn fyrir eina skrifborðsvél.

Skráðu hvaða hjálpari sendir rammann og á hvaða brú eða VLAN hann situr. Hjálpari sem sendir á röngu viðmóti gefur fullkomna upptöku og vél sem vaknar aldrei, og sú samsetning kostar síðdegi.

Sannreyndu sendinguna áður en þú kennir biðlinum um

Athugaðu markkortið fyrst, því enginn sendandi getur vakið kort sem er ekki armert. Skipunin hér að neðan les studdu og núverandi wake-stillingarnar, þar sem núverandi gildi g þýðir að magic packet er virkt:

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

Keyrðu upptökuna á hjálparanum meðan sendingin fer fram, og lestu hana í stað þess að gera ráð fyrir árangri. Ramminn sem fer af réttri brú með broadcast-mark-MAC er eina sönnunin fyrir því að sendingin hafi gengið; er upptakan tóm valdi sendandinn annað viðmót og restin af prófinu er merkingarlaus. Sendandi sem byggir hrárann ramma í stað UDP-gagnapakka passar ekki við það filter, svo athugaðu hvaða form verkfærið þitt notar áður en þú ályktar að ekkert hafi verið sent.

Á Windows er samsvarandi kortstýring powercfg /devicequery wake_armed, sem telur upp tækin sem mega vekja kerfið. Netkort sem vantar á þann lista hunsar hvern pakka sem sendur er á það, hversu rétt ramminn en lítur út á vírnum.

Staðfestu svo vekkingu sjálfa og eftirfylgdina. Vél sem kveikir en helst óaðgengileg eftir nafni þarf statískt fang og DNS-færslu, því broadcast-nafnalausn fer samt ekki yfir tunnilinn. Þráðlaus vekking er aðskilinn og mun óáreiðanlegri eiginleiki en sú snúruð, svo prófaðu hana á sama segmenti áður en VPN kemur yfirhöfuð við sögu. Skrifaðu viðmótsheitið og hýsil hjálparans í miðann, því næsta bilun snýst venjulega um sömu tvö staðreyndir.