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

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