האם שיתוף אינטרנט מכניס את שאר המכשירים שלך ל-VPN?

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

המיתוס: שיתוף החיבור משתף את המנהרה

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

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

מה פאנל השיתוף באמת בוחר

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

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

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

איך חבילה מועברת מוצאת את דרכה

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

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

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

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

בחר את גבול הכיסוי בכוונה

אם המכשיר השני יכול להריץ את הקליינט המאושר, זה הסידור החזק יותר. הוא מקבל פרופיל משלו, זהות משלו ומדיניות משלו, וה-Mac רק מספק את הרשת שמתחת.

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

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

מה לאמת לפני שאתה מבטיח את זה

בדוק את היעד בפועל של המכשיר השני, לא של ה-Mac. שירות פרטי ויציאה ציבורית הם בדיקות שונות, והצלחה באחת לא אומרת דבר על האחרת.

בדוק את שתי משפחות הכתובות ואת פתרון השמות. תצורה שמעבירה IPv4 במנהרה ומשאירה את IPv6 על הקישור הפיזי מייצרת מכשיר שנראה מוגן בדפדפן ומדליף בכל השאר.

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