כיצד OpenVPN data-ciphers בוחר את צופן ערוץ הנתונים

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

שני ערוצים, שתי תצורות

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

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

שמרו את שלושת הדברים בקופסאות נפרדות כשאתם קוראים קובץ תצורה.

קראו את המשא ומתן מהיומן

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

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

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

איך הבחירה באמת מתרחשת

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

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

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

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

עמיתים ותיקים זקוקים לגיבוי מכוון

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

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

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

שמרו על האימות שלם

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

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

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

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