חיבור ו-DNS
בדיקת דליפת WebRTC
בדקו את הכתובות שזוהו באמצעות תכונות השיחה של הדפדפן ולמדו כיצד לקרוא את התוצאה עם VPN או בלעדיו.
תצורת הבדיקה
תצורת TURN אופציונלית
ממסר TURN יכול להראות שהדפדפן יכול להשתמש במועמד מסוג relay. פרטי ההתחברות שהוזנו מאמתים מול TURN; כלי זה אינו שומר אותם או שולח אותם לשרת שלנו.
פרטיות: שירותי STUN/TURN וההחזרה רואים בהכרח את כתובת המקור המשמשת להגעה אליהם. המועמדים והדוח נשארים בזיכרון לשונית זו אלא אם מייצאים אותם.
מוכן. הבדיקה אינה ניגשת למצלמה או למיקרופון.
ממצאים
כתובות יציאה שהדפדפן רואה
| בדיקה | משפחה | כתובת | מצב | משך |
|---|
מועמדי WebRTC ICE
| שלב | סוג | כתובת | יציאה | היקף | תעבורה | כתובת קשורה |
|---|
לא היה מועמד ICE גלוי לסקריפט.
יומן טכני
| שלב | מצב | פרט | משך |
|---|
ההיסטוריה של לשונית זו
בדקו אם כתובות משתנות בין הרצות. ההיסטוריה אינה נשמרת לאחר סגירת הלשונית.
| שעה | תוצאה | כתובות גלויות | מועמדים |
|---|
דוח JSON מוצג מקומית
איך לפרש את התוצאה?
hostמזהה ממשק מקומי, המוסתר לרוב מאחורי שם mDNS המסתיים ב-.local.srflxהיא כתובת משתקפת שנלמדה משרת STUN; השוו אותה ליציאת ה-VPN הצפויה.relayשייכת לממסר TURN ואינה מייצגת ישירות את כתובת הגישה שלכם.- היעדר מועמד ציבורי עשוי לשקף הגנת דפדפן, חסימת רשת או חריגת זמן. לבדו הוא אינו מוכיח היעדר דליפה.
השוואה לפני ואחרי
הריצו את אותה בדיקה באותו מכשיר ושמרו תוצאת בסיס. הפעילו את ה-VPN או שנו הגדרה רלוונטית אחת, הריצו שוב באותם תנאים ושמרו את התוצאה הבאה.
שמרו תוצאה מלפני ותוצאה מאחרי כדי להשוות ביניהן.
מה הבדיקה הזאת מגלה
WebRTC עשוי לבחור מסלולי רשת באופן שונה מבקשות אינטרנט רגילות. הבדיקה עוזרת לבחון את המסלולים האלה בלי להתחיל שיחה. כתובת פרטית או שם mDNS שונים מכתובת ציבורית של ספק אינטרנט, וכתובת ממסר TURN שייכת לממסר ואינה מזהה ישירות את החיבור שלכם.
איך לבצע את הבדיקה
- השאירו את מצב החיבור קבוע והזינו את כתובת ה-VPN הצפויה אם יש לכם כתובת אמינה כזאת.
- הפעילו איסוף מועמדים; אפשר לכלול בקשות החזרת IP של הדפדפן כדי להשוות את מסלול HTTPS.
- קראו את סוג המועמד, משפחת הכתובות, ההיקף ומצב ההשוואה, לרבות איסופים שלא הושלמו.
איך המדידה פועלת
הדפדפן אוסף מועמדי Interactive Connectivity Establishment, או ICE, תחילה ללא STUN/TURN ולאחר מכן עם השרתים שהוגדרו. הסוגים כוללים מועמדי מארח, מועמדים המשתקפים בשרת, מועמדים המשתקפים בעמית ומועמדי ממסר.
ערוץ נתונים מתחיל את האיסוף ללא הרשאה למצלמה או למיקרופון. המועמדים נשארים בדפדפן; שירותי STUN, TURN ושירותי ההחזרה האופציונליים רואים את כתובות המקור המשמשות לפנייה אליהם.
הבנת התוצאות
- הכתובת הציבורית תואמת למסלול הצפוי
- מועמד שנצפה תואם את כתובת ה-VPN שסופקה או תוצאת החזרה שמישה וברת השוואה. הדבר תומך בעקביות לגבי אותה תצפית.
- כתובת ציבורית לא צפויה
- ייתכן שהמועמד משתמש במסלול אחר. בדקו את המשפחה והסוג שלו לפני שתתייחסו להבדל כאל חשיפה אפשרית מחוץ ל-VPN המיועד.
- ראיות פרטיות, ממסריות או חלקיות
- מועמדים פרטיים ומועמדי mDNS דורשים פירוש שונה; כתובות ממסר מתארות את TURN. איסוף שנכשל או ריק משאיר את התוצאה לא חד-משמעית גם אם החזרת HTTPS מצליחה.
השוואה לפני ואחרי
- שמרו את סוגי המועמדים, המשפחות, הגדרות STUN/TURN והכתובת הצפויה של אותו דפדפן.
- שנו הגדרת ניתוב VPN או WebRTC רלוונטית אחת וחזרו על אותו איסוף.
- השוו מועמדים ציבוריים לפי משפחה וסוג. עדכנו את היציאה הצפויה רק כשידוע לכם באופן עצמאי שהיא השתנתה.
מגבלות הבדיקה
- היעדר מועמד ציבורי אינו מוכיח שכל חיבור WebRTC נמנע ממסלולים לא רצויים.
- ללא כתובת צפויה או החזרה רלוונטית מוצלחת אי אפשר לכנות מועמד ציבורי דליפה באופן אוטומטי.
מה לשנות, אם צריך
- מועמד ציבורי משתמש במסלול ספק אינטרנט לא צפוי
- בדקו ניתוב יישומים ואת אופן הטיפול של ה-VPN במשפחת הכתובות הזו, ואז הריצו שוב עם אותם שרתים.
- האיסוף לא הושלם
- בדקו מדיניות דפדפן, חומת אש וזמינות שרתים לפני הערכת המסלול; שמרו על מצב לא חד-משמעי.
שאלות נפוצות
האם זה מפעיל את המיקרופון שלי?
לא. איסוף המועמדים משתמש בערוץ נתונים ואינו מבקש גישה למצלמה או למיקרופון.
האם כל כתובת שונה היא דליפה?
לא. שרתי ממסר, משפחות כתובות ומסלולים מותרים שונים יכולים ליצור הבדלים תקינים.