למה nslookup נפתר דרך ה-VPN אבל הדפדפן לא

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

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

שלוש מדיניות קובעות את התשובה

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

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

למה הדפדפן שואל שאלה אחרת

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

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

קראו את רשימת הפותרים ואת הכללים

ב-Windows, שפכו מה שהמערכת מחזיקה לפני שאתם מתארים תיאוריות. Get-DnsClientServerAddress מציג את השרתים לכל ממשק, Get-DnsClientNrptRule מפרט את כללי מרחב השמות, ו-Resolve-DnsName עונה לשם המדויק דרך מסלול המערכת. השוו את התשובה הזו לשאילתה ישירה לשרת ה-VPN לפי כתובת. כש-Resolve-DnsName נכשל והשאילתה הישירה מצליחה, החשוד הוא רשימת הפותרים או כלל מרחב שמות.

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

הפותר הנדחף שאינו נגיש

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

אם הפותר אינו נגיש, התיקון הוא מסלול או תת-רשת כלולה, לא שרת DNS אחר.

DNS מוצפן עוקף את כל המסלול

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

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

תיקונים שמתאימים לכשל

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

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

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