چه چیزی در یک پیشنهاد IPsec می‌گنجد؟ فیلدهای IKE و ESP
یک پیشنهاد یک عرضه کامل است، نه کیسه‌ای از الگوریتم‌ها. ببینید کدام فیلدها به IKE تعلق دارند و کدام به ESP، و چرا یک ناسازگاری کل مجموعه را رد می‌کند.
IKE آغاز می‌شود، هر دو همتا AES را اعلام می‌کنند، و تونل همچنان با NO_PROPOSAL_CHOSEN شکست می‌خورد. گزارش نام پیشنهاد را می‌آورد اما فیلدی را که تطبیق نیافته ذکر نمی‌کند. یک پیشنهاد یک عرضه کامل است، و یک فیلد ناسازگار کل ترکیب را باطل می‌کند نه فقط همان خط. خواندن آن به‌عنوان کیسه‌ای از انتخاب‌های مستقل الگوریتمی دلیل معمول نامرئی ماندن این ناسازگاری است.
دو مذاکره با فهرست‌های پیشنهاد جداگانه
IKEv2 دو انجمن امنیتی می‌سازد. اولی IKE SA است که خود تبادل کنترل را محافظت می‌کند، و دومی CHILD SA است که ترافیک شما را از طریق ESP حمل می‌کند. هرکدام فهرست پیشنهاد خود را دارند، و همتا می‌تواند یکی را بپذیرد و دیگری را رد کند.
این جداسازی یک سردرگمی رایج را توضیح می‌دهد: IKE SA سالم تنها ثابت می‌کند که الگوریتم‌های کانال کنترل تطبیق یافته‌اند. اگر پیشنهاد CHILD شکست بخورد، تونل حتی یک بسته را حمل نمی‌کند، هرچند فاز اول کامل شده و گزارش‌ها در بالا سالم به نظر می‌رسند.
ترتیب داخل هر فهرست هم مهم است. پاسخ‌دهنده از میان عرضه‌های مرتب آغازکننده انتخاب می‌کند، بنابراین جابه‌جا کردن یک ورودی گسترده‌سازگار به بالای یک ورودی باریک، مجموعه‌ای را که نصب می‌شود تغییر می‌دهد بدون آنکه نام هیچ الگوریتمی تغییر کند. این ترتیب را در پیکربندی تثبیت کنید نه اینکه به پیش‌فرض‌ها تکیه کنید. ترتیب پایدار مقایسه گزارش‌ها میان سایت‌ها را نیز معنادار می‌کند.
کدام فیلدها به کدام پیشنهاد تعلق دارند
مجموعه فیلدها کوچک است، اما در دو مذاکره یکسان نیست. جدول را سطر به سطر بخوانید، چون فیلدی در یک ستون ممکن است در ستون دیگر نباشد. نحو بسته به پیاده‌سازی متفاوت است؛ مستندات پیشنهادهای strongSwan یک مرجع مشخص است.
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
فیلد رمزنگاری نام رمز و در بیشتر نحوها طول کلید آن را می‌آورد. فیلد یکپارچگی نام هشی را می‌آورد که برای احراز متن رمزشده استفاده می‌شود، و PRF نام تابعی را می‌آورد که مواد کلید را برای IKE SA استخراج می‌کند. گروه DH مواد سری مشترک تازه ایجاد می‌کند، و به همین دلیل در هر دو سمت ظاهر می‌شود اما با اهداف متفاوت.
شماره‌های ترتیب گسترده فقط به مسیر داده تعلق دارند. آن‌ها فضای ترتیب را گسترش می‌دهند و به‌عنوان بخشی از پیشنهاد CHILD مذاکره می‌شوند، بنابراین ناسازگاری در آنجا یک عرضه CHILD را رد می‌کند و IKE SA دست‌نخورده می‌ماند.
چگونه یک عرضه کامل انتخاب می‌شود
هر پیشنهاد یک مجموعه است، و پاسخ‌دهنده مجموعه‌ای را می‌جوید که در آن هر فیلد لازم قابل قبول باشد. دو فهرست می‌توانند هر دو AES و SHA-256 داشته باشند و باز هیچ ورودی سازگاری نداشته باشند، چون طول کلید، PRF یا گروه DH متفاوت است. مقایسه برای هر پیشنهاد انجام می‌شود، نه برای هر الگوریتم.
وقتی هیچ چیز تطبیق نمی‌یابد، پاسخ‌دهنده NO_PROPOSAL_CHOSEN را با نوع SA که شکست خورده می‌فرستد. پیش از ویرایش پیکربندی بخوانید که این اعلان به کدام فهرست پیشنهاد اشاره دارد؛ تغییر الگوریتم‌های ESP وقتی پیشنهاد IKE رد شده، یک چرخه عیب‌یابی را هدر می‌دهد.
دانستن رفتار انتخاب هنگام تنظیم یک نمایه ارزشمند است. برخی پیاده‌سازی‌ها ترتیب آغازکننده را ترجیح می‌دهند، برخی دیگر بر اساس سیاست محلی بازمرتب می‌کنند، بنابراین مجموعه‌ای که میان دو فروشنده کار می‌کند می‌تواند ناپدید شود وقتی جای طرفی را که اتصال را آغاز می‌کند عوض کنید.
AEAD یک فیلد را حذف می‌کند نه اینکه یکی اضافه کند
AES-GCM و ChaCha20-Poly1305 در یک عملیات احراز و رمزنگاری می‌کنند. وقتی هرکدام برای ESP انتخاب شود، الگوریتم یکپارچگی به‌طور جداگانه مذاکره نمی‌شود، چون ساختار AEAD از قبل آن را پوشش می‌دهد. از این رو پیشنهادی که AES-GCM را با SHA-256 جفت می‌کند دست‌کم زائد و در بدترین حالت رد شده است.
PRF در سمت IKE همچنان جداگانه است، چون کلیدها را برای کانال کنترل استخراج می‌کند نه برای محافظت از بارهای مفید. به همین دلیل یک پیشنهاد IKE می‌تواند به‌طور مشروع یک رمز AEAD را با PRF و گروه DH ترکیب کند، در حالی که پیشنهاد ESP متناظر تنها رمز AEAD و گروه اختیاری PFS را فهرست می‌کند.
طول کلید بخشی از توکن رمزنگاری است، بنابراین AES-128-GCM و AES-256-GCM دو عرضه متفاوت‌اند. نمایه‌ای که از راهنمایی با فرض کلیدهای 256-bit کپی شده با نقطه پایانی که برای 128-bit پیکربندی شده تطبیق نمی‌یابد، حتی اگر هر دو خط AES-GCM بگویند. دو همتا می‌توانند درباره خانواده رمز توافق کنند و باز به‌خاطر عدد پس از خط تیره یکدیگر را رد کنند.
SA نصب‌شده را بخوانید، نه پیکربندی را
فهرست پیشنهادهای پیکربندی‌شده یک عرضه است؛ SA نصب‌شده نتیجه است. در strongSwan و هسته Linux هر دو نما در دسترس است:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas الگوریتم‌های مذاکره‌شده را برای هر SA چاپ می‌کند، از جمله اینکه آیا CHILD از AEAD استفاده می‌کند. ip xfrm state نشان می‌دهد که هسته در واقع چه چیزی نصب کرده است ، و همان‌جاست که تأیید می‌کنید تمدید کلید به مجموعه‌ای متفاوت از آنچه مستند کرده‌اید بازنگشته است.
پس از رفع مشکل آن خروجی را کنار پیکربندی ذخیره کنید. وقتی به‌روزرسانی یک کلاینت پیش‌فرض‌هایش را تغییر می‌دهد، مجموعه ثبت‌شده خط پایه‌ای برای مقایسه به شما می‌دهد، و مقایسه به فیلدی اشاره می‌کند که جابه‌جا شده است، نه اینکه بررسی را از ابتدا آغاز کند.