מי צריך להחזיק בנתיבים וב-DNS כש-openfortivpn מתחבר?

ארבעה שלבים נערמים זה על זה בסשן openfortivpn עובד. הלקוח מאמת מול השער ומתחיל חיבור TLS, אחר כך מריץ PPP בתוך אותו חיבור, אחר כך מקבל כתובת ומידע DNS, ולבסוף מחיל נתיבי מארח והגדרות resolver. כל שלב יכול להיות חי כשהשלב הבא אינו, ולכן “מחובר” היא מילה כה חלקלקה בשרשורי תמיכה.

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

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

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

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

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

מי עורך את טבלת הניתוב

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

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

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

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

מי מחזיק ב-DNS ובקובץ ה-resolver

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

במארח Linux מודרני ה-resolver עשוי להיות מנוהל על ידי stub מקומי, ולשכתב את קובץ ה-resolver מאחורי הגב של אותו stub מייצר תצורה שנראית נכונה ומתנהגת בחוסר עקביות. אם המארח כבר מריץ מנהל resolver, תן לו להחזיק ב-DNS והזן לו את שרתי המנהרה דרך הממשק הנתמך שלו. אפשרות ה-no-dns של הלקוח היא הבחירה הנכונה שם, לא עקיפה.

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

הרשאה, מוכנות והמסירה

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

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

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