Wake-on-LAN dros VPN ddim yn gweithio? Nid yw'r darllediad byth yn croesi

Rydych chi'n rhoi peiriant y swyddfa i gysgu, yn deialu'r VPN o gartref, ac mae'n aros i ffwrdd. Mae'r twnnel i fyny, mae rhannu ffeiliau'n ateb, ac mae tudalen wake-on-LAN y llwybrydd yn adrodd iddo anfon y cais. Mae pob signal gweladwy'n dweud bod y rhwydwaith yn iawn, a dyna'n union pam mae'r achos hwn yn ddryslyd: nid yw'r ffrâm a fyddai'n deffro'r peiriant byth yn cyrraedd y segment lle mae'n byw.

Mae'r symptomau'n pwyntio at yr is-rwydwaith, nid at y twnnel

Mae ping i'r hôst sy'n cysgu'n methu, ac mae'r rhan honno'n normal. Nid oes gan beiriant mewn segurfa stac IP sy'n rhedeg, felly ni all ateb ARP nac ICMP, ac nid oes unrhyw ffurfweddiad twnnel yn newid hynny. Y prawf defnyddiol yw a yw ail beiriant yn yr un LAN yn deffro, ac a yw tudalen deffro'r llwybrydd ei hun yn gweithio i hôst sy'nghysylltiedig ag ef.

Unwaith y bydd'r prawf yn yr un segment yn pasio, mae'r nam yn y cwmpas. Mae'r anfonydd rydych chi'n ei ddefnyddio'n byw ar ryngwyneb y VPN, ac mae'r pecyn mae'n ei adeiladu'n ddarllediad ar gyfer y cyswllt lleol, felly mae'n mynd allan drwy'r rhyngwyneb anghywir neu ddim o gwbl. Nid yw'r twnnel wedi torri; mae'n cario'r math anghywir o draffig. Darganfyddwch pa ryngwyneb y mae'r anfonydd yn ei ddewis cyn i chi newid unrhyw osodiad llwybrydd.

Mae magic packet yn ffrâm, nid yn wasanaeth

Mae'r llwyth yn dechrau â phenawd sefydlog o chwe beit 0xFF, yna cyfeiriad caledwedd y cerdyn targed yn cael ei ailadrodd un ar bymtheg o weithiau, yna cyfrinair SecureOn dewisol o bedwar beit. Mae anfonwyr fel arfer yn ei lapio mewn UDP i borth 7 neu borth 9, ond mae rhif y porth yn gonfensiwn rhwng anfonydd a cherdyn, nid yn wrandawr y gellir cysylltu ag ef. Nid oes unrhyw beth yn gwrando, ac nid oes unrhyw beth yn ateb.

Yr hyn sy'n deffro'r peiriant yw'r rhyngwyneb rhwydwaith, sy'n cadw ychydig o gylchedwaith wedi'i bweru o'r rheilen segurfa tra bo gweddill y system i ffwrdd. Dyna pam mae'r gosodiad yn gorfod goroesi colled pŵer lawn yn ogystal â chwsg: nid oes gan fwrdd sy'n torri'r pŵer segurfa wrth ddiffodd gerdyn i dderbyn unrhyw beth.

Pam na all twnnel llwybrol ei ddanfon

Mae rhyngwyneb VPN llwybrol yn gyswllt IP pwynt-i-bwynt rhwng dau gyfeiriad twnnel. Mae'n bodoli i gario pecynnau a gyfeiriwyd at y partner, a dyna pam mae ping, SSH a rhannu ffeiliau'n ymddwyn yn normal drwyddo. Nid yw ffrâm darlledu wedi'i chyfeirio at y partner hwnnw, ac ni fydd llwybrydd byth yn anfon cyfeiriad darlledu cyfyngedig ymlaen o'i wirfodd.

Mae anfon darllediad sy'n wynebu'r is-rwydwaith ymlaen yn gallu bwriadol gan y llwybrydd y mae'r rhan fwyaf o ffurfweddiadau rhagosodedig yn ei ddiffodd, a hyd yn oed wedyn mae'n danfon i'r is-rwydwaith hwnnw, nid i gerdyn penodol sy'n cysgu. Ni all hôst sy'n cysgu ateb ARP chwaith, felly mae llwybrydd sy'n ceisio datrys y cyfeiriad targed cyn anfon ymlaen yn gollwng y ffrâm tra bo'n aros am ateb na ddaw byth. Mae cofnod rhwymo statig yn trwsio'r rhan honno ac yn gadael problem cwmpas y darllediad heb ei chyffwrdd. Dau gyfyngiad ar wahân, felly, ac nid yw dileu un yn gwneud dim i'r llall.

