Wake-on-LAN caur VPN nedarbojas? Pārraide nekad nešķērso

Tunelis ir pacelts un koplietotās mapes atbild, bet dators paliek snaudā. Magic packet jāsūta pašā mērķa segmentā, tāpēc novietojiet tur palīgu.

Jūs aizmigdinat biroja datoru, no mājām pieslēdzat VPN, un tas paliek izslēgts. Tunelis ir pacelts, failu koplietojumi atbild, un maršrutētāja wake-on-LAN lapa ziņo, ka pieprasījums ir nosūtīts. Katrs redzamais signāls saka, ka tīkls ir kārtībā, un tāpēc šis gadījums mulsina: kadrs, kas datoru pamodinātu, nekad neaizsniedz segmentu, kurā tas atrodas.

Simptomi norāda uz apakštīklu, nevis uz tuneli

Ping uz aizmigušo saimnieku neizdodas, un šī daļa ir normāla. Dators gaidīšanas režīmā neuztur darbojošos IP steku, tāpēc nevar atbildēt ne uz ARP, ne uz ICMP, un neviena tuneļa konfigurācija to nemaina. Noderīgs tests ir tas, vai pamostas otrs dators tajā pašā LAN un vai paša maršrutētāja modināšanas lapa darbojas tam pieslēgtam saimniekam.

Kad tests tajā pašā segmentā izdodas, problēma ir pārklājumā. Sūtītājs, ko izmantojat, dzīvo VPN saskarnē, un pakete, ko tas būvē, ir pārraide vietējam posmam, tāpēc tā iznāk pa nepareizo saskarni vai neiznāk vispār. Tunelis nav salūzis; tas pārvadā nepareizo trafika veidu. Noskaidrojiet, kuru saskarni sūtītājs izvēlas, pirms maināt kaut vienu maršrutētāja iestatījumu.

Magic packet ir kadrs, nevis pakalpojums

Lietderīgā slodze sākas ar fiksētu sešu baitu 0xFF galveni, tad mērķa kartes aparatūras adrese, atkārtota sešpadsmit reizes, tad neobligāta četru baitu SecureOn parole. Sūtītāji to parasti iesaiņo UDP uz portu 7 vai portu 9, bet porta numurs ir vienošanās starp sūtītāju un karti, nevis klausošs pakalpojums, kuram var pieslēgties. Nekas neklausās, un nekas neatbild.

Datoru pamodina tīkla saskarne, kas uztur nelielu shēmu daļu barotu no gaidīšanas kopnes, kamēr pārējā sistēma ir izslēgta. Tāpēc iestatījumam ir jāpārdzīvo gan pilnīgs barošanas zudums, gan miegs: plate, kas izslēgšanas laikā atslēdz gaidīšanas barošanu, vairs nav ar karti, kas varētu kaut ko uztvert.

Kāpēc maršrutēts tunelis to nevar piegādāt

Maršrutēta VPN saskarne ir punkts-punktā IP saite starp divām tuneļa adresēm. Tā pastāv, lai pārraidītu paketes, kas adresētas partnerim, un tāpēc ping, SSH un failu koplietojumi caur to darbojas normāli. Pārraides kadrs nav adresēts šim partnerim, un ierobežotā pārraides adrese nekad netiek pārsūtīta ar maršrutētāju bez atsevišķa norādījuma.

Uz apakštīklu vērstas pārraides pārsūtīšana ir apzināta maršrutētāja iespēja, ko lielākā daļa noklusējuma konfigurāciju izslēdz, un pat tad tā tiek piegādāta tam apakštīklam, nevis konkrētai aizmigušai kartei. Aizmigušais saimnieks arī nevar atbildēt uz ARP, tāpēc maršrutētājs, kas pirms pārsūtīšanas mēģina atrisināt mērķa adresi, kadru izmet, kamēr gaida atbildi, kas nekad nenāks. Statisks piesaistes ieraksts izlabo šo daļu un atstāj pārraides pārklājuma problēmu neskartu. Tātad divi atsevišķi ierobežojumi, un viena novēršana neko nedod otram.

