VPN אנדרואיד ל-Cisco IOS: החוזה שצריך להשיג קודם

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

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

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

בצעו את איסוף המידע לפני שמתקינים משהו

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

1. שם המארח או הכתובת של השער שאליו הלקוח צריך לחייג, והאם הוא נגיש מבחוץ.
2. הפרוטוקול והגרסה: IKEv2, דור אחר של IPsec, או שירות מבוסס TLS.
3. זהות העמית שהשער מצפה לה, ומה הוא עצמו מציג בחזרה.
4. חומר אמון: איזו CA חותמת על תעודת השער, או האם משתמשים במפתח משותף מראש.
5. אימות משתמש: תעודה, שם משתמש וסיסמה של EAP, או מפתח משותף מראש.
6. מאגר הכתובות שאליו נוחת הלקוח, עם מסכה ושער.
7. שרתי DNS לשימוש בתוך המנהרה, והאם הלקוח חייב לקבל אותם.
8. קידומות יעד מותרות, והאם יש לחסום תעבורה מחוץ להן.
9. גרסאות הלקוח הנתמכות וגרסאות מערכת ההפעלה של הטלפון, וכן כל דרישת רישום.

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

שם הספק אינו פרוטוקול

Cisco IOS ו-IOS XE מציעים כמה סידורי גישה מרחוק, והם אינם חולקים פורמט העברה אחד. IKEv2 עם פרופיל בסגנון FlexVPN אינו אותו שירות כמו תצורת IKEv1 ישנה יותר, ושירות לקוח מבוסס TLS הוא מוצר אחר שוב, לעתים קרובות בפלטפורמה אחרת באותו סביבה.

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

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

מה חבילת הליבה של אנדרואיד מכסה

אנדרואיד חושף פרופיל IKEv2/IPsec של הפלטפורמה דרך Ikev2VpnProfile, עם סוגי אימות נפרדים למפתח משותף מראש, לתעודת RSA ולשם משתמש וסיסמה של EAP. המדריך של Ikev2VpnProfile הוא הסמכות לגבי מה הבונה מקבל, כולל שם המארח של השער וה-CA השורש של השרת שמשמש לאימותו.

ה-API הזה הוא הצהרת יכולת, לא הבטחת תאימות. הוא אומר שהפלטפורמה יודעת IKEv2 עם סוגי האימות האלה. הוא לא אומר שמסך הגדרות של OEM מסוים חושף כל שדה, ולא שקובץ פרופיל שיוצא ממוצר אחר ייובא.

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

בדקו לפי הסדר שבו החוזה נכתב

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

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

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

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

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

מצבי כשל והחזרה לאחור

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

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