بیدار کردن رایانه خانگی خوابیده از طریق VPN: بسته از کجا می‌آید

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

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

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

از یک شبکهٔ هتل به روتر خانه وصل می‌شوید که تنها نقطهٔ پایانی همیشه‌فعال در تصویر است. درخواست بیدار کردنی که روی لپ‌تاپ خود تایپ می‌کنید به ترافیک معمولی تونل تبدیل می‌شود و به هر مقصدی که نام برده‌اید نشانه می‌رود. همان مقصد همهٔ ادامهٔ کار را تعیین می‌کند.

اگر آن را به نشانی LAN روتر خانه روی درگاه بستهٔ جادویی فرستاده باشید، روتر ممکن است داده‌گرام را بپذیرد و هرگز قابی روی بخش خانه منتشر نکند، چون هیچ چیز آنجا به آن درگاه گوش نمی‌دهد. اگر آن را داخل تونل پخش کنید، در واسط تونل متوقف می‌شود. تونل مسیریابی‌شده امتداد لایه 2 سیم‌کشی خانه نیست. مسیر را قدم به قدم دنبال کنید تا بن‌بست آشکار شود.

بررسی‌ای که این را روشن می‌کند به یک فرمان از سمت دور و یک فرمان از سمت خانه نیاز دارد. درخواست را بفرستید و سپس بخش خانه را برای دیدن قاب زیر نظر بگیرید.

فرستنده را به بخش خانه منتقل کنید

روتر می‌تواند خودش بیدار کردن را انجام دهد، به‌محض اینکه از طریق تونل احراز هویت کنید. OpenWrt سرویس Wake-on-LAN را مستند می‌کند که روی دستگاه اجرا می‌شود و قاب را به‌صورت محلی منتشر می‌کند، و این دقیقاً همان شکلی است که لازم است: احراز هویت راه‌دور در بیرون، پخش محلی در درون.

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

وابستگی دوری را باید صریح نام برد. کلاینت VPN نصب‌شده روی رایانهٔ رومیزی نمی‌تواند همان رایانه را بیدار کند، چون فرایند کلاینت به روشن بودن ماشین نیاز دارد. نقطهٔ ورود راه‌دور را روی روتر یا جعبه‌ای دیگر که همیشه روشن است نگه دارید و بگذارید رایانهٔ رومیزی فقط هدف باشد.

پیش از سرزنش تونل، هدف را تأیید کنید

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

نشانی سخت‌افزاری را از آداپتوری بخوانید که واقعاً قاب را دریافت می‌کند. رایانهٔ رومیزی با هم Ethernet و هم Wi-Fi غالباً دو نشانی دارد و شاید فقط یکی از آن‌ها توان بیدار کردن داشته باشد. بیدار کردن بی‌سیم قابلیتی جداست با نیازهای firmware خودش، پس بیدار کردن موفق از طریق Ethernet چیزی دربارهٔ بیدار کردن از طریق Wi-Fi نمی‌گوید.

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

پس از ادامه، به سرویسی که می‌خواستید وصل شوید

بیدار کردن دسترسی راه‌دور نیست. پس از اینکه ماشین ادامه داد، هنوز باید سرویس‌هایش را بالا بیاورد، نشانی بگیرد و جلسه‌ای را که واقعاً لازم دارید بپذیرد. پیش از نتیجه‌گیری از شکست بیدار کردن، به آن وقت بدهید تا به این وضعیت برسد.

# remote side: trigger the wake through the already-authenticated tunnel
ssh [email protected] 'wol -i br-lan 3c:7a:8f:2b:11:04'

# home side: is the target answering on the LAN?
ping -c 3 10.10.0.42
arp -n 10.10.0.42

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

مراحل را در یادداشت‌هایتان جدا کنید: بیدار کردن، راه‌اندازی، سرویس. شکست در مرحلهٔ دوم از یک پنجرهٔ گفتگو دقیقاً مانند شکست در مرحلهٔ اول به نظر می‌رسد و فقط شواهد محلی آن‌ها را از هم جدا می‌کند.