EC2 पर strongSwan: VPC को काम का भार रूट करने दें

सुरंग चालू है, गेटवे इंस्टेंस दूर के नेटवर्क को पिंग कर सकता है, पर उसके पास का एप्लिकेशन इंस्टेंस कहीं नहीं पहुँचता। कुछ भी टूटा नहीं है। जो परीक्षण सफल हुआ वह VPN होस्ट पर शुरू हुआ था, और उसने कभी नहीं पूछा कि क्या वह होस्ट उसी IPsec संबंध से कोई दूसरा स्रोत पता ले जा सकता है। यह रनबुक उस अंतराल को चार चरणों में बंद करती है, उसी क्रम में जो हर विफलता को दिखाई देता रखता है।

पहले चारों पते लिख लें

नीचे का हर चरण इन्हीं की ओर संकेत करता है, इसलिए रूटिंग तालिका छूने से पहले इन्हें अपने खाते के लिए भरें।

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

उदाहरण एक स्वीकृत, कार्यशील नीति-आधारित IPsec कनेक्शन और स्रोत बनाए रखने वाले प्रवाह को मानता है। यह NAT वाला दूरस्थ पहुँच क्लाइंट नहीं है जो एक आवंटित पता उधार लेता है, और यही अंतर तय करता है कि सिलेक्टर बदलने हैं या नहीं।

चरण 1: काम के भार की सबनेट को एक रूट दें

काम के भार की सबनेट से वास्तव में जुड़ी रूटिंग तालिका को दूर के प्रीफ़िक्स के लिए ऐसा पथ चाहिए जो गेटवे के नेटवर्क इंटरफ़ेस की ओर इशारा करे। इंस्टेंस के भीतर स्थापित अतिथि रूट उस AWS रूटिंग तालिका में प्रविष्टि नहीं है, और कोई भी मात्रा strongSwan कॉन्फ़िगरेशन की उसे नहीं बनाएगी।

AWS की उपकरण के माध्यम से रूटिंग संबंधी मार्गदर्शिका नेटवर्क इंटरफ़ेस लक्ष्यों और अग्रेषित करने वाले इंस्टेंस की स्रोत/गंतव्य जाँच की आवश्यकता बताती है। उस जाँच परिवर्तन को गेटवे की भूमिका तक सीमित रखें, और साधारण एप्लिकेशन इंस्टेंस को शांति से रहने दें।

एक स्वीकृत नेटवर्क के लिए जगह बनाने हेतु VPC के स्थानीय रूट या हर मौजूदा प्रविष्टि को न बदलें। देखें कि क्या जुड़ा और सक्रिय है, न कि कंसोल पृष्ठ किसी ऐसी रूटिंग तालिका के लिए क्या दिखाता है जिसे कोई उपयोग नहीं करता। एक जैसी दिखने वाली दो तालिकाओं के संबंध अलग हो सकते हैं। महत्वपूर्ण वही है जिससे काम के भार की सबनेट जुड़ी है।

चरण 2: अतिथि पर फ़ॉरवर्डिंग चालू करें

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

कर्नेल को अग्रेषित करना होगा और होस्ट फ़ायरवॉल को पारगमन अनुमत करना होगा। सब कुछ स्वीकार करने के बजाय काम के भार और दूर के प्रीफ़िक्स के लिए इच्छित फ़ॉरवर्डिंग नियम जोड़ें, और पुष्टि करें कि गेटवे सबनेट अपने ही ट्रैफ़िक के लिए उपयोगी ट्रांसपोर्ट रूट रखती है।

सुरक्षा समूह वह जगह हैं जहाँ यह चरण आमतौर पर अटकता है। कोई मध्यवर्ती उपकरण सीधे इंस्टेंस संचार के सुरक्षा समूह संदर्भ व्यवहार को विरासत में नहीं लेता, इसलिए प्रबंधित Client VPN उदाहरण से नकल किया गया नियम कभी मेल नहीं खा सकता। वास्तविक पथ पर दोनों दिशाओं में सुरक्षा समूह और सबनेट ACL जाँचें।

चरण 3: सिलेक्टर को असली स्रोतों तक बढ़ाएँ

AWS की ओर केवल 10.60.1.10/32 को कवर करने वाली नीति 10.60.2.20 को कवर किए बिना गेटवे से शुरू हुई सफलता की व्याख्या करती है। दूर के गंतव्य की ओर रूट किसी ट्रैफ़िक सिलेक्टर को नहीं बढ़ाता, और यही उसी आश्चर्य का दूसरा आधा हिस्सा है।

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

यदि सहमत डिज़ाइन पूरे VPC की रक्षा करता है, तो दोनों पक्षों को 10.60.0.0/16 और 10.90.0.0/24 स्वीकार करने होंगे। यदि यह एक काम के भार की रक्षा करता है, तो जानबूझकर वही संकरा प्रीफ़िक्स इस्तेमाल करें। किसी भी हालत में, स्थापित CHILD-SA नीति जाँचें, क्योंकि आपका संपादित कॉन्फ़िगरेशन और जिस पक्ष ने उसे अलग तरह से सँकरा किया, वे एक ही समझौता नहीं हैं।

दूर की साइट को भी संरक्षित VPC स्रोतों के उत्तर इच्छित IPsec गेटवे से वापस रूट करने चाहिए। जहाँ अन्य स्रोत NAT नियम हों वहाँ संरक्षित ट्रैफ़िक के लिए समर्थित NAT छूट बनाए रखें; किसी अस्वीकृत काम के भार को अनुमत होस्ट पते में बदलना एक अलग पहचान अनुबंध है, आपकी चाही हुई पहुँच का शॉर्टकट नहीं।

चरण 4: सत्यापित करें, फिर ज़रूरत हो तो वापस लौटाएँ

काम के भार से ही किसी नई अनुमत एप्लिकेशन क्रिया के साथ परखें, फिर ऐसे गंतव्य के साथ दोहराएँ जिसे बाहर रखा जाना चाहिए। दूर की सेवा जो स्रोत पता देखती है और जो वापसी पथ इस्तेमाल करती है, वह दर्ज करें। गेटवे को पिंग या हरा IKE स्टेटस वह परीक्षण नहीं है।

यदि गेटवे के चलते हुए भी काम का भार विफल रहता है, तो चरणों में क्रम से पीछे जाएँ: सिलेक्टर, फिर फ़ॉरवर्डिंग और सुरक्षा समूह, फिर जुड़ी रूटिंग तालिका। हर एक का अलग लक्षण है, और अनुमान उसी को छोड़ देता है जो सचमुच गलत है।

वापस लौटाना उसी क्रम को उलट देता है। काम के भार की सबनेट का रूट सबसे अंत में हटाएँ, पिछले सिलेक्टर बहाल करने के बाद, ताकि ऐसी सबनेट न छोड़ें जो ऐसे गेटवे की ओर इशारा करे जो अब उसके स्रोतों की रक्षा नहीं करता। जब ये अनुबंध टिकते हैं तब स्व-होस्टिंग गेटवे होस्ट से अधिक की सेवा कर सकती है, और AWS-प्रबंधित Site-to-Site VPN एक भिन्न संचालन मॉडल है जहाँ strongSwan ग्राहक गेटवे के छोर पर बैठ सकता है।