VPN עם IP פרטי ב-Azure מעל ExpressRoute ללא NVA

המיתוס הוא שהצפנת תעבורה מעל peering פרטי של ExpressRoute דורשת התקן רשת וירטואלי. זה לא נכון. Azure תומך ב-Site-to-Site VPN Gateway שנקודת הקצה של המנהרה שלו היא כתובת RFC1918 פרטית הנישאת על גבי המעגל, וההתקן הוא אופציונלי ולא מבני. מה שמיתוס ההתקן מסתיר הוא החלק שבאמת כואב: הפעלת נקודת הקצה הפרטית על אובייקט אחד במקום שניים, ונתינת נתיב peering ישיר לנצח בשקט על הנתיב המוצפן.

מאין בא המיתוס

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

שום דבר מזה לא מוציא את ה-NVA לפנסיה. הוא מוציא לפנסיה את ההנחה שהתקן הוא הדרך היחידה לדרישה.

הפעילו את נקודת הקצה הפרטית בשני הרמות

התחילו מחיבור peering פרטי של ExpressRoute שעובד ומקושר ל-VNet שמכיל את שער ה-VPN. הצד המקומי חייב כבר להגיע לכתובות הפרטיות הרלוונטיות דרך המעגל הזה, מפני שהמנהרה תשתמש בכתובות האלה כתובלה. אחר כך התנאי המוקדם של השער: הנוהל של Microsoft ל-VPN עם IP פרטי דורש שער שנבנה על משאב IP ציבורי Standard. מיעון מנהרה פרטי אינו מסיר את הדרישה הזו, מה שמפתיע אנשים שמניחים ש„פרטי“ פירושו „בלי IP ציבורי בשום מקום“.

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

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

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

המיתוס השני: מנהרה מבוססת מצפינה את התעבורה שלכם

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

שיטות ההיגוי המתועדות הן טווח מכסה ב-ExpressRoute עם טווח מוגן ספציפי יותר ב-VPN, או קידומות נפרדות בשני הנתיבים. להמחשה, peering פרטי יכול לשאת 10.40.0.0/16 בעוד ה-VPN מכריז על 10.40.12.0/24. הקידומת הספציפית יותר מנצחת ושאר הטווח נשאר ישיר.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

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

החליטו מה קורה כשהמנהרה נופלת

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

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

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