Wake-on-LAN از طریق VPN کار نمی‌کند؟ بسته هرگز عبور نمی‌کند

دستگاه دفتر را به خواب می‌فرستید، از خانه VPN را وصل می‌کنید، و دستگاه خاموش می‌ماند. تونل برپاست، اشتراک فایل پاسخ می‌دهد، و صفحه wake-on-LAN روتر گزارش می‌دهد که درخواست را فرستاده است. هر نشانهٔ دیدنی می‌گوید شبکه سالم است، و دقیقاً به همین دلیل این مورد گیج‌کننده است: قابی که دستگاه را بیدار می‌کند هرگز به بخشی که دستگاه در آن است نمی‌رسد.

نشانه‌ها به زیرشبکه اشاره می‌کنند، نه به تونل

پینگ به میزبان خواب‌رفته شکست می‌خورد، و آن بخش عادی است. دستگاهی در حالت آماده‌به‌کار پشتهٔ IP فعال ندارد، پس نمی‌تواند به ARP یا ICMP پاسخ دهد، و هیچ تنظیم تونلی این را تغییر نمی‌دهد. آزمون سودمند این است که آیا دستگاه دومی در همان شبکه محلی بیدار می‌شود و آیا صفحهٔ بیدارسازی خود روتر برای میزبانی که به آن وصل است کار می‌کند.

وقتی آزمون در همان بخش موفق شد، ایراد در دامنه است. فرستنده‌ای که به کار می‌برید روی رابط VPN زندگی می‌کند، و بسته‌ای که می‌سازد پخش برای پیوند محلی است، پس از رابط اشتباه بیرون می‌رود یا اصلاً بیرون نمی‌رود. تونل خراب نیست؛ نوع اشتباهی از ترافیک را حمل می‌کند. پیش از تغییر حتی یک تنظیم روتر، دریابید فرستنده کدام رابط را انتخاب می‌کند.

magic packet یک قاب است، نه یک سرویس

بار مفید با سرآیند ثابتی از شش بایت 0xFF آغاز می‌شود، سپس نشانی سخت‌افزاری کارت مقصد شانزده بار تکرار می‌شود، سپس گذرواژهٔ اختیاری چهاربایتی SecureOn می‌آید. فرستنده‌ها معمولاً این را در UDP به درگاه 7 یا درگاه 9 می‌پیچند، اما شمارهٔ درگاه قراردادی میان فرستنده و کارت است، نه شنونده‌ای که بتوان به آن وصل شد. چیزی گوش نمی‌دهد و چیزی پاسخ نمی‌دهد.

آنچه دستگاه را بیدار می‌کند رابط شبکه است که بخش کوچکی از مدارها را از ریل آماده‌به‌کار روشن نگه می‌دارد در حالی که بقیهٔ سیستم خاموش است. از همین رو تنظیم باید هم قطع کامل برق و هم خواب را تحمل کند: مادربوردی که هنگام خاموش شدن برق آماده‌به‌کار را قطع می‌کند دیگر کارتی ندارد که چیزی بگیرد.

چرا یک تونل مسیریابی‌شده نمی‌تواند آن را برساند

رابط VPN مسیریابی‌شده پیوندی IP از نقطه به نقطه میان دو نشانی تونل است. وجود دارد تا بسته‌های نشانی‌شده به همتا را حمل کند، و به همین دلیل پینگ و SSH و اشتراک فایل از آن به‌طور عادی کار می‌کنند. قاب پخش به آن همتا نشانی نشده است، و نشانی پخش محدود هرگز به‌طور معمول توسط روتر ارسال نمی‌شود.

ارسال پخشی که به زیرشبکه نشانه رفته قابلیتی آگاهانه در روتر است که بیشتر پیکربندی‌های پیش‌فرض آن را می‌بندند، و حتی در آن حالت به همان زیرشبکه می‌رساند نه به کارت خواب‌رفتهٔ مشخص. میزبان خواب‌رفته به ARP هم پاسخ نمی‌دهد، پس روتری که می‌خواهد پیش از ارسال نشانی مقصد را حل کند قاب را رها می‌کند در حالی که منتظر پاسخی است که هرگز نمی‌آید. یک ورودی اتصال ایستا آن بخش را درست می‌کند و مشکل دامنهٔ پخش را دست‌نخورده می‌گذارد. پس دو محدودیت جداگانه، و برداشتن یکی هیچ کاری برای دیگری نمی‌کند.

