Peering ב-Azure או VPN מ-VNet ל-VNet? החליטו לפני הניתוב

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

שלושה תנאים שקובעים את המודל

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

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

תנאי 1: האם אתם צריכים גבול IPsec שבבעלותכם?

Peering נושא תעבורה בעמוד השדרה הפרטי של Azure ואינו דורש שער VPN עבור חיבור ה-peered עצמו. זו אמירה על התעבורה, לא אמירה על הצפנה שתוכלו למסור למבקר כ'אנחנו מריצים IPsec'. אם הדרישה נוקבת במנהרה שהלקוח מגדיר, במדיניות IKE מסוימת או בגבול שמסתיים בציוד שאתם שולטים בו, Peering לא עומד בה, עד כמה שעמוד השדרה פרטי.

VPN מ-VNet ל-VNet כן מספק את הגבול הזה: שני שערים, יחס IPsec/IKE, מפתחות משותפים וכל פני השטח התפעוליים הנלווים. אתם יורשים את מצב המנהרה, קיבולת השער, מגבלות SKU והניטור שמוכיח שהמנהרה פעילה. זו התשובה הנכונה כשהדרישה עוסקת בדיוק בגבול הזה, המתואר בסקירת ה-peering כסוג חיבור נפרד מ-Peering.

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

תנאי 2: האם הטופולוגיה ישירה, או שמשהו צריך לעבור?

Peering אינו טרנזיטיבי. שני VNet-ים שמחוברים ב-peering ל-hub אינם מחוברים זה לזה בגלל זה, ומסלול שנראה עובד בכיוון אחד הוא בדרך כלל Peering שהגיע ל-Connected רק בצד אחד. שני הצדדים חייבים להתקיים ושניהם חייבים להציג Connected, וזה הדבר הראשון שתבדקו כשהתעבורה נעלמת בשקט.

אם הדרישה היא הגעה לרשת המקומית דרך hub, מעבר שער הוא תכנון נפרד עם תפקידים מוגדרים: ה-hub הוא הבעלים של השער, ה-peering של ה-spoke מתיר מעבר שער, וה-spoke חייב להתיר תעבורה מועברת. אלו מאפיינים על ה-peering, לא תוצאות אוטומטיות של חיבור ה-VNet-ים:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

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

תנאי 3: מי הבעלים של מסלול המעבר והחשבון?

לכל קפיצה נוספת יש בעלים. עם Peering, VNet חדש פירושו זוג peering חדש בשני הצדדים, ולמעבר hub שממשיך להעביר תעבורה וטבלת מסלולים שממשיכה להצביע עליו. עם VPN, VNet חדש פירושו שער נוסף או חיבור נוסף על שער קיים, עם תקרת הקיבולת שלו שיש לנטר.

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

מה שתבחרו, בדקו שלושה זרמים: המיועד, זה שנדחה ואמור להישאר נדחה, ומקרה השחזור שבו שער ה-hub או peering למטה. מודל שמסביר רק את המסלול המאושר לא אומת, הוא הודגם.

אמתו את הבחירה מול ההצהרה שלה

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

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