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

अघिल्लो फाइल पुनःस्थापित गरेर फेरि लोड गरी रोलब्याक गर्नुहोस्, त्यसपछि ती दुई आदेश दोहोर्याउनुहोस्। डेमन रिस्टार्टपछि मात्र फर्कने टनेल मर्मत भएको होइन, रिसेट भएको हो।