OpenVPN ממשיך לדחוף מסלולים ישנים? בדקו מה הוא טען

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

ההשוואה שלהלן הולכת מהתהליך החוצה, כי התהליך הוא הסמכות היחידה לקובץ שבתוקף.

הקובץ שערכתם והקובץ שהתהליך קורא

התחילו מה-unit ומשורת הפקודה שהוא יצר. במארח systemd, systemctl cat openvpn@server מדפיס את השורה ExecStart, ו-unit של מופע גוזר בדרך כלל את נתיב התצורה משם המופע, כך שדמון שהופעל בשם openvpn@office קורא קובץ אחר מזה שהופעל בשם openvpn@server. השוו זאת ל-argv של התהליך שרץ. כלי לניהול תצורה מוסיף דרך נוספת לאבד את השינוי: הוא יכול לכתוב קובץ נכון למיקום שה-unit אף פעם לא מזכיר, ואז פריסה ירוקה נראית כאילו לא עשתה דבר.

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

מה השרת דוחף ומה הלקוח מתקין

מסלול שנדחף חייב לעבור שני מסננים. בשרת הוא חייב להיות בתצורה הטעונה, לא בבלוק מוער ולא בקובץ ייעודי ללקוח ששמו אינו תואם. בלקוח pull חייב להיות מופעל ואף pull-filter לא אמור לזרוק את האפשרות. התחברו עם verbosity 4 וקראו את האפשרויות שנדחפו שהלקוח מדווח עליהן: אם המסלול מופיע ברשימה הזו, השרת עשה את שלו והלקוח בוחר שלא להתקין אותו.

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

הקידומת שנדחפה ומסלול החזרה הם בעיות שונות

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

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

השוו את הטבלאות בשני הקצוות

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

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

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

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