फेलओभर परीक्षण: स्थापित TCP स्ट्रिम टिक्छ?

«ब्याकअप काम गर्छ» भन्ने वाक्यभित्र दुई नतिजा लुकेका छन्। नयाँ अनुरोध सफल हुन्छ, त्यो पुनःप्राप्ति हो। पहिले नै चलिरहेको स्थानान्तरण जारी रहन्छ, त्यो निरन्तरता हो। यी दुई फरक वाचा हुन्, र धेरै फेलओभर योजनाहरू पहिलो दिन्छन् जबकि दोस्रो चुपचाप समय सकिएर टुंगिन्छ। कुन चाहिन्छ भनेर संयन्त्र छान्नु अघि निर्णय गर्नुहोस्, र दुवैलाई छुट्याउन सक्ने गरी परीक्षण लेख्नुहोस्।

एउटै सफलता जस्तो देखिने दुई नतिजा

10.90.0.42 मा रहेको क्लाइन्टको 198.51.100.20:443 सँग जडान छ भनी कल्पना गर्नुहोस्। प्राथमिक एग्जिटले त्यसलाई एउटा सार्वजनिक ठेगाना र पोर्टमा रूपान्तरण गर्छ, र ब्याकअप एग्जिटले अर्कोमा। क्लाइन्टको आन्तरिक ठेगाना कहिल्यै बदलिँदैन, त्यसैले मानिसहरू जडान टिक्छ भन्ने अपेक्षा गर्छन्।

सर्भरले आन्तरिक ठेगाना देख्दैन। यसले रूपान्तरित अन्त्यबिन्दु देख्छ, र स्विचपछि त्यो बिन्दु फरक हुन्छ।

त्यसैले पुरानो स्ट्रिम समय सकिएर टुंगिन्छ जबकि त्यही सेवामा नयाँ जडान तुरुन्तै काम गर्छ। दुवै अवलोकन एकै समयमा सत्य हुन्।

एग्जिट बदलिँदा सर्भरले के देख्छ

TCP जडान यसको चारअंशले पहिचान गरिन्छ, र स्रोत ठेगाना वा पोर्ट बदल्दा प्राप्त गर्ने होस्टका लागि फरक जडान बन्छ। सर्भरलाई थाहा नभएको जडानमा नयाँ स्रोतबाट आउने प्याकेट हटाइन्छ वा रिसेटले जवाफ दिइन्छ। VPN क्लाइन्टको ठेगानामा त्यो परिवर्तनभरि सम्बन्ध जोगाउने केही छैन।

अवस्थायुक्त फेलओभर ठ्याक्कै यसैबाट बच्नका लागि छ, र यो अगाडि पठाउने उपकरणहरूबीच रूपान्तरण अवस्था र जडान अवस्था साटासाट गरेर काम गर्छ। यो जोडीको विशेषता हो, सुरुङको होइन, र यसलाई अनुमान गर्नुको सट्टा डिजाइन र परीक्षण गर्नुपर्छ।

कसैलाई निरन्तरताको वाचा गर्नु अघि जोडीले साँच्चै अवस्था राख्छ कि जाँच्नुहोस्। तलका आदेशहरू दुवैतर्फको हालको अवस्था देखाउँछन्।

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

एउटै सार्वजनिक ठेगाना किन पर्याप्त हुँदैन

दुवै मार्गमा एउटा सार्वजनिक ठेगाना राख्नु राम्रो सुरुवात हो, किनकि त्यसपछि सर्भरले त्यही स्रोत अन्त्यबिन्दु देख्छ। तर एक्लैले यो पर्याप्त हुँदैन। अगाडि पठाउने उपकरणलाई अझै रूपान्तरण अवस्था, फायरवाल अवस्था र प्रयोगयोग्य फर्कने मार्ग चाहिन्छ, र ती स्विचपछि ट्राफिक बोक्ने उपकरणमै हुनुपर्छ।

