למה תו תבנית בהנחיית מסלול של OpenVPN לא יכול לעבוד

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

מה מסלול מתקין, ומה הוא אף פעם לא קורא

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

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

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

כשהיעד הוא באמת קידומת

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

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

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

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

כשיחידת העבודה היא שם מארח

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

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

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

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

מה אפשרות הפרוקסי לא מכסה

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

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

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

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

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

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