VPN מאתר לאתר ב-Azure עם עמית מאחורי NAT: רשימת בדיקה

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

שלב 1: ודאו שהעמית בכלל מאחורי NAT

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

אם שתי הכתובות זהות, עצרו כאן: NAT אינו הבעיה שלכם ושאר הרשימה לא יעזור.

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

שלב 2: הסכימו מי יוזם

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

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

צפו בחילופי IKE במכשיר בזמן ייזום ידני; שתיקה שם היא תשובת ניתוב או חומת אש, לא תשובה של Azure.

שלב 3: קבעו נכון את כתובת העמית

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

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

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

שלב 4: פתחו רק את הפורטים ש-NAT-T צריך

NAT-T נושא ESP בתוך UDP, ו-RFC 3948 מתאר את העטיפה הזו עם פורט 4500 שמשמש אחרי המשא ומתן הראשוני בפורט 500. חומת האש שלכם והמתרגם חייבים שניהם לאפשר את החילוף ואת תעבורת החזרה שלו. מתן היתר לפורט TCP לא קשור לא מוכיח דבר על הנתיב הזה, וכלל שמתיר יציאה אבל לא את התשובה עדיין ייכשל.

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

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

שלב 5: הפרידו בין תעבורה חיצונית לניתוב פנימי

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

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

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