גיבוי ה-DNS של ה-VPN שלך: לאן השאילתה באמת הולכת

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

גיבוי הוא מדיניות, לא התנהגות אחת

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

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

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

מי מקבל את השאילתה לאחר המעבר

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

שמות פנימיים הופכים את ההבחנה למוחשית. resolver ציבורי בדרך כלל אינו יכול לענות על שם split-horizon, ולכן השאילתה נכשלת בעוד השם כבר נחשף לצד שלא היה אמור לראות אותו. לכן זמינות ופרטיות הולכות כאן יחד ולא מתחלפות זו בזו.

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

בדקו את המסלול ואת הנמען יחד

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

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

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

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

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

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

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

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