מנהרה מפוצלת: מדוע קישור נפתח מחוץ ל-VPN שהגדרתם
הניתוב עוקב אחר התהליך שפותח את השקע, לא אחר האפליקציה שהציגה לכם את הקישור. הוכיחו איזו תוכנית מתחברת לפני שתרחיבו את החריגים.
העברת אפליקציה דרך מנהרה אינה מעבירה את הניתוב שלה לכל מה שהאפליקציה מפעילה, גם אם הממשק מרמז אחרת. קישור מוסר בקשה לתוכנית אחרת, אותה תוכנית פותחת שקע משלה, והפלטפורמה מחילה את הכללים על התהליך החדש ולא על זה שהציג את הטקסט. אותו תהליך שני הוא מה שמדיניות המנהרה רואה באמת, והוא אינו זה שהגדרתם.
אפליקציה שנכללת יכולה אפוא לפתוח דפדפן שנמצא מחוץ למנהרה. דפדפן שהוחרג יכול להחזיר עבודה לאפליקציה שנמצאת בתוכו. שני הכיוונים של ההפתעה הזאת הם התנהגות רגילה.
החלק בתהליך העבודה שאיש לא הגדיר
מדיניות לפי אפליקציה נכתבת מול זהות של קובץ הרצה או חבילה, וכל חיבור מוערך ברגע יצירתו. הדפדפן, מציג המסמכים, נגן המדיה וגיליון השיתוף של המערכת נושאים כל אחד זהות משלו, וכל אחד מקבל את פסק הדין שלו. קישור עמוק נושא נתונים, לא מדיניות.
לכן התצפית נראית שרירותית: אותה לחיצה מנותבת בשתי דרכים לפי איזה מסדר עונה לה. לקוח דואר בתוך המנהרה פותח קישור בדפדפן שחי מחוץ למנהרה, והדף נטען מכתובת הבית שלכם. דפדפן מחוץ למנהרה פותח מסמך במציג שחי בתוכו, והקובץ מגיע דרך היציאה. אף אחד משני התוצאות אינו תקלה בלקוח.
מסדר שכבר פועל מחמיר את המצב. אם הדפדפן כבר פתוח, הקישור הופך להודעה לתהליך קיים, ואותו תהליך שומר על הניתוב שהיה לו בהפעלה. סגירה ופתיחה מחדש של המסדר משנה את התוצאה, ולכן הבעיה לעולם אינה משוחזרת לפי דרישה.
| Platform | Policy object | What it is evaluated against |
|---|---|---|
| Android | Per-app VPN allowlist | Package name of the process opening the socket |
| Windows | Application traffic filters | Application path in the filter rule |
| Linux | UID or cgroup routing rules | Owner of the socket, which can be a different program |
איזה תהליך באמת יצר את החיבור
מדדו את הצד המקבל במקום לנמק עליו. השאירו את המנהרה פעילה, לחצו על קישור בלתי מזיק והסתכלו על השקעים שהתוכנית החדשה מחזיקה.
ss -tnp state established '( dport = :443 )' Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess
הפקודה הראשונה משמיעה את שם התהליך שמאחורי כל שקע מבוסס בלינוקס, והשנייה עושה אותו דבר בווינדוס בפתרון מזהה התהליך המחזיק בו. השוו את שם התהליך לשמות שבמדיניות שלכם. אם השם הוא הדפדפן והדפדפן הוחרג, הלחיצה יצאה מהמנהרה לפי התכנון ולא מחמת תקלה. התאמת כלל מדיניות לשקע חי היא כל השיטה.
חזרו על הבדיקה כשהמסדר כבר פועל, ואחר כך כשהוא סגור. שתי התוצאות יכולות להיות שונות, וההבדל הזה מסביר את רוב הדיווחים המזדמנים על קישורים שבורחים ממנהרה.
כיסוי הוא תכונה של תהליך העבודה
אם משימה צריכה להישאר במנהרה מתחילתה ועד סופה, כל רכיב שהיא יכולה להגיע אליו צריך להיות בתוך המדיניות: המפעיל, המסדר, המציג וכל מתווך שהפלטפורמה מכניסה ביניהם. כיסוי רחב יותר הוא לעתים קרובות התשובה הכנה, והוא זול יותר מאשר ביקורת של כל יעד שיתוף.
החרגת מתווך מערכת כדי לתקן אפליקציה אחת היא טעות נפוצה. מתווכים משותפים, ולכן ההחרגה עוקבת אחרי כל אפליקציה אחרת שמשתמשת באותו נתיב, בדרך כלל בלי שאיש שם לב עד שדוח מגיע שבועות לאחר מכן. קראו מה עוד תלוי ברכיב לפני שאתם מחריגים אותו.
שמרו על הפרדה בין זהות לניתוב. קישור יכול לשאת אסימון הפעלה או מזהה חשבון ללא קשר לאיזו יציאה מקבלת את הבקשה. לחיצה מנותבת כהלכה עדיין יכולה לספר ליעד בדיוק מי עקב אחריה.
תעדו את תהליך העבודה, לא את תיבת הסימון הראשונה. כשמשימה משתרעת על ארבע תוכניות, התרשים עם ארבע תוכניות הוא זה שמנבא לאן ילך התעבורה, והגדרת אפליקציה אחת היא רק שורה אחת בו.