VM של Azure לא מגיע ל-IMDS או ל-WireServer לאחר שה-VPN מתחבר

המכונה פועלת, לקוח ה-VPN אומר שהוא מחובר, וזמן קצר לאחר מכן סוכן Azure מתחיל לדווח על מצב לא תקין. לפעמים SSH שורד ואילו Run Command מהפורטל לא, מה שמפנה אנשים לסוכן במקום לטבלת הניתוב. החלטות ההעברה של האורח עצמו השתנו כשהמנהרה עלתה, ושתי כתובות פלטפורמה הן בדרך כלל הקורבנות הראשונות. אני מתייחס לזה כאל תסמין ניתוב לפני שאני מתייחס לזה ככשל של הסוכן.

התסמין נראה כמו סוכן מקולקל

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

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

168.63.129.16 אינו יעד ציבורי

168.63.129.16 הוא הכתובת הווירטואלית המיוחדת של פלטפורמת Azure, ואחד מתפקידיה הוא WireServer, שבו משתמש סוכן המכונה כדי לדבר עם האריג. מיקרוסופט מתעדת שתעבורת הסוכן אל פורטי TCP 80 ו-32526 חייבת להישאר זמינה. זה אינו מארח אינטרנט רגיל, וזה אינו משהו ש-VPN במנהרה מלאה אמור לשאת ליציאה מרוחקת. לכן מנהרה שנראית בריאה עדיין עלולה להרעיב את הסוכן.

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

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

ל-169.254.169.254 יש כללים משלו

169.254.169.254 הוא הכתובת link-local של שירות Azure Instance Metadata Service. לבקשות אליו יש דרישות משלו: כרטיס הרשת הראשי וכתובת ה-IP הראשית, תצורת DHCP שתומכת בכתובת, ועקיפת כל פרוקסי HTTP. שליחתן דרך יציאת VPN מרוחקת או שער אינטרנט שרירותי אינה מודל הגישה שמיקרוסופט מתארת.

סעיף הפרוקסי הזה תופס אנשים שתיקנו את המסלול ועדיין רואים כשלים. פרוקסי HTTP באורח יכול לשבור את IMDS בעוד ש-ip route get מחזיר בדיוק את הממשק שאתה מצפה לו, לכן בדוק גם את חריגי הפרוקסי ולא רק את המסלולים.

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

קרא את ניתוב המדיניות של האורח, לא רק את הטבלה הראשית

באורח Linux שלוש פקודות לקריאה בלבד מפרידות בין השכבות: ip -4 rule show לכללי המדיניות, ואז ip -4 route get 168.63.129.16 ו-ip -4 route get 169.254.169.254 להחלטות שהגרעין באמת מקבל. הרץ אותן לפני שה-VPN מתחבר ואחרי. ההבדל בין שתי הפלטים הוא מערך השינויים שלך, והוא שימושי יותר מכל ניחוש לגבי מה שהלקוח עשה.

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

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

הפרד ניהול משחזור

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

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

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