מבוא

Virtual Connect הוא אפשרות תוסף נוספת עבור קישוריות ענן למופע ייעודי עבור Webex Calling (מופע ייעודי). Virtual Connect מאפשר ללקוחות להרחיב את הרשת הפרטית שלהם בצורה מאובטחת דרך האינטרנט באמצעות מנהרות IP VPN נקודה לנקודה. אפשרות קישוריות זו מספקת יצירת חיבור רשת פרטית במהירות באמצעות ציוד הלקוח (CPE) הקיים וקישוריות לאינטרנט.

סיסקו מארחת, מנהלת ומבטיחה מנהרות IP VPN יתירות וגישה לאינטרנט הנדרשת באזור/י מרכז הנתונים של ה-Dedicated Instance של סיסקו שבהם השירות נדרש. באופן דומה, מנהל המערכת אחראי על שירותי ה-CPE והאינטרנט המתאימים שלו, הנדרשים להקמת Virtual Connect.

כל הזמנת Virtual Connect באזור מסוים של Dedicated Instance תכלול שתי מנהרות גנריות של אנקפסולציה של ניתוב (GRE) המוגנות על ידי הצפנת IPSec (GRE over IPSec), אחת לכל מרכז נתונים של סיסקו באזור שנבחר.

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

לפני שליחת בקשת העמית עבור Virtual Connect, ודא ששירות ה-Dedicated Instance מופעל באזור המתאים.

דרישות מקדימות

התנאים המוקדמים להקמת Virtual Connect כוללים:

  • הלקוח מספק

    • חיבור אינטרנט עם רוחב פס זמין מספיק כדי לתמוך בפריסה

    • כתובות IP ציבוריות עבור שתי מנהרות IPSec

    • כתובות IP של תעבורת GRE בצד הלקוח עבור שתי מנהרות GRE

  • שותף ולקוח

    • לעבוד יחד כדי להעריך את דרישות רוחב הפס

    • ודא/י שהתקן/י הרשת תומך/ים בניתוב של פרוטוקול Border Gateway (BGP) ובתכנון מנהרה של GRE over IPSec

  • שותף או לקוח מספק

    • צוות רשת עם ידע בטכנולוגיות מנהרת VPN מאתר לאתר

    • צוות רשת עם ידע ב-BGP, eBGP ועקרונות ניתוב כלליים

  • Cisco

    • סיסקו הקצתה מספרי מערכת אוטונומיים פרטיים (ASN) וכתובות IP חולפות עבור ממשקי מנהרת GRE

    • סיסקו הקצתה Class C ציבורי אך לא ניתן לניתוב לאינטרנט (/24) רשת עבור כתובות ענן ייעודיות של מופעים

אם ללקוח יש רק מכשיר CPE אחד, אזי שתי המנהרות לכיוון מרכזי הנתונים של סיסקו (DC1 ו-DC2) בכל אזור יהיו מאותו מכשיר CPE. ללקוח יש גם אפשרות לשני התקני CPE, כאשר כל התקן CPE צריך להתחבר למנהרה אחת בלבד לכיוון מרכזי הנתונים של סיסקו (DC1 ו-DC2) בכל אזור. ניתן להשיג יתירות נוספת על ידי סיום כל מנהרה במבנה פיזי נפרד. site/location בתוך התשתית של הלקוח.

פרטים טכניים

מודל פריסה

Virtual Connect משתמש בארכיטקטורת headend דו-שכבתית, שבה מישורי הניתוב והבקרה של GRE מסופקים על ידי התקן אחד ומישור הבקרה של IPSec מסופק על ידי אחר.

עם השלמת קישוריות Virtual Connect, ייווצרו שתי מנהרות GRE over IPSec בין רשת הארגון של הלקוח לבין מרכזי הנתונים של Cisco Dedicated Instance. אחד לכל מרכז נתונים עודף באזור המתאים. רכיבי רשת נוספים הנדרשים לצורך העמית מועברים על ידי השותף או הלקוח לסיסקו באמצעות טופס ההפעלה של Control Hub Virtual Connect.

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

חיבור וירטואלי - VPN הוא עיצוב Hub, שבו אתרי ה-Hub של הלקוח מחוברים ל-DC1 ו-DC2 של מרכזי הנתונים של ה-Dedicated Instance בתוך אזור מסוים.

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

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

