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 बऱ्याचदा वेगळा मार्ग घेतो आणि त्यामागील सबनेटचे संरक्षण करणाऱ्या धोरणाबद्दल काहीच सिद्ध करत नाही.