Wake-on-LAN melalui VPN tidak berfungsi? Siaran tidak pernah melintas

Anda menidurkan mesin pejabat, mendail VPN dari rumah, dan mesin kekal mati. Terowong sudah naik, perkongsian fail menjawab, dan halaman wake-on-LAN penghala melaporkan telah menghantar permintaan. Setiap isyarat yang kelihatan mengatakan rangkaian baik, dan kerana itulah kes ini mengelirukan: rangka yang sepatutnya mengejutkan mesin tidak pernah sampai ke segmen tempat ia berada.

Gejala menunjuk ke subnet, bukan ke terowong

Ping ke hos yang tidur gagal, dan bahagian itu normal. Mesin dalam mod sedia tidak mempunyai tindanan IP yang berjalan, jadi tidak boleh menjawab ARP atau ICMP, dan tiada konfigurasi terowong yang mengubahnya. Ujian berguna ialah sama ada mesin kedua dalam LAN yang sama terjaga, dan sama ada halaman jaga penghala itu sendiri berfungsi untuk hos yang dipasang padanya.

Sebaik ujian dalam segmen yang sama lulus, kerosakan terletak pada skop. Penghantar yang anda gunakan tinggal pada antara muka VPN, dan paket yang dibinanya ialah siaran untuk pautan setempat, jadi ia keluar melalui antara muka yang salah atau tidak keluar langsung. Terowong tidak rosak; ia membawa jenis trafik yang salah. Cari antara muka yang dipilih oleh penghantar sebelum menukar satu pun tetapan penghala.

Magic packet ialah rangka, bukan perkhidmatan

Muatan bermula dengan pengepala tetap enam bait 0xFF, kemudian alamat perkakasan kad sasaran diulang enam belas kali, kemudian kata laluan SecureOn pilihan empat bait. Penghantar biasanya membungkusnya dalam UDP ke port 7 atau port 9, tetapi nombor port ialah konvensyen antara penghantar dan kad, bukan pendengar yang boleh disambung. Tiada apa yang mendengar, dan tiada apa yang menjawab.

Yang mengejutkan mesin ialah antara muka rangkaian, yang mengekalkan sebahagian kecil litar berkuasa dari rel sedia semasa seluruh sistem dimatikan. Kerana itu tetapan mesti bertahan menghadapi kehilangan kuasa penuh dan juga tidur: papan yang memutuskan kuasa sedia apabila dimatikan tidak lagi mempunyai kad untuk menerima apa-apa.

Mengapa terowong terarah tidak dapat menyampaikannya

Antara muka VPN terarah ialah pautan IP titik-ke-titik antara dua alamat terowong. Ia wujud untuk membawa paket yang dialamatkan kepada rakan, dan sebab itu ping, SSH dan perkongsian fail berkelakuan normal melaluinya. Rangka siaran tidak dialamatkan kepada rakan itu, dan alamat siaran terhad tidak pernah diteruskan oleh penghala secara automatik.

Meneruskan siaran yang dihalakan ke subnet ialah keupayaan sengaja pada penghala yang dimatikan oleh kebanyakan konfigurasi lalai, dan walaupun dihidupkan ia menghantar ke subnet itu, bukan ke kad tidur tertentu. Hos yang tidur juga tidak boleh menjawab ARP, jadi penghala yang cuba menyelesaikan alamat sasaran sebelum meneruskan akan menggugurkan rangka itu sambil menunggu jawapan yang tidak akan tiba. Entri pengikatan statik membaiki bahagian itu dan membiarkan masalah skop siaran tidak tersentuh. Jadi dua kekangan berasingan, dan menghapuskan satu tidak melakukan apa-apa untuk yang lain.

Tiga penempatan yang benar-benar sampai ke kad

Setiap susunan yang boleh digunakan meletakkan rangka dalam segmen sasaran, dan semuanya berbeza dari segi berapa banyak mengganggu rangkaian:

1. Letakkan peranti yang sentiasa hidup dalam segmen sasaran. Penghala, NAS atau kotak Linux kecil yang kekal berkuasa boleh memancarkan rangka secara setempat sebaik anda mencapainya melalui terowong, dan tiada apa dalam VPN berubah.
2. Biarkan penghala sendiri memancarkan rangka. Banyak perisian tegar menyediakan halaman jaga yang menghantar dari jambatan LAN, dan ia berfungsi selagi sasaran berada pada jambatan itu dan bukan di belakang penghala kedua.
3. Jambatani kedua-dua lokasi dengan terowong jenis TAP apabila siaran memang perlu melintas. Ini menyatukan dua domain siaran, membawa ribut siaran, satu pelan alamat dan setiap protokol penemuan yang melihat kedua-dua lokasi serentak.

Pilihan pertama ialah yang patut diutamakan untuk satu mesin. Pilihan ketiga ialah keputusan reka bentuk rangkaian dengan kos berterusan, jadi anggapnya begitu, bukan pembaikan cepat untuk satu desktop.

Catat pembantu mana yang memancarkan rangka dan pada jambatan atau VLAN mana ia berada. Pembantu yang memancar dari antara muka salah menghasilkan tangkapan sempurna dan mesin yang tidak pernah terjaga, dan gabungan itu memakan satu petang.

Sahkan penghantaran sebelum menyalahkan klien

Periksa kad sasaran dahulu, kerana tiada penghantar boleh mengejutkan kad yang belum sedia. Arahan di bawah membaca mod jaga yang disokong dan yang semasa, di mana nilai semasa g bermaksud magic packet dihidupkan:

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

Jalankan tangkapan pada pembantu semasa penghantaran berlaku, dan bacalah dan bukan menganggapnya berjaya. Rangka yang meninggalkan jambatan yang betul dengan MAC sasaran siaran ialah satu-satunya bukti bahawa penghantaran berjaya; jika tangkapan kosong, penghantar memilih antara muka lain dan baki ujian tidak bermakna. Penghantar yang membina rangka mentah dan bukan datagram UDP tidak sepadan dengan penapis itu, jadi periksa bentuk yang digunakan alat anda sebelum membuat kesimpulan tiada apa yang dihantar.

Dalam Windows pemeriksaan kad yang setara ialah powercfg /devicequery wake_armed, yang menyenaraikan peranti yang dibenarkan mengejutkan sistem. Penyesuai rangkaian yang tiada dalam senarai itu akan mengabaikan setiap paket yang dihantar kepadanya, walau seberapa betul rangka itu kelihatan pada kabel.

Kemudian sahkan jaga itu sendiri dan susulan. Mesin yang menyala tetapi masih tidak dapat dicapai melalui nama memerlukan alamat statik dan rekod DNS, kerana penyelesaian nama melalui siaran masih tidak melintasi terowong. Jaga tanpa wayar ialah keupayaan berasingan dan jauh lebih tidak boleh dipercayai daripada versi berwayar, jadi ujinya dalam segmen yang sama sebelum melibatkan VPN. Tulis nama antara muka dan hos pembantu dalam tiket, kerana kegagalan seterusnya biasanya melibatkan dua fakta yang sama.