रीकी, पुनः कनेक्ट या पुनः प्रमाणीकरण: आपको कौन-सा चाहिए?

घंटों से चल रहा सत्र हमेशा वही कुंजियाँ नहीं रखेगा, और यह जानबूझकर है। तीन अलग-अलग घटनाओं को कुंजी रोटेशन कहा जाता है: मौजूदा एसोसिएशन के अंतर्गत नई सत्र सामग्री, कनेक्शन का पूरा पुनर्निर्माण, और पहचान जाँच की पुनरावृत्ति। हर एक का ट्रिगर, लागत और विफलता हस्ताक्षर अलग है। गलत चुनें तो सुधार या तो कुछ नहीं करेगा या बिना कारण टनल गिरा देगा।

निर्णय इस पर निर्भर है कि वास्तव में कौन-सी परत समाप्त हुई है।

रोटेशन कही जाने वाली तीन क्रियाएँ

रीकी मौजूदा नियंत्रण संबंध के भीतर प्रोटोकॉल द्वारा निर्धारित तंत्र का उपयोग करके नई ट्रैफ़िक कुंजियाँ बनाता है। IKEv2 यह नए चाइल्ड सुरक्षा एसोसिएशन से करता है, TLS 1.3 कुंजी अद्यतन संदेश से, और WireGuard समय या संदेश सीमा पूरी होने पर नए हैंडशेक से। टनल के पते और प्रमाणित पहचान जहाँ थे वहीं रहते हैं।

पुनः कनेक्ट कनेक्शन को छोड़कर उसे शुरू से फिर बनाता है, जिससे पता आवंटन, रूटिंग स्थापना और पहले प्रयास की हर बातचीत दोहराई जाती है।

पुनः प्रमाणीकरण पहचान का प्रमाण ही दोहराता है, जिसमें क्रेडेंशियल, प्रमाणपत्र या दूसरा कारक शामिल हो सकता है। उत्पाद के अनुसार यह पुनः कनेक्ट के साथ या उसके बिना हो सकता है।

नवीनीकरण पर उपयोगकर्ता क्या नोटिस करते हैं

रीकी लगभग अदृश्य होना चाहिए। एसोसिएशन पहचानकर्ता बदलते हैं, काउंटर रीसेट हो सकते हैं, और एप्लिकेशन अपने सॉकेट रखते हैं; आदान-प्रदान के दौरान एक दिशा में थोड़ा ठहराव सामान्य है। स्थिति सूची में नया पहचानकर्ता दिखना खराबी का प्रमाण नहीं है। आदान-प्रदान के बाद की लॉग पंक्ति ही बताती है कि वह पूरा हुआ या नहीं।

नवीनीकरण पर असली कटाव किसी विशिष्ट जगह की ओर इशारा करता है। प्रस्ताव का बेमेल होना, समाप्त क्रेडेंशियल या पथ परिवर्तन — हर एक अलग लॉग पंक्ति बनाता है, और इनमें से केवल एक ही जीवनकाल समायोजित करके ठीक होता है।

व्यवहार में तीनों कहाँ अलग होते हैं

अगर केवल कुंजी सामग्री समाप्त हुई है, तो रीकी करें। अगर पीयर पता, रूट या NAT बाइंडिंग बदल गई है और पैकेट अब नहीं पहुँचते, तो पुनः कनेक्ट करें। अगर संगठन आवधिक पहचान जाँच माँगता है, तो वह पुनः प्रमाणीकरण है और कोई जीवनकाल समायोजन उसका विकल्प नहीं है।

प्रोटोकॉल के डिफ़ॉल्ट में आमतौर पर सही उत्तर होता है। WireGuard बिना किसी उपयोगकर्ता क्रिया के समय और डेटा-मात्रा सीमा के बाद कुंजियाँ बदलता है; IKEv2 के जीवनकाल हर चाइल्ड एसोसिएशन के लिए तय होते हैं; TLS आधारित टनल मौजूदा सत्र के भीतर ही कुंजियाँ घुमाते हैं। बार-बार होने वाली त्रुटि से बचने के लिए जीवनकाल बढ़ाना विफलता को टालता है और कुंजी लीक होने पर जोखिम लंबा कर देता है।

लंबे सत्रों के लिए एक चेतावनी ज़रूरी है: केवल आवृत्ति फ़ॉरवर्ड सीक्रेसी नहीं बनाती। यह गुण इस पर निर्भर है कि सत्र कुंजियाँ दीर्घकालिक रहस्यों से कैसे संबंधित हैं और पुरानी कुंजियाँ नष्ट की जाती हैं या नहीं, जो सेटिंग नहीं बल्कि डिज़ाइन और कार्यान्वयन का प्रश्न है।

डिफ़ॉल्ट चुनें, फिर चरण दर्ज करें

प्रलेखित आवश्यकता अलग न कहे तो विक्रेता के डिफ़ॉल्ट रखें, और जीवनकाल बदलना हो तो दोनों पीयर पर बदलें। फिर दर्ज करें कि हर घटना किस चरण तक पहुँची, ताकि अगली बार उसी हैंडशेक बिंदु से तुलना की जा सके।

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

सुधार के बाद नियंत्रित नवीनीकरण करें और नए एसोसिएशन से ताज़ा एप्लिकेशन ट्रैफ़िक भेजें। जो टनल खुद को स्थापित बताती है पर कुछ भी आगे नहीं भेजती, वही विफलता है जिसे पकड़ने के लिए यह जाँच है।