IPsec با چند زیرشبکه ترافیک برگشت را از دست می‌دهد؟ reqidها را بشمارید
ترافیک یک‌طرفه از میان تونلی با چند زیرشبکه معمولاً ناسازگاری خط‌مشی و reqid است، نه رمزنگاری یا مسیریابی. پایگاه‌های داده xfrm را به ترتیب بخوانید.
ترافیک یک سایت را ترک می‌کند و هرگز بازنمی‌گردد، هر دو دروازه مذاکره‌ای کامل‌شده را گزارش می‌کنند، و تنها سرنخ انبوهی از بسته‌های خروجی بدون پاسخ است. روی یک نقطه پایانی لینوکس، علت معمول قدرت رمزنگاری، MTU یا جدول مسیریابی نیست. این دانه‌بندی ورودی‌های خط‌مشی و شماره‌ای است که هر خط‌مشی را به یک انجمن امنیتی پیوند می‌دهد. رویه زیر آن دو پایگاه داده را پیش از دست‌زدن به چیز دیگر می‌خواند.
علامت را پیش از تغییر هر چیزی جدا کنید
خرابی یک‌طرفه با مذاکره IKE کامل‌شده مسئله را به مسیر داده محدود می‌کند. یا خط‌مشی خروج مطابقت داشت و پاسخ دور انداخته شد، یا پاسخ هرگز نرسید چون طرف مقابل چیزی برای فرستادن آن نداشت. از دید یک برنامه هر دو یکسان به‌نظر می‌رسند، و پایگاه‌های xfrm آن‌ها را از هم جدا می‌کنند.
با MTU شروع نکنید. MTU نادرست گیرکردن و نشانه‌های قطعه‌بندی تولید می‌کند، نه جدایی تمیز جهت با شمارنده‌های خروجی رو‌به‌افزایش.
پایگاه خط‌مشی و پایگاه وضعیت را بخوانید
در لینوکس ورودی‌های خط‌مشی رمزنگاری را تعیین می‌کنند، پس خط‌مشی منطبق، نه یک مسیر، بسته را به تونل می‌برد. ip xfrm policy را اجرا کنید تا انتخاب‌گرها، جهت، اولویت و الگوی هر ورودی را ببینید، و ip xfrm state را برای دیدن انجمن‌های برقرارشده با reqidهایشان. خط‌مشی و انجمن با همان reqid به هم پیوند می‌خورند.
هر سه جهت را ببینید. خروجی و ورودی ترافیک به و از این میزبان را پوشش می‌دهند؛ جهت ارسال زمانی مهم است که میزبان برای دیگران مسیریابی می‌کند. ورودی گم‌شده یا ناسازگار در یک جهت نتیجه یک‌طرفه را بدون هیچ نقص رمزنگاری توضیح می‌دهد.
عدم تقارن کلاسیک: یک reqid برای چند زیرشبکه
خرابی رایج از همتایی می‌آید که خط‌مشی‌های همه زیرشبکه‌های مذاکره‌شده را زیر یک reqid نصب می‌کند، که با generate_policy require در racoon رخ می‌دهد. ترافیک سپس از انجمنی خارج می‌شود که آخرین بار برقرار شده، در حالی که طرف مقابل برای هر زیرشبکه انجمنی جدا نگه می‌دارد. پاسخ‌ها روی انجمنی می‌رسند که reqid آن خط‌مشی‌ای را که باید بپذیرد مشخص نمی‌کند، و هسته آن‌ها را پس از رمزگشایی دور می‌ریزد.
اصلاح یک تغییر پیکربندی است نه قاعده دیوار آتش: generate_policy unique; به هر خط‌مشی reqid خودش را می‌دهد، تا انجمن‌های هر خط‌مشی همتا، جفت‌های منطبق داشته باشند. آن را اعمال کنید، دوباره مذاکره کنید، و پیش از اعلام موفقیت reqidهای متمایز زیرشبکه‌های مورد انتظار را بشمارید.
اگر دو زیرشبکه هنوز یک reqid را شریک‌اند در حالی که طرف مقابل دو تا انتظار دارد، عدم تقارن را یافته‌اید. نگاشت را ثبت کنید، چون سند این است که تغییر بعدی آن را اصلاح کرده یا حفظ کرده است.
انتخاب‌گرها از مذاکره می‌آیند نه از پیکربندی شما
بازه‌های محافظت‌شده چیزی است که دو سر توافق کرده‌اند، نه چیزی که یک طرف خواسته است. کاربری که جفت میزبان را در برابر بازه دور گسترده پیشنهاد می‌کند نسخه تنگ‌شده دروازه را می‌گیرد و نمی‌تواند آن را گسترش دهد. انتخاب‌گرهای نصب‌شده را بخوانید نه آن‌هایی که در پرونده محلی شماست.
وقتی هدف معکوس است، یعنی نگه‌داشتن یک مقصد بیرون تونل، خط‌مشی میان‌بری با شماره اولویت پایین‌تر بیفزایید تا بر ورودی نصب‌شده خودکار پیروز شود. خط‌مشی بدون الگو متن ساده را مجاز می‌کند، که آن را به استثنایی عامدانه برای سابقه تغییر بدل می‌کند نه گامی برای اشکال‌زدایی.
به این ترتیب بررسی کنید، و بدانید چگونه عقب‌نشینی کنید
خط‌مشی‌های هر زیرشبکه را در هر دو جهت فهرست کنید، از جمله ارسال اگر میزبان مسیریابی می‌کند. reqidهای متمایز را بشمارید و یکی برای هر خط‌مشی در سمت انتظار تأیید کنید. انتخاب‌گرهای نصب‌شده را با مذاکره‌شده‌ها مقایسه کنید. پس از نوسازی کلید شمارنده‌های هر انجمن را دوباره بخوانید، چون انجمنی که بررسی کردید ممکن است رفته باشد. مسیرها را آخر بررسی کنید، چون مسیر گم‌شده به زیرشبکه دور نشانه یک‌طرفه مشابهی با شمارنده‌های خط‌مشی پاک تولید می‌کند.
پیش از تغییر همتا، خروجی کنونی هر دو فرمان xfrm را ذخیره کنید. اگر تنظیم جدید جهت برگشت را بازنگرداند، بازگرداندن آن خروجی عقب‌نشینی سریع‌تری از بازسازی تونل از حافظه است، و مقایسه را صادق نگه می‌دارد.