लोड किया गया strongSwan प्रोफ़ाइल सक्रिय टनल नहीं है
strongSwan परिभाषाएँ लोड करता है और फिर IKE तथा CHILD SA पर बातचीत करता है। प्रोफ़ाइल का लोड होना इस बात पर कुछ नहीं कहता कि कोई टनल मौजूद है या उसे कौन शुरू करता है।
strongSwan कॉन्फ़िगरेशन में किसी कनेक्शन को सूचीबद्ध करना केवल यह सिद्ध करता है कि एक परिभाषा लोड हुई। इसका अर्थ यह नहीं कि साथी से संपर्क किया गया, कोई IKE SA मौजूद है या कोई ट्रैफ़िक सुरक्षित है। डेमॉन परिभाषाओं और जीवित एसोसिएशनों को अलग-अलग वस्तुओं के रूप में देखता है, और उनके बीच की दूरी एक सोचा-समझा डिज़ाइन निर्णय है। यह जानना कि आप कौन-सी वस्तु जाँच रहे हैं, एक अस्पष्ट विफलता को अगले ठोस आदेश में बदल देता है।
लोड करना जुड़ना नहीं है
लोड किया गया कनेक्शन इस बात का कथन है कि आगे किन चीज़ों पर बातचीत हो सकती है: साथी के पते, प्रमाण-पत्र, प्रस्ताव और ट्रैफ़िक चयनक। इस कथन में कुछ भी डेमॉन के किसी को फ़ोन करने की माँग नहीं करता। गेटवे दूसरे पक्ष की प्रतीक्षा कर सकता है, शुरुआत में स्वयं पहल कर सकता है, या उपयुक्त ट्रैफ़िक के जागने की प्रतीक्षा कर सकता है। तीनों वैध हैं, और तीनों कॉन्फ़िगरेशन फ़ाइल में तब तक एक जैसे दिखते हैं जब तक आप शुरुआत की नीति न पढ़ें।
ऑपरेटर परिभाषाओं की सूची को स्थिति की सूची मानकर पढ़ने से मुसीबत में पड़ते हैं। प्रोफ़ाइल मौजूद है, इसलिए टनल को सक्रिय मान लिया जाता है, और अगला घंटा ऐसी एसोसिएशन के रूटों की डिबगिंग में जाता है जो कभी बनी ही नहीं।
उलटी ग़लती भी उतनी ही आम है। ग़ायब प्रोफ़ाइल लोगों को नेटवर्क विफलता खोजने भेज देता है जबकि कॉन्फ़िगरेशन कभी लोड ही नहीं हुआ। वस्तु को नाम दें, फिर वह आदेश चलाएँ जो उसे देखता है।
तीन वस्तुएँ, तीन अवलोकन
strongSwan एक लोड की गई परिभाषा, एक IKE SA और एक CHILD SA रखता है। पहली कॉन्फ़िगरेशन है, दूसरी प्रमाणित नियंत्रण संबंध है, और तीसरी चुने गए ट्रैफ़िक के लिए तय की गई सुरक्षा है। इनके अलग-अलग नाम भी हैं, इसलिए hq नाम का प्रोफ़ाइल hq-lan नाम का child रख सकता है।
तालिका हर परत को उस आदेश से जोड़ती है जो उसे दिखाता है। लॉग पढ़ने से पहले पंक्ति पढ़ें।
| Layer | What it contains | Command |
|---|---|---|
| Definition | Peer addresses, credentials, proposals, and traffic selectors | swanctl --list-conns |
| IKE SA | One authenticated control channel to the peer | swanctl --list-sas |
| CHILD SA | Keys and selectors for the traffic being protected | Child rows under the IKE SA |
child का अनुरोध पहले उसका जनक IKE SA बनाता है जब कोई न हो। केवल IKE SA का अनुरोध दूसरी कॉल है। ठीक से प्रमाणित होने वाला नियंत्रण चैनल अनुरोधित child की गारंटी नहीं देता।
यह अंतर आंशिक विफलता के दौरान मायने रखता है। IKE SA स्वस्थ हो सकता है जबकि child चयनक के बेमेल होने या ऐसे प्रस्ताव के कारण विफल हो जाता है जिसे साथी स्वीकार नहीं करता। दोनों वस्तुएँ अलग-अलग कारणों से विफल होती हैं, इसलिए वे अलग अवलोकनों की हक़दार हैं।
शुरुआत की क्रिया सोच-समझकर चुनें
swanctl.conf में child का start_action लोड होने के बाद का व्यवहार तय करता है। डिफ़ॉल्ट none परिभाषा को मैनुअल शुरुआत या responder के रूप में उपयोग के लिए छोड़ देता है। start उसे डायल करता है, जबकि trap ऐसी नीति छोड़ता है जो उपयुक्त ट्रैफ़िक दिखते ही बातचीत करती है।
इसलिए «लोड करना कभी टनल शुरू नहीं करता» और «लोड करना हमेशा एक शुरू करता है» दोनों ग़लत हैं। क्रिया प्रोफ़ाइल का हिस्सा है और उसे साथी की भूमिका से मेल खाना चाहिए। दो गेटवे जो दोनों दूसरे पक्ष की प्रतीक्षा करते हैं, ख़ामोशी पैदा करते हैं, टनल नहीं।
trap के साथ ट्रैफ़िक को चयनकों से मेल खाना होता है, इसलिए असंबंधित ping कुछ नहीं जगाएगा। start के साथ साथी का पता उपयोगी होना चाहिए और दोनों पक्षों को प्रमाणीकरण और प्रस्तावों पर सहमत होना चाहिए। दोनों में से कोई क्रिया इन शर्तों की जाँच का विकल्प नहीं है।
रिकवरी एक अलग नीति है
शुरुआत कोई keepalive नहीं है। मृत साथी का पता लगाना, साथी द्वारा स्पष्ट बंदी, कुंजियों का नवीनीकरण और प्रक्रिया का पुनः आरंभ जीवन-चक्र की अलग-अलग घटनाएँ हैं जिनकी अपनी सेटिंग्स हैं। हर एक को सोच-समझकर कॉन्फ़िगर करें, बजाय इसके कि प्रारंभिक शुरुआत से सब ढकने की अपेक्षा रखें।
ऐसी टनल जो बूट पर उठती है और एक घंटे बाद मर जाती है, रिकवरी का प्रश्न है। शुरुआत की नीति ने अपना काम किया और फिर मायने रखना बंद कर दिया। प्रारंभिक बातचीत को दोष देने से पहले DPD और कुंजी नवीनीकरण की सेटिंग्स देखें।
लोड की गई परिभाषाओं को बदलना एक अलग कार्रवाई है। ग़ैर-डिफ़ॉल्ट शुरुआत नीतियों में दस्तावेज़ित उलटी क्रियाएँ होती हैं, और पुनः लोड करना एक परिचालन परिवर्तन है न कि यह मान लेना कि हर एसोसिएशन मौके पर ही अद्यतन हुई। पुनः लोड चरणों में करें, जहाँ पुनः जुड़ना स्वीकार्य हो। पुराना कॉन्फ़िगरेशन तब तक रखें जब तक नया सिद्ध न हो जाए।
रूटिंग डिबग करने से पहले जाँचें कि क्या मौजूद है
तीनों अवलोकन क्रम से करें: लोड की गई परिभाषाएँ, सक्रिय IKE SA और child प्रविष्टियाँ। हर उत्तर अगले प्रश्न को सँकरा करता है। एक चरण छोड़ें और अंत में आप ऐसी परत डिबग करेंगे जो कभी बनी ही नहीं।
उससे शुरू करें जो लोड है और जो वास्तव में स्थापित है:
swanctl --list-conns
swanctl --list-sasअगर child ग़ायब है जबकि प्रोफ़ाइल सही है, तो उसे नाम से शुरू करें और देखें क्या होता है। आउटपुट आमतौर पर बताता है कि जनक पहले उठा या नहीं।
swanctl --initiate --child hq-lanसक्रिय CHILD SA अंतिम रेखा नहीं है। अग्रेषण नियम, रूट और अनुप्रयोग का अपना प्राधिकरण अभी भी मेल खाना चाहिए। जीवन-चक्र बताता है कि किस पर बातचीत हुई; यह तय नहीं कर सकता कि कौन सेवा का उपयोग कर सकता है।