אתרים מרוחקים של הלקוח באותו אזור יצטרכו להתחבר חזרה לאתר/ים של ה-Hub דרך רשת ה-WAN של הלקוח, וזו אינה אחריותה של סיסקו לקישוריות זו.

מצופה מהשותפים לעבוד בשיתוף פעולה הדוק עם הלקוחות, ולהבטיח שהנתיב האופטימלי ביותר ייבחר עבור אזור השירות Virtual Connect.

האיור שלהלן מציג את אזורי העמית של קישוריות ענן של מופע ייעודי.

אזורי חיבור וירטואליים

ניתוב

ניתוב עבור תוסף Virtual Connect מיושם באמצעות BGP חיצוני (eBGP) בין מופע ייעודי לבין ציוד הלקוח (CPE). סיסקו תפרסם את הרשת המתאימה שלה עבור כל בקר מתח מיותר באזור ל-CPE של הלקוח, וה-CPE נדרש לפרסם נתיב ברירת מחדל לסיסקו.

  • סיסקו מתחזקת ומקצה

    • כתובת IP של ממשק מנהרה (קישור חולף לניתוב) שסיסקו מקצה ממרחב כתובות משותף ייעודי (לא ניתן לניתוב ציבורי)

    • כתובת יעד של תחבורה במנהרה (צד סיסקו)

    • מספרי מערכת אוטונומיים פרטיים (ASN) עבור תצורת ניתוב 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 יחיד יהיו שניים active/active מנהרות. עבור שני צמתי CPE, לכל CPE תהיה מנהרה פעילה אחת ושני צמתי ה-CPE צריכים להיות פעילים ולעבור תעבורה. בתרחיש של אי-כשל, התנועה חייבת להתפצל לשתי מנהרות המובילות לכיוון הנכון /25 יעדים, אם אחת המנהרות קורסת, המנהרה הנותרת יכולה לשאת את התנועה עבור שתיהן. תחת תרחיש כשל כזה, כאשר ה- /25 הרשת מושבתת אז ה /24 הרשת משמשת כנתיב גיבוי. סיסקו תשלח את תעבורת הלקוחות דרך ה-WAN הפנימי שלה לעבר ה-DC שאיבד קישוריות.

זרימת תעבורת חיבור וירטואלי

זרימת התנועה כאשר שתי המנהרות פתוחות

מופע ייעודי - חיבור וירטואלי

תמונה זו ממחישה ארכיטקטורת רשת Virtual Connect, המפרטת את זרימת התנועה כאשר מנהרות ראשיות ומשניות פועלות.

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

הגדרות:

  • מיקום הלקוח:
    • זה מייצג את הרשת באתר של הלקוח, שם ממוקמים המשתמשים והמכשירים שלהם (למשל, טלפוני IP, מחשבים המריצים לקוחות UC).
    • תעבורה שמקורה מכאן צריכה להגיע ליישומי UC המאוחסנים במרכזי הנתונים של סיסקו.
  • מרכזי נתונים של Cisco Webex Calling Dedicated Instance (Dedicated Instance) (WxC-DI DC-A ו-WxC-DI DC-B):
    • אלו הם מרכזי הנתונים של סיסקו המארחים את יישומי UC.
    • DC-A ו-DC-B שונים מבחינה גיאוגרפית, מה שמספק יתירות.
    • לכל מרכז נתונים יש תת-רשת משלו עבור יישומי UC:
      • DC-A subnet:X.X.X.0/25
      • DC-B subnet: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: מחבר את הנחת הלקוח ל-"Dedicated Instance DC-A" (מרכז נתונים A) דרך האינטרנט. מנהרה זו משתמשת ב-BGP AS:64XX1 בצד הלקוח וב-BGP AS:64XX2 בצד של ה-DC-A של ה-Dedicated Instance. תצורות מקור מנהרות IPSEC ו-GRE מחולקות בין פרטים המסופקים על ידי הלקוח לבין פרטים המסופקים על ידי סיסקו.
  • מִנהָרָה 2: מחבר את הנחת הלקוח ל-"Dedicated Instance DC-B" (מרכז נתונים B) דרך האינטרנט. מנהרה זו משתמשת ב-BGP AS:64YY1 בצד הלקוח וב-BGP AS:64YY2 בצד ה-DC-B של ה-Dedicated Instance. כמו מנהרה 1, תצורות מקור מנהרות IPSEC ו-GRE משותפות בין הלקוח לסיסקו.

