किल स्विच सक्रिय झाल्यावर: उघड्या TCP सत्रांना काय होते?

टनेल तुटते, किल स्विच सक्रिय होते, आणि तीन-चतुर्थांश पूर्ण झालेला डाउनलोड एकतर गोठतो किंवा लगेच अयशस्वी होतो। हे दोन्ही परिणाम संरक्षणाच्या वेगवेगळ्या स्तरांमुळे नाही, तर अंमलबजावणीच्या वेगवेगळ्या निवडींमुळे येतात। सोडून दिलेला पॅकेट कनेक्शनला प्रतीक्षेत ठेवतो, तर नाकारलेला पॅकेट ते बंद करून अनुप्रयोगाला कळवतो। कोणते वर्तन हवे हा रचनेचा प्रश्न आहे, आणि ते तपासणे हा वेगळा सराव आहे।

सोडणे, नाकारणे आणि रीसेट करणे वेगळे आहेत

रहदारी सोडणारा फायरवॉल नियम पॅकेट टाकून देतो आणि काहीही परत पाठवत नाही, त्यामुळे प्रेषक स्वतःच्या टाइमरनुसार पुन्हा पाठवत राहतो। TCP रीसेटसह नाकारणारा नियम कनेक्शन लगेच बंद करतो आणि अनुप्रयोगाला त्रुटी दिसते। बहुतेक किल स्विच सोडतात, कारण नाकारणे धोरण उघड करेल आणि सोडणे मृत नेटवर्कच्या वर्तनासारखे वाटते।

ब्लॉक करणे म्हणजे सॉकेट बंद करणे नव्हे। अनुप्रयोग अजूनही प्रस्थापित स्थितीत डिस्क्रिप्टर धरून ठेवतो, आणि फक्त पॅकेट गायब आहेत। म्हणूनच संचालन प्रणाली कनेक्शन अस्तित्वात असल्याचा आग्रह धरत असताना पृष्ठ कित्येक मिनिटे स्पिनरवर बसू शकते। अनुप्रयोगाच्या संदेशावरून अंदाज न करता दस्तऐवजीकृत अंमलबजावणी वाचा, कारण दोन्ही वर्तने नेटवर्क कोसळल्यासारखी दिसतात।

अंतर टिकत असताना अनुप्रयोग काय करतो

TCP वाढत्या विलंबाने पुन्हा पाठवतो, आणि Linux चे मूलभूत पुनर्प्रयत्न बजेट सेकंदांत नाही, तर सुमारे पंधरा मिनिटांत संपते। तोपर्यंत सॉकेट उपयुक्तपणे उघडेही नाही आणि बंदही नाही। स्वतःचे keepalive किंवा विनंती कालमर्यादा असलेले अनुप्रयोग बरेचदा लवकर हार मानतात, म्हणूनच एकाच यंत्रावरील दोन कार्यक्रम एकाच अडथळ्यात वेगळे वागतात।

टनेल परत आल्यावर स्थानिक सॉकेट बदललेले नसते, पण मार्ग बदललेला असू शकतो। नवीन सार्वजनिक स्रोत पत्ता सर्व्हरवर वेगळी चौकार मांडणी तयार करतो, त्यामुळे पलीकडील स्थितीपूर्ण फायरवॉल आता सत्राशी जुळत नाही। क्लायंटने कधीही त्रुटी न पाहिली तरी कनेक्शन मृत आहे।

पुनर्प्राप्ती आवश्यक आहे का ते ठरवा

दोन करारांपैकी एक निवडा। एकतर सत्राने लहान अंतर झेलले पाहिजे, ज्यासाठी स्थिर पत्ता नियुक्ती आणि स्थिती टिकवणारा सर्व्हर लागतो, किंवा अनुप्रयोगाने स्वच्छपणे पुन्हा जोडले पाहिजे, ज्यासाठी पुनरावृत्तीसाठी सुरक्षित पुनर्प्रयत्न तर्क लागतो। यांच्यातील काहीही सर्वात वाईट परिणाम देते: सर्व्हरने आधीच नोंदवलेले पुन्हा पाठवणारा क्लायंट, किंवा कोणालाही न दिसणाऱ्या सत्रासाठी यश नोंदवणारा क्लायंट।

स्थिर पत्ता नियुक्ती हा लोक विसरतात तो भाग आहे, कारण वेगळ्या सार्वजनिक पत्त्यावर पोहोचणारे पुनर्जोडणी क्लायंटचे सॉकेट निरोगी दिसत असतानाही सर्व्हरच्या बाजूची स्थिती रद्द करते। दोन करारांपैकी कोणता प्रत्येक अनुप्रयोगाला लागू होतो ते लिहून ठेवा, कारण ते सर्व जुळणे दुर्मिळ आहे।

ब्लॉक आणि पुनर्प्राप्ती स्वतंत्रपणे तपासा

गळती संरक्षण आणि सत्र टिकून राहणे हे दोन गुणधर्म माना, कारण एक उत्तीर्ण होणे दुसऱ्याबद्दल काहीही सांगत नाही। टिकून राहिलेले सत्र थेट रहदारी अवरोधित झाल्याचा पुरावा नाही, आणि मृत सत्र प्रत्येक थेट मार्ग अवरोधित झाल्याचा पुरावा नाही।

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'

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

अपेक्षित वर्तन अंमलबजावणी नियमाच्या शेजारी लिहा आणि तारीख टाका। तो नियम बदलणाऱ्या पुढील व्यक्तीला तैनातीने दोनपैकी कोणत्या कराराचे वचन दिले हे माहीत असणे आवश्यक आहे।