UDP ISP ब्लॉक करतो की टनेलमधील ॲप?
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 प्रवाह पाठवतो आणि हानी व जिटरचा अहवाल देतो. सुरू होऊन नंतर थांबणारा प्रवाह ब्लॉककडे नाही, आकाराकडे निर्देश करतो.
प्रोटोकॉल नाही, स्तर सांगा
निष्कर्ष तीनपैकी एका स्वरूपात लिहा: बाह्य वितरण अयशस्वी, आंतरिक फॉरवर्डिंग अयशस्वी, किंवा ॲप अयशस्वी. प्रत्येकाचा मालक वेगळा आहे, आणि ते मिसळल्यास तिकीट चुकीच्या संघाकडे जाते.
स्थानिक पोर्ट बदलल्याने दूरच्या टोकाला जुळणारा श्रोता तयार होऊ शकत नाही, त्यामुळे मदत करत असल्यासारखे वाटणारे क्लायंट-बाजूचे उपाय सामान्यतः मूळ गंतव्य चुकीचे होते याचा पुरावा असतात. त्याचप्रमाणे, दिलेले पर्यायी प्रोफाइल पोहोचीबद्दल काहीतरी सिद्ध करते आणि ॲप योग्यरित्या संरचित आहे का याबद्दल काहीही नाही.
अनुमान वेगळे आणि निरीक्षण वेगळे ठेवा. ट्रॅफिक विश्लेषण डिक्रिप्ट न करता प्रवाह काय आहे हे सुचवू शकते, आणि तो उपयुक्त निष्कर्ष आहे, पण तो आंतरिक हेडर वाचण्याचा तोच दावा नाही. तुमच्याकडे प्रत्यक्षात कोणते आहे ते सांगा.