איזו כתובת מקור רואה STUN עם VPN בנתב?
המסלול, בחירת המקור והתרגום קובעים את הכתובת שהמשקף מדווח. שלוש עובדות לרשום, ואז שאילתה אחת כדי לאשר איזה מסלול מנצח.
השאלה נשמעת כמו בדיקה אחת ולמעשה מדובר בשלוש החלטות. באיזה מסלול ה-binding request יוצא, איזה מקור הגרעין בוחר למסלול הזה, והאם משהו בדרך כותב מחדש את המקור הזה. שנו כל אחד מהם והכתובת ששרת STUN מדווח משתנה יחד איתו. לכן הקביעה שה-VPN יושב על הנתב כמעט לא אומרת דבר בפני עצמה.
ההחלטה נשענת על שלוש עובדות
ראשית המסלול: כללי המדיניות וטבלת הניתוב קובעים אם הבקשה יוצאת דרך המנהרה או דרך ה-WAN הרגיל, ויעד מוחרג בוחר במסלול השני גם כשהמנהרה פעילה. שנית המקור: הגרעין בוחר מקור למסלול הנבחר, ובחירה זו תלויה במקור המועדף של המסלול ובכל כלל שהתאים. שלישית התרגום: NAT בדרך מחליף את המקור שנבחר. הכתובת המשתקפת היא המכפלה של כל השלושה, לא תכונה של המנהרה.
שנו אחד מהשלושה והתשובה משתנה, בעוד כל רכיב עדיין נראה תקין ביומן שלו. זו הסיבה הרגילה לכך שהאבחון הזה נתקע.
רשמו את שלוש העובדות עבור הזרימה שאתם בודקים לפני שמתחילים. ממשק, מסלול וכלל תרגום מספיקים כדי לחזות את התוצאה, ודווקא החיזוי הוא שהופך הפתעה למאלפת. אם אינכם מצליחים למלא אחד מהשלושה, הפער הזה הוא הממצא האמיתי.
עקבו אחרי binding request אחד לאורך המסלול
binding request של STUN מבקש משרת לדווח את כתובת התובלה של המקור שנצפתה. התשובה מתארת את המסלול שהבקשה עברה, ולא מלאי של ממשקים במחשב הלקוח. שתי בקשות בשני מסלולים ידווחו ביושר שתי כתובות שונות.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
קראו את הטבלה כקבוצת תנאים, לא כתפריט של ספקים. השורה האמצעית דורשת שהמשקף הפרטי יהיה נגיש תחת הניתוב ומדיניות העמיתים של המנהרה עצמה; זו עובדת תצורה שאפשר לאמת, ולא משהו שרמת חשבון מרמזת עליו. השורה התחתונה היא בדרך כלל זו שחשובה למדיניות, מפני שהתעבורה הזו הייתה אמורה להישאר בתוך המנהרה. בין השתיים נמצא המקרה הרגיל, שבו היציאה מתרגמת והמשקף רואה רק את היציאה.
מועמדי מארח ומועמדים רפלקסיביים של שרת מגיעים ממנגנונים שונים, ולכן רשימת מועמדים אינה אומרת באיזה מסלול המדיה השתמשה בפועל. קראו את הזוג הנבחר, לא את יומן האיסוף, כשאתם רוצים לדעת לאן הלכה הסשן.
מה כתובת המנהרה של הנתב אינה
כתובת מנהרה שהוקצתה לנתב שייכת לממשק בנתב. לדפדפן במארח LAN יש כתובות ממשק משלו ואין לו מבט ישיר על ממשק המנהרה של הנתב. התייחסות לשניים כאל ניתנים להחלפה מייצרת תשובות שגויות ובטוחות לגבי מה שדף אינטרנט יכול ללמוד.
העברה היא מה שמחבר ביניהם. הבקשה חוצה את הנתב כתעבורה מנותבת, והמקור שלה הוא מה שהניתוב והתרגום יצרו.
אם מסלול המנהרה משמר את מקור ה-LAN, משקף פרטי יכול ללמוד את כתובת ה-LAN הזו, וזהו גילוי אמיתי ושונה מכתובת המנהרה. אם המסלול מתרגם לכתובת המנהרה, המשקף לומד במקום זאת את כתובת המנהרה. שתי התוצאות עולות בקנה אחד עם אותו דפדפן באותו מארח, ולכן יש לקשור תצפית לזרימה מסוימת. שאלו את הגרעין באיזה מקור ישתמש לפני שאתם מאשימים את היישום.
גילוי מול עקיפה: שני ממצאים, שני תיקונים
כתובת מנהרה משתקפת מגלה מזהה פנימי במסלול שהתרתם. בקשה ישירה דרך ה-WAN עוקפת מסלול שרציתם לדרוש. הראשון הוא שאלת מידע, השני שאלת אכיפה, והם מתוקנים במקומות שונים. איחודם למילה אחת מייצר תיקון שלא מטפל באף אחד מהם.
WebRTC הופך זאת לגלוי יותר בלי לעשות אותו שגוי, מפני שאיסוף מועמד אינו זהה לבחירתו.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showהריצו את שאילתת המסלול לכל כתובת משקף שאתם מתירים, עם המקור שאתם מצפים שהזרימה הזו תישא, ואז הריצו אותה שוב עבור הטווחים המוחרגים כדי לראות מה בוחרת החלופה. השוו את שתי התשובות למדיניות שרשמתם. כשהן נבדלות באופן שלא התכוונתם, מצאתם את נקודת התיקון בלי בכלל לפרש את רשימת המועמדים של הדפדפן.