EC2 पर Access Server फुल टनल: एक चेकबॉक्स क्यों पर्याप्त नहीं है
EC2 पर स्रोत और गंतव्य जाँच बंद करना फ़ॉरवर्डिंग का सुधार है, क्लाइंट की इंटरनेट नीति नहीं। Access Server में फुल टनल सेट करें और फिर AWS के निकास पथ का पता लगाएँ।
EC2 इंस्टेंस पर स्रोत और गंतव्य जाँच बंद करना Access Server के इंटरनेट निकास से जुड़े सवालों का सबसे ज़्यादा दोहराया जाने वाला उत्तर है, और अकेले यह आपके क्लाइंट के लिए कुछ नहीं करता। यह जाँच AWS की फ़ॉरवर्डिंग बाधा है: यह इंस्टेंस को ऐसे पैकेट स्वीकार करने देती है जिनका स्रोत या गंतव्य उसका अपना पता नहीं है। यह Access Server क्लाइंट को इंटरनेट ट्रैफ़िक टनल से भेजने को नहीं कहती, ऊपर की ओर कोई रूट नहीं बनाती और NAT नहीं जोड़ती। भ्रम यह है कि चेकबॉक्स ही सुविधा है।
जाँच वास्तव में क्या नियंत्रित करती है
हर EC2 नेटवर्क इंटरफ़ेस उस ट्रैफ़िक को गिरा देता है जो उसके पते पर नहीं है, जब तक इंस्टेंस राउटर, NAT उपकरण या VPN गेटवे की तरह काम न कर रहा हो और आप वह जाँच बंद न कर दें। इसे बंद करने से फ़ॉरवर्ड करने की अनुमति मिलती है। अनुमति कॉन्फ़िगरेशन नहीं है: इंस्टेंस को अब भी इंटरनेट गेटवे या NAT उपकरण तक रूट चाहिए, VPC रूट तालिका को अब भी मेल खाती प्रविष्टि चाहिए, सुरक्षा समूहों को अब भी प्रवाह की अनुमति देनी होगी, और सर्वर को अब भी वापसी ट्रैफ़िक का अनुवाद या रूटिंग करनी होगी।
कुछ भी बदलने से पहले aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck से वर्तमान मान जाँचें। यदि आप इसे कंसोल में बदलते हैं, तो इसलिए बदलें कि इंस्टेंस दूसरों के लिए फ़ॉरवर्ड करता है, इसलिए नहीं कि कोई क्लाइंट इंटरनेट तक नहीं पहुँचता।
क्लाइंट रूटिंग नीति Access Server की है
Access Server 3 में Access Controls खोलें और Internet Access and DNS अनुभाग खोजें। Internet Gateway चयन फुल टनल या विभाजित टनल देता है; फुल टनल क्लाइंट से कहता है कि वह अपना डिफ़ॉल्ट ट्रैफ़िक VPN में रूट करे, विभाजित टनल इंटरनेट ट्रैफ़िक को क्लाइंट के स्थानीय पथ पर छोड़ देता है। उत्पाद के वर्कफ़्लो से सहेजें और लागू करें, फिर परीक्षण क्लाइंट को दोबारा जोड़ें, क्योंकि नीति कनेक्शन के समय दी जाती है।
पुराने संस्करण अलग मेन्यू इस्तेमाल करते हैं और कुछ Community OpenVPN बिल्ड में समतुल्य नियंत्रण नहीं है। ऐसी स्क्रीन खोजने से पहले कि जो मौजूद नहीं है, स्थापित प्रमुख संस्करण जाँचें। फिर पुष्टि करें कि क्लाइंट को क्या मिला: फुल टनल प्रोफ़ाइल को टनल से होकर डिफ़ॉल्ट रूट स्थापित करना चाहिए, और विभाजित टनल प्रोफ़ाइल को ऐसा नहीं करना चाहिए।
टनल के बाद पैकेट का पता लगाएँ
क्लाइंट के इंटरनेट ट्रैफ़िक को टनल में भेजने के बाद सर्वर को उसे फ़ॉरवर्ड करना होता है और आमतौर पर उसका अनुवाद करना होता है। Access Server अपने NAT और रूटिंग नियम स्वयं प्रबंधित करता है, इसलिए जनरेट की गई फ़ाइलों में Community OpenVPN नियम जोड़ने के बजाय प्रभावी कॉन्फ़िगरेशन पढ़ें; अनियंत्रित नियम अगले उत्पाद अपडेट पर अधिलेखित हो जाते हैं या टकरा जाते हैं। sudo iptables -t nat -L -n -v या nftables का समतुल्य दिखाता है कि वास्तव में क्या अनूदित हो रहा है।
AWS पक्ष अलग पथ है। सार्वजनिक सबनेट का इंस्टेंस सीधे इंटरनेट गेटवे तक पहुँचता है और अपना सार्वजनिक पता या इलास्टिक IP रखता है। निजी सबनेट के इंस्टेंस को NAT गेटवे या NAT इंस्टेंस तक रूट चाहिए, और NAT उपकरण को अपना रूट इंटरनेट गेटवे तक चाहिए। VPC से इंटरनेट गेटवे जोड़ने से अकेले किसी निजी स्रोत को सार्वजनिक वापसी पता नहीं मिलता, इसीलिए वही Access Server सेटअप एक सबनेट में काम करता है और दूसरे में चुपचाप विफल हो जाता है।
इंस्टेंस के सबनेट से जुड़ी रूट तालिका जाँचें, केवल VPC की मुख्य तालिका नहीं। सबनेट संबद्धताएँ मुख्य तालिका पर हावी होती हैं, और पुरानी संबद्धता एक आम कारण है कि काम करता कॉन्फ़िगरेशन पुनर्निर्माण के बाद रुक जाता है।
IP निकास और DNS अलग रखें
एक ही क्लाइंट ऐप से पहले पते का शाब्दिक रूप और फिर नाम जाँचें। यदि curl -4 https://checkip.amazonaws.com सार्वजनिक पता लौटाता है पर होस्टनाम विफल होते हैं, तो टनल और NAT पथ काम कर रहे हैं और समस्या DNS में है: धकेला गया रिज़ॉल्वर, क्लाइंट की रिज़ॉल्वर स्थिति, या रिज़ॉल्वर को अवरुद्ध करने वाला सुरक्षा समूह। Access Server की DNS सेटिंग्स उसी Internet Access क्षेत्र में हैं, पर वे अलग कोड पथ से जाती हैं।
लौटाए गए पते की तुलना उस निकास से करें जो आप चाहते थे। यदि वह इंस्टेंस का सार्वजनिक पता है, तो ट्रैफ़िक का अनुवाद इंस्टेंस कर रहा है; यदि वह NAT गेटवे का पता है, तो निजी सबनेट पथ प्रयोग में है। दोनों सही हो सकते हैं। जो आप निष्कर्ष नहीं निकाल सकते वह यह है कि सर्वर पर ब्राउज़र क्लाइंट फ़ॉरवर्डिंग सिद्ध करता है।
एक चेकबॉक्स जाँच को बंद न कर दे
IPv6 अलग निर्णय है। IPv4 के लिए फुल टनल नीति इस बारे में कुछ नहीं कहती कि IPv6 ले जाया जाता है, अवरुद्ध है या लीक होता है, और दोहरे स्टैक वाला क्लाइंट IPv4 के टनल में रहते हुए अपना स्थानीय IPv6 पथ इस्तेमाल करता रह सकता है। जिस पता परिवार की आपको वास्तव में चिंता है उसे जाँचें, और स्पष्ट रूप से तय करें कि दूसरे को बंद करना चाहिए या नहीं।
अंत में, डिस्कनेक्टेड स्थिति जाँचें। फुल टनल चयन जुड़े रहने के दौरान की रूटिंग नीति बताता है, यह नहीं कि टनल गिरने पर क्या होता है। यदि आवश्यकता यह है कि कोई ट्रैफ़िक VPN के बाहर न भागे, तो यह kill-switch और फ़ायरवॉल का प्रश्न है, और इसे रूट तालिका से अनुमान के बजाय अपना परीक्षण चाहिए।