সব ICMP ব্লক করলে কাজ করা VPN পথ কেন ভাঙে
আকার-সংক্রান্ত ফিডব্যাক বার্তা ping-এর উত্তর নয়। এগুলো কখনো না এলে ছোট প্যাকেট পার হয়, বড়গুলো হারিয়ে যায়, আর টানেলটি দোল খাওয়ার মতো দেখায়।
যে টানেল প্রমাণীকরণ পেরোয়, একটি ping বহন করে এবং তারপর প্রথম বড় স্থানান্তরে আটকে যায়, সেটি ভাঙা VPN-এর নয় বরং হারানো ICMP বার্তার চিরাচরিত লক্ষণ। প্রেরক কখনো জানতে পারে না যে প্যাকেটটি খুব বড় ছিল, একই আকারে বারবার চেষ্টা করে, আর অ্যাপ্লিকেশনটি অপেক্ষা করে। এটি ঠিক করা ফায়ারওয়াল নীতির সিদ্ধান্ত, ক্লায়েন্ট পুনঃস্থাপন নয়। ক্রমটি গুরুত্বপূর্ণ: আকারের সীমা কোথায় তা মাপুন, তারপর যে নিয়মটি রিপোর্টটি গিলে ফেলেছিল তা সংকুচিত করুন।
এই পথে ICMP আসলে কী বহন করে
IPv4 পথ MTU আবিষ্কার নির্ভর করে একটি রাউটার জানানোর উপর যে don't-fragment বিট সেট থাকা একটি প্যাকেট পাঠানো যায়নি। সেই রিপোর্টটি ICMP Fragmentation Needed বার্তা, এবং এটি ছাড়া প্রেরকের সেগমেন্টের আকার কমানোর কোনো কারণ থাকে না। IPv6 আরও কঠোর: রাউটাররা ট্রানজিটে খণ্ডন করে না, তাই ICMPv6 Packet Too Big বার্তাই একমাত্র সংকেত যা প্রেরককে ছোট হতে বাধ্য করে।
দুটি বার্তাই কন্ট্রোল-প্লেন ফিডব্যাক, এবং কোনোটিই ডায়াগনস্টিক ইকো নয়। ping ব্লক করা নীতি আর সব ICMP ব্লক করা নীতি নিয়মের তালিকায় একই রকম দেখায় কিন্তু নেটওয়ার্কে খুব ভিন্নভাবে আচরণ করে। দ্বিতীয়টি সঠিক আকারের টানেলকে শৃঙ্খলের সবচেয়ে ছোট লিঙ্কের চেয়ে বড় যেকোনো কিছুর জন্য একমুখী পথে পরিণত করতে পারে।
কিছু ট্রান্সপোর্ট নিজস্ব আবিষ্কার প্রোব প্যাকেট দিয়ে করে, যেমন RFC 4821 বর্ণনা করে, এবং সেগুলো এই ফিডব্যাকের উপর কম নির্ভরশীল। এটি কোন ট্রান্সপোর্ট চালাচ্ছেন তা যাচাই করার যুক্তি, প্রতিটি টানেল প্রতিরোধী ধরে নেওয়ার নয়।
| বার্তা | পথে উদ্দেশ্য | ব্লক করা হলে |
|---|---|---|
| ICMPv4 ধরন 3 কোড 4 | পরবর্তী লিঙ্কের জন্য প্যাকেটটি খুব বড় ছিল | প্রেরক বারবার চেষ্টা করে এবং আটকে যায় |
| ICMPv6 ধরন 2 | Packet Too Big, IPv6-এর সমতুল্য | একই আটকে যাওয়া, খণ্ডনের কোনো বিকল্প ছাড়াই |
| ICMP ধরন 11 | সময় অতিক্রান্ত, traceroute ব্যবহার করে | ডায়াগনস্টিকস হপ হারায়, ট্রাফিক তবুও প্রবাহিত হয় |
| ICMP ইকো অনুরোধ ও উত্তর | পৌঁছানোর পরীক্ষা | ping ব্যর্থ হয়, পথ ঠিক থাকতে পারে |
ব্যর্থতাটি আকার-নির্ভর
জিজ্ঞাসা করুন ব্যর্থতাটি প্যাকেটের আকারের সাথে সম্পর্কিত কি না। একটি লগইন পাতা, DNS কোয়েরি এবং সংক্ষিপ্ত API কল সফল হয়, অথচ একটি ফাইল আপলোড, বড় উত্তর বা ছবি ডাউনলোড আটকে যায়। এই ধরনটি দুই প্রান্তের মাঝে কোথাও আকারের সীমার দিকে ইশারা করে, প্রমাণীকরণ বা রাউটিংয়ের দিকে নয়। একটি সফল ছোট ping সেই সীমা কোথায় তা নিয়ে প্রায় কিছুই বলে না।
টানেলের ভিতরে দুটি স্তর বিবেচনা করতে হয়: পেলোড প্যাকেট এবং বাইরের এনক্যাপসুলেটেড প্যাকেট। ভিতরের প্রেরক সঠিকভাবে আচরণ করতে পারে অথচ বাইরের পথ টানেলের অনুমানের চেয়ে ছোট হতে পারে, তাই টানেলের নিজস্ব MTU সেটিং এবং তার নিচের ভৌত লিঙ্ক—দুটোই গুরুত্বপূর্ণ।
নিয়ম সম্পাদনার আগে মাপুন
don't-fragment বিট এবং আপনার বেছে নেওয়া পেলোড আকার দিয়ে প্রোব করুন, ব্যর্থ ক্লায়েন্ট থেকে একটি সুরক্ষিত ঠিকানার দিকে:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.71472 বাইটের পেলোড আর 28 বাইট হেডার মিলে 1500 বাইটের প্যাকেট হয়। যদি বড় প্রোবটি খণ্ডন ত্রুটিতে ব্যর্থ হয় আর ছোটটি পাস করে, আপনি সীমাটি খুঁজে পেয়েছেন; টানেলের অতিরিক্ত ভারসাম্য ধরে সামঞ্জস্য করুন এবং কার্যকর আকার স্থিতিশীল হওয়া পর্যন্ত পুনরাবৃত্তি করুন।
তারপর নিশ্চিত করুন যে ফাঁকটি রিপোর্টটিই। যদি প্রোবটি নিঃশব্দে ব্যর্থ হয়, কোনো ত্রুটি ও উত্তর ছাড়া, বার্তাটি সম্ভবত বাতিল হচ্ছে, পৌঁছাচ্ছে না, আর সন্দেহভাজন হলো নিয়মটি।
নিয়ম সংকুচিত করুন, তারপর কাজটি আবার পরীক্ষা করুন
সংশোধনটি নির্দিষ্ট কন্ট্রোল বার্তাগুলোকে অনুমতি দেবে, পুরো প্রোটোকলকে নয়। iptables হোস্টে রূপটি ধরন-নির্দিষ্ট গ্রহণ; আপনার প্ল্যাটফর্মে ফায়ারওয়াল যা পরিচালনা করে তার সাথে সিনট্যাক্স মানিয়ে নিন:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTস্থানীয় নীতি এমন হলে ইকো উত্তর ব্লক করাই রাখুন, কারণ পথের প্রয়োজন সেগুলো নয়। তারপর মূলত ব্যর্থ হওয়া স্থানান্তরটি নতুন সংযোগ থেকে আবার পরীক্ষা করুন এবং নিয়মের কাউন্টারগুলো বার্তা আসছে তা দেখাচ্ছে কি না নিশ্চিত করুন।
বার্তাগুলো অনুমোদনের পরেও বড় স্থানান্তরটি আটকে থাকলে, বাকি সীমাটি অন্য জায়গায়: খুব উঁচুতে সেট করা টানেল MTU, প্যাকেট পুনর্লিখন করা প্রক্সি, বা জানানোর বদলে ফেলে দেওয়া মিডলবক্স। ICMP নিয়মটি প্রয়োজনীয় ছিল, যথেষ্ট নয়।