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

यापैकी फक्त एक कमांड तुमच्या होस्टची आहे। दोन्ही चालवून आउटपुट तुलना करणे म्हणजे कोणता तुमच्याशी खोटे बोलतो हे शोधण्याचा मार्ग, निदान पद्धत नाही।

पॅकेज मालकी, कॉन्फिगरेशन लोडिंग आणि प्रोटोकॉल सुसंगतता या तीन स्वतंत्र प्रश्नांप्रमाणे घ्या। एका फ्रंटएंडसाठी वैध फाइल अन्यथा वारंवार संपादित होईल, तेव्हा दुसरा डेमॉन चालू असेल।