peer रीबूटनंतर strongSwan खाली राहतो: एक बोगदा पुन्हा मिळवा

दूरचा गेटवे रीबूट होतो, एका मिनिटात परत येतो, आणि स्थानिक strongSwan डेमन काम करत राहतो तर बोगदा अजून खाली आहे। ESTABLISHED शोधून डेमन रीस्टार्ट करणारे cron काम शेवटी ते झाकून टाकेल, आणि मशीनवरील प्रत्येक असंबंधित बोगदाही तोडेल, तर कदाचित जो अयशस्वी झाला तोच चुकेल। पुनर्प्राप्ती त्या कनेक्शनची आहे जे परत आले पाहिजे, आणि ती reload टिकून राहणाऱ्या सेटिंग्जमध्ये व्यक्त होते। हे रनबुक ते एका कनेक्शनसाठी तयार करते आणि निकाल नावाने सिद्ध करते।

जागतिक रीस्टार्ट सोडा, त्याचे पुरावे ठेवा

डेमन रीस्टार्टला दोन ठोस दोष आहेत: ते प्रत्येक कनेक्शनची स्थिती नष्ट करते, आणि कोणती घटना खरोखर अयशस्वी झाली हे सांगत नाही। तुम्ही शोधलेला स्टेटस मजकूर दुसऱ्या कनेक्शनचा असू शकतो, तर आवश्यक child काहीच सुरू न केल्याने रिकामा बसला होता।

काहीही बदलण्यापूर्वी लोड झालेली कनेक्शन्स आणि सक्रिय सहयोग वाचा, म्हणजे peer परत आल्यावर तुलना करण्यासाठी तुमच्याकडे आधीचे चित्र असेल।

swanctl --list-conns
swanctl --list-sas

सुरुवात आणि पुनःप्रयत्न परत येणाऱ्या कनेक्शनवर ठेवा

swanctl.conf तैनातीत ही सेटिंग्ज जागतिक धोरणात नाही, कनेक्शन आणि child स्तरावर राहतात। खालील भाग हा सुरुवात करणाऱ्याच्या बाजूचा उदाहरण आहे जो प्रस्ताव, प्रमाणीकरण आणि निवडक आधीच बरोबर आहेत असे गृहीत धरतो।

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

child लोड होताना काय होते हे start_action ठरवते: start लगेच सुरू करते, तर trap जुळणारा रहदारी आल्यावर सुरुवात सुरू करणारे धोरण बसवते। trap|start लिहिण्यासाठी strongSwan 5.9.6 किंवा नंतरची आवृत्ती लागते, म्हणून ओळ कॉपी करण्यापूर्वी आवृत्ती तपासा। dpd_action=restart peer मृत घोषित झाल्यावर नवीन बोलणी मागते, आणि कनेक्शन स्तरावरील keyingtries=0 यश किंवा कायमची त्रुटी होईपर्यंत अधिक प्रयत्नांना परवानगी देते। IKEv2 अंतर्गत dpd_timeout ला अजिबात परिणाम नाही, कारण peer कधी प्रतिसाद देत नाही हे सामान्य पुनःप्रेषण ठरवते।

त्या उदाहरणातील विलंब हा प्रारंभ बिंदू आहे, सार्वत्रिक मुदत नाही। peer चा रीबूट किती वेळ घेतो आणि किती पुनःप्रेषण सहन करायला तुम्ही तयार आहात यावरून तो निवडा।

तुम्ही कोणत्या घटनेतून पुनर्प्राप्ती करत आहात ते जाणून घ्या

तीन बिघाड डॅशबोर्डवर सारखे दिसतात आणि वेगवेगळ्या सेटिंग्ज मागतात। कधीच न उभे राहिलेले सुरुवातीचे कनेक्शन ही संरचना किंवा पोहोचण्याची समस्या आहे। प्रतिसाद देणे थांबवलेला peer हा DPD प्रकार आहे। peer ने स्पष्टपणे बंद केलेला child ही स्वतःच्या close_action असलेली धोरण घटना आहे, जी DPD कधीच पाहत नाही। व्यत्ययाच्या सभोवतालचा लॉग वाचल्यास तीनपैकी कोणता आहे ते समजते, आणि उत्तर उपाय बदलते।

ऑपरेटर देखभालीसाठी जाणीवपूर्वक बंद करतात अशा कनेक्शनमध्ये आक्रमक पुनःसुरुवात जोडू नका, नाहीतर विंडोच्या मध्यात बोगदा पुन्हा दिसेल। मागणी-आधारित रचनांसाठी ठेवलेला trap पुरतो, कारण जुळणारा रहदारी कोणत्याही टाइमरशिवाय child पुन्हा उभा करतो।

डेमन स्थितीने नाही, नावाने पडताळा

peer अजून खाली असताना कनेक्शन आणि त्याचा child नावाने वाचा, नंतर परत आल्यावर पुन्हा वाचा; त्या दोन आउटपुटमधील फरक हाच पुरावा आहे।

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

नंतर सहयोग नाही, सेवा पुष्टी करा। नवीन child सुरक्षा सहयोग आणि त्याच्या मागील खाजगी गंतव्यस्थानाकडे यशस्वी विनंती—हीच महत्त्वाची दोन तथ्ये आहेत, आणि निरोगी असंबंधित बोगद्यासह चालणारा डेमन दोन्हीपैकी काहीही सिद्ध करत नाही।

child कधीच सुरू होत नसेल तर चाचणी रहदारी संरचित निवडकांशी तंतोतंत जुळते का ते तपासा, प्रोटोकॉल आणि पोर्टसह। ते सुरू होऊन अयशस्वी झाले तर अंतहीन लूपमागे लपवण्याऐवजी प्रमाणीकरण किंवा प्रस्ताव त्रुटी वाचा, कारण keyingtries=0 कायमचा नकार हमेशा पुनरावृत्त करेल।

बदल विंडोमध्ये लोड करा आणि पुन्हा चाचणी करा

रीलोड डेमन रीस्टार्टपेक्षा सुरक्षित आहे, आणि तरीही मोफत नाही: child बदलणे किंवा अनलोड करणे सुरू झालेला सहयोग बंद करू शकते किंवा त्याचा trap पाडू शकते।

देखभाल विंडोमध्ये लोड करा, मागील फाइल ठेवा, आणि कनेक्शन डीफॉल्टऐवजी तुमच्या इच्छित सेटिंग्जसह दिसते याची खात्री करा।

swanctl --load-conns
swanctl --list-conns

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