Trīs izvietojumi, kas patiešām aizsniedz karti

Jebkura darbspējīga shēma ievieto kadru mērķa segmentā, un tās atšķiras ar to, cik ļoti traucē tīklu:

  1. Novietojiet mērķa segmentā ierīci, kas vienmēr ir ieslēgta. Maršrutētājs, NAS vai maza Linux kaste, kas paliek barota, var pārraidīt kadru lokāli, tiklīdz tam caur tuneli piekļūstat, un VPN nekas nemainās.
  2. Ļaujiet maršrutētājam pašam pārraidīt kadru. Daudzas programmaparatūras piedāvā modināšanas lapu, kas sūta no LAN tilta, un tas darbojas, kamēr mērķis atrodas uz šī tilta, nevis aiz otra maršrutētāja.
  3. Savienojiet vietas ar tiltu un TAP tipa tuneli, kad pārraidēm patiešām jāšķērso. Tas apvieno divus pārraides domēnus, atnesot pārraides vētras, vienu adresācijas plānu un katru atklāšanas protokolu, kas redz abas vietas vienlaikus.

Pirmais variants ir tas, kam vienam datoram vērts dot priekšroku. Trešais ir tīkla projektēšanas lēmums ar pastāvīgām izmaksām, tāpēc iztieties pret to kā pret tādu, nevis kā pret ātru labojumu vienam darbvirsmam.

Pierakstiet, kurš palīgs pārraida kadru un uz kura tilta vai VLAN tas atrodas. Palīgs, kas pārraida pa nepareizo saskarni, dod perfektu ierakstu un datoru, kas nekad nepamostas, un šāda kombinācija maksā pēcpusdienu.

Pārbaudiet sūtīšanu, pirms vainojat klientu

Vispirms pārbaudiet mērķa karti, jo neviens sūtītājs nepamodinās karti, kas nav sagatavota. Tālāk esošā komanda nolasa atbalstītos un pašreizējos modināšanas režīmus, kur pašreizējā g vērtība nozīmē, ka magic packet ir ieslēgts:

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

Palaidiet ierakstu uz palīga, kamēr notiek sūtīšana, un izlasiet to, nevis pieņemiet panākumus. Kadrs, kas atstāj pareizo tiltu ar pārraides mērķa MAC, ir vienīgais pierādījums, ka sūtīšana nostrādāja; ja ieraksts ir tukšs, sūtītājs izvēlējās citu saskarni un pārējais tests neko nenozīmē. Sūtītājs, kas būvē neapstrādātu kadru, nevis UDP datagrammu, neatbilst šim filtram, tāpēc pārbaudiet, kādu formu izmanto jūsu rīks, pirms secināt, ka nekas nav nosūtīts.

Windows sistēmā atbilstošā kartes pārbaude ir powercfg /devicequery wake_armed, kas uzskaita ierīces, kam atļauts modināt sistēmu. Tīkla adapteris, kas šajā sarakstā nav, ignorēs katru tam nosūtīto paketi, lai cik pareizs kadrs izskatītos uz vada.

Pēc tam apstipriniet pašu modināšanu un turpinājumu. Datoram, kas ieslēdzas, bet paliek neaizsniedzams pēc nosaukuma, vajag statisku adresi un DNS ierakstu, jo nosaukumu atrisināšana ar pārraidi joprojām nešķērso tuneli. Bezvadu modināšana ir atsevišķa un daudz mazāk uzticama iespēja nekā vadu versija, tāpēc pārbaudiet to tajā pašā segmentā, pirms vispār iesaistāt VPN. Ierakstiet pieteikumā saskarnes nosaukumu un palīga saimnieku, jo nākamā kļūme parasti attiecas uz tiem pašiem diviem faktiem.

Saistītie raksti