क्या ISP UDP को ब्लॉक करता है, या टनल के अंदर का ऐप?

कोई बताता है कि 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 प्रवाह भेजता है और हानि तथा जिटर की रिपोर्ट करता है। जो प्रवाह शुरू होकर फिर रुक जाता है, वह ब्लॉक की ओर नहीं, आकार की ओर संकेत करता है।

प्रोटोकॉल नहीं, परत बताएँ

निष्कर्ष को तीन रूपों में से एक में लिखें: बाहरी डिलीवरी विफल, आंतरिक फ़ॉरवर्डिंग विफल, या ऐप विफल। हर एक का अलग स्वामी है, और उन्हें मिलाने से टिकट गलत टीम के पास चला जाता है।

स्थानीय पोर्ट बदलने से दूर के छोर पर मेल खाता श्रोता नहीं बन सकता, इसलिए क्लाइंट-पक्ष का वह उपाय जो मदद करता दिखता है, आमतौर पर साक्ष्य है कि मूल गंतव्य गलत था। उसी तरह, दिया गया वैकल्पिक प्रोफ़ाइल पहुँच के बारे में कुछ सिद्ध करता है और इस बारे में कुछ नहीं कि ऐप ठीक से कॉन्फ़िगर है या नहीं।

अनुमान को अवलोकन से अलग रखें। ट्रैफ़िक विश्लेषण डिक्रिप्ट किए बिना बता सकता है कि प्रवाह क्या है, और यह उपयोगी निष्कर्ष है, पर यह आंतरिक हेडर पढ़ने का वही दावा नहीं है। स्पष्ट करें कि आपके पास वास्तव में कौन-सा है।