توان عملیاتی IPsec کمتر از انتظار؟ ابتدا SA فعال را بررسی کنید
فهرست بلند تبدیل‌ها همان نشستی نیست که انتقال شما را محافظت می‌کند. SA مذاکره‌شده، اندازه بار و نرخ تحویل‌شده را قبل از سرزنش رمزنگاری ثبت کنید.
پیکربندی هشت تبدیل ارائه می‌دهد، کسی قوی‌ترین را می‌خواند و رقم توان عملیاتی به آن نسبت داده می‌شود. احتمالاً تونل آن تبدیل را انتخاب نکرده و همان بار کاری را هم که کسی تصور می‌کرد اجرا نکرده است. آنچه مذاکره شده یک ورودی از این فهرست است، با یک اندازه بسته، در یک جهت، روی یک بیلد. این را اندازه بگیرید و بحث درباره الگوریتم‌ها معمولاً پیش از شروع تمام می‌شود.
نشانه: رقمی کمتر از آنچه پیکربندی وعده می‌دهد
فهرست بلند تبدیل‌ها امکانات را توصیف می‌کند و هر امکان روی کاغذ سنجیده می‌شود نه روی این سخت‌افزار. نتیجه مذاکره یک ترکیب واحد است که هر دو طرف پذیرفته‌اند و می‌تواند ضعیف‌ترین ترکیبی باشد که هر طرف هنوز برای سازگاری مجاز می‌داند. آنچه این ترکیب به دست می‌آورد به وضعیت offload، اندازه بسته و رفتار صف بستگی دارد، بنابراین دو دستگاه با فایل خط‌مشی یکسان می‌توانند بسیار دور از هم قرار بگیرند. فهرست یک منو است؛ تداعی همان سفارشی است که برگشت.
خواندن فهرست به شما می‌گوید چه چیزی می‌توانست انتخاب شود. خواندن تداعی به شما می‌گوید چه چیزی واقعاً انتقال را حمل می‌کند و تنها همین چیزی است که رقم توان عملیاتی توصیف می‌کند. هر گام تنظیم که از فهرست شروع می‌شود یک حدس همراه با کاغذبازی اضافی است.
تداعی‌ای را ثبت کنید که این انتقال را حمل می‌کند
روی یک ASA show crypto ipsec sa تداعی‌های فعال را همراه با تبدیل‌ها و شمارنده‌های هر جهت فهرست می‌کند و مرجع فرمان سیسکو این خروجی را مستند می‌کند. همتای مقابل و جهت مهم را انتخاب کنید و توجه داشته باشید که مذاکره مجدد کلید تداعی را جایگزین و شمارنده‌هایش را صفر می‌کند، که بی‌صدا یک خط پایه مورد اعتماد شما را باطل می‌کند. خروجی را کنار یادداشت‌های آزمون ذخیره کنید تا اجرای بعدی چیزی برای مقایسه داشته باشد. شناسه تداعی که بین اجراها جابه‌جا شود هر مقایسه بعدی را بی‌معنا می‌کند.
| 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" |
پنج ردیف کافی است تا یک اندازه‌گیری تکرارپذیر شود و هر ردیف وقتی غایب باشد توضیح مشخصی را رد می‌کند. هیچ‌کدام ورودی فهرست پیشنهادها نیست، چون فهرست نمی‌تواند بگوید همین حالا چه چیزی از بایت‌های شما محافظت می‌کند. جدول را یک بار پر کنید و حادثه بعدی با داده آغاز می‌شود نه با بحث تازه درباره الگوریتم‌ها.
ردیف پیوند دسترسی همان ردیفی است که مردم از آن می‌گذرند، و همان ردیفی است که بیشتر اوقات شکافی را توضیح می‌دهد که رمزنگاری به نظر می‌رسد. یک underlay اشباع‌شده یا policer در طول مسیر همان شکل نشانه را می‌سازد که یک موتور کند.
یک جهت را با بار کنترل‌شده اندازه بگیرید
آزمون را از یک نقطه پایانی در 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همان آزمون را دو بار با همان طول بار و همان مدت اجرا کنید، چون یک اجرا نمی‌تواند سقف را از یک دقیقه بد جدا کند. اگر گیرنده بسته‌های کمتری از آنچه فرستنده فرستاده گزارش کند، افت یافته شماست و موتور رمزنگاری تنها یکی از چند نامزد است.
شکاف را توضیح دهید پیش از آنکه چیزی را تنظیم کنید
خط‌مشی ارسال، افت صف، خطاهای رابط و محدودیت منابع را همراه با مسیر رمزنگاری بررسی کنید، چون کمبود نرخ به‌تنهایی هرگز پردازنده را مشخص نمی‌کند. لایه‌های حسابداری را هم صریح نگه دارید: بایت‌های تونل بیرونی شامل کپسوله‌سازی است و ارسال‌های مجدد رابطه بین شمارنده‌های درونی و بیرونی را جابه‌جا می‌کند. مقایسه بایت‌به‌بایت شمارنده‌های بی‌ربط اختلافی می‌سازد که هرگز وجود نداشت.
اندازه بسته شایسته مقایسه کنترل‌شده خودش است نه رقمی کپی‌شده از یک مثال قدیمی. TCP MSS خود TCP را تنظیم می‌کند و هیچ اثری بر داده‌گرام‌های دلخواه UDP ندارد، پس مقدار ثابت 1350 که از سندی قدیمی منتقل شده اصلاً چیزی را اندازه نمی‌گیرد. طول بار را عمداً تغییر دهید و ببینید گیرنده چه گزارش می‌کند.
یک متغیر را تغییر دهید و بار کاری را نگه دارید
وقتی خط پایه در باریکه‌ای باریک تکرار شد، یک متغیر پشتیبانی‌شده را تغییر دهید و وظیفه اصلی برنامه را دوباره اجرا کنید. همان گام چیزی است که یک رقم را به علت تبدیل می‌کند و تنها گام موجه برای دست زدن به پیکربندی است. همان بار کاری را تکرار کنید نه باری راحت‌تر.
پیشنهادها را کنار نگذارید، احراز هویت را تضعیف نکنید و حفاظت را خاموش نکنید تا رقمی مصنوعی بزرگ‌تر شود. این اقدام‌ها وضعیت امنیتی را تغییر می‌دهند و سپس نتیجه همان تغییر را می‌سنجند، نه ظرفیت تونل را.