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 बरु ग्राहक गेटवेको छेउमा बस्न सक्छ।