Nem működik a Wake-on-LAN VPN-en át? A csomag soha nem jut át

Elaltatja az irodai gépet, otthonról tárcsázza a VPN-t, és a gép kikapcsolva marad. Az alagút áll, a fájlmegosztások válaszolnak, és a router wake-on-LAN oldala jelzi, hogy elküldte a kérést. Minden látható jel azt mondja, hogy a hálózat rendben van, és éppen ezért zavaró ez az eset: a keret, amely felébresztené a gépet, soha nem ér el abba a szegmensbe, ahol a gép van.

A tünetek az alhálózatra mutatnak, nem az alagútra

A ping nem megy át az alvó hosztra, és ez a rész normális. A készenléti gépnek nincs futó IP-vereme, ezért nem tud válaszolni ARP-ra vagy ICMP-re, és ezen semmilyen alagútbeállítás nem változtat. A hasznos próba az, hogy felébred-e egy másik gép ugyanabban a LAN-ban, és működik-e a router saját ébresztőoldala a rá csatlakoztatott hoszt esetében.

Amint a próba ugyanabban a szegmensben sikerül, a hiba a hatókörben van. Az Ön által használt küldő a VPN-interfészen él, és az általa épített csomag a helyi kapcsolat felé irányuló szórás, ezért a rossz interfészen megy ki, vagy sehol. Az alagút nem hibás; rossz fajtájú forgalmat szállít. Derítse ki, melyik interfészt választja a küldő, mielőtt bármelyik routerbeállítást megváltoztatná.

A magic packet keret, nem szolgáltatás

A hasznos teher hat bájtos fix fejléccel kezdődik, 0xFF, majd a célkártya hardvercíme tizenhatszor megismételve, majd egy opcionális négybájtos SecureOn-jelszó. A küldők ezt általában UDP-be csomagolják a 7-es vagy a 9-es portra, de a portszám a küldő és a kártya közötti megegyezés, nem figyelő szolgáltatás, amelyhez csatlakozni lehet. Semmi nem figyel, és semmi nem válaszol.

A gépet a hálózati interfész ébreszti fel, amely a készenléti sínről táplálva tart egy kis áramköri részt, miközben a rendszer többi része ki van kapcsolva. Ezért a beállításnak túl kell élnie a teljes áramkimaradást és az alvást is: az alaplap, amely kikapcsoláskor megszakítja a készenléti tápellátást, már nem tartogat kártyát, amely bármit fogadhatna.

Miért nem tudja ezt leszállítani egy irányított alagút

Az irányított VPN-interfész pont-pont IP-kapcsolat két alagútcím között. Azért létezik, hogy a partnernek címzett csomagokat szállítsa, ezért a ping, az SSH és a fájlmegosztások normálisan viselkednek rajta. A szórási keret nincs a partnernek címezve, és a korlátozott szórási címet egy router soha nem továbbítja automatikusan.

Az alhálózat felé irányuló szórás továbbítása szándékos routerfunkció, amelyet a legtöbb alapértelmezett beállítás kikapcsol, és még akkor is abba az alhálózatba szállítja, nem egy adott alvó kártyához. Az alvó hoszt ARP-ra sem tud válaszolni, ezért az a router, amely a továbbítás előtt fel akarja oldani a célcímet, eldobja a keretet, miközben olyan válaszra vár, amely soha nem jön meg. Egy statikus hozzákötési bejegyzés rendbe teszi ezt a részt, és érintetlenül hagyja a szórás hatókörének problémáját. Két külön korlát tehát, és az egyik megszüntetése semmit nem tesz a másikért.

Három elhelyezés, amely valóban eléri a kártyát

Minden működő elrendezés a cél szegmensére teszi a keretet, és abban különböznek, mennyire zavarják a hálózatot:

1. Tegyen egy mindig bekapcsolt eszközt a célszegmensbe. Egy router, NAS vagy kis Linux-doboz, amely áram alatt marad, helyben ki tudja bocsátani a keretet, amint az alagúton eléri, és a VPN-ben semmi nem változik.
2. Hagyja, hogy a router maga bocsássa ki a keretet. Sok firmware kínál ébresztőoldalt, amely a LAN-hídról küld, és ez addig működik, amíg a cél ezen a hídon van, nem pedig egy második router mögött.
3. Hidalja össze a helyszíneket TAP-típusú alagúttal, ha a szórásoknak valóban át kell jutniuk. Ez két szórási tartományt von össze, szórási viharokkal, egyetlen címtervvel és minden felderítési protokollal, amely egyszerre látja mindkét helyszínt.

Az első lehetőséget érdemes előnyben részesíteni egyetlen gépnél. A harmadik hálózattervezési döntés állandó költséggel, ezért úgy is kezelje, és ne egy asztali gép gyors javításaként.

Jegyezze fel, melyik segéd bocsátja ki a keretet, és melyik hídon vagy VLAN-on van. A rossz interfészen küldő segéd tökéletes rögzítést és soha fel nem ébredő gépet ad, és ez a kombináció egy délutánba kerül.

Ellenőrizze a küldést, mielőtt a klienst hibáztatja

Először a célkártyát ellenőrizze, mert egyetlen küldő sem ébreszt fel egy kártyát, amely nincs felkészítve. Az alábbi parancs kiolvassa a támogatott és az aktuális ébresztési módokat, ahol az aktuális g érték azt jelenti, hogy a magic packet be van kapcsolva:

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

Futtassa a rögzítést a segéden a küldés közben, és olvassa el, ahelyett hogy sikert feltételezne. Az a keret, amely a megfelelő hídról távozik a szórási cél-MAC-kel, az egyetlen bizonyíték arra, hogy a küldés működött; ha a rögzítés üres, a küldő másik interfészt választott, és a teszt többi része értelmetlen. Az a küldő, amely nyers keretet épít UDP-datagram helyett, nem illik ehhez a szűrőhöz, ezért nézze meg, milyen formát használ az eszköze, mielőtt arra jutna, hogy semmi nem ment ki.

Windows alatt a kártya megfelelő ellenőrzése a powercfg /devicequery wake_armed, amely felsorolja a rendszert ébreszthető eszközöket. Az a hálózati adapter, amely hiányzik a listáról, figyelmen kívül hagy minden neki küldött csomagot, bármennyire helyesnek látszik a keret a vezetéken.

Ezután igazolja magát az ébresztést és a folytatást. Az a gép, amely bekapcsol, de név szerint elérhetetlen marad, statikus címet és DNS-rekordot igényel, mert a névfeloldás szórással továbbra sem jut át az alagúton. A vezeték nélküli ébresztés külön és sokkal megbízhatatlanabb képesség, mint a vezetékes változat, ezért ugyanabban a szegmensben próbálja ki, mielőtt egyáltalán bevonja a VPN-t. Írja a jegybe az interfész nevét és a segéd hosztját, mert a következő hiba általában ugyanazt a két tényt érinti.