Wake-on-LAN VPN-i kaudu ei tööta? Saade ei jõua kunagi kohale

Paned kontorimasina magama, helistad kodust VPN-i sisse, ja see jääb välja. Tunnel on üleval, failijagamised vastavad ning ruuteri wake-on-LAN leht teatab, et saatis päringu. Iga nähtav signaal ütleb, et võrk on korras, ja just seepärast on see juhtum segane: kaader, mis masina ärataks, ei jõua kunagi selle segmendini, kus masin asub.

Sümptomid osutavad alavõrgule, mitte tunnelile

Ping magavale hostile ei õnnestu ja see osa on normaalne. Ooterežiimis masinal ei ole töötavat IP-pinu, seega ei saa see vastata ARP-ile ega ICMP-le, ja ükski tunneli seadistus ei muuda seda. Kasulik test on see, kas teine masin samas LAN-is ärkab ja kas ruuteri enda äratamisleht töötab sinna ühendatud hosti jaoks.

Kui test samas segmendis õnnestub, on viga ulatuses. Saatja, mida kasutad, elab VPN-liidesel, ja pakett, mille see ehitab, on saade kohalikule lingile, seega väljub see vale liidese kaudu või üldse mitte. Tunnel ei ole katki; see kannab vale tüüpi liiklust. Uuri välja, millise liidese saatja valib, enne kui muudad ühtki ruuteri seadet.

Magic packet on kaader, mitte teenus

Kasulik koormus algab fikseeritud kuue baidi suuruse 0xFF päisega, seejärel sihtkaardi riistvara-aadress, korratud kuusteist korda, seejärel valikuline nelja baidi suurune SecureOn-parool. Saatjad pakivad selle tavaliselt UDP-sse pordile 7 või pordile 9, kuid pordi number on kokkulepe saatja ja kaardi vahel, mitte kuulav teenus, millega saaks ühenduda. Miski ei kuula ja miski ei vasta.

Masinat äratab võrguliides, mis hoiab väikest osa skeemidest toidetuna ooterežiimi siinilt, samal ajal kui ülejäänud süsteem on väljas. Seepärast peab seade üle elama nii täieliku toitekatkestuse kui ka une: emaplaat, mis väljalülitamisel ootetoite katkestab, ei oma enam kaarti, mis midagi vastu võtaks.

Miks marsruuditud tunnel ei suuda seda kohale toimetada

Marsruuditud VPN-liides on punkt-punkt IP-ühendus kahe tunneli aadressi vahel. See on olemas selleks, et kanda partnerile adresseeritud pakette, ja seepärast käituvad ping, SSH ja failijagamised selle kaudu tavaliselt. Saatekaader ei ole sellele partnerile adresseeritud, ja piiratud saateaadressi ei edastata ruuteri poolt lihtsalt niisama.

Alavõrku suunatud saate edastamine on ruuteri teadlik võimekus, mille enamik vaikimisi seadistusi välja lülitab, ja isegi siis toimetatakse see kohale sellesse alavõrku, mitte konkreetsele magavale kaardile. Magav host ei saa ka ARP-ile vastata, seega ruuter, mis üritab enne edastamist sihtaadressi lahendada, viskab kaadri ära, oodates vastust, mis kunagi ei tule. Staatiline sidumiskirje parandab selle osa ja jätab saate ulatuse probleemi puutumata. Kaks eraldi piirangut, seega, ja ühe kõrvaldamine ei tee teise heaks midagi.

Kolm paigutust, mis tõesti kaardini jõuavad

Iga toimiv lahendus paneb kaadri sihtkoha segmenti, ja need erinevad selle poolest, kui palju need võrku häirivad:

1. Pane sihtsegmenti seade, mis on alati sees. Ruuter, NAS või väike Linuxi kast, mis jääb toidetuks, saab kaadri kohapeal välja saata, niipea kui sellele tunneli kaudu ligi pääsed, ja VPN-is ei muutu miski.
2. Lase ruuteril kaader ise välja saata. Paljud püsivaramad pakuvad äratamislehte, mis saadab LAN-sillalt, ja see töötab seni, kui siht asub sellel sillal, mitte teise ruuteri taga.
3. Ühenda asukohad sillaga ja TAP-tüüpi tunneliga, kui saadetel tõesti tuleb üle minna. See ühendab kaks saatedomeeni, tuues kaasa saadetormid, ühe aadressiplaani ja iga avastusprotokolli, mis näeb mõlemat asukohta korraga.

Esimene valik on see, mida ühe masina jaoks eelistada. Kolmas on võrgu kavandamise otsus püsivate kuludega, seega käsitle seda sellisena, mitte kiirparandusena ühele töölauaarvutile.

Pane kirja, milline abiline kaadri saadab ja millisel sillal või VLAN-is see asub. Vale liidese kaudu saatja abiline annab täiusliku salvestuse ja masina, mis kunagi ei ärka, ja see kombinatsioon maksab ühe pärastlõuna.

Kontrolli saatmist, enne kui klienti süüdistad

Kontrolli kõigepealt sihtkaarti, sest ükski saatja ei äratä kaarti, mis ei ole valmis. Allolev käsk loeb toetatud ja praegused äratamisrežiimid, kus praegune väärtus g tähendab, et magic packet on sisse lülitatud:

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

Käivita salvestus abilisel saatmise ajal ja loe seda, selle asemel et eeldada õnnestumist. Kaader, mis lahkub õigelt sillalt saate siht-MAC-iga, on ainus tõestus, et saatmine õnnestus; kui salvestus on tühi, valis saatja teise liidese ja ülejäänud test ei tähenda midagi. Saatja, mis ehitab toores kaadri, mitte UDP-datagrammi, ei sobi selle filtriga, seega kontrolli, millist vormi sinu tööriist kasutab, enne kui järeldad, et midagi ei saadetud.

Windowsis on samaväärne kaardi kontroll powercfg /devicequery wake_armed, mis loetleb seadmed, millel on lubatud süsteemi äratada. Võrguadapter, mida selles loendis pole, eirab iga talle saadetud paketti, ükskõik kui korrektne kaader juhtmel välja näeb.

Seejärel kinnita äratamine ise ja järeltegevus. Masin, mis lülitub sisse, kuid jääb nime järgi kättesaamatuks, vajab staatilist aadressi ja DNS-kirjet, sest saate kaudu nime lahendamine ei ületa endiselt tunnelit. Juhtmeta äratamine on eraldi ja palju vähem usaldusväärne võimalus kui juhtmega versioon, seega testi seda samas segmendis, enne kui VPN-i üldse mängu tood. Kirjuta piletisse liidese nimi ja abilise host, sest järgmine rike puudutab tavaliselt samu kahte fakti.