‏iOS IKEv2 אל strongSwan: לא נבחרה הצעה, תקנו את הרשימה

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

היכן השער מצהיר על המדיניות שלו

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

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

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

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

שני תרגומים תופסים אנשים שמעבירים ערכים מ-strongSwan ל-iOS. אלגוריתם האימות שנכתב SHA1 בהצעת IKE נוסע בצורתו הקטועה, שאותה iOS מכנה .SHA96. קבוצת Diffie-Hellman שנכתבה modp1024 היא group 2, שאותה iOS מכנה .group2. החלפה ב-SHA-256 או ב-group 14 לא תנהל משא ומתן מול שער שמקבל רק את הצמד הישן. הלקוח חייב לתאר את אותו אלגוריתם, לא אחד חזק יותר.

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

הצעת הילד נכשלת מאוחר יותר וביותר שקט

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

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

השאירו את החבילה הישנה רק כל עוד היא נדרשת

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

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