למה OpenVPN ב-Windows אומר ca: נתיב בלי מרכאות, לא תעודה פגומה

OpenVPN לא מתחיל, והודעת הכשל מצביעה על שורה שנראית תקינה: Unrecognized option or missing or extra parameter(s) in office.ovpn:42: ca. התעודה לא השתנתה, הקובץ נפתח בעורך, ושום דבר בנתיב לא נראה שגוי. המנתח לא מתנגד לשם האפשרות; הוא מתנגד לכמה ארגומנטים הגיעו איתה. ארבע בדיקות פותרות כמעט כל מקרה כזה, וכדאי להריץ אותן לפי סדר העלות.

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

כל שורת תצורה מפוצלת לפי רווחים ולפי מרכאות לפני שאפשרות כלשהי רואה אותה. לכן ערך שמכיל רווח מגיע ככמה ארגומנטים אלא אם הוא עטוף, והאפשרות שבעל השורה מדווחת על אי ההתאמה. ב-Windows תיקיית ההתקנה המוגדרת כברירת מחדל הופכת זאת לוודאי, מפני ש-C:\Program Files נמצא באמצע הנתיב מכוח המבנה. התעודה לא נפתחת לעולם בכשל הזה, ולכן בדיקה אם הקובץ קיים אינה מוכיחה דבר שימושי.

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

ca C:\Program Files\OpenVPN\config\office-ca.crt

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

זוג אחד של מרכאות כפולות סביב הערך הוא כל התיקון, וקווים נטויים קדימה מתקבלים ב-Windows, ולכן הבריחה אינה הופכת לחלק מהבעיה. תקנו כל אפשרות נתיב באותה מעבר, כי המנתח עוצר בכשל הראשון והבאה רק ממתינה לאתחול הבא. הקבוצה כוללת בדרך כלל ca, cert, key, tls-auth ו-auth-user-pass.

ca "C:/Program Files/OpenVPN/config/office-ca.crt"
cert "C:/Program Files/OpenVPN/config/office.crt"
key "C:/Program Files/OpenVPN/config/office.key"

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

Select-String -Path .\office.ovpn -Pattern 'Program Files'

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

שחזרו את הצהרת המצב לפני התעודות

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

client
dev tun
proto udp
remote vpn.example.net 1194

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

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

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

Format-Hex .\office.ovpn | Select-Object -First 1

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

איזו בדיקה ראשונה, ולמה

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

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