איזה קישור עונה: דומיינים לניתוב DNS של VPN עם מנהרה מפוצלת

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

שלב ראשון: הפרידו בין הנתיב לפותר

ipv4.never-default עונה על שאלת ניתוב, ומונע מ-NetworkManager להתקין את החיבור הזה כנתיב לכל תעבורת IPv4. דומיין ניתוב DNS עונה על שאלה אחרת: שרתי השמות של איזה קישור מקבלים שאילתה עבור סיומת מתאימה. אף אחד מהם לא מחייב את השני, ופרופיל יכול לשאת אחד מהם שנים בעוד השני חסר. נתיב בלבד פירושו שהמנהרה נושאת את תתי-הרשתות של החברה והפותר שלה עונה לשמות החברה, בעוד כל השאר נשאר בלי שינוי.

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

שלב שני: הוסיפו דומיין ניתוב בלבד לפרופיל

נניח שהחיבור נקרא corp-vpn, סיומת החברה היא internal.example, והפותר של המנהרה כבר נגיש. קראו תחילה את הערכים הנוכחיים, כי הפקודות למטה משנות מאפיינים שאולי כבר מכילים רשומות.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

טילדה בהתחלה מסמנת דומיין ניתוב בלבד, כך ששאילתות מתאימות הולכות לשרתים של הקישור הזה והסיומת לא מתווספת לשמות קצרים. הסירו את הטילדה ואותו מחרוזת הופך גם לסיומת חיפוש, שהיא תוצאה אחרת שאנשים ממעטים להתכוון אליה. שתי ההגדרות למעלה הן IPv4, כך שפרופיל דו-סטאק צריך את ipv6.never-default ואת אותו דומיין ניתוב ב-ipv6.dns-search, אחרת צד ה-IPv6 ממשיך להשתמש בנתיב ברירת המחדל והשמות הפנימיים נכשלים שם.

שלב שלישי: שאלו את resolvectl איזה קישור ענה

הריצו resolvectl status וקראו את שרתי ה-DNS והדומיינים של כל קישור, ואז הריצו resolvectl query host.internal.example מול שם פנימי אמיתי שמותר לכם לשאול עליו. הפקודה השנייה היא ההוכחה הישירה היחידה שדומיין הניתוב עושה את עבודתו, כי היא נוקבת בשם הקישור שענה. רשימת סטטוס לבדה מוכיחה תצורה; השאילתה מוכיחה פתרון.

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

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

שלב רביעי: כשהשם נפתר אבל השירות לא

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

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

שלב חמישי: אל תחליפו את הפותר כדי לתקן דומיין חסר

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

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