IPv6 প্যাকেট অনেক বড়: বড় VPN ট্রান্সফার কেন আটকে যায়

পিং কাজ করে, ব্রাউজার একটি ছোট পৃষ্ঠা লোড করে, আর ফাইল ট্রান্সফার আটকে যায়—সবই IPv6-এর মাধ্যমে একই টানেল দিয়ে। এই ধরনের প্যাটার্ন সাধারণত বোঝায় যে প্রেরক পথের প্রকৃত আকার কখনো জানতে পারেনি, টানেল ধীর বলে নয়। IPv6 আশা করে রাউটাররা Packet Too Big বার্তা দিয়ে সমস্যাটি জানাবে, আর প্যাকেট বাইরের নেটওয়ার্কে পৌঁছানোর আগেই এনক্যাপসুলেশন বাড়তি ওভারহেড যোগ করে। ওই বার্তাটি ফিল্টার করা হলে প্রেরক এমন একটি আকার বারবার পাঠাতে থাকে যা পার হতে পারে না।

ছোট অনুরোধ, বড় আটকে যাওয়া

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

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

Packet Too Big হলো ফিডব্যাক, ট্রাফিক নয়

একটি ICMPv6 Packet Too Big বার্তা পরবর্তী হপ যে আকার নিতে পারে তা বহন করে, আর প্রেরক তা ব্যবহার করে নিজের অনুমান কমাতে। এটি ফিল্টার করা মানে পথের সাইনবোর্ড সরিয়ে তারপর চালকদের দোষ দেওয়া। সমস্ত ICMPv6 ফেলে দেওয়া নিয়ম কঠোর দেখায়, অথচ যেসব লিঙ্কে এটি দরকার সেখানে পথ আবিষ্কার ভেঙে দেয়। বার্তাটি পথ সম্পর্কে নিয়ন্ত্রণ তথ্য, অ্যাপ্লিকেশন পেলোড নয়।

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

দুটি অ্যাড্রেস পরিবার আলাদাভাবে যাচাই করুন

IPv6 আলাদাভাবে পরীক্ষা করুন, কারণ সফল IPv4 ট্রান্সফার IPv6 পথ সম্পর্কে কিছুই প্রমাণ করে না। তারপর বড় ট্রান্সফার আটকে থাকার সময় নিয়ন্ত্রণ বার্তা ক্যাপচার করুন। দুটি রেকর্ড একসাথে হয় দেখায় ফিডব্যাক বেরিয়ে যাচ্ছে, নয়তো প্রমাণ করে তা কখনো পৌঁছায়নি।

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

প্রোবটি do-not-fragment বিট সেট করে একটি প্যাকেট পাঠায় এবং যে আকারে ব্যর্থ হয় তা জানায়, এটাই সেই সংখ্যা যা টানেলকে সামলাতে হয়। রুট কোয়েরি সেই ইন্টারফেসের নাম দেয় যা গন্তব্য বহন করবে, তাই কোন লিঙ্কের MTU প্রযোজ্য তা আপনি জানেন। ক্যাপচারটি ICMPv6 টাইপ 2, অর্থাৎ Packet Too Big বার্তা, ফিল্টার করে এবং দেখায় এটি আদৌ এই হোস্টে পৌঁছায় কি না। ক্যাপচারে বার্তাটি দেখা গেলে আর ট্রান্সফার তবুও আটকে থাকলে, প্রেরক এটি উপেক্ষা করছে, যা তদন্তকে নেটওয়ার্কের বদলে স্ট্যাকে নিয়ে যায়।

প্রমাণ পাওয়ার পরেই টানেলের আকার বদলান

টানেলের MTU কমানো একটি ফিল্টার করা বার্তা লুকিয়ে লক্ষণটি মুছে দিতে পারে, তবে প্রতিটি প্যাকেটে বেশি ওভারহেডের খরচে। এটি সমাধানের পথ নয়, নির্ণয়ও নয়, এবং ক্যাপচারকে প্রতিস্থাপন না করে তার পরে আসা উচিত। ইচ্ছেমতো কম মান দৃশ্যত কিছুই ভাঙে না, তাই এটি বছরের পর বছর কনফিগারেশনে টিকে থাকে। এটি সচেতনভাবে বদলান, মানটি লিখে রাখুন, আর কোন পরিমাপ এটিকে ন্যায্যতা দিয়েছে তা টুকে রাখুন।

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