NAT ב-Azure VPN אינו פותר כתובות VNet חופפות
שני VNet עם אותו טווח פרטי לא יתחברו רק מפני ש-NAT קיים. בדקו קודם את סוג החיבור, ואז מחדשו מספור או החזיקו בכינוי תרגום.
שני ה-VNet משתמשים ב-10.40.1.0/24, המנהרות עולות, ושום דבר לא עובד. הוספת שער VPN שני לא משנה את זה, וגם לא מדד מסלול נמוך יותר, כי הבעיה אינה בחירת נתיב. שני עומסי עבודה שעונים לאותה כתובת פרטית מותירים כל מנה עם יעד מעורפל ונתיב חזור שלא ניתן לאמת. לפני תכנון כל תרגום, גלו איזה סוג חיבור יצרתם בפועל, כי הבחירה האחת הזו קובעת אם תכונת ה-NAT של Azure זמינה בכלל.
מה התסמין באמת אומר לכם
כשמארח ב-VNet A שולח אל 10.40.1.10, טבלת הניתוב יכולה רק להצביע עליו לאנשהו. אם גם VNet B מכיל את 10.40.1.10, הכתובת הזו אינה יעד שהנתיב יכול להבחין בו; היא כתובת אחת עם שני בעלים.
השער השני שאנשים בדרך כלל פורסים לא עוזר. הוא נותן מנהרה נוספת, לא כתובת נוספת, והטווח המשוכפל עובר בתוך המנהרה ללא שינוי. הוא גם מכפיל את התצורה שעליכם לשמור עקבית. מה שהוא לא יכול לעשות הוא לגרום לכתובת אחת לומר שני מארחים.
גם שינוי הכתובות הציבוריות של עמיתי ה-VPN לא עושה דבר. הכתובות האלה מזהות את נקודות הקצה של המנהרה, בעוד שההתנגשות נמצאת בטווח הפרטי שנישא בפנים.
סוג החיבור קובע אם NAT זמין
ל-Azure VPN Gateway אכן יש יכולת NAT, והיא מתועדת עבור חיבורי IPsec בין אתרים מבוססי נתיב ב-SKU מסוימים של שער. מאותה תיעוד עצמו מוציאים חיבורי VNet-to-VNet ו-point-to-site, ולכן התכונה אינה תיבת סימון שמופיעה בכל יחסי שער.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
VNet-to-VNet מקורי גם דורש שטווחי ה-VNet והרשת המקומית לא יחפפו מלכתחילה, מה שמתיישב עם ההחרגה. גם עמיתות VNet אינה פתרון לחפיפה מאותה סיבה.
יש חלופה נתמכת שאנשים מבלבלים עם הסוג המקורי: למדל את ה-VNet האחר כרשת מקומית ולחבר אותו כחיבור מאתר לאתר. זהו משאב אחר ותכנון אחר, ולכן התייחסו לחיבור ששמו שונה כשינוי שצריך לאמת, לא כשם חדש בלבד.
מחדשים מספור, או מתרגמים עם משהו שמחזיק בכינוי
אם שני ה-VNet שלכם, השוו מחדוש מספור מתוכנן לעלות המתמשכת של התרגום. מחדוש מספור נוגע בתצורת היישומים, ברשומות ה-DNS, בכללי האבטחה ובכל חיבור קיים, אך מותיר רשת שנקראת באופן רגיל אחר כך. עשו זאת תת-רשת אחת בכל פעם, עם שינוי ה-DNS אחרון. טווח שמספורו חודש למחצה גרוע מכל אחת מהאפשרויות, כי אז שני התחיליות נראות סמכותיות למי שיקרא את הטבלה בהמשך.
כשמחדוש מספור אינו מעשי, השתמשו בתכנון מתורגם עם בעלים אמיתי לכינוי. קוראים ב-VNet A עשויים להגיע אל 10.40.1.10 של VNet B בתור 10.140.1.10, אבל הכינוי הזה זקוק להתקן שמתרגם, לנתיב אליו ולהתנהגות מתאימה לתשובה. כתובת שנוספה ל-DNS בלבד אינה תרגום.
תעדו את שני הטווחים בשני הכיוונים: מה הקורא מחייג, מה היעד רואה כמקור, ואיזה צד רשאי ליזום. כללי ה-NAT של Azure עצמם כוללים את התרגום ההפוך עבור מיפויי ה-SNAT שלהם, ולכן אינכם כותבים כלל DNAT מתאים ביד, אך הנוחות הזו נעצרת בסוגי החיבורים שהתכונה תומכת בהם.
מה לא יעבוד
נתיב מוגדר על ידי המשתמש או מדד מסלול לא יכולים ליצור הבחנת כתובות חסרה. שניהם פועלים על יעד שעדיין מעורפל, והמנה מגיעה לצומת הבא שהטבלה מעדיפה.
הוספת הטווח המשוכפל לטבלת ניתוב כתחילית ספציפית יותר רק מזיזה את העמימות צעד אחד. היא גם נוטה לשבור את הכיוון השני, שבו לתשובה יש עכשיו שני מקורות סבירים.
קבלו את התכנון עם תעבורה בשני הכיוונים
הוכיחו את התכנון בפעולה מורשית חדשה מכל צד, לא בסטטוס המנהרה. מנהרת IPsec מחוברת אומרת שהעמיתים מסכימים על הצפנה; היא לא אומרת דבר על האם היעדים הפכו מובחנים.
לאחר מכן הריצו את הנתיבים הנדחים: כתובת שאמורה להישאר בלתי נגישה, ושירות שהמדיניות אמורה לחסום. אם שניהם עדיין מצליחים, התרגום רחב יותר ממה שהתכנון התכוון.
סיימו עם העובדות שיסבירו את ההתקנה בהמשך: הטווח המקורי, הטווח המוצג, ההתקן שמתרגם, והכיוון שכל צד רשאי ליזום בו. אם אחד מאלה חסר, המהנדס הבא יורש רשת שבה שני מארחים חולקים שם ואיש לא זוכר למה אחד מהם עונה.