फेलओव्हर चाचणी: स्थापित 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

कामाचा भार डेटा लिहीत असेल, तर वेळ संपल्यानंतर अनिश्चित क्रिया डोळे झाकून पुन्हा करू नका. उत्तर हरवण्यापूर्वी लेखन पोहोचले असू शकते. अनुप्रयोगाला निकाल विचारा, किंवा क्रिया इडेम्पोटेंट असेल तिथेच पुन्हा प्रयत्न करा. नंतर स्वीकृती विधान तीन भागांत लिहा: नवीन क्रिया एग्झिट धोरणानुसार सावरतात, विद्यमान स्ट्रीमचे नोंदवलेले व्यत्यय वर्तन आहे, आणि अनुप्रयोग सुरक्षितपणे पुढे जातो. ते विधान तपासण्याजोगे आहे, आणि आराखडा काय वचन देत नाही याबद्दल ते प्रामाणिक आहे.