שגיאת אמון ב-IKEv2 באנדרואיד: שלחו את ה-CA הביניים, לא שורש
הטלפון דוחה את השער כי השרשרת שהתקבלה נגמרת מוקדם. החליטו: שלחו את הביניים, תקנו את הזהות או שנו את סוג המפתח.
הטלפון מסרב להתחבר ומדפיס No trusted RSA public key found for vpn.example.net, בעוד שאותו אישור שער עובד ממחשב נייד באותה רשת. הצעד המפתה הוא להנפיק את האישור מחדש. לפני כן, גלו איזו משלוש התקלות יש לכם, כי רק אחת מהן עוסקת בתוכן האישור.
שלוש תקלות מאחורי הודעה אחת
אנדרואיד בונה שרשרת מאישור השער עד ה-CA שנבחר בפרופיל ה-VPN, ואז משווה את שם השרת לפרופיל. ההודעה מדווחת על התוצאה, לא על השלב. תקלת אמון משמעה שהשרשרת לא הושלמה עם האישורים שנמסרו בהחלפה; תקלת זהות משמעה שהשרשרת תקפה אך השם אינו תואם; תקלת אלגוריתם משמעה שהמכשיר או הפרופיל אינם מקבלים את סוג המפתח או החתימה.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
החליטו על סמך ראיות במקום לנסות תיקונים לפי סדר. ניסיון אחד ברמת יומן 2 על הדמון אומר לכם באיזו שורה אתם נמצאים, והוא עולה פחות מהנפקה מחדש של אישור שמעולם לא היה שגוי.
החליטו קודם: האם הגיעה השרשרת כולה?
strongSwan שולח את האישור שהוגדר לאותו חיבור, ואישורי ביניים הם אישורי נפרדים. יש לטעון אותם כאישורי CA לפני שהדמון יכול להציבם במטען, ולכן פריסה שבה אישור השרת חתום בידי ביניים, השורש הוא עוגן האמון והביניים חי רק בתיקיית הבנייה של ה-CA מייצרת בדיוק את התקלה הזו: רק העלה על החוט והשרשרת נגמרת מוקדם בטלפון.
בדקו מה מחזיק הדמון עם swanctl --list-certs בפריסת swanctl, או ipsec listcerts עם ה-starter הישן. הביניים אמור להופיע כאישור CA עם השורש מעליו. אם הוא חסר, שום אפשרות לקוח לא תעזור; אם הוא קיים, עברו לשאלה הבאה.
לאחר מכן בדקו אם הוא יישלח. התיעוד של swanctl.conf מתאר את send_cert, שברירת המחדל שלו ifasked שולחת אישורים רק כשהצד השני ביקש, בעוד always שולח תמיד. המקבילה הישנה היא leftsendcert=always ב-ipsec.conf. ההגדרה שולטת בשליחה, לא בזמינות, ולכן אינה מפצה על ביניים שהדמון מעולם לא טען.
אם השרשרת קצרה, טענו את הביניים במקום שבו הדמון מחפש
שימו את הביניים בתיקיית ה-CA ולא לצד העלה: /etc/ipsec.d/cacerts לפריסה עם ipsec.conf, /etc/swanctl/x509ca ל-swanctl, או הנתיב שהחבילה שלכם מחליפה. טענו מחדש את התצורה ורשמו שוב את האישורים. גרסאות מסוימות שולחות גם צרור שמכיל את השרשרת בתוך קובץ העלה, אבל תיקיית ה-CA היא הסידור הנייד בין גרסאות לחבילות.
בדקו גם מצד הלקוח. הטלפון רואה רק את מה שההחלפה נשאה, ולכן יומן הדמון ברמה 2 אמור להראות את הביניים בין האישורים שנשלחו. אם היומן מראה אותו והטלפון עדיין נכשל, אתם בשורה אחרת בטבלה, וכיוונון קבצי CA לא ישנה את התוצאה.
אם השרשרת שלמה, הפסיקו לערוך אישורים
תקלת זהות היא אי-התאמה בין השם בפרופיל ה-VPN לשם באישור. אנדרואיד משווה את זהות השרת שהגדרתם לאישור שאימת, ולכן פרופיל שמצביע על כתובת בזמן שהאישור נוקב בשם מארח, או פרופיל עם שם מארח שהאישור אינו מכסה, נכשל לאחר אימות שרשרת מוצלח. תקנו את הצד השגוי ושמרו על התאמה בין הפרופיל לאישור.
תקלת אלגוריתם מופיעה עם שרשרת תקפה ושם תואם. גרסאות אנדרואיד נבדלות בסוגי המפתחות ובסכמות החתימה שהן מקבלות, וסוג הפרופיל עצמו מגביל את האפשרויות. אם השער משתמש בשילוב ישן או חריג, השוו אותו למה שהמכשיר תומך בו לפני שאתם מניחים שהאישור פגום. היומן יראה שהלחיצה מתקדמת יותר מאשר במקרה האמון, וזה הסימן שהשרשרת אינה הבעיה עוד.
אל תתקינו את הביניים כשורש משתמש בטלפון
התקנת הביניים החסר כאישור משתמש בטלפון מעלימה את האזהרה ומשנה את מודל האמון של הטלפון לכל אפליקציה שמקבלת שורשים שהותקנו בידי המשתמש. היא גם מסתירה פגם אספקה שיפגע בלקוח הבא, ומשאירה את השער שולח שרשרת חלקית לכל מכשיר עתידי. התיקון העמיד הוא בשרת, פעם אחת, לכל הלקוחות.
שמרו את שלוש ההחלטות בנפרד ביומן השינויים: אילו אישורים הועברו, איזו זהות הושוותה ואיזה אלגוריתם סוכם. שער שתמיד שולח את שרשרתו המלאה, פרופיל שמכנה את האישור נכון וסוג מפתח שהצי תומך בו הם שלוש עובדות קטנות, והן כל התקלה הזאת.