שתי כתובות VPN מקומיות: שני עמיתי Azure, לא אחד

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

המיתוס: שער אחד, שתי כתובות

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

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

ספרו את האובייקטים, ואז את המנהרות

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

החשבון קצר מספיק כדי להדביק אותו במסמך התכנון:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

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

מה מצב פעיל-פעיל מוסיף בצד Azure

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

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

BGP הופך את שני הנתיבים לשימושיים

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

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

בחירה מבוססת זרימה אינה איגוד רוחב פס

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

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

איזו יתירות הסרתם בפועל

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

צפו לעיכובי זיהוי והתכנסות, וצפו שכמה הפעלות קיימות יסתיימו.