কেন VPN বড় ট্রান্সফারে আটকে যায়, ছোটটিতে নয়
ছোট অনুরোধের উত্তর আসে, অথচ বড় ট্রান্সফার জমে যায়। নির্দিষ্ট MTU কপি করার আগে ইন্টারফেস সীমা, পথের সীমা ও ঘোষিত TCP পেলোড তুলনা করুন।
একটি পৃষ্ঠা লোড হয়, একটি ping সফল হয়, আর একটি ফাইল কপি প্রতিবার একই জায়গায় আটকে যায়। এই ধরনটি ব্যান্ডউইথ বা শংসাপত্রের বদলে প্যাকেটের আকারের দিকে ইঙ্গিত করে। এনক্যাপসুলেশন প্রতিটি প্যাকেটে বাইট যোগ করে, তাই যে পেলোড মূল পথে ফিট করত, টানেলের ভেতর দিয়ে যাওয়ার পর তা সীমা ছাড়িয়ে যেতে পারে। এই আলোচনায় তিনটি ভিন্ন সংখ্যাকে MTU বলা হয়, আর তাদের গুলিয়ে ফেললে এমন সেটিং দাঁড়ায় যা একটি অ্যাপ ঠিক করে অন্যটি ভেঙে দেয়।
মানুষ যেগুলোকে MTU বলে, সেই তিনটি সংখ্যা
ইন্টারফেস MTU হলো ওই লিংকে একটি প্যাকেটের জন্য কনফিগার করা সীমা। পথ MTU হলো রুট বরাবর সবচেয়ে ছোট সীমা, যা কনফিগার করা হয় না, আবিষ্কার করা হয়। TCP MSS হলো সেই পেলোডের আকার যা প্রতিপক্ষ জানায় সে গ্রহণ করতে পারে, এবং এটি অন্য দুটি থেকে উদ্ভূত, আলাদা কোনো ভৌত সীমা নয়।
একটি টানেলের ভেতরের ও বাইরের দুই রূপ থাকে। বাইরের প্যাকেটটি এনক্যাপসুল করা প্যাকেট এবং প্রোটোকলের প্রয়োজনে যেসব হেডার লাগে তা বহন করে, তাই ব্যবহারযোগ্য ভেতরের আকার বাইরের পথ যতটা অনুমোদন করে তার চেয়ে ছোট। VPN সার্ভারের পথটিও সার্ভার থেকে গন্তব্যে যাওয়ার পথ থেকে আলাদা।
পথ MTU আবিষ্কার সেন্ডারকে কার্যকর আকার জানতে দেয়, কিন্তু তা নির্ভর করে ফিডব্যাক পৌঁছানোর উপর। যখন একটি মধ্যবর্তী ডিভাইস প্রাসঙ্গিক ICMP বার্তাগুলো ফিল্টার করে, সেন্ডার এমন প্যাকেট পাঠাতে থাকে যা কখনো সম্পূর্ণ হয় না, আর এটাই চিরাচরিত ব্ল্যাক হোল। লক্ষণটি জানলে স্বতন্ত্র: হ্যান্ডশেক সফল হয়, প্রথম পূর্ণ আকারের পেলোড উধাও হয়, এবং সংযোগ শেষে রিসেট হয় বা আটকে যায়। অ্যাপ্লিকেশন লগে কিছুই নেটওয়ার্ক সমস্যার মতো দেখায় না।
নিজের নিয়ন্ত্রণে থাকা পেলোড দিয়ে পথ পরীক্ষা করুন
একটি প্রোব একটি রুট ও একটি আকার সম্পর্কে প্রমাণ, সুপারিশকৃত সেটিং নয়। এমন হোস্ট ব্যবহার করুন যা উত্তর দেয়, এবং কেবল পেলোডের আকার বদলান।
ping -M do -s 1372 -c 2 203.0.113.20 ping -4 -f -l 1372 vpn.example
প্রথম কমান্ডটি ফ্র্যাগমেন্টেশন বন্ধ রেখে 1372 বাইট পেলোড দিয়ে একটি লিনাক্স প্রোব পাঠায়, আর দ্বিতীয়টি উইন্ডোজে একই কাজ করে যেখানে পেলোড -l দিয়ে সেট করা হয়। উত্তর মানে ওই আকার পথ পেরিয়েছে। ফ্র্যাগমেন্টেশন প্রয়োজন এমন বার্তা তথ্যবহুল, অন্যদিকে টাইমআউট দ্ব্যর্থক কারণ হোস্ট বা মধ্যবর্তী ডিভাইস শুধু ICMP ফেলে দিতে পারে।
বাইট পর্যন্ত বাইনারি সার্চ না করে কয়েক ধাপে আকার নামিয়ে আনুন। আপনি বোঝার চেষ্টা করছেন আকারের কোনো ছাদ আছে কি না, প্রতিটি নেটওয়ার্কের জন্য সংখ্যা প্রকাশ করা নয়। আপনি যে সংখ্যা পাবেন তা এই পথ, এই প্রোটোকল ও এই ঠিকানা পরিবারের জন্য প্রযোজ্য।
IPv4 ও IPv6 ভিন্নভাবে ফ্র্যাগমেন্ট হয়, তাই এক পরিবারের প্রোব ফলাফল অন্য সম্পর্কে কিছুই বলে না। অ্যাপ্লিকেশনটি যে পরিবার সত্যিই ব্যবহার করে সেটিই পরীক্ষা করুন।
MSS ক্ল্যাম্পিং কেবল TCP-তে সাহায্য করে
TCP-তে কার্যকর পেলোড হ্যান্ডশেকের সময় নির্ধারিত হয়, এবং পথের একটি রাউটার সেই মান নিচের দিকে লিখে দিতে পারে যাতে দুই প্রান্তই ছোট সেগমেন্ট পাঠায়। MSS ক্ল্যাম্পিং ঠিক এটাই করে, এবং এটি ক্লায়েন্টকে একেবারেই না ছুঁয়ে কাজ করে।
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu ip link show tun0
প্রথম নিয়মটি ফরোয়ার্ড করা TCP হ্যান্ডশেকের জন্য ঘোষিত MSS-কে পথ MTU-তে ক্ল্যাম্প করে, আর দ্বিতীয়টি টানেল ইন্টারফেসের নিজের MTU দেখায় যাতে আপনি তা পথের অনুমোদনের সঙ্গে তুলনা করতে পারেন। হ্যান্ডশেকের পর থেমে যাওয়া TCP অ্যাপ্লিকেশনের জন্য ক্ল্যাম্পিং সবচেয়ে কম আক্রমণাত্মক সমাধান।
UDP-তে এটি কিছুই করে না। বড় ডেটাগ্রাম পাঠানো ভয়েস বা গেম ক্লায়েন্ট MSS সেটিং সম্পূর্ণ উপেক্ষা করবে, কারণ সেখানে পুনর্লিখনের মতো কোনো হ্যান্ডশেক নেই। ব্যর্থ অ্যাপ্লিকেশনটি UDP হলে এর বদলে ক্লায়েন্টের নিজের প্যাকেট আকারের অপশনগুলো দেখুন। দুটি প্রোটোকল ভিন্নভাবে ব্যর্থ হয় ও ভিন্ন যন্ত্রে সারানো হয়, তাই টিকিটের প্রথম বাক্যেই প্রোটোকলটি থাকা উচিত।
OpenVPN tun-mtu, mssfix ও ফ্র্যাগমেন্ট-সংশ্লিষ্ট সেটিংস দেয়, আর তাদের আচরণ নির্ভর করে সংস্করণ এবং ডেটা চ্যানেল AEAD কি না তার উপর। ব্যবহৃত সংস্করণের ম্যানুয়াল পড়ুন, এবং একবারে একটি অপশন বদলান।
একটি সমর্থিত সেটিং বদলে দুই চালনাই আবার করুন
মূল প্রোফাইলটি রেখে দিন, একটি সমর্থিত মান বদলান, এবং যে ছোট অনুরোধটি কাজ করেছিল ও যে বড় ট্রান্সফারটি ব্যর্থ হয়েছিল দুটোই আবার চালান। কেবল বড়টি বদলালে আপনি আকারের পিছনে ছুটছিলেন। দুটোই বদলালে এর সঙ্গে অন্য কিছু সরেছে।
কম মান উপসর্গ কমাতে পারে তবে বাড়তি ওভারহেড যোগ করে, তাই সম্ভাব্য সবচেয়ে ছোট সংখ্যাটি লক্ষ্য নয়। লক্ষ্য হলো এমন আকার যা পথটি সবচেয়ে কম অপচয়ে নির্ভরযোগ্যভাবে বহন করে। মান, পথ ও ক্লায়েন্ট সংস্করণ টিকিটে লিখুন, কারণ একই সংখ্যা অন্য জায়গায় প্রয়োগ করা একটি অনুমান।
একই প্রোফাইল অন্য বিশ্বস্ত নেটওয়ার্ক থেকে কাজ করলে ক্লায়েন্ট ঠিক হয়েছে ঘোষণা না করে সেই পার্থক্যটি রোগনির্ণয়ে রাখুন। যে চলকটি বদলেছে তা হলো পথ, এবং প্রোব যা মেপেছে তা-ই পথ।