למה Azure Point-to-Site VPN לא משנה את כתובת ה-IP הציבורית שלכם
מנהור point-to-site מעביר רק מסלולי רשת וירטואלית, כך שה-IP הציבורי שלכם נשאר מקומי עד שהמנהור הכפוי ו-SNAT של חומת האש מעבירים את היציאה ל-Azure.
אני מחבר את לקוח Azure VPN במחשב נייד עם Windows, פותח דף הד-כתובת ורואה את אותה כתובת ציבורית שהנתב הביתי שלי הקצה. בינתיים מארחת הקפיצה ב-10.20.0.4 עונה ושם נקודת קצה פרטית נפתר, כך שהמנהור לא שבור. שער point-to-site עושה בדיוק את מה שהתצורה המוגדרת כברירת מחדל שלו אומרת: הוא מעביר את הקידומות הפרטיות ומשאיר את כל השאר בקישור המקומי. קבלת כתובת יציאה בבעלות Azure היא שינוי בתכנון הניתוב, לא תיקון.
מה השער מכריז כברירת מחדל
השער דוחף מסלולים עבור מרחב הכתובות של הרשת הווירטואלית, בתוספת רשתות עמיתות שבהן מותר מעבר שער וקידומות מקומיות שנלמדו דרך חיבור site-to-site או BGP. אין 0.0.0.0/0 בקבוצה הזו. מערכת ההפעלה שלכם שומרת על מסלול ברירת המחדל ב-Wi-Fi או ב-Ethernet, כך שחבילה ל-API ציבורי לא נכנסת למנהור מלכתחילה.
הכתובת שלקוח מקבל בתוך המנהור היא חכירה פרטית ממאגר point-to-site. היא מזהה את הלקוח בפני משאבים ב-VNet; היא אינה כתובת שהאינטרנט יכול לראות, והיא לעולם לא תופיע כמקור של בקשה יוצאת ל-API של SaaS. רשומת רשימת היתרים שנבנתה סביב החכירה הזו לא יכולה לעבוד, ככל שתמתינו שהיא תופיע ביומני הספק.
מנהור מפוצל ומנהור כפוי זה לצד זה
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
רק השורה השנייה משנה את הכתובת ששירות מרוחק רואה. כל השאר בטבלה הוא עלות ומשטח תפעולי שאתם מקבלים כאשר היציאה חייבת להיבדק או להיות מתורגמת בתוך Azure. אם מישהו מבקש מכם לשנות את ה-IP הציבורי, הוא מבקש את כל העמודה הימנית, לא התאמה קטנה בלקוח.
יש אפשרות ביניים שראויה לשם לפני שתבנו מחדש משהו. מכונה וירטואלית של פרוקסי או שער בתוך ה-VNet נותנת כתובת מקור מבוקרת לאפליקציות שאפשר לכוון אליה, בלי להזיז את מסלול ברירת המחדל של הלקוח. זה משאיר גלישה רגילה מקומית ועדיין מספק שותף שזקוק רק לקריאת API אחת שתגיע מ-Azure. זה נכשל כשהדרישה באמת נוגעת לכל התעבורה, כי כל מה שמתעלם מהגדרת הפרוקסי עדיין יוצא מקומית.
גרמו למנהור לשאת את מסלול ברירת המחדל
בשער רשת וירטואלית, הדרך הנתמכת לנתב את כל תעבורת האינטרנט של הלקוח למנהור היא הוספת מסלולים מותאמים אישית לתצורת point-to-site. שני חצאים מכסים את כל מרחב IPv4, וכל אחד ספציפי יותר ממסלול ברירת המחדל המקומי, כך שהלקוח מעדיף אותם בלי למחוק דבר:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1השורה הזו להמחשה ולא שלמה להעתקה: הביאו תחילה את אובייקט השער עם Get-AzVirtualNetworkGateway והחליפו אותו ב-GWOBJ, ואשרו שה-SKU ומודל הפריסה מקבלים מסלולים מותאמים לפני שתפעילו אותו. אותן קידומות מופיעות בפורטל בעמוד תצורת point-to-site, וזה המקום הבטוח יותר לקבוע אותן אם אתם עדיין לא כותבים סקריפט לשער.
שינוי הקידומות האלה מבטל את חבילת הלקוח. הורידו שוב את חבילת לקוח ה-VPN והתקינו אותה מחדש, כי המסלולים נוסעים בתוך הפרופיל. לקוח שמתחבר מחדש עם הפרופיל הישן שומר על מערך המסלולים הישן, ואתם עשויים לאבד שעה בניפוי שינוי שמעולם לא הגיע אליו.
ברכז WAN וירטואלי מאובטח המקבילה היא מסלול ברירת מחדל בטבלת המסלולים של הרכז שמשויכת לשער point-to-site, כאשר Azure Firewall ברכז לוקח את התעבורה. חומת האש מתרגמת חיבורים לכיוון האינטרנט לכתובות ה-IP הציבוריות שלה, ומהתרגום הזה מגיעה כתובת היציאה החדשה. כשלחומת אש יש כמה כתובות IP ציבוריות, כל אחת מהן יכולה להופיע כמקור, ולכן רשימת היתרים חייבת להכיל את כולן.
שתי התכנונים שלמעלה הם IPv4. שתי הקידומות /1 לא עושות דבר ל-IPv6, והתמיכה של point-to-site ב-IPv6 צרה מספיק כדי שתבדקו את השילוב לפני שתבטיחו שוויון.
בדקו את המסלול, ואז את היציאה
אחרי התקנה מחדש של החבילה והתחברות מחדש, אשרו שהלקוח באמת התקין את החצאים. ב-Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 ואותה שאילתה עבור 128.0.0.0/1 אמורים לציין את ממשק המנהור, ו-route print מציג את שניהם לצד ברירת המחדל המקורית שלכם. ב-Linux, ip route show חייב להציג את שתי הקידומות; אם לא, הפרופיל מעולם לא נשא אותן.
אחר כך בדקו שוב את הכתובת הציבורית מהלקוח וקראו את יומן חומת האש עבור אותו חיבור. המקור אמור להיות ה-IP הציבורי של חומת האש עם פורט מתורגם. לקוח שעדיין יוצא מקומית כששני המסלולים קיימים פירושו שהחבילות הגיעו ל-Azure ויצאו בדרך אחרת: מסלול שהוגדר על ידי המשתמש בתת-הרשת של השער, חומת אש שמנותבת בכפייה לרשת המקומית, או מדיניות שמפילה את הזרימה לפני התרגום.
בדקו שוב יעד פרטי אחד באותו מושב. מארח קפיצה שמפסיק לענות אחרי השינוי הוא הסימן הרגיל לכך שהקידומות החדשות דחקו משהו, או מסלול מקומי צר יותר שהוכרז קודם או פתרון שמות שעובר כעת לפותר בלי מעביר לאזורים הפרטיים שלכם.
מתי להשאיר את המנהור המפוצל בשקט
אם המטרה היא רק להגיע ל-API פרטי, לנקודת קצה פרטית או לעמוד ניהול פנימי, ההתנהגות המוגדרת כברירת מחדל זולה ושקטה יותר. מנהור כפוי מוסיף שעות חומת אש ועלויות עיבוד נתונים, מסלול ארוך יותר ועוד מקום שבו כל זרימת לקוח יכולה להיכשל. הוא גם לוכד תעבורה הרבה יותר גדולה מהיעד הבודד שהיה לכם חשוב.
השתמשו בו כשהדרישה מנוסחת במונחי יציאה: שותף חייב לראות כתובת Azure קבועה, האבטחה רוצה שהחיבורים יירשמו וייבדקו, או שהנתונים חייבים לצאת דרך נקודה מבוקרת אחת. גם אז התכנון נותן לכל משתמש יציאה משותפת, ולכן אחריות לכל משתמש חייבת לבוא מזהות באפליקציה ולא מכתובת המקור.
לפני שתסגרו את השינוי, אשרו ארבעה דברים: חבילת הלקוח המותקנת היא החדשה, שני מסלולי ה-/1 יושבים על ממשק המנהור, יעד פרטי עדיין עונה, ויומן השירות המרוחק מציג את כתובת חומת האש.