נתיבים קבועים ל-VPN ב-Mac: networksetup או hook חיבור?

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

החליטו אם הנתיב שייך לשירות או להפעלה

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

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

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

קראו את מצב הנתיב והשירות הנוכחי

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

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

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

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

שמרו את הקידומת עם networksetup

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

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

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

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

השתמשו ב-route add רק לבדיקה

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

sudo route -n add -net 10.20.0.0/16 -interface utun4

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

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

בחרו hook רק כשהכתובת נמצאת במשא ומתן

לקישורים מבוססי PPP כמו L2TP, macOS מריץ את /etc/ppp/ip-up לאחר שהקישור נוצר. הסקריפט מקבל את שם הממשק ואת הכתובות המקומית והמרוחקת שהוסכמו, כך שהוא יכול להוסיף נתיב שתלוי בעמית שהשרת הקצה. זה בדיוק המקרה שנתיב שירות קבוע אינו יכול לבטא.

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

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

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