Linux IPsec গেটওয়েতে TCP MSS ক্ল্যাম্পিং: এটি কী ঠিক করে

Ping কাজ করে, SSH কাজ করে, ছোট একটি পাতা লোড হয়, আর তারপর প্রতিটি বড় উত্তর সময় শেষ হওয়া পর্যন্ত আটকে থাকে। চিরচেনা ধরনটি পৌঁছানোযোগ্যতা নয়, প্যাকেটের আকারের দিকে ইঙ্গিত করে: পথটি হ্যান্ডশেক ও প্রথম কয়েক কিলোবাইট বহন করে, তারপর পূর্ণ আকারের সেগমেন্ট উধাও হয়ে যায়। Linux IPsec গেটওয়েতে TCP MSS নিয়ম প্রায়ই সমাধান, তবে কেবল তখনই যদি আপনি বোঝেন এটি কী বদলায় এবং এটি যে প্যাকেট স্পর্শ করে তা আসলে কোথায় আছে। নিচের ক্রমটি উপসর্গ থেকে নিয়ম স্থাপন পর্যন্ত প্যাকেটকে অনুসরণ করে, যাতে ব্যাখ্যাটি আর খাপ না খেলেই আপনি থামতে পারেন।

যে উপসর্গ MSS-এর দিকে ইঙ্গিত করে

TCP হ্যান্ডশেকে সর্বোচ্চ সেগমেন্ট আকার নিয়ে দরকষাকষি করে। যদি সেই মানটি এনক্যাপসুলেশনের পর পথটি যে পরিমাণ বহন করতে পারে তার চেয়ে বড় হয়, তবে প্রেরক এমন সেগমেন্ট তৈরি করতে থাকে যা কখনও পৌঁছায় না, এবং প্রথম রাউন্ড ট্রিপের পর সংযোগটি আটকে যায়। ছোট উত্তরগুলো ফিট হয়; বড়গুলো নয়।

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

TCPMSS নিয়ম কী করে আর কী করে না

নিয়মটি TCP হ্যান্ডশেক প্যাকেট পার হওয়ার সময় তাদের MSS অপশনটি পুনর্লিখন করে। এটি টানেল ইন্টারফেসের MTU নির্ধারণ করে না, IPsec নীতিমালা বদলায় না, এবং বর্তমান কার্নেলে কেবল ঘোষিত একটি মান কমায়, আগে থেকে ছোট মান বাড়ায় না। এটি কেবল TCP-তে হাত দেয়; UDP পেলোড, DNS আচরণ এবং দরকষাকষি করা ট্রাফিক সিলেক্টর এর নাগালের বাইরে।

যেহেতু পরিবর্তনটি হ্যান্ডশেকের সময় ঘটে, নিয়মের আগে প্রতিষ্ঠিত একটি বিদ্যমান সংযোগ তার পুরোনো মান ধরে রাখে। নতুন সংযোগ দিয়ে পরীক্ষা করুন, এবং আশা করুন পরিবর্তনের পরের প্রথম প্রচেষ্টাই আপনাকে কিছু বলবে। নিয়মের কিছুই ইতিমধ্যে খোলা সংযোগে পৌঁছায় না। এজন্যই কোনো ঘটনার মাঝখানে প্রয়োগ করা সমাধান দেখে মনে হতে পারে এটি কিছুই করেনি।

নিয়মটি ভেতরের TCP পথে রাখুন

নীতিমালাভিত্তিক Linux গেটওয়েতে ফায়ারওয়াল যখন ফরোয়ার্ড করা প্যাকেট দেখে, তখনও তা সাধারণ TCP-এর মতোই দেখায়। IPsec নীতিমালা ঠিক করে প্যাকেটটি সুরক্ষিত হবে; ফায়ারওয়াল ভেতরের প্রবাহের জন্য ESP হেডার দেখে না, তাই এখানে ESP-এর সঙ্গে মিলিয়ে দেখা সম্পূর্ণ ভিন্ন একটি প্যাকেটের বর্ণনা দেয়। এই অমিলের কারণেই কিছু নিয়ম সঠিক দেখায় অথচ কখনও মেলে না।

iptables-এর ভাষায় নিয়মটি ফরোয়ার্ডিং পথের mangle টেবিলে রাখতে হয়, কেবল হ্যান্ডশেক প্যাকেটে সীমিত: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270। সংখ্যাটি একটি উদাহরণ, সর্বজনীন ধ্রুবক নয়; এনক্যাপসুলেশন ওভারহেড ও পথের প্রকৃত MTU থেকে এটি বের করুন। nftables-এর সমতুল্য একটি forward বা postrouting চেইনে সর্বোচ্চ সেগমেন্ট আকার নির্ধারণ করে।

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

ফায়ারওয়ালের মালিকানা ও NAT-এর ক্রমকে সম্মান করুন

UFW যদি হোস্ট ফায়ারওয়ালের মালিক হয়, তবে mangle ও ফরোয়ার্ডিং পরিবর্তনগুলো পরেরবার রিলোডে হারিয়ে যাওয়া কোনো কমান্ড টাইপ করার বদলে তার সমর্থিত স্থায়ী কনফিগারেশনের মাধ্যমে যোগ করুন। ভুল টেবিলে বা কোনো টার্মিনাল নিয়মের পরে ঢোকানো নিয়মের কোনো প্রভাব নেই, আর চালু টেবিলটি তা আপনার কাছ থেকে লুকিয়ে রাখে।

সোর্স অনুবাদ একটি আলাদা সিদ্ধান্ত যা প্রায়ই এটির সঙ্গে মিথস্ক্রিয়া করে। সাধারণ masquerade নিয়মের আগে বসানো একটি অব্যাহতি সুরক্ষিত ট্রাফিককে তার নীতিমালার প্রয়োজনীয় সোর্স হারানো থেকে বাঁচায়; এটি আকারের সমস্যা মেরামত করে না, আর আকারের নিয়ম অনুবাদের সমস্যা মেরামত করে না।

সংকীর্ণভাবে যাচাই করুন, তারপর থামুন

ব্যর্থ সেবায় একটি নতুন সংযোগ খুলুন এবং অ্যাপ্লিকেশন ও নিয়মের কাউন্টার দুটোই লক্ষ্য করুন। আটকে যাওয়া যদি সরে যায়, তবে সেই এনক্যাপসুলেশনসহ ওই TCP পথ সম্পর্কে আপনার প্রমাণ আছে। প্রতিটি VPN প্রোটোকল খাপ খায়, প্রতিটি UDP অ্যাপ্লিকেশন ঠিক হয়েছে, বা নির্দিষ্ট কোনো আপস্ট্রিম সেবাই মূল কারণ ছিল—এসবের প্রমাণ আপনার নেই।

যেখানে নীতিমালা অনুমতি দেয় সেখানে ICMP আকার-প্রতিক্রিয়া কাজ করতে দিন, এবং বাইরের IPsec পথ যখন ভেতরের রুটে প্রতিনিধিত্ব করে না তখন রুট-MTU ভিত্তিক স্বয়ংক্রিয় ক্ল্যাম্পিংয়ের সঙ্গে সতর্কভাবে আচরণ করুন। সিদ্ধান্ত যত সংকীর্ণ, পরের ঘটনাটি তত সহজে নির্ণয় করা যায়।