OpenVPN रुट strongSwan XFRM नीतिसँग किन हार्छ
एक विशेष OpenVPN रुटले XFRM नीतिलाई अगाडि बढाउँदैन: रुट र नीतिका चयनकर्ता पढ्नुहोस्, त्यसपछि साँघुरो बनाउनुहोस्, अपवाद दिनुहोस् वा XFRM इन्टरफेसमा जानुहोस्.
प्याकेटहरूले OpenVPN रुट पछ्याउँदै पनि IPsec नीतिले समात्न सक्छ, र यो संयोजन सही कोणबाहेक सबै कोणबाट राउटिङ बगजस्तो देखिन्छ। Linux एउटा रुट समाधान गरेपछि छुट्टै सुरक्षा नीति डेटाबेससँग परामर्श गर्छ, त्यसैले अझ विशिष्ट गन्तव्य रुटले मिल्ने XFRM नीतिलाई विस्थापित गर्दैन। देखिने लक्षण भनेको होस्ट छोडेर कहिल्यै नपुग्ने ट्राफिक हो, जबकि दुवै टनेलले आफूलाई स्वस्थ घोषणा गर्छन्। तीन विकल्पले यसलाई समाधान गर्छन्, र तपाईंले कुन रोज्नुहुन्छ त्यो दुई बाटोमध्ये कुनले त्यो प्रिफिक्स बोक्ने हो भन्नेमा निर्भर गर्छ।
दुई निर्णय, एउटा होइन
रुट चयनले साँघुरो प्रश्नको उत्तर दिन्छ: कुन अर्को हप र स्रोत ठेगानाले यो प्याकेट बोक्नुपर्छ। सुरक्षा नीति डेटाबेसले अर्कोको उत्तर दिन्छ: यो प्याकेटलाई IPsec सुरक्षा चाहिन्छ कि, र कुन चयनकर्ताहरू अन्तर्गत। दुवै एउटै प्याकेटका लागि चल्छन्, र पहिलो पूरा गर्नाले दोस्रोको बारेमा केही भन्दैन। त्यसैले मेट्रिक बदल्नु वा स्थिर रुट थप्नुले लक्षणलाई अछुतो राख्न सक्छ।
फराकिलो IPsec चयनकर्ता सामान्य कारण हो। 172.16.0.0/12 को सुरक्षा गर्ने नीतिले 172.20.8.0/24 पनि ढाक्छ, जहाँ प्रशासकले OpenVPN टनेलबाट पुग्ने इरादा राखेको हुन सक्छ। इरादा राउटिङ तालिकामा मात्र छ, र नीति डेटाबेसले त्यसको बारेमा कहिल्यै थाहा पाएन।
यसलाई दुई मेट्रिकबीचको प्रतिस्पर्धा नभई कन्फिगर गरिएका दुई सुरक्षा बाटोबीचको द्वन्द्व मान्नुहोस्। सुधार त्यही घटकमा हुनुपर्छ जुन गलत दायरासँग कन्फिगर भएको थियो।
कर्नेलले वास्तवमा छान्ने रुट पढ्नुहोस्
कर्नेलले गर्ने खोजबाट सुरु गर्नुहोस्, जसमा स्रोत ठेगाना र यसलाई अर्को तालिकामा मोड्न सक्ने कुनै पनि नीति नियम समावेश छ। मुख्य तालिकाको रुट कहिल्यै हेरिन सक्दैन यदि अघिल्लो नियमले अर्को तालिका छान्छ, र सबैभन्दा लामो प्रिफिक्स मिलान नियमले छान्ने तालिकाभित्र मात्र लागू हुन्छ।
ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15अन्तिम आदेश महत्त्वपूर्ण छ, किनकि यसले छानिएको रुट र कर्नेलले प्रयोग गर्ने स्रोत ठेगाना सँगै छाप्छ। त्यो आउटपुटलाई IPsec नीतिले मिल्ने चयनकर्तासँग तुलना गर्नुहोस्। जब रुट OpenVPN इन्टरफेसतर्फ देखाउँछ र नीति अझै त्यही जोडीसँग मिल्छ, तब तपाईंले अनुमान नगरी द्वन्द्व पुनःउत्पादन गर्नुभएको छ।
टिकटमा पुग्नुअघि डम्पहरूलाई असम्बन्धित ठेगानाबाट मुक्त राख्नुहोस्। उत्पादन होस्टको राउटिङ तालिकाले आन्तरिक टोपोलोजी बोक्छ, र प्रश्नको उत्तर दिने लाइनहरू मात्र टाँस्न योग्य छन्।
लागू हुने नीति पनि पढ्नुहोस्
नीति सूचीले दिशा, चयनकर्ता र मिल्ने प्याकेटलाई के हुन्छ भन्ने निर्णय गर्ने टेम्प्लेट देखाउँछ। पहिले बाहिर जाने दिशा पढ्नुहोस्, त्यसपछि फर्किने ट्राफिकका लागि भित्र पस्ने पक्ष, किनकि एकतर्फी अपवादले सुरु हुने र कहिल्यै पूरा नहुने जडान बनाउँछ।
ip -s xfrm policy
swanctl --list-sasसूचीका चयनकर्ताहरूलाई जडानले वार्ता गरेका प्रिफिक्ससँग तुलना गर्नुहोस्। strongSwan को रुट स्थापना बन्द गर्दा ती नीतिहरू हट्दैनन्, र मेट्रिक बदल्दा कुन स्रोत-गन्तव्य जोडीको नीतिले सुरक्षा गर्छ भन्ने बदलिँदैन। यी दुई झुटा सुधारहरू चाँडै बहिष्कृत गर्न योग्य छन्, किनकि मानिसहरूले पहिले तिनै प्रयास गर्छन्।
यदि सूचीमा तपाईंले अपेक्षा गरेको प्रिफिक्सका लागि कुनै नीति छैन भने, समस्या अन्तै छ र राउटिङ तालिका सम्भवतः सत्य बोल्दै छ। यदि यसमा प्रिफिक्स ढाक्ने फराकिलो नीति छ भने, तपाईंले समात्ने भेट्टाउनुभयो।
दुवै बाटो वैध हुँदा तीन विकल्प
फराकिलो प्रिफिक्स आवश्यकता नभई सुविधा भएको बेला IPsec चयनकर्ता साँघुरो बनाउनु सबैभन्दा सफा विकल्प हो। दूरस्थ ट्राफिक चयनकर्तालाई साँच्चै IPsec पछाडि पर्ने सबनेटसम्म घटाउँदा सबै होस्टका लागि एकैचोटि द्वन्द्व हट्छ, र यसको लागत नयाँ घटक नभई कुञ्जी पुनःवार्ता हो।
फराकिलो चयनकर्ता रहनैपर्ने बेला पासथ्रु अपवाद शल्यक्रियाजस्तो विकल्प हो। strongSwan ले child ले pass मोड प्रयोग गर्ने छुट्टै जडानलाई समर्थन गर्छ, जसले कर्नेललाई मिल्ने ट्राफिक IPsec ले प्रशोधन गर्न नहुने बताउँछ। लूपब्याक दूरस्थ ठेगानाले त्यो जडानलाई आउने साथीहरूका लागि छानिनबाट रोक्छ, र चयनकर्ताहरूले सबैथोक नभई वास्तविक अधिकृत जोडी वर्णन गर्नुपर्छ।
connections {
openvpn-exception {
remote_addrs = 127.0.0.1
children {
openvpn-exception {
local_ts = 10.44.7.0/24
remote_ts = 172.20.8.0/24
mode = pass
start_action = trap
}
}
}
}strongSwan कन्फिगरेसन उदाहरणहरू ले यो नीति प्रकार र लूपब्याक साथी परम्पराको दस्तावेजीकरण गर्छन्। तेस्रो विकल्प XFRM इन्टरफेससँग रुट-आधारित डिजाइन हो, जसले नीतिलाई विश्वव्यापी चयनकर्ताको सट्टा नाम दिइएको इन्टरफेसबाट राउट हुने ट्राफिकसँग बाँध्छ। यो ट्वीक होइन, स्थानान्तरण हो, र ट्राफिकले अझै वार्ता गरिएका चयनकर्ताहरू पूरा गर्नुपर्छ।
| Option | Use it when | Cost |
|---|---|---|
| Narrow the selector | The broad prefix was convenience | A rekey and a policy review |
| Passthrough child | The broad selector must stay | One exception per intended pair |
| XFRM interface | Policy should follow routing | A design migration |
बाँकीलाई कमजोर नबनाई अपवाद प्रमाणित गर्नुहोस्
परिवर्तन लोड गरेपछि अपवाद र सुरक्षित रहनुपर्ने सामान्य गन्तव्य परीक्षण गर्नुहोस्। दुवै दिशा जाँच्नुहोस्, त्यसपछि OpenVPN टनेल खसाल्नुहोस् र अपवादित ट्राफिकलाई के हुन्छ पुष्टि गर्नुहोस्। टनेल बन्द हुँदा त्यो प्रिफिक्स चुपचाप खुला रूपमा पठाउने अपवाद घटनाको क्रममा पत्ता लगाउने कुरा होइन, जानीजानी लिनुपर्ने नीति निर्णय हो।
कुन प्रिफिक्सले कुन बाटो प्रयोग गर्छ र किन लेख्नुहोस्। नत्र फराकिलो चयनकर्ता देख्ने अर्को इन्जिनियरले त्यही अनुसन्धान फेरि खोल्नेछ, र उत्तर कसैले नपढ्ने commit सन्देशमा रहनेछ।