העברת VPN מ-IOS ל-ASA: לתרגם את ההסכם, לא את הפקודות
מפת הצפנה אינה קבוצת מנהרה ב-ASA. אילו חלקים של ההסכם מועברים, אילו יש לבנות מחדש, ואילו בדיקות מוכיחות שהשירות עובד.
תצורת IOS שמגיעה כאסמכתא להגירה ל-ASA מתארת הסכם עטוף בתחביר של פלטפורמה אחת. כתובות העמיתים, הזהויות והטווחים המוגנים הם ההסכם. טבעת המפתחות, הפרופיל ושרשרת מפות ההצפנה הם הדרך שבה IOS מבטאת אותו, בעוד ASA מבטאת את אותה כוונה דרך קבוצות מנהרה והתכונות שלהן. העתקת החלק השני לעולם אינה עובדת, והעתקת הראשון בלבד משאירה את העבודה חצי גמורה.
עברו על חמשת השלבים שלהלן לפי הסדר, ועצרו בכל מקום שבו שתי הפלטפורמות מתארות דברים שונים ולא מילים שונות.
שלב 1: הפרידו את ההסכם מהתחביר
כתבו את המסירה כדרישות ששני המנהלים מסכימים עליהן. ארבע שורות מכסות כמעט הכול: היכן העמית ואיזה צד יוזם, כיצד כל צד מוכיח את זהותו, איזו הגנה מקובלת, ואילו יישומים חייבים לשרוד דרך המנהרה. אף אחת מהשורות הללו אינה מזכירה פקודה.
שמרו את הטקסט המקורי כראיה ולא כהוראות. שורה שקיימת בפלטפורמה אחת ולא בשנייה היא הבדל תחבירי עד שבדקתם אם אפשר למלא את אותה דרישה בדרך אחרת.
| Requirement | What must be agreed |
|---|---|
| Peer delivery | Outer endpoint, address family, NAT view, initiating side |
| Authentication | IKE version, expected identities, credential method and delivery |
| Data protection | Permitted suites, protected ranges, intentional translation |
| Application | Routes, return routes, resources beyond the tunnel |
שלב 2: תנו שמות לאובייקטים בכל פלטפורמה
ב-IOS XE טבעת מפתחות IKEv2 מזינה פרופיל IKEv2, והפרופיל הזה מחובר דרך מפת הצפנה או פרופיל IPsec. ב-ASA קבוצת מנהרה מחזיקה את פרופיל החיבור ואת תכונות ה-IPsec שלו, ומפת ההצפנה מצביעה עליו, כפי שמתארת מדריך פרופיל החיבור. אלו גרפי אובייקטים שונים עם ירושה שונה, ולכן מיפוי שורה אחר שורה מפיק תצורה שנפרסת ואינה מתחברת.
בנו את אובייקטי היעד משורות הדרישות ולא משורות המקור. אם השורות שלמות, תצורת היעד היא החלטת תכנון. אם לא, שום כמות של תרגום פקודות לא תספק את הכוונה החסרה.
שלב 3: העבירו זהות, לא רק כתובות
זהות היא החלק שנשבר בשקט. עמית שמאמת לפי כתובת מתנהג אחרת מזה שמאמת לפי נושא תעודה או FQDN, ושתי הפלטפורמות רושמות את הציפייה הזו במקומות שונים. שמרו על הזהות המיועדת ועל שרשרת האמון במקום להחליף סוד משותף מפני שקל יותר לבדוק אותו.
הרחיקו את הסוד המשותף מראש מהערות השוואה ומכרטיסים. רשמו מי הבעלים שלו וכיצד הוא עובר בערוץ מאושר, וזכרו שממלא מקום מדוגמה בתיעוד אינו אישור הגישה של הלקוח.
שלב 4: סכמו על ההגנה לפני המעבר
אל תעבירו הגדרות הצפנה ישנות רק מפני שהן מופיעות בטקסט שסופק. סכמו על חיתוך של חבילות ששני העמיתים הפרוסים תומכים בהן כעת, ואשרו אותו עם המנהל האחר לפני חלון השינוי. אם החיתוך הזה שונה ממה שהעמית הקיים מצפה לו, זהו שינוי מתואם ולא עריכה מקומית.
רשמו את הקבוצה המוסכמת. שני מנהלים עם זיכרונות שונים משיחת טלפון הם הדרך שבה מעבר מייצר אי-התאמה בשלב השני.
שלב 5: אמתו את השירות, לא את התחביר
בדקו תחילה את האובייקטים האפקטיביים של היעד, אחר כך את האגודה שהתקבלה, אחר כך זרימת יישום אמיתית ואת תגובתה. הזנת פקודה בלי שגיאה מוכיחה תחביר ושום דבר אחר. מנהרה שעולה ואינה נושאת תעבורה פירושה בדרך כלל שהטווחים המוגנים או נתיב החזרה אינם תואמים לצד השני, וזו בעיה של שורת דרישות ולא של פקודה. השוו את הטווחים המוגנים בשני הצדדים לפני שתגעו שוב במפת ההצפנה.
רשמו מה אימתם, עם אילו כתובות, מאיזה צד. הרישום הזה הופך טענה מעורפלת שה-VPN פועל למשהו שהמנהל האחר יכול לבדוק באופן עצמאי.
מה להחזיר
שלחו את מטריצת הדרישות, סיכום של תצורת היעד ותוצאות האימות. ציינו במפורש אילו הגדרות מקור לא העברתם ולמה. הרשימה הזו שימושית יותר מהתצורה המתורגמת, כי שם יתחיל אי-ההסכמה הבא.
שמרו גם את טקסט המקור עם הכרטיס. הוא מתעד מה נתבקש, בעוד המטריצה מתעדת מה סוכם.