साइट-देखि-साइट सुरुङ चालु छ, स्थानीय ग्राहकले केही 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 ट्यागले के समेट्छ परिवर्तन गर्न सक्छ।

सम्बन्धित लेखहरू