ipsec.conf वा swanctl.conf? strongSwan को एउटा फ्रन्टएन्ड छान्नुहोस्

पुरानो निर्देशिकाको काम गर्ने IKEv1 प्रोफाइल Ubuntu 24.04 मा आउँछ, र पहिलो प्रयास असफल हुन्छ किनभने डेमनले त्यो फाइल कहिल्यै पढेन। सामान्य प्रतिक्रिया भनेको प्रोफाइल फेरि सम्पादन गर्नु हो। वास्तविक प्रश्न यो हो कि कुन strongSwan फ्रन्टएन्ड स्थापित छ र चलिरहेको सेवाले कुन प्रयोग गर्छ। त्यसको उत्तर नआएसम्म, हरेक सम्पादन नहुन सक्ने लोडरतर्फ लक्षित हुन्छ।

दुई फाइल, दुई लोडर, एउटा डेमन

पुरानो starter व्यवस्थाले ipsec.conf पढ्छ र आफ्नो पुरानो व्यवस्थापन एकीकरणमार्फत जडानहरू charon लाई सुम्पन्छ। यसको सञ्चालन प्रवेश बिन्दु ipsec आदेश हो।

swanctl व्यवस्थाले VICI मार्फत परिभाषा लोड गर्छ, swanctl.conf पढ्छ र swanctl आदेशले चल्छ। systemd मा निहित charon डेमन यो दृष्टिकोणसँग एकीकृत हुन्छ।

दुवै एउटै मेसिनमा स्थापित हुन सक्छन्, र अलमल त्यहीँबाट सुरु हुन्छ। /etc मुनि रहेको फाइलले कसैले त्यो लेख्यो भन्ने मात्र प्रमाणित गर्छ, चलिरहेको प्रक्रियाले त्यो लोड गर्यो भन्ने होइन। कुन चल्छ भनेर हेर्न हरेक विकल्प स्थापित गर्दा दुई व्यवस्थापन मार्ग र स्पष्ट मालिक नभएको होस्ट बन्छ। एउटा व्यवस्था छान्नुहोस् र अर्को हटाउनुहोस् वा अक्षम गर्नुहोस्।

स्थापित प्याकेज र unit पढ्नुहोस्

पढ्ने मात्र अवस्थाबाट सुरु गर्नुहोस्। Ubuntu 24.04 मा प्याकेजका नाम अलग छन्: strongswan-starter, strongswan-swanctl र charon-systemd। अनुपस्थित प्याकेज उपयोगी जानकारी हो, त्यो स्थापित गर्ने निर्देश होइन।

एउटै पटकमा प्याकेज र unit को सूची बनाउनुहोस्:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

त्यसपछि सक्रिय unit र यसको सुरु गर्ने आदेश जाँच्नुहोस्। unit को नामले कुन डेमन कन्फिगरेसनको मालिक हो भन्ने बताउँछ, र आदेश लाइनले कुन फाइल पढ्न भनिएको थियो भन्ने पुष्टि गर्छ। सक्रिय गरिएको तर निष्क्रिय unit ले अहिले चलिरहेको भन्दा फरक कथा भन्छ।

सक्रिय unit strongswan-starter भए महत्त्वपूर्ण फाइल ipsec.conf हो। यदि swanctl सहितको charon-systemd हो भने ipsec.conf केवल सजावट हो।

मिल्ने नियन्त्रण मार्ग प्रयोग गर्नुहोस्

हरेक फ्रन्टएन्डको जडान र संगठनबारे आफ्नै दृष्टिकोण हुन्छ। swanctl --list-conns ले लोड गरिएका परिभाषा देखाउँछ र swanctl --list-sas ले सक्रिय संगठन देखाउँछ। पुरानो मार्गले ipsec statusall प्रयोग गर्छ।

दुवै मिसाउँदा भ्रम पार्ने त्रुटि हुन्छ। अनुपस्थित VICI सकेट वा अस्वीकृत नियन्त्रण अनुरोध व्यवस्थापन-मार्गको समस्या हो, सामनेवालाले प्रमाणीकरण अस्वीकार गर्यो भन्ने प्रमाण होइन।

चलिरहेको डेमनको दृष्टिकोण पढ्नुहोस्, त्यसपछि नतिजाको व्याख्या गर्नुहोस्। यदि त्यो दृष्टिकोणमा जडान छैन भने समस्या लोडिङमा छ, वार्तामा होइन।

ढाँचा IKE संस्करण होइन

पुरानो प्रोफाइलले keyexchange=ikev1 मार्फत IKEv1 छान्छ। swanctl जडानले संस्करण सेटिङ प्रयोग गर्छ, जहाँ 1 ले IKEv1 छान्छ। यी एउटै विचारका दुई शब्दावली हुन्, रूपान्तरण होइन।

सामनेवालाको ठेगाना, स्थानीय र टाढाको पहिचान, प्रमाण-स्रोत, प्रस्ताव र child चयनकर्ता सबै जानाजान म्याप गर्नुपर्छ। left/right ब्लक swanctl सिन्ट्याक्समा टाँस्दा यीमध्ये केही पनि हुँदैन।

केवल प्रोटोकल संस्करण बदल्नु सबैभन्दा सामान्य आधा-स्थानान्तरण हो। यसले लोड हुने र त्यसपछि संस्करणसँग सम्बन्ध नभएका कारणले प्रमाणीकरणमा असफल हुने फाइल बनाउँछ। IKEv1 आफै RFC 9395 द्वारा अप्रचलित भएको छ, त्यसैले अझै यसको माग गर्ने विद्यमान सामनेवालालाई कागजातीय अनुकूलता-सीमा र स्थानान्तरण मार्ग चाहिन्छ, नयाँ पूर्वनिर्धारित होइन।

प्रोफाइल छुनुअघि लोडर जाँच्नुहोस्

पहिले लोडर जाँच चलाउनुहोस्, त्यसपछि इच्छित जडान लोड गर्नुहोस्, त्यसपछि वार्ताको मूल्याङ्कन गर्नुहोस्, र अन्तमा सुरक्षित ट्राफिकको मार्ग। हरेक चरणको असफलता-चिन्ह फरक हुन्छ।

दुई नियन्त्रण मार्गले लोडिङको प्रश्नको सिधा उत्तर दिन्छन्:

swanctl --list-conns
ipsec statusall

यीमध्ये एउटा मात्र आदेश तपाईंको होस्टको हो। दुवै चलाएर आउटपुट तुलना गर्नु कुनले तपाईंलाई झुट बोल्दै छ भनी पत्ता लगाउने उपाय हो, निदान विधि होइन।

प्याकेज स्वामित्व, कन्फिगरेसन लोडिङ र प्रोटोकल अनुकूलतालाई तीन अलग प्रश्नका रूपमा लिनुहोस्। एउटा फ्रन्टएन्डका लागि मान्य फाइल अन्यथा बारम्बार सम्पादन हुन्छ, जब अर्को डेमन चलिरहेको हुन्छ।