Azure P2S: לקוח Windows אחד מאבד נתיבים לאחר שינוי ב-VNet

שני מחשבים ניידים מאמתים זהות מול אותו שער Azure point-to-site, ורק אחד מהם מגיע ל-VNet החדש שמחובר. שניהם מציגים Connected, כך שהאימות אינו ההבדל; הנתיבים ליעד שהם מחזיקים הם ההבדל. התחילו מהלקוח שנכשל, השוו יעד אחד, ורק אחר כך החליטו אם הפער שייך לחבילת השער או לטבלת הנתיבים המקומית.

התחילו מהלקוח שנכשל, לא מהשער

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

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

השוו יעד אחד עם route print

בחרו כתובת IP מורשית של משאב והשוו את שני המחשבים פעמיים: מנותקים ואחר כך מחוברים. ב-Windows, route print -4 מציג נתיבי IPv4 עם קידומת יעד, ממשק, קפיצה הבאה ומדד. רשמו את השורה שבאמת תנצח עבור אותו יעד, במקום לספור רשומות שמכילות את המילה VPN.

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

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

TTL expired אינו באג של חלוקת נתיבים

פינג שמחזיר TTL expired in transit אומר שהחבילה ניצלה את מכסת הקפיצות שלה, מה שבדרך כלל מעיד על לולאת העברה ולא על מנהל התקן VPN שבור. פינג של Windows מקבל TTL עד 255, והעלאת הערך אינה מתקנת לולאה; היא רק מעכבת את אותה שגיאה. התייחסו להודעה כסימפטום של הנתיב, לא כהוכחה על חלוקת נתיבים.

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

צרו את החבילה מחדש בשער שבבעלותו היא נמצאת

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

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

תרחישי הניתוב של Azure P2S מפרידים בין VNets בעמיתות ישירה לבין רשתות שנגישות דרך מנהרות אחרות, וחבילה חדשה אינה יכולה להפוך את העמיתה לטרנזיטיבית. תרחישים מסוימים של Windows site-to-site או BGP דורשים גם נתיבים מרוחקים שהוגדרו ידנית, ולכן רענון חבילה אינו מנגנון אוניברסלי לחלוקת נתיבים.

השאירו נתיב זמני כזמני

נתיב ידני יכול לבודד נתיב לקוח חסר, אבל בנו אותו מהתכנון האמיתי: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, בלי דגל ההתמדה, כך שהוא ייעלם באתחול. בחרו את אינדקס הממשק ואת הקפיצה הבאה מהמתאם VPN המחובר, לא מניחוש.

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

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