किल स्विच सक्रिय हुँदा: खुला 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'

पुनःप्राप्ति अवलोकन गर्दा हानि नगर्ने परीक्षण कार्य प्रयोग गर्नुहोस्, ताकि दोहोरो सबमिसन घटना नबनोस्। तपाईंले वास्तवमै देख्नुभएको असफलता प्रकार रेकर्ड गर्नुहोस्: अनुप्रयोगले के देखायो, सकेट टिक्यो कि, र त्यो आफैं कहिले सुधारियो।

अपेक्षित व्यवहार कार्यान्वयन नियमको छेउमा लेख्नुहोस् र मिति राख्नुहोस्। त्यो नियम परिवर्तन गर्ने अर्को व्यक्तिले तैनाथीले दुईमध्ये कुन सम्झौताको वाचा गरेको थियो भन्ने जान्नु आवश्यक छ।