למה תווית מדינה ב-DNS לא מוכיחה דליפת VPN
בדיקה ממפה כתובת למדינה; זה אומר מעט על המסלול. קראו את הפותר, את שרשרת ההעברה ואת המדיניות לפני שמשנים משהו.
כתובות פותרות שנראות זרות מופיעות כל הזמן בתוצאות בדיקות DNS, והמסקנה שאליה אנשים מגיעים תמיד אותה: השאילתות ודאי חמקו מהמנהרה. לפעמים זה קרה. לעיתים קרובות יותר הדוח מתאר איזה שירות רקורסיבי השיב ואיפה מסד נתונים חושב שהכתובת הזאת נמצאת, וזו אמירה על התשתית ולא על החבילות שלכם. כדי להפריד את התצפית מהמסקנה דרושים שלושה עובדות: מי השיב, איך עבר השם ואיזו מדיניות באמת הגדרתם.
קראו מה הבדיקה באמת צפתה בו
רוב דפי הבדיקה עובדים אותו דבר: הם מבקשים מהלקוח לפתור שם מארח ייחודי ואז בודקים איזה פותר הביא אותו, או שהם פשוט מחזירים את כתובת הפותר שהלקוח מדווח עליה. זה מזהה שירות רקורסיבי ואם השאילתה נשאה מידע על תת-רשת של הלקוח, גם מיקום רשת גס. זה לא מוכיח שהשאילתה עזבה את המכשיר מחוץ למנהרה, ובוודאי לא מוכיח שאותו מסלול שימש לכל שם. תצפית אחת של חיפוש אחד מוכללת לטענה על כל התעבורה.
בדיקה שמראה את כתובת הפותר שימושית יותר מתג מדינה, כי אפשר להשוות את הכתובת לרשימת הפותרים שהלקוח באמת קיבל.
anycast והעברה מסבירים את רוב ההפתעות
פותרים ציבוריים גדולים מכריזים על אותה כתובת מהרבה מקומות, והרשת מנתבת כל שאילתה לאתר הקרוב ביותר מבחינת ניתוב. אחר כך מסד נתונים גיאוגרפי ממפה את הכתובת למקום אחד, שעשוי להיות כתובת רישום תאגידית ביבשת אחרת או מרכז נתונים שאינו זה שהשיב. RFC 4786 עוסק בפרקטיקה התפעולית של שירותי anycast ובקושי לקשור כתובת כזאת למקום פיזי אחד. המפה היא פישוט של החלטת ניתוב, והיא מפשטת בכיוון שמייצר תוצאות מדאיגות.
ההעברה מוסיפה שכבה שנייה. פותר מקומי, נתב או פותר של ספק האינטרנט עשויים להעביר שאילתות לשירות שמעל, והשם שמופיע בבדיקה משקף את המפעיל האחרון בשרשרת ולא את הראשון. הרחבות תת-רשת של הלקוח יכולות להתאים תשובה מלמעלה לרשת שלכם ובו-זמנית לגרום למיקום המדווח להיראות כמו מקום שמעולם לא הייתם בו.
לכן פותר מוגדר יכול להיות נכון ובכל זאת להפיק תוצאה שנראית זרה, ופותר במדינה שלכם יכול להיות השגוי מפני שהוא שייך לצד שלא בחרתם.
מי קיבל את השם, ובאיזה מסלול
שתי שאלות עונות על החלק המעשי: באיזה שרת משתמש הלקוח, והאם מגיעים לשרת הזה דרך המנהרה. השוו את רשימת הפותרים לכתובת בתוצאת הבדיקה לפני שאתם מסיקים מסקנות על ניתוב, ואז בדקו שהשאילתה לכתובת הזאת יוצאת דרך ממשק המנהרה. אם שתי הכתובות שונות, הממצא המעניין הוא שמשהו שכתב מחדש או עקף את הפותר המיועד, וזה ראוי למבט קרוב יותר משם המדינה.
resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net
הפקודה הראשונה מראה איזה שרת השיב עבור שם, השנייה מראה את הרשימה המוגדרת ואת היקפה, והשלישית מדווחת על כתובת הפותר כפי ששירות ציבורי רואה אותה. כשכל השלוש מסכימים, המדיניות עושה את מה שהוגדרה לעשות, יהיה אשר יאמר תג המדינה.
השוו למדיניות שבחרתם
VPN שדוחף פותר, דפדפן שמוגדר להשתמש ב-DNS המוצפן שלו, ו מערכת הפעלה שמעדיפה את ההגדרות של ממשק אחד יכולים להיות נכונים בנפרד ובכל זאת לסתור זה את זה ביחד. דפדפנים מודרניים עשויים לשלוח שאילתות דרך תעבורה מוצפנת לספק שנבחר בדפדפן, מה שעוקף בכוונה את רשימת הפותרים של המערכת. זו אינה דליפה במובן של מנהרה שבורה; זו מדיניות שנבחרה במקום אחר, ומציאת המקום שבו נבחרה היא המשימה האמיתית.
מכשירי עבודה מוסיפים כללים לפי דומיין: שמות פנימיים חייבים ללכת לפותר של הארגון בעוד שכל השאר הולך לפי ברירת המחדל. החלפת הסדר הזה מפני שדף בדיקה הראה מדינה לא צפויה היא הדרך שבה שמות פנימיים מפסיקים להיפתר עבור צוות שלם.
שמרו על בדיקות צרות ובטוחות
שאילת שירות בדיקה ציבורי על שם מארח פנימי חושפת את השם בפני צד שאין לו עסק לראות אותו, והתשובה לא מספרת לכם דבר שקריאה מקומית של רשימת הפותרים לא הייתה מספרת.
השתמשו במקום זאת בשמות שחושפים תשתית, תעדו את כתובת הפותר, את ההיקף ואת הממשק שבו השתמשו, והשוו את התיעוד לכוונה המתועדת. תווית במפה היא הקשר לשיחה ולא תוצאת עבר או נכשל, והתייחסות אליה כאל פסק דין מייצרת שינויי תצורה במקום אבחון.