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 त्याऐवजी ग्राहक गेटवेच्या टोकाला बसू शकते।