किल स्विच सक्रिय: खुले TCP सत्रों का क्या होता है?

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

छोड़ना, अस्वीकार करना और रीसेट करना अलग-अलग हैं

ट्रैफ़िक छोड़ने वाला फ़ायरवॉल नियम पैकेट को नष्ट कर देता है और कुछ वापस नहीं भेजता, इसलिए प्रेषक अपने टाइमर पर फिर भेजता रहता है। TCP रीसेट के साथ अस्वीकार करने वाला नियम कनेक्शन तुरंत बंद कर देता है और एप्लिकेशन को त्रुटि दिखती है। अधिकांश किल स्विच छोड़ते हैं, क्योंकि अस्वीकृति नीति का खुलासा कर देती और छोड़ना मृत नेटवर्क जैसा व्यवहार लगता है।

अवरोध करना सॉकेट बंद करने के समान नहीं है। एप्लिकेशन अभी भी स्थापित अवस्था में डिस्क्रिप्टर रखे हुए है, और केवल पैकेट गायब हैं। इसीलिए कोई पृष्ठ मिनटों तक स्पिनर पर बैठा रह सकता है जबकि ऑपरेटिंग सिस्टम कहता है कि कनेक्शन मौजूद है। एप्लिकेशन के संदेश से अनुमान लगाने के बजाय दस्तावेज़ीकृत प्रवर्तन पढ़ें, क्योंकि दोनों व्यवहार नेटवर्क के गिरने जैसे दिखते हैं।

अंतराल के दौरान एप्लिकेशन क्या करता है

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

जब टनल लौटती है, स्थानीय सॉकेट नहीं बदला होता, पर पथ बदल सकता है। नया सार्वजनिक स्रोत पता सर्वर पर अलग चार-टपल बनाता है, इसलिए दूसरी ओर का स्टेटफुल फ़ायरवॉल अब सत्र से मेल नहीं खाता। कनेक्शन मृत है, भले ही क्लाइंट ने कभी त्रुटि नहीं देखी।

तय करें कि रिकवरी आवश्यक है या नहीं

दो अनुबंधों में से चुनें। या तो सत्र को छोटे अंतराल में बचे रहना चाहिए, जिसके लिए स्थिर एड्रेसिंग और स्थिति बनाए रखने वाला सर्वर चाहिए, या एप्लिकेशन को साफ़-सुथरे ढंग से फिर से जुड़ना चाहिए, जिसके लिए ऐसा पुनःप्रयास तर्क चाहिए जिसे दोहराना सुरक्षित हो। बीच का कोई भी विकल्प सबसे बुरा परिणाम देता है: ऐसा क्लाइंट जो वही फिर भेजता है जो सर्वर पहले ही दर्ज कर चुका है, या ऐसा जो उस सत्र के लिए सफलता की रिपोर्ट करता है जिसे कोई देख नहीं सकता।

स्थिर एड्रेसिंग वह हिस्सा है जिसे लोग भूल जाते हैं, क्योंकि अलग सार्वजनिक पते पर पहुँचने वाला पुनःकनेक्शन सर्वर-पक्ष की स्थिति को अमान्य कर देता है, भले ही क्लाइंट का सॉकेट स्वस्थ दिखे। लिखें कि कौन-सा अनुबंध किस एप्लिकेशन पर लागू होता है, क्योंकि वे शायद ही सब मेल खाते हैं।

ब्लॉक और रिकवरी को अलग-अलग जाँचें

लीक सुरक्षा और सत्र के बचे रहने को दो गुण मानें, क्योंकि एक का पास होना दूसरे के बारे में कुछ नहीं कहता। बचा रहा सत्र इस बात का प्रमाण नहीं कि सीधा ट्रैफ़िक अवरुद्ध हुआ, और मृत सत्र इस बात का प्रमाण नहीं कि हर सीधा मार्ग अवरुद्ध हुआ।

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

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

अपेक्षित व्यवहार को प्रवर्तन नियम के बगल में लिखें और तारीख डालें। उस नियम को बदलने वाले अगले व्यक्ति को जानना चाहिए कि परिनियोजन ने दोनों में से कौन-सा अनुबंध वादा किया था।