कुन 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 म्यापिङ टाइमरहरू एक छेउबाट अनुमान गर्न किन गाह्रो हुन्छ भन्ने व्याख्या गर्छ, र त्यही कठिनाइले सीमित खोजलाई इमानदार बनाउँछ। टाइमरहरू वास्तविक छन्, र तिनका वरिपरिको अनिश्चितता पनि।