RFC 3022 ले ठेगाना रूपान्तरण वर्णन गर्छ र रूपान्तरण गर्ने उपकरणहरूबीच अवस्था साटासाटलाई ब्याकअप योजनाको भाग मान्छ। तैरने ठेगाना वा प्रतिलिपि गरिएको प्रोफाइलले कन्फिगरेसन सार्छ तर अवस्था सार्दैन।

त्यसैले ब्याकअपबाट मात्र पिंग गर्ने परीक्षणले धेरै थोरै प्रमाणित गर्छ। पिंगसँग गुमाउने जडान अवस्था हुँदैन।

आवश्यकता कति बलियो छ निर्णय गर्नुहोस्

यदि प्रयोगकर्ताले असफलतापछि पुनः जडान गर्न सक्छन् भने योजना पुनःप्राप्ति योजना हो र स्वीकृति परीक्षण नयाँ अनुरोध हो। यदि फाइल स्थानान्तरण टिक्नुपर्छ भने योजनालाई अवस्था समकालिकीकरण र धेरै सतर्क परीक्षण चाहिन्छ। यदि टाढाको सत्र टिक्नुपर्छ भने आवश्यकता अझ बलियो छ र नेटवर्क तहको सट्टा अनुप्रयोग तहको संयन्त्र चाहिन सक्छ।

आवश्यकतालाई मापन गर्न सकिने नतिजासहितको वाक्यका रूपमा लेख्नुहोस्, जस्तै अपलोड पुनः सुरु नगरी पूरा हुन्छ वा अपरेटर एक मिनेटभित्र पुनः जडान हुन्छ। त्यसपछि त्यसलाई पूरा गर्ने सबैभन्दा सस्तो संयन्त्र छान्नुहोस्, र त्यो प्रायः पुनःप्राप्ति योजना हुन्छ।

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

पुरानो स्ट्रिम र नयाँ अनुरोध जाँच्नुहोस्

प्राथमिक मार्गबाट हानिरहित लामो स्थानान्तरण सुरु गर्नुहोस्, त्यसपछि त्यही सेवामा छुट्टै नयाँ अनुरोध। अनुप्रयोग सन्दर्भ, अवलोकित एग्जिट ठेगाना र समय रेकर्ड गर्नुहोस्। स्वीकृत तरिकाले प्राथमिक तोड्नुहोस् र ब्याकअपबाट नयाँ अनुरोध पठाउँदै मूल स्थानान्तरण हेरिरहनुहोस्।

तीन मान रिपोर्ट गर्नुहोस्: पुरानो स्ट्रिम जारी रह्यो, रिसेट भयो वा समय सकिएर टुंगियो; नयाँ कार्य पहिलो पटक कहिले चल्यो; र फेलब्याकले केही तोड्यो कि। ती तीन लाइन नै स्वीकृति रेकर्ड हुन्।

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

यदि कार्यभारले डाटा लेख्छ भने समय सकिएपछि अनिश्चित कार्य आँखा चिम्लिएर दोहोर्याउनु हुँदैन। जवाफ हराउनु अघि लेखाइ पुगेको हुन सक्छ। अनुप्रयोगलाई नतिजा सोध्नुहोस्, वा कार्य इडेम्पोटेन्ट हुने ठाउँमा मात्र फेरि प्रयास गर्नुहोस्। त्यसपछि स्वीकृति वक्तव्य तीन भागमा लेख्नुहोस्: नयाँ कार्यहरू एग्जिट नीतिअन्तर्गत पुनःप्राप्त हुन्छन्, विद्यमान स्ट्रिमहरूको अभिलेखित अवरोध व्यवहार छ, र अनुप्रयोग सुरक्षित रूपमा अगाडि बढ्छ। त्यो वक्तव्य परीक्षणयोग्य छ, र योजनाले के वाचा गर्दैन भन्नेमा त्यो इमानदार छ।