MSS নিয়মটি রাউটারে কাজ করে, কিন্তু Squid-এ ব্যর্থ হয়

একজন প্রশাসক FORWARD-এ TCPMSS ক্ল্যাম্পিং যোগ করেন। সরাসরি রাউট করা ট্রাফিক উন্নত হয়, কিন্তু স্থানীয় Squid ইনস্ট্যান্স দিয়ে ডাউনলোড এখনও আটকে যায়। প্রক্সির ওয়েবসাইট সংযোগ কেবল ক্লায়েন্টের TCP সংযোগ সেই শৃঙ্খল দিয়ে যাওয়া নয়।

সাধারণ সমাপ্তিকারী ফরওয়ার্ড প্রক্সিতে ক্লায়েন্টের দিকের সংযোগ স্থানীয়ভাবে শেষ হয়। প্রক্সি উৎস বা প্যারেন্টের দিকে দ্বিতীয় TCP সংযোগ তৈরি করে। Linux-এ সেই সংযোগের জন্য তৈরি প্যাকেটগুলো স্থানীয় আউটপুট পথ অনুসরণ করে।

তাই কেবল FORWARD-এর নিয়ম পুরোপুরি কার্যকর হয়েও যে হ্যান্ডশেক সংশোধন করার কথা ছিল তা মিস করতে পারে। hook বাছাই করার আগে প্রকৃত সংযোগ ও SYN-এর দিক ম্যাপ করুন। কনটেইনার বা আলাদা namespace আরও একটি রাউট করা অংশ যোগ করতে পারে, তাই সঠিক স্থান নির্ভর করে প্রক্রিয়াটি কোথায় চলছে তার উপর।

PMTU সংখ্যাটি সরাসরি MSS-এ দেবেন না

পথ MTU হলো IP প্যাকেটের আকার। TCP MSS TCP পেলোড বর্ণনা করে এবং প্রাসঙ্গিক হেডার হিসাব করতে হয়। অনুরূপভাবে ping পেলোডের দৈর্ঘ্য সম্পূর্ণ IP প্যাকেটের দৈর্ঘ্য নয়। পরিচিত 28 বাইট যোগটি মৌলিক IPv4 ICMP echo বিন্যাসের সঙ্গে যুক্ত, প্রতিটি অ্যাড্রেস ফ্যামিলি বা এনক্যাপসুলেশনের সঙ্গে নয়।

TCPMSS টার্গেট স্পষ্ট মান ও PMTU ক্ল্যাম্পিং নথিভুক্ত করে। ক্ল্যাম্পিং এখনও পথের MTU তথ্যের উপর নির্ভর করে; এটি পথ আবিষ্কার সুস্থ থাকার প্রমাণ নয়, প্রয়োজনীয় ICMP বার্তা অনুমোদনের বিকল্পও নয়।

লক্ষণটিকেও তত্ত্বের সঙ্গে মেলান। সম্পূর্ণ হ্যান্ডশেকের পর বড় স্থানান্তরে আটকে যাওয়া প্যাকেট আকার তদন্তের যৌক্তিকতা দেয়। বারবার উত্তরহীন SYN বা তাৎক্ষণিক reset আরও বিস্তৃত ব্যাখ্যা দাবি করে; ছোট প্যাকেট ব্যর্থ হলে অতিরিক্ত বড় ডেটা সেগমেন্ট প্রমাণিত হয় না।

রেকর্ডে কাজ করা সরাসরি সংযোগ ও ব্যর্থ প্রক্সি সংযোগ আলাদা রাখুন। একই মেশিন থেকেও তারা ভিন্ন উৎস, পথ ও এনক্যাপসুলেশন ব্যবহার করতে পারে।