האם ממשק WAN אחד יכול לשרת גם VPN בין אתרים וגם גישה מרחוק?

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

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

שתי רשומות לפני כל תצורה

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

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

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

היכן התאמת העמיתים והאימות נפרדים

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

פרופיל הסניף מתאים בדרך כלל לזהות צרה: כתובת מרוחקת, FQDN או נושא תעודה. משהו כמו match identity remote address 198.51.100.10 255.255.255.255 נועל עמית אחד, ו-authentication remote pre-share עם מפתח שנשמר לכל אתר מספיק. שמרו על ההתאמה ספציפית ככל שמלאי העמיתים מאפשר, מפני שתו-כוכב חופף גבוה יותר בסדר הבחירה יכול למשוך תעבורת סניף לפרופיל הלא נכון.

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

העברה ותרגום זקוקים לאותה הפרדה

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

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

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

מקרי קבלה שחושפים מדיניות מוצלבת

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

אחר כך אמתו את מישור הנתונים ולא את התצורה. show crypto ikev2 sa ו-show crypto ipsec sa אומרים איזה פרופיל ואילו בוררים נשאו כל זרם, בעוד show ip nat translations ומוני המנהרה מראים אם נתיב החזור והפטור אכן התאימו. tracer או לכידת מנות על ממשק המנהרה סוגרים את הלולאה.

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