Eikö Wake-on-LAN toimi VPN:n yli? Lähetys ei ylitä koskaan

Laitat toimistokoneen uneen, soitat VPN:n kotoa, ja se jää pois päältä. Tunneli on pystyssä, tiedostojatot vastaavat, ja reitittimen wake-on-LAN-sivu ilmoittaa lähettäneensä pyynnön. Jokainen näkyvä signaali sanoo, että verkko on kunnossa, ja juuri siksi tämä tapaus hämmentää: kehys, joka herättäisi koneen, ei koskaan saavuta segmenttiä, jossa se on.

Oireet osoittavat aliverkkoon, eivät tunneliin

Ping nukkuvalle isännälle epäonnistuu, ja se osa on normaalia. Lepotilassa olevalla koneella ei ole käynnissä olevaa IP-pinoa, joten se ei voi vastata ARP:iin eikä ICMP:hen, eikä mikään tunnelin asetus muuta sitä. Hyödyllinen testi on, herääkö toinen kone samassa lähiverkossa ja toimiiko reitittimen oma herätyssivu siihen kytketylle isännälle.

Kun testi samassa segmentissä onnistuu, vika on ulottuvuudessa. Käyttämäsi lähettäjä elää VPN-liitännäisessä, ja paketti, jonka se rakentaa, on lähetys paikalliselle linkille, joten se lähtee väärästä liitännäisestä tai ei lainkaan. Tunneli ei ole rikki; se kuljettaa vääränlaista liikennettä. Selvitä, minkä liitännäisen lähettäjä valitsee, ennen kuin muutat yhtäkään reitittimen asetusta.

Magic packet on kehys, ei palvelu

Hyötykuorma alkaa kiinteällä kuuden tavun 0xFF-otsakkeella, sitten kohdekortin laiteosoite kuusitoista kertaa toistettuna, sitten valinnainen neljän tavun SecureOn-salasana. Lähettäjät käärelevät sen yleensä UDP:hen porttiin 7 tai porttiin 9, mutta porttinumero on lähettäjän ja kortin välinen sopimus, ei kuunteleva palvelu, johon voisi yhdistää. Mikään ei kuuntele, eikä mikään vastaa.

Koneen herättää verkkoliitäntä, joka pitää pienen osan piireistä virroitettuna valmiustilan kiskosta, kun muu järjestelmä on pois päältä. Siksi asetuksen on kestettävä sekä täysi virrankatkos että uni: emolevy, joka katkaisee valmiustilan virran sammutettaessa, ei enää omista korttia, joka voisi vastaanottaa mitään.

Miksi reititetty tunneli ei voi toimittaa sitä

Reititetty VPN-liitäntä on piste-piste IP-yhteys kahden tunneliosoitteen välillä. Se on olemassa, jotta se kuljettaisi kumppanille osoitettuja paketteja, ja siksi ping, SSH ja tiedostojatot käyttäytyvät sen kautta normaalisti. Lähetyskehys ei ole osoitettu sille kumppanille, eikä rajoitettua lähetysosoitetta koskaan välitetä reitittimen toimesta pelkän tavan vuoksi.

Aliverkkoon suunnatun lähetyksen välittäminen on reitittimen tarkoituksellinen ominaisuus, jonka useimmat oletusasetukset poistavat käytöstä, ja silloinkin se toimitetaan siihen aliverkkoon, ei tietylle nukkuvalle kortille. Nukkuva isäntä ei voi vastata myöskään ARP:iin, joten reititin, joka yrittää selvittää kohdeosoitteen ennen välitystä, pudottaa kehyksen odottaessaan vastausta, jota ei koskaan tule. Staattinen sidostietue korjaa tuon osan ja jättää lähetyksen ulottuvuusongelman koskemattomaksi. Siis kaksi erillistä rajoitusta, eikä toisen poistaminen tee toiselle mitään.

Kolme sijoittelua, jotka todella yltävät kortille

Jokainen toimiva järjestely sijoittaa kehyksen kohteen segmenttiin, ja ne eroavat siinä, kuinka paljon ne häiritsevät verkkoa:

1. Sijoita kohdesegmenttiin laite, joka on aina päällä. Reititin, NAS tai pieni Linux-laatikko, joka pysyy virroitettuna, voi lähettää kehyksen paikallisesti, kunhan pääset siihen tunnelin kautta, eikä VPN:ssä mikään muutu.
2. Anna reitittimen lähettää kehys itse. Monet laiteohjelmistot tarjoavat herätyssivun, joka lähettää lähiverkon sillalta, ja se toimii niin kauan kuin kohde istuu sillä sillalla eikä toisen reitittimen takana.
3. Sillaa toimipisteet TAP-tyyppisellä tunnelilla, kun lähetysten on todella ylitettävä. Se yhdistää kaksi lähetysverkkotunnusta, mukanaan lähetysmyrskyt, yksi osoitekaava ja jokainen löytöprotokolla, joka näkee molemmat toimipisteet yhtä aikaa.

Ensimmäinen vaihtoehto on se, jota yhdelle koneelle kannattaa suosia. Kolmas on verkon suunnittelupäätös, jolla on jatkuvat kustannukset, joten kohtele sitä sellaisena, älä nopeana korjauksena yhdelle työpöydälle.

Kirjaa, mikä apuri lähettää kehyksen ja millä sillalla tai VLAN:ssa se on. Apuri, joka lähettää väärästä liitännästä, antaa täydellisen tallenteen ja koneen, joka ei koskaan herää, ja sellainen yhdistelmä maksaa yhden iltapäivän.

Varmista lähetys ennen kuin syytät asiakasta

Tarkista ensin kohdekortti, koska mikään lähettäjä ei herätä korttia, joka ei ole valmiina. Alla oleva komento lukee tuetut ja nykyiset herätystilat, joissa nykyinen arvo g tarkoittaa, että magic packet on päällä:

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

Aja tallenne apurilla lähetyksen aikana ja lue se sen sijaan, että olettaisit onnistumisen. Kehys, joka lähtee oikealta sillalta lähetyksen kohde-MAC:lla, on ainoa todiste siitä, että lähetys onnistui; jos tallenne on tyhjä, lähettäjä valitsi toisen liitännän ja loppu testistä on merkityksetön. Lähettäjä, joka rakentaa raa'an kehyksen UDP-datagrammin sijaan, ei sovi tuohon suodattimeen, joten tarkista, mitä muotoa työkalusi käyttää, ennen kuin päättelet, ettei mitään lähetetty.

Windowsissa vastaava kortin tarkistus on powercfg /devicequery wake_armed, joka luettelee laitteet, joilla on lupa herättää järjestelmä. Verkkosovitin, joka puuttuu siltä listalta, jättää huomiotta jokaisen sille lähetetyn paketin, niin oikealta kehys näyttää johtimella.

Vahvista sitten itse herääminen ja jatko. Kone, joka käynnistyy mutta jää nimen perusteella tavoittamattomaksi, tarvitsee staattisen osoitteen ja DNS-tietueen, koska nimen selvitys lähetyksellä ei edelleenkään ylitä tunnelia. Langaton herätys on erillinen ja paljon epäluotettavampi ominaisuus kuin langallinen versio, joten testaa sitä samassa segmentissä ennen kuin VPN:tä edes otetaan mukaan. Kirjoita tikettiin liitännän nimi ja apurin isäntä, koska seuraava vika koskee yleensä samoja kahta tosiasiaa.