SA IKEv2 شما برپا است ولی SA فرزند وجود ندارد: تبادل را بخوانید
احراز هویت می‌تواند تمام شود در حالی که مذاکره SA فرزند شکست می‌خورد. پیش از مسیرها یا شمارنده‌ها، تبادل ساخت SA فرزند را بخوانید، سپس پیشنهاد و انتخابگرها را.
IKE می‌گوید تونل برپا است، SA فرزند غایب است، و هر دو گزاره می‌توانند همزمان درست باشند. رابطه کنترل برقرارشده یک انجمن داده نیست، و دو شیء عمر، مذاکره و حالت‌های شکست جداگانه دارند. گزارش اولی به عنوان اتصال همان راهی است که تیکت در پایان ادعا می‌کند تونل برپا است در حالی که هیچ چیز کار نمی‌کند. فهرست انجمن‌ها را بخوانید نه برچسب خلاصه اتصال را، زیرا آن فهرست تنها جایی است که شیء غایب دیده می‌شود. آنچه می‌آید ترتیبی است که فهرست در آن معنا پیدا می‌کند.
دو انجمن، دو کار
یک SA IKE کانال کنترل را حمل می‌کند: هویت‌ها، کلیدها و پیشنهادهای خود تبادل کنترل. یک SA فرزند محافظت ESP را با الگوریتم‌های خود و انتخابگرهای ترافیک خود حمل می‌کند. احراز هویت و ساخت SA فرزند معمولاً با هم پیش می‌روند، چون SA فرزند نخست درون IKE_AUTH مذاکره می‌شود، و همین بسته‌بندی است که مردم را از این جدایی شگفت‌زده می‌کند.
این دو شکل شکستی را هم که با آن‌ها روبه‌رو می‌شوید توضیح می‌دهد. SA فرزندی که در تبادل آغازین رد می‌شود معمولاً SA IKE را هم با خود پایین می‌آورد، پس اصلاً هیچ کانال کنترل برقرارشده‌ای نمی‌بینید. SA IKE که تنها می‌ایستد بیشتر یعنی SA فرزند نخست موفق شده و تلاش بعدی برای ساخت SA فرزند شکست خورده است، مثلاً هنگام تازه‌سازی کلید. برچسب‌های زمانی این حالت‌ها را سریع‌تر از هر بازبینی پیکربندی از هم جدا می‌کنند.
کدام لایه رد کرد
وقتی SA فرزندی رد می‌شود، اعلان لایه را نام می‌برد. رد پیشنهاد یعنی طرفین نتوانستند بر سر الگوریتم‌ها توافق کنند، غالباً چون یکی گروه رازداری کامل رو به جلو متفاوتی یا رمزنگاری‌ای می‌خواهد که دیگری نمی‌پذیرد. رد انتخابگر یعنی مجموعه ترافیک یکسره رد شده است، و این استدلال پوشش است نه استدلال رمزنگاری.
گاهی نبود SA فرزند خودِ طراحی است. SA IKE بدون SA فرزند یک افزونه تعریف‌شده است که در جایی به کار می‌رود که انجمن داده باید درخواستی ساخته شود، پس نبود آن درست است و SA فرزند وقتی ترافیک منطبق می‌رسد پدیدار می‌شود. یادداشت‌های strongSwan درباره IKEv2 هم سبک درخواستی و هم تنظیمات پیشنهاد را که مورد نخست را تعیین می‌کنند پوشش می‌دهند.
پیش از عیب‌یابی، وجود پیکربندی درخواستی یا تله را بررسی کنید. اگر SAهای فرزند به‌صورت تنبل ساخته می‌شوند، نبود SA فرزند در حالت بیکار وضعیت مورد انتظار است و آزمون واقعی این است که آیا ترافیک یکی را بالا می‌آورد. این آزمون طراحی تنبل را از شکست خاموش هم جدا می‌کند، چون ساخت ناموفق محرک را بی‌پاسخ می‌گذارد نه فقط بیکار.
سپس از مسیر داده بپرسید
وقتی SA فرزندی وجود دارد، شمارنده‌ها به پرسش بعدی پاسخ می‌دهند. ip -s xfrm state شمار بسته و بایت هر انجمن را گزارش می‌کند، و SA فرزندی که چیزی حمل نمی‌کند در حالی که ترافیک تولید می‌کنید به تطبیق یا مسیریابی اشاره دارد نه به انجمن غایب. swanctl --list-sas انتخابگرهای SA فرزند را کنار آن شمارنده‌ها چاپ می‌کند، و همین تأیید می‌کند که بسته درون مجموعه پذیرفته‌شده است.
احراز هویت موفق و تبادل ناموفق SA فرزند را در گزارش جدا نگه دارید. گزارشی که می‌گوید احراز هویت شکست خورد، مهندس بعدی را به انبار گواهی می‌فرستد، و جمله دقیق بسیار کوتاه‌تر است: SA IKE بالا آمد، و SA فرزند برای این جریان هرگز پذیرفته نشد.
دو سر را به هم مربوط کنید
برای سروری که خودتان اداره می‌کنید، گزارش‌های کارخواه و دروازه را برای همان تبادل بگیرید، نه اینکه دو تلاش اتصال مجدد با فاصله یک ساعت را مقایسه کنید. اعلان‌ها باید در دو طرف یکی باشند، و جایی که یکی نیستند، طرف بدپیکربندی‌شده را یافته‌اید.
مذاکره SA فرزند را اصلاح کنید، سپس با ترافیک درون انتخابگر موردنظر دوباره آزمون کنید. این تنها آزمونی است که ثابت می‌کند شیء غایب اکنون حاضر است، چون فهرست انجمنی که در حالت بیکار تازه می‌شود می‌تواند پیش و پس از اصلاح یکسان به نظر برسد.