سه جای‌گذاری که واقعاً به کارت می‌رسند

هر چیدمان کارآمد قاب را در بخش مقصد می‌گذارد، و آن‌ها در این تفاوت دارند که چقدر شبکه را مختل می‌کنند:

1. دستگاهی همیشه روشن را در بخش مقصد بگذارید. روتر، NAS یا جعبهٔ کوچک لینوکس که برق می‌ماند می‌تواند قاب را به‌صورت محلی بفرستد، به‌محض اینکه از تونل به آن برسید، و هیچ چیز در VPN تغییر نمی‌کند.
2. بگذارید روتر خودش قاب را بفرستد. بسیاری از فرم‌ورها صفحهٔ بیدارسازی عرضه می‌کنند که از پل شبکهٔ محلی می‌فرستد، و این تا زمانی کار می‌کند که مقصد روی همان پل باشد نه پشت روتر دوم.
3. سایت‌ها را با تونلی از نوع TAP پل بزنید وقتی پخش‌ها واقعاً باید عبور کنند. این دو دامنهٔ پخش را یکی می‌کند و توفان پخش، طرح نشانی یکتا و هر پروتکل کشفی که هر دو سایت را هم‌زمان می‌بیند با خود می‌آورد.

گزینهٔ نخست برای یک دستگاه ترجیح دارد. گزینهٔ سوم تصمیم طراحی شبکه با هزینهٔ پیوسته است، پس آن را چنین بدانید نه راه‌حل سریع برای یک رومیزی.

بنویسید کدام کمک‌کننده قاب را می‌فرستد و روی کدام پل یا VLAN است. کمک‌کننده‌ای که از رابط اشتباه می‌فرستد یک ضبط کامل و دستگاهی می‌دهد که هرگز بیدار نمی‌شود، و این ترکیب یک بعدازظهر را می‌خورد.

پیش از سرزنش کارخواه، ارسال را بررسی کنید

نخست کارت مقصد را بررسی کنید، زیرا هیچ فرستنده‌ای کارتی را که آماده نیست بیدار نمی‌کند. فرمان زیر حالت‌های بیدارسازی پشتیبانی‌شده و کنونی را می‌خواند، جایی که مقدار کنونی g یعنی magic packet روشن است:

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

ضبط را روی کمک‌کننده در حین ارسال اجرا کنید و بخوانیدش به‌جای اینکه موفقیت را فرض بگیرید. قابی که پل درست را با MAC مقصد پخش ترک می‌کند تنها شاهد کارکرد ارسال است؛ اگر ضبط خالی است فرستنده رابط دیگری برگزیده و بقیهٔ آزمون بی‌معناست. فرستنده‌ای که قاب خام می‌سازد نه داده‌گرام UDP با آن پالایه جور درنمی‌آید، پس پیش از نتیجه‌گیری که چیزی فرستاده نشده، بررسی کنید ابزارتان چه قالبی به کار می‌برد.

در ویندوز بررسی هم‌ارز کارت powercfg /devicequery wake_armed است که دستگاه‌های مجاز به بیدار کردن سیستم را فهرست می‌کند. کارت شبکه‌ای که از آن فهرست جا مانده باشد هر بسته‌ای را که به آن فرستاده شود نادیده می‌گیرد، هرقدر هم قاب روی سیم درست به نظر برسد.

سپس خود بیدار شدن و ادامهٔ کار را تأیید کنید. دستگاهی که روشن می‌شود اما با نام دسترس‌ناپذیر می‌ماند به نشانی ایستا و رکورد DNS نیاز دارد، زیرا حل نام با پخش هنوز از تونل نمی‌گذرد. بیدارسازی بی‌سیم قابلیتی جداست و بسیار کم‌اعتمادتر از نسخهٔ باسیم، پس آن را در همان بخش پیش از دخالت دادن VPN بیازمایید. نام رابط و میزبان کمک‌کننده را در تیکت بنویسید، زیرا خرابی بعدی معمولاً به همان دو واقعیت مربوط است.