OpenVPN ग्राहकहरूले गेटवेका IPsec चयनकर्ता किन चुक्छन्

गेटवेबाट टाढाको IPsec सुरुङपछाडिको होस्टमा ping गर्नुहोस्, त्यो सफा जवाफ दिन्छ, त्यसैले सुरुङ स्वस्थ देखिन्छ र टिकट अगाडि बढ्छ। त्यसपछि जोडिएको ग्राहकले त्यही होस्ट प्रयास गर्छ र केही पनि फर्केर आउँदैन। त्यो ping कहिल्यै ग्राहकको प्रवाहको प्रमाण थिएन, किनभने त्यो गेटवेकै स्रोत ठेगानासँग बाहिर गएको थियो र अर्को IPsec चयनकर्तासँग मिलेको थियो। यी दुई अवस्था किन फरक पर्छन् भन्ने बुझ्नु नै समाधानको ठूलो भाग हो।

गेटवेको ping ले तपाईंको ग्राहकले कहिल्यै नभोग्ने प्रवाह जाँच्छ

कुन नीति लागू हुन्छ भन्ने स्रोत ठेगानाले निर्धारण गर्छ। गेटवेमा बनेको प्याकेट त्यसको स्थानीय LAN वा सुरुङको अन्त्य बिन्दुको ठेगानासँग बाहिर जान्छ, र त्यससँग मिल्ने नीति ठ्याक्कै त्यही अवस्थाका लागि लेखिएको थियो। ग्राहकको प्याकेट OpenVPN इन्टरफेसमा ग्राहक पूलको ठेगानासँग आउँछ, जो पूर्ण रूपमा अर्को चयनकर्ता हो।

त्यसैले विफलता राउटिङ समस्याजस्तो देखिन्छ, तर वास्तवमा त्यो नीतिको दायराको समस्या हो। गेटवेबाट पहुँचले पीयर सक्रिय छ र प्रस्तावहरूमा वार्ता भएको प्रमाणित गर्छ, र पूल सुरक्षित छ कि छैन भन्नेबारे केही पनि प्रमाणित गर्दैन।

एप्लिकेसनलाई साँच्चै चाहिने टाढाको प्रिफिक्स पुश गर्नुहोस्

जोडिएका ग्राहकका लागि 10.8.0.0/24 र सुरक्षित टाढाको सञ्जालका लागि 172.30.239.0/25 को यो उदाहरण जोडी लिनुहोस्। ग्राहकलाई त्यो दोस्रो प्रिफिक्सको मार्ग चाहिन्छ, गेटवेको LAN होइन र अर्को सुरुङ ठेगाना पनि होइन। पूलमा पुश गरिएको मार्गले नै ग्राहकलाई त्यो ट्राफिक गेटवेलाई सुम्पन लगाउँछ। त्यो बिना प्याकेट तपाईंले डिबग गरिरहेको नीति निर्णयसम्म कहिल्यै पुग्दैन।

पुश गरिएका मार्ग स्वीकार गर्ने Community सर्भरमा निर्देशनले साँचो मास्क लिन्छ: push "route 172.30.239.0 255.255.255.128"। Access Server ले त्यही गन्तव्य स्थापित संस्करणको निजी-सञ्जाल वा पहुँच-नियम सेटिङमार्फत कन्फिगर गर्छ, र राउटेड वा अनुवादित मोड सचेत रूपमा छानिन्छ। मालिक कन्फिगरेसनको सट्टा उत्पन्न फायरवाल चेन सम्पादन गर्नु नै कार्यरत सेटअप पुनरुत्पादन गर्न असम्भव बनाउने बाटो हो।

जोडिएपछि सर्भरको मनसाय होइन, ग्राहकको राउटिङ तालिका पढ्नुहोस्। केवल पूल ढाक्ने मार्ग भनेको पुश कहिल्यै पुगेन, र सुरुङबाट जाने डिफल्ट मार्ग यो आवश्यकताभन्दा फराकिलो छ र पछि तपाईंलाई छक्क पार्छ। मास्क र प्रिफिक्स दुवै जाँच्नुहोस्, किनभने /25 लाई /24 को रूपमा पुश गर्दा छिमेकी ठेगानाको ट्राफिक त्यसलाई बोक्न नसक्ने बाटोमा जान्छ। त्यसपछि ग्राहकले त्यो गन्तव्यका लागि सुरुङ इन्टरफेस छानेको पुष्टि गर्नुहोस्।

