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