IPsec ওভারহেড: মোড, NAT-T আর অ্যালগরিদম সবই তা বদলে দেয়
প্রকাশিত একটি ওভারহেড সংখ্যা এক পথে এক এনক্যাপসুলেশন বর্ণনা করে। আপনার টানেল আসলে কোন হেডারগুলো নিয়ে সমঝোতা করে তা যোগ করুন, তারপর পথটি মাপুন।
কোনো গাইডের কোথাও একটা সংখ্যা থাকে, সাধারণত ষাট থেকে আশি বাইটের মধ্যে, যা কেউ 1500 থেকে বিয়োগ করে ইন্টারফেস MTU পেয়েছে। সেই সংখ্যাটি এক নির্দিষ্ট পথে এক নির্দিষ্ট এনক্যাপসুলেশন বর্ণনা করে। মোড, বাইরের ঠিকানা পরিবার, সাইফার বা NAT-এর উপস্থিতি বদলালে হিসাবটা আর আপনার টানেলে খাটে না।
সংখ্যাটা এসেছে অন্য এক টানেল থেকে
ওভারহেড কোনো বিমূর্ত অর্থে IPsec-এর ধর্ম নয়। এটি সেই প্যাকেটের ধর্ম যা সত্যিই তৈরি হয়: সমঝোতায় ঠিক করা মোড, বাইরের হেডার, সুরক্ষা হেডার, প্যাডিং, অখণ্ডতার ফিল্ড এবং সম্ভবত অতিরিক্ত একটি UDP মোড়ক।
IPv4 আর NAT ছাড়া ট্রান্সপোর্ট মোডের জন্য উদ্ধৃত সংখ্যাটি NAT ট্রাভার্সালের অধীনে IPv6-সহ টানেল মোডের চেয়ে ছোট প্যাকেট বর্ণনা করে। দুটোই নিজ নিজ ক্ষেত্রে ঠিক। তার মধ্যে একটি অন্য স্থাপনায় কপি করলেই মানুষ এমন MTU পায় যা বড় ট্রান্সফার ভেঙে দেয়। ব্যর্থতাটা নীরব, কারণ ছোট অনুরোধ চলতেই থাকে।
যে স্তরগুলো সত্যিই আছে সেগুলো যোগ করুন
বাইরের IP হেডার থেকে শুরু করে ভেতরের দিকে এগোন। টানেল মোডে মূল প্যাকেট ভেতরে থাকে, তাই বাইরের হেডারটি প্রতিস্থাপন নয়, সংযোজন। RFC 4303 ESP হেডার, প্যাডিং এবং তার পরের অখণ্ডতা ডেটা বর্ণনা করে।
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
ওই সারিগুলোর কোনোটিই বিভিন্ন স্থাপনায় ধ্রুবক নয়, আর প্যাডিং সারিটি একই স্থাপনার ভেতরেও ধ্রুবক নয়। প্রকাশিত একটি একক ওভারহেড সংখ্যা হতাশ করে বলেই এটা।
একই টানেল নিয়ে দুটি সাইট দ্বিমত করতে পারে
সুরক্ষিত প্যাকেটটিকে এখনও বাইরের পথ পার হতে হয়, আর বাইরের পথ সব জায়গায় এক নয়। PPPoE অ্যাক্সেস লিংক পরিষ্কার Ethernet সেগমেন্টের চেয়ে কম বইতে পারে। মোবাইল নেটওয়ার্ক আরও সংকুচিত হতে পারে, আর নিজের ট্রাফিক টানেল করা প্রদানকারী আরেকটি এনক্যাপসুলেশন যোগ করে যা কেউ বলেনি। যে টানেল এক লিংকে কাজ করে আর অন্য লিংকে ব্যর্থ হয়, সে দ্বিতীয় লিংকের কথা বলছে, প্রোটোকলের নয়।
দুই দিকও আলাদা হতে পারে। অসমমিত রুট আপনাকে কাজ করা আপলোড আর থেমে যাওয়া ডাউনলোড দিতে পারে, যা প্যাকেটের আকার না দেখে প্রাপ্যতা দেখলে অ্যাপ্লিকেশনের সমস্যা মনে হয়। ছোট ping সফল হওয়া পূর্ণ আকারের উত্তরের বিষয়ে খুব কম প্রমাণ দেয়।
বিয়োগ না করে মাপুন
পথ পেরিয়ে টিকে থাকা সবচেয়ে বড় ডেটাগ্রাম খুঁজুন। তারপর ইন্টারফেস যে মান জানায় তার সঙ্গে মেলান:
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
উত্তর আসা পর্যন্ত ping-এর আকার কমাতে থাকুন, আর সবচেয়ে বড় কাজ করা মানটিকে ওই পথের বাজেট ধরে নিন। xfrm-এর আউটপুট বলে কোন মোড আর কোন অ্যালগরিদম সমঝোতা হয়েছে, আর যে কোনো সৎ হিসাবের ইনপুট সেটাই। ক্যাপচার নিশ্চিত করে তারে ESP আছে নাকি UDP-মোড়কানো ESP, আর এতেই NAT-এর প্রশ্নটা অনুমান ছাড়া মিটে যায়।
কন্ট্রোল প্লেনের জন্যও একটা মান আলাদা রাখুন। IKE হ্যান্ডশেক প্যাকেটের গঠন ডেটা প্যাকেটের চেয়ে আলাদা, তাই হ্যান্ডশেক ক্যাপচার থেকে পাওয়া আকার ডেটা প্লেনের MTU নয়।
সংখ্যাটাকে তার জায়গায় রাখুন
টানেলের ভেতর দিয়ে TCP-এর ক্ষেত্রে MSS ক্ল্যাম্প প্রায়ই সবচেয়ে কম হস্তক্ষেপকারী নিয়ন্ত্রণ, কারণ এটি টানেল নিজে না বদলে প্রান্তগুলো যা পাঠায় তা কমায়। রুট-ভিত্তিক টানেলের জন্য টানেল ইন্টারফেসের MTU সচেতনভাবে ঠিক করুন আর কেন তা লিখে রাখুন। দুটো একসঙ্গে করে তারপর মাপলে কোনটি সাহায্য করেছে সে সম্পর্কে কোনো তথ্য পাবেন না।
টিকিটে সমঝোতাকৃত মোড, বাইরের পরিবার, NAT অবস্থা আর পুনরুৎপাদনযোগ্য উপসর্গ একসঙ্গে রাখুন। লিখে রাখা চারটি তথ্যের সেট মনে রাখা ধ্রুবকের চেয়ে ভালো, আর পরের ক্লায়েন্ট আপগ্রেড পর্যন্ত টিকে থাকা এটিই একমাত্র সংস্করণ।