למה הוטספוט מפנה מחדש DNS לפני שה-VPN מתחבר?
הוטספוט כותב מחדש שאילתות ברשת שלו, וכתובת קצה בצורת שם מארח נפתרת לפני שקיימת מנהרה. עקבו אחרי איזה פותר ענה לכל שאילתה.
הצטרפות לרשת של בית מלון מציבה בפניכם שתי החלטות DNS בזמנים שונים: השאילתות שהמכשיר מבצע בזמן הכניסה, והשאילתות שמבוצעות לאחר שהמנהרה עולה. הוטספוט יכול להשפיע על הראשונות דרך הרשת שהוא שולט בה. השניות תלויות במדיניות של הלקוח עצמו, וזה עניין נפרד לבדיקה.
עברו על החיבור לפי הסדר, מהחכירה הראשונה של DHCP ועד לשאילתה שפתרה שם פרטי. אז שני כשלים שנראים זהים בכרטיס תמיכה נפרדים בבירור: האחד קרה לפני שהמנהרה הייתה קיימת, והשני קרה בתוכה.
מה ההוטספוט יכול לגעת בו ומה לא
רשת הגישה מחלקת כתובת פותר ב-DHCP, ויכולה ליירט את פורט 53 אל אותה כתובת. זה מספיק כדי לענות לכל שאילתה לא מוגנת בכתובת פורטל או בדף חסימה. זה מספיק גם כדי לשבור לקוח VPN שכתובת הקצה שלו כתובה כשם מארח.
מה שההוטספוט לא יכול לעשות הוא לקרוא או לכתוב מחדש שאילתה ברגע שהיא נוסעת בתוך מנהרה מבוססת, בהנחה שהמנהרה באמת נושאת אותה. יירוט תלוי בראיית השאלה בטקסט גלוי.
השאילתות יוצאות מהמנהרה בכל זאת מסיבות שאינן קשורות להוטספוט: הגדרת DNS מאובטח בדפדפן, כלל split-DNS שמשאיר סיומת ארגונית אצל הפותר המקומי, או לקוח שהוגדר להוציא DNS מהמנהרה. כל אחת היא בחירה בצד הלקוח, וכל אחת נראית כמו הפרעה של הוטספוט במבט מבחוץ.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
שאילתת האתחול מתרחשת לפני שהמנהרה קיימת
לקוח שמקבל שם מארח חייב לפתור אותו קודם, וברגע הזה אף מנהרה לא מגנה על השאילתה. אם ההוטספוט עונה בכתובת פורטל, המשא ומתן נכשל או נתקע. אם הוא עונה בכלום, הלקוח מדווח על שגיאת שם והמנהרה לא מתחילה לעולם. כל אחת משתי התוצאות מסבירה יומן מנהרה ריק שנראה אחרת תמים.
מערכות הפעלה מריצות גם בדיקות קישוריות וגילוי פורטל משלהן, המתוארות ב-RFC 8910 וב-RFC 8952, והבקשות האלה יוצאות לפני שכל VPN עולה. לראות אותן ביומן פרוקסי זו התנהגות צפויה ולא הוכחה לדליפה.
התיקון המעשי הוא לתת ללקוח כתובת קצה שלא דורשת שאילתה. כשאי אפשר, סיימו קודם את הכניסה והתחברו אחר כך.
בררו איזה פותר ענה
שאלו את המערכת ולא את הדפדפן, והריצו את השאילתה פעמיים: פעם אחת דרך הפותר שהמכשיר משתמש בו כעת, ופעם אחת מול כתובת קבועה.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
תשובה מהפקודה הראשונה ששונה מהשלישית אומרת לכם שהפותר המקומי מחזיר משהו אחר, וזה בדיוק מה שעושה הוטספוט שמפנה מחדש. כשל מהשלישית לצד הצלחה מהראשונה מצביע על הפורטל: הפותר המקומי הגיש כתובת כניסה בזמן שפורט 53 היוצא נזרק. פסקי זמן בשניהם אומרים שהרשת משליכה DNS עד שהאימות יושלם.
חזרו על כך לאחר ההתחברות והשוו. תשובה שמורה במטמון שורדת את המעבר, לכן רוקנו את המטמון או שאלו שם חדש לתצפית השנייה.
השאירו את השאילתות המאוחרות במסלול שהתכוונתם אליו
פרופיל מנהרה מלאה שלוכד גם DNS הוא הסידור הפשוט ביותר: כל שאילתה מכל יישום הולכת לפותר שהמנהרה דוחפת, והרשת המקומית רואה רק תעבורה מוצפנת. הוכיחו זאת על ידי פתרון שם פנימי ושם ציבורי לאחר ההתחברות, ואז השוואת שתי התשובות למה שהפותר של המנהרה מחזיר לבדו.
split-DNS צריך רשימת דומיינים שנכתבה בכוונה: סיומות ארגוניות דרך המנהרה, כל השאר מקומית, ובלי חפיפה בין השניים.
DNS מאובטח בדפדפן נמצא מחוץ למדיניות הזו, לכן אם הוא חייב להיות כבוי כדי שהפרופיל יתנהג בצפוי, כבו אותו עבור הפרופיל הזה ולא עבור המכונה. עשו זאת בהגדרות הדפדפן, לא על ידי עריכת הפותר של המערכת, כדי שהשינוי ייראה בפעם הבאה. רשמו את התשובה, הפותר ושלב החיבור בשורה אחת לכל בדיקה. דוח שאומר ש-DNS נכשל ב-Wi-Fi של בית המלון מתאר תסמין עם לפחות שלושה גורמים שונים.