Wake-on-LAN דרך VPN לא עובד? השידור לא עובר אף פעם

אתם מרדימים את מחשב המשרד, מתחברים ל-VPN מהבית, והוא נשאר כבוי. המנהרה פעילה, שיתופי הקבצים מגיבים, ועמוד ה-wake-on-LAN של הנתב מדווח ששלח את הבקשה. כל אות גלוי אומר שהרשת תקינה, ובדיוק משום כך המקרה הזה מבלבל: הפריים שאמור להעיר את המחשב לא מגיע לעולם לסגמנט שבו הוא נמצא.

התסמינים מצביעים על תת-הרשת, לא על המנהרה

ה-ping אל המארח הישן נכשל, וזה החלק התקין. מחשב במצב המתנה אינו מריץ מחסנית IP, ולכן אינו יכול להשיב ל-ARP או ל-ICMP, ואין תצורת מנהרה שמשנה זאת. הבדיקה השימושית היא אם מחשב שני באותה LAN מתעורר, ואם עמוד ההערה של הנתב עצמו עובד עבור מארח שמחובר אליו.

ברגע שהבדיקה באותו סגמנט עוברת, התקלה היא בהיקף. השולח שבו אתם משתמשים חי בממשק ה-VPN, והחבילה שהוא בונה היא שידור עבור הקישור המקומי, ולכן היא יוצאת מהממשק הלא נכון או לא יוצאת כלל. המנהרה אינה שבורה; היא נושאת סוג תנועה לא נכון. גלו איזה ממשק בוחר השולח לפני שתשנו ולו הגדרה אחת בנתב.

חבילת magic packet היא פריים, לא שירות

המטען מתחיל בכותרת קבועה של שישה בתים, 0xFF, אחר כך כתובת החומרה של כרטיס היעד חוזרת שש עשרה פעמים, ואחר כך סיסמת SecureOn אופציונלית של ארבעה בתים. שולחים עוטפים זאת בדרך כלל ב-UDP אל פורט 7 או פורט 9, אבל מספר הפורט הוא מוסכמה בין שולח לכרטיס, לא שירות שמאזין ושאליו מתחברים. שום דבר לא מאזין, ושום דבר לא משיב.

מה שמעיר את המחשב הוא ממשק הרשת, שמחזיק חלק קטן מהמעגלים תחת מתח מפס ההמתנה בזמן ששאר המערכת כבויה. לכן ההגדרה חייבת לשרוד גם ניתוק חשמל מלא וגם שינה: לוח אם שמנתק את מתח ההמתנה בזמן כיבוי לא משאיר כרטיס שיקבל דבר.

למה מנהרה מנותבת לא יכולה למסור אותה

ממשק VPN מנותב הוא קישור IP מנקודה לנקודה בין שתי כתובות מנהרה. הוא קיים כדי לשאת חבילות הממוענות לעמית, ולכן ping, SSH ושיתופי קבצים מתנהגים דרכו כרגיל. פריים שידור אינו ממוען לעמית הזה, וכתובת השידור המוגבלת לעולם אינה מועברת על ידי נתב כדבר שבשגרה.

העברת שידור המכוון לתת-רשת היא יכולת מכוונת של הנתב שרוב תצורות ברירת המחדל מכבות, וגם אז היא נמסרת לאותה תת-רשת ולא לכרטיס ישן מסוים. מארח ישן גם אינו יכול להשיב ל-ARP, ולכן נתב שמנסה לפתור את כתובת היעד לפני ההעברה מפיל את הפריים בזמן שהוא ממתין לתשובה שלעולם לא תגיע. רשומת קישור סטטית מתקנת את החלק הזה ומשאירה את בעיית היקף השידור ללא שינוי. שתי מגבלות נפרדות אפוא, והסרת האחת אינה עושה דבר לשנייה.

שלושה מיקומים שבאמת מגיעים לכרטיס

כל סידור ישים שם את הפריים בסגמנט של היעד, והם נבדלים במידת ההפרעה לרשת:

1. הציבו התקן שתמיד דלוק בסגמנט היעד. נתב, NAS או קופסת Linux קטנה שנשארת תחת מתח יכולים לשדר את הפריים באופן מקומי ברגע שתגיעו אליהם דרך המנהרה, ושום דבר ב-VPN לא משתנה.
2. תנו לנתב לשדר את הפריים בעצמו. קושחות רבות מציעות עמוד הערה ששולח מגשר ה-LAN, וזה עובד כל עוד היעד יושב על אותו גשר ולא מאחורי נתב שני.
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 של השידור הוא ההוכחה היחידה שהשידור עבד; אם הלכידה ריקה, השולח בחר ממשק אחר ושאר הבדיקה חסר משמעות. שולח שבונה פריים גולמי במקום datagram של UDP לא מתאים למסנן הזה, לכן בדקו איזו צורה משתמשת הכלי שלכם לפני שתסיקו ששום דבר לא נשלח.

ב-Windows הבדיקה המקבילה של הכרטיס היא powercfg /devicequery wake_armed, שמפרטת את ההתקנים שמורשים להעיר את המערכת. מתאם רשת שחסר ברשימה הזו יתעלם מכל חבילה שנשלחת אליו, ככל שהפריים ייראה נכון על הכבל.

לאחר מכן אשרו את ההערה עצמה ואת ההמשך. מחשב שנדלק אבל נשאר בלתי נגיש לפי שם זקוק לכתובת סטטית ולרשומת DNS, כי פענוח שמות בשידור עדיין לא חוצה את המנהרה. הערה אלחוטית היא יכולת נפרדת והרבה פחות אמינה מהגרסה החוטית, לכן בדקו אותה באותו סגמנט לפני שמערבים את ה-VPN בכלל. כתבו בכרטיס את שם הממשק ואת המארח של העוזר, כי התקלה הבאה נוגעת בדרך כלל באותן שתי עובדות.