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

ההחלטה היא התקן עמית אחד או שניים

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

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

כתבו את גיליון העבודה לפני כל פקודה

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

RowWhat it records
Google sideProject, VPC, region, HA VPN gateway, and the external address of each interface
Peer sideThe Cisco external addresses, plus the external peer VPN gateway resource that represents them
Tunnel pairsWhich peer interface maps to each Google interface, with IKE version, secret and crypto parameters
RoutingCloud Router, local and remote AS numbers, and one inside BGP pair per tunnel
WorkloadsApproved on-premises and VPC prefixes, and what firewall policy should permit between them

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

אם לשורה אין בעלים, מי שנמצא בתורנות במהלך המעבר ימלא אותה.

הפרידו בין שלושת תפקידי הכתובת

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

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

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

תרגמו את גיליון העבודה לגרסת Cisco

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

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

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

קבלו כל מנהרה על סמך הראיות שלה

HA VPN זקוק להפעלות BGP, ומשא ומתן מוצלח של IKE מבסס רק את השלב הראשון. ההפעלה הפנימית חייבת לעלות, יש להכריז על הקידומות המיועדות ולקבל אותן, וחייבים להתקיים מסלולים שימושיים והרשאות חומת אש לפני שתנועת העומסים נעה. רישום אלה כאור ירוק אחד מסתיר איזה שלב נכשל בפועל.

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

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

מאמרים קשורים