Wake-on-LAN lewat VPN tidak bekerja? Siaran tidak pernah menyeberang

Anda menidurkan mesin kantor, menyambung VPN dari rumah, dan mesin tetap mati. Tunel aktif, berbagi berkas menjawab, dan halaman wake-on-LAN router melaporkan telah mengirim permintaan. Setiap sinyal yang terlihat mengatakan jaringan baik-baik saja, dan justru karena itu kasus ini membingungkan: frame yang seharusnya membangunkan mesin tidak pernah mencapai segmen tempat mesin berada.

Gejalanya menunjuk ke subnet, bukan ke tunel

Ping ke host yang tidur gagal, dan bagian itu normal. Mesin dalam mode siaga tidak memiliki tumpukan IP yang berjalan, sehingga tidak bisa menjawab ARP atau ICMP, dan tidak ada konfigurasi tunel yang mengubahnya. Uji yang berguna adalah apakah mesin kedua di LAN yang sama terbangun, dan apakah halaman bangun milik router bekerja untuk host yang terpasang padanya.

Setelah uji di segmen yang sama lolos, kesalahannya ada pada cakupan. Pengirim yang Anda pakai hidup di antarmuka VPN, dan paket yang dibangunnya adalah siaran untuk tautan lokal, jadi keluar dari antarmuka yang salah atau tidak keluar sama sekali. Tunel tidak rusak; ia membawa jenis lalu lintas yang salah. Cari tahu antarmuka mana yang dipilih pengirim sebelum mengubah satu pun pengaturan router.

Magic packet adalah frame, bukan layanan

Muatan diawali header tetap enam byte 0xFF, lalu alamat perangkat keras kartu tujuan diulang enam belas kali, lalu kata sandi SecureOn opsional empat byte. Pengirim biasanya membungkusnya dalam UDP ke port 7 atau port 9, tetapi nomor port adalah kesepakatan antara pengirim dan kartu, bukan pendengar yang bisa dihubungi. Tidak ada yang mendengarkan, dan tidak ada yang menjawab.

Yang membangunkan mesin adalah antarmuka jaringan, yang menjaga sebagian kecil rangkaian tetap berdaya dari rel siaga selama sisa sistem mati. Karena itu pengaturannya harus bertahan terhadap kehilangan daya penuh maupun tidur: papan yang memutus daya siaga saat dimatikan tidak lagi punya kartu untuk menerima apa pun.

Mengapa tunel terarah tidak bisa mengantarkannya

Antarmuka VPN terarah adalah tautan IP titik-ke-titik antara dua alamat tunel. Ia ada untuk membawa paket yang dialamatkan ke rekan, karena itu ping, SSH, dan berbagi berkas berperilaku normal melaluinya. Frame siaran tidak dialamatkan ke rekan itu, dan alamat siaran terbatas tidak pernah diteruskan router secara otomatis.

Meneruskan siaran yang diarahkan ke subnet adalah kemampuan sengaja pada router yang dimatikan oleh sebagian besar konfigurasi bawaan, dan bahkan saat aktif ia mengantar ke subnet itu, bukan ke kartu tidur tertentu. Host yang tidur juga tidak bisa menjawab ARP, jadi router yang mencoba menyelesaikan alamat tujuan sebelum meneruskan akan membuang frame itu sambil menunggu jawaban yang tak akan datang. Entri pengikatan statis memperbaiki bagian itu dan membiarkan masalah cakupan siaran tetap utuh. Jadi dua batasan terpisah, dan menghapus satu tidak melakukan apa pun untuk yang lain.

Tiga penempatan yang benar-benar mencapai kartu

Setiap tata letak yang bisa dipakai menaruh frame di segmen tujuan, dan semuanya berbeda dalam seberapa banyak mengganggu jaringan:

1. Letakkan perangkat yang selalu menyala di segmen tujuan. Router, NAS, atau kotak Linux kecil yang tetap berdaya dapat memancarkan frame secara lokal begitu Anda mencapainya lewat tunel, dan tidak ada yang berubah pada VPN.
2. Biarkan router sendiri yang memancarkan frame. Banyak firmware menyediakan halaman bangun yang mengirim dari jembatan LAN, dan itu bekerja selama tujuan berada di jembatan tersebut dan bukan di belakang router kedua.
3. Jembatani kedua lokasi dengan tunel bergaya TAP ketika siaran memang harus menyeberang. Ini menyatukan dua domain siaran, membawa badai siaran, satu rencana alamat, dan setiap protokol penemuan yang melihat kedua lokasi sekaligus.

Opsi pertama adalah yang patut dipilih untuk satu mesin. Opsi ketiga adalah keputusan desain jaringan dengan biaya berkelanjutan, jadi perlakukan sebagai itu, bukan sebagai perbaikan cepat untuk satu desktop.

Catat pembantu mana yang memancarkan frame dan di jembatan atau VLAN mana ia berada. Pembantu yang memancar dari antarmuka salah menghasilkan tangkapan sempurna dan mesin yang tak pernah bangun, dan kombinasi itu memakan satu sore.

Verifikasi pengiriman sebelum menyalahkan klien

Periksa kartu tujuan lebih dulu, sebab tidak ada pengirim yang bisa membangunkan kartu yang belum siap. Perintah di bawah membaca mode bangun yang didukung dan yang berlaku, di mana nilai berlaku g berarti magic packet aktif:

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 selagi pengiriman berlangsung, dan bacalah alih-alih menganggapnya berhasil. Frame yang meninggalkan jembatan yang benar dengan MAC tujuan siaran adalah satu-satunya bukti bahwa pengiriman berhasil; jika tangkapan kosong, pengirim memilih antarmuka lain dan sisa uji tidak bermakna. Pengirim yang membangun frame mentah alih-alih datagram UDP tidak cocok dengan penyaring itu, jadi periksa bentuk apa yang dipakai alat Anda sebelum menyimpulkan tidak ada yang dikirim.

Di Windows pemeriksaan kartu yang setara adalah powercfg /devicequery wake_armed, yang mendaftar perangkat yang boleh membangunkan sistem. Adaptor jaringan yang tidak ada di daftar itu akan mengabaikan setiap paket yang dikirim kepadanya, seberapa pun benar frame di kabel.

Lalu pastikan bangunnya sendiri dan kelanjutannya. Mesin yang menyala tetapi tetap tak terjangkau lewat nama memerlukan alamat statis dan catatan DNS, karena penyelesaian nama lewat siaran tetap tidak menyeberangi tunel. Bangun nirkabel adalah kemampuan terpisah dan jauh lebih tidak andal daripada versi kabel, jadi ujilah di segmen yang sama sebelum melibatkan VPN. Tulis nama antarmuka dan host pembantu di tiket, karena kegagalan berikutnya biasanya menyangkut dua fakta yang sama.