رمزهای Windows و strongSwan: لایه درست را تطبیق دهید

هر دو طرف AES-128 می‌گویند و تونل هنوز از ساخته‌شدن سر باز می‌زند. CBC و GCM تبدیل‌های متفاوتی هستند که تصادفاً طول کلید یکسانی دارند، و کلاینتی که یکی را پیشنهاد می‌دهد دروازه‌ای را که فقط دیگری را می‌پذیرد راضی نمی‌کند. واژه AES یک خانواده را توصیف می‌کند، نه یک توافق.

محور دومی هم وجود دارد، و همان است که خطاهای گیج‌کننده را تولید می‌کند.

دو لایه، دو فهرست مستقل

IKE خودِ مذاکره را محافظت می‌کند، در حالی که ارتباط فرزند ترافیکی را که واقعاً برایتان مهم است محافظت می‌کند. Windows اولی را به‌صورت روش رمزنگاری و روش یکپارچگی، و دومی را به‌صورت ثابت‌های تبدیل رمز و احراز هویت ارائه می‌دهد. این فیلدها نام‌های مستعار یکدیگر نیستند، و مقداری که در یکی معتبر است می‌تواند در دیگری بی‌معنا یا نادرست باشد. خواندن پروفایل با این تفکیک در ذهن بیشتر سردرگمی را برمی‌دارد.

نتیجه عملی این است که می‌توانید سیاست تبادل کلید کاملاً قابل‌قبولی داشته باشید و سیاست کانال داده‌ای که همتا آن را نمی‌پذیرد. یک فهرست مذاکره می‌کند؛ دیگری بسته‌ها را محافظت می‌کند. تغییر یک مقدار در اولی هیچ اثری بر دومی ندارد، هرقدر هم که دو فهرست در یک پنجره پیکربندی شبیه هم به نظر برسند.

هر دو فهرست را پیش از مقایسه با دروازه بنویسید. مقایسه از روی حافظه همان روشی است که یک فیلد دو بار ویرایش می‌شود و دیگری هرگز. کنسول دروازه را کنار پروفایل باز نگه دارید.

خطا را کنار پیشنهادها بخوانید

مرحله‌ای که شکست خورده به شما می‌گوید کدام فهرست را بررسی کنید. رد شدن در طول تبادل کلید اولیه مشکل پیشنهاد IKE است، و پیش از وجود هر ارتباط فرزندی رخ می‌دهد. شکست در حالی که ارتباط ترافیک محافظت‌شده در حال مذاکره است مشکل پیشنهاد ESP است، و تبادل کلید از قبل موفق شده است. پیام عمومی تطابق سیاست از سوی کلاینت هیچ‌یک از دو مرحله را نام نمی‌برد، به همین دلیل دید خودِ دروازه دید مفید است.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

پیشنهاد دریافت‌شده، پیشنهاد پیکربندی‌شده و پیشنهاد انتخاب‌شده را مقایسه کنید برای همان تلاش واحد. سه فهرست متفاوت اینجا مهم‌اند، و فقط آخری توصیف می‌کند که واقعاً چه چیزی استفاده شده است. آن را در تیکت عیناً نقل کنید نه اینکه خلاصه‌اش کنید.

CBC و GCM را به‌عنوان گزینه‌های جداگانه نگه دارید

دروازه‌ای که عمداً اجازه دارد هر یک از دو خانواده را بپذیرد به دو پیشنهاد نیاز دارد، نه یکی. در strongSwan ویرگول گزینه‌ها را جدا می‌کند و خط تیره اجزای یک مجموعه را به هم می‌پیوندد. ترکیب هر دو خانواده با خط تیره یک پیشنهاد ناممکن تولید می‌کند نه دو پیشنهاد قابل‌قبول.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

گزینه اول رمزنگاری احرازشده دارد و هنوز یک تابع شبه‌تصادفی نام می‌برد، چون اشتقاق کلید حتی وقتی یکپارچگی از رمز می‌آید به یکی نیاز دارد. گزینه دوم رمزنگاری کلاسیک با الگوریتم یکپارچگی جداگانه است. هر دو همچنان تابع آن چیزی هستند که پیاده‌سازی رمزنگاری بارگذاری‌شده پشتیبانی می‌کند.

پیشنهاد ESP یک پیشنهاد IKE تغییرنام‌یافته نیست

نشانه رمز در هر دو فهرست یکسان به نظر می‌رسد، و تقریباً هیچ چیز دیگری منتقل نمی‌شود. پیشنهاد ESP هیچ تابع شبه‌تصادفی تبادل کلید ندارد، و الزامات یکپارچگی و رازداری رو به جلو آن در برابر سیاست Windows در طرف دیگر استدلال می‌شود نه اینکه از خط IKE کپی شود. ترجمه مکانیکی یک فهرست به فهرست دیگر چیزی تولید می‌کند که اعتبارسنجی می‌شود و هرگز مذاکره نمی‌کند.

یک جهت انتخاب کنید و در آن بمانید. یا دروازه سیاست فقط GCM را نگه می‌دارد و کلاینت سیاست سازگار کامل را مستقر می‌کند، یا دروازه هر دو خانواده را می‌پذیرد و کلاینت مجموعه موجود خود را نگه می‌دارد. فعال‌کردن گزینه‌ای که سیاست امنیتی ممنوع کرده راه‌حل نیست، هرقدر هم سریع خطا را پاک کند.

هر دو مجموعه را بررسی کنید، سپس یک نوسازی کلید

مجموعه تبادل کلید انتخاب‌شده و مجموعه ترافیک انتخاب‌شده را جداگانه تأیید کنید، چون از فهرست‌های متفاوتی می‌آیند و می‌توانند مستقلاً موفق شوند. سپس بگذارید نوسازی کلید رخ دهد و آن را هم تأیید کنید. اولین دست‌دادن که کار می‌کند و نوسازی کلیدی که شکست می‌خورد مجموعه‌ای از پیشنهادها را توصیف می‌کنند که فقط تا حدی قابل‌قبول است.

آن شواهد را همراه تغییر نگه دارید. قطع ارتباط تکرارشونده پیش از آنکه کسی تایمر یا نقص پلتفرم را سرزنش کند به سابقه شکست تبادل خودش نیاز دارد.