OpenVPN דוחף DNS, אבל ייתכן שהפותר שלך לא יראה אותו לעולם

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

התסמין: היומן מציג DNS והשמות עדיין נכשלים

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

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

לקבל אינו להחיל

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

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

מצא את הבעלים של הפותר לכל פלטפורמה

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

קרא את המצב האפקטיבי בכלי שבאמת עונה לשאילתות: resolvectl query internal.example.net במארח systemd-resolved, או המקבילה בפלטפורמה. ואז השווה את התשובה לשרת ה-DNS שהיומן של הלקוח טוען שנדחף.

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

Scripts ו-foreign_option

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

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

בדוק את השם, לא את היומן

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

אם השם נפתר אך השירות נכשל, עבור אל ניתוב וגישה ליישומים במקום לשנות שוב את ה-DNS. המדריך של OpenVPN מתעד את dhcp-option ואת סביבת ה-scripts; השתמש בו כדי לאשר מה הלקוח שלך אמור להחיל לפני שתערוך קובץ פותר נוסף.