VPN-এর মধ্য দিয়ে নির্দিষ্ট 1,500 বাইটের ভিতরের প্যাকেট বহন

আপনার একটি দাবি আছে যা নমনীয় নয়: দূরবর্তী পক্ষকে অবশ্যই প্রেরকের পাঠানো একই 1,500 বাইটের IP প্যাকেটটি হেডারসহ গ্রহণ করতে হবে। একটি টানেল সেই প্যাকেট ও তার নিজস্ব ফ্রেমিং একটি দ্বিতীয় 1,500 বাইটের IP প্যাকেটের ভিতরে মুড়ে দিতে পারে না, তাই ডিজাইনে কিছু একটা ছাড় দিতে হবে। নিচের ক্রমটিই আমি পরিবর্তন উইন্ডোতে ব্যবহার করি: বাইট বাজেট লিখুন, আন্ডারলে আসলে কী বহন করতে পারে তা প্রমাণ করুন, তারপর ঠিক একটি বহন পদ্ধতি বেছে নিন এবং দূরবর্তী প্রান্তে ভিতরের প্যাকেট নিশ্চিত করুন।

প্রোফাইল সম্পাদনার আগে বাইট বাজেট লিখুন

এনক্যাপসুলেশন কয়েকটি স্তরে বাইট যোগ করে, আর মোটটি আপনার প্রোফাইলের একটি বৈশিষ্ট্য, এমন কোনো ধ্রুবক নয় যা আপনি খুঁজে বের করতে পারেন। অ্যাড্রেস ফ্যামিলি, সাইফার নির্বাচন, ট্রান্সপোর্ট প্রোটোকল এবং যেকোনো কম্প্রেশন বা ফ্রেমিং অপশন এই সংখ্যাটি বদলায়, তাই অন্য কোনো ডিপ্লয়মেন্ট থেকে কপি করা বিয়োগফল বাজেট হিসেবে মূল্যহীন। ভিতরের দাবি থেকে শুরু করুন, আপনার নিজের কনফিগারেশনের পরিমাপ করা প্রতি-প্যাকেট ওভারহেড যোগ করুন, এবং কেউ ফাইল সম্পাদনা করার আগেই ফলাফল পাওয়া বাইরের আকার পরিবর্তন টিকিটে লিখুন।

দুটি সংখ্যা ডিজাইন নির্ধারণ করে: পথটি ফ্র্যাগমেন্টেশন ছাড়া বহন করে এমন বৃহত্তম বাইরের প্যাকেট, এবং আপনার এনক্যাপসুলেশনের প্রয়োজনীয় অতিরিক্ত বাইট। যখন প্রথমটি দ্বিতীয়টি যোগ 1,500-এর চেয়ে ছোট, তখন তাদের একটিকে বদলাতে হবে। তখন পছন্দটি সৃজনশীল নয়, সংকীর্ণ, তাই বিকল্প নিয়ে আলোচনার আগেই আমি দুটি সংখ্যাই লিখে রাখি। টানেল স্তরে কিছুই সেই বাইটগুলো কম্প্রেস করে সরায় না, এবং কোনো একক MTU পূর্ণসংখ্যা আপনার দেওয়া দাবিটি সরায় না।

ডু-নট-ফ্র্যাগমেন্ট পিং দিয়ে আন্ডারলে যাচাই করুন

ইন্টারফেস MTU-তে ভরসা না করে পথটি পরিমাপ করুন, কারণ বাইরের পথের সবচেয়ে ছোট লিঙ্কটিই গুরুত্বপূর্ণ। Linux-এ -M do ডু-নট-ফ্র্যাগমেন্ট বিট সেট করে এবং -s ICMP পেলোড নেয়, তাই 1,500 বাইটের ফ্রেম 20 বাইটের IP হেডার ও 8 বাইটের ICMP হেডার বাদ দেওয়ার পর 1,472 বাইট পেলোডে উত্তর দেয়। পেলোড ধাপে ধাপে বাড়ান যতক্ষণ না যাচাই ব্যর্থ হয়, তারপর জাম্বো আকারে লাফ দিন দেখতে পথটি আদৌ এটি বহন করে কি না।

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

যে পথ 1,472 পাস করে এবং 8,972-তে ব্যর্থ হয়, সেটি 1,500 বাইটের ভিতরের প্যাকেট ও ওভারহেড একটি বাইরের প্যাকেটে বহন করতে পারে না। VPN কনফিগারেশন খোলার আগে আপনার এই উত্তরটিই দরকার ছিল। এটি আরও ঠিক করে পরের দুটি বিভাগের কোনটি আপনার জন্য প্রযোজ্য, তাই দুটি যাচাইয়ের ফলাফল টিকিটের পাশে রাখুন। এখানে অনুমান করলে একটি মেইনটেনেন্স উইন্ডো নষ্ট হয়, কারণ যে টানেল নিজেকে আপ বলে জানায়, সেটি পথটি কোন বৃহত্তম প্যাকেট গ্রহণ করবে সে সম্পর্কে কিছুই বলে না।

পথের MTU বাড়ান কেবল যেখানে প্রতিটি হপ সম্মত