ב-BGP AS:64XX ו-BGP AS:64YY, XX ו-YY ספציפיים לאזור מסוים.

ברגע שה- GRE/IPSEC כאשר נוצרות מנהרות למרכזי נתונים של Webex Calling Dedicated Instance (A ו-B), הלקוח אמור לקבל את המסלולים הבאים המפורסמים מ-Cisco במהלך הפעלות BGP המתאימות.

  • עבור DC-A: המסלולים שיפורסמו על ידי סיסקו יהיו X.X.X.0/25 ו X.X.x.0/24. באופן אופציונלי, אם IaaS מתבקש ומוגדר עבור נתיבי הלקוח Y.Y.Y.0/25 ו Y.Y.Y.0/24 יפורסם על ידי סיסקו.
  • עבור DC-B: המסלולים שיפורסמו על ידי סיסקו יהיו X.X.X.128/25 ו X.X.x.0/24. באופן אופציונלי, אם IaaS מתבקש ומוגדר עבור נתיבי הלקוח Y.Y.Y.128/25 ו Y.Y.Y.0/24 יפורסם על ידי סיסקו.
  • הלקוח צריך לפרסם את 0.0.0./0 מסלול לסיסקו דרך שני החיבורים (מנהרות)
  • הלקוח צריך להשתמש בקידומת הארוכה ביותר (/25) נתיבים לשליחת תעבורה לסיסקו דרך המנהרות המתאימות כאשר שתי המנהרות פועלות.
  • סיסקו תחזיר את התעבורה דרך אותן מנהרות כדי לשמור על סימטריה של התנועה.

זרימת תנועה:

  • תעבורה המיועדת ל"אפליקציות UC של DC-A" (X.X.X.0/25) ממקום עבודת הלקוח זורם דרך מנהרה 1.
  • תנועה המיועדת ל"אפליקציות UC של DC-B" (X.X.X.128/25) מנקודת המכירה של הלקוח זורם דרך מנהרה 2.

תרחיש כשל : זרימת התנועה כאשר אחת המנהרות פתוחה

מופע ייעודי - חיבור וירטואלי

כפי שמוצג בתרשים לעיל, כאשר המנהרה ל-DC-A נמצאת למטה, ה-bgp שנוצר דרך המנהרה ל-DC-A יירד למטה.

השפעה על BGP: כאשר מנהרה 1 נופלת, גם סשן ה-BGP מעל מנהרה זו ייכשל. כתוצאה מכך, DC-A לא תוכל עוד לפרסם את המסלולים שלה (במיוחד X.X.X.0/25) ללקוח דרך נתיב זה. לפיכך, נתב הלקוח יזהה את הנתיב כבלתי ניתן להשגה.

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

  • תעבורה המיועדת לרשת האפליקציות של UC (X.X.X.0/24) או תת-רשת DC-A (X.X.X.0/25) לאחר מכן יופנה דרך מנהרת העבודה לכיוון DC-B אשר תמשיך לפרסם את X.X.X.0/24 שכולל את ה X.X.X.0/25 רֶשֶׁת.
  • התנהגות דומה תראה אם המנהרה ל-DC-B פועלת בעוד שהמנהרה ל-DC-A עדיין פועלת.

תהליך קישוריות

השלבים הבאים ברמה גבוהה מתארים כיצד ליצור קישוריות עם Virtual Connect for Dedicated Instance.
1

בצע הזמנה ב- Cisco CCW

2

הפעלת Virtual Connect ממרכז הבקרה

3

סיסקו מבצעת הגדרת רשת

4

הלקוח מבצע את הגדרת הרשת

שלב 1: הזמנת CCW

Virtual Connect הוא תוסף עבור Dedicated Instance ב-CCW.

1

נווטו לאתר ההזמנות של CCW ולאחר מכן לחצו על התחברות כדי להיכנס לאתר:

https://apps.cisco.com/Commerce/guest.
2

צור הערכה.

3

הוסף את מק"ט "A-FLEX-3".

4

בחר אפשרויות עריכה.

5

בכרטיסיית המנוי שמופיעה, בחר אפשרויות ותוספות.

6

תחת תוספים נוספים, סמן את תיבת הסימון שליד "חיבור וירטואלי עבור מופע ייעודי". שם ה-SKU הוא "A-FLEX-DI-VC".

7

הזן את כמות ומספר האזורים שבהם נדרש Virtual Connect.

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

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

9

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

