מי באמת מחיל את הגדרות ה-DNS של OpenConnect ב-Windows?
Windows שומר את מצב הפותר בשלושה מקומות. מצאו את העוזר שבבעלותו החיבור לפני שאתם עורכים ידנית את ה-DNS של המתאם או מוסיפים כלל מרחב שמות.
העלאת המנהרה אינה אותו דבר כמו התקנת ערכי ה-DNS שלה. OpenConnect מנהל משא ומתן, ועוזר בצד Windows מחיל. הפער בין שני השלבים האלה מסביר את רוב כשלי השמות הפרטיים בלקוח הזה, והעוזר כמעט אינו עמוד הגדרות ה-VPN של Windows.
הפרידו בין מה שהציע השער לבין מה ש-Windows התקין
הלקוח מוסר את נתוני החיבור לממשק סקריפט, וגרסאות ה-Unix וה-Windows הן תוכנות נפרדות. ב-Windows המימוש הוא בדרך כלל עוזר JavaScript שקורא משתנים כמו שרת ה-DNS הפנימי והתחום הפנימי לפני שהוא נוגע במתאם כלשהו. שום דבר במנהרה עצמה לא כותב מצב פותר.
ההפרדה הזו חשובה כי ערך יכול להתקיים במשא ומתן ולא להגיע למתאם לעולם. עוזר שחסר, נכשל באמצע הדרך או שהוא עותק ישן שנארז בתוך מעטפת GUI משאיר את Windows בדיוק כפי שהיה. החיבור נראה מחובר, השם הפרטי עדיין נפתר דרך הספק המקומי, ושום דבר בחלון הלקוח לא רומז להבדל. קריאת הפלט של העוזר עצמו היא הדרך האמינה היחידה לדעת איזה שלב נשבר.
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
מעטפת GUI עשויה לספק עותק משלה של הלקוח והעוזר, ולכן openconnect.exe שני במקום אחר בדיסק לא מוכיח דבר. מצאו את קובץ ההרצה שהתחיל את החיבור לפני שאתם שופטים את התצורה שלו.
קראו את מצב הפותר בלי לשנות אותו
שלוש שאילתות לקריאה בלבד מכסות את הבלבול הרגיל, וכל אחת עונה על שאלה אחרת:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effectiveשרת ברמת המתאם הוא מה שרוב האנשים מתכוונים אליו ב-DNS של VPN. סיומת ספציפית לחיבור קובעת אם שם קצר יורחב בכלל. רשימת מדיניות מרחב השמות חלה על שמות תואמים ללא תלות בסדר המתאמים, ותוצאה ריקה שם אינה תקלה כאשר העוזר מעולם לא התכוון ליצור אחת. קריאת שלושתם לפני עריכה היא מה שמונע תיקון שרק מזיז את הסימפטום למקום אחר.
התחילו בשם המלא. אם ה-FQDN נפתר והשם הקצר לא, הסיומת או רשימת החיפוש היא הפער, לא כתובת השרת.
שאלו את השרת המיועד ישירות כשלב שני, בכל כלי פותר שכבר מותקן. תשובה ישירה מוכיחה שהשרת נגיש ובעל סמכות לאזור. היא לא מוכיחה דבר לגבי איזה שרת אפליקציה שואלת כברירת מחדל.
תנו שם לרכיב שבבעלותו החיבור
שני סידורים נפוצים. לקוח שהופעל ממסוף מעביר את נתיב הסקריפט שלו במפורש, ולכן הבעלים גלוי בפקודה שהורצה. אפליקציה ארוזה מפעילה את הלקוח עבורכם ושומרת את העוזר בתיקייה שלה, כלומר הספק מחליט מתי הוא משתנה.
השוו גרסאות עוזר בין התקנות לפני שאתם מחליפים משהו. הרצת עוזר שהורד ממראה בהרשאות מוגברות כי שם הקובץ נראה מוכר הופכת פער DNS לתקרית אבטחה.
לאחר שהבעלים ידוע, יעד התיקון מתבהר: נתיב סקריפט נתמך במשגר, עדכון חבילה או פרופיל מתוקן בשער. אף אחד מאלה לא דורש עריכת מאפייני מתאם ביד.
תקנו את הבעלים, לא את המתאם
DNS שהוגדר ידנית במתאם שורד לעיתים קרובות את הניתוק, ולכן נראה שהוא עובד ואז גורם לצרות ברשת הבאה. פותר ציבורי שמוברג לכל ממשק מסתיר את בעיית מרחב השמות הפרטי במקום לפתור אותה. כאשר העוזר מעולם לא קיבל ערך DNS, פרופיל השער הוא המקום להסתכל בו. כאשר הוא קיבל אחד והמתאם עדיין מציג את השרת הישן, העוזר נכשל בזמן ההתחברות ויומן הלקוח בדרך כלל מתעד זאת ליד שורות הגדרת המנהרה.
בנו מחדש את המצב דרך הנתיב הנתמך, ואז אמתו מחזור שלם: התחברו, פתרו את ה-FQDN הפרטי, פתחו את השירות, התנתקו, ואשרו שהמתאם חזר עם השרתים הקודמים שלו.
בדקו את האפליקציה שנכשלת בפועל
דפדפן עם הגדרת DNS מוצפן משלו מתעלם מכל האמור לעיל וממשיך לענות מפותר ציבורי. אפליקציה שמחזיקה תשובה שלילית שמורה מרגע שלפני עליית המנהרה מתנהגת באותה דרך. השוו אותה לשאילתת מערכת פשוטה באותה מכונה לפני שתשנו שוב כתובות פותר.
אם שאילתת המערכת נכונה והאפליקציה שגויה, התקלה שנותרה נמצאת בתצורת ה-DNS של אותה אפליקציה, לא בנתיב ה-VPN.