وقتی IKEv2 مقدار TS_UNACCEPTABLE را برمی‌گرداند، زیرشبکه‌های واقعی را مقایسه کنید
رد شدن انتخابگر یعنی اختلاف پوشش میان دو طرف. برچسب‌های محلی و دور را جابه‌جا کنید، سپس گستره‌های دقیقی را که هر طرف پیشنهاد می‌کند مقایسه کنید.
TS_UNACCEPTABLE را اختلاف پوشش بخوانید، نه پروفایل خراب. دروازه می‌گوید دو طرف نتوانسته‌اند بر سر اینکه این تونل کدام نشانی‌ها را حمل کند توافق کنند. ممکن است IKE SA در آن لحظه بالا باشد، و همین است که باعث می‌شود کارخواه بدون هیچ SA فرزندی در پشتش متصل به نظر برسد. وقتی این‌طور قالب‌بندی کنید، کار مکانیکی می‌شود. پیشوندهای موردنظر دو طرف را بنویسید، آن‌ها را در یک جهت مقایسه کنید و تا وقتی هم‌پوشانی پیدا کنند باریکشان کنید.
اول جفت‌های موردنظر را بنویسید
پیش از دست زدن به پیکربندی، چهار مقدار را فهرست کنید: گسترهٔ مبدأ آغازگر، گسترهٔ مقصد آن، و همان جفت از دید پاسخ‌دهنده. خانوادهٔ نشانی هر کدام را هم ثبت کنید. گسترهٔ IPv4 و گسترهٔ IPv6 دو نوع جداگانهٔ انتخابگرند و هیچ‌کدام در بار مفید دیگری جای نمی‌گیرد.
هر محدودیت پروتکل یا درگاهی را که سیاست دارد اضافه کنید. قاعده‌ای که فقط TCP 445 به یک کارساز پرونده را مجاز می‌کند، مجموعه‌ای باریک‌تر از زیرشبکه‌ای که در آن قرار دارد توصیف می‌کند. اگر آن را از یادداشت‌هایتان بیرون بگذارید، نتیجهٔ مذاکره به دلایلی که نمی‌بینید ناسازگار به نظر می‌رسد.
پیش از مقایسه، برچسب‌ها را جابه‌جا کنید
محلی و دور برچسب‌هایی نسبی‌اند. پیشوند محلی کارخواه همان گسترهٔ دور دروازه است و گسترهٔ محلی دروازه همان گسترهٔ دور کارخواه. بنابراین تصاویر صفحه از دو سر هرگز هم‌خوان نمی‌شوند و مقایسهٔ تحت‌اللفظی آن‌ها راه معمول از دست دادن یک بعدازظهر است.
پاسخ‌دهنده می‌تواند به جای ردکردن یک پیشنهاد، آن را به زیرمجموعه‌ای قابل‌قبول باریک کند. این نتیجه از یک شکست تمیز بدتر است، چون نصفه کار می‌کند. وقتی سیاست 10.0.5.0/24 را مجاز می‌کند، 10.0.0.0/16 بخواهید و ممکن است با SA فرزندی تمام کنید که فقط همان /24 را پوشش می‌دهد. یک میزبان پاسخ می‌دهد، همه‌چیز دیگر بیرون می‌افتد و هیچ‌چیز در کارخواه این را نمی‌گوید. پیش از آنکه نتیجه بگیرید مذاکره موفق بوده، انتخابگرهای پذیرفته‌شده را بخوانید نه درخواست‌شده‌ها را.
پروفایل‌های road warrior که مسیر پیش‌فرض درخواست می‌کنند دائماً اینجا فرود می‌آیند. دروازه‌ای که برای دسترسی تفکیک‌شده ساخته شده، پیشنهاد تمام‌گستره را به زیرشبکه‌های خودش باریک می‌کند و کارخواه باید نتیجهٔ باریک‌شده را بپذیرد یا با صدای بلند شکست بخورد.
رد شدن را از یک تلاش بخوانید
هر دو گزارش را از همان تلاش اتصال جمع کنید. پروفایل ذخیره‌شده نشان می‌دهد شما چه چیز را پیکربندی کرده‌اید، نه چه چیزی پیشنهاد شده، و در strongSwan فرمان swanctl --log اعلان دریافتی را همراه با انتخابگرهایی که حمل می‌کرده چاپ می‌کند.
سپس بررسی کنید واقعاً چه چیزی نصب شده است. swanctl --list-sas انتخابگرهای SA فرزندی را نشان می‌دهد و ip xfrm policy همان گستره‌ها را به‌صورت ورودی‌های سیاست هسته نشان می‌دهد. SA فرزندی در آن فهرست با انتخابگرهایی که قصدشان را نداشته‌اید یک رویداد باریک‌شدن است؛ نبود SA فرزندی به‌همراه TS_UNACCEPTABLE در گزارش یعنی امتناع.
وقتی آنجا هستید، همسایه‌های نزدیک را جدا کنید. INVALID_SELECTORS از انتخابگری درون یک SA فرزندی برقرار شکایت می‌کند، در حالی که INTERNAL_ADDRESS_FAILURE یعنی پاسخ‌دهنده نتوانسته نشانی مجازی تخصیص دهد، که مشکلی در استخر است نه در پوشش.
بررسی کنید چه چیزی مجموعه را بی‌صدا کوچک می‌کند
سه چیز مجموعهٔ انتخابگر را بدون هیچ حرفی کوچک می‌کنند. سیاست پاسخ‌دهنده اولی است، از طریق فهرست‌های زیرشبکه، قواعد گروهی یا مجوزسازی به‌ازای کاربر که پیشنهاد را به زیرمجموعه کاهش می‌دهد. خانوادهٔ نشانی دومی است: کارخواه دوپشته اغلب IPv6 را در کنار IPv4 پیشنهاد می‌کند و برای گستره‌هایی که دروازه هرگز پیکربندی نکرده رد می‌شود.
محدودیت‌های پروتکل و درگاه سومی هستند. جایی که سیاست فقط TCP 445 را مجاز می‌کند، SA فرزندی می‌تواند بالا بیاید در حالی که ICMP و UDP بیرون آن می‌مانند، و کاربر تونل خراب را گزارش می‌کند در حالی که تنها یک پروتکل مجاز بوده است.
پس فقط گشادکردن نشانی‌ها نمی‌تواند سیاست محدود به درگاه را درست کند، و این همان موردی است که بیشترین احتمال را دارد سه دور عیب‌یابی را بدون تغییر پشت سر بگذارد.
پوشش را با ترافیکی که جا می‌افتد ثابت کنید
پس از نصب SA فرزندی، یک درخواست بفرستید که قطعاً درون گستره‌های پذیرفته‌شده بیفتد. به جای نماد وضعیت، شمارنده‌ها را ببینید: ip -s xfrm state و شمارنده‌های پشت ip xfrm policy وقتی بسته‌ای تطبیق داده و محافظت شود بالا می‌روند. شمار بایتی که پس از ترافیک واقعی صفر بماند یعنی هسته هرگز آن سیاست را انتخاب نکرده است.
آن صفر مشکلی در مسیریابی یا ترتیب سیاست‌هاست، نه مشکلی در رمزنگاری. از دید کاربر هم دقیقاً مثل رد شدن انتخابگر به نظر می‌رسد، و به همین دلیل ارزش دارد پیش از بازکردن دوبارهٔ پروفایل شمارنده‌ها را جمع کنید. شمارنده‌هایی که فقط در یک جهت بالا می‌روند به‌جای آن به مسیر بازگشت اشاره می‌کنند.
در پایان جفت پذیرفته‌شده را در تیکت بنویسید، کنار گستره‌ای که در ابتدا درخواست شده بود. انتخاب را به‌اندازهٔ نیاز باریک نگه دارید، چون پاک‌کردن خطا با جایگزین‌کردن یک گسترهٔ خصوصی با همهٔ نشانی‌ها دسترسی بسیار بیشتری از آنچه برای حساب تأیید شده اعطا می‌کند.