התחברות VPN אחת במחשב משותף: מי עוד מקבל את המסלול?
התחברות VPN מאמתת אדם אחד; המסלול שהיא מתקינה הוא היקף אחר. השוו מנהרות ברמת המארח, ברמת המשתמש וברמת היישום במכונה משותפת.
שיתוף תחנת עבודה מעלה שאלה שמחשב נייד של משתמש יחיד אינו צריך לענות עליה לעולם: ברגע שאדם אחד מאמת את המנהרה, מי עוד יכול להשתמש בה? ההתחברות מזהה סובייקט, והמסלול שהיא מתקינה מתאר היקף, ושני הדברים האלה אינם אותו אובייקט. ביניהם עומדים מערכת ההפעלה, התצורה של הלקוח ומה שהשירות הפרטי דורש מעצמו. השוואת נקודות האכיפה היא הדרך היחידה לענות על השאלה בלי לנחש.
התחברות אחת, כמה היקפים
אימות עונה מי התקבל. המסלול עונה אילו מנות רשאיות לצאת דרך המנהרה. הרשאה עונה איזה שירות יקבל את החיבור הנובע, ואף אחד מהשלושה אינו מחייב את הבא.
מנהרה ברמת המארח היא ברירת המחדל הנפוצה, והיא הופכת את הפער לברור. המסלול יושב בטבלה של הגרעין, ולכן כל תהליך שמשתמש בטבלה הזו יכול להגיע לרשת הפרטית, כולל תהליך שהופעל בידי משתמש שמעולם לא ראה את חלון ה-VPN. זה אינו פגם במנהרה; זו המשמעות של מסלול ברמת המערכת. השירות הפרטי עדיין יכול לסרב לחיבור, ולכן הנגישות וההרשאה זקוקות לתשובות נפרדות.
כתיבת ארבע השאלות לפני הבדיקה מונעת מהסקירה להתמוטט לאחת מהן.
היכן הגבול באמת נמצא
ארבע הסדרים מכסים את רוב המכונות: מנהרה ברמת המארח, חיבור ברמת המשתמש, רשימת יישומים מורשים ומרחב שמות רשת או מכונה וירטואלית נפרדים.
כל אחד מציב את נקודת האכיפה במקום אחר, וההבדלים חשובים מהתוויות. חיבור ברמת המשתמש נאכף בידי הרשאות הפרופיל ולא בידי מסך ההתחברות של שולחן העבודה. רשימת יישומים מורשים נאכפת בתוך הלקוח, שקובע מה יישא. מרחב שמות או מכונה וירטואלית אוכפים בגבול הממשק, ולכן תהליך בפנים אינו יכול לראות כלל את המסלול של המארח. מספר מסכי ההתחברות במכונה אינו אומר דבר על אף אחד מהם.
| Arrangement | Enforced by | Who can use the path |
|---|---|---|
| Host-wide tunnel | The routing table | Any local process using that table |
| Per-user connection | Profile permission list | Only the listed accounts |
| Per-app allowlist | The VPN client itself | Only the selected applications |
| Namespace or VM | The interface boundary | Only processes inside it |
קריאת הטבלה שורה אחר שורה מראה שהשאלה האמיתית אינה אם קיימת בידוד, אלא היכן הוא מיושם.
השוו ארבע נקודות אכיפה
ב-Linux טבלת המסלולים היא הדבר הראשון שיש לבדוק, משום שמנהרה ברמת המארח מופיעה בה ומרחב שמות אינו מופיע. הרצת החיפוש כמשתמש השני היא הצעד שאנשים מדלגים עליו; התשובה שונה מזו שקיבלו בתור עצמם, וזה מסביר את הדוח.
שתי הבדיקות הבאות מסתכלות על מדיניות ולא על ניתוב. כלל חומת אש שמתאים ל-UID חל על תעבורה שנוצרת מקומית, ולכן הוא יכול להפריד בין שני משתמשים במארח אחד גם כששניהם חולקים את המסלול. פרופיל חיבור עם רשימת הרשאות מפורשת נאכף בידי מנהל הרשת בעת ההפעלה. אף אחת מהבדיקות אינה מחייבת לשנות את המנהרה, ולכן כדאי לעשות אותן לפני כל עיצוב מחדש.
ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuidאם החיפוש השני מציג את מסלול המנהרה, הגבול אינו במקום שהתכנון הניח.
כללי הפעלות במקביל הם בקרה נפרדת
שערים מגבילים לעתים קרובות כמה הפעלות חשבון אחד רשאי להחזיק, ומגבלה זו אינה קשורה למשתמשים מקומיים. היא מגבילה את החשבון, ולכן אדם שני שנכנס עם אותם פרטי גישה יכול לסיים את המנהרה של הראשון.
קראו את הכשל לפני שאתם מניחים בעיית בידוד מקומית. מגבלת הפעלות יוצרת ניתוק בשער, בעוד שבעיית היקף יוצרת מנהרה שעובדת ופשוט אינה נושאת את התעבורה של המשתמש האחר. שני הסימפטומים האלה מובילים לתיקונים שונים לגמרי. שמרו את הודעת הלקוח המדויקת, משום שהיא בדרך כלל מנקה את הכלל. בקשו מבעל הפרופיל את זרימת העבודה המאושרת במקום לעקוף את המגבלה.
מכונה וירטואלית אינה פוטרת אף אחד מאותו כלל, והיא מוסיפה עיצוב רשת ופרטי גישה משלה.
בדקו את ההקשר שמעניין אתכם
בדקו את המשתמש והיישום המיועדים, ואחר כך בדקו הקשר שאמור להידחות. סקירה שמוכיחה רק שהסיסמה המקורית עובדת בדקה אימות ולא דבר אחר.
sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'רשמו את נקודת האכיפה לצד כל תוצאה: טבלת המסלולים, כלל UID, הרשאת פרופיל או מדיניות ההפעלות של השער. הרישום הזה הופך את השינוי הבא לניתן לבדיקה. הוא גם מונע את פתיחת אותה שאלה מחדש בכל פעם שמישהו מבחין במסך התחברות שני. נגישות אינה הרשאה, ואף אחד מהשניים אינו בידוד.