WireGuard থেমে যাওয়া: MTU সীমা নাকি অনুপস্থিত ফরওয়ার্ড নিয়ম?
সার্ভারের ওপাশে কিছুই কাজ না করলে সেটি ফরওয়ার্ডিং বা রিটার্ন রুটের সমস্যা। ছোট অনুরোধ চললে আর বড়গুলো আটকে গেলে সেটি প্যাকেট আকারের লক্ষণ।
অভ্যাস হলো WireGuard খারাপ আচরণ করলেই MTU কমিয়ে দেওয়া, আর সেই অভ্যাস অন্য একটি ত্রুটি ঢেকে রাখে। যে গেটওয়ে ফরওয়ার্ড করে না এবং যে পথ বড় প্যাকেট বহন করে না, তারা আলাদা প্যাটার্ন তৈরি করে: একটি উভয় দিকেই এবং প্রতিটি আকারেই ব্যর্থ হয়, অন্যটি ছোট অনুরোধে টিকে থাকে আর বড়গুলোতে মারা যায়। কোনো সংখ্যা বদলানোর আগে আপনার কোন রূপ সেটি চিহ্নিত করুন। পরীক্ষাটি সস্তা এবং এটি সম্ভাব্য কারণের অর্ধেক সরিয়ে দেয়।
দুটি ব্যর্থতা, দুটি ভিন্ন রূপ
ফরওয়ার্ডিং সমস্যা সার্ভারের ঠিক পরে দেখা যায়। হ্যান্ডশেক সফল হয়, টানেল ঠিকানা উত্তর দেয়, আর গেটওয়ের পিছনে ছোট অনুরোধ দিয়েও কিছুই পৌঁছায় না। প্যাকেটটি সার্ভারে পৌঁছেছিল কিন্তু পাঠানো হয়নি, অথবা উত্তরের ফেরার কোনো পথ ছিল না।
আকারের সমস্যা কেবল একটি সীমার উপরে দেখা যায়। DNS, একটি TCP হ্যান্ডশেক এবং একটি ছোট API কল কাজ করে, অথচ একটি ফাইল ডাউনলোড বা বড় উত্তর আটকে যায়। যে প্যাকেটগুলো ধরে গিয়েছিল সেগুলো এক প্রান্ত থেকে অন্যপ্রান্ত পর্যন্ত গেছে, আর যেগুলো ধরে না সেগুলো কোথাও ব্যবহারযোগ্য রিপোর্ট ছাড়াই ফেলে দেওয়া হয়েছে।
সেই বর্ণনাগুলো ভিন্ন মানুষ ও ভিন্ন কনফিগারেশন ফাইলের দিকে ইশারা করে, তাই আন্দাজের চেয়ে রূপটি মাপা বেশি মূল্যবান। গেটওয়েতে একটি একক পিং তাদের আলাদা করতে পারে না।
কিছু ছোট করার আগে ফরওয়ার্ডিং বাদ দিন
গেটওয়ে নিজে নয়, গেটওয়ের ওপাশের একটি গন্তব্য পরীক্ষা করুন। সার্ভারের টানেল ঠিকানায় পিং কেবল প্রমাণ করে যে ইন্টারফেসটি চালু এবং টানেল শেষ করা মেশিনে আপনি পৌঁছান। বিস্তৃত নেটওয়ার্কের ট্রাফিক নির্ভর করে সেই মেশিনে IP ফরওয়ার্ডিং চালু থাকা এবং ফরওয়ার্ড হওয়া প্রবাহকে অনুমতি দেওয়া ফায়ারওয়ালের উপর। দুটোই সত্য হতে হবে, আর যেকোনো একটি মিথ্যা হলে একই নীরবতা তৈরি হয়।
রিটার্ন রাউটিংও সমান গুরুত্বপূর্ণ। যদি গন্তব্য নেটওয়ার্ক ক্লায়েন্টের টানেল ঠিকানায় পৌঁছানোর পথ না জানে, অনুরোধ আসে আর উত্তর অদৃশ্য হয়ে যায়, এবং ক্লায়েন্ট এমন টাইমআউট জানায় যা বাদ পড়া ফরওয়ার্ডের মতোই দেখায়।
যেখানে ডিজাইনে ঠিকানা অনুবাদ ব্যবহার হয়, সেখানে অনুবাদের নিয়মটি সেই ফেরার পথের অংশ। MTU সমস্যার পিছু নেওয়ার সময় তা সরিয়ে ফেললে একটি কাজ করা ডিজাইন ভাঙা ডিজাইনে পরিণত হয়, তাই সম্পাদনার আগে বিদ্যমান নিয়মগুলো পড়ুন।
বিরতি কোথায় শুরু হয় তা মাপুন
প্রথমে ফরওয়ার্ডিংয়ের অবস্থা ও ফিল্টার নিয়মগুলো পড়ুন। এগুলো কেবল পড়ার পরীক্ষা এবং সস্তা প্রশ্নটির উত্তর দেয়:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9তারপর ক্লায়েন্ট থেকে গেটওয়ের ওপাশের একটি হোস্টের দিকে, ডোন্ট-ফ্র্যাগমেন্ট বিট দিয়ে আকারগুলো পরখ করুন:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9যদি প্রথম পরখ কাজ করে আর দ্বিতীয়টি ফ্র্যাগমেন্টেশন ত্রুটিতে ব্যর্থ হয়, পথটি আপনাকে তার ব্যবহারযোগ্য আকার জানাচ্ছে। যদি কোনোটিই কাজ না করে, আপনি ফরওয়ার্ডিং বা রাউটিং দেখছেন, এবং MTU বদলানোর চলক নয়।
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
আপনি যে স্তরটি প্রমাণ করেছেন সেটি ঠিক করুন
যখন ফরওয়ার্ডিং দোষী, সমাধান হলো একটি ফরওয়ার্ডিং নিয়ম বা রুট, ডিজাইন যতটা সংকীর্ণ অনুমতি দেয় ততটা সংকীর্ণভাবে প্রকাশ করা। যখন আকার দোষী, সমাধান হলো এমন MTU যা এই নির্দিষ্ট পথের এনক্যাপসুলেশন হিসাব করে, এবং তা প্রয়োজনের ইন্টারফেসে প্রয়োগ করা হয়, ফ্লিটের প্রতিটি অ্যাডাপ্টারে নয়।
যেভাবেই হোক, পরে একই গন্তব্যে একই কাজটি আবার করুন। যদি মূল বড় স্থানান্তরটি এখন সম্পন্ন হয়, তবে পরিবর্তনটি সেই স্তরটিকেই সম্বোধন করেছে যা ব্যর্থ হচ্ছিল। যদি কেবল ছোট পরখটি উন্নত হয়, আপনি একটি উপসর্গের চিকিৎসা করেছেন আর প্রকৃত সীমাটি এখনও রয়েছে।
পরিবর্তনের আগে আপনি কোন রূপ দেখেছেন তা লিখে রাখুন। সমাধানের পাশে লেখা সেই এক লাইনই পরের মানুষকে এমন MTU কমানো থেকে বিরত রাখে যা কখনো সমস্যা ছিল না।