שגיאת OpenVPN: אפשרות לא מוכרת tls-remote או keysize

בדרך כלל זה מתחיל בפרופיל שהתחבר במשך שנים, נפתח בלקוח חדש יותר, ונכשל לפני שהמנהרה בכלל מתחילה. המסוף מדפיס משהו כמו Options error: Unrecognized option ... in client.ovpn:130: tls-remote, עם גרסה בסוגריים בסוף. קראו את זה כתלונה של המנתח: הקובץ מכיל הנחיה שהלקוח הזה כבר לא מכיר.

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

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

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

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

מה קרה ל-keysize ול-tls-remote

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

tls-remote הוסר ב-2.4. הוא השווה את תעודת השרת לשם צפוי, והמחליף שלו הוא verify-x509-name, שמחמיר יותר באופן שבו השם מותאם. ההנחיה הישנה נעלמה, ולכן פרופיל שנושא אותה לעולם לא יפוענח בלקוח נוכחי.

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

שכתבו את בדיקת זהות השרת

המחליף לוקח את השם הצפוי ומצב השוואה. verify-x509-name vpn.example.edu name דורש שנושא התעודה יהיה שווה בדיוק לערך הזה. מצבים אחרים מתאימים קידומת או מחרוזת נושא מלאה, ובחירת המצב הלא נכון הופכת פרופיל עובד לכשל אימות נקי.

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

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

פרופיל מתוקן, עריכה מקומית או לקוח ישן יותר

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

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

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

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