WireGuard-এর ভিতরে IPIP: বাড়তি 20 বাইট যা কেউ বাজেটে ধরেনি
IPIP WireGuard-এর ভিতরে আরও 20 বাইট খরচ করে। জীবন্ত টানেলে আটকে যাওয়া স্থানান্তরকে ফ্র্যাগমেন্টেশনকে দোষ দেওয়ার আগে সঠিক স্তরে বাজেটটি করুন।
ছোট ping সারা দিন টানেল পার হয়, SSH ব্যানার এসে পৌঁছায়, আর ঠিক যখন ফাইল স্থানান্তর শুরু হয় তখনই সেশন জমে যায়। এই ধরনটি ভুল স্তরে গোনা বাইট-বাজেটের দিকে ইশারা করে, যেখানে বাইরের টানেল তার নিজের ওভারহেডের জন্য মাপা হয়েছিল আর ভিতরেরটি কেউ বিয়োগ করেনি। WireGuard-এর কাছে নেস্টেড IPIP প্যাকেট কেবল আরেকটি IP প্যাকেট, ঠিক এ কারণেই এটি আপনার কখনো সংরক্ষিত না করা বাইট খরচ করে। সংশোধনটি পাটিগণিত, এবং তা তিনটি কমান্ড আর একটি টেবিলে ধরে যায়।
যে লক্ষণটি এটি ধরা দেয়
ফ্র্যাগমেন্টেশনের সমস্যা নিজেকে আকার দিয়েই জানায়, কখনো ঠিকানা দিয়ে নয়। আপনার পিয়ার এক ঘণ্টা ধরে 56 বাইটের ping-এর উত্তর দেয়, তারপর 1400 বাইটে চুপ হয়ে যায়, অথচ টানেল সক্রিয় থাকে আর কোনো রুট বদলায় না। হ্যান্ডশেক ধরে, প্রথম পূর্ণ TCP উইন্ডো ধরে না, এবং সুস্থ দেখানোর কয়েক সেকেন্ড পরেই স্থানান্তর আটকে যায়।
কিছু সম্পাদনা করার আগে সিলিংটি মাপুন, কারণ অমাপা সিলিং হলো সেইটি যা আপনাকে দুবার তাড়া করতে হবে। সন্দেহভাজন আকারের নিচে do-not-fragment বিট সেট করে একটি প্রোব পাঠান, ping -M do -s 1000 10.9.0.2, তারপর এমন আকারে পুনরাবৃত্তি করুন যা আপনি আগেই জানেন খুব বড়। যখন উল্টোটা পেলোডের আকার অনুসরণ করে অথচ গন্তব্য অপরিবর্তিত থাকে, তখন রাউটিং তার কাজ করছে আর বাজেটে একটি হেডার অনুপস্থিত।
প্রতিটি হেডার একবারই গুনুন, সঠিক স্তরে
টানেল ইন্টারফেস থেকে নয়, পথের সবচেয়ে ছোট MTU থেকে শুরু করুন, কারণ দেয়ালটি দুই প্রান্তেরই উজানে বসে। WireGuard একটি IPv4 বাইরের পরিবহনে 60 বাইট খরচ করে: 20 IP-র জন্য, 8 UDP-র জন্য আর 32 নিজের হেডারের জন্য, আর ওই পরিবহন IPv6 হলে 80 বাইট। 1420 বাইটের wg0 1440-এর নিচে 20 বাইটের হেলার রাখে, যা 1500 বাইটের পথ সত্যিই পৌঁছাতে পারে, তাই উইকি থেকে কপি করা সংখ্যাটি এখানেও খাপ খায়। পুরো স্ট্যাকটি ডায়াগ্রামে লিখে রাখুন, কারণ পরেরবার যে MTU বদলাবে সে নাহলে নতুন এক গোল সংখ্যা বেছে নেবে আর আপনার বাগ উত্তরাধিকারে পাবে।
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
পঞ্চম সারিতেই বাজেট ভুল হয়, কারণ একটি নেস্টেড ইন্টারফেস যে 1400 বাইট বহন করে তা ইতিমধ্যে মূল প্যাকেটের নিজের 40 বাইট হেডার ধারণ করে। ওই বাইটগুলোর মধ্যে কেবল 1360 ফাইলটি পড়া প্রসেসে পৌঁছায়। 1400-কে অ্যাপ্লিকেশন পেলোড ধরুন, যে ডায়াগ্রামে ওই কলাম নেই তা আপনাকে এভাবেই আমন্ত্রণ জানায়, আর ভিতরের ডিভাইসটি এমন দেয়ালের সামনে 40 বাইট অতিরিক্ত উদার হয়ে যায় যা নড়েনি।
দুটি MTU আলাদা করে সেট করুন
বাহক আর নেস্টেড ডিভাইস আলাদা বস্তু, তাই প্রত্যেকের নিজের মান দরকার। এই ক্রমে সেগুলো প্রয়োগ করুন, কারণ নেস্টেড ডিভাইস বাহক থেকে কিছুই উত্তরাধিকার পায় না:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400মনে রাখার মতো নিয়ম: ভিতরের MTU = বাইরের MTU - 20, যখন IPIP টানেল যে প্যাকেট বহন করে তা IPv4, আর - 40 যখন ভিতরের প্যাকেটের যেকোনো দিক IPv6 হয়, কারণ নেস্টেড হেডার 20 বাইট থেকে 40-এ বাড়ে। এই বিয়োগে আর কিছুই ঢোকে না। WireGuard-এর ওভারহেড 1420 বেছে নেওয়ার সময়ই খরচ হয়ে গেছে, আর এটি দুবার ধার্য করলে এমন টানেল তৈরি হয় যা নিখুঁতভাবে কাজ করে এবং কেউ না মাপা পর্যন্ত ধীর থাকে। যে স্থাপনায় দুই ডিভাইসই গোল 1400 বহন করে, তা ঠিক ওই ভুলের আঙুলের ছাপ।
নেস্টেড প্যাকেটের যেকোনো পাশে IPv6 থাকলে উপরের প্রতিটি সংখ্যা অকার্যকর হয়ে যায়, তাই অনুরূপ সাইট থেকে সংখ্যা কপি না করে পুনরায় হিসাব করুন। IPv6 বাইরের পথে বা মূল ডেটাগ্রামে দেখা দেওয়ার পর বিয়োগকৃত হেডারগুলো প্রতিটি 40 বাইট, আর পেলোডের সংখ্যা ঠিক ততটাই কমে।
যে ফায়ারওয়াল নিয়মটির সম্ভবত আপনার দরকার নেই
দুই WireGuard পিয়ারের মধ্যে তারে কেবল UDP থাকে, তাই প্রোটোকল 4-এর জন্য একটি ইনবাউন্ড নিয়ম — যে নম্বরটি RFC 2003 IPv4-এর-ভিতরে-IPv4 এনক্যাপসুলেশনকে দেয় — নেস্টেড পথ তৈরি করে না, তা সচলও রাখে না। IPIP হেডার এনক্রিপ্টেড পেলোডের ভিতরে থাকে, যেখানে কোনো প্রান্তীয় ফায়ারওয়াল তা দেখে না। তবু প্রোটোকল 4 খোলা হোস্টে আরেকটি অনুমোদিত প্রবেশপথ ছাড়া কিছুই কেনে না।
মূল প্যাকেটের উৎস ও গন্তব্যের উল্লেখ করা নীতি ডিক্যাপসুলেশনের পরে, টানেল ইন্টারফেসে ও রাউটিং টেবিলে বসে। সেখানে রাখুন, প্রান্তীয় নিয়মটি বন্ধই থাকতে পারে।
WireGuard আসলে কী যাচাই করে
AllowedIPs WireGuard যে প্যাকেট বহন করে তার উৎসের বিচার করে, আর এটি বহন করে IPIP-এনক্যাপসুলেটেড প্যাকেট। অনুমোদিত IPIP উৎস গৃহীত হয় এমনকি যখন ভিতরের হেডার এমন হোস্টের নাম দেয় যা আপনি রাউট করতে চান না। তাই মূল উৎস আপনার জন্য পিয়ার যাচাই করেছে তা নয়, আর ভিতরের ওই ঠিকানা-জোড়ার ডিক্যাপসুলেশনের পরে নিজস্ব প্রয়োগ দরকার।
মোড়কটি রাউটিং কাঠামো দেয়, দ্বিতীয় স্তরের ক্রিপ্টোগ্রাফি নয়। WireGuard-এর ভিতরে IPIP-কে বাড়তি সুরক্ষা বলা ভিন্ন এক নকশার বর্ণনা।
একটি ping নয়, একটি সিঁড়ি দিয়ে যাচাই করুন
আপনি যে সীমানা হিসাব করেছেন তা দুই পাশে ছাড়ানো আকারগুলো যাচাই করুন, তারপর কার্নেল দুই ডিভাইস সম্পর্কে কী মনে করে তা নিশ্চিত করুন। 1360 বাইট পেলোড আর 40 বাইট হেডার মিলে 1400 হলে, নিচের প্রথম ইকোটি ধরে, দ্বিতীয়টি সিলিং থেকে এক বাইট ওপারে বসে:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0সিলিংয়ের নিচে পরিষ্কারভাবে পার হওয়া আর তার ওপরে প্রথম আকারে ব্যর্থ হওয়া মানে হিসাবটি শুরু থেকে শেষ পর্যন্ত টেকে। তারপর যে স্থানান্তরটি প্রথমে আটকে গিয়েছিল তা আবার চালান, কারণ কৃত্রিম প্রোব বাজেট প্রমাণ করে, প্রেরকের নিজের লেখার আকার সম্পর্কে কিছুই বলে না। প্রমাণিত আকারেও যদি নেস্টেড পথটি এখনো ভাঙে, তাহলে MTU থেকে আরও দশ বাইট কাটার আগে দূরের প্রান্তের ডিক্যাপসুলেশন ও রুট দেখুন।