איזה רכיב באמת מחזיק במגבלת מסלולים של OpenVPN?
מגבלת מסלולים יכולה להיות של מנוע OpenVPN, של תוסף NetworkManager או של השרת. נקבו בשם הבעלים לפני עריכת פרופיל או העלאת מספר.
פרופיל שנושא מאתיים מסלולים עובד במכונה אחת ומתקין ארבעים באחרת. למנוע, לאינטגרציה שמפעילה אותו ולשרת שמזין אותו יש לכל אחד מילה, וכל אחד מהם יכול לעצור את הרשימה בנקודה אחרת. קריאת התקלה כמגבלה אחת שולחת אתכם לקובץ הלא נכון. המנגנון כולל שלושה שלבים, והשלב שנעצר משאיר ראיות גלויות כשאתם יודעים מה לחפש.
שלושה שלבים, שלוש מגבלות שונות
תחילה המנוע מנתח את האפשרות ומחליט אם הגרסה הזו מבינה אותה. אחר כך האינטגרציה מתקינה את מה שהמנוע מדווח, והקוד שלה עשוי להגביל או לעצב מחדש את הרשימה. לבסוף השרת מחליט כמה מסלולים ידחוף לזהות מסוימת, לפני ששלב לקוח כלשהו רואה משהו. שלושה שלבים, שלוש תקרות, ורק אחת מהן היא המספר בפרופיל.
העלאת תקרה אחת לא עושה דבר לאחרות. מסלול שנדחף ונדחה יכול להיות החלטת מדיניות בשרת, חפיפה שהלקוח פתר, או מגבלה של המתקין שזרק את העודף. לכל אחד מאלה יש תיקון אחר.
הפרידו בין השלושה לפני שתמדדו משהו. שגיאת מנתח נוקבת בטוקן, מגבלת מתקין משאירה טבלת מסלולים קצרה, והחלטת מדיניות לא משאירה דבר. הראיות אומרות לכם איזה שלב לבדוק ראשון.
| Stage | Who decides | What you can see |
|---|---|---|
| Parse | Client engine | An error naming the option |
| Install | Activation owner | A route count below the pushed count |
| Offer | Server policy | A route absent from the pushed list |
המנתח מדבר ראשון
אפשרות לא מוכרת נכשלת בקול ומוקדם, וטקסט השגיאה נוקב בשם הטוקן. זה השלב הקל ביותר לזיהוי: השוו את ההודעה המדויקת לגרסת המנוע המותקנת, כי אפשרות שנוספה במהדורה אחת אינה מוכרת בקודמתה. פרופיל שהועתק מפריסה חדשה יותר הוא המקור הרגיל לאי-ההתאמה הזו. המנתח אינו מתעלם בשקט לעולם מהוראה שאינו מזהה.
אפשרות שהתקבלה לא אומרת דבר על התוצאה. הניתוח מצליח, והרשימה עדיין עשויה להיחתך בידי המתקין או לא להיות מוצעת כלל בידי השרת. התייחסו לניתוח נקי כרשות להמשיך, לא כהוכחה.
רשמו את מחרוזת הגרסה מהבינארי שרץ בפועל, לא מהתפיסה של מנהל החבילות לגבי מה שמותקן. השניים האלה חלוקים לעתים קרובות יותר מהמצופה.
למתקין יש תקרה משלו
הרכיב שמחזיק בהפעלה עשוי להיות תוסף NetworkManager ולא הבינארי של המנוע, והוא עשוי לכפות מגבלה משלו לפני שקיים מנהרה. העורך שלו עשוי לחשוף שדה שהמנוע הפועל אינו קורא לעולם, או לקרוא שדה שהעורך אינו מציג. שני המצבים נראים מבחוץ כמו תקלה בלקוח. אף אחד מהם אינו מתוקן בעריכת הפרופיל.
ספרו מה נחת ולא מה הוגדר. הפקודה ip route show dev tun0 מציגה את המסלולים המותקנים, והשוואת המספר הזה לרשימה שנדחפה מפרידה בין מסלול שנזרק למסלול שמעולם לא נשלח. מספר שמתאים לדחיפה מחזיר את החשד לשרת.
עטיפת מעטפת סביב הבינארי של המנוע כדי לכפות מספר גדול יותר מטשטשת שדרוגים והופכת את החזרה לאחור לניחוש. היא גם מסתירה את המגבלה האמיתית מכל מי שיקרא את התצורה בהמשך.
השרת מחליט מה הוצע לכם
מדיניות לכל לקוח עשויה לכווץ את הרשימה לפני שהיא נשלחת. קובץ ייעודי ללקוח עשוי להוסיף מסלולים לזהות אחת, או שמדיניות קבוצה עשויה להשמיט אותם, והלקוח אינו יכול להבחין בין מסלול שסונן למסלול שמעולם לא הוגדר. העמימות הזו היא הסיבה שרישומת השרת חשובה. בקשו את רשימת הדחיפה האפקטיבית לאותה זהות, לא את התבנית.
השוו את רישומת השרת לרשימה שהתקבלה. הפער ביניהם הוא שכבת המדיניות, והוא בדרך כלל קטן ממה שהפרופיל מרמז.
כשהתכנון מאפשר, סכמו רשתות סמוכות ומחקו רשומות מיושנות. מסלולים מעטים וגדולים יותר פותרים יותר מקרים מתקרה גבוהה יותר.
שנו את המספר במקום הנכון
השתמשו בהגדרה המתועדת של הרכיב שבאמת מחזיק במגבלה. אם השדה חסר בתוסף, בדקו אם התוסף קדום לתכונה או אם ממשק אחר מחזיק במסלולים. אחר כך תעדו את גרסאות המנוע, התוסף והשרת לצד הערך שבחרתם. השדרוג הבא פותח מחדש את השאלה, וההערה היא מה שהופך אותה לניתנת למענה.
בדקו מחדש אחרי כל שדרוג של כל אחד מהשלושה. מגבלה שהועלתה במקום הנכון עדיין זזה כשהרכיב שאוכף אותה משתנה. רישום הגרסאות הוא הדבר היחיד שהופך את התנועה הזו לצפויה.