האם ה-VPN שינה את ה-DNS שלי? השוו לפני ואחרי
פרופיל יכול להעביר את השאילתות שלכם בכוונה. השוו את מדיניות הפותר ואת התשובה בפועל לפני ואחרי התחברות VPN, תוך שמירה על משתנה אחד.
אתם מתחברים למנהרה, פותחים לוח בקרה פרטי, והשם נפתר לכתובת שמעולם לא ראיתם. או שקורה ההפך: הדפדפן ממשיך לעבוד בעוד כלי שורת פקודה מפסיק לפתע לפתור דבר. שתי התוצאות באות מאותו שינוי, ואנשים בדרך כלל מסבירים אותו במשפט אחד על ה-VPN ש"משתמש ב-DNS משלו", וזה לא מדויק מספיק כדי לאתר תקלות או לאמת. בשני משפטים חבויות שתי שאלות: אילו שאילתות אמור הפרופיל הזה לקחת על עצמו, והאם המחשב שלכם באמת שלח אותן לפותר שקיבל? להחזיק אותן בנפרד זו כל השיטה, כי בדיקה שמערבבת ביניהן מפיקה תשובה שגויה ובטוחה בעצמה בשני הכיוונים.
למה פרופיל בכלל מספק פותר
בתוך מנהרה, שמות שמאחורי הקצה המרוחק נפתרים בדרך כלל לכתובות שקיימות רק באותה רשת. לאזור פרטי כמו corp.internal אין האצלה ציבורית, ולכן הפותר שעונה עליו חייב להיות נגיש מתוך המנהרה. אותו מנגנון משרת מטרה שנייה: כששאילתות היו יוצאות אחרת דרך ספק האינטרנט שלכם, פותר בצד המרוחק מחזיק את השאילתה בתוך הנתיב המוצפן. לכן כתובת שרת ה-DNS מגיעה כחלק ממדיניות החיבור ולא כהגדרה גלובלית שבחרתם פעם אחת עבור המחשב.
הכתובת לבדה לא מכריעה דבר. פותר יכול לענות רק אם קיים אליו נתיב, והכשל הנפוץ ביותר הוא פותר שנגיש רק כל עוד המנהרה פעילה. כשהמנהרה נופלת והמדיניות נשארת, השאילתות הולכות לכתובת בלי נתיב, והתסמין הוא פסק זמן ולא שגיאה נקייה. ההבדל הזה חשוב כשאתם קוראים את תוצאת הבדיקה הבאה, כי פסק זמן שולח אנשים להגדרות תעבורה שלא היו מעורבות כלל.
השוו בין שתי התצורות לפני השוואת תשובות
מנהרה מלאה ו-DNS מפוצל מייצרים ציפיות הפוכות, ואף אחד מהם אינו תקלה. במנהרה מלאה כל שאילתה עשויה לעבור לספק או לפותר הארגוני, ולכן זה צפוי ששמות ציבוריים יענו אחרת לאחר ההתחברות. ב-DNS מפוצל רק התחומים הרשומים עוברים לפותר הפרטי וכל השאר נשאר מקומי; ב-Windows רשימת התחומים נמצאת ב-Name Resolution Policy Table, ב-macOS בתחומי ההתאמה של הגדרות ה-DNS, ובמארח systemd-resolved בתחומי הניתוב לכל קישור.
זו ההשוואה שצריך לעשות קודם, כי היא קובעת מה נחשב לתקלה. ב-DNS מפוצל, שם ציבורי שעונה מפותר חדש הוא מה ששווה לחקור, בעוד שם פנימי שעונה נכון הוא המערכת שעושה את עבודתה. במנהרה מלאה, החריגה היא שם ציבורי שעדיין עונה מפותר ספק האינטרנט שלכם. התיעוד של מיקרוסופט על פתרון שמות ב-VPN מתאר את סדר הכללים ב-Windows, כולל האופן שבו רשומת מדיניות תואמת נבדקת לפני השרתים של המתאם עצמו.
יש פותר שלישי בחדר שקל לשכוח. ה-DNS המאובטח של הדפדפן פותר שמות בעצמו ויכול להמשיך לענות אחרי שהמנהרה שינתה את מדיניות מערכת ההפעלה, ולכן דף שנטען מוכיח שהפותר של הדפדפן עבד, לא שהפרופיל הוחל. אם אתם משווים רק את מה שהדפדפן מציג, חצי מהזמן אתם בודקים את השכבה הלא נכונה.
רשמו קו בסיס עם משתנה אחד בלבד
שנו את המנהרה. אל תשנו גם את השם, את הכלי או את סיומת החיפוש באותו שלב. בחרו שם שמותר לכם לשאול עליו, רשמו באיזו אפליקציה השתמשתם, וכתבו או את הכתובת שחזרה או את השגיאה המדויקת. ב-Windows Get-DnsClientServerAddress -AddressFamily IPv4 מדפיס את השרתים לכל מתאם ו-Get-DnsClientNrptPolicy מדפיס את רשומות המדיניות; ב-Linux עם systemd-resolved resolvectl status מציג שרתי DNS ותחומי ניתוב לכל קישור; ב-macOS scutil --dns מדפיס את סדר הפותרים שהמערכת באמת תלך לפיו.
אחר כך התחברו דרך הפקדים הרגילים של הלקוח וחזרו בדיוק על אותן פקודות. שמרו את הפלט הראשון ולא זיכרון שלו, כי ההשוואה היא כל העניין וקריאה שנייה שנלקחת אחרי ריקון המטמון היא כבר מדידה אחרת. אם קו הבסיס נלקח כשהדפדפן מלפנים וההרצה שאחרי ההתחברות נעשית במסוף, אתם משווים שני פותרים ולא שני מצבים של פותר אחד.
שאילתה מפורשת וחיפוש של אפליקציה הם בדיקות שונות
לשאול שרת מסוים אחד, עם nslookup name 10.20.0.1 או dig @10.20.0.1 name, מוכיח דבר אחד: שהשרת שציינתם עונה כשאפשר להגיע אליו. זה עוקף לגמרי את לוגיקת הבחירה, ולכן אינו יכול לומר לכם אם המערכת הייתה בוחרת בשרת הזה לשם הזה. השתמשו בזה כדי לבדוק אם הפותר שהוקצה נגיש, ואל תשתמשו בזה כדי לבדוק מדיניות.
חיפוש דרך הפותר המקומי אכן מפעיל בחירה. resolvectl query name עובר את אותם כללי תחומי ניתוב ומדווח איזה פרוטוקול ענה, Resolve-DnsName ב-Windows עובר דרך טבלת המדיניות והמטמון של הלקוח, ו-scutil --dns מציג את הסדר שחיפוש ילך לפיו. הריצו את שני הסוגים ושמרו אותם בעמודות נפרדות בהערות שלכם. שאילתה מפורשת מוצלחת לצד חיפוש אפליקציה שנכשל היא בעיית ניתוב או בחירה, לא פותר שמסרב לעבוד.
המטמון עומד ביניכם לבין התשובה. מערכת ההפעלה, פותר ה-stub המקומי, הדפדפן והמטמון השלילי כולם מחזיקים תוצאות, ולכן חיפוש יכול להצליח בלי שחבילה אחת תצא מהמחשב. רשמו את התוצאה לפני שתנקו משהו: ipconfig /flushdns, resolvectl flush-caches או sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ב-macOS. דלגו על איפוס הרשת הרחב בשלב הזה, כי הוא הורס את הראיות שאתם עדיין אוספים.
מה המשמעות של ההבדל
השוו את שתי השורות שרשמתם וסווגו את השינוי לפני שאתם נוגעים בהגדרה אחת.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
שורה אחת ראויה להדגשה. שם שנפתר אינו שירות שעובד, והצלחה של DNS אומרת רק שנמצאה כתובת. היא לא אומרת דבר על העברה, על כללי חומת אש או על האם החשבון שלכם רשאי להשתמש בשירות בכלל, ולכן סיימו בבדיקת האפליקציה בפועל במקום להניח שהתקלה נסוגה מעצמה.
החזירו את קו הבסיס ואמתו אותו
התנתקו דרך הפקדים של הלקוח עצמו במקום להרוג את התהליך, ואז קראו שוב את אותן שלוש פקודות. השרתים לכל קישור, רשומות המדיניות והתשובה לשם הבדיקה שלכם אמורים לחזור לקו הבסיס שרשמתם קודם. רשומת מדיניות שנותרת אחרי התנתקות נקייה היא פגם אמיתי ששווה לתעד, וזו גם הסיבה לכך שעריכה ידנית של קובץ פותר שנוצר היא הרגל רע: הקובץ נכתב מחדש והעריכה נעלמת, או שהעריכה שורדת ומצמידה פותר שאין לו יותר נתיב.
עברו על הרשימה הזו פעם אחת, לפי הסדר. החליטו איזו תצורה הפרופיל מיישם לפני שאתם שופטים תוצאה כלשהי. החזיקו את השם, הכלי והסיומת קבועים בשתי ההרצות. הפרידו את השאילתה המפורשת מחיפוש האפליקציה. קראו את המדיניות האפקטיבית, לא רק את התשובה. נקו מטמונים אחרונים, אחרי שההשוואה נרשמה. אמתו עם האפליקציה האמיתית, ואז הפעילו מחדש פעם אחת וודאו שמצב הניתוק עדיין נקי.