שלב 2: הפעלת Virtual Connect במרכז הבקרה

1

היכנס למרכז הבקרה https://admin.webex.com/login.

2

במקטע שירותים, נווט אל שיחות > אינסטנס ייעודי > קישוריות ענן.

3

בכרטיס Virtual Connect, כמות Virtual Connect שנרכשה רשומה. מנהל המערכת יכול כעת ללחוץ על הפעל כדי להתחיל את הפעלת Virtual Connect.

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

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

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

  1. כתובת IP של GRE Tunnel Transport: הלקוח נדרש לספק את כתובות ה-IP של Tunnel Transport בצד הלקוח וסיסקו תקצה את כתובות ה-IP באופן דינמי לאחר השלמת ההפעלה. רשות הגישה הרשומה של IPSec עבור תעבורה מעניינת אמורה לאפשר תעבורה מקומית במנהרה IP/32 לתחבורת מנהרות מרוחקת IP/32. ה-ACL צריך גם לציין רק את פרוטוקול GRE IP.

    כתובת ה-IP שמספק הלקוח יכולה להיות פרטית או ציבורית.

  2. עמיתים של IPSec: הלקוח נדרש לספק את כתובות ה-IP של המקור של מנהרת ה-IPSec וסיסקו מקצה את כתובת ה-IP של יעד ה-IPSec. ביצוע תרגום NAT של כתובת מנהרת IPSEC פנימית לכתובת ציבורית נתמך גם הוא במידת הצורך.

    כתובת ה-IP שסופקת על ידי הלקוח צריכה להיות ציבורית.

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

לחץ על כפתור הפעל לאחר שמולאו כל שדות החובה.

6

לאחר מילוי טופס הפעלת Virtual Connect עבור אזור מסוים, הלקוח יכול לייצא את טופס ההפעלה מ-Control Hub, Calling > מופע ייעודי > בכרטיסייה קישוריות לענן ולחצו על הגדרות ייצוא.

מסיבות אבטחה, האימות וסיסמת ה-BGP לא יהיו זמינים במסמך המיוצא, אך מנהל המערכת יכול לצפות בהם ב-Control Hub על ידי לחיצה על View Settings תחת Control Hub, Calling. > מופע ייעודי > כרטיסיית קישוריות לענן.

שלב 3: סיסקו מבצעת הגדרת רשת

1

לאחר מילוי טופס הפעלת Virtual Connect, הסטטוס יעודכן ל- הפעלה בתהליך בשיחות > מופע ייעודי > כרטיס חיבור וירטואלי של קישוריות ענן.

2

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

שלב 4: הלקוח מבצע את הגדרת הרשת

הסטטוס משתנה ל-"מופעל" כדי להודיע למנהל הלקוח שצד סיסקו של תצורות קישוריות IP VPN הושלם בהתבסס על הקלט שסיפק הלקוח. עם זאת, מנהל הלקוח צפוי להשלים את הצד שלו בתצורות ב-CPEs ולבדוק את נתיבי הקישוריות כדי שמנהרת ה-Virtual Connect תהיה מקוונת. במקרה של בעיות כלשהן בזמן התצורה או הקישוריות, הלקוח יכול לפנות ל-Cisco TAC לקבלת סיוע.

פתרון בעיות

פתרון בעיות ואימות של שלב ראשון של IPsec (משא ומתן של IKEv2)

משא ומתן מנהרת IPsec כולל שני שלבים, שלב IKEv2 ושלב IPsec. אם משא ומתן שלב IKEv2 לא הושלם, אזי לא תתחיל שלב IPsec שני. ראשית, יש להוציא את הפקודה "show crypto ikev2 sa" (בציוד של סיסקו) או פקודה דומה בציוד של צד שלישי כדי לוודא שהסשן של IKEv2 פעיל. אם סשן IKEv2 אינו פעיל, הסיבות האפשריות עשויות להיות:

  • תעבורה מעניינת אינה מפעילה את מנהרת ה-IPsec.

  • רשימת הגישה למנהרת IPsec מוגדרת באופן שגוי.

  • אין קישוריות בין הלקוח לבין כתובת ה-IP של נקודת הקצה של מנהרת ה-IPsec של המופע הייעודי.

  • פרמטרי ההפעלה של IKEv2 אינם תואמים בין צד המופע הייעודי לצד הלקוח.

  • חומת אש חוסמת את חבילות ה-UDP של IKEv2.

