peer के रीबूट के बाद strongSwan नीचे रहता है: एक टनल बहाल करें

दूरस्थ गेटवे रीबूट होता है, एक मिनट में लौट आता है, और स्थानीय strongSwan डेमन चलता रहता है जबकि टनल अब भी नीचे है। ESTABLISHED खोजकर डेमन रीस्टार्ट करने वाला cron जॉब अंततः इसे ढक देगा, और मशीन पर हर असंबंधित टनल को भी काट देगा, जबकि शायद वही टनल चूक जाएगा जो विफल हुआ। रिकवरी उस कनेक्शन की है जिसे लौटना है, और वह ऐसी सेटिंग्स में व्यक्त होती है जो रीलोड के बाद भी टिकती हैं। यह रनबुक इसे एक ही कनेक्शन के लिए स्थापित करता है और परिणाम को नाम से सिद्ध करता है।

वैश्विक रीस्टार्ट छोड़ें, उसके साक्ष्य रखें

डेमन रीस्टार्ट में दो ठोस खामियाँ हैं: यह हर कनेक्शन की स्थिति नष्ट कर देता है, और यह आपको यह नहीं बताता कि वास्तव में कौन-सी घटना विफल हुई। जिस स्टेटस टेक्स्ट को आपने खोजा हो वह किसी दूसरे कनेक्शन से आया हो सकता है, जबकि आवश्यक 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
            }
        }
    }
}

start_action तय करता है कि child लोड होने पर क्या होता है: start तुरंत शुरू करता है, जबकि trap ऐसी नीति स्थापित करता है जो मेल खाता ट्रैफ़िक आने पर इनिशिएशन शुरू करती है। trap|start लिखने के लिए strongSwan 5.9.6 या बाद का संस्करण चाहिए, इसलिए पंक्ति कॉपी करने से पहले संस्करण जाँचें। dpd_action=restart peer के मृत घोषित होते ही नया वार्तालाप माँगता है, और कनेक्शन स्तर पर keyingtries=0 सफलता या स्थायी त्रुटि तक और प्रयासों की अनुमति देता है। IKEv2 के अंतर्गत dpd_timeout का कोई प्रभाव नहीं होता, क्योंकि सामान्य पुनःप्रेषण ही तय करता है कि peer कब उत्तर नहीं दे रहा।

उस उदाहरण में देरी एक प्रारंभिक बिंदु है, कोई सार्वभौमिक समय-सीमा नहीं। इसे इस आधार पर चुनें कि peer का रीबूट कितना समय लेता है और आप कितना पुनःप्रेषण सहने को तैयार हैं।

जानें कि आप किस घटना से बहाली कर रहे हैं

तीन विफलताएँ डैशबोर्ड पर एक जैसी दिखती हैं और अलग-अलग सेटिंग्स माँगती हैं। कभी न उठा शुरुआती कनेक्शन कॉन्फ़िगरेशन या पहुँच की समस्या है। जिस peer ने जवाब देना बंद किया वह DPD का मामला है। जिस child को peer ने स्पष्ट रूप से बंद किया वह अपने 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

पिछली फ़ाइल बहाल करके और उसे फिर लोड करके वापस जाएँ, फिर वही दो कमांड दोहराएँ। जो टनल केवल डेमन रीस्टार्ट के बाद लौटता है, वह मरम्मत नहीं हुआ, रीसेट हुआ है।