כיצד אפליקציית אינטרנט של Azure מגיעה למקום באמצעות VPN
חומת האש של המשרד רואה את תת-רשת האינטגרציה שלך, לא את הכתובת הציבורית של האפליקציה. תקן את טווח המקור, הבוררים ונתיב החזרה לפני האשמת המנהרה.
הבקשה היוצאת של ה-Web App משאירה עובד שאתה אף פעם לא רואה, ממקור שלא בחרת, וחומת האש של המשרד צריכה לקבל זאת. זו כל הבעיה במשפט אחד. אינטגרציה אזורית של VNet נותנת לבקשה נתיב לרשת וירטואלית, וה-VPN מאתר לאתר נושא אותה משם. כל מה שמשתבש לאחר מכן הוא על איזה טווח מקור ואיזה מסלול השתמשה החבילה בפועל.
מה העובד שולח בפועל
App Service מפעיל את הקוד שלך על עובדים שיושבים מחוץ לתצוגת הרשת של המנוי שלך. כאשר אינטגרציה אזורית מופעלת, תעבורה יוצאת מועברת לרשת משנה מואצלת ברשת VNet באותו אזור, והחבילה מופיעה שם לפני שהיא ממשיכה. השילוב אינו מעביר את האפליקציה ל-VNet ואינו משנה את הכתובת הנכנסת שלה. זה רק נותן לזרימות היוצאות קפיצה ראשונה שונה.
כברירת מחדל, רק שטח כתובות פרטי לוקח את הנתיב הזה, כך שיעדי אינטרנט רגילים עדיין יוצאים ישירות מהעובד. ניתוב הכל דרך ה-VNet הוא הגדרה נפרדת והחלטה נפרדת, מכיוון שהוא גם שולח את התלות הציבוריות שלך על פני המנהרה.
תעבורת תצורה, כגון משיכת תמונת מיכל בעת ההפעלה, פועלת לפי כללי הניתוב שלה ויכולה להיכשל בזמן שקריאות ה-API שלך מצליחות.
רשת המשנה של השילוב היא המקור שעליך לאפשר
המשרד רואה את טווח הכתובות של רשת המשנה של האינטגרציה, או כל מה שהמכשיר שלך מתרגם לו, לא את הכתובות הציבוריות היוצאות של האפליקציה. הכניסו את הטווח הזה לבוררי התעבורה של ה-VPN של האתר ולכלל חומת האש המקומית. אם המנהרה מבוססת על מדיניות, בוררים שמשמיטים אותה משחררים את החבילה גם כאשר קיים נתיב.
אל תאפשר לכתובת אחת של עובד שראיתי במקרה. מופעים משתנים עם קנה המידה ותחזוקת הפלטפורמה, וכלל המוצמד לכתובת אחת נשבר ברגע הגרוע ביותר.
שמור על צד היעד צר: שירות אחד, נמל אחד, כיוון אחד, כאשר נתיב ההחזרה מותר במפורש.
הצצה ומעבר שער הם מפורשים
אם שער ה-VPN יושב ב-hub VNet ורשת המשנה של האינטגרציה בחישור, הנתיב צריך מעבר שער המותר ב-hub-peering ושימוש ב-gateway מרוחק מופעל על-peering חישור. הצצה כשלעצמה נושאת תעבורה בין שני ה-VNets ותו לא. המסלולים היעילים ברשת המשנה של האינטגרציה הם המקום שבו אתה מאשר שהשער הבא hop באמת קיים.
עיצוב רכזת ודיבור שטבלת המסלולים שלו שולחת 0.0.0.0/0 לחומת אש היא גרסה נפוצה, וחומת האש הזו צריכה אז כלל משלה לקידומת המקומית.
צייר את הנתיב על נייר לפני פתיחת כרטיס עם צוות הרשת, כי זה חוסך יום של ניחושים. כלול את כיוון החזרה בשרטוט, מכיוון שזהו חצי האנשים ששכחו.
נקודת קצה פרטית נכנסת היא הכיוון השני
נקודת קצה פרטית מאפשרת גישה לאפליקציה מתוך VNet. זה לא עושה כלום לשיחה היוצאת של האפליקציה למשרד, וצוותים מגדירים אותה באופן קבוע בזמן שהדרישה בפועל הייתה הפוכה.
תיעוד ישן יותר מתאר אינטגרציה שנדרשת שער הבנויה על VPN מנקודה לאתר, תכונה שונה עם דרישות משלה. מיקרוסופט מתזמן את פרישה של תכונה זו ל-31 במרץ 2027, וממליצה במקום זאת על שילוב אזורי.
אל תעתיק תצורה מדור קודם של נקודה לאתר רק בגלל שדוגמה ישנה השתמשה בה.
אמת עם ההקשר של האפליקציה עצמה
בדוק מהאפליקציה שנפרסה, לא מהמחשב הנייד שלך ולא מ-VM באותו VNet. רשום בנפרד את הכתובת שנפתרה, תוצאת החיבור והתגובה ברמת היישום, בגלל כשל DNS, פסק זמן של TCP ונקודת דחיית אימות אצל שלושה בעלים שונים. אם פתרון השם נכשל, תקן DNS פרטי עבור ה-VNet לפני נגיעה במנהרה.
סטטוס מנהרה ירוקה רק מוכיח שהשער פתוח. זה לא אומר כלום על בוררים, כללי חומת אש או DNS.
כשהבקשה תעבוד סוף סוף, כתוב את טווח המקור, יציאת היעד ואזור ה-DNS לתוך ספר ההפעלה של האפליקציה. האדם הבא לנפות באגים זה יתחיל מההערה שלך במקום מדף הסטטוס של השער.