AirDrop נעלם עם VPN פעיל? בדקו את הניתוב המקומי

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

מה נשבר עוד לפני שהמנהרה בכלל מעורבת

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

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

גיליון השיתוף מתרוקן כשהמסלול המוגדר כברירת מחדל זז

לקוח של מנהרה מלאה מתקין בדרך כלל מסלול ברירת מחדל דרך המנהרה ועוד שני חצאי מסלול שתופסים את רוב היעדים. תת-רשת מקומית שורדת את הסידור הזה רק אם יש לה מסלול ספציפי יותר; אחרת היא נעלמת לתוך המנהרה. AirDrop עצמו רץ מעל ממשק AWDL של עמיתים, כך שלקוח שמסנן או מנתב בתוקפנות ממשקים מקומיים יכול להפריע בזמן שמסלול האינטרנט נשאר מושלם. ארבע פקודות מכסות את הממשק, את המסלולים, את החיבור הפעיל ואת מסנן המנות.

ifconfig awdl0 | grep -E "status|inet"
netstat -rn | grep -E '^default|^0/1|^128.0/1|awdl'
scutil --nc list
sudo pfctl -s rules | head -40

קראו קודם את שורת ברירת המחדל: אם היא מצביעה על ממשק utun ושום מסלול ספציפי יותר לא מכסה את תת-הרשת שלכם, התעבורה המקומית נכנסת למנהרה והמודעות נעלמת איתה. הצמד 0/1 ו-128.0/1 הוא צורה נפוצה של מנהרה מלאה, כי המסלולים האלה מנצחים את ברירת המחדל האמיתית בלי להחליף אותה. שורת awdl0 שמראה סטטוס פעיל וכתובת שוללת שממשק העמיתים למטה. כשכל השלושה נראים תקינים, ההגבלה מגיעה ממדיניות הלקוח או ממסנן על המארח ולא מטבלת הניתוב.

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

מאק מנוהל עשוי לא להציע את מתג הגישה המקומית

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

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

הוכיחו את זה בקובץ, לא בסמל

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

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