שני VPN, פותר אחד: מי שכתב אחרון מנצח

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

המיתוס: ה-VPN החדש ביותר הוא הבעלים של DNS

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

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

מפו מרחבי שמות לפותרים

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

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

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

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

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

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

כתובות חופפות אינן בעיית DNS

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

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

הוכיחו זאת עם יישומים אמיתיים

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

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