ראשית, בדוק את יומני ה-IPsec עבור הודעות המציגות את התקדמות המשא ומתן על מנהרת IKEv2. ייתכן שהיומנים מצביעים על בעיה במשא ומתן של IKEv2. היעדר הודעות רישום עשוי גם להצביע על כך שהפעלה של IKEv2 אינה מופעלת.

כמה שגיאות נפוצות במשא ומתן של IKEv2 הן:

  • ההגדרות עבור IKEv2 בצד ה-CPE אינן תואמות לצד סיסקו, בדוק שוב את ההגדרות שהוזכרו:

    • ודא שגרסת ה-IKE היא גרסה 2.

    • ודא שפרמטרי ההצפנה והאימות תואמים להצפנה הצפויה בצד המופע הייעודי.

      כאשר צופן "GCM" נמצא בשימוש, פרוטוקול GCM מטפל באימות ומגדיר את פרמטר האימות ל- NULL.

    • ודא את הגדרת אורך החיים.

    • אימות קבוצת מודול דיפי הלמן.

    • ודא את הגדרות הפונקציה הפסאודו-אקראית.

  • רשימת הגישה למפת הקריפטו אינה מוגדרת ל:

    • אישור GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (או פקודה מקבילה)

      רשימת הגישה חייבת להיות ספציפית עבור פרוטוקול "GRE" ופרוטוקול "IP" לא יעבוד.

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

צד המופע הייעודי לא תמיד יתחיל את חילופי ה-IKEv2 ולעיתים עשוי לצפות שצד ה-CPE של הלקוח יהיה היוזם.

בדוק את תצורת צד ה-CPE עבור הדרישות המוקדמות הבאות לאתחול סשן IKEv2:

  • בדוק אם יש רשימת גישה קריפטוגרפית מסוג IPsec עבור תעבורת GRE (פרוטוקול 50) מכתובת ה-IP של תעבורת מנהרה של CPE לכתובת ה-IP של תעבורת מנהרה של המופע הייעודי.

  • ודא שממשק מנהרת ה-GRE מופעל עבור GRE keepalives. אם הציוד אינו תומך ב-GRE keepalives, סיסקו מקבלת הודעה מכיוון ש-GRE keepalives יופעלו בצד ה-Dedicated Instance כברירת מחדל.

  • ודא ש-BGP מופעל ותצורתו מוגדרת עם כתובת השכן של כתובת ה-IP של מנהרת המופע הייעודי.

לאחר הגדרה נכונה, הפעולות הבאות מתחילות את מנהרת ה-IPsec ואת השלב הראשון של משא ומתן IKEv2:

  • GRE keepalives מממשק מנהרת GRE בצד ה-CPE לממשק מנהרת GRE בצד המופע הייעודי.

  • סשן TCP של שכן BGP משכן BGP בצד CPE לשכן BGP בצד המופע הייעודי.

  • פינג מכתובת ה-IP של המנהרה הצדדית של ה-CPE לכתובת ה-IP של המנהרה הצדדית של המופע הייעודי.

    פינג לא יכול להיות כתובת ה-IP של תעבורת מנהרה אחת לאחרת, היא חייבת להיות כתובת IP של מנהרה אחת לאחרת.

אם נדרש מעקב אחר מנות עבור תעבורת IKEv2, הגדר את המסנן עבור UDP ויציאה 500 (כאשר אין התקן NAT באמצע נקודות הקצה של IPsec) או יציאה 4500 (כאשר התקן NAT מוכנס באמצע נקודות הקצה של IPsec).

ודא שחבילות IKEv2 UDP עם פורט 500 או 4500 נשלחות ומתקבלות אל כתובת ה-IP של DI IPsec וממנה.

ייתכן שמרכז הנתונים של המופע הייעודי לא תמיד יתחיל את חבילת IKEv2 הראשונה. הדרישה היא שהתקן ה-CPE מסוגל ליזום את חבילת IKEv2 הראשונה לכיוון צד ה-Dedicated Instance.

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

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

פתרון בעיות ואימות של שלב שני של IPsec (משא ומתן של IPsec)

ודא שהשלב הראשון של IPsec (כלומר, שיוך האבטחה IKEv2) פעיל לפני פתרון בעיות בשלב השני של IPsec. בצע פקודה "show crypto ikev2 sa" או פקודה מקבילה כדי לאמת את סשן ה-IKEv2. בפלט, ודא שסשן ה-IKEv2 פעיל יותר מכמה שניות ושהוא אינו קופץ. זמן הפעולה של הסשן מוצג כ-"זמן פעיל" של הסשן או שווה ערך בפלט.

