tls-auth key-direction: 0 ו-1 חייבים להיות שונים, לא תואמים
עם tls-auth שני הקצוות צריכים כיוונים מנוגדים, 0 ו-1, או ששניהם חייבים להשמיט את ההגדרה. אותו מספר נכשל, ו-tls-crypt אף פעם לא משתמש בו.
צד אחד של המנהרה חותם על ערוץ הבקרה עם חריץ מפתח שהצד השני אף פעם לא בודק, והחיבור מת עם שגיאת אימות לפני שהוחלף אפילו תעודה אחת. כך נראית אי-התאמת כיוון ב-tls-auth, והיא דטרמיניסטית: אותם שני קבצים נכשלים בכל ניסיון, מכל רשת. שום דבר ביומן לא נוקב בשם האפשרות שאתם מחפשים, ולכן אנשים בונים מפתחות מחדש ומנפיקים תעודות שמעולם לא היו שבורות. הפתרון הוא להפוך את שני הקצוות למשלימים, או להשאיר את שניהם דו-כיווניים, במקום להחליש את האימות.
הכשל מגיע לפני התעודות
עם tls-auth שני העמיתים מחזיקים באותו מפתח משותף וכל אחד משתמש באחד משני חריצים שנגזרים ממנו: חריץ אחד חותם על חבילות הבקרה היוצאות, האחר מאמת את הנכנסות. כיוון 0 וכיוון 1 מקצים את התפקידים האלה בסדר הפוך, ולכן הזוג חייב להיות משלים כדי שבדיקות ה-HMAC יתאימו. כשההקצאה מתהפכת בצד אחד, המקלט מחפש חתימה בחריץ הלא נכון ודוחה את החבילה. הסשן מסתיים שם, ולכן השגיאה נוגעת לאימות חבילות ולא למשהו שמאגר התעודות היה מייצר.
הדטרמיניזם חשוב לאבחון, כי בעיית תזמון או נתיב משאירה חתימה אחרת: נפילות לסירוגין, כיוון אחד שנכשל, או סשן שמת רק ברשת מסוימת. אי-התאמת כיוון נכשלת במחיאת היד הראשונה בכל פעם, והיא נכשלת באופן זהה במכונה אחרת עם אותם שני קבצים. קראו את היומן ב---verb 4 ו-מצאו את החבילה הראשונה שנדחתה ולא את השורה האחרונה. אם הדחייה הזו מתרחשת לפני כל החלפת תעודות, המפתח המשותף והכיוון שלו הם שני הדברים ששווה לבדוק.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
איפה המספר חי
המדריך של OpenVPN 2.6 מתעד שני מקומות לכיוון: הארגומנט השני של tls-auth כשהמפתח נמצא בקובץ נפרד, ושורת key-direction עצמאית כשהמפתח מוטמע בפרופיל. שניהם קובעים את אותו ערך, ולכן פרופיל צריך להשתמש בצורה אחת או בשנייה, אף פעם לא בשתיהן. השמטה היא גם בחירה, והיא מציבה את שני העמיתים בסידור דו-כיווני שעובד כשאיש מהצדדים לא נוקב בכיוון. שני עמיתים עם אותו מספר אינם בסידור הזה: כל אחד מצפה לחתום בחריץ אחד ולאמת בשני, ושניהם עושים זאת באותו אופן.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
הצורה המוטמעת היא הנחיה בשורה נפרדת, לא מאפיין בתג הפתיחה של בלוק המפתח, והוספת ארגומנט לתג הזה היא שגיאה ולא שינוי כיוון. גם המיקום חשוב: ההנחיה נמצאת מחוץ לבלוק שאליו היא שייכת, ולכן ערך שנכתב בתוך הבלוק נקרא כחומר מפתח. העתיקו את הסידור שהפיץ הפרופיל התכוון לו במקום להמציא זיווג, כי פרופיל שעובד מול שרת אחד אולי כבר משוכפל בצד השני.
מה האפשרות משאירה ללא שינוי
היא לא מצפינה תעבורת יישומים. tls-auth שם HMAC סביב חבילות ערוץ הבקרה, בעוד שערוץ הנתונים מוגן במפתחות סשן שנדונים במחיאת היד, ולכן שאלת תפוקה או צופן לא קשורה למספר הכיוון. ההגדרה גם לא מוסיפה שכבה שנייה של הצפנה, וזו ההנחה ששולחת אנשים לחפש מפתח ארוך יותר.
היא לא חלה על tls-crypt, מנגנון אחר לערוץ בקרה עם אפשרויות וטיפול מפתחות משלו, והיא לא אומרת דבר על זהות התעודה של אף עמית. לכן התאמת כיוון שעובדת רק מוכיחה ששני הקצוות מסכימים כיצד לאמת את ערוץ הבקרה, ולא ששרשרת האמון אומתה.
יישרו את הזוג ואז התחברו מחדש
השוו את שתי התצורות לפני שאתם משנים אחת מהן, כי עריכת הצד שכבר היה נכון מכפילה את העבודה. ה-grep שלמטה מראה איזה מנגנון כל קובץ בוחר; הריצה המפורטת מראה אם ערוץ הבקרה אומת בכלל. שמרו את שני הפלטים, כדי שאפשר יהיה להשוות את השינוי הבא למצב ידוע.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
הפעילו מחדש את שני העמיתים אחרי כל שינוי, כי האפשרויות האלה נקראות פעם אחת בהפעלה, וטעינה מחדש של צד אחד משאירה את הזוג לא עקבי לכל חיי הסשן הישן. אם הפריסה עובדת כרגע בלי כיוון מוגדר, הוספת ההגדרה בעמית אחד משחזרת את הכשל שהתחלתם בו; או שתשאירו את שניהם או שתגדירו את שניהם. שנו קצה אחד בכל פעם ושמרו את הקובץ הקודם, כדי שנסיגה תהיה חזרה של שתי דקות ולא בנייה מחדש.
תעדו את המנגנון, קובץ המפתח והכיוון לכל קצה בהערות הפריסה, כי אחרת האדם הבא יקרא שני קבצים דומים ויניח שהמספרים אמורים להתאים זה לזה. הכיוון הוא פרט תיאום, לא שדרוג אבטחה: הוא מפריד בין שני הכיוונים של ערוץ הבקרה ולא עושה דבר אחר.