UDP लाई ISP ले ब्लक गर्छ, कि टनेलभित्रको एपले?

कसैले VPN „UDP ब्लक गर्छ“ भनी रिपोर्ट गर्छ, र यो वाक्यले दुई पूर्ण रूपमा फरक दाबी लुकाउँछ। एउटा पहुँच नेटवर्कले देख्न सक्ने ट्रान्सपोर्टको बारेमा हो, अर्को टनेलभित्र डिक्रिप्ट भएपछिको एपका प्याकेटको बारेमा। इन्क्रिप्ट गरिएको टनेल कुनै पनि कुञ्जी बिना बाहिरबाट फिल्टर गर्न सकिन्छ, र आन्तरिक UDP एप फिल्टरिङसँग कुनै सम्बन्ध नभएका कारणले असफल हुन सक्छ। प्रमाण जम्मा गर्नुअघि तपाईं कुन दाबी परीक्षण गर्दै हुनुहुन्छ निर्णय गर्नुहोस्।

दुई हेडर, एउटा शब्द

NAT-traversal सहितको IPsec तैनाथीमा बाह्य प्याकेट UDP हो, जुन दुई VPN इन्डपोइन्टबीच ठेगाना गरिएको हुन्छ, सामान्यतया पोर्ट 4500 मा। त्यसभित्र इन्क्रिप्ट गरिएको पेलोडले टनेलले पठाउने सबै कुरा बोक्छ, र त्यो आफैं TCP वा UDP हुन सक्छ। त्यसैले UDP शब्द दुई पटक आउँछ, फरक अर्थ र फरक दृश्यतासहित।

बीचको नेटवर्कले बाह्य हेडर देख्छ र आन्तरिकबाट केही देख्दैन। यसले बाह्य प्रवाहलाई अनुमति दिन, आकार दिन वा फाल्न सक्छ, र त्यसका लागि केही पनि डिक्रिप्ट गर्नु आवश्यक छैन। यही असमानता दुई दाबी गडबड हुनुको पूरा कारण हो: एउटै शब्दले नेटवर्कले फिल्टर गर्ने र एपले पठाउने दुवैलाई वर्णन गर्छ। निष्कर्ष लेख्दा शब्दको छेउमा तह लेख्नुहोस्, र अन्योल धेरै हदसम्म हराउँछ।

आन्तरिक हेडर प्राप्त गर्ने इन्डपोइन्टमा, डिक्रिप्शनपछि मात्र देखिन्छ। त्यस क्षणदेखि प्याकेट अरू जस्तै फर्वार्ड हुन्छ, मार्ग, नीति र इन्डपोइन्टको आफ्नै फिल्टरिङको अधीनमा। यी फरक उपकरणहरूले लिने अलग निर्णय हुन्।

नेटवर्कले अझै के देख्न सक्छ

इन्क्रिप्शनले पेलोड र आन्तरिक ट्रान्सपोर्ट हेडर लुकाउँछ, प्रवाह अस्तित्वमा छ भन्ने तथ्य होइन। इन्डपोइन्ट ठेगाना, पोर्ट, प्याकेटको आकार र समय देखिने नै रहन्छ, र ती ट्राफिकलाई अनुमानित रूपमा वर्गीकरण गर्न वा निश्चित गन्तव्य ब्लक गर्न पर्याप्त छन्।

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

पहिलो क्याप्चरले भौतिक इन्टरफेसमा बाह्य प्रवाह देखाउँछ, र दोस्रोले टनेल इन्टरफेसमा आन्तरिक प्रवाह देखाउँछ। दुवै एकैचोटि चलाउँदा प्रश्नको सिधा उत्तर मिल्छ: बाह्य प्रवाह छ र आन्तरिक छैन भने, एपले टनेलमा केही पनि पठाएको छैन। दुवै छन् र केही फर्किएन भने, समस्या टनेलभन्दा पर, गन्तव्यमा वा फर्कने बाटोमा छ।

