מנהרה מפוצלת מוציאה את הדפדפן, לא את שאילתות ה-DNS שלו

הדפדפן הוצא מהמנהרה, עמוד ה-IP הציבורי מאשר שהתעבורה שלו יוצאת דרך חיבור הבית, והוויקי הפנימי עדיין לא נפתח. פתרון השמות הלך למקום אחר, והמקום האחר הזה הוא בדרך כלל הפותר שה-VPN הגדיר. נתיב הנתונים ונתיב הפותר הם החלטות נפרדות ברוב עיצובי המנהרה המפוצלת. בדקו איזה מהם הדפדפן השתמש בו בפועל לפני שאתם מכנים את ההוצאה מקולקלת.

נתיב הנתונים ונתיב הפותר נפרדים

הוצאה מסירה את מנות היישום מהמנהרה, וזו החלטת ניתוב וחומת אש בנתיב הנתונים. פתרון שמות הוא חיפוש אחר: תהליך שואל את הפותר של המערכת, והפותר הזה מחליט איזה שרת יקבל את השאלה.

שניהם יכולים להיות מכוונים ושונים. פריסה בעבודה עשויה להשאיר מרחבי שמות פנימיים אצל הפותר הארגוני ובמקביל לשלוח גלישה ציבורית נבחרת מחוץ למנהרה, דווקא מפני ששמות פנימיים אינם נפתרים בשום מקום אחר. המקרה המבלבל הוא ההפוך: אתר ציבורי נכשל כי הדפדפן מעולם לא שאל את הפותר שהפריסה ציפתה לו. רשמו את המסלול ואת הפותר בנפרד, וחצי מהוויכוחים נעלמים.

מצאו איזה תהליך שואל את השאלה

דפדפן יכול להשתמש בפותר של המערכת, בשירות ה-DNS המוצפן שלו, או בפותר שמערכת ההפעלה מקצה לכל רשת. הראשון פועל לפי מדיניות הפלטפורמה, השני עוקף את המדיניות הזו לגמרי, והשלישי תלוי לאיזה קישור מנותב השאילתה.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

קראו את התצורה התקפה לפני הבדיקה: אילו קישורים נושאים שרתי DNS, אילו מרחבי שמות הם תובעים, והאם מדיניות לפי שם עוקפת את ברירת המחדל. בלינוקס DNS מפוצל משתמש בתחומי ניתוב; בווינדוס טבלת מדיניות פתרון השמות עושה את אותו תפקיד עבור מרחבי שמות. אף אחד מהם אינו נראה מעמוד בדיקת דליפה.

החליטו איזה פותר רואה איזה שם

כתבו את המיפוי המיועד לפני שמשנים משהו: שמות פנימיים לפותר הארגוני, שמות ציבוריים לשירות שהמדיניות מתירה, וחריגים עם אחראי. בלי הרשימה הזו, כל תווית בבדיקת הדליפה הופכת לוויכוח מדיניות שאיש אינו יכול להכריע.

אחר כך בדקו את ההגדרה של הדפדפן עצמו, מפני ש-DNS מוצפן בדפדפן מיושם לפני שמערכת ההפעלה מקבלת את השאילתה. משתמש שהפעיל אותו כדי לעקוף פורטל שבייה שינה בשקט את הפותר שהפריסה בחרה. זו החלטת תצורה ולא דליפה, והיא ראויה להחלטה ולא לרשימת חסימה.

אל תשכתבו כל שדה DNS כדי שתווית בדיקה אחת תהפוך לירוקה. התווית מתארת שאילתה אחת מתהליך אחד ברגע אחד.

אמתו שאילתה וחיבור בנפרד

בדקו את שני הנתיבים בנפרד. בדיקת החיבור מציגה את נתיב הנתונים, ובדיקת הפותר מציגה מי קיבל את השם.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

שאלו גם את הפותר במפורש, כדי שכשל יוחס לשרת ולא לנתיב. אחר כך הפעילו מחדש את הדפדפן וחזרו על הבדיקה, מפני שיישומים שומרים תשובות שליליות במטמון וכשל ישן נראה מתמשך.

לאחר שינוי מאושר, רשמו את נתיב הנתונים ואת המקבל של הפותר כשני קווים נפרדים עם התאריך. אם ההתנהגות תחזור בחיבור הבא, הפרופיל שמספק אותה הוא מה שצריך לתקן, לא הדפדפן.