VPN בענן זקוק ל-BGP: מדוע פרוטוקולי ניתוב אחרים נכשלים

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

המנהרה פעילה והנתיב חסר

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

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

מה הספק באמת נותן לכם

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

Google Cloud מתעד ניתוב BGP דינמי ל-HA VPN, כאשר Cloud Router לומד נתיבי עמיתים ומספק נתיבים דינמיים מותאמים כשירים ל-VPC. AWS Site-to-Site VPN מתעד בחירה בין ניתוב סטטי לדינמי, ומתאר בדיקות חיות של BGP כמועילות למעבר כשל של המנהרה, ובמקביל תומך בבדיקות בריאות להתקנים ללא BGP. אין להסיק את התנהגות פלטפורמה אחת משם המוצר של האחרת.

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

הגנת המנהרה והנגישות הן משימות נפרדות

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

דמיינו סניף שמכריז על 10.42.0.0/16 דרך שני נתיבי מנהרה כשירים. הסירו נתיב שמיש אחד ובחירת הנתיב עשויה להשתנות בלי שאיש יערוך את הנתיב של כל עומס עבודה. זיהוי, בחירת נתיב והתאוששות היישום אינם מיידיים ואינם זהים בין פריסות, לכן מבחן מעבר הכשל חייב לצפות ברצף כולו ולא במנות הראשונה שעוברת.

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

היכן הנחות OSPF נשברות

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

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

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

קראו את דרישת השירות ואז תכננו

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

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

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