RFC 3948 ले बाह्य UDP इन्क्याप्सुलेसन परिभाषित गर्छ, र ESP विशेषताले त्यसभित्रको संरक्षित लेआउट परिभाषित गर्छ। दुवैमध्ये कुनै कागजातले पहुँच नेटवर्कले बाह्य प्रवाह पार गराउने वाचा गर्दैन, त्यसैले आन्तरिकबारे कुनै पनि सिद्धान्तअघि बाह्य टपलमा पुग्ने क्षमताको परीक्षण गर्नु उपयुक्त हुन्छ। ब्लक गरिएको बाह्य टपलले कहिल्यै नबन्ने टनेल दिन्छ, बनेर पछि एउटा एप गुमाउने टनेल होइन।

किन काम गर्ने टनेलभित्र एउटा UDP एप असफल हुन्छ

वेब एप बोक्ने तर UDP एप नबोक्ने टनेलका धेरै विश्वसनीय व्याख्या छन्, र ISP द्वारा आन्तरिक प्रोटोकल फिल्टर गर्नु पहिलो होइन। सबैभन्दा सामान्य कभरेज हो: दुवै एप एउटै टनेलमा सँगै पस्दैनन्, किनभने UDP गन्तव्यको मार्ग छैन वा क्लाइन्टका विभाजित टनेल नियमले त्यसलाई बाहिर राख्छन्।

दोस्रो इन्डपोइन्ट हो। प्रोटोकल सूचीलाई अनुमति दिने VPN सर्भर, गन्तव्यको फायरवाल, वा अपेक्षित पोर्टमा कहिल्यै नसुन्ने सेवा — सबैले नेटवर्क ब्लक जस्तै देखिने समय समाप्ति उत्पन्न गर्नेछन्।

तेस्रो प्याकेटको आकार हो। UDP एपहरूले प्रायः वेब अनुरोधभन्दा ठूला डेटाग्राम पठाउँछन्, र इन्क्याप्सुलेसनले प्रयोगयोग्य MTU घटाउँछ, त्यसैले सफल ह्यान्डसेकपछि पहिलो पूर्ण आकारको पेलोडमा मौनता आउन सक्छ। यो ढाँचालाई ब्लक भनेर गलत पढ्न सजिलो छ, किनभने साना प्याकेट जान्छन् र ठूला हराउँछन्। छिटो MTU जाँचले एक मिनेटभन्दा कममा यो टुंग्याउँछ, र उत्तर सामान्यतया नेटवर्क फिल्टर होइन, सानो पेलोड वा सुधारिएको MSS हुन्छ।

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

पहिलो आदेशले ठूलो प्याकेटले फ्र्याग्मेन्टेसन बन्द अवस्थामा बाटो पार गर्छ कि भनी जाँच्छ, जसले MTU समस्या छिटो खोल्छ। दोस्रोले सानो, सीमित UDP प्रवाह पठाउँछ र हानि तथा जिटरको रिपोर्ट दिन्छ। सुरु भएर पछि रोकिने प्रवाहले ब्लकतिर होइन, आकारतिर संकेत गर्छ।

प्रोटोकल होइन, तह रिपोर्ट गर्नुहोस्

निष्कर्ष तीनमध्ये एक स्वरूपमा लेख्नुहोस्: बाह्य डेलिभरी असफल, आन्तरिक फर्वार्डिङ असफल, वा एप असफल। प्रत्येकको मालिक फरक छ, र तिनीहरू मिसाउँदा टिकट गलत टोलीकहाँ जान्छ।

स्थानीय पोर्ट बदल्नाले टाढाको छेउमा मिल्ने श्रोता बनाउन सक्दैन, त्यसैले मद्दत गरेजस्तो देखिने क्लाइन्ट-पक्षीय उपाय सामान्यतया मूल गन्तव्य गलत थियो भन्ने प्रमाण हो। त्यसैगरी, दिइएको वैकल्पिक प्रोफाइलले पहुँचबारे केही प्रमाणित गर्छ र एप ठीकसँग कन्फिगर भएको छ कि छैन भन्नेबारे केही पनि होइन।

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