מדוע OpenVPN הפסיק להתחבר לאחר שדרוג של Ubuntu?

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

איזו שכבה נכשלה: לחיצת יד, הצפנה, חבילה או ספרייה

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

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

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

כשהלחיצה נכשלת, מדיניות TLS דוחה את התעודה

‏Ubuntu 22.04 העביר את המערכת ל-OpenSSL 3, ורמת האבטחה המוגדרת כברירת מחדל בענף הזה מחמירה יותר לגבי חתימות תעודות וגדלי מפתחות מאשר 20.04. תעודת CA שנחתמה עם תמצית ישנה יותר, או מפתח מתחת לסף הנוכחי, נכשלים כעת בזמן לחיצת היד. כיוון שדבר עדיין לא אומת, השגיאה נקראת כמו סיסמה שגויה או שרת מת.

התיקון הצר מצמיד מחרוזת הצפנה לחיבור הזה בלבד. בעורך שולחן העבודה פתחו את הפרופיל, עברו להגדרות המתקדמות והניחו DEFAULT:@SECLEVEL=0 בשדה הצפנת TLS. קובץ המפתח של NetworkManager מקבל את אותו ערך תחת [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

הפעילו מחדש את NetworkManager והתחברו שוב, מפני שהדמון שומר במטמון פרופילים מפוענחים ואחרת ימשיך להשתמש בעותק שכבר בידו. דעו מה השורה עושה לפני שאתם משאירים אותה: ההגדרה היא סף על פני כמה פרמטרים של תעודות ומפתחות, לא שם הצפנה, ולכן הורדתה מרחיבה את מה שהפרופיל הבודד מקבל. רשמו איזה שרת דרש אותה והסירו את ההגדרה כשהמפעיל מוציא מחדש חומר עדכני. לעומת זאת, שינוי /etc/ssl/openssl.cnf מגיע לאותו סף עבור כל תוכנית שקוראת את הקובץ הזה, הרבה מעבר ל-VPN.

‏OpenVPN 2.6 דורש שההצפנה תופיע ברשימה למשא ומתן

‏Ubuntu 22.10 סיפק את OpenVPN 2.6, ובגרסה הזו --cipher מפסיק לבחור את ערוץ הנתונים בעצמו. ההצפנה חייבת להופיע גם ברשימת data-ciphers שנקבעה במשא ומתן, אחרת הלקוח מדפיס אזהרת התיישנות ואז נכשל בהעלאת המנהרה.

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

data-ciphers=AES-256-CBC

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

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

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

תקלות חבילה ותוסף נראות כמו תקלות VPN

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

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

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

ספרייה של ספק יכולה להסתתר מאחורי שגיאת מדיניות

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

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

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

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

נעיצת לקוח ישן קונה זמן, לא פתרון

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

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

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