Windows L2TP কিছু সাইট লোড করে: pfSense-এ DF বিট পরিষ্কার করুন

ল্যাপটপ সংযুক্ত হয়, ইন্ট্রানেট লোড হয়, আর কয়েকটি পাবলিক সাইট আটকে যায়। প্রমাণীকরণ ও রাউটিং স্পষ্টভাবে কাজ করছে, ফলে ব্যাখ্যা হিসেবে প্যাকেটের আকারই থাকে। L2TP/IPsec টানেলে ব্যবহারযোগ্য MTU অ্যাডাপ্টার যে মান ঘোষণা করে তার চেয়ে ছোট, এবং ক্লায়েন্ট ফ্র্যাগমেন্ট-নয় বিট সেট করে পূর্ণ আকারের প্যাকেট পাঠাতেই থাকে। pfSense গেটওয়েকে সেই বিট পরিষ্কার করতে বলা যায়, এবং সঠিকভাবে সমাধান করার আগে রোগনির্ণয় নিশ্চিত করার এটি দ্রুততম উপায়।

যে পৃষ্ঠাগুলো ব্যর্থ হয় সেখান থেকেই শুরু করুন

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

যে ping বিট সেট করে ও পেলোডের আকার নিয়ন্ত্রণ করে তা দিয়ে পরীক্ষা করুন। যে বৃহত্তম পেলোড টিকে থাকে তা আপনাকে প্রকৃত পথের MTU জানায়, আর অ্যাডাপ্টারের ঘোষিত মান দেখায় দুটি কত দূরে।

দুটি সংখ্যাই লিখে রাখুন। কোনটি ভুল তার উপরেই সমাধান নির্ভর করে, আর জোড়াটিই পরে ক্যাপচার নিশ্চিত করে।

বাইরের দিকে যাওয়ার পথে DF বিট কী করে

সংখ্যাগুলো আলাদা হওয়ার কারণ এনক্যাপসুলেশন। IPsec ESP যোগ করে, L2TP আরেকটি হেডার যোগ করে, তাই টানেল ভৌত লিঙ্কের চেয়ে কম পেলোড বহন করে। Windows এখনও অ্যাডাপ্টারে 1500 বাইট জানায় এবং যা পাঠায় তাতে ফ্র্যাগমেন্ট-নয় সেট করে। এমন প্যাকেট না ধরলে গেটওয়ে থেকে সঠিক উত্তর হলো প্রেরককে ছোট হতে অনুরোধ করা একটি ICMP বার্তা। এজন্যই ছোট ping পার হওয়া টানেলও ফাইল ডাউনলোড ব্যর্থ করতে পারে।

সেই বার্তা প্রায়ই কখনো পৌঁছায় না। কোনো হপ ICMP ফিল্টার করতে পারে, বা কিছুই তা তৈরি করে না, আর প্রেরক স্থানান্তর হাল ছাড়া পর্যন্ত একই আকার পুনরাবৃত্তি করে।

এখানে নীরবতাই স্বাভাবিক উপস্থাপনা, তাই উপসর্গটি নির্বাচিত ব্লকিং হিসেবে পড়া হয়। ক্লায়েন্ট লগে অনুপস্থিত ICMP বার্তা কিছুই লিপিবদ্ধ করে না।

pfSense-এর অপশন, এবং যা এটি করে না

অপশনটি সিস্টেম, অ্যাডভান্সড, ফায়ারওয়াল ও NAT পৃষ্ঠায় আছে, লেবেল «প্যাকেট ফেলার বদলে অবৈধ DF বিট পরিষ্কার করুন»। ফ্ল্যাগ বহনকারী অতিরিক্ত বড় প্যাকেট ফেলে দেওয়ার বদলে ফিল্টার ফ্ল্যাগটি সরিয়ে দেয় এবং প্যাকেটকে নিচের দিকে ভাগ হতে দেয়। প্যাকেট তখনই অবৈধ গণ্য হয় যখন এটি এক টুকরোয় বহির্গামী ইন্টারফেস পার হতে পারে না।

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

এটি কেবল ফরওয়ার্ড করা ট্র্যাফিকে প্রযোজ্য, ফায়ারওয়াল নিজে যে ট্র্যাফিক তৈরি করে তাতে নয়। একই পৃষ্ঠা «ফায়ারওয়াল স্ক্রাব বন্ধ করুন» অফার করে, যা স্বাভাবিকীকরণ সম্পূর্ণ বন্ধ করে, আর এটি এই সমস্যার প্রয়োজনের চেয়ে অনেক বড় পরিবর্তন।

TCP-কে অবিচ্ছিন্ন রাখা আরও সংকীর্ণ সমাধান

প্রায় সব আটকে যাওয়া প্রবাহ TCP, আর TCP ফ্র্যাগমেন্টেশনের উপর ভরসা না করে ছোট সেগমেন্টে সমঝোতা করতে পারে। টানেল ইন্টারফেসে MSS ক্ল্যাম্প করলে হ্যান্ডশেকের সময় ঘোষিত মান পুনর্লিখিত হয়, ফলে প্রতিটি পক্ষ যা সত্যিই ধরে তা পাঠায়। তখন পথটি পূর্বানুমেয়ভাবে আচরণ করে এবং কোনো প্যাকেট ভাগ করতে হয় না।

এটি UDP-কে আবিষ্কার বা DF অপশনের উপর ছেড়ে দেয়। ব্যর্থ সাইটগুলো সাধারণ ওয়েব পৃষ্ঠা হলে ক্ল্যাম্পই পছন্দের পরিবর্তন।

ক্লায়েন্ট netsh interface ipv4 show subinterfaces কমান্ডের মাধ্যমে নিজের অ্যাডাপ্টারের MTU জানাতে পারে। সেই সংখ্যাটি সার্ভার যা সমঝোতা হয়েছে বলে মনে করে তার সঙ্গে তুলনা করুন, কারণ দুটি সবসময় এক নয়। সমঝোতা যা-ই জানাক, অপারেটিং সিস্টেম আসলে যে মানটি ব্যবহার করবে সেটিই সেই মান।

ক্যাপচার দিয়ে নিশ্চিত করুন, তারপর অবস্থা রিসেট করুন

সিদ্ধান্তের আগে দুই পাশেই ক্যাপচার করুন: একটি ট্রেস যেখানে টানেল চলে, আরেকটি যেখানে WAN ইন্টারফেস চলে। পূর্ণ আকারে বেরিয়ে যাওয়া আর ICMP ফিরে না আসা ক্ল্যাম্পকে সঠিক স্তর হিসেবে দেখায়। যে উত্তর আসে অথচ ফেরার পথে মরে যায়, সেগুলো বদলে টানেলের MTU-কে নির্দেশ করে।

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