कौन-सा NAT हॉप निष्क्रिय VPN मैपिंग गिरा देता है और यह कैसे पता करें
एक निष्क्रिय VPN प्रवाह किसी भी स्थिति रखने वाले हॉप पर मर सकता है। एक परीक्षण दोहराएँ, हर सीमा ने क्या देखा इसकी तुलना करें, और अनुमानित दोषी के बजाय सीमित परिणाम की रिपोर्ट करें।
शांत अवधि के बाद टनल फिर जुड़ जाता है, कोई लॉग दोषी का नाम नहीं लेता, और स्पष्ट कदम है सबसे प्रभावशाली टाइमआउट दस्तावेज़ीकरण वाला उपकरण चुनना। यह निदान के वेश में एक अनुमान है। स्थिति कुछ समय तक घरेलू राउटर में, ऑपरेटर के अनुवादक में और क्लाउड किनारे पर बची रह सकती है, और इनमें से कोई भी चुप हो जाने वाला प्रवाह गिरा सकता है। इसके बजाय आप पथ का नक्शा बना सकते हैं, यह चिह्नित कर सकते हैं कि किन उपकरणों को आप वास्तव में देख सकते हैं, और एक निष्क्रिय परीक्षण चला सकते हैं जिसे आप दोहरा सकें।
दोहराने योग्य परीक्षण किस्से को माप में बदल देता है। नीचे सब कुछ एक क्लाइंट, एक सर्वर और एक प्रोटोकॉल मानता है, और मानता है कि आप एक साथ दो चर बदलने से बचते हैं। मकसद यह है कि अगली घटना इससे सस्ती पड़े।
हर बार वही निष्क्रिय परीक्षण चलाएँ
लिखें कि प्रवाह आखिरी बार कब ठीक था, उसके बाद कितनी देर निष्क्रिय रहा, और क्या एक ताज़ा पैकेट उसे वापस लाया। ये तीन तथ्य ही माप हैं; इनके बिना आपके पास गिरे हुए लैपटॉप की कहानी है। हर दोहराव में वही क्लाइंट, वही सर्वर और वही प्रोटोकॉल इस्तेमाल करें, और वह क्षण दर्ज करें जब खामोशी के बाद पहला पैकेट भेजा गया।
फिर तुलना करें कि आपकी हर सीमा ने वास्तव में क्या देखा। जो अंतर जाँच तय करता है वह यह है कि सर्वर ने रुकावट के बाद कुछ भी नहीं देखा, या अनुरोध देखा और ऐसे पथ में जवाब दिया जो अब जवाब नहीं ढो रहा था।
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
पाँच चीज़ें बदले बिना पथों की तुलना
दूसरा स्वीकृत एक्सेस नेटवर्क वैध तुलना है, क्योंकि NAT शृंखला अलग है। यह प्रदाता, रेडियो परिस्थितियों और शायद पता परिवार में भी अलग है, इसलिए परिणाम सीमा है, आरोप नहीं। रिपोर्ट करते समय सीमाओं को चुपचाप छोड़ने के बजाय परिणाम के साथ दर्ज करें। पथ भी साथ लिखें: उपकरण, भूमिका, और क्या उसकी स्थिति बिलकुल पढ़ी जा सकती है।
पथों की तुलना आपको एक सीमित सवाल देती है: प्रवाह एक पर बचा रहता है और दूसरे पर समान खामोशी के बाद मर जाता है, इसलिए चर अलग पड़ने वाले हिस्सों में कहीं है। किसी उपकरण का नाम न होने पर भी यह वास्तविक परिणाम है, और यह अगले इंजीनियर को बताता है कि दोपहर कहाँ बितानी है और कहाँ नहीं।
ऑपरेटरों के बारे में अटकलें लगाने से पहले स्थानीय स्थिति पढ़ना उचित है। Linux गेटवे पर conntrack -L ट्रैक किए गए प्रवाहों को उनकी बची हुई आयु के साथ सूचीबद्ध करता है, जो टाइमर के बारे में अनुमान को ऐसी संख्या में बदल देता है जिसे आप खत्म होते देख सकते हैं। इसे निष्क्रिय अवधि से पहले और बाद में पढ़ें, केवल बाद में नहीं।
कीपअलाइव क्या टिकाएगा और क्या नहीं
समर्थित कीपअलाइव मैपिंग खुली रखता है, और मैपिंग खुली रखना उसके पीछे की सेवा के बारे में कुछ साबित नहीं करता। टनल मैप रह सकता है जबकि उसके द्वारा ढोया जाने वाला एप्लिकेशन जवाब देना बंद कर चुका है, और स्टेटस लाइट से ये दोनों स्थितियाँ एक जैसी दिखती हैं। कीपअलाइव को निष्क्रिय समाप्ति के खिलाफ बीमा मानें, स्वास्थ्य जाँच नहीं।
अंतराल उस सबसे छोटे टाइमआउट के हिसाब से तय करें जिसे आपने वास्तव में मापा है, किसी फोरम से नकल की गई संख्या के हिसाब से नहीं। हर संभव टाइमर से नीचे ट्यून किया गया कीपअलाइव वह ट्रैफ़िक है जिसकी किसी को ज़रूरत नहीं थी, और यह उस लक्षण को भी हटा देता है जो बताता कि कौन-सी सीमा पहले समाप्त होती है। अंतराल मापी गई संख्या से चुनें और बाकी सबको ऐसे ही रहने दें।
एक बदलाव, फिर दोबारा मापें
लाइव परीक्षण के दौरान हर टाइमआउट बढ़ाने और हर गेटवे को फ्लश करने की इच्छा का विरोध करें। यह उन सबूतों को मिटा देता है जिनके लिए आप आए और दूसरों के प्रवाह बाधित करता है, जो बिना जाँची परिकल्पना के लिए बुरा सौदा है। एक उपकरण पर एक समर्थित सेटिंग बदलें, फिर निष्क्रिय अवधि और एप्लिकेशन की वसूली दोहराएँ।
दर्ज करें कि कौन-सा सीमा-अवलोकन बदला, और कुछ सुधरा न हो तो भी दर्ज करें। जिस सेटिंग ने कुछ ठीक नहीं किया वह जानकारी है, और पूरे परिसर में घुमाने के बजाय एक बार नोटिस करना सस्ता है।
ऐसी खोज लिखना जिसका आप बचाव कर सकें
जब ऊपर की ओर का अनुवादक जाँचा न जा सके, तो केवल वही कहें जो सबूत समर्थित करते हैं: अदला-बदली इस पथ के इस हिस्से में कहीं इतनी खामोशी के बाद मर जाती है, और ज़िम्मेदार हॉप बिना आरोपित रहता है। सीमित कथन समीक्षा में टिकता है और अगले व्यक्ति को सही खंड की ओर इंगित करता है। छिपे राउटर को कारण बताना इन दोनों में से कुछ नहीं करता। सीमित खोज अंतराल के साथ उस व्यक्ति को दें जिसके पास अवलोकन-अयोग्य खंड है।
RFC 4787 बताता है कि UDP मैपिंग टाइमर एक सिरे से अनुमान लगाना कठिन क्यों है, और यही कठिनाई सीमित खोज को ईमानदार बनाती है। टाइमर वास्तविक हैं, और उनके आसपास की अनिश्चितता भी।