VPN ב-Mac, מסנן תוכן או Private Relay: מה פעיל
שלוש שכבות רשת ב-Mac נראות דומה בהגדרות. הבדילו VPN, מסנן תוכן ו-Private Relay לפי נתיב היציאה, מדיניות הזרימה והיקף הגלישה.
ב-Mac שלכם יכולים להיות מותקנים בו-זמנית מנהרת VPN, מסנן תוכן ו-iCloud Private Relay, ואף אחד מהם אינו מודיע מי מהם מעצב חיבור נתון. חלוניות ההגדרות נראות דומות, הסמלים נראים דומים, וכמעט כל ספק קורא למוצר שלו אבטחת רשת. שלוש עובדות מפרידות ביניהם: אם התעבורה יוצאת דרך נקודת קצה מרוחקת שאתם יכולים לנקוב בשמה, אם מנוע מדיניות מחליט לאשר-או-לחסום על זרימות בודדות, ואם ההגנה נגמרת ב-Safari. סדרו את השלושה האלה ורוב השאלות מסוג האם ה-VPN שלי פועל עונות מעצמן.
שלושה תנאים שמזהים את הרכיב
התנאי הראשון הוא היציאה. ספק מנהרה מוסר מנות לשער מרוחק, כך שהכתובת הציבורית שלכם משתנה, ואם הפרופיל אומר זאת, מארחים מאחורי אותו שער נעשים נגישים. אם הכתובת לא משתנה לעולם ואף תת-רשת פרטית לא נפתחת, אינכם רואים מנהרה עובדת, יאמר מה שיאמר סרגל התפריטים.
התנאי השני הוא ההחלטה. מסנן תוכן מעריך זרימות ומחזיר לאשר או לחסום. הוא יכול לאכוף חסימת קטגוריה, כלל לפי אפליקציה או מדיניות שמעסיק דחף, והוא יכול לתעד את הפסיקה. מה שהוא לא יכול לעשות בעצמו הוא לתת לתעבורה מקום ללכת אליו.
התנאי השלישי הוא ההיקף. Private Relay מגן על פלח מוגדר של גלישה ולא על מכשיר שלם, ותפקידו להפריד בין מי שאתם לבין מה שאתם מבקרים, ולא למקם אתכם ברשת אחרת.
העמידו את השלושה זה לצד זה והגבולות קשים לפספוס:
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
מסנן תוכן הוא מנוע מדיניות, לא יציאה
ב-macOS מגיע מסנן בתור Network Extension הבנוי על מחלקת ספק נתוני הסינון של Apple, NEFilterDataProvider. בפריסה מנוהלת MDM דוחף אותו, הוא מותקן כהרחבה של המערכת ומאושר פעם אחת תחת System Settings > General > Login Items and Extensions. מכאן והלאה הוא רואה זרימות TCP, ובכמה תצורות גם UDP, ומחזיר פסיקה על כל אחת.
אופן הכשל הוא מה שמבלבל אנשים. מסנן שדוחה זרימה מייצר פסק זמן, לחיצת יד TLS תקועה או איפוס, שנראה בדיוק כמו מנהרה שעלתה אבל אינה מעבירה תעבורה. הכתובת הציבורית לא השתנתה מעולם, כי מעולם לא הייתה יציאה שתשנה אותה.
לקוחות מסחריים לעיתים קרובות מאגדים את שני התפקידים. מתקין אחד מביא ספק מנהרה ומסנן, המסנן עושה את החסימה והמנהרה עושה את הניתוב. לכן שם האפליקציה לא אומר לכם דבר על איזה רכיב דחה את החיבור. בדקו את רשימת ההרחבות, אחר כך את השירות המחובר, אחר כך את יומן הלקוח, בסדר הזה.
Private Relay מכסה את Safari, לא את המחשב
Private Relay שולח את הגלישה שהוא מכסה דרך שני ממסרים המופעלים בידי גורמים נפרדים, כך שאף מפעיל יחיד לא מחזיק גם את הזהות שלכם וגם את היעדים שלכם. זהו עיצוב פרטיות, לא מנהרה: אין שער להיכנס אליו, אין תת-רשת פרטית, ואין דרך לנעוץ כתובת יציאה במדינה שתבחרו.
ההיקף שלו צר במכוון, ומכסה גלישה ב-Safari יחד עם שאילתות ה-DNS וטעינות ה-HTTP הלא מאובטחות שמתלוות אליה. הפעלת מסוף, לקוח דואר, אפליקציית צ'אט ומשגר משחקים נמצאים מחוצה לו. אם בדיקה במסוף עדיין מציגה את כתובת רשת הגישה שלכם בעוד Safari מציג כתובת ממסר, זו התוצאה הצפויה, לא התקנה שבורה.
הזמינות מותנית. נדרש מסלול iCloud+, הוא לא מוצע בכל אזור, ורשת מנוהלת יכולה לחסום גישה לממסר, ואז Safari חוזר לחיבור ישיר. סקירת Private Relay של Apple היא המקור להיקף הנוכחי. כשפרופיל VPN מחובר ונושא את התעבורה הזו, הממסר אינו נערם מעליו; הפרופיל קובע את המסלול.
קראו את הראיות בסדר הנכון
התחילו ממצב השירות, כי זה האות הזול ביותר. scutil --nc list מדפיס את שירותי ה-VPN המוגדרים ואם כל אחד מהם מחובר. פרופיל יכול לשבת שם שנים בלי להתחבר מעולם, ואנשים נוהגים לספור אותו כמנהרה.
אחר כך הסתכלו על ממשקים ונתיבים. ifconfig מציג ממשקי utun, אבל עצם קיומם מוכיח מעט, כי macOS משתמש ב-utun למספר מטרות מעבר ל-VPN. מה שקובע הוא אם נתיב ברירת המחדל מצביע לתוך אחד מהם, וזה מה ש-route -n get default מדווח.
לפתרון שמות, scutil --dns מפרט את הפותרים שהמערכת תשתמש בהם בפועל, וספק פרוקסי DNS מופיע שם. השוואה בין dig +short example.com ל-dig +short example.com @1.1.1.1 מפרידה בין הפותר שעונה לבין הפותר שמיירטים אותו.
פעילות ההרחבות מגיעה ליומן המאוחד: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. אתם מחפשים איזו הרחבה התחילה ואם מסנן דיווח פסיקה על הזרימה שמעניינת אתכם, לא שורה לשנן.
צמצמו את התסמין לפני שתשביתו משהו
סווגו קודם את הכשל. שם שלא נפתר, חיבור שנדחה מיד, וחיבור שתלוי עד לפסק זמן הם שלושה תצפיות שונים עם שלושה אחראים שונים. פתרון מצביע על פותר או פרוקסי DNS. דחייה מיידית מצביעה על כלל סינון. שתיקה מצביעה בדרך כלל על ניתוב, או על מנהרה שעלתה אך אינה מעבירה.
ב-Mac מנוהל הניחו שהמסנן שייך לארגון. השבתתו כדי לבדוק את ה-VPN מסירה את הרכיב שרציתם לצפות בו, ו-MDM לעיתים קרובות מחזיר אותו בבדיקה הבאה. בקשו מהמנהל את שם המדיניות לפני שאתם משנים משהו, ובדקו עם האפליקציה הספציפית שנכשלה ולא עם המערכת כולה.
מלכודת נוספת: כיבוי Private Relay כדי לבדוק VPN לא אומר דבר על תעבורה זרה, כי הממסר מעולם לא כיסה את התעבורה הזו. כל שכבה חייבת להיבדק באפליקציה שהיא באמת שולטת בה.
עברו על הרשימה הזו ועצרו בפריט הראשון שנכשל:
- האם
scutil --nc listמציג את השירות שאתם מצפים לו כמחובר? - האם הכתובת הציבורית הנצפית מהמסוף שונה מהכתובת שרשת הגישה שלכם הקצתה?
- האם מותקנת הרחבת סינון, והאם היא תיעדה פסיקה על הזרימה שנכשלת?
- האם הכשל הוא ב-Safari בלבד? אם כן, בדקו את היקף הממסר לפני שתאשימו את המנהרה.
אם כל הארבעה עוברים והאפליקציה עדיין נכשלת, הבעיה נמצאת מעל שכבת הרשת: הגדרות פרוקסי, אמון בתעודות או רשימת היתרים ברמת האפליקציה.