Azure साइट-टू-साइट VPN ट्रैफ़िक के लिए NSG कहाँ लगाएँ

साइट-टू-साइट सुरंग चालू है, स्थानीय क्लाइंट कुछ Azure होस्ट तक पहुँचता है और कुछ तक नहीं, और किसी ने इसे ठीक करने के लिए GatewaySubnet पर नेटवर्क सुरक्षा समूह जोड़ दिया है। वहीं रुकिए। Azure GatewaySubnet पर NSG का समर्थन नहीं करता, और समूह भीतरी पैकेट को वैसे नहीं देख सकता जैसे वर्कलोड नियम देखता है। नीति को गंतव्य सबनेट या NIC पर रखें, डिक्रिप्शन के बाद मौजूद स्रोत पते का मिलान करें, और फिर पुराने के बजाय नए कनेक्शन से जाँचें।

NSG को वहाँ रखें जहाँ Azure उसका मूल्यांकन करता है

वर्कलोड फ़िल्टरिंग की समर्थित सीमा गंतव्य सबनेट या गंतव्य नेटवर्क इंटरफ़ेस है। गेटवे सबनेट अधोसंरचना है, और Azure दस्तावेज़ करता है कि वहाँ NSG समर्थित नहीं हैं और गेटवे के संचालन को नुकसान पहुँचा सकते हैं।

रखाव में एक तार्किक समस्या भी है। 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 टैग क्या कवर करता है।