Azure मा VPN उपकरण भएको VM ले फिर्ता मार्ग किन गुमाउँछ
Azure VM मा रहेको VPN उपकरणले UDR, NIC को फर्वार्डिङ फ्ल्याग र पाहुना नीति तीनवटै मिल्नुपर्छ। एउटा शाखा अनुरोध तीनैबाट पछ्याउनुहोस्।
VPN उपकरण चलाउने Azure VM दुई स्वतन्त्र निर्णय प्रणालीभित्र बस्छ। प्याकेट कुन सबनेटबाट बाहिरिन्छ भन्ने Azure ले रुट तालिका र NIC को फर्वार्डिङ सेटिङ प्रयोग गरी तय गर्छ। डिक्रिप्ट भएको प्याकेट अगाडि पठाउने हो कि होइन भन्ने उपकरणको आफ्नै अपरेटिङ सिस्टमले तय गर्छ। पूर्ण रूपमा माथि उठेको टनेल पनि दोस्रो प्रणालीमा असफल हुन सक्छ, र यस्ता धेरैजसो तैनाती त्यहीँ रोकिन्छन्।
एउटै मार्गका तीन मालिक
एउटा शाखा नेटवर्क लिनुहोस् 192.168.50.0/24 र एउटा वर्कलोड सबनेट लिनुहोस् 10.0.10.0/24, उपकरण यो ठेगानामा छ 10.0.0.4 यसको आफ्नै सबनेटमा। एउटा अनुरोधले तीन अलग कन्फिगरेसन छुन्छ।
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
धेरैजसो संस्थामा प्रत्येक पङ्क्तिको मालिक फरक टोली हुन्छ, त्यसैले यो खराबी सामान्यतया एउटाको सट्टा तीन टिकटको रूपमा आउँछ।
उपकरणतर्फ देखाउने मार्ग
वर्कलोड सबनेटसँग रुट तालिका जोड्नुहोस् र शाखा उपसर्गलाई Virtual appliance प्रकारको अर्को हप दिनुहोस् 10.0.0.4 ठेगानाको रूपमा। उपकरणको पुग्न सकिने निजी ठेगाना प्रयोग गर्नुहोस्, कहिल्यै पनि यसको सार्वजनिक VPN प्रवेश बिन्दु। अर्को हप वर्कलोड सबनेटले पहिले नै पुग्न सक्ने ठेगाना हुनुपर्छ। डिफल्ट मार्ग जानाजानी बदल्ने निर्णय नगरेसम्म वर्कलोडको बाँकी राउटिङ जस्ताको तस्तै राख्नुहोस्।
उपकरणलाई यसको आफ्नै सबनेटमा राख्नुहोस् र शाखा ट्राफिक उपकरणतर्फ पठाउने मार्गले उपकरणको आफ्नै बाहिरिने मार्ग पनि नसमातोस् भन्ने सुनिश्चित गर्नुहोस्। यस्तो लुप शून्य उत्तर भएको स्वस्थ टनेलजस्तो देखिन्छ, र राति 2 बजे यसलाई डिबग गर्न धेरै कष्टकर हुन्छ।
सबैले बिर्सने NIC फ्ल्याग
Azure मा प्रत्येक NIC का लागि IP फर्वार्डिङ सेटिङ छ, र त्यो पूर्वनिर्धारित रूपमा बन्द छ। यो यसकारण छ कि फर्वार्ड गर्ने NIC ले आफूलाई नभई अरू कुनैलाई पठाइएका प्याकेट प्राप्त गर्छ, र तिनलाई चुपचाप फाल्नु बाँकी सबैका लागि सुरक्षित पूर्वनिर्धारित हो।
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true यसलाई एउटा इन्टरफेसका लागि खोल्छ। Microsoft का NIC फर्वार्डिङ निर्देशिका ट्राफिक फर्वार्ड गर्ने प्रत्येक जोडिएको NIC मा यो सेटिङ माग्छन्, त्यसैले एउटै NIC भएको उपकरणले पनि त्यो NIC मा यो सेट गर्नुपर्छ।
फ्ल्याग कुनै मार्ग होइन र फायरवाल नियम पनि होइन। यो खोल्दा अनुमति मात्र मिल्छ, अरू केही होइन।
पाहुनाले डिक्रिप्ट भएको प्याकेटसँग के गर्छ
टनेल सकिएपछि उपकरणको आफ्नै स्ट्याकले अर्को निर्णय गर्छ। Linux पाहुनामा IPv4 फर्वार्डिङ रनटाइम सेटिङ हो, र sysctl -w net.ipv4.ip_forward=1 अर्को बुटसम्म टिक्छ। यसलाई सट्टा एउटा फाइलमा /etc/sysctl.d/ सुरक्षित गर्नुहोस्। विक्रेताको उपकरणको आफ्नै समकक्ष हुन्छ, र विक्रेता प्लेटफर्ममा टाँसिएका Linux निर्देशनहरूले सामान्यतया केही पनि गर्दैनन्।
पाहुनाको फायरवाल नीति फेरि अलग छ, र वर्कलोडको नेटवर्क सुरक्षा समूह पनि। VM को सार्वजनिक ठेगानामा UDP 500 र 4500 अनुमति दिनुले टनेल जोगाउँछ; डिक्रिप्ट भएको शाखा अनुरोध वर्कलोड पोर्टसम्म पुग्न सक्छ कि भन्नेबारे यसले केही भन्दैन।
एउटा अनुरोध र त्यसको उत्तर पछ्याउनुहोस्
एउटा अनुमति दिइएको प्रवाह छान्नुहोस् र सुरुदेखि अन्तसम्म पछ्याउनुहोस्। शाखालाई मार्ग चाहिन्छ 10.0.10.0/24 साइट जडानबाट, उपकरणलाई वर्कलोड सबनेटसम्म पुर्याउने मार्ग चाहिन्छ, र वर्कलोड सबनेटलाई शाखातर्फ फर्कने मार्ग चाहिन्छ।
डिजाइनले शाखाको स्रोत ठेगाना राख्छ कि अनुवाद गर्छ भन्ने चाँडै तय गर्नुहोस्। NAT ले वर्कलोडले देख्ने कुरा बदल्छ, त्यसैले यसका पहुँच नियमहरूले तपाईंले वास्तवमा छान्नुभएको मोडेल वर्णन गर्नुपर्छ, अनुमानित गेटवे ठेगाना होइन।
सफल ह्यान्डशेकले त्यो साङ्खलाको एउटा कडी प्रमाणित गर्छ। उत्तर त्यही उपकरणबाट फर्केर आउँदा र वर्कलोडको आफ्नै नीतिले अनुमति दिँदा मार्ग पूर्ण हुन्छ।