শাখা অফিসে পুনঃসংযোগের ঝড়: strongSwan-এর ভর্তি সীমা

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

একটি ল্যাপটপকে নেটওয়ার্কে ফেরার পথ অনুসরণ করুন

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

এই ক্রমে কোনো কিছুই ত্রুটি নয়। ভর্তি পথটি যা করার জন্য কনফিগার করা হয়েছে তা-ই করছে।

অর্ধ-খোলা কাজকে আলাদা সম্পদ হিসেবে গণনা করুন

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

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

প্রমাণীকরণের বিলম্ব ঠিক করে প্রতিটি প্রচেষ্টা কতক্ষণ অর্ধ-খোলা গণনায় থাকে। ধীরে উত্তর দেওয়া একটি ব্যাকএন্ড স্বল্প ঝড়কে দীর্ঘ সারিতে পরিণত করে, এমনকি আগমনের হার পরিমিত হলেও।

swanctl --stats
swanctl --list-sas | grep -c ESTABLISHED

পরিবর্তনের আগে ভর্তি সেটিংস পড়ুন

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

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

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

grep -rn -E 'block_threshold|cookie_threshold' /etc/strongswan.conf /etc/strongswan.d/
swanctl --stats | grep -i half

প্রত্যাবর্তনের জন্য পরিকল্পনা করুন, কেবল স্থির অবস্থার জন্য নয়

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

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

এই সেটিংসের জন্য ভেন্ডর রেফারেন্স হলো strongswan.conf ডকুমেন্টেশন, যা কাউন্টারগুলোর নাম দেয় এবং যে সংস্করণে প্রতি-ঠিকানার কুকি থ্রেশহোল্ড চালু হয়েছিল। নতুনতম পৃষ্ঠা নয়, আপনার ইনস্টল করা সংস্করণের অংশটি পড়ুন, কারণ ডিফল্টগুলো সংস্করণের মধ্যে বদলায়।