TCP रीसेट हे तुमचा VPN ब्लॉक होत असल्याचा पुरावा नाही

क्लायंट लॉगमध्ये “कनेक्शन रीसेट, पुन्हा सुरू होत आहे” दिसते, आणि निष्कर्ष पुराव्यापूर्वी येतो. नेटवर्क VPN ब्लॉक करत आहे, किंवा प्रमाणपत्र चुकीचे आहे, किंवा एखादा देश हस्तक्षेप करत आहे असे कोणी ठरवते. रीसेट हे कनेक्शन संपवणारे TCP पॅकेट आहे, आणि लॉग ओळ नोंदवते की तुमच्या क्लायंटला एक मिळाले. ते पाठवणाऱ्या उपकरणाचे नाव देत नाही किंवा कारणही सांगत नाही.

रीसेट एक पॅकेट आहे, निवाडा नाही

TCP रीसेट प्रक्रिया परिभाषित करते: RST फ्लॅग असलेला सेगमेंट कनेक्शन लगेच संपवतो. प्राप्तकर्ता वाटाघाटी करत नाही, पुन्हा प्रयत्न करत नाही आणि का विचारत नाही. तो रीसेटची नोंद देतो आणि पुढे जातो.

क्लायंटला एवढेच माहीत आहे. RST सर्व्हर, प्रॉक्सी, फायरवॉल किंवा स्थिती गमावलेल्या लोड बॅलन्सरकडून आले असू शकते.

स्रोत निश्चित करणे हा वेगळा सराव आहे. कॅप्चरमध्ये दिसणारा स्रोत पत्ता भौतिक उगमाचा पुरावा नाही, आणि त्यामागील धोरण निर्णयाबद्दल काहीही सांगत नाही. मध्यस्थ उपकरणे पत्ते बनावट करू शकतात, आणि स्थिती असलेली उपकरणे हेतूनुसार नव्हे तर कालबाह्यतेमुळे रीसेट करू शकतात. रीसेटला निवाडा मानल्यास सत्य शोधण्याचा भाग वगळला जातो.

कोणते कनेक्शन रीसेट झाले ते निश्चित करा

प्रथम सक्रिय प्रोफाइल खरोखर TCP वापरते का ते तपासा. UDP टनलवर रीसेटला अर्थ नाही, आणि HTTP प्रॉक्सीचा लॉग VPN पेक्षा वेगळ्या TCP भागाशी संबंधित असू शकतो.

गंतव्य, पोर्ट, प्रयत्नाची वेळ आणि क्लायंट पोहोचलेला टप्पा नोंदवा.

टप्पा हे सर्वात उपयुक्त क्षेत्र आहे. TLS हँडशेक दरम्यानचा रीसेट एका संशयित गटाकडे निर्देश करतो; प्रमाणीकरणानंतरचा रीसेट दुसऱ्याकडे. टप्प्याशिवाय प्रत्येक सिद्धांत जुळतो.

मार्गाच्या दोन्ही टोकांची तुलना करा

तुम्ही सर्व्हर व्यवस्थापित करत असल्यास, त्याच प्रयत्नासाठी त्याच्या घटनांची तुलना करा. त्याने कनेक्शन स्वीकारले का? ते जाणूनबुजून बंद केले का? एखादे उत्तर एक सीमा सोडून पुढील सीमेवर कधीच पोहोचले नाही का?

शक्य असल्यास क्लायंट आणि सर्व्हर दोन्हीकडे कॅप्चर करा. क्लायंटवर दिसणारा पण सर्व्हरवर न दिसणारा रीसेट सर्व्हरवर उद्भवलेला नाही.

दोन्ही दिशांमधील RST सेगमेंटकडे लक्ष द्या:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

नियंत्रित तुलनेने मर्यादित करा

दुसरे मंजूर नेटवर्क सांगू शकते की अयशस्वीता क्लायंटचा पाठलाग करते की मार्गाचा. तोच प्रोफाइल अन्यत्र चालत असेल, तर क्लायंट कॉन्फिगरेशन बहुधा ठीक आहे आणि चल म्हणजे मार्ग.

हे अजूनही एक विशिष्ट मध्यस्थ उपकरण ओळखत नाही. ते व्याप्ती एका मार्गापर्यंत मर्यादित करते, जो उपयुक्त आणि प्रामाणिक निकाल आहे.

“हा मार्ग अयशस्वी होतो” आणि “या नामांकित पक्षाने ते घडवले” यातील फरक टिकवा. पहिले तपासण्यायोग्य आहे; दुसरे सामान्यतः एका क्लायंटवरून नाही.

विश्वास सेटिंग्ज न बदलता दुरुस्ती तपासा

TLS पडताळणी बंद करू नका, क्रेडेन्शियल्स पुन्हा तयार करू नका आणि एका रीसेट ओळीवरून ब्लॉकिंग धोरण जाहीर करू नका. यातील प्रत्येक बदल चाचणीतील प्रणाली बदलतो आणि पुढील तुलना अर्थहीन करतो.

ओळखलेला घटक त्याच्या मालकामार्फत दुरुस्त करा, नंतर तोच प्रोफाइल आणि तेच निरीक्षण पुन्हा करा:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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