Azure साइट-टू-साइट VPN रहदारीसाठी NSG कुठे लागू करावे

साइट-टू-साइट सुरंग कार्यरत आहे, स्थानिक क्लायंट काही Azure होस्टपर्यंत पोहोचतो आणि काहीपर्यंत नाही, आणि कोणीतरी ते दुरुस्त करण्यासाठी GatewaySubnet वर नेटवर्क सुरक्षा गट जोडला आहे. तिथेच थांबा. Azure GatewaySubnet वर NSG ला समर्थन देत नाही, आणि गट वर्कलोड नियमाप्रमाणे अंतर्गत पॅकेट पाहू शकत नाही. धोरण गंतव्य सबनेट किंवा NIC वर ठेवा, डिक्रिप्शननंतर अस्तित्वात असलेला स्रोत पत्ता जुळवा आणि नंतर जुन्याऐवजी नवीन कनेक्शनने तपासा.

Azure जिथे त्याचे मूल्यांकन करते तिथे NSG ठेवा

वर्कलोड फिल्टरिंगसाठी समर्थित सीमा गंतव्य सबनेट किंवा गंतव्य नेटवर्क इंटरफेस आहे. गेटवे सबनेट ही पायाभूत सुविधा आहे, आणि तिथे NSG समर्थित नाहीत आणि गेटवेच्या कार्यात अडथळा येऊ शकतो असे Azure नोंदवते.

ठेवण्यात एक तार्किक अडचणही आहे. GatewaySubnet वरील NSG बाह्य 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

डिक्रिप्शननंतर स्रोत पत्ता शोधा

अंतर्गत स्रोत म्हणजे स्थानिक क्लायंटचा खाजगी पत्ता, किंवा उपकरण किंवा VPN NAT भाषांतरानंतर सादर करते तो पत्ता. हा स्थानिक VPN गेटवेचा सार्वजनिक पत्ता नाही, तो बाह्य देवाणघेवाणीचा आहे.

NAT हा रचनेचा भाग असल्यास, गृहीत धरण्याऐवजी सादर केलेल्या स्रोताची पुष्टी करा. Azure VM वर पॅकेट कॅप्चर, किंवा सेवेच्या कनेक्शन लॉगमधील स्रोत फील्ड, स्थानिक संरचना वाचण्यापेक्षा लवकर प्रश्न सोडवते. नंतर त्या पत्त्यावर आणि खऱ्या गंतव्य पोर्टवर नियम लिहा.

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 सेवा टॅग स्थानिक व्हर्च्युअल नेटवर्कपेक्षा विस्तृत आहे. त्याच्या व्याख्येत जोडलेली स्थानिक पत्ता जागा, पीअर केलेली नेटवर्क आणि गेटवेने जोडलेले इतर प्रीफिक्स समाविष्ट आहेत. त्यामुळे VirtualNetwork पर्यंत मर्यादित डीफॉल्ट परवानगी नियम ऑपरेटरने बाह्य मानलेल्या सुरंग रहदारीला आधीच परवानगी देऊ शकतो.

अरुंद नियम जोडण्यापूर्वी डीफॉल्ट नियम वाचा, आणि आधी जुळू शकणारा प्रत्येक उच्च-प्राधान्य नियम वाचा. स्पष्ट परवानगी जोडल्याने प्रवाहाला आधीच परवानगी देणारा विस्तृत नियम काढला जात नाही. धोरण नकार आवश्यक असल्यास, तो परवानगीपूर्वी खरोखर मूल्यांकन होणाऱ्या प्राधान्यावर ठेवा.

Microsoft चे सेवा टॅग दस्तऐवज VirtualNetwork टॅग काय समाविष्ट करतो ते सूचीबद्ध करते, आणि टॅगचा अर्थ केवळ VNet श्रेणी आहे असा युक्तिवाद कोणी केल्यास उद्धृत करण्याचा संदर्भ तोच आहे.

दोन्ही सीमांवर प्रभावी नियम वाचा

सबनेट NSG आणि NIC 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 संबद्धता आणि जुळणारा नियम मंजूर सेवेसह नोंदवा, कारण पुढील पीअरिंग किंवा मार्ग बदल VirtualNetwork टॅग काय समाविष्ट करतो ते बदलू शकतो.