- בית
- /
- מאמר
תודה על המשוב.
מופע ייעודי-חיבור וירטואלי
במאמר זה
משוב?חיבור וירטואלי הוא אפשרות תוספת נוספת לקישוריות ענן למופע ייעודי Webex Calling. Virtual Connect מאפשר ללקוחות להרחיב באופן מאובטח את הרשת הפרטית שלהם דרך האינטרנט באמצעות מנהרות VPN IP מנקודה לנקודה. כאן אנו דנים בהזמנה, הפעלה ותצורה של Virtual Connect.
מבוא
Virtual Connect הוא אפשרות תוספת נוספת לקישוריות ענן למופע ייעודי עבור Webex Calling (מופע ייעודי). Virtual Connect מאפשר ללקוחות להרחיב באופן מאובטח את הרשת הפרטית שלהם דרך האינטרנט באמצעות מנהרות VPN IP מנקודה לנקודה. אפשרות קישוריות זו מספקת הקמה מהירה של חיבור רשת פרטית באמצעות ציוד מקומי הלקוח הקיים (CPE) וקישוריות לאינטרנט.
Cisco מארחת, מנהלת ומבטיחה מנהרות IP VPN מיותרות וגישה לאינטרנט הנדרשת באזור/ים של מרכז הנתונים הייעודי של Cisco שבהם השירות נדרש. באופן דומה, מנהל המערכת אחראי על שירותי ה- CPE והאינטרנט המתאימים להם הנדרשים להקמת Virtual Connect.
כל סדר חיבור וירטואלי באזור מופע ייעודי מסוים יכלול שתי מנהרות אנקפסולציה ניתוב גנריות (GRE) המוגנות באמצעות הצפנת IPsec (GRE over IPsec), אחת לכל מרכז הנתונים של סיסקו באזור שנבחר.
ל-Virtual Connect יש מגבלת רוחב פס של 250 Mbps למנהרה ומומלץ לפריסות קטנות יותר. מכיוון שמשתמשים בשתי מנהרות VPN מנקודה לנקודה, כל התעבורה לענן צריכה לעבור דרך CPE של הלקוח, ולכן יתכן שהיא לא מתאימה במקום שיש הרבה אתרים מרוחקים. לקבלת אפשרויות מימוד חלופיות אחרות, עיין בקי שוריות ענן.
לפני שתשלח את בקשת הצימוד עבור Virtual Connect, ודא ששירות המופע הייעודי מופעל באזור המתאים.
תנאים מוקדמים
התנאים המוקדמים להקמת חיבור וירטואלי כוללים:
-
הלקוח מספק
-
חיבור לאינטרנט עם רוחב פס זמין מספיק כדי לתמוך בפריסה
-
כתובות IP ציבוריות לשתי מנהרות IPsec
-
כתובות IP הובלה GRE בצד הלקוח עבור שתי מנהרות GRE
-
-
שותף ולקוח
-
עבדו יחד כדי להעריך את דרישות רוחב הפס
-
ודא שהתקני רשת תומכים בניתוב פרוטוקול שער גבול (BGP) ובתכנון מנהרת GRE באמצעות IPsec
-
-
שותף או לקוח מספק
-
צוות רשת עם ידע בטכנולוגיות מנהרות VPN מאתר לאתר
-
צוות רשת עם ידע ב- BGP, EBGP ועקרונות ניתוב כלליים
-
-
Cisco
-
סיסקו הקצה מספרי מערכת אוטונומיים פרטיים (ASNs) וכתובת IP חולפת לממשקי מנהרת GRE
-
סיסקו הקצתה רשת ציבורית אך לא ניתנת לניתוב אינטרנט מסוג Class C (/24) לכתובת ענן ייעודית
-
אם ללקוח יש מכשיר CPE אחד בלבד, אז שתי המנהרות לכיוון מרכזי הנתונים של סיסקו (DC1 ו- DC2) בכל אזור, יהיו מאותו מכשיר CPE. ללקוח יש גם אפשרות לשני התקני CPE, ואז כל התקן CPE צריך להתחבר למנהרה אחת בלבד לכיוון מרכזי הנתונים של סיסקו (DC1 ו- DC2) בכל אזור. ניתן להשיג יתירות נוספת על ידי סיום כל מנהרה באתר/מיקום פיזי נפרד בתשתית הלקוח.
פרטים טכניים
מודל פריסה
Virtual Connect משתמש בארכיטקטורת ראשי שכבה כפולה, שבה מישורי הניתוב והבקרה של GRE מסופקים על ידי התקן אחד ומישור הבקרה IPsec מסופק על ידי מכשיר אחר.
עם השלמת הקישוריות Virtual Connect, ייווצרו שתי מנהרות GRE באמצעות IPsec בין הרשת הארגונית של הלקוח לבין מרכזי הנתונים של Cisco Instance הייעודי. אחד לכל מרכז נתונים מיותר באזור המתאים. רכיבי רשת נוספים הנדרשים לצורך הפירינג מוחלפים על ידי השו תף או הלקוח לסיסקו באמצעות טופס ההפעלה של Control Hub Virtual Connect.
האיור שלהלן מציג את הדוגמה למודל פריסת החיבור הווירטואלי עבור אפשרות 2-ריכוז בצד הלקוח.
חיבור וירטואלי - VPN הוא עיצוב רכזת, שבו אתרי הרכזת של הלקוח מחוברים ל- DC1 ו- DC2 של מרכזי הנתונים של מופע ייעודי באזור מסוים.
שני אתרי רכזת מומלצים ליתירות טובה יותר, אך אתר One Hub עם שתי מנהרות הוא גם מודל פריסה נתמך.
רוחב הפס לכל מנהרה מוגבל ל -250 Mbps. כדי להבטיח מעבר יעיל של כשל, התנועה המשולבת בשתי המנהרות לא תעלה על 250 Mbps, מכיוון שכל התעבורה תועבר דרך מנהרה אחת במקרה של תקלה.
האתרים המרוחקים של הלקוח באותו אזור יצטרכו להתחבר בחזרה לאתרי הרכ זת דרך ה-WAN של הלקוח ואין זו אחריותה של סיסקו לקיש וריות זו.
השותפים צפויים לעבוד בשיתוף פעולה הדוק עם הלקוחות, ולהבטיח שנבחר הנתיב האופטימלי ביותר עבור אזור השירות Virtual Connect.
האיור שלהלן מציג את אזורי הצימוד לקישוריות בענן של מופע ייעודי.
ניתוב
תוסף ניתוב עבור חיבור וירטואלי מיושם באמצעות BGP חיצוני (eBGP) בין מופע ייעודי לציוד הנחת הלקוח (CPE). סיסקו תפרסם את הרשת המתאימה שלה עבור כל DC מיותר באזור ל-CPE של הלקוח וה-CPE נדרש לפרסם מסלול ברירת מחדל לסיסקו.
-
סיסקו מתחזקת ומקצה
-
כתובת IP של ממשק מנהרה (קישור חולף לניתוב) סיסקו מקצה ממרחב כתובות משותף ייעודי (לא ניתן לניתוב ציבורי)
-
כתובת חלוקת תחבורה במנהרות (הצד של סיסקו)
-
מספרי מערכת אוטונומיים פרטיים (ASNs) לתצורת ניתוב BGP של הלקוח
-
סיסקו מקצה מטווח השימוש הפרטי המיועד: 64512 עד 65534
-
-
-
EBGP משמש להחלפת נתיבים בין מופע ייעודי ל- CPE
-
סיסקו תחלק את רשת /24 שהוקצתה ל- 2/25 אחת עבור כל DC באזור המתאים
-
ב- Virtual Connect כל רשת /25 מפורסמת בחזרה ל- CPE על ידי סיסקו דרך מנהרות ה- VPN הנקודה לנקודה המתאימות (קישור חולף)
-
יש להגדיר את CPE עם שכני EBGP המתאימים. אם משתמשים ב- CPE אחד, ישמשו שני שכנים EBGP, אחד מצביע על כל מנהרה מרוחקת. אם אתה משתמש בשני CPE, אז לכל CPE יהיה שכן EBGP אחד המתמקד במנהרה המרוחקת היחידה עבור ה- CPE.
-
צד סיסקו של כל מנהרת GRE (IP ממשק מנהרה) מוגדר כשכן BGP ב- CPE
-
CPE נדרש לפרסם מסלול ברירת מחדל מעל כל אחת מהמנהרות
-
CPE אחראי לחלוקה מחדש, כנדרש, של המסלולים הנלמדים ברשת הארגונית של הלקוח.
-
-
במצב של כשל בקישור ללא כשל, ל-CPE בודד יהיו שתי מנהרות פעילות/פעילות. עבור שני צמתים CPE, לכל CPE תהיה מנהרה פעילה אחת ושני צמתים CPE צריכים להיות פעילים ועוברים תנועה. בתרחיש אי-כשל, התנועה חייבת להתפצל לשתי מנהרות המגיעות ליעדים הנכונים/25, אם אחת המנהרה יורדת, המנהרה שנותרה יכולה לשאת את התנועה לשניהם. בתרחיש כשל כזה, כאשר רשת /25 מושבתת אז רשת /24 משמשת כמסלול גיבוי. סיסקו תשלח תעבורת לקוחות באמצעות ה- WAN הפנימי שלה לכיוון DC שאיבד את הקישוריות.
זרימת תנועה לחיבור וירטואלי
זרימת התנועה כששתי המנהרות למעלה
תמונה זו ממחישה ארכיטקטורת רשת Virtual Connect, המפרטת את זרימת התנועה כאשר הן מנהרות ראשוניות והן משניות פועלות.
הוא מייצג מודל קישוריות פעיל עבור לקוח לגישה ליישומי UC המתארחים במרכזי הנתונים של סיסקו, ומנף מנהרות GRE/IPSEC כפולות דרך האינטרנט עם BGP להחלפת מסלולים.
הגדרות:
- הנחת הלקוח:
- זה מייצג את הרשת באתר הלקוח, שבה נמצאים המשתמשים והמכשירים שלהם (למשל, טלפוני IP, מחשבים המפעילים לקוחות UC).
- תנועה שמקורה מכאן צריכה להגיע ליישומי UC המתארחים במרכזי הנתונים של סיסקו .
- Cisco Webex Callingמרכזי נתונים של מופעים ייעודיים (מופע ייעודי) (WXC-Di DC-
A ו-WXC-Di DC-B):
- אלה מרכזי הנתונים של סיסקו המארחים את יישומי UC.
- DC-A ו- DC-B נבדלים מבחינה גיאוגרפית, ומ ספקים יתירות.
- לכל מרכז נתונים יש רשת משנה משלו ליישומי UC:
- רשת משנה DC-A: X.X.X.0/25
- רשת משנה DC-B: X.X.X.128/25
- מנהרות GRE/IPsec (מנהרה 1 ומנהרה 2):
- אלה הם החיבורים המאובטחים והמוצפנים בין הנ חת הלקוח למרכז הנתונים של סיסקו דרך האינטרנט הציבורי.
- GRE (אנקפסולציה ניתוב גנרית): פרוטוקול זה משמש לאנקפסולציה של פרוטוקולי שכבת רשת שונים בתוך קישורים וירטואליים מנקודה לנקודה. זה מאפשר פרוטוקולי ניתוב כמו BGP לפעול מעל המנהרה.
- IPsec (אבטחת פרוטוקול אינטרנט): חבילת פרוטוקולים זו מספקת שירותי אבטחה קריפטוגרפיים (אימות, שלמות, סודיות) לתקשורת IP . הוא מצפין את התעבורה המצורפת GRE-ומבטיח העברת נתונים מאובטחת דרך האינטרנט.
- פרוטוקול שער הגבול (BGP):
- BGP הוא פרוטוקול הניתוב המשמש להחלפת מידע ניתוב בין הנחת הלקוח למרכזי הנתונים של סיסקו.
כפי שמוצג בתרשים לעיל, התקנים הפרוסים בחצרים של הלקוח צריכים להקים שתי מנהרות GRE/IPSEC.
מוסכמות השמות המשמשות להלן עם XX/YY, DC-A DC-B הן כלליות לכל האזורים שבהם מוצע מופע יי עודי. ערכים אלה יהיו ייחודיים לכל אזור והע רכים בפועל עבור כל אזור. הערכים הספציפיים מסופקים במהלך הפעלת החיבור הווירטואלי.
בצד סיסקו מנהרות ה- IPsec ו- GRE יוסמו במכשירים שונים. לכן הלקוח צריך לוודא להגדיר כתובות IP של יעד IPsec ו- GRE במ כשירים בהתאם. לקוחות יכולים להשתמש באותו IP עבור GRE ו- IPSEC אם הוא נתמך במכשירים שלהם. עיין בתרשים שלמעלה. הערכים הקשורים ל- IP מסופקים במהלך הפעלת החיבור הווירטואלי בפורטל.
- מנהרה 1: מחבר את הנחת הלקוח ל"מופע ייעודי DC-A" (מרכז נתונים A) באמצעות האינטרנט. מנהרה זו משתמשת ב- BGP AS: 64XX1 בצד הלקוח וב- BGP AS: 64XX2 בצד המופע הייעודי DC-A. תצורות מקור מנהרות IPSEC ו- GRE מחולקות בין פרטים המסופקים על ידי הלקוח לבין פרטים המסופקים על ידי Cisco.
- מנהרה 2: מחבר את הנחת הלקוח ל"מופע ייעודי DC-B "(מרכז נתונים B) באמצעות האינטרנט. מנהרה זו משתמשת ב- BGP AS: 64YY1 בצד הלקוח וב- BGP AS: 64YY2 בצד המופע הייעודי DC-B. בדומה למנהרה 1, תצורות מקור מנהרות IPSEC ו- GRE משותפות בין הלקוח לסיסקו.
ב- BGP AS: 64XX ו- BGP AS: 64YY, XX ו- YY ספציפיים לאזור מסוים.
לאחר הקמת מנהרות GRE/IPSEC למרכזי נתונים של מופעים Webex Calling ייעודיים (A ו- B), הלקוח צריך לקבל את המסלולים הבאים המפורסמים מסיסקו במהלך הפעלות ה- BGP המת אימות.
- עבור DC-A: מסלולים המפורסמים מסיסקו יהיו X.X.0/25 ו- X.X.0/24. לחלופין, אם IaaS מתבקש ומוגדר עבור נתיבי הלקוחות, YY.Y.0/25 ו- YYY.0/24 יפורסמו מסיסקו.
- עבור DC-B: מסלולים המפורסמים מסיסקו יהיו X.X.128/25 ו- X.X.X.0/24. לחלופין, אם IaaS מתבקש ומוגדר עבור נתיבי הלקוחות, YY.Y.128/25 ו- YYY.0/24 יפורסמו מסיסקו.
- הלקוח צריך לפרסם את המסלול 0.0.0./0 לסיסקו דרך שני החיבורים (מנהרות)
- הלקוח צריך לעקוב אחר מסלולי הקידומת הארוכים ביותר (/25) כדי לשלוח תנועה לסיסקו דרך המנהרות המתאימות כאשר שתי המנהרות עומדות.
- סיסקו תחזיר את התנועה דרך אותן מנהרות כדי לשמור על התנועה סימטרית.
זרימת תנועה:
- תנועה המיועדת ל- "DC-A UC Apps" (X.X.0/25) מהנחת הלקוח זורמת דרך מנהרה 1.
- תנועה המיועדת ל- "יישומי DC-B UC" (X.X.128/25) ממתחם הלקוח זורמת דרך מנהרה 2.
תרחיש כישלון: זרימת תנועה כאשר אחת המנהרות מושבתת
כפי שמוצג בתרשים לעיל כאשר המנהרה ל- DC-A נמצאת במורד ה- bgp שהוקם דרך המנהרה ל- DC-A תרד.
השפעה על BGP: כאשר מנהרה 1 יורדת, גם הפעלת ה- BGP מעל המנהרה הזו תרד . כתוצאה מכך, DC-A לא תוכל עוד לפרסם את המסלולים שלה (במיוחד X. X.0/25) ללקוח דרך נתיב זה. מכאן שנתב הלקוח יזהה את הנתיב כ בלתי ניתן להשגה.
כעת מכיוון שמנהרה 1 מושבתת, נתב הלקוח במוקד הלקוח י סיר אוטומטית את המסלולים שנלמדו דרך מנהרה 1 מטבלת הניתוב שלה או יסמן אותם כ בלתי נגישים.
- תנועה המיועדת לרשת האפליקציות של UC (X.X.0/24) או לרשת המשנה DC-A (X.X.0/25) תופנה לאחר מכן דרך מנהרת העבודה לכיוון DC-B שממשיך לפרסם את X.X.0/24 הכוללת את רשת X.X.0/25.
- התנהגות דומה תיראה אם המנהרה ל- DC-B מושבתת בעוד המנהרה ל- DC-A עדיין למעלה.
תהליך קישוריות
| 1 | |
| 2 | |
| 3 | |
| 4 |
שלב 1: הזמנת CCW
חיבור וירטואלי הוא תוסף עבור מופע ייעודי ב- CCW.
| 1 |
נווט לאתר הזמנת CCW ולאחר מכן לחץ על התחבר כדי להיכנס לאתר: |
| 2 |
צור הערכה. |
| 3 |
הוסף מק"ט "A-FLEX-3". |
| 4 |
בחר באפשרויות עריכה. |
| 5 |
בכרטיסיית המנוי שמופיעה, בחר אפשרויות ותוספות. |
| 6 |
תחת תוספות נוספות, בחר בתיבת הסימון לצד "חיבור וירטואלי למופע ייעודי". שם המק"ט הוא "א-פלקס-די-VC". |
| 7 |
הזן את הכמות ומספר האזורים שבהם נדרש חיבור וירטואלי. כמות החיבור הווירטואלי לא תעלה על המספר הכולל של אזורים שנרכשו עבור מופע ייעודי. כמו כן, רק הזמנת חיבור וירטואלי אחת מותרת לכל אזור. |
| 8 |
כאשר אתה מרוצה מהבחירות שלך, לחץ על אימות ושמור בחלק השמאלי העליון של הדף. |
| 9 |
לחץ על שמור והמשך כדי לסיים את ההזמנה שלך. ההזמנה הסופית שלך מופיעה כעת ברשת ההזמנות. |
שלב 2: הפעלת חיבור וירטואלי במרכז הבקרה
| 1 |
היכנס לרכזת הבקרה https://admin.webex.com/login. |
| 2 |
במקטע שירותים, נווט אל שיחות > הגדרות ייעודיות > קישוריות ענן. |
| 3 |
בכרטיס Virtual Connect, כמות החיבור הווירטואלי שנרכשה מופיעה ברשימה. מנהל המערכת יכול כעת ללחוץ על הפ על כדי להתחיל את הפעלת Virtual Connect. 
תהליך ההפעלה יכול להיות מופעל רק על ידי מנהלי מערכת עם תפקיד "מנהל מלא של לקוח". בעוד שמנהל עם תפקיד "מנהל לקוח לקריאה בלבד" יכול להציג רק את הסטטוס. |
| 4 |
בלחיצה על כפ תור ההפעלה, מוצג טופס הפעל חיבור וירטואלי עבור מנהל המערכת כדי לספק את הפרטים הטכניים של Virtual Connect הנדרשים לתצורות הצימוד בצד של סיסקו. הטופס מספק גם מידע סטטי בצד של סיסקו, בהתבסס על האזור שנבחר. מידע זה יהיה שימושי עבור מנהלי לקוחות כדי להגדיר את ה- CPE בצד שלהם כדי ליצור את הקישוריות. |
| 5 |
לחץ על כפ תור ההפעלה לאחר מילוי כל שדות החובה. |
| 6 |
לאחר השלמת טופס ההפעלה של Virtual Connect עבור אזור מסוים, הלקוח יכול לייצא את טופס ההפעלה מ- Control Hub, התקשרות > מופע ייעודי > הכרטיסייה קישוריות ענן ולחץ על הגדרות ייצוא. 
מסיבות אבטחה, האימות וסיסמת ה- BGP לא יהיו זמינים במסמך המיוצא, אך מנהל המערכת יכול להציג אותם ברכזת בקרה על ידי לחיצה על הצג הגדרות תחת רכזת בקרה, שיחות > מופע ייעודי > הכרטיסייה קישוריות ענן. |
שלב 3: סיסקו מבצעת תצורת רשת
| 1 |
לאחר השלמת טופס ההפעלה של חיבור וירטואלי, הסטטוס יעודכן ל' הפעלה בעיצומה' ב'שיחות > מופע ייעודי > כרטיס חיבור וירטואלי של קישוריות ענן. |
| 2 |
סיסקו תשלים את התצורות הנדרשות בציוד הצד של סיסקו תוך 5 ימי עסקים. בסיום מוצלח, הסטטוס יעודכן ל"מופעל" עבור אותו אזור מסוים ב- Control Hub. |
שלב 4: הלקוח מבצע תצורת רשת
|
הסטטוס משתנה ל- "מופעל" כדי להודיע למנהל הלקוח כי הצד של התצורות של סיסקו עבור קישוריות ה- IP VPN הושלם בהתבסס על התשומות שסיפק הלקוח. עם זאת, מנהל הלקוחות צפוי להשלים את הצד שלהם בתצורות ב- CPEs ולבדוק את נתיבי הקישוריות עבור מנהרת ה- Virtual Connect שתהיה מקוונת. במקרה של בעיות כלשהן בעת התצורה או הקישוריות, הלקוח יכול לפנות Cisco TAC לקבלת סיוע. |
פתרון בעיות
פתרון בעיות ואימות שלב ראשון של IPsec (משא ומתן IKEv2)
המשא ומתן על מנהרת IPsec כולל שני שלבים, שלב IKEv2 ושלב IPsec. אם המשא ומתן על שלב IKEv2 לא הושלם, אין התחלה של שלב IPsec שני. ראשית, הנפיק את הפקודה "הצג crypto ikev2 sa" (בציוד של סיסקו) או פקודה דומה בציוד של צד שלישי כדי לוודא אם הפעלת IKEv2 פעילה. אם הפעלת IKEv2 אינה פעילה, הסיבות האפשריות יכולות להיות:
-
תנועה מעניינת אינה מפעילה את מנהרת ה- IPsec.
-
רשימת הגישה למנהרת IPsec אינה מוגדרת באופן שגוי.
-
אין קישוריות בין הלקוח לבין כתובת ה-IP של נקודת הקצה של מנהרת IPsec של מופע ייעודי.
-
הפרמטרים של הפעלת IKEv2 אינם תואמים בין צד המופע הייעודי לצד הלקוח.
-
חומת אש חוסמת את מנות IKEv2 UDP.
ראשית, בדוק ביומני IPsec אם יש הודעות המציגות את התקדמות המשא ומתן על מנהרת IKEv2. היומנים עשויים לציין היכן יש בעיה במשא ומתן IKEv2. היעדר הודעות רישום עשוי גם להצביע על כך שהפעלת IKEv2 אינה מופעלת.
כמה שגיאות נפוצות במשא ומתן IKEv2 הן:
-
ההגדרות עבור IKEv2 בצד CPE אינן תואמות את הצד של סיסקו, בדוק מחדש את ההגדרות שהוזכרו:
-
בדוק שגרסת ה- IKE היא גרסה 2.
-
ודא שהפרמטרים של הצפנה ואימות תואמים את ההצפנה הצפויה בצד המופע הייעודי.
כאשר צופן "GCM" נמצא בשימוש, פרוטוקול GCM מטפל באימות ומגדיר את פרמטר האימות ל- NULL.
-
ודא את הגדרת חיי החיים.
-
בדוק את קבוצת המודולוס של דיפי הלמן.
-
ודא את הגדרות הפונקציה האקראית הפסאודו.
-
-
רשימת הגישה למפת הקריפטו אינה מוגדרת ל:
-
אישור GRE (מנהלה_תחבורה_ip מקומית) 255.255.255.255 (מרוחק_תחבורה_ip) 255.255.255.255 אינץ' (או פקודה שווה ערך)
רשימת הגישה חייבת להיות ספציפית לפרוטוקול "GRE" ופרוטוקול "IP" לא יעבוד.
-
אם הודעות היומן אינן מציגות פעילות משא ומתן לשלב IKEv2, ייתכן שיהיה צורך בלכידת מנות.
צד מופע ייעודי עשוי לא תמיד להתחיל את החלפת IKEv2 ולעיתים עשוי לצפות שצד ה- CPE של הלקוח יהיה היוזם.
בדוק בתצורת צד CPE את התנאים המוקדמים הבאים ליזום הפעלת IKEv2:
-
בדוק אם יש רשימת גישה לקריפטו של IPsec עבור תעבורת GRE (פרוטוקול 50) מ- IP הובלת מנהרת CPE ל- IP הובלת מנהרת מופע ייעודי.
-
ודא שממשק מנהרת GRE מופעל עבור שימושים GRE, אם הציוד אינו תומך ב- GRE keepalives אז סיסקו מקבלת הודעה מכיוון ש- GRE keepalives יופעלו בצד המופע הייעודי כברירת מחדל.
-
ודא ש- BGP מופעל ומוגדר עם הכתובת השכנה של כתובת ה-IP של מנהרת המופע הייעודי.
כאשר מוגדרת התצורה כהלכה, הפעולות הבאות מתחילות את מנהרת ה- IPsec ואת המשא ומתן של IKEv2 בשלב הראשון:
-
GRE עוברים מממשק מנהרת GRE בצד CPE לממשק מנהרת GRE בצד המופע הייעודי.
-
הפעלת TCP של השכן של BGP משכן BGP בצד CPE לשכן BGP בצד המופע הייעודי.
-
פינג מכתובת ה- IP של המנהרה הצדדית של CPE לכתובת ה- IP של המנהרה בצד המופע הייעודי.
פינג לא יכול להיות IP הובלת המנהרה ל- IP הובלת מנהרה, זה חייב להיות IP מנהרה ל- IP של מנהרה.
אם יש צורך במעקב אחר מנות לתעבורת IKEv2, הגדר את המסנן עבור UDP ויציאה 500 (כאשר אין התקן NAT באמצע נקודות הקצה של IPsec) או יציאה 4500 (כאשר התקן NAT מוכנס באמצע נקודות הקצה של IPsec).
ודא שמנות IKEv2 UDP עם יציאה 500 או 4500 נשלחות ומתקבלות אל כתובת ה- IP DI IPsec וממנה.
ייתכן שמרכז הנתונים של מופע ייעודי לא תמיד יתחיל את חבילת IKEv2 הראשונה. הדרישה היא שמכשיר ה- CPE מסוגל ליזום את חבילת IKEv2 הראשונה לכיוון צד המופע הייעודי.
אם חומת האש המקומית מאפשרת זאת, נסה גם לבצע פינג לכתובת ה- IPsec המרוחקת. אם הפינג אינו מצליח מכתובת IPsec מקומית לכתובת IPsec מרוחקת, בצע נתיב מעקב כדי לעזור וקבע היכן המנה נשמרת.
ייתכן שחומות אש וציוד אינטרנט מסוימים אינם מאפשרים מסלול מעקב.
פתרון בעיות ואימות שלב שני של IPsec (משא ומתן IPsec)
ודא שהשלב הראשון של IPsec (כלומר, שיוך האבטחה של IKEv2) פעיל לפני פתרון בעיות בשלב השני של IPsec. בצע "הצג קריפטו ikev2 sa" או פקודה שווה ערך כדי לאמת את הפעלת IKEv2. בפלט, ודא שהפעלת IKEv2 הייתה פעילה יותר מכמה שניות וכי היא לא מקפצת. זמן הפעילות של ההפעלה מופיע כ"זמן פעיל" של ההפעלה או שווה ערך בפלט.
לאחר שהפעלת IKEv2 מואמת כפעילה, בדוק את הפעלת ה- IPsec. בדומה להפעלת IKEv2, בצע "הצג קריפטו ipsec sa" או פקודה שווה ערך כדי לאמת את הפעלת ה- IPsec. הן הפעלת IKEv2 והן הפעלת IPsec חייבים להיות פעילים לפני הקמת מנהרת ה- GRE. אם הפעלת IPsec אינה מוצגת כפעילה, בדוק ביומני IPsec אם קיימים הודעות שגיאה או שגיאות משא ומתן.
חלק מהבעיות הנפוצות יותר שעשויות להיתקל בהן במהלך המשא ומתן על IPsec הן:
ההגדרות בצד CPE אינן תואמות את הצד המופע הייעודי, בדוק שוב את ההגדרות:
-
ודא שהפרמטרים של הצפנה ואימות תואמים להגדרות בצד מופע ייעודי.
-
ודא את הגדרות הסודיות המושלמת קדימה ושההגדרות תואמות בצד המופע הייעודי.
-
ודא את הגדרות חיי החיים.
-
ודא שה- IPsec הוגדר במצב מנהרה.
-
ודא את כתובות IPsec המקור והיעד.
פתרון בעיות ואימות ממשק מנהרה
כאשר הפעלות IPsec ו- IKEv2 מאומתות כפעילות, מנהרת GRE שומרת חבילות מסוגלות לזרום בין המופע הייעודי ונקודות הקצה של מנהרת CPE. אם ממשק המנהרה אינו מציג סטטוס, כמה בעיות נפוצות הן:
-
VRF להובלת ממשק המנהרה אינו תואם את ה- VRF של ממשק הלולאה (אם נעשה שימוש בתצורת VRF בממשק המנהרה).
אם לא נעשה שימוש בתצורת VRF בממשק המנהרה, ניתן להתעלם מבדיקה זו.
-
Keepalives אינם מופעלים בממשק המנהרה הצדדי של CPE
אם keepalives אינם נתמכים בציוד ה- CPE, יש להודיע לסיסקו כך שגם רכיבי ה- Keepalives המוגדרים כברירת מחדל בצד המופע הייעודי יושבתו.
אם keepalives נתמכים, ודא שה-keepalives מופעלים.
-
המסכה או כתובת ה- IP של ממשק המנהרה אינם נכונים ואינם תואמים לערכים הצפויים של מופע ייעודי.
-
כתובת ההובלה של מנהרת המקור או היעד אינה נכונה ואינה תואמת את הערכים הצפויים של מופע ייעודי.
-
חומת אש חוסמת מנות GRE שנשלחו למנהרת IPsec או מתקבלות ממנהרת ה- IPsec (מנהרת GRE מועברת מעל מנהרת IPsec)
בדיקת פינג צריכה לוודא שממשק המנהרה המקומי פועל והקישוריות טובה לממשק המנהרה המרוחק. בצע את בדיקת הפינג מ- IP של המנהרה (לא ה- IP של התחבורה) ל- IP המנהרה המרוחקת.
רשימת הגישה לקריפטו עבור מנהרת ה- IPsec הנושאת את תעבורת מנהרת ה- GRE מאפשרת לחצות רק מנות GRE. כתוצאה מכך, פינגים לא יעבדו מ- IP של הובלת מנהרה ל- IP הובלת מנהרה מרוחקת.
בדיקת הפינג מביאה למנת GRE שנוצרת מ- IP הובלת מנהרת המקור ל- IP הובלת מנהרת היעד בעוד המטען של חבילת GRE (ה- IP הפנימי) יהיה IP המנהרה המקור והיעד.
אם בדיקת הפינג אינה מוצלחת והפריטים הקודמים מאומתים, ייתכן שתידרש לכידת מנות כדי להבטיח שה-icmp ping מביא למנת GRE אשר לאחר מכן נעוטפת במנת IPsec ולאחר מכן נשלחת מכתובת IPsec המקור לכתובת IPsec היעד. מונים בממשק מנהרת GRE ודלפקי הפעלות IPsec יכולים גם לעזור להציג. אם המנות שליחה וקבלה מצטברות.
בנוסף לתעבורת פינג, הלכידה אמורה להציג גם מנות Keepalive GRE גם במהלך תנועה סרק. לבסוף, אם BGP מוגדר, יש לשלוח מנות BGP keepalive גם כמנות GRE המצורפות במנות IPSEC גם דרך ה- VPN.
פתרון בעיות ואימות BGP
מפגשי BGP
BGP נדרש כפרוטוקול הניתוב מעל מנהרת ה- IPSec של VPN. השכן המקומי של BGP צריך להקים מפגש eBGP עם השכן של המופע הייעודי BGP. כתובות ה- IP של השכנות eBGP זהות לכתובות ה- IP המקומיות והמרוחקות של המנהרה. ראשית ודא שהפעלת ה- BGP פועלת ולאחר מכן ודא שהנתיבים הנכונים מתקבלים ממופע ייעודי ונתיב ברירת המחדל הנכון נשלח למופע ייעודי.
אם מנהרת ה- GRE עולה, ודא כי פינג מצליח בין ה- IP המקומי למנהרת GRE המרוחק. אם הפינג מצליח אך הפעלת ה- BGP אינה מגיעה, חקור את יומן ה- BGP עבור שגיאות הקמת BGP.
חלק מנושאי המשא ומתן הנפוצים יותר ב- BGP הם:
-
מספר ה- AS המרוחק אינו תואם למספר ה- AS שהוגדר בצד המופע הייעודי, בדוק מחדש את תצורת ה- AS השכן.
-
מספר ה- AS המקומי אינו תואם את מה שצד המופע הייעודי מצפה, ודא שמספר ה- AS המקומי תואם את הפרמטרים הצפויים של מופע ייעודי.
-
חומת אש חוסמת מנות BGP TCP המצורפות במנות GRE מלהישלח למנהרת IPsec או להתקבל ממנהרת IPSEC
-
כתובת ה- IP השכנה המרוחקת של BGP אינה תואמת את IP מנהרת GRE המרוחקת.
החלפת מסלולים BGP
לאחר אימות הפעלת ה- BGP עבור שתי המנהרות, ודא שהנתיבים הנכונים נשלחים ומתקבלים מצד המופע הייעודי.
פתרון ה-Dedicated Instance VPN מצפה שיוקמו שתי מנהרות מצד הלקוחות והשותפים. המנהרה הראשונה מצביעה על מרכז הנתונים של מופע ייעודי A והמנהרה השנייה מצביעה על מרכז הנתונים של מופע ייעודי B. שתי המנהרות חייבות להיות במצב פעיל והפתרון דורש פריסה פעילה/פעילה. כל מרכז נתונים של מופע ייעודי יפרסם את מסלול /25 המקומי שלו וכן מסלול גיבוי /24. בעת בדיקת נתיבי ה- BGP הנכנסים ממופע ייעודי, ודא שהפעלת BGP המשויכת למנהרה המצביעה על מרכז הנתונים A של מופע ייעודי מקבלת את הנתיב המקומי A /25 של מרכז הנתונים של מופע ייעודי וכן את מסלול הגיבוי /24. בנוסף, ודא שהמנהרה המצביעה על מרכז הנתונים B של מופע ייעודי מקבלת את הנתיב המקומי של מרכז הנתונים B /25 של מופע ייעודי וכן את מסלול הגיבוי /24. שים לב שנתיב הגיבוי /24 יהיה אותו מסלול המפורסם מתוך מרכז הנתונים של מופע ייעודי A ומרכז הנתונים של מופע ייעודי B.
יתירות ניתנת למרכז נתונים של מופע ייעודי אם ממשק המנהרה למרכז נתונים זה יורד. אם הקישוריות למרכז הנתונים של מופע ייעודי A תאבד, התנועה תועבר ממרכז הנתונים של מופע ייעודי B למרכז נתונים A. בתרחיש זה, המנהרה למרכז נתונים B תשתמש בנתיב מרכז הנתונים B/25 כדי לשלוח תנועה למרכז נתונים B והמנהרה למרכז נתונים B תשתמש בנתיב הגיבוי /24 כדי לשלוח תנועה למרכז נתונים A באמצעות מרכז נתונים B.
חשוב שכאשר שתי המנהרות פעילות, מנהרת מרכז הנתונים A אינה משמשת לשליחת תנועה למרכז נתונים B ולהיפך. בתרחיש זה, אם התנועה נשלחת למרכז נתונים A עם יעד של מרכז נתונים B, מרכז הנתונים A יעביר את התעבורה למרכז הנתונים B ולאחר מכן מרכז הנתונים B ינסה לשלוח תנועה חזרה למקור דרך מנהרת מרכז הנתונים B. זה יביא לניתוב תת-אופטימלי ועלול גם לשבור תנועה החוצה חומות אש. לכן, חשוב ששתי המנהרות יהיו בתצורה פעילה/פעילה במהלך פעולה רגילה.
יש לפרסם את המסלול 0.0.0.0/0 מצד הלקוח לצד מרכז הנתונים של מופע ייעודי. מסלולים ספציפיים יותר לא יתקבלו בצד המופע הייעודי. ודא שהמסלול 0.0.0.0/0 מתפרסם הן מהמנהרה A של מרכז הנתונים הייעודי של מופע ייעודי והן מהמנהרה B של מרכז הנתונים של מופע ייעודי.
תצורת MTU
בצד המופע הייעודי, שתי תכונות מופעלות להתאמה דינמית של MTU לגדלי מנות גדולים. מנהרת ה- GRE מוסיפה כותרות נוספות למנות ה- IP הזורמות דרך הפעלת ה- VPN. מנהרת ה- IPsec מוסיפה את הכותרות הנוספות על גבי כותרות ה- GRE תקטין עוד יותר את ה- MTU הגדול ביותר המותר מעל המנהרה.
מנהרת GRE מתאימה את תכונת MSS ונתיב מנהרת GRE בתכונת גילוי MTU מופעל בצד המופע הייעודי. הגדר את התצורה של "ip tcp just-mss 1350" או פקודה שווה ערך וכן "נתיב מנהרה\ u0002mtu-discovery" או פקודה שווה ערך בצד הלקוח כדי לסייע בהתאמה דינמית של MTU של התנועה דרך מנהרת ה- VPN.
