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

उपयोगी परिणाम बेहतर ढंग से स्थानीयकृत विफलता है, अधिक आत्मविश्वासी कहानी नहीं। यदि प्रॉक्सी सुधार के बाद रीसेट गायब हो जाता है, तो आपके पास कारण है। यदि यह किसी दूसरे चरण में चला जाता है, तो आपने पथ के बारे में कुछ सीखा। किसी भी स्थिति में, सबूत को दूसरे व्यक्ति के पढ़ने तक टिकना चाहिए। जो आपने देखा वह लिखें, जो आपने निष्कर्ष निकाला वह नहीं।