জাম্বো ফ্রেম একটি এন্ড-টু-এন্ড বৈশিষ্ট্য, আপনার নিয়ন্ত্রণে থাকা দুটি এন্ডপয়েন্টে চালু করার কোনো সেটিং নয়। বাইরের পথের প্রতিটি সুইচ, রাউটার ও প্রোভাইডার হ্যান্ডঅফকে বড় আকারে একমত হতে হবে, এবং একটি মাত্র 1,500 বাইটের হপ আপনি সদ্য বড় করা প্যাকেটটি নিঃশব্দে ফেলে দেবে। শুধু স্থানীয় ইন্টারফেস বাড়ানো হলো সেই চেনা অর্ধেক পরিবর্তন, যাতে টানেল ভাঙা দেখায় আর আন্ডারলে চুপচাপ ফেলে দেয়।

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

ইন্টারফেস বদলান, তারপর অন্য কিছু বদলানোর আগে একই পথ আবার যাচাই করুন। যদি যাচাই এখনও ব্যর্থ হয়, ip link set dev eth1 mtu 1500 দিয়ে ফিরিয়ে নিন এবং আপনার মালিকানার বাইরের একটি লিঙ্ক নিয়ে প্রোভাইডারের সঙ্গে তর্ক না করে ফ্র্যাগমেন্টেশনে যান।

আন্ডারলে বাড়তে না পারলে টানেল ফ্র্যাগমেন্টেশন ব্যবহার করুন

ভিতরের প্যাকেটের নিচে একটি সমর্থিত ফ্র্যাগমেন্টেশন পদ্ধতি কয়েকটি বাইরের প্যাকেটকে একটি ভিতরের প্যাকেট বহন করতে দেয়, এবং দূরবর্তী টানেল প্রান্তটি মূল প্যাকেটটি স্ট্যাকের উপরে দেওয়ার আগে সেগুলো আবার জোড়া লাগায়। Community OpenVPN-এর UDP ফ্র্যাগমেন্ট অপশন সেই ধারণার একটি বাস্তবায়ন, এবং এটি বাইরের প্যাকেটের সাধারণ IP ফ্র্যাগমেন্টেশনের মতো একই জিনিস নয়। দুই পক্ষকেই ফরম্যাট সমর্থন করে এমন সংস্করণ চালাতে হবে, এবং ডেটা পথটি অবশ্যই আপনার ভাবা পথটিই হতে হবে: OpenVPN 3 ক্লায়েন্ট ও কার্নেল-ত্বরিত ডেটা চ্যানেলের সীমা ভিন্ন, তাই এক ক্লায়েন্টে কাজ করা প্রোফাইল অন্য ক্লায়েন্টে ব্যর্থ হতে পারে।

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

সাধারণ বাইরের ফ্র্যাগমেন্টেশন হলো অন্য বিকল্প, এবং এটি দুর্বলতর। IPv6 রাউটার ফরওয়ার্ড করা প্যাকেট আদৌ ফ্র্যাগমেন্ট করে না, তাই অতিরিক্ত বড় বাইরের প্যাকেট কেবল মরে যায় এবং প্রেরক তা জানতে পারে কেবল যদি সংশ্লিষ্ট ICMPv6 বার্তাটি পথ পেরোয়। ফ্র্যাগমেন্ট ফিল্টারিং ও লস অ্যামপ্লিফিকেশনকেও আমন্ত্রণ জানায়, তাই আমি এটিকে পরিকল্পনা নয়, ফলব্যাক হিসেবে দেখি।

স্ট্রিম-ভিত্তিক বাইরের ক্যারিয়ার নিজের বাইট স্ট্রিম ভাগ করে আকারের প্রশ্নটি এড়িয়ে যায়, এবং পুনর্গঠিত ভিতরের প্যাকেট এখনও 1,500 বাইট হতে পারে। এটি নিজস্ব খরচসহ একটি ট্রান্সপোর্ট সিদ্ধান্ত, যার মধ্যে TCP-এর ভিতরে TCP-এর সুপরিচিত আচরণও আছে, তাই এটি MTU তর্কের পার্শ্বপ্রতিক্রিয়া নয়, সচেতনভাবে নিন।

ভিতরের প্যাকেট অপরিবর্তিত পৌঁছায় কি না নিশ্চিত করুন

যাচাই মানে সফল হ্যান্ডশেক নয়। দুই প্রান্তে টানেল ইন্টারফেসে ক্যাপচার করুন এবং অ্যাপ্লিকেশনটি আসলে যে প্যাকেট পাঠিয়েছে তার আকার ও বিষয়বস্তু দূরবর্তী পক্ষ যে পেয়েছে তার সঙ্গে তুলনা করুন।

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

যদি ক্যাপচারে দূরবর্তী প্রান্তে পূর্ণ আকারের ভিতরের প্যাকেট দেখা যায়, তবে বহন পছন্দটি কাজ করে এবং বাকি কাজ হলো তা লিখে রাখা। যদি টানেল নিজেকে আপ বলে জানানোর সময়েও কিছু না দেখা যায়, তবে বাইরের প্যাকেট এন্ডপয়েন্টগুলোর মাঝে কোথাও ফেলে দেওয়া হচ্ছে, যা আপনাকে সাইফার সেটিংসে নয়, যাচাইয়ের দিকেই ফিরিয়ে নেয়।

টিকিট বন্ধ করার আগে তিনটি জিনিস লিখুন: পরিমাপ করা বাইরের বাজেট, আপনি যে পদ্ধতি বেছেছেন, এবং যে কমান্ড প্রমাণ করেছে ভিতরের প্যাকেট টিকে গেছে। এই টানেলে পরের যে হাত দেবে তার তিনটিই লাগবে, এবং একটিও শুধু কনফিগারেশন ফাইল থেকে পুনর্গঠন করা যায় না।