VPN üzərindən Wake-on-LAN işləmir? Yayım heç vaxt keçmir

Ofis maşınını yuxuya salırsınız, evdən VPN-ə qoşulursunuz, amma o, söndürülmüş qalır. Tunel qalxıb, fayl paylaşımları cavab verir və marşrutlaşdırıcının wake-on-LAN səhifəsi sorğunun göndərildiyini bildirir. Görünən hər siqnal şəbəkənin qaydasında olduğunu deyir və bu işi çaşdırıcı edən də elə budur: maşını oyadacaq kadr onun yerləşdiyi seqmentə heç vaxt çatmır.

Simptomlar tunelə deyil, alt şəbəkəyə işarə edir

Yuxuda olan hosta ping getmir və bu hissə normaldır. Gözləmə rejimindəki maşında işləyən IP yığını yoxdur, ona görə ARP və ya ICMP-yə cavab verə bilməz və heç bir tunel konfiqurasiyası bunu dəyişmir. Faydalı test eyni LAN-dakı ikinci maşının oyanıb-oyanmadığı və marşrutlaşdırıcının öz oyatma səhifəsinin ona qoşulmuş host üçün işləyib-işləmədiyidir.

Eyni seqmentdəki test keçdikdən sonra qüsur əhatədədir. İstifadə etdiyiniz göndərən VPN interfeysində yaşayır və qurduğu paket yerli keçid üçün yayımdır, ona görə yanlış interfeysdən çıxır ya da heç çıxmır. Tunel xarab deyil; səhv növ trafik daşıyır. Bir dənə də olsun marşrutlaşdırıcı parametrini dəyişməzdən əvvəl göndərənin hansı interfeysi seçdiyini öyrənin.

Magic packet kadrdır, xidmət deyil

Faydalı yük altı baytlıq sabit başlıqla başlayır, 0xFF, sonra hədəf kartın aparat ünvanı on altı dəfə təkrarlanır, sonra istəyə bağlı dörd baytlıq SecureOn parolu gəlir. Göndərənlər bunu adətən UDP içində port 7 və ya port 9-a yığır, amma port nömrəsi göndərənlə kart arasında razılaşmadır, qoşula biləcəyiniz dinləyici deyil. Heç nə dinləmir və heç nə cavab vermir.

Maşını oyadan şey şəbəkə interfeysidir, o, sistemin qalan hissəsi söndürülmüş halda kiçik bir dövrə hissəsini gözləmə şinindən qidalandırır. Ona görə parametr həm tam enerji itkisini, həm də yuxunu keçməlidir: söndürərkən gözləmə enerjisini kəsən plata artıq nə isə qəbul edəcək kart saxlamır.

Marşrutlaşdırılmış tunel bunu niyə çatdıra bilmir

Marşrutlaşdırılmış VPN interfeysi iki tunel ünvanı arasında nöqtədən nöqtəyə IP əlaqəsidir. O, tərəfdaşa ünvanlanmış paketləri daşımaq üçün mövcuddur və buna görə ping, SSH və fayl paylaşımları onun üzərindən normal davranır. Yayım kadrı həmin tərəfdaşa ünvanlanmayıb və məhdud yayım ünvanı marşrutlaşdırıcı tərəfindən heç vaxt avtomatik ötürülmür.

Alt şəbəkəyə yönəlmiş yayımın ötürülməsi marşrutlaşdırıcının qəsdən qoyduğu imkandır və əksər standart konfiqurasiyalar onu söndürür, hətta o halda da o, həmin alt şəbəkəyə çatdırılır, konkret yuxuda olan karta yox. Yuxuda olan host ARP-yə də cavab verə bilməz, ona görə ötürmədən əvvəl hədəf ünvanı həll etməyə çalışan marşrutlaşdırıcı kadrı atır, heç vaxt gəlməyəcək cavabı gözləyərkən. Statik bağlama qeydi o hissəni düzəldir və yayım əhatəsi probleminə toxunmadan qoyur. Deməli, iki ayrı məhdudiyyət və birinin aradan qaldırılması digəri üçün heç nə etmir.

Karta həqiqətən çatan üç yerləşdirmə

Hər işlək quruluş kadrı hədəfin seqmentinə qoyur və onlar şəbəkəni nə qədər narahat etmələri ilə fərqlənir:

1. Hədəf seqmentə həmişə açıq olan cihaz qoyun. Enerji altında qalan marşrutlaşdırıcı, NAS və ya kiçik Linux qutusu tuneldən ona çatdıqdan sonra kadrı yerli olaraq yaya bilər və VPN-də heç nə dəyişmir.
2. Marşrutlaşdırıcı kadrı özü yaysın. Bir çox proqram təminatı LAN körpüsündən göndərən oyatma səhifəsi təklif edir və bu, hədəf ikinci marşrutlaşdırıcının arxasında deyil, həmin körpüdə olduğu müddətcə işləyir.
3. Yayımlar həqiqətən keçməlidirsə, məntəqələri TAP tipli tunellə körpüləyin. Bu, iki yayım domenini birləşdirir; yayım fırtınaları, vahid ünvan planı və hər iki məntəqəni eyni anda görən hər kəşf protokolu ilə birlikdə.

Birinci variant tək maşın üçün üstün tutulmalı olandır. Üçüncüsü davamlı xərci olan şəbəkə dizaynı qərarıdır, ona görə ona elə yanaşın, bir iş masası üçün sürətli düzəliş kimi yox.

Hansı köməkçinin kadrı yaydığını və hansı körpüdə və ya VLAN-da durduğunu qeyd edin. Yanlış interfeysdən yayan köməkçi mükəmməl qeyd və heç vaxt oyanmayan maşın verir, bu birləşmə isə bir günorta vaxt aparır.

Müştərini günahlandırmazdan əvvəl göndərişi yoxlayın

Əvvəlcə hədəf kartı yoxlayın, çünki heç bir göndərən hazır olmayan kartı oyada bilməz. Aşağıdakı əmr dəstəklənən və cari oyatma rejimlərini oxuyur, cari g dəyəri magic packet-in qoşulduğunu bildirir:

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öndəriş gedərkən qeydi köməkçidə işə salın və uğur ehtimal etmək yerinə onu oxuyun. Düzgün körpüdən yayım hədəf MAC-i ilə çıxan kadr göndərişin işlədiyinin yeganə sübutudur; qeyd boşdursa, göndərən başqa interfeys seçib və testin qalan hissəsi mənasızdır. UDP veraqramı yerinə xam kadr quran göndərən bu filtrə uyğun gəlmir, ona görə heç nə göndərilmədiyi qənaətinə gəlməzdən əvvəl alətinizin hansı formadan istifadə etdiyini yoxlayın.

Windows-da kartın ekvivalent yoxlaması powercfg /devicequery wake_armed-dir və sistemi oyatmağa icazə verilən cihazları sadalayır. O siyahıda olmayan şəbəkə adapteri ona göndərilən hər paketi nəzərə almayacaq, kadr kabeldə nə qədər düzgün görünsə də.

Sonra oyanmanın özünü və davamını təsdiqləyin. Açılan, amma adla əlçatmaz qalan maşın statik ünvan və DNS qeydi tələb edir, çünki yayımla ad həlli hələ də tuneldən keçmir. Simşiz oyatma kabel variantından ayrı və qat-qat az etibarlı imkandır, ona görə VPN-i heç işə qatmadan əvvəl onu eyni seqmentdə sınayın. İnterfeys adını və köməkçinin hostunu bilettə yazın, çünki növbəti nasazlıq adətən eyni iki faktdan gedir.