বড় ডাউনলোড বনাম VPN: অনুরোধেই পথ বেছে নিন

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

কেন রাউটার উত্তরের আকার জানতে পারে না

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

এমনকি প্রোটোকলের নিজস্ব মেটাডেটাও যতটা মনে হয় ততটা শক্তিশালী নয়। HTTP এমন উত্তর অনুমোদন করে যার দৈর্ঘ্য বডির আগে ঘোষণা করা হয় না, আর একটি ব্যবহারকারী-ক্রিয়া বহু অনুরোধ তৈরি করতে পারে যাদের মিলিত খরচ কোনো একটি হেডার মানের মতো নয়। হেডারকে কাজের আকার হিসেবে ধরা রাউটিং ভুলের আগেই মডেলিং ভুল।

পরীক্ষা 1: পথ বেছে নিতে পারে এমন সিদ্ধান্ত-বিন্দু আছে কি?

যে উপাদানটি বেছে নেবে তার নাম দিন, তারপর সে নির্বাচনের মুহূর্তে কী জানে তা বলুন। নথিভুক্ত হোস্ট-তালিকা থেকে আনে এমন আপডেটার স্থানান্তর শুরুর আগেই নিজের উদ্দেশ্য জানে। মেটাডেটা দেখে তারপর অনুরোধ খোলে এমন ডাউনলোড সেবা সংযোগ তৈরির আগেই কাজটি জানে। সহযোগী proxy অনুরোধ-স্তরের নীতি প্রয়োগ করতে বা উত্তর ক্যাশ করতে পারে, নিজেকে রাউটার বলে না দেখিয়ে।

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

পরীক্ষা 2: মেটাডেটা আসলে আপনাকে কী বলে?

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

অ্যাপ্লিকেশন মেটাডেটা যা সমর্থন করতে পারে তা হলো কোনো কাজ সম্পর্কে সিদ্ধান্ত: এই ওয়ার্কফ্লো বাল্ক সিঙ্ক, এটি ইন্টারঅ্যাকটিভ, এটি পরিচিত উৎস থেকে সফটওয়্যার আপডেট। এটা উদ্দেশ্যের ভাষায় লেখা নীতি, আর পরীক্ষা করার মতো যথেষ্ট স্থিতিশীল। „এই উত্তরটি চল্লিশ মেগাবাইটের চেয়ে বড় হবে“ সে ধরনের নীতি নয়।

পরীক্ষা 3: ফ্লো কি ইতিমধ্যেই আছে?

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

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

তাই ব্যবহারিক নিয়ম হলো, সংযোগের মাঝপথে এক বহির্গমন থেকে অন্যত্র সরানো নতুন সম্পর্ক, স্থানান্তর নয়। নকশা যদি একই সংযোগ চালু রাখা চায়, সিদ্ধান্তটি প্রথম SYN-এর আগেই নিতে হতো, আর পরে যোগ করা কোনো প্যাকেট-নিয়মই তা পরিষ্কারভাবে পুনর্গঠন করতে পারে না।

পরীক্ষা 4: আসল প্রয়োজন কি বিলম্ব, বহির্গমন নয়?

„বাল্ক ট্র্যাফিক অন্যত্র পাঠান“ ধরনের অনেক অনুরোধ আসলে অভিযোগ যে বড় স্থানান্তর ইন্টারঅ্যাকটিভ কাজকে ধীর করে দেয়। এটি সময়সূচির সমস্যা, আর এর সময়সূচিভিত্তিক উত্তর আছে: বিদ্যমান পথে ন্যায্য কিউ বা সমর্থিত ব্যান্ডউইথ নীতি বাল্ক ফ্লোকে চ্যাট বার্তাকে অভুক্ত করতে দেয় না, দুটির কোনোটিই না সরিয়ে।

tc qdisc replace dev eth0 root cake bandwidth 100mbit

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

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

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