iPhone IKEv2 מול RouterOS: איזה מזהה הולך לאן
ארבע טענות נפרדות קובעות מנהרת IKEv2 ב-iOS: הכתובת המחויגת, זהות השרת המצופה, זהות הלקוח הנטענת וחומרי האישור.
ההגעה אל שער MikroTik פותרת רק את חצי התעבורה של פריסת IKEv2 ולא דבר אחר. לאחר מכן ארבע טענות נפרדות קובעות אם המנהרה תיווצר: הכתובת שהטלפון מחייג אליה, זהות השרת שהוא מצפה לה, הזהות שהוא תובע לעצמו, וחומרי האישור שתומכים בטענה הזו. בדקו אותן בסדר הזה, ועצרו בראשונה שאינה תואמת את מה שהשער מציג. כל אחת נערכת במקום אחר, ולכן עריכה שגויה בדרך כלל מזיזה את התקלה במקום לתקן אותה.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
בדקו את שדות הפרופיל לפי הסדר שבו ההחלפה משתמשת בהם
הכתובת המרוחקת היא היעד של חבילת ה-IKE הראשונה ולא יותר. המזהה המרוחק הוא מה שהטלפון מצפה שהשער יוכיח שהוא, והוא שם, לא מסלול. מילוי שניהם באותו שם מארח עובד כאשר אישור השער נושא את השם הזה, ונכשל באופן שנראה כמו בעיית ניתוב כאשר הוא אינו נושא אותו. קראו את הפרופיל כרצף טענות ולא כרשימת שדות למילוי.
המזהה המקומי הוא הטענה של הטלפון עצמו, והוא חייב להיות שם שרישומת הזהות של RouterOS מקבלת עבור אישור הלקוח שהטלפון מציג. אם השניים אינם תואמים, השער דוחה את החיבור לאחר שהאישור עצמו אומת, והיומן נראה כמו בעיית הרשאה ולא בעיית שמות.
בדקו את המזהים מול מה שהשער מציג
רישומת עמית ב-RouterOS שהוגדרה לאימות באישור מציגה את האישור של עצמה, והזהות שלה נגזרת מאותו אישור אלא אם הגדרתם אחרת. אם המזהה המרוחק של הטלפון מציין את שם ה-DNS של השער, אישור השער צריך את השם הזה במקום שהטלפון יקבל, בדרך כלל בשם חלופי של הנושא. אישור שהונפק עבור שם נפוץ אחר לא יאומת גם אם המפתח והשרשרת מושלמים.
פרופילי Apple מנוהלים יכולים לשאת גם הגבלת שם אישור שנאמדת בנוסף לשדות המזהה. בדקו את המטען במקום להסיק את שם האימות ממה שמסך ההגדרות מציג, מפני שאלה אינן אותה הגדרה.
בדקו שאישור הלקוח הוא מפתח, לא רק עוגן אמון
ייבוא אישור CA נותן לטלפון משהו שדרכו יאמת את השער. הוא אינו נותן לטלפון זהות לקוח, ואימות באישור דורש את אישור העלה של הלקוח ואת המפתח הפרטי שלו, מסופקים יחד בנתיב ההרשמה המאושר. PKCS#12 שנבנה בלי המפתח הפרטי מפיק פרופיל שמתקין בצורה נקייה ואינו מאמת דבר.
גם עלה הלקוח צריך זהות שהצד של RouterOS מצפה לה, כלומר הנושא או השם החלופי של הנושא חייבים להתאים לתצורת הזהות המתאימה. הנפקת אישורי לקוח ושרת מאותה CA הופכת את השרשרת נוחה ואינה הופכת את שני העלים לברי החלפה.
בדקו שמדיניות RouterOS מקבלת את השם הזה
בשער, רישומת העמית קובעת את מצב ההחלפה ואת שיטת האימות, ורישומת הזהות קושרת את הזהות המרוחקת המתקבלת לאישור ולמדיניות שאחריה. ב-RouterOS v7 הצמד הזה מובע דרך רישומות העמית והזהות של IPsec, למשל עמית IKEv2 עם auth-method=digital-signature. בדקו את תוכן התפריט בפועל בגרסה המותקנת ולא מדריך שנכתב לגרסה ישנה יותר.
כאן גם הזול ביותר לתקן אי-התאמה, מפני שהשער יכול לומר לכם גם את הזהות שקיבל וגם את הזהות שרצה. הרחבת הזהות המתקבלת כדי להשתיק את השגיאה מסירה את הקישור שנתן לפריסה משמעות.
בדקו איזה שלב נכשל לפני שתערכו משהו
קראו את הניסיון בשני הקצוות וסווגו אותו לפני שתשנו הצעה. אי-התאמת הצעה, מפתח חתימה חסר, מנפיק לא מהימן, מזהה עמית שגוי והרשאת לקוח נדחית נראים כולם מנקודת המבט של הטלפון כמנהרה מתה, ולכל אחד אחראי אחר. שינוי כל חמש ההגדרות בבת אחת מבטיח שלא תלמדו דבר מהתוצאה.
תעדו את הזהות שהוצגה, הזהות המצופה, מנפיק האישור ומספרו הסידורי ואת שם המדיניות הרלוונטית, תוך שמירת מפתחות פרטיים וסודות פרופיל מחוץ לתיעוד הזה. לאחר שהאימות יצליח, בדקו שירות פרטי ואת תגובתו, מפני שהקצאת כתובות, בוררים, DNS ומדיניות גישה עדיין חייבים לעבוד לאחר שהחלפת ה-IKE מסתיימת.