מה שהרשת המקומית עדיין רואה דרך ה-VPN שלך

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

טענה ראשונה: אף אחד לא יכול לקרוא את התעבורה

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

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

ב-macOS הצינור הזה מדפיס שורת נושא אחת לכל אישור בצרור המפתחות של המכונה, בלי לפתוח חלון, וב-Windows certutil -store Root מפרט את אותו מאגר ש-certlm.msc מציג באופן גרפי. שורש השייך לבית ספר, למעסיק או למוצר אבטחת רשת הוא הרשומה שכדאי לחפש. מציאה של אחד מוכיחה רק שיירוט אפשרי, לא שהוא מתרחש.

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

טענה שנייה: אף אחד לא רואה לאן אתם הולכים

היעד הוא הטענה הקשה יותר, כי שתי חשיפות מתרחשות לפני שדף נטען. שאילתה הולכת לפותר שהמערכת מוגדרת להשתמש בו, והתשובה גלויה לרשת שנושאת אותה. אחר כך לחיצת היד של TLS נושאת את שם השרת המבוקש בגלוי, אלא אם Encrypted Client Hello נתמך בשני הקצוות. אף אחת משתי החשיפות אינה כוללת פענוח, ולכן למנהרה אין השפעה על אף אחת מהן.

resolvectl status | grep -A2 "Link"
nslookup example.com

איזה פותר באמת בשימוש הוא שקובע את החשיפה, ואפשר למדוד זאת במקום להתווכח. ב-Linux resolvectl status מדפיס את שרתי ה-DNS לכל קישור, והפלט שלו אומר לכם אם הפותר של האתר או זה שנדחף הוא שעונה. Windows עונה לאותה שאלה עם nslookup example.com, שהבלוק הראשון בפלט שלו הוא שרת ה-DNS שענה.

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

טענה שלישית: אף אחד לא יודע שהתחברתם

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

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

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

החליטו איזו טענה דרושה לכם

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

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