היכן להחיל NSG על תעבורת VPN מאתר לאתר ב-Azure

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

הציבו את ה-NSG במקום שבו Azure מעריכה אותו

הגבול הנתמך לסינון עומס עבודה הוא תת-הרשת או ממשק הרשת של היעד. תת-רשת של שער היא תשתית, ו-Azure מתעדת ש-NSG אינו נתמך שם ועלול לפגוע בפעולת השער.

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

בדקו את השיוכים הנוכחיים לפני שתשנו משהו, כדי שתדעו מה אתם מזיזים:

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

מצאו את כתובת המקור לאחר הפענוח

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

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

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

השתמשו בכלל אחד לכל שירות שתרצו לחשוף, והשאירו את רשימת הפורטים קצרה. כלל שמתיר את כל הפורטים מהטווח המקומי הופך את ה-NSG לפורמליות.

בדקו את היקף ברירת המחדל של VirtualNetwork

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

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

התיעוד של Microsoft לתגי שירות מפרט מה מכסה התג VirtualNetwork, וזה המקור לצטט כאשר מישהו טוען שהתג מתייחס רק לטווח ה-VNet.

קראו את הכללים האפקטיביים בשני הגבולות

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

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

אם כללי מנהל אבטחה של Azure Virtual Network Manager פעילים, בדקו גם את השכבה הזו. כלל ניהולי Always allow יכול להעביר תעבורה בלי הערכת NSG, בעוד ש-Deny ניהולי עוצר אותה לפני שה-NSG רואה אותה. סקירה של NSG בלבד אינה שלמה לסידור כזה.

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

אמתו בחיבור חדש

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

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

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