Tri lleoliad sy'n cyrraedd y cerdyn mewn gwirionedd

Mae pob trefniant y gellir ei weithredu'n rhoi'r ffrâm yn segment y targed, ac maent yn wahanol yn y maint maent yn tarfu ar y rhwydwaith:

1. Rhowch ddyfais sydd bob amser ymlaen yn y segment targed. Gall llwybrydd, NAS neu focs Linux bach sy'n parhau i fod â phŵer allyrru'r ffrâm yn lleol unwaith y byddwch yn ei gyrraedd drwy'r twnnel, ac nid oes dim yn newid yn y VPN.
2. Gadewch i'r llwybrydd allyrru'r ffrâm ei hun. Mae llawer o firmware yn cynnig tudalen deffro sy'n anfon o bont y LAN, ac mae hynny'n gweithio cyhyd â bod y targed ar y bont honno ac nid y tu ôl i ail lwybrydd.
3. Pontiwch y safleoedd â thwnnel o fath TAP pan fo'r darllediadau wir angen croesi. Mae hyn yn cydgysylltu dwy barth ddarlledu, gan ddod â stormydd darlledu, un cynllun cyfeiriadau a phob protocol darganfod sy'n gweld y ddau safle ar unwaith.

Y dewis cyntaf yw'r un i'w ffafrio ar gyfer un peiriant. Mae'r trydydd yn benderfyniad dylunio rhwydwaith â chost barhaus, felly triniwch ef felly, nid fel atgyweiriad cyflym ar gyfer un penbwrdd.

Nodwch pa gymorthydd sy'n allyrru'r ffrâm ac ar ba bont neu VLAN y mae. Mae cymorthydd sy'n allyrru ar y rhyngwyneb anghywir yn rhoi cofnod perffaith a pheiriant na fydd byth yn deffro, ac mae'r cyfuniad hwnnw'n costio prynhawn.

Gwiriwch yr anfon cyn beio'r cleient

Edrychwch ar y cerdyn targed yn gyntaf, oherwydd ni all unrhyw anfonydd ddeffro cerdyn nad yw'n barod. Mae'r gorchymyn isod yn darllen y moddau deffro a gefnogir a'r rheini cyfredol, lle mae gwerth cyfredol o g yn golygu bod magic packet ymlaen:

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

Rhedwch y cofnod ar y cymorthydd tra bo'r anfon yn digwydd, a'i ddarllen yn hytrach na chymryd yn ganiataol ei fod wedi llwyddo. Ffrâm sy'n gadael y bont gywir gyda MAC y targed darlledu yw'r unig dystiolaeth bod yr anfon wedi gweithio; os yw'r cofnod yn wag, mae'r anfonydd wedi dewis rhyngwyneb arall ac mae gweddill y prawf yn ddiystyr. Nid yw anfonydd sy'n adeiladu ffrâm amrwd yn lle datagram UDP yn cyd-fynd â'r hidlydd hwnnw, felly gwiriwch pa ffurf y mae'ch teclyn yn ei defnyddio cyn dod i'r casgliad na anfonwyd dim.

Ar Windows, y gwiriad cerdyn cyfatebol yw powercfg /devicequery wake_armed, sy'n rhestru'r dyfeisiau a ganiateir i ddeffro'r system. Bydd addasydd rhwydwaith sydd ar goll o'r rhestr honno'n anwybyddu pob pecyn a anfonir ato, waeth pa mor gywir y mae'r ffrâm yn edrych ar y wifren.

Yna cadarnhewch y deffro ei hun a'r dilyniant. Mae peiriant sy'n troi ymlaen ond sy'n aros yn un na ellir ei gyrraedd wrth ei enw angen cyfeiriad statig a chofnod DNS, gan nad yw datrys enwau drwy ddarllediad yn croesi'r twnnel o hyd. Mae deffro di-wifr yn allu ar wahân ac yn llawer llai dibynadwy na'r fersiwn gwifrog, felly profwch ef yn yr un segment cyn i chi gynnwys y VPN o gwbl. Ysgrifennwch enw'r rhyngwyneb a hôst y cymorthydd yn y tocyn, oherwydd mae'r methiant nesaf fel arfer yn ymwneud â'r un dau ffaith.