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 से अलग कहानी कहता है।

अगर सक्रिय 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

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

पैकेज स्वामित्व, कॉन्फ़िगरेशन लोडिंग और प्रोटोकॉल संगतता को तीन अलग सवाल मानें। एक फ्रंटएंड के लिए मान्य फ़ाइल अन्यथा बार-बार संपादित होती रहेगी जबकि कोई दूसरा डेमॉन चल रहा हो।