IPsec থ্রুপুট প্রত্যাশার চেয়ে কম? আগে সক্রিয় SA যাচাই করুন
লম্বা ট্রান্সফর্ম তালিকা আপনার স্থানান্তর রক্ষা করা সেশন নয়। এনক্রিপশনকে দোষ দেওয়ার আগে সমঝোতা করা SA, পেলোড আকার এবং প্রকৃতপক্ষে পৌঁছানো হার লিখে রাখুন।
কনফিগারেশন আটটি ট্রান্সফর্ম দেয়, কেউ সবচেয়ে শক্তিশালীটি পড়ে এবং থ্রুপুটের সংখ্যা তার উপরেই চাপানো হয়। টানেল সম্ভবত সেই ট্রান্সফর্মটি বেছে নেয়নি এবং কেউ কল্পনা করা কাজের চাপও চালায়নি। যা সমঝোতা হয়েছে তা এই তালিকার একটি এন্ট্রি, একটি প্যাকেট আকার, একটি দিক, একটি বিল্ডে। এটি মাপুন এবং অ্যালগরিদম নিয়ে বিতর্ক সাধারণত শুরু হওয়ার আগেই শেষ হয়।
লক্ষণ: কনফিগারেশনের প্রতিশ্রুতির চেয়ে কম সংখ্যা
লম্বা ট্রান্সফর্ম তালিকা সম্ভাবনা বর্ণনা করে এবং প্রতিটি সম্ভাবনা এই হার্ডওয়্যারে নয়, কাগজে মূল্যায়ন করা হয়। সমঝোতা করা ফলাফল একটিই সমন্বয় যা উভয় পক্ষ গ্রহণ করেছে এবং এটি সেই সবচেয়ে দুর্বল সমন্বয় হতে পারে যা সামঞ্জস্যের জন্য কোনো পক্ষ এখনও অনুমোদন করে। সেই সমন্বয় কী অর্জন করে তা অফলোড অবস্থা, প্যাকেট আকার এবং সারির আচরণের উপর নির্ভর করে, তাই একই নীতি ফাইলযুক্ত দুটি ডিভাইস অনেক দূরে গিয়ে পড়তে পারে। তালিকা একটি মেনু; অ্যাসোসিয়েশন হলো ফিরে আসা অর্ডার।
তালিকা পড়লে বোঝা যায় কী বেছে নেওয়া যেত। অ্যাসোসিয়েশন পড়লে বোঝা যায় স্থানান্তরটি আসলে কী বহন করছে, এবং থ্রুপুটের সংখ্যা কেবল তারই বর্ণনা দেয়। তালিকা থেকে শুরু হওয়া প্রতিটি টিউনিং পদক্ষেপ অতিরিক্ত কাগজপত্রসহ একটি অনুমান।
এই স্থানান্তর বহনকারী অ্যাসোসিয়েশন লিখে রাখুন
একটি ASA-তে show crypto ipsec sa সক্রিয় অ্যাসোসিয়েশনগুলো তাদের ট্রান্সফর্ম ও প্রতি-দিক কাউন্টারসহ তালিকাভুক্ত করে এবং কমান্ড রেফারেন্স Cisco এই আউটপুট নথিভুক্ত করে। গুরুত্বপূর্ণ পিয়ার ও দিক বেছে নিন এবং লক্ষ্য রাখুন যে কী-রিকি অ্যাসোসিয়েশনটি প্রতিস্থাপন করে ও তার কাউন্টার শূন্য করে, যা আপনার এখনও ভরসা করা ভিত্তিরেখাকে নীরবে অকার্যকর করে দেয়। আউটপুটটি পরীক্ষার নোটের পাশে রাখুন যাতে পরের বার তুলনা করার কিছু থাকে। রানগুলোর মধ্যে বদলে যাওয়া অ্যাসোসিয়েশন শনাক্তকারী পরবর্তী প্রতিটি তুলনাকে অর্থহীন করে তোলে।
| What to record | Where to read it | What it rules out |
|---|---|---|
| Negotiated transform and SA identifiers | show crypto ipsec sa for that peer and direction | "the configuration picked the wrong algorithm" |
| Offload or accelerator state for that build | platform show commands and interface statistics | "the crypto engine is the ceiling" |
| Payload size and offered rate | the test tool's own settings and summary | "packets per second versus bytes per second" |
| Delivered rate and loss at the receiver | the receiving endpoint, not the sender's counters | "the sender transmitted, so it arrived" |
| Access-link load and drops | underlay interface counters along the path | "the bottleneck lives inside the tunnel" |
পাঁচটি সারি মাপন পুনরুৎপাদনযোগ্য করতে যথেষ্ট এবং প্রতিটি সারি অনুপস্থিত থাকলে নির্দিষ্ট ব্যাখ্যা বাদ দেয়। এগুলোর কোনোটিই প্রস্তাব-তালিকার এন্ট্রি নয়, কারণ তালিকা বলতে পারে না এখন আপনার বাইটগুলো কী রক্ষা করছে। টেবিলটি একবার পূরণ করুন এবং পরের ঘটনাটি অ্যালগরিদম নিয়ে নতুন বিতর্কের বদলে ডেটা দিয়ে শুরু হবে।
অ্যাক্সেস-লিঙ্ক সারিটি হলো যেটি মানুষ এড়িয়ে যায়, এবং ক্রিপ্টোগ্রাফিক দেখতে একটি ফাঁক প্রায়ই সেটিই ব্যাখ্যা করে। সম্পৃক্ত আন্ডারলে বা পথে থাকা পুলিসার ধীর ইঞ্জিনের মতো একই লক্ষণ-আকৃতি তৈরি করে।
নিয়ন্ত্রিত লোড দিয়ে একটি দিক মাপুন
পরীক্ষাটি গেটওয়ে থেকে নয়, বরং অ্যাপ্লিকেশনকে প্রতিনিধিত্বকারী একটি LAN প্রান্ত থেকে চালান, কারণ গেটওয়ে তৈরি করা প্রোব ভিন্ন স্থানীয় নীতি অনুসরণ করতে পারে। দ্বিতীয় স্ট্রিম যোগ করার আগে একটি দিক মাপুন এবং দুটোই লিখুন: প্রদত্ত হার এবং রিসিভার আসলে যা পেয়েছে। হার-সীমিত UDP রান প্রদত্ত লোডকে TCP-র ভিড়-প্রতিক্রিয়া থেকে আলাদা করে, অন্যদিকে সীমাহীন UDP প্রেরক নিরপেক্ষ রোগনির্ণয় নয়। পেলোড দৈর্ঘ্যও লিখুন, কারণ বড় ডেটাগ্রাম প্যাকেট হার ও এনক্যাপসুলেশন ওভারহেড দুটোই বদলায়।
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30একই পরীক্ষা দুইবার একই পেলোড দৈর্ঘ্য ও সময়কালে চালান, কারণ একটি রান উপরের সীমাকে খারাপ মিনিট থেকে আলাদা করতে পারে না। যদি রিসিভার প্রেরকের পাঠানোর চেয়ে কম প্যাকেট জানায়, তবে ক্ষতি আপনার সিদ্ধান্ত এবং ক্রিপ্টো ইঞ্জিন তার কয়েকটি প্রার্থীর একটি মাত্র।
কিছু টিউন করার আগে ফাঁকটি ব্যাখ্যা করুন
ফরওয়ার্ডিং নীতি, সারি ড্রপ, ইন্টারফেস ত্রুটি এবং রিসোর্স সীমা এনক্রিপশন পথের সঙ্গে যাচাই করুন, কারণ শুধু হারের ঘাটতি কখনও CPU চিহ্নিত করে না। হিসাবের স্তরগুলোও স্পষ্ট রাখুন: বাইরের টানেল বাইটে এনক্যাপসুলেশন থাকে এবং পুনঃপ্রেরণ ভেতরের ও বাইরের কাউন্টারের সম্পর্ক সরিয়ে দেয়। সম্পর্কহীন কাউন্টারের বাইট-বাই-বাইট তুলনা এমন একটি ব্যবধান বানায় যা কখনও ছিল না।
প্যাকেট আকার পুরোনো উদাহরণ থেকে কপি করা সংখ্যার বদলে নিজের নিয়ন্ত্রিত তুলনার যোগ্য। TCP MSS TCP সমন্বয় করে এবং ইচ্ছাকৃত UDP ডেটাগ্রামে কোনো প্রভাব ফেলে না, তাই পুরোনো নথি থেকে নেওয়া নির্দিষ্ট 1350 কিছুই মাপে না। পেলোড দৈর্ঘ্য ইচ্ছাকৃতভাবে বদলান এবং রিসিভার কী জানায় দেখুন।
একটি চলক বদলান এবং কাজের চাপ ধরে রাখুন
ভিত্তিরেখা সংকীর্ণ ব্যান্ডে পুনরাবৃত্তি হলে একটি সমর্থিত চলক বদলান এবং মূল অ্যাপ্লিকেশন কাজটি আবার চালান। এই পদক্ষেপই একটি সংখ্যাকে কারণ্যে বদলায় এবং কনফিগারেশন স্পর্শ করার যৌক্তিকতা কেবল এটিই দেয়। বেশি অনুকূল কাজের চাপের বদলে একই চাপ পুনরাবৃত্তি করুন।
কৃত্রিম সংখ্যা বড় করতে প্রস্তাব প্রত্যাহার করবেন না, প্রমাণীকরণ দুর্বল করবেন না এবং সুরক্ষা বন্ধ করবেন না। এই পদক্ষেপগুলো নিরাপত্তা অবস্থান বদলায় এবং তারপর সেই পরিবর্তনের ফল মাপে, টানেলের ধারণক্ষমতা নয়।