openfortivpn ממשיך לדרוס את ה-DNS? מצאו את הבעלים האמיתי

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

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

התחילו במה שהחיבור באמת שינה

התחברו פעם אחת עם הפקודה הרגילה שלכם והשוו את הפתרון לפני ואחרי. במארח Linux שמריץ systemd-resolved, resolvectl status מדפיס שרתי DNS ותחומי חיפוש לכל קישור, וקישור tun או ppp חדש שנושא שרתים משלו הוא טביעת האצבע של עדכון מצד הלקוח. ב-macOS, scutil --dns מציג את תצורת הפותר בסדר שבו יישומים מתייעצים איתה.

השוו את זה לקובץ שציפיתם שישתנה. רשומה הקשורה לחיבור בתצוגה לכל קישור וקובץ /etc/resolv.conf שנכתב מחדש הם שתי תוצאות שונות, והשנייה עשויה להיות קישור סמלי שמשהו אחר לגמרי מנהל אותו. רשמו את כתובת הפותר, תחומי החיפוש ושם הממשק באותו רגע; שינוי בכל אחד מהם מצביע על כותב אחר. בלי קו הבסיס הזה, כל תיקון מאוחר יותר הוא ניחוש לגבי איזה משלושה רכיבים זז.

שני המתגים והכותב שכל אחד מהם משתיק

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

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

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

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

בחרו את הבעלים לפני שתשביתו משהו

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

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

בדקו את הפתרון לכל קישור, לא לכל קובץ

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

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

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

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

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

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