מה רשימת מועמדים של WebRTC מגלה על ה-VPN שלך
מועמד מארח, מחזרי-שרת או ממסר אומר מאיפה הגיעה כתובת. רק זוג ה-ICE שנבחר אומר באיזה נתיב המדיה עברה בפועל.
כאשר דף בדיקה של WebRTC מדפיס 172.20.4.15, הוא למד שקיים ממשק מקומי באותה רשת. זו חשיפה אמיתית, וזו אינה אותה ממצא כמו «המדיה יצאה דרך יציאת ה-VPN». גילוי מועמדים וניתוב מנות הם מנגנונים נפרדים, ורוב דוחות הדליפה ממזגים אותם לפסק דין אחד. איזה משני אלה אתה רואה הוא שקובע את התיקון.
האיסוף מתרחש לפני שנשלח משהו
הדפדפן מונה ממשקים מקומיים, שולח בקשת כריכה לשרת STUN ומבקש משרת TURN הקצאה, ואז כותב את התוצאות בתיאור הסשן כשורות מועמדים. כל זה מסתיים בלי שיחה, בלי מדיה ובלי עמית. רשימת מועמדים היא אפוא תיעוד של גילוי, לא של העברה.
דפדפנים מודרניים עשויים להחליף את הכתובת המילולית של מועמד מארח בשם mDNS .local, כך שהדף אינו יכול לקרוא את כתובת ה-IP הפרטית. הרשת המקומית עדיין רואה את שאילתות השידור המרובות שמפענחות את השם הזה, כלומר הכתובת מוסתרת מהאפליקציה ולא מוסרת מהרשת.
גם הסדר חשוב: טעינת דף חדשה אוספת קבוצה חדשה, עם הקצאת TURN אחרת ואולי מיפוי מחזרי אחר. שתי ריצות שאינן מסכימות אינן בהכרח שתי תצורות שונות.
שלושה סוגי מועמדים, שלושה סוגי ראיות
כל שורה נובעת מתצפית אחרת. כל סוג עונה על שאלה אחרת, והטבלה מפרידה ביניהם לפי מה שהם יכולים ומה שאינם יכולים לקבוע.
| Candidate | Derived from | What it establishes | What it cannot establish |
|---|---|---|---|
| Host | An interface on the device | A local address exists in that network | That the peer can reach it |
| Server-reflexive | A STUN binding response | How a NAT mapped this source | Which exit the media will use |
| Peer-reflexive | A connectivity check that arrived | An address seen by the far side | That it was ever advertised |
| Relay | A TURN allocation | The relay server accepted the session | That the relay carries the call |
מועמד ממסר נחשב בטעות לכתובת האינטרנט של המשתמש. הוא שייך לשרת TURN, ונוכחותו מראה שממסר היה זמין, לא שהדפדפן בחר בו. אותה טעות פועלת בכיוון ההפוך עם מועמדי מארח, שם שם mDNS מסתיר את הכתובת מהדף בעוד הרשת ממשיכה לשאת את השאילתות. קרא את הסוג לפני שאתה קורא את הערך.
הזוג שנבחר עונה על שאלת הניתוב
ICE מצמיד כל מועמד מקומי לכל מועמד מרוחק, מריץ בדיקות קישוריות על כל זוג וממנה מנצח. אותו זוג ממונה, הנראה באבחון של הדפדפן עצמו, נושא את המדיה. כל השאר ברשימה הוא אפשרות שהפסידה.
המנצח אומר לך את צורת הנתיב. ממסר לממסר עובר דרך שרת TURN, זוג מארח נשאר ברשת המקומית, וזוג מחזרי-שרת עובר ישירות דרך NAT. זו העובדה שבדיקת VPN זקוקה לה, והיא עובדה שונה מרשימת הכתובות. שתי שיחות עם רשימות מועמדים זהות יכולות לבחור זוגות שונים.
מועמדים שלא נבחרו עדיין נאספו, ואיסוף הוא תעבורת רשת שיוצאת מהמכונה. שיחה שבסופו של דבר השתמשה בממסר אינה אומרת שלא נחשף דבר בזמן בניית הרשימה.
הבקרות מתאימות למטרות, לא לציון דליפה
מפרט הטיפול ב-IP של WebRTC מתאר כמה מדיניות: להשתמש רק בממשק שנושא את הנתיב המוגדר כברירת מחדל, להשתמש בכל הממשקים, ולכבות UDP ללא פרוקסי כך שהתעבורה חייבת לעבור דרך ממסר או פרוקסי. כל אחת מחליפה קישוריות והשהיה בסוג אחר של חשיפה. איזו מהן דפדפן מיישם, ובאיזה שם, משתנה לפי פלטפורמה וגרסה.
בחר את המדיניות לפי המטרה. הסתרת כתובות מקומיות מדף היא מטרה אחת; מניעת תעבורה ישירה בין עמיתים היא מטרה שנייה; החזקת כל מנה בתוך המנהרה היא מטרה שלישית. הראשונה עוסקת בעיקר במה שהאפליקציה לומדת, השנייה באיזה נתיב מותר, והשלישית חייבת להיאכף גם בגבול הפלטפורמה או ה-VPN.
איזו בקרה שתבחר, אמת את שני החצאים: הרץ את מבחן האיסוף ורשום את סוגי המועמדים, ואז בדוק את הזוג שנבחר במהלך סשן אמיתי. רשימת כתובות נקייה עם נתיב מדיה ישיר היא עדיין נתיב שלא התכוונת אליו.