चयनकर्ताहरूमा ग्राहक पूल समावेश गर्नुहोस्

ग्राहक ठेगाना जोगाउने राउटेड पहुँचका लागि IPsec नीतिले पूल र टाढाको प्रिफिक्सबीचको ट्राफिक सुरक्षित राख्नुपर्छ। गेटवेको आफ्नै LAN का लागि लेखिएका चयनकर्ताले ping स्वीकार्छन् र ग्राहकको अनुरोध फ्याँक्छन्, र यही त्यो असमानता हो जसले यो अनुसन्धान सुरु गर्यो।

कन्फिगर गरिएका प्रस्तावसँगै वार्ता भएको नीति पनि जाँच्नुहोस्, उदाहरणका लागि strongSwan मा ipsec statusall वा तपाईंको कार्यान्वयनका लागि समान स्थिति आदेश। नीति-आधारित IPsec मा सामान्य मार्ग भौतिक इन्टरफेसतिर देखाउन सक्छ, तर मिल्ने ट्राफिक अझै इन्क्रिप्ट हुन्छ, त्यसैले सुरुङ यन्त्र नहुनुले केही प्रमाणित गर्दैन। चयनकर्ता जोडीहरूलाई तपाईंले लेखेको पूल र प्रिफिक्ससँग तुलना गर्नुहोस्।

गेटवेमा सामान्य स्रोत NAT ले पनि मिलान तोड्न सक्छ। नीति जाँचअघि masquerade नियमले ग्राहकको स्रोत पुनःलेख्छ भने, प्याकेट अब तपाईंले लेखेको चयनकर्ताजस्तो देखिँदैन। फराकिलो masquerade नियम दोस्रो VPN का लागि खराब समाधान हुनुको एउटा कारण यही हो: यसले कुन नीति लागू हुन्छ र टाढाको पक्षले कुन ठेगाना लग गर्छ भन्ने बदल्छ। तपाईंले राउट गर्न चाहेको ट्राफिकलाई छुट दिनुहोस्, वा सचेत रूपमा अनुवाद गरेर चयनकर्ता अद्यावधिक गर्नुहोस्।

राउटिङ वा अनुवाद सचेत रूपमा छान्नुहोस्

राउटिङले ग्राहकको ठेगाना टाढाको पक्षलाई देखिने राख्छ, त्यसैले टाढाका लग र प्रति-स्रोत नियम अर्थपूर्ण रहन्छन्, र टाढाको गेटवेले पूलसम्मको फर्कने बाटो जान्नु आवश्यक हुन्छ। अनुवादले पूललाई एउटा ठेगानाभित्र लुकाउँछ, जसले फर्कने मार्गको समस्या हटाउँछ र प्रति-ग्राहक पहिचान नष्ट गर्छ।

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

फर्वार्डिङ र जवाफमा चक्र बन्द गर्नुहोस्

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

ग्राहकबाट एप्लिकेसनमा जाने एउटा वास्तविक अनुरोधले प्रमाणित गर्नुहोस्, त्यो OpenVPN इन्टरफेस, IPsec निर्णय र टाढाको होस्ट हुँदै जाने हेर्नुहोस्। जवाफलाई छुट्टै अवलोकनका रूपमा हेर्नुहोस्, किनभने पुग्ने अनुरोध र कहिल्यै नफर्कने जवाफ ग्राहकको ठाउँबाट उस्तै देखिन्छन्। एउटा ट्रेस गरिएको अनुरोध गेटवेका जतिसुकै ping भन्दा बढी मूल्यवान् हुन्छ।

परीक्षण गर्दा गन्तव्यको अधिकार साँघुरो राख्नुहोस्, र नियम नभएको ग्राहक सेवासम्म पुग्न नसक्ने पुष्टि गर्नुहोस्। स्थापित मार्ग र स्थापित एसोसिएसन दिइएको पहुँचसँग बराबर होइनन्।