לאחר שסשן IKEv2 אימות כפעיל, בדוק את סשן ה-IPsec. כמו עם סשן IKEv2, בצע פקודה "show crypto ipsec sa" או פקודה מקבילה כדי לאמת את סשן ה-IPsec. גם סשן IKEv2 וגם סשן IPsec חייבים להיות פעילים לפני יצירת מנהרת GRE. אם הפעלת ה-IPsec אינה מוצגת כפעילה, בדוק את יומני ה-IPsec עבור הודעות שגיאה או שגיאות משא ומתן.

חלק מהבעיות הנפוצות יותר שעלולות להתעורר במהלך משא ומתן IPsec הן:

ההגדרות בצד ה-CPE אינן תואמות לצד ה-Dedicated Instance, בדוק שוב את ההגדרות:

  • ודא שפרמטרי ההצפנה והאימות תואמים להגדרות בצד המופע הייעודי.

  • ודא את הגדרות הסודיות קדימה המושלמת (Perfect Forward Secrecy) ושהן תואמות את ההגדרות בצד המופע הייעודי.

  • אימות הגדרות אורך החיים.

  • ודא ש-IPsec הוגדר במצב מנהרה.

  • אמת את כתובות ה-IPsec של המקור והיעד.

פתרון בעיות ואימות של ממשק מנהרה

כאשר מאומתים כי מערכות ה-IPsec וה-IKEv2 פעילות, חבילות ה-GRE keepalive יכולות לזרום בין נקודות הקצה של ה-Dedicated Instance לבין נקודות הקצה של מנהרת ה-CPE. אם ממשק המנהרה אינו מוצג בסטטוס, כמה בעיות נפוצות הן:

  • ערך ה-VRF של תעבורת ממשק המנהרה אינו תואם ל-VRF של ממשק הלולאה החוזרת (אם נעשה שימוש בתצורת VRF בממשק המנהרה).

    אם תצורת VRF אינה בשימוש בממשק המנהרה, ניתן להתעלם מבדיקה זו.

  • ‏Keepalives אינם מופעלים בממשק המנהרה הצדדי של CPE

    אם ציוד ה-CPE אינו תומך ב-keepalives, יש להודיע לסיסקו כך שגם ה-keepalives המוגדרים כברירת מחדל בצד ה-Dedicated Instance יושבתו.

    אם קבצי keepalive נתמכים, ודא שהם מופעלים.

  • המסכה או כתובת ה-IP של ממשק המנהרה אינן נכונות ואינן תואמות את הערכים הצפויים של המופע הייעודי.

  • כתובת התעבורה של מנהרת המקור או היעד אינה נכונה ואינה תואמת את הערכים הצפויים של המופע הייעודי.

  • חומת אש חוסמת חבילות GRE מלשלוח לתוך מנהרת IPsec או לקבל ממנה (מנהרת ה-GRE מועברת דרך מנהרת IPsec)

בדיקת פינג אמורה לוודא שממשק המנהרה המקומי פעיל ושהקישוריות לממשק המנהרה המרוחק תקינה. בצע את בדיקת הפינג מכתובת ה-IP של המנהרה (לא מכתובת ה-IP של התעבורה) אל כתובת ה-IP של המנהרה המרוחקת.

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

בדיקת הפינג גורמת לחבילת GRE שנוצרת מכתובת ה-IP של תעבורת המנהרה של המקור לכתובת ה-IP של תעבורת המנהרה של היעד, בעוד שמטען חבילת ה-GRE (ה-IP הפנימי) יהיה כתובת ה-IP של המנהרה של המקור והיעד.

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

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

פתרון בעיות ואימות של BGP

מפגשי BGP

BGP נדרש כפרוטוקול ניתוב מעל מנהרת IPsec של VPN. שכן ה-BGP המקומי צריך ליצור סשן eBGP עם שכן ה-BGP של המופע הייעודי. כתובות ה-IP של השכן ב-eBGP זהות לכתובות ה-IP של המנהרה המקומית והמרוחקת. ראשית, ודא שסשן ה-BGP פעיל ולאחר מכן ודא שהנתיבים הנכונים מתקבלים מה-Dedicated Instance ושהנתיב הנכון המוגדר כברירת מחדל נשלח ל-Dedicated Instance.

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

חלק מבעיות המשא ומתן הנפוצות יותר של BGP הן:

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

  • מספר ה-AS המקומי אינו תואם את מה שצד ה-Dedictaed Instance מצפה לו, ודא שמספר ה-AS המקומי תואם את הפרמטרים הצפויים של ה-Dedictaed Instance.

  • חומת אש חוסמת מנות BGP TCP הכלולות במנות GRE מלהישלח לתוך מנהרת IPsec או מלקבל אותן ממנהרת IPSEC.

  • כתובת ה-IP של השכן המרוחק של BGP אינה תואמת את כתובת ה-IP של מנהרת GRE המרוחקת.

החלפת מסלולי BGP

לאחר אימות סשן ה-BGP עבור שתי המנהרות, יש לוודא שהנתיבים הנכונים נשלחים ומתקבלים מצד ה-Dedicated Instance.

פתרון ה-VPN של מופע ייעודי מצפה שיוקמו שתי מנהרות מה- customer/partner צַד. המנהרה הראשונה מצביעה על מרכז הנתונים ייעודי A והמנהרה השנייה מצביעה על מרכז הנתונים ייעודי B. שתי המנהרות חייבות להיות במצב פעיל והפתרון דורש active/active פְּרִיסָה. כל מרכז נתונים של מופע ייעודי יפרסם את המיקום המקומי שלו /25 מסלול כמו גם א /24 נתיב גיבוי. בעת בדיקת נתיבי BGP נכנסים מ-Dedicated Instance, יש לוודא ש-BGP session המשויך למנהרה המצביעת על Dedicated Instance datacenter A מקבל את Dedicated Instance datacenter A. /25 המסלול המקומי וגם ה /24 נתיב גיבוי. בנוסף, ודא שהמנהרה המצביעה אל מרכז הנתונים Dedicated Instance B מקבלת את מרכז הנתונים Dedicated Instance B. /25 המסלול המקומי וגם ה /24 נתיב גיבוי. שימו לב ש- /24 נתיב הגיבוי יהיה אותו נתיב שמפורסם מתוך מרכז נתונים ייעודי A של מופע ייעודי ומרכז נתונים ייעודי B של מופע ייעודי.

יתירות מסופקת למרכז נתונים של מופע ייעודי אם ממשק המנהרה למרכז נתונים זה נופל. אם הקישוריות למרכז נתונים ייעודי A תאבד, התעבורה תועבר ממרכז נתונים ייעודי B למרכז נתונים A. בתרחיש זה, המנהרה למרכז נתונים B תשתמש במרכז נתונים B. /25 הנתיב לשליחת תעבורה למרכז נתונים B והמנהרה למרכז נתונים B תשתמש בגיבוי /24 נתיב לשליחת תעבורה למרכז נתונים א' דרך מרכז נתונים ב'.

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

ה 0.0.0.0/0 יש לפרסם את המסלול מצד הלקוח לצד מרכז הנתונים של המופע הייעודי. נתיבים ספציפיים יותר לא יתקבלו על ידי צד ה-Dedicated Instance. ודא ש- 0.0.0.0/0 המסלול מפורסם הן מתוך מנהרה A של מרכז הנתונים הייעודי של מופע ייעודי והן מתוך מנהרה B של מרכז הנתונים הייעודי של מופע ייעודי.

תצורת MTU

בצד ה-Dedicated Instance, שתי תכונות מופעלות כדי להתאים באופן דינמי את ה-MTU עבור גדלי חבילות גדולים. מנהרת ה-GRE מוסיפה כותרות נוספות לחבילות ה-IP הזורמות דרך סשן ה-VPN. מנהרת IPsec מוסיפה את הכותרות הנוספות מעל כותרות ה-GRE ותפחית עוד יותר את ה-MTU הגדול ביותר המותר מעל המנהרה.

מנהרת ה-GRE מתאימה את תכונת ה-MSS ואת נתיב מנהרת ה-GRE בתכונת גילוי ה-MTU מופעלת בצד המופע הייעודי. הגדר את הפקודה "ip tcp adjust-mss 1350" או פקודה מקבילה, וכן את הפקודה "tunnel". path\u0002mtu-discovery" או פקודה מקבילה בצד הלקוח כדי לסייע בהתאמה הדינמית של MTU של תעבורה דרך מנהרת ה-VPN.