לאן הולך ה-DNS כשמשלבים Tor ו-VPN

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

תנו שם לכל החלפה לפני שאתם קוראים לזה דליפה

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

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

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

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

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

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

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

הדפדפן ושאר המכונה שונים

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

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

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

בדקו כל תוכנית, ואז השוו לכוונה

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

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

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

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