VPN üzerinden Wake-on-LAN çalışmıyor mu? Yayın asla karşıya geçmiyor

Tünel ayakta ve paylaşımlar yanıt veriyor, ama makine uykuda kalıyor. Magic packet hedefin kendi segmentinde yayılmalı, bu yüzden oraya bir yardımcı koyun.

Ofis makinesini uykuya alıyorsunuz, evden VPN'e bağlanıyorsunuz ve makine kapalı kalıyor. Tünel ayakta, dosya paylaşımları yanıt veriyor ve yönlendiricinin wake-on-LAN sayfası isteği gönderdiğini bildiriyor. Görünen her sinyal ağın iyi olduğunu söylüyor ve bu vakayı kafa karıştırıcı yapan tam da bu: makineyi uyandıracak çerçeve, makinenin bulunduğu segmente hiç ulaşmıyor.

Belirtiler tünele değil, alt ağa işaret ediyor

Uyuyan ana bilgisayara ping gitmiyor ve bu kısım normal. Bekleme modundaki bir makinede çalışan bir IP yığını yoktur, bu yüzden ARP veya ICMP'ye yanıt veremez ve hiçbir tünel yapılandırması bunu değiştirmez. Faydalı test, aynı LAN'daki ikinci bir makinenin uyanıp uyanmadığı ve yönlendiricinin kendi uyandırma sayfasının ona bağlı bir ana bilgisayar için çalışıp çalışmadığıdır.

Aynı segmentteki test geçtiğinde sorun kapsamdadır. Kullandığınız gönderici VPN arayüzünde yaşıyor ve kurduğu paket yerel bağlantı için bir yayın olduğundan yanlış arayüzden çıkıyor ya da hiç çıkmıyor. Tünel bozuk değil; yanlış türde trafik taşıyor. Tek bir yönlendirici ayarını değiştirmeden önce göndericinin hangi arayüzü seçtiğini bulun.

Magic packet bir çerçevedir, hizmet değil

Yük, altı baytlık sabit bir başlıkla başlar, 0xFF, ardından hedef kartın donanım adresi on altı kez tekrarlanır, ardından isteğe bağlı dört baytlık bir SecureOn parolası gelir. Göndericiler bunu genellikle UDP içine sarıp port 7 veya port 9'a gönderir, ancak port numarası gönderici ile kart arasında bir uzlaşımdır; bağlanabileceğiniz bir dinleyici değildir. Hiçbir şey dinlemiyor ve hiçbir şey yanıt vermiyor.

Makineyi uyandıran şey, sistemin geri kalanı kapalıyken küçük bir devre bölümünü bekleme rayından besleyen ağ arayüzüdür. Bu yüzden ayar hem tam güç kaybını hem de uykuyu atlatmalıdır: kapanırken bekleme gücünü kesen bir anakartta artık bir şey alabilecek kart kalmaz.

Yönlendirilmiş bir tünel bunu neden teslim edemez

Yönlendirilmiş bir VPN arayüzü, iki tünel adresi arasında noktadan noktaya bir IP bağlantısıdır. Eşe adreslenmiş paketleri taşımak için vardır ve bu yüzden ping, SSH ve dosya paylaşımları onun üzerinden normal davranır. Yayın çerçevesi o eşe adreslenmemiştir ve sınırlı yayın adresi bir yönlendirici tarafından kendiliğinden asla iletilmez.

Alt ağa yönelik bir yayını iletmek, çoğu varsayılan yapılandırmanın kapattığı bilinçli bir yönlendirici yeteneğidir ve o zaman bile o alt ağa teslim eder, belirli bir uyuyan karta değil. Uyuyan bir ana bilgisayar ARP'ye de yanıt veremez, bu yüzden iletmeden önce hedef adresi çözmeye çalışan bir yönlendirici, asla gelmeyecek bir yanıtı beklerken çerçeveyi düşürür. Statik bir bağlama girdisi o kısmı düzeltir ve yayın kapsamı sorununu dokunulmadan bırakır. Yani iki ayrı kısıt ve birini kaldırmak diğeri için hiçbir şey yapmaz.

Karta gerçekten ulaşan üç yerleşim

İşleyen her düzen çerçeveyi hedefin segmentine koyar ve bunlar ağı ne kadar rahatsız ettikleriyle ayrılır:

  1. Hedef segmente her zaman açık bir cihaz koyun. Güç altında kalan bir yönlendirici, NAS veya küçük bir Linux kutusu, tünelden ona ulaştığınızda çerçeveyi yerel olarak yayabilir ve VPN'de hiçbir şey değişmez.
  2. Yönlendiricinin çerçeveyi kendisi yaymasına izin verin. Birçok ürün yazılımı LAN köprüsünden gönderen bir uyandırma sayfası sunar ve bu, hedef ikinci bir yönlendiricinin arkasında değil de o köprüde olduğu sürece çalışır.
  3. Yayınların gerçekten geçmesi gerektiğinde siteleri TAP tipi bir tünelle köprüleyin. Bu, iki yayın alanını birleştirir; yayın fırtınaları, tek bir adres planı ve iki siteyi aynı anda gören her keşif protokolü beraberinde gelir.

İlk seçenek tek bir makine için tercih edilmesi gerekendir. Üçüncüsü, sürekli maliyeti olan bir ağ tasarımı kararıdır, bu yüzden onu öyle ele alın, tek bir masaüstü için hızlı bir düzeltme olarak değil.

Hangi yardımcının çerçeveyi yaydığını ve hangi köprüde veya VLAN'da durduğunu kaydedin. Yanlış arayüzden yayın yapan bir yardımcı kusursuz bir kayıt ve asla uyanmayan bir makine verir; bu bileşim bir öğleden sonraya mal olur.

İstemciyi suçlamadan önce gönderimi doğrulayın

Önce hedef kartı kontrol edin, çünkü hiçbir gönderici hazır olmayan bir kartı uyandıramaz. Aşağıdaki komut desteklenen ve geçerli uyandırma kiplerini okur; geçerli değer g ise magic packet açık demektir:

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

Gönderim olurken kaydı yardımcıda çalıştırın ve başarı varsaymak yerine okuyun. Doğru köprüden yayın hedef MAC'i ile çıkan bir çerçeve, gönderimin çalıştığının tek kanıtıdır; kayıt boşsa gönderici başka bir arayüz seçmiştir ve testin geri kalanı anlamsızdır. UDP datagramı yerine ham bir çerçeve kuran gönderici bu filtreye uymaz, bu yüzden hiçbir şey gönderilmediği sonucuna varmadan önce aracınızın hangi biçimi kullandığını kontrol edin.

Windows'ta kartın eşdeğer kontrolü powercfg /devicequery wake_armed olup sistemi uyandırmasına izin verilen aygıtları listeler. O listede olmayan bir ağ bağdaştırıcısı, çerçeve kabloda ne kadar doğru görünürse görünsün, ona gönderilen her paketi yok sayar.

Ardından uyanmanın kendisini ve devamını doğrulayın. Açılan ama adıyla ulaşılamaz kalan bir makine statik bir adrese ve DNS kaydına ihtiyaç duyar, çünkü yayınla ad çözümleme hâlâ tüneli geçmiyor. Kablosuz uyandırma, kablolu sürümden ayrı ve çok daha az güvenilir bir yetenektir, bu yüzden VPN'i hiç devreye sokmadan önce aynı segmentte test edin. Arayüz adını ve yardımcının ana bilgisayarını kayda yazın, çünkü sonraki arıza genellikle aynı iki gerçekle ilgilidir.

İlgili makaleler