תעבורת החזרה של Azure P2S VPN פועלת רק בכיוון אחד

סמל המנהרה ירוק, ה-NSG נראה מתיר, המסלולים האפקטיביים נראים תקינים, ובכל זאת ה-VM אינו יכול לפתוח חיבור חזרה אל הלקוח המחובר. ההנחה המקובלת היא שמנהרת point-to-site תקינה היא סימטרית: אם הלקוח מגיע ל-VM, ה-VM מגיע ללקוח. ההנחה הזו היא השגיאה בהיגיון, לא בתצורה. מנהרה יכולה לשאת כיוון אחד של זרימה לא מבוקשת ולהפיל את השני, והתיקון תלוי באיזו שכבה מפילה אותו.

מיתוס: מנהרה מחוברת היא מנהרה דו-כיוונית

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

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

בדקו את הכיוון לפני בדיקת הנגישות

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

הצעד הבא הוא ראיות, לא עוד כללים. בדקו את ה-NSG בתת-הרשת של ה-VM בשני הכיוונים, קראו את המסלולים האפקטיביים ב-NIC של ה-VM, ולכדו מנות ב-VM בזמן שהלקוח שולח תעבורה. בקשה שמגיעה בלי תשובה היא בעיית מסנן או נתיב חזרה; בקשה שלעולם לא מגיעה היא בעיית נתיב. אל תראו בפינג כושל הוכחה שה-VM אינו נגיש, כי מדיניות ICMP יכולה להפיל את התשובה בזמן ש-TCP עובד.

נתיב החזרה של IKEv2 point-to-site הוא החשוד הרגיל

בדוח Azure שמאחורי המאמר הזה, לקוח הצליח להגיע ל-VM דרך IKEv2, אבל ICMP נכנס מה-VM אל הלקוח נכשל עד שסוג המנהרה של השער הוחלף ל-OpenVPN. מחבר הדוח מציין שמיקרוסופט אישרה מגבלה בנתיב IKEv2 point-to-site, שבה תעבורת חזרה מ-VM ללקוח אינה מנותבת באופן סימטרי אלא אם הלקוח התחיל את ההפעלה. IKEv2 נשען על בוררי תעבורה, והשער לא כיבד את כיוון החזרה במקרה הזה.

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

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

מיתוס: גילוי בשידור חוצה את גבול ה-VNet

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

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

מה לשנות, ואיך להוכיח זאת

אם בדיקת הכיוון נכשלת רק ב-IKEv2, תעדו את סוג המנהרה של השער, מאגר כתובות הלקוחות ואת בדיקת ה-ICMP או ה-TCP המדויקת, ואחר כך העריכו פרופיל OpenVPN מאושר עבור הלקוחות המושפעים. אם היא נכשלת בכל סוג מנהרה, עבדו על נתיב החזרה: כתובת הלקוח חייבת להיות ניתנת לניתוב מתת-הרשת של ה-VM, כל מסלול שמוגדר על ידי המשתמש חייב להצביע על קפיצה הבאה תקפה, וחומת האש של הלקוח חייבת לקבל את הזרימה הנכנסת. צרפו את ראיות ה-NSG והמסלולים לכרטיס.

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