Wake-on-LAN përmes VPN nuk punon? Transmetimi nuk kalon kurrë

E vë makinën e zyrës në gjumë, hap VPN-në nga shtëpia, dhe ajo mbetet e fikur. Tuneli është ngritur, ndarjet e skedarëve përgjigjen, dhe faqja wake-on-LAN e routerit raporton se e dërgoi kërkesën. Çdo sinjal i dukshëm thotë se rrjeti është në rregull, dhe pikërisht prandaj ky rast ngatërron: korniza që do ta zgjonte makinën nuk arrin kurrë në segmentin ku ndodhet.

Simptomat tregojnë nënrrjetin, jo tunelin

Ping-u dështon për hostin në gjumë, dhe ajo pjesë është normale. Një makinë në standby nuk ka stivë IP që punon, prandaj nuk mund t'i përgjigjet ARP ose ICMP, dhe asnjë konfigurim i tunelit nuk e ndryshon këtë. Testi i dobishëm është nëse zgjohet një makinë e dytë në të njëjtën LAN, dhe nëse faqja wake e vetë routerit punon për një host të lidhur me të.

Pasi testi në të njëjtin segment kalon, defekti është i shtrirjes. Dërguesi që përdor jeton në ndërfaqen e VPN-së, dhe paketa që ndërton është një transmetim për lidhjen lokale, prandaj del nga ndërfaqja e gabuar ose nuk del fare. Tuneli nuk është i prishur; po mban llojin e gabuar të trafikut. Zbulo cilën ndërfaqe zgjedh dërguesi përpara se të ndryshosh një rregullim të vetëm të routerit.

Një magic packet është kornizë, jo shërbim

Ngarkesa fillon me një kokë fikse prej gjashtë bajtësh 0xFF, pastaj adresa e harduerit e kartës objektiv e përsëritur gjashtëmbëdhjetë herë, pastaj një fjalëkalim opsional SecureOn prej katër bajtësh. Dërguesit zakonisht e mbështjellin në UDP drejt portit 7 ose portit 9, por numri i portit është një konventë e përbashkët mes dërguesit dhe kartës, jo një shërbim që dëgjon dhe me të cilin lidhesh. Asgjë nuk dëgjon, dhe asgjë nuk përgjigjet.

Ajo që e zgjon makinën është ndërfaqja e rrjetit, e cila mban një sasi të vogël qarqesh të ushqyera nga shina e standby ndërsa pjesa tjetër e sistemit është e fikur. Prandaj rregullimi duhet t'i mbijetojë si një humbjeje totale të rrymës ashtu edhe gjumit: një pllakë që heq ushqimin e standby në fikje nuk ka më kartë për të marrë asgjë.

Pse një tunel i rrugëtuar nuk mund ta dorëzojë

Një ndërfaqe VPN e rrugëtuar është një lidhje IP pikë-për-pikë mes dy adresave tuneli. Ajo ekziston për të mbajtur paketa të adresuara te partneri, dhe prandaj ping, SSH dhe ndarjet e skedarëve sillen normalisht përmes saj. Një kornizë transmetimi nuk i adresohet atij partneri, dhe adresa e transmetimit të kufizuar nuk përcillet kurrë automatikisht nga një router.

Përcjellja e një transmetimi të drejtuar nga nënrrjeti është aftësi e qëllimshme e routerit që shumica e konfigurimeve parazgjedhur e çaktivizojnë, dhe edhe atëherë dorëzon në atë nënrrjet dhe jo te një kartë e caktuar në gjumë. Një host në gjumë nuk mund t'i përgjigjet as ARP, prandaj një router që përpiqet të zgjidhë adresën objektiv përpara përcjelljes e hedh kornizën ndërsa pret një përgjigje që nuk vjen kurrë. Një zë statik lidhjeje e rregullon atë pjesë dhe e lë të paprekur problemin e shtrirjes së transmetimit. Dy kufizime të ndara, pra, dhe heqja e njërës nuk bën asgjë për tjetrën.

Tre vendosje që arrijnë vërtet te karta

Çdo rregullim i zbatueshëm e vendos kornizën në segmentin e objektivit, dhe ato ndryshojnë në sa e shqetësojnë rrjetin:

1. Vendos një pajisje gjithmonë të ndezur në segmentin objektiv. Një router, NAS ose kuti e vogël Linux që mbetet e ushqyer mund ta emetojë kornizën lokalisht sapo ta arrish përmes tunelit, dhe asgjë e VPN-së nuk ndryshon.
2. Lëre routerin ta emetojë vetë kornizën. Shumë firmware ofrojnë një faqe wake që dërgon nga ura LAN, e cila punon përderisa objektivi ndodhet në atë urë dhe jo pas një routeri të dytë.
3. Ura lidh vendet me një tunel të tipit TAP kur transmetimet duhet vërtet të kalojnë. Kjo bashkon dy domain-e transmetimi, me stuhi transmetimi, një plan të vetëm adresimi dhe çdo protokoll zbulimi që i sheh të dy vendet njëkohësisht.

Mundësia e parë është ajo që duhet preferuar për një makinë të vetme. E treta është një vendim i projektimit të rrjetit me kosto të vazhdueshme, prandaj trajtoje si të tillë dhe jo si një rregullim i shpejtë për një desktop.

Shëno cili ndihmës e emeton kornizën dhe në cilën urë ose VLAN ndodhet. Një ndihmës që emeton në ndërfaqen e gabuar prodhon një kapje të përsosur dhe një makinë që nuk zgjohet kurrë, dhe ajo kombinim harxhon një pasdite.

Verifiko dërgimin përpara se të fajësosh klientin

Kontrollo fillimisht kartën objektiv, sepse asnjë dërgues nuk mund të zgjojë një kartë që nuk është armatosur. Komanda më poshtë lexon mënyrat e wake të mbështetura dhe atë aktuale, ku një vlerë aktuale prej g do të thotë që magic packet është aktivizuar:

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

Ekzekuto kapjen te ndihmësi ndërsa bëhet dërgimi, dhe lexoje në vend që të supozosh sukses. Një kornizë që del nga ura e duhur me MAC-un e transmetimit është prova e vetme që dërgimi funksionoi; nëse kapja është bosh, dërguesi zgjodhi një ndërfaqe tjetër dhe pjesa tjetër e testit nuk ka kuptim. Një dërgues që ndërton një kornizë të papërpunuar në vend të një datagrame UDP nuk përputhet me atë filtër, prandaj kontrollo çfarë forme përdor mjeti yt përpara se të konkludosh se nuk u dërgua asgjë.

Në Windows kontrolli ekuivalent i kartës është powercfg /devicequery wake_armed, që liston pajisjet e lejuara të zgjojnë sistemin. Një përshtatës rrjeti që mungon në atë listë do të injorojë çdo paketë që i dërgohet, sado korrekt të duket korniza në kabllo.

Pastaj konfirmo vetë zgjimin dhe vazhdimin. Një makinë që ndizet por mbetet e paarritshme me emër ka nevojë për një adresë statike dhe një regjistrim DNS, sepse zgjidhja e emrave me transmetim prapë nuk e kalon tunelin. Zgjimi pa tela është aftësi e veçantë dhe shumë më pak e besueshme se versioni me kabllo, prandaj provoje në të njëjtin segment përpara se të përfshish fare VPN-në. Shkruaj emrin e ndërfaqes dhe hostin e ndihmësit në biletë, sepse defekti i radhës zakonisht ka të bëjë me të njëjtat dy fakte.