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 बदल देता है कि वर्कलोड क्या देखता है, इसलिए उसके एक्सेस नियमों को वही मॉडल बताना चाहिए जो आपने वास्तव में चुना है, अनुमानित गेटवे पता नहीं।
एक सफल हैंडशेक उस श्रृंखला की एक कड़ी सिद्ध करता है। रास्ता तब पूरा होता है जब उत्तर उसी उपकरण से होकर लौटता है और वर्कलोड की अपनी नीति उसे अनुमति देती है।