پاسخ‌های DPD ثابت می‌کنند همتای IKE زنده است، نه این‌که داده‌های شما جریان دارد
پاسخ‌های زنده‌بودن، یک اعلان پدینگ و انتخابگرهای باریک‌شده سه چیز متفاوت را توصیف می‌کنند. پیش از سرزنش یکی از آن‌ها برای یک توقف، آن‌ها را جداگانه بخوانید.
گزارش‌های IPsec می‌توانند پاسخ‌های زنده‌بودن را نشان دهند در حالی که برنامه‌ی پیش روی آن‌ها متوقف است، و هر دو واقعیت می‌توانند هم‌زمان درست باشند. یک پاسخ DPD ثابت می‌کند که پردازش IKE همتا در آن لحظه پاسخ داده است؛ درباره‌ی این‌که آیا SA فرزند بسته‌ای را که برای شما مهم است حمل می‌کند چیزی نمی‌گوید. برخورد با هر هشدار نزدیک یک قطعی به‌عنوان علت آن، همان روشی است که یک مشکل انتخابگر به‌صورت باگ پروتکل تشخیص داده می‌شود. سه مشاهده بیشتر از همه اشتباه گرفته می‌شوند و آن‌ها به سه پرسش متفاوت پاسخ می‌دهند. پیش از خواندن بر اساس مهر زمانی، آن‌ها را بر اساس ارتباط و هدف بخوانید.
هر مشاهده چه چیزی را ثابت می‌کند
جدول آنچه را هر مشاهده اثبات می‌کند از آنچه فقط همراهی می‌کند جدا می‌کند.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
هیچ‌کدام از این سه به‌تنهایی خطا نیست. هر کدام فقط در کنار جریانی که در حال اشکال‌زدایی آن هستید جالب می‌شود، و سطری که به جریان مشخصی پیوند نمی‌خورد زمینه است نه شاهد.
زنده‌بودن سلامت داده نیست
DPD به‌صورت تبادل INFORMATIONAL اجرا می‌شود، گفت‌وگویی در سطح کنترل میان دیمن‌های IKE. یک پاسخ ثابت می‌کند که فرآیند IKE همتا قابل دسترسی است و آماده‌ی پاسخ دادن است، و یک پایان مهلت ثابت می‌کند که نیست. هیچ‌یک از دو نتیجه SA فرزند، انتخابگرها، مسیر ارسال یا پاسخ برنامه را آزمایش نمی‌کند، بنابراین DPD سالم در کنار انتقالی متوقف‌شده تصویری منسجم است نه تناقض.
به همین دلیل خطوط زنده‌بودن کم‌فایده‌ترین بخش یک تیکت سطح داده هستند، هرقدر هم در بالای گزارش آرامش‌بخش به نظر برسند.
اعلان پدینگ بیانیه‌ای درباره‌ی پدینگ است
پدینگ TFC بیش از همه در این گزارش‌ها اشتباه خوانده می‌شود. می‌گوید که پدینگ محرمانگی جریان ترافیک برای آن SA فرزند پذیرفته نخواهد شد، که بیانیه‌ای درباره‌ی یک ویژگی اختیاری پدینگ است نه رد حفاظت ESP. یافتن آن نزدیک یک خرابی معمولاً تصادفی از پرحرفی است و روشن یا خاموش کردن پدینگ چیزی را در پوشش انتخابگرها تغییر نمی‌دهد.
مشخصات IKEv2 هم اعلان و هم مذاکره‌ی انتخابگر را تعریف می‌کند، و برچسب هشدار یک پیاده‌سازی در هیچ‌یک از دو حالت جای معنای پروتکل را نمی‌گیرد.
باریک‌سازی آرام‌تر است و بیشتر احتمال دارد مهم باشد
پاسخ‌دهنده می‌تواند زیرمجموعه‌ای از انتخابگرهای پیشنهادی را بپذیرد، و مجموعه‌ی پذیرفته‌شده می‌تواند در چند ورودی چاپ شود، یکی با تعیین پورت و دیگری شامل همه‌ی پورت‌ها. خواندن تنها نخستین خط با تعیین پورت، مقدار پذیرفته‌شده را کم‌نمایی می‌کند؛ خواندن تنها خط گسترده آن را بیش‌نمایی می‌کند. پیشنهاد چاپ‌شده را با خط‌مشی نصب‌شده مقایسه کنید، چون پیشنهاد آن چیزی است که همتاها گفته‌اند و خط‌مشی آن چیزی است که هسته تطبیق خواهد داد. وقتی ناسازگارند، تونل وجود دارد و ترافیک نه، که همان شکایت متناوب کلاسیک است. هنگام مقایسه‌ی همتاها دیدگاه محلی و دور را برعکس کنید، زیرا محلی هر طرف دورِ طرف دیگر است.
ورودی‌های مخصوص میزبان با محدودیت پورت ارزش دو بار خواندن را دارند، زیرا همان‌ها هستند که ICMP یا پورت دومی را کنار می‌گذارند در حالی که پینگ به دروازه همچنان کار می‌کند.
برای جریان خراب یک رکورد بسازید
مبدأ، مقصد، خانواده‌ی نشانی، پروتکل و پورت را همان‌گونه که در تصمیم حفاظت دیده می‌شوند ثبت کنید، از جمله هر ترجمه‌ی عمدی. این‌ها مقادیری هستند که باید با یک انتخابگر تطبیق کنند و همان مقادیری هستند که مردم وقتی تیکت به دست سوم می‌رسد از حافظه دوباره تایپ می‌کنند.
سپس SA فرزند و شمارنده‌های جهت‌دار آن را شناسایی کنید: swanctl --list-sas خلاصه‌ی انجمن را روی میزبان strongSwan می‌دهد و ip -s xfrm state شمارنده‌ها را می‌دهد. آن‌ها را پس از یک درخواست مجاز تازه بخوانید نه زمانی که سیستم بی‌کار است. نبود افزایش در ترافیک خروجی به انتخاب یا مسیر محلی اشاره دارد؛ خروجی بدون ورودی متناظر به همتا، ارسال آن یا پاسخ‌هایش اشاره دارد.
تبادل کامل‌شده‌ی برنامه از هر یک از شمارنده‌ها مهم‌تر است، به همین دلیل آزمون باید در برنامه پایان یابد نه در نشانگر تونل.
تصحیح را بعداً انتخاب کنید
تنها پس از وجود آن رکورد است که تصحیحی برای انتخاب وجود دارد: انتخابگرهای پذیرفته‌شده، مسیر، فیلترکردن، پیاده‌سازی همتا، یا مرزی که اکنون نشان داده‌اید. بازنشانی همتا چندین حالت را هم‌زمان تغییر می‌دهد و غالباً ترافیک را بی‌آن‌که توضیح دهد کدام اشتباه بود بازمی‌گرداند، پس قطعی بازمی‌گردد. دامپ‌های وضعیت هسته را هم بیرون از تیکت‌ها نگه دارید، چون ممکن است کلید داشته باشند و خلاصه‌ی کوتاه برای هر کسی که بخواهد کمک کند کافی است.
وقتی رکورد با نظریه‌ی اول شما در تضاد است، به رکورد باور کنید و نظریه را بازنویسی کنید؛ این عادت از هر یک خط گزارش که اینجا بحث شد ارزشمندتر است.