הגעה לאפליקציית Container Apps פרטית דרך VPN מנקודה לאתר
סביבת Container Apps פנימית זקוקה לכניסה פרטית, לשם מארח תואם ולמפענח שה-VPN יכול להגיע אליו. הפעילו כל שלב, ואז אמתו את הדחייה.
מדריך זה מכסה סביבת Container Apps עם פרופילי עומס עבודה וכניסת רשת וירטואלית פנימית, שאליה מגיעים ממחשב נייד דרך VPN מנקודה לאתר מאושר, תוך שימוש ב-FQDN הישיר של האפליקציה וללא נתיבי HTTP ברמת הסביבה. כניסת הסביבה נגישה מהלקוח, היקף הכניסה של האפליקציה מתיר את הקורא, ושם המארח מפוענח לכניסה הפרטית. כל שלב להלן משאיר תוצאה ניתנת לאימות וחזרה אחורה שאינה נוגעת בדבר שלא שיניתם. עברו עליהם בסדר הנתון, כי שום שלב מאוחר יותר אינו יכול לפצות על החלטת היקף שנעשתה בטעות בשלב 1.
לפני שנוגעים ב-DNS, הבהירו את המילה פנימי. היא משמשת לשני היקפים שונים במוצר הזה, וערבובם הוא הסיבה הנפוצה ביותר לכך ששם שעובד עדיין מחזיר דבר לא שימושי.
שלב 1: קבעו את היקף הסביבה והאפליקציה
קראו את תצורת הכניסה של האפליקציה לפני שינוי של כל רשומה:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
כניסה פנימית נחשפת במאזן העומסים הפנימי של הסביבה בתוך ה-VNet של הסביבה, ולכן השאלה אינה אם המחשב הנייד הוא אפליקציית מכולה אחרת, אלא אם הוא יכול להגיע ל-VNet הזה. לקוח VPN עם נתיב אל ה-VNet והדומיין המוגדר כברירת מחדל של הסביבה שמפוענח דרך האזור הפרטי הוא קורא כשיר, וזה בדיוק מה שהשלבים הנותרים בונים. סביבה פנימית ללא כניסה ציבורית היא עובדה שונה מאפליקציה עם כניסה פנימית, וכניסה חיצונית ברמת האפליקציה אינה נותנת לסביבה דלת ציבורית. כתבו את ההיקף בכרטיס וגם בפורטל, כי המהנדס הבא קורא קודם את הכרטיס.
אשרו את ההיקף הזה עם בעל התצורה לפני שתמשיכו, והשאירו את השער צר: אם אין נתיב אל ה-VNet של הסביבה, או שהדומיין המוגדר כברירת מחדל של הסביבה אינו מפוענח דרך האזור הפרטי, עצרו ותקנו קודם את הנתיב הזה. שום שלב מאוחר יותר אינו יכול להחליף קורא שאינו יכול להגיע ל-VNet או לפענח את השם.
שלב 2: אספו את שם המארח האמיתי ואת כתובת הכניסה
רשמו את הדומיין המוגדר כברירת מחדל של הסביבה, את כתובת הכניסה הפרטית הקבועה שלה ואת ה-FQDN המוגדר של האפליקציה, מתוך המשאב ולא מצילום מסך ישן או מעמוד ויקי:
az containerapp env show -n ENV -g RG \
--query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
--query "properties.configuration.ingress.fqdn"הוראות הכניסה הפרטית של Container Apps מתארות התאמה של דומיין הסביבה לכתובת הפנימית שלו תוך שמירה על שמות המארח של היישום ללא שינוי. זה בדיוק הצורה שאתם בונים כאן ביד, לכן יישרו את תוכן האזור איתה במקום להמציא סכימת שמות חדשה.
אם הדומיין שקראתם אינו תואם ל-FQDN שהאפליקציה מדווחת, עצרו ויישרו ביניהם עכשיו. בניית אזור על הסיומת השגויה מייצרת שם מארח שמפוענח היטב ובכל זאת נוחת במארח הווירטואלי השגוי.
שלב 3: הציבו את האזור הפרטי בנתיב המפענח של ה-VPN
צרו או השתמשו מחדש באזור ה-DNS הפרטי הנתמך עבור הדומיין המוגדר כברירת מחדל בפועל של הסביבה, כאשר רשומות תו הכל ותווית הכתובת המתועדות מצביעות לכניסה הקבועה. קשרו את האזור הזה לרשת הווירטואלית המתאימה, והפכו את הסמכות הפרטית לנגישה דרך נתיב המפענח המאושר של ה-VPN במקום להניח שהקישור מספיק.
לקוח מנקודה לאתר זקוק בדרך כלל לנקודת קצה נכנסת של מפענח פרטי או למעביר DNS נתמך כדי להגיע לאזור הזה. קישור אזור משנה את מה ש-Azure מפענח עבור רשתות מקושרות; הוא אינו מפנה מחדש את המפענח הציבורי של כל מחשב נייד חיצוני. אל תחליפו באזור DNS של נקודת קצה פרטית שהושאל ממודל רשת אחר של Container Apps, כי שמות הרשומות וסיומת האזור לא יתאימו.
החזרה אחורה עבור שלב זה היא הסרת קישור האזור או הרשומה שהוספתם. רשמו איזה משניהם היה, כי מחיקת אזור משותף כדי לבטל קישור בודד היא דרך ידועה לשבור סביבה שנייה.
שלב 4: בדקו את השם, ואז את הקהל הנדחה
בדקו את שם המארח וזהות ה-TLS יחד, לא רק את הכתובת. לאבחון ממופה שמות מבוקר תוכלו לנעוץ את הכתובת תוך שמירה על שם המארח:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/החליפו את שם המארח ב-FQDN האמיתי של האפליקציה ואת הכתובת בכניסה הפנימית האמיתית. זה משפיע על הבקשה האחת הזו בלבד ואינו הקצאת DNS. אל תוסיפו -k כדי להפוך כשל זהות למעבר לכאורה, כי אי-התאמת תעודה היא הסימן שאתם פוגעים במאזין השגוי.
בקשה ישירה של הכתובת המספרית עלולה לבחור במארח הווירטואלי השגוי או להיכשל באימות גם כשמתקבלת תשובת TCP 443, לכן התייחסו לבדיקת IP מוצלחת כראיה על הרשת ולא יותר. מהמחשב הנייד המיועד, נתיב המפענח הרגיל הוא מעביר ה-DNS של הלקוח או נקודת הקצה הנכנסת של המפענח הפרטי שמארח את האזור, וכשל שם הוא בעיית נגישות של המפענח ולא רשומה חסרה. אשרו שאותה בקשה מצליחה בנתיב הזה, ואז אשרו שהקהל הנדחה עדיין נדחה.
מה לתעד ומה להחזיר אחורה
פורט היעד של המכולה ופורט ה-HTTPS של הלקוח הם הגדרות נפרדות. אל תפרסמו את פורט היעד של המכולה דרך ה-VPN משום שהמכולה מאזינה שם, ואל תרחיבו כלל רשת כדי שבדיקת פורט תעבור. שני השינויים שורדים את התקרית וקשים לייחוס מאוחר יותר.
סיימו בפעולת יישום טרייה מהמחשב הנייד המיועד, עם הזהות המורשית וה-DNS הרגיל שלו, ואז בדקו שקורא לא מורשה עדיין נכשל. בזמן שאתם בתצורת האפליקציה, אשרו גם אם נתיב HTTP ברמת הסביבה חושף את האפליקציה הזו כיעד, כי הנתיב הזה הוא דלת שנייה שהיקף הכניסה אינו מתאר.
תעדו חמישה ערכים יחד: היקף הסביבה, היקף הכניסה של האפליקציה, FQDN, כתובת הכניסה הפרטית ובעל המפענח. החמישה האלה מתארים את כל חוזה הגישה, והאדם הבא שיתקן אותו יבקש בדיוק אותם.