למה מכונה וירטואלית עם מכשיר VPN ב-Azure מאבדת את נתיב החזרה
מכשיר VPN במכונה וירטואלית של Azure זקוק לכך שה-UDR, דגל העברת החבילות בכרטיס הרשת ומדיניות האורח יתאימו. עקבו אחר בקשת סניף אחת דרך שלושתם.
מכונה וירטואלית של Azure שמריצה מכשיר VPN נמצאת בתוך שתי מערכות החלטה בלתי תלויות. Azure מחליט מהיכן חבילה יוצאת מתת-רשת, באמצעות טבלאות נתיבים והגדרת העברת החבילות בכרטיס הרשת. מערכת ההפעלה של המכשיר עצמו מחליטה אם להעביר את החבילה המפוענחת הלאה. מנהרה שעולה בצורה מושלמת עדיין עלולה להיכשל במערכת השנייה, ושם נעצרות רוב הפריסות האלה.
שלושה בעלים לנתיב אחד
קחו רשת סניף 192.168.50.0/24 ותת-רשת של עומס עבודה 10.0.10.0/24, כשהמכשיר נמצא ב- 10.0.0.4 בתת-הרשת שלו. בקשה אחת נוגעת בשלוש תצורות נפרדות.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
כל שורה נמצאת בבעלות צוות אחר ברוב הארגונים, ולכן התקלה הזו מגיעה בדרך כלל כשלושה קריאות במקום אחת.
הנתיב שמצביע אל המכשיר
שייכו טבלת נתיבים לתת-רשת של עומס העבודה ותנו לקידומת הסניף קפיצה הבאה מסוג Virtual appliance עם 10.0.0.4 ככתובת. השתמשו בכתובת הפרטית הנגישה של המכשיר, ולעולם לא בנקודת הכניסה הציבורית של ה-VPN שלו. הקפיצה הבאה חייבת להיות כתובת שתת-הרשת של עומס העבודה כבר יכולה להגיע אליה. השאירו את שאר הניתוב של עומס העבודה כמו שהוא, אלא אם החלטתם במכוון להחליף את נתיב ברירת המחדל.
החזיקו את המכשיר בתת-הרשת שלו, וודאו שהנתיב ששולח תעבורת סניף אל המכשיר לא לוכד גם את נתיב היציאה של המכשיר עצמו. לולאה כזו נראית כמו מנהרה תקינה בלי תשובות, וזה דבר מאוד לא נעים לניפוי באגים בשעה 2 בלילה.
דגל כרטיס הרשת שכולם שוכחים
ב-Azure יש הגדרת העברת IP לכל כרטיס רשת, והיא כבויה כברירת מחדל. היא קיימת מפני שכרטיס שמעביר חבילות מקבל חבילות שמופנות למשהו אחר, והשלכתן בשקט היא ברירת המחדל הבטוחה לכל השאר.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true מפעיל אותה עבור ממשק אחד. ההנחיות של Microsoft בנושא העברת חבילות בכרטיס הרשת דורשות את ההגדרה בכל כרטיס מחובר שמעביר תעבורה, כך שמכשיר עם כרטיס אחד עדיין צריך אותה בכרטיס הזה.
הדגל אינו נתיב והוא אינו כלל חומת אש. הפעלתו מעניקה הרשאה ולא דבר אחר.
מה האורח עושה עם החבילה המפוענחת
כשהמנהרה מסתיימת, המחסנית של המכשיר עצמו מקבלת את ההחלטה הבאה. באורח Linux, העברת IPv4 היא הגדרה בזמן ריצה, ו- sysctl -w net.ipv4.ip_forward=1 נמשכת עד האתחול הבא. שמרו אותה בקובץ תחת /etc/sysctl.d/ במקום זאת. למכשיר של ספק יש מקבילה משלו, והוראות Linux שמודבקות בפלטפורמה של ספק בדרך כלל לא עושות דבר כלל.
מדיניות חומת האש של האורח נפרדת שוב, וכך גם קבוצת האבטחה של הרשת של עומס העבודה. התרת UDP 500 ו-4500 לכתובת הציבורית של המכונה מגנה על המנהרה; היא לא אומרת דבר על האם בקשת סניף מפוענחת יכולה להגיע לפורט של עומס עבודה.
עקבו אחר בקשה אחת והתשובה שלה
בחרו זרם מותר אחד ועקבו אחריו מקצה לקצה. הסניף זקוק לנתיב עבור 10.0.10.0/24 דרך חיבור האתר, המכשיר זקוק לנתיב מסירה אל תת-הרשת של עומס העבודה, ותת-הרשת של עומס העבודה זקוקה לנתיב חזרה אל הסניף.
החליטו מוקדם אם התכנון שומר על כתובת המקור של הסניף או מתרגם אותה. NAT משנה את מה שעומס העבודה רואה, ולכן כללי הגישה שלו צריכים לתאר את המודל שבחרתם בפועל ולא כתובת שער משוערת.
לחיצת יד מוצלחת מוכיחה חוליה אחת בשרשרת הזו. הנתיב שלם כשהתשובה חוזרת דרך אותו מכשיר והמדיניות של עומס העבודה עצמו מתירה זאת.