VPN מול ממסר TURN: מה באמת נושא שיחת WebRTC?
המנהרה משנה את הנתיב ש-ICE רואה; היא לעולם אינה מקצה ממסר ואינה מספקת איתות. השוו מה מספק יציאת VPN ומה מספק שרת TURN.
הדף נטען דרך ה-VPN, אך השיחה לעולם אינה מתחברת: שתי תקלות שונות באותה שורת כתובות. המנהרה שינתה את הנתיב שהדפדפן משתמש בו; היא לא הפכה לשירות איתות, לשרת STUN או לממסר, והיא אינה קובעת איזה זוג מועמדים ICE יבחר. דווקא הפרדת התפקיד של כל רכיב היא שהופכת „WebRTC חסום” מעורפל לתקלה מדויקת.
ארבעה תפקידים, והמנהרה נוגעת רק באחד מהם
היישום מחליף מידע סשן דרך איזו מערכת איתות, וזה התפקיד הראשון. ICE אוסף כתובות מועמדים ובודק זוגות עד שאחד עובד, וזה השני. STUN מאפשר לעמית ללמוד איך נראית התעבורה שלו מבחוץ, ו-TURN מקצה ממסר למקרים שבהם אין נתיב ישיר. ארבעת התפקידים האלה נבדלים זה מזה, ו-VPN משפיע על הכתובות ועל הסינון שהם פוגשים במקום לספק מי מהם.
לכן התחברות מוצלחת אינה אומרת דבר על נתיב המדיה. האיתות בדרך כלל נוסע על אותו HTTPS שהדף כבר משתמש בו, בפורט 443, בעוד המדיה עשויה לנסוע ב-UDP ליעד שונה לחלוטין.
כתובות פרטיות מחמירות את הבלבול. כתובת מנהרה מועילה לעמית רק כאשר יש לו נתיב מתוכנן חזרה אליה; היותה פרטית אינה הוכחה לנגישות הדדית, והדפדפנים אינם מתייחסים אליה כך כשהם פוסלים מועמדים שאי אפשר לבדוק. מועמד שנראה לך מקומי עשוי להיות בלתי ניתן לבדיקה מהצד השני. כדאי לשלול את הפער הזה לפני שאתם מסיקים שהמנהרה מפילה מדיה.
השוו יציאת VPN לממסר TURN
שניהם מעבירים מנות, ולכן מבלבלים ביניהם, וכדאי לקרוא את טבלת ההשוואה שלמעלה עמודה אחר עמודה ולא כרשימת תכונות. הקצאת ממסר היא אובייקט לכל סשן שנוצר בבקשה מאומתת; מנהרה היא נתיב. לאחד יש פרטי התחברות שפגים, ולשני יש כתובת עמית שהיא או נגישה או לא.
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
מספרי הפורטים הופכים את ההבדל למוחשי. TURN מאזין כברירת מחדל בפורט 3478 עבור UDP ו-TCP ובפורט 5349 עבור TLS, ורשת שמתירה 443 אך מפילה את הפורטים האלה תיכשל בשיחות ממוסרות בעוד הגלישה נמשכת כרגיל. שינוי הפורט של ה-VPN אינו מגדיר דבר מזה, כי הפורטים החשובים שייכים לשירות הממסר ולא למנהרה.
קראו את האבחון, ואז בדקו את השיחה
דפדפנים חושפים את המידע הדרוש בלי ללכוד מנות. פתחו את עמוד האבחון של WebRTC בדפדפן שלכם, בצעו את השיחה, וקראו את זוג המועמדים שנבחר ולא את הרשימה שנאספה: אילו סוגי מועמדים מקומיים ומרוחקים נבחרו, על איזה תעבורה ומשפחת כתובות, והאם הנתיב ישיר או ממוסר.
שני קראים כדאי להכיר מראש. אם הזוג שנבחר הוא מארח למארח בכתובות פרטיות, המדיה נשארת על נתיב שאפשר לנמק לגביו; אם הוא ממסר לממסר, השיחה צורכת קיבולת ממסר ותלויה בזמינות של אותו שירות. תקלה שנעצרת ב„בודק” בלי זוג שנבחר משמעה שהמועמדים נאספו אבל אף אחד מהם לא עבר את בדיקות הקישוריות.
לאחר מכן השוו את אותם שני קצוות באותה שיחה כשאתם משנים רק תנאי מאושר אחד, וקבלו את התוצאה על פי מדיה או נתונים דו-כיווניים ולא על פי מחוון „מחובר”. איסוף מועמדים מצליח בהרבה מקרים שלעולם אינם נושאים אפילו פריים שמע אחד. חזרו על השיחה בצד השני של השינוי ושמרו את שתי לכידות האבחון, כי השוואת שתי הרצות מלמדת יותר מקריאה של כל אחת לבדה. אותם קצוות, אותו קודק, משתנה אחד שהשתנה.
יישום שקובע במכוון את מדיניות תעבורת ה-ICE שלו ל-relay מבקש רק מועמדים של ממסר. ההגדרה הזאת אינה יוצרת ממסר ואינה מתקנת פרטי התחברות חסרים; היא הופכת את הדרישה למפורשת, וזה מועיל כשמישהו מאשים את ה-VPN במדיניות שהאתר בחר.
השאירו את טענת הפרטיות צרה כמו הראיות
חשיפת המועמדים תלויה במדיניות הדפדפן והיישום, לא רק במצב המנהרה, ומפרט ה-W3C לחיבור בין עמיתים מתייחס לטיפול ב-IP כעניין בפני עצמו. לכן VPN מחובר הוא בסיס גרוע להבטחה ששיחה חושפת רק כתובת אחת נבחרת. שני עמיתים מאחורי אותה מנהרה יכולים אף לבחור נתיב שלעולם אינו יוצא מהמארח, וזה גם שיפור פרטיות וגם מגבלת קישוריות בו-זמנית.
מה שאפשר לומר בדיוק הוא צר יותר ושימושי יותר: איזה זוג מועמדים נבחר, איזו תעבורה נשאה אותו, והאם הנתיב הזה נשאר בתוך המנהרה. רשמו את שלוש העובדות האלה לשיחה שעובדת ולשיחה שנכשלת, וההבדל בדרך כלל נוקב בשם הרכיב שצריך לתקן.
כשהקישוריות עובדת, הפרידו ביצועים מנגישות. אובדן, השהיה, תורים ו-MTU כולם נמצאים במורד הזרם של זוג מועמדים נכון, והתייחסות לשיחה מקוטעת כתקלת קישוריות מחזירה אתכם לרשימת המועמדים בלי סיבה.