ISP কি UDP ব্লক করছে, নাকি টানেলের ভেতরের অ্যাপ?
একটি 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 স্ট্রিম পাঠায় এবং লস ও জিটার রিপোর্ট করে। যে স্ট্রিম শুরু হয়ে পরে থেমে যায়, তা ব্লকের দিকে নয়, আকারের দিকে ইঙ্গিত করে।
প্রোটোকল নয়, স্তর জানান
ফলাফলটি তিনটি রূপের একটিতে লিখুন: বাইরের ডেলিভারি ব্যর্থ, ভেতরের ফরওয়ার্ডিং ব্যর্থ, বা অ্যাপ্লিকেশন ব্যর্থ। প্রত্যেকের মালিক আলাদা, আর সেগুলো মিশিয়ে দিলে টিকিট ভুল দলে চলে যায়।
স্থানীয় পোর্ট বদলে দূর প্রান্তে মিলে যাওয়া লিসেনার তৈরি করা যায় না, তাই ক্লায়েন্ট-পাশের যে সমাধান সাহায্য করছে বলে মনে হয়, তা সাধারণত প্রমাণ করে মূল গন্তব্যটি ভুল ছিল। একইভাবে, সরবরাহ করা বিকল্প প্রোফাইল পৌঁছানোর বিষয়ে কিছু প্রমাণ করে, অ্যাপ্লিকেশন সঠিকভাবে কনফিগার করা আছে কি না তা নিয়ে কিছুই নয়।
অনুমানকে পর্যবেক্ষণ থেকে আলাদা রাখুন। ট্রাফিক বিশ্লেষণ ডিক্রিপ্ট না করেই একটি ফ্লো কী তা ইঙ্গিত দিতে পারে, আর এটি উপকারী ফলাফল, কিন্তু এটি ভেতরের হেডার পড়ার সমান দাবি নয়। আপনার কাছে আসলে কোনটি আছে তা উল্লেখ করুন।