OpenVPN דחף שרת DNS, אבל Linux מתעלם ממנו

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

בדיקה ראשונה: איך החיבור מתחיל

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

תהליך משורת פקודה אינו אוטומטית חיבור NetworkManager, וחיבור NetworkManager אינו אוטומטית הדבר שכתב resolv.conf. שתי ההנחות האלה מסבירות את רוב השעות שאבדו בחקירה הזאת. שאלו איזה רכיב היה מפרסם DNS עבור הממשק שאתם באמת רואים.

רשמו את הבעלים לפני שממשיכים. כל בדיקה מאוחרת תלויה בו.

בדיקה שנייה: מה הקישור של הפותר מחזיק באמת

במארח systemd-resolved, resolvectl status מפרט כל קישור עם שרתי ה-DNS והדומיינים שלו. מצאו את קישור המנהרה וקראו את הערכים שלו, ואל תניחו שהממשק נקרא tun0, כי המספור הולך לפי סדר היצירה. אם הכתובת שנדחפה חסרה בקישור, ההעברה נכשלה ולא השאילתה.

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

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

בדיקה שלישית: האם מרחב השמות בוחר את הקישור הזה

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

בדקו את הקצאת הדומיין, לא רק את כתובת השרת. דומיין שנכתב בתור ~corp.example הוא דומיין ניתוב, והטילדה משנה איך מתאימים את השם.

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

בדיקה רביעית: בעלים אחד, לא שניים

אם NetworkManager כבר מנהל את ה-VPN ואת מצב הפותר, הוספת סקריפט וו לא קשור יוצרת כותבים מתחרים. הוו שמותקן על ידי החבילה עבור systemd-resolved הוא אינטגרציה נתמכת, והוא מצפה למחזור חיים מסוים: script-security 2, נתיב up, up-restart, נתיב down ו-down-pre. האפשרויות האלה גורמות לרישום ולהסרה לקרות ברגעים הנכונים ולא רק בחיבור הראשון.

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

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

בדיקה חמישית: אותה תוצאה אחרי התחברות מחדש

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

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