VPN מחובר אבל השמות נכשלים: איפה DNS באמת נשבר

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

מה חיפוש באמת צריך

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

הלקוח לומד את הפותר שלו מפרופיל ה-VPN, מ-DHCP על המנהרה או מהתצורה שלו עצמו, ואיזה מקור מנצח תלוי בפלטפורמה. ב-Windows, ipconfig /all מציג את שרתי ה-DNS לכל מתאם, כך שאתם רואים אם הערך שנדחף באמת הגיע. ערך שנדחף ומעולם לא הגיע למערכת ההפעלה הוא כשל שקט ונפוץ. קראו את הערך המוגדר לפני שנוגעים בפרופיל.

Linux ו-macOS עונים על אותה שאלה בפקודות שונות, והתשובה ראויה לאותה קריאה: resolvectl status ו scutil --dns שניהם מפרטים את השרתים לפי ממשק. השוו את הרשימה הזו לכתובת שהפרופיל טוען שהוא דוחף. אי-התאמה כאן מסבירה את כל מה שלמטה, אז יישבו אותה לפני שתבדקו שמות.

בדקו שם ציבורי אחד ושם פרטי אחד

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

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

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

nslookup example.com
nslookup host.corp.example 10.20.30.53

ודאו שהלקוח באמת מגיע לשרת הזה

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

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

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

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

זכרו שדפדפנים יכולים לעקוף את פותר המערכת

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

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

נקו את המטמון ובדקו שוב את המשימה האמיתית

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

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

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

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