האם Azure VNet המחובר בעמיתות זקוק לשער VPN משלו?
VNet המחובר בעמיתות יכול להשתמש בשער ה-VPN של ה-hub עם SKU נתמך ובהגדרה אחת בכל כיוון עמיתות. אמתו מסלולים אפקטיביים, לא את סטטוס העמיתות.
מופיע VNet spoke חדש, ל-hub כבר יש שער site-to-site פעיל, והשאלה המתבקשת היא אם עליכם לשלם עבור שער שני. בדרך כלל לא: תעבורת שער מאפשרת ל-spoke להשתמש בשער של ה-hub דרך העמיתות. שלושה תנאים קובעים אם זה יעבוד, ואף אחד מהם אינו נראה בתג הסטטוס של העמיתות. קישוריות העמיתות וההרשאה להשתמש בשער של מישהו אחר הן הגדרות נפרדות, ולכן שתי VM שכבר יכולות לבצע פינג זו לזו אינן מוכיחות דבר על נתיב ה-VPN.
התנאי הראשון: השער, והיעדרו ב-spoke
Azure תומך בתעבורת שער עבור SKU של VPN Gateway שאינם Basic, ועמיתות אזורית וגם גלובלית יכולות לשאת אותה. ה-spoke צורך שער שאינו בבעלותו, ולכן אינו יכול להחזיק שער משלו: אם כבר קיים שער ב-spoke, או שכבר נבחרה אפשרות של שער מרוחק, הגדרת התעבורה הרצויה לא תהיה זמינה או לא תהיה אפקטיבית. בדקו זאת לפני שתנחו משהו, כי תיבת הסימון המושבתת היא הסימפטום, לא התקלה. קראו תחילה את ה-SKU ואת השער הקיים, ורק אחר כך הביטו בהגדרות העמיתות.
אל תמחקו שער spoke קיים כדי שהאפשרות תופיע, עד שתדעו מה תלוי בו. סדר ההעברה חשוב יותר מתיבת הסימון.
התנאי השני: הגדרה אחת בכל כיוון עמיתות
עמיתות היא שני אובייקטים, אחד בכל VNet, והגדרות התעבורה נמצאות בצדדים שונים של הזוג הזה. העמיתות של ה-hub אל ה-spoke חייבת לאפשר לשער של ה-hub לשרת את ה-spoke; העמיתות של ה-spoke אל ה-hub חייבת לקבל את השער של ה-hub. מדריך תעבורת השער של Microsoft מפרט אותם לפי כיוון, וזו הדרך היחידה לשמור עליהם נכונים:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
פקד המסומן remote משנה משמעות בהתאם לעמיתות של איזה VNet אתם עורכים, לכן קראו את הכיוון, לא את המילה. הגדירו את שני הצדדים, שמרו, ואשרו שהעמיתות מדווחת על חיבור בשני המקומות.
התנאי השלישי: מרחב כתובות וגבולות הרשאה
תעבורה אינה יכולה לגרום לאותו קידומת יעד לייצג שתי רשתות, לכן טווחי ה-hub, ה-spoke והרשת המקומית חייבים להיות נפרדים לפני שמישהו מזה יעבוד. רשתות ה-VNet יכולות גם לשבת במנויים שונים או בדיירים שונים; זו אינה אסירה, אבל הזהות שיוצרת או מעדכנת כל עמיתות זקוקה להרשאות הנדרשות באותה רשת. שינויים בין מנויים נכשלים לעתים קרובות בגלל הרשאות, וקל לקרוא את השגיאה בטעות כבעיית טופולוגיה.
רשמו את הטווחים ואת הבעלים לפני השינוי. ניחוש בכל אחד מהם מייצר עמיתות שמתחבר ולא מנתב דבר.
אמתו באמצעות מסלולים אפקטיביים, לא באמצעות סטטוס העמיתות
הביטו במסלולים האפקטיביים בממשק הרשת של עומס עבודה ב-spoke ומצאו את קידומת הרשת המקומית בפועל. בדקו את טבלת המסלולים של תת-הרשת ואם הפצת מסלולי השער מושבתת, כי מסלול שהוגדר על ידי המשתמש או מכשיר בדיקה יכולים לעקוף את הנתיב שהדגלים של העמיתות מרמזים עליו. לאחר מכן אשרו את הכיוון האחר: הרשת המקומית חייבת לדעת כיצד להגיע לקידומת של ה-spoke דרך חיבור ה-site-to-site, בין באמצעות מודעות נלמדות ובין באמצעות מסלול מפורש ורשומת רשת מוגנת תואמת במכשיר הלקוח. אם הקידומת חסרה באחד הצדדים, הדגלים של העמיתות אינם הדבר שצריך לשנות.
בדקו שירות אחד מעומס עבודה ב-spoke ועקבו אחר התגובה. בדיקה משער ה-VPN או מ-VM ב-hub מפעילה קידומת מקור ונתיב שונים.
אם הטופולוגיה משרתת גם לקוחות point-to-site, אמתו בנפרד את המסלולים המותקנים שלהם. חבילות לקוח של Windows עשויות לדרוש יצירה מחדש לאחר שינוי טופולוגיה, וזו משימת ניתוב בצד הלקוח ולא הוכחה ששיתוף השער נכשל.
מה שיתוף שער אינו מעניק
תעבורת שער היא נוחות ניתוב, לא הרשאה. קבוצות אבטחה של רשת, מסננים מקומיים וכללים ברמת השירות עדיין קובעים למה עומס עבודה ב-spoke יכול להגיע, לכן הפעילו את השירות הספציפי מהמקור ליעד במקום להניח שהמנהרה המשותפת מתירה הכול מאחוריה.
גם עמיתות אינה טרנזיטיבית כפי שאנשים מקווים. הוספת spoke נוסף, או נקודת קצה פרטית, מכניסה דרישות ניתוב וגישה משלה שהגדרת התעבורה הקיימת אינה מכסה.