strongSwan trap मोड: IPsec टनल ट्रैफ़िक का इंतज़ार क्यों करता है

स्थिति आउटपुट में कोई CHILD SA नहीं दिखता, टनल मरा हुआ लगता है, और फिर दूर के सबनेट पर एक ping उसे ऊपर ले आता है। ऑन-डिमांड IPsec सेटअप में यह क्रम ही डिज़ाइन है, कोई खराबी नहीं। trap नीति एक सिलेक्टर इंस्टॉल करती है और इंतज़ार करती है, और उससे मेल खाने वाला पहला पैकेट ही IKE और CHILD SA वार्ता शुरू करता है।

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

निष्क्रिय ऑन-डिमांड टनल के पास दिखाने को कोई CHILD SA नहीं है

trap प्रविष्टि अपने आप कुछ भी प्रमाणित नहीं करती। यह कर्नेल से चयनित ट्रैफ़िक के लिए नीति रखने और तब acquisition उठाने के लिए कहती है जब किसी पैकेट को वह नीति चाहिए। डेमन acquisition प्राप्त करता है, उसे child परिभाषा से मिलाता है और वहीं से वार्ता करता है। उस क्षण तक दिखाने को IKE SA भी नहीं होता, इसीलिए दोनों सूचियाँ एक साथ खाली हो सकती हैं।

यही क्रम लॉग को पढ़ने योग्य बनाता है। पहले acquisition आता है, फिर IKE_SA_INIT और IKE_AUTH, फिर CHILD SA। अगर लॉग acquisition के ठीक बाद खत्म होता है, तो ट्रिगर काम कर गया। वार्ता विफल रही, और अगला सवाल क्रेडेंशियल, प्रस्ताव या पहुँच के बारे में है, trap के बारे में नहीं।

Linux कर्नेल बैकएंड के साथ आप किसी भी SA के बनने से पहले नीति देख सकते हैं। चलाएँ ip xfrm policy और out दिशा तथा कनेक्शन की ओर इशारा करने वाले टेम्पलेट वाला सिलेक्टर खोजें। वही प्रविष्टि ऑन-डिमांड स्थिति है, और उसकी मौजूदगी पहली चीज़ है जिसकी पुष्टि करनी है।

start_action तय करता है कि कुछ भी इंतज़ार करेगा या नहीं

हर child swanctl.conf में start_action. start कॉन्फ़िगरेशन लोड होने पर शुरू करता है, trap नीति इंस्टॉल करता है और इंतज़ार करता है, और none शुरुआत किसी और को छोड़ देता है। केवल trap ही ऊपर वर्णित “ping और वह ऊपर आ जाता है” व्यवहार देता है।

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

दो ट्रैफ़िक सिलेक्टर तय करते हैं कि क्या दिलचस्प माना जाए, और उन प्रीफ़िक्स के बाहर के होस्ट से आया पैकेट trap नहीं छेड़ता; वह सामान्य रूप से रूट होता है। ट्रिगर को और उत्सुक बनाने के लिए सिलेक्टर चौड़ा करने से टनल जिस दायरे की सुरक्षा का दावा करता है वह भी चौड़ा होता है, इसलिए उन्हें उसी ट्रैफ़िक से लें जिसे आप वास्तव में एन्क्रिप्ट करना चाहते हैं।

यहाँ swanctl.conf संदर्भ स्वीकृत मानों की सूची देता है, साथ में अलग close और DPD क्रियाएँ जो SA बनने के बाद क्या होता है यह तय करती हैं।

पता करें कि ट्रिगर आखिर चला या नहीं

शुरू करें swanctl --list-conns से और पुष्टि करें कि child आपके इच्छित क्रिया के साथ लोड हुआ है। फिर local_ts के अंदर के होस्ट से remote_ts के अंदर के पते पर एक पैकेट भेजें और swanctl --list-sas देखें। अगर आउटपुट नहीं बदलता, तो कोई acquisition डेमन तक नहीं पहुँचा।

शांत trap के दो सामान्य कारण: पैकेट नीति तक पहुँचने से पहले source-NAT हो गया और अब local_ts से मेल नहीं खाता, या सिंटैक्स या क्रेडेंशियल त्रुटि के कारण कनेक्शन कभी लोड ही नहीं हुआ। फिर से चलाएँ swanctl --load-all और सिलेक्टर छूने से पहले उसका आउटपुट पढ़ें। जो कनेक्शन लोड नहीं हुआ वह कोई नीति इंस्टॉल नहीं करता, इसलिए ट्रैफ़िक के छेड़ने को कुछ नहीं है।

दिशा भी मायने रखती है: बाहर जाने वाले ट्रैफ़िक के लिए इंस्टॉल किया गया trap अंदर आते पैकेट पर शुरू नहीं होता। अगर दूर का पक्ष टनल ऊपर लाने वाला है, तो उसे अपना trap चाहिए, या इस पक्ष को start.

पहले पैकेट का इंतज़ार करना हमेशा सही सौदा नहीं है

इंटरैक्टिव सत्र सेटअप की कीमत महसूस करते हैं। पहला अनुरोध IKE आदान-प्रदान और CHILD वार्ता की कीमत चुकाता है, और कम समय-सीमा वाला क्लाइंट SA बनने से पहले हार मान सकता है। सक्रिय start उस पहले-पैकेट की देरी हटा देता है। पर यह ऐसे ट्रैफ़िक के लिए टनल खुला रखता है जो शायद कभी न आए।

तीन तथ्य यह चुनाव तय करते हैं: रास्ता कितनी बार इस्तेमाल होता है, पहले अनुरोध की समय-सीमा कितनी तंग है, और बूट के समय पीयर पहुँच में है या नहीं। कभी-कभार आने वाला बैच ट्रैफ़िक और बूट के समय ऑफ़लाइन हो सकने वाला पीयर, दोनों trap के पक्ष में हैं। देरी के प्रति संवेदनशील क्लाइंट और हमेशा पहुँच में रहने वाला पीयर start के पक्ष में हैं। अगर दोनों पक्ष शुरू कर सकते हैं, तो तय करें कि ट्रिगर किसका है ताकि दोहरी वार्ता न हो।

इंस्टॉल की गई नीति भी लीक-प्रूफ़ गारंटी नहीं है। अगर आवश्यकता fail-closed है, तो फ़ायरवॉल को बिना SA वाला ट्रैफ़िक गिराना होगा, और वह नियम child परिभाषा के बाहर रहता है।

अगली बहस खत्म करने वाली तीन पंक्तियाँ लिखें

सिलेक्टर, स्टार्टअप क्रिया और वह कमांड आउटपुट लिखें जो SA के बिना नीति मौजूद दिखाता है। वे तीन पंक्तियाँ अगली बार कोई टनल डाउन बताए तो “ऑन-डिमांड और निष्क्रिय” को “लोड नहीं हो रहा” से अलग करती हैं। उन्हें दर्ज करने में एक मिनट लगता है। उनके बिना वही जाँच शून्य से शुरू होती है।

ऐसे होस्ट से परखें जो वास्तव में सिलेक्टर के अंदर है। राउटर से ही किया गया ping अक्सर अलग रास्ता लेता है और उसके पीछे के सबनेट की रक्षा करने वाली नीति के बारे में कुछ साबित नहीं करता।