‏iOS דחה את מנהרת strongSwan שלך: השוו את הצעות ה-IKE

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

שורת היומן שמכריעה

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

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

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

מה השתנה בטלפון

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

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

צמד אחד שעדיין מצליח לנהל משא ומתן

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

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

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

שלושה מקומות לתקן, אחד בדרך כלל סגור

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

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

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

הוכיחו את זה, ואז תעדו את זה

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

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