מסלולי VPN נוספים ב-Mac צריכים בעלים, לא סקריפט התחברות
מסלול שנוסף פעם אחת בהתחברות אינו מדיניות התחברות מחדש. תנו בעלים לקידומות מרוחקות והחליטו כיצד הן מופיעות, משתנות ונעלמות עם החיבור הזה.
הגעה לקידומת פרטית דרך VPN היא דרישה שיש לה משך: היא תקפה כל עוד החיבור הזה שמיש, והיא נגמרת כשהחיבור נגמר. סקריפט התחברות אינו יכול לבטא זאת, מפני שהתחברות והעלאת המנהרה הם רגעים שונים, והמנהרה שקיימת בהתחברות אינה בהכרח זו שנושאת תעבורה דקה לאחר מכן. ההחלטה הראשונה אינה איזו פקודה להריץ. היא איזה רכיב מחזיק בקידומת.
הקידומת צריכה בעלים, לא רגע
התחילו בכתיבת הדרישה כמשפט עם נושא: הגיעו 10.77.0.0/24 דרך VPN המשרד כל עוד החיבור הזה פעיל. המשפט הזה נוקב בקידומת, בחיבור ובתנאי, והוא פוסל מיד שני תחליפים פופולריים: וו התחברות ושם ממשק כמו ppp0 או utun2.
שמות ממשקים מוקצים בזמן ריצה ואינם יציבים בין התחברויות מחדש. וו שמתאים לשם שראה בשבוע שעבר או שלא יופעל או שיופעל מול הממשק של מישהו אחר. שתי התוצאות נראות כמו תקלת ניתוב ולא כמו ההנחה המיושנת שהן. אותה התנגדות חלה על כל סקריפט שתלוי בשם שקיים רק כל עוד מנהרה מסוימת פעילה.
השתמשו במקור נתמך לכוונת ניתוב
השער, פרופיל מנוהל או מנגנון הניתוב המתועד של הלקוח הבעלים הוא המקום הנכון לכך, בכל עת שהמנגנון הזה יכול לבטא את הדרישה. איזה מהם חל תלוי בפרוטוקול ובספק, והמפתחות אינם עוברים ביניהם, כך שערך שמגדיר פרופיל OpenVPN לא אומר לכם דבר על לקוח L2TP או IKEv2 המקורי.
| Mechanism | Can carry extra prefixes | Who owns the lifetime |
|---|---|---|
| Gateway-pushed routes | Often, if the gateway is configured for it | The connection |
| Managed profile settings | Depends on the client and profile format | The profile |
| Provider tunnel settings | Yes, as included and excluded routes | The provider process |
| Manual command | Yes, once | Nobody |
למפתחי מנהרות מנות, הגדרות מנהרת IPv4 של Apple חושפות במפורש מסלולים כלולים ומוחרגים, ול-IPv6 יש מקבילה. אלה ממשקי API שהספק משתמש בהם, לא הוכחה שכל פאנל VPN מקורי מציע למנהל רשימת מסלולים שרירותית. אם השילוב הנוכחי אינו יכול לבטא את הקידומות שאתם צריכים, הצעד הבא הוא נתיב תצורה נתמך מהמפעיל, לא אפליקציה אחרת שמותקנת בתקווה שתתנהג טוב יותר.
אורך החיים כולל ניקוי
לפעמים עוזר חיצוני נדרש באמת, ואז «הוסף את המסלול» הוא החלק הקטן ביותר בעבודתו. הוא צריך לדעת לאיזה חיבור הוא משרת ואיזה ממשק החיבור הזה משתמש בו, להמתין עד שמצב הרשת הרלוונטי יתייצב, להישאר אידמפוטנטי כשהוא רץ פעמיים ברצף, ולא לנקות דבר שהוא עצמו לא התקין.
הסעיף האחרון הוא זה שכואב. עוזר שמוחק כל מסלול שמתאים לקידומת המשרד ימחק במוקדם או במאוחר מסלול שהוא לא הוסיף. התקלה הנובעת מכך מיוחסת ללקוח ה-VPN, מפני שהלקוח הוא החלק שהמשתמש רואה. החלטה מה העוזר מחזיק בו לפני שכותבים אותו זולה יותר מלהסביר אחר כך למה תת-רשת מקומית הפסיקה לענות.
מירוץ ההתחברות מחדש
חשבו על התחברות מחדש מהירה. הפעלה A נופלת, הפעלה B עולה ומתקינה את המסלול שלה, ואז הניקוי המושהה של A סוף סוף רץ. אם הניקוי הזה מסיר מסלולים לפי קידומת, הוא לוקח איתו את המצב התקף של B, והחיבור שעבד לפני שנייה מנתב כעת לשום מקום.
זהו מירוץ בעלות, והוספת שינה לסקריפט רק משנה איזה צד מנצח בו. התיקון הוא להתנות את הניקוי בזהות: השוו את הממשק וההפעלה שהעוזר התקין לאלה שעדיין תקפים, והסירו רק בהתאמה.
מה לבדוק, ומה מסלול לא יכול לעשות
הקבלה חייבת לכסות ארבעה מעברים: החיבור הראשון, התחברות מחדש לממשק אחר, ניסיון חיבור שנכשל, והניתוק הסופי. אחרי כל אחד מהם, קראו את המסלול שהמערכת בחרה בו בפועל לכתובת בצד המרוחק, ולא את זה שציפיתם לה.
route -n get 10.77.0.5
netstat -rn -f inetכללו גם את המקרים המסורבלים באותו סבב: IPv6 היכן שנדרש, קידומת מקומית שחופפת לקידומת המרוחקת, והמסלול לנקודת הקצה הציבורית של ה-VPN עצמו, שחייב להמשיך לעבוד כל עוד המנהרה פעילה. אחר כך כתבו מה מסלול אינו. הוא בוחר מנות; הוא אינו מעניק הרשאה בצד המרוחק ואינו יוצר נתיב חזרה, ואלה נשארים דרישות נפרדות עם בעלים נפרדים.
התוצאה שאתם רוצים היא קידומת שעוקבת אחרי בעל החיבור הנתמך שלה בכל מעבר, ולא פקודה שהצליחה פעם אחת במקרה במכונה שבה נכתבה.