האם ה-DNS של ה-VPN שלכם באמת משמש? תפסו פורט 53 ותראו

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

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

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

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

בדקו מה הממשק באמת מחזיק

ב-Linux הפותר של המערכת יכול להיות הקובץ הפשוט, NetworkManager או systemd-resolved, ומי מהם מחזיק בו קובע היכן נוחת שרת שנדחף. תהליך OpenVPN משורת הפקודה אינו מעדכן את פותר המערכת בעצמו, ולכן האינטגרציה המתועדת היא סקריפט up/down או מנהל חיבורים שכבר יודע ליישם את ההגדרות. הרצת שניהם היא דרך יעילה ליצור מירוץ.

resolvectl status
cat /etc/resolv.conf

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

עקבו אחרי שאילתה אחת מחוץ למכונה

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

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

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

חומת האש שמקבלת רק את ה-DNS של עצמה

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

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

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

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

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

למה דף דליפה מוכיח פחות ממה שנדמה

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

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