कोणती 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 मॅपिंग टाइमरचा अंदाज लावणे का कठीण आहे हे स्पष्ट करते, आणि तीच अडचण मर्यादित शोधनोंद प्रामाणिक बनवते। टाइमर वास्तविक आहेत, आणि त्यांच्याभोवतीची अनिश्चितताही।