נתיב VPN חסר ב-NetworkManager: מדיניות פרופיל או סקריפט?

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

החליטו איזה בעל אחראי לפני שתכתבו משהו.

שלושה בעלים, קידומת חסרה אחת

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

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

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

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

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

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

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

ipv4.ignore-auto-routes ו-ipv4.never-default עונים על שאלות שונות. הראשון יכול לדחות נתיבים שהחיבור היה נוטל אחרת באופן אוטומטי, והשני שולט בשאלה אם הפרופיל רשאי להפוך לנתיב ברירת המחדל. פרופיל שמתעלם מנתיבים אוטומטיים ולא נשען על שום דבר אחר יתחבר נקי וכמעט לא יתקין דבר.

ip -4 rule show
ip -4 route show table all

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

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

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

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

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

ההחלטה, לפי הסדר

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

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

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