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 सन्दर्भ ले स्वीकार्य मानहरू सूचीबद्ध गर्छ, साथै SA अवस्थित भएपछि के हुन्छ भन्ने नियन्त्रण गर्ने छुट्टै close र DPD क्रियाहरू।

ट्रिगर आखिर चल्यो कि चलेन पत्ता लगाउनुहोस्

यसबाट सुरु गर्नुहोस्: 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 प्रायः फरक बाटो लिन्छ र त्यसपछाडिको सबनेटको सुरक्षा गर्ने नीतिबारे केही प्रमाणित गर्दैन।