ACK প্যাকেটে conntrack NEW: এটি কী প্রমাণ করে না

ফায়ারওয়াল লগে এমন একটি লাইন আছে যা আপনি আশা করেননি: একটি ACK প্যাকেট, conntrack স্টেট NEW, উৎস ঠিকানা আপনার নয়, গন্তব্য পোর্ট খোলা। প্রলোভন হলো এটিকে কেউ অনুমোদন না দেওয়া নতুন অন্তর্গামী সংযোগ হিসেবে পড়া। লাইনটি আসলে যা বলে তা আরও সংকীর্ণ: ওই প্যাকেট যখন এই hook-এ পৌঁছায়, তখন ট্র্যাকারের মিলে যাওয়া কোনো স্টেট ছিল না, এবং প্যাকেটটি ACK বহন করছিল। এগুলো দুটি ভিন্ন জিনিস সম্পর্কে দুটি তথ্য, এবং কোনোটিই সম্পূর্ণ handshake রেকর্ড নয়। সিদ্ধান্তে পৌঁছানোর আগে আমি যে ক্রম অনুসরণ করি তা এই।

রায় নয়, প্যাকেট দিয়ে শুরু করুন

ব্যাখ্যা করার আগে পর্যবেক্ষণগুলো আলাদা করুন। TCP ফ্ল্যাগ এই প্যাকেটের বর্ণনা দেয়, ট্র্যাকারের স্টেট ওই hook-এ সে কী জানত তা বর্ণনা করে, আর আপনার ক্যাপচার কেবল আপনি যে উইন্ডো রেকর্ড করেছেন তার বর্ণনা দেয়।

এই তিনটিকে গুলিয়ে ফেলাই একটি ACK-কে “প্রোভাইডার কাউকে ঢুকতে দিয়েছে”-এ পরিণত করে।

hook-এ NEW আসলে কী বোঝায়

iptables conntrack মিল NEW-কে এমন প্যাকেট হিসেবে নথিভুক্ত করে যা একটি সংযোগ শুরু করে, অথবা এমন সংযোগের সঙ্গে যুক্ত যা এখনো উভয় দিকে ট্রাফিক দেখেনি। ESTABLISHED মানে ট্র্যাকার উভয় দিকে প্যাকেট দেখেছে। কোনো সংজ্ঞাতেই বলা নেই প্যাকেটটি SYN ছিল, আর এও বলা নেই যে এটি ইতিহাস ছাড়া এসেছে।

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

শিথিল ট্র্যাকিং বেশিরভাগ ACK বিস্ময় ব্যাখ্যা করে

কার্নেল নথিভুক্ত করে nf_conntrack_tcp_loose, যা ট্র্যাকারকে এমন TCP সংযোগ তুলে নিতে দেয় যার শুরু সে দেখেনি। সেটিংটি ডিফল্টে থাকলে প্রবাহের মাঝপথের একটি ACK প্রতিষ্ঠিত প্রবাহ হিসেবে গৃহীত হতে পারে। এটি বন্ধ করুন, আর একই প্যাকেট NEW-এর বদলে INVALID হিসেবে শ্রেণিবদ্ধ হওয়ার সম্ভাবনা বেশি। দুই ফলাফলই ট্র্যাকারের নিয়ম বর্ণনা করে, অ্যাপ্লিকেশনের ইতিহাস নয়।

তাই লেবেলের ওপর তত্ত্ব দাঁড় করানোর আগে ওই সেটিংটি যাচাই করুন।

একঘেয়ে কারণগুলো এই ক্রমে বাদ দিন

আমি যে NEW-অন-ACK ঘটনাগুলোর পেছনে গেছি, বেশিরভাগই এগুলোর একটিতে শেষ হয়েছে, আর সবগুলোই সস্তায় যাচাইযোগ্য:

• conntrack টেবিল ফ্লাশ হয়েছে, অথবা ট্র্যাকার রিস্টার্ট হয়েছে।
• হোস্ট রিবুট হয়েছে, অথবা প্রবাহটি অন্য namespace বা ডিভাইসে চলে গেছে।
• অসমান রাউটিং SYN-টি এমন পথে পাঠিয়েছে যা আপনি ক্যাপচার করছেন না।
• NAT tuple পুনর্লিখন করেছে, তাই এন্ট্রিটি আর আপনার পড়ার সঙ্গে মেলে না।
• ক্যাপচার দেরিতে শুরু হয়েছে এবং শুরুটা কখনো দেখেনি।

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

এগিয়ে যাওয়ার আগে লিখে রাখুন কোনগুলো বাদ দিয়েছেন এবং কীভাবে।

tuple, ইন্টারফেস ও hook পড়ুন

conntrack এন্ট্রির চাবি হলো ঠিকানা, পোর্ট ও প্রোটোকল, তাই যেকোনো অনুবাদ বদলে দেয় কোন এন্ট্রি মেলে। ইন্টারফেস ও hook-ও লিপিবদ্ধ করুন, কারণ ভুল ইন্টারফেসে বা অন্য চেইনের পরে দেখা প্যাকেট বলে দেয় পথটি ডায়াগ্রামে যা দেখানো হয়েছে তা নয়। ঘটনাটি VPN-সংক্রান্ত হলে, আপনি ভেতরের প্যাকেট না বাইরের বাহক দেখছেন তা নির্ধারণ করুন। তারপর গেটওয়ে একই পাঁচ-অংশের tuple-এর জন্য যা লগ করেছে তার সঙ্গে তুলনা করুন।

একই প্রবাহের দুটি পরস্পরবিরোধী দৃশ্য যেকোনো একটির চেয়ে বেশি তথ্য দেয়।

কখন escalate করা উচিত

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

তারপর সেই দৃশ্যমানতার ফাঁক বন্ধ করুন যা একটি প্যাকেটকে পুরো সেশন বলে দেখিয়েছিল।