SWANCTL.CONF(5) strongSwan SWANCTL.CONF(5)

swanctl.conf - پرونده پیکربندی swanctl

swanctl.conf پرونده پیکربندی است که توسط ابزار swanctl(8) برای بارگذاری پیکربندی‌ها و اطلاعات هویتی و اعتبارسنجی در دیمن IKE مربوط به strongSwan به کار می‌رود.

برای شرح ساختار نحوی پایه پرونده، شامل قالب‌های اعداد/زمان، یا چگونگی ارجاع به بخش‌ها یا تقسیم پیکربندی به چند پرونده از طریق گنجاندن پرونده‌های دیگر، به strongswan.conf(5) مراجعه کنید.

تنظیمات زیر می‌توانند برای پیکربندی اتصالات، اطلاعات اعتبارسنجی و استخرها به کار روند.


بخشی که پیکربندی‌های اتصال IKE را تعریف می‌کند.

بخش connections پیکربندی‌های اتصال IKE را تعریف می‌کند، که هر یک در زیربخش‌های جداگانه خود قرار دارند. در شرح کلیدواژه‌های زیر، اتصال با نام <conn> مشخص شده است، اما می‌توان یک نام دلخواه اما یکتا برای زیربخش هر اتصال برگزید.


بخش مربوط به اتصال IKE با نام <conn>.
نسخه اصلی IKE برای استفاده در اتصال. مقدار 1 از IKEv1 (معروف به ISAKMP) استفاده می‌کند، مقدار 2 از IKEv2 (پیش‌فرض) بهره می‌برد. اتصالی با مقدار 0 به عنوان پاسخ‌دهنده (responder) هر دو نسخه IKEv1 و IKEv2 را می‌پذیرد، و اتصال را به طور فعال با IKEv2 آغاز می‌کند.
نشانی(های) محلی برای استفاده در ارتباطات IKE، جداشده با ویرگول. نشانی‌های تکی IPv4/IPv6، نام‌های DNS، زیرشبکه‌های CIDR یا محدوده‌های نشانی IP را می‌پذیرد.

به عنوان آغازگر (initiator)، نخستین نشانی که غیرمحدوده/غیرزیرشبکه باشد برای آغاز اتصال استفاده می‌شود. به عنوان پاسخ‌دهنده، نشانی مقصد محلی باید دست‌کم با یکی از نشانی‌ها، زیرشبکه‌ها یا محدوده‌های مشخص‌شده همخوانی داشته باشد.

اگر از FQDNها استفاده شود، هر بار که جستجوی پیکربندی انجام می‌گیرد تفکیک (resolve) می‌شوند. اگر تفکیک DNS با مهلت زمانی مواجه شود، جستجو به همان میزان به تأخیر می‌افتد.

نشانی(های) دوردست برای استفاده در ارتباطات IKE، جداشده با ویرگول. نشانی‌های تکی IPv4/IPv6، نام‌های DNS، زیرشبکه‌های CIDR یا محدوده‌های نشانی IP را می‌پذیرد.

به عنوان آغازگر، نخستین نشانی غیرمحدوده/غیرزیرشبکه برای آغاز اتصال به آن استفاده می‌شود. به عنوان پاسخ‌دهنده، نشانی مبدأ آغازگر باید دست‌کم با یکی از نشانی‌ها، زیرشبکه‌ها یا محدوده‌های مشخص‌شده همخوانی داشته باشد.

اگر از FQDNها استفاده شود، هر بار که جستجوی پیکربندی انجام می‌گیرد تفکیک می‌شوند. اگر تفکیک DNS با مهلت زمانی مواجه شود، جستجو به همان میزان به تأخیر می‌افتد.

برای آغاز اتصال، دست‌کم باید یک نشانی یا نام DNS مشخص تعیین شود.

درگاه محلی UDP برای ارتباطات IKE. به طور پیش‌فرض از درگاه backend سوکت استفاده می‌شود، که معمولاً 500 است. اگر از درگاه 500 استفاده شود، جابجایی خودکار درگاه IKE به درگاه 4500 برای حل مشکلات NAT به کار گرفته می‌شود.

استفاده از درگاه غیرپیش‌فرض IKE محلی مستلزم پشتیبانی از سوی backend سوکت مورد استفاده است (socket-dynamic).

درگاه دوردست UDP برای ارتباطات IKE. اگر از درگاه پیش‌فرض 500 استفاده شود، جابجایی خودکار درگاه IKE به درگاه 4500 برای حل مشکلات NAT انجام می‌گیرد.
یک پیشنهاد (proposal) مجموعه‌ای از الگوریتم‌ها است. برای پیشنهادهای غیـر-AEAD IKE، این شامل یک الگوریتم رمزنگاری، یک الگوریتم یکپارچگی، یک تابع شبه‌تصادفی و یک روش تبادل کلید است. برای پیشنهادهای AEAD، به جای الگوریتم‌های رمزنگاری و یکپارچگی، از یک الگوریتم حالت ترکیبی استفاده می‌شود.

با همتایانی که از تبادل کلید چندگانه IKEv2 پشتیبانی می‌کنند (RFC 9370)، تا هفت تبادل کلید اضافی می‌تواند مذاکره شود. آنها را می‌توان با افزودن پیشوند keX_ (که در آن X عددی بین 1 تا 7 است) به کلیدواژه الگوریتم پیکربندی کرد.

برای IKEv2، چند الگوریتم از یک نوع را می‌توان در یک پیشنهاد واحد مشخص کرد که یکی از آنها انتخاب می‌شود. برای IKEv1، تنها یک الگوریتم از هر نوع در هر پیشنهاد مجاز است؛ الگوریتم‌های بیشتر به طور ضمنی حذف می‌شوند. برای ارائه ترکیب‌های مختلف الگوریتمی در IKEv1 از چندین پیشنهاد استفاده کنید.

کلیدواژه‌های الگوریتم با خط فاصله (-) جدا می‌شوند. چندین پیشنهاد ممکن است با ویرگول از هم جدا شوند. مقدار ویژه default یک پیشنهاد پیش‌فرض از الگوریتم‌های پشتیبانی‌شده و ایمن را تشکیل می‌دهد، و معمولاً انتخاب خوبی برای سازگاری متقابل است.

فهرست جداشده با ویرگول از IPهای مجازی برای درخواست در محموله‌های پیکربندی IKEv2 یا Mode Config در IKEv1. نشانی‌های عام (wildcard) 0.0.0.0 و :: یک نشانی دلخواه را درخواست می‌کنند؛ نشانی‌های مشخص نیز قابل تعریف هستند. هرچند ممکن است پاسخ‌دهنده نشانی دیگری را برگرداند، یا اصلاً هیچ نشانی‌ای بازنگرداند.
حالت تهاجمی (Aggressive Mode) را به جای حالت اصلی با حفاظت هویت (Main Mode with Identity Protection) فعال می‌کند. حالت تهاجمی کمتر ایمن دانسته می‌شود، زیرا محموله‌های ID و HASH بدون محافظت تبادل می‌شوند. این امر به یک مهاجم غیرفعال امکان می‌دهد هویت‌های همتا را استراق سمع کند، و بدتر از آن، حملات لغت‌نامه‌ای را علیه کلید از پیش اشتراک‌گذاشته‌شده (PSK) آغاز کند.
اگر مقدار پیش‌فرض yes استفاده شود، Mode Config در حالت کششی (pull mode) عمل می‌کند، که در آن آغازگر به صورت فعال IP مجازی را درخواست می‌کند. با مقدار no، حالت رانشی (push mode) استفاده می‌شود، که در آن پاسخ‌دهنده IP مجازی را به همتای آغازگر ارسال می‌کند.

حالت رانشی در حال حاضر برای IKEv1 پشتیبانی می‌شود، اما در IKEv2 پشتیبانی نمی‌شود. این حالت تنها توسط تعداد معدودی از پیاده‌سازی‌ها استفاده می‌شود؛ حالت کششی توصیه می‌شود.

مقدار فیلد نقطه کد خدمات تفکیک‌شده (DSCP) برای تنظیم روی بسته‌های خروجی IKE برای این اتصال. مقدار یک رشته شش رقمی با کدگذاری دودویی است که نقطه کد مورد نظر را مشخص می‌کند، همان‌گونه که در RFC 2474 تعریف شده است.
برای اجبار کپسوله‌سازی UDP بسته‌های ESP، دیمن IKE می‌تواند محموله‌های تشخیص NAT را جعل کند. این امر باعث می‌شود همتا تصور کند NAT در مسیر رخ داده است، و آن را مجبور می‌کند بسته‌های ESP را در UDP کپسوله‌سازی کند.

معمولاً این امر الزامی نیست، اما می‌تواند به رفع مشکلات اتصال در حضور دیواره‌های آتش میانی بیش از حد سخت‌گیر کمک کند.

پروتکل MOBIKE را در اتصالات IKEv2 فعال می‌کند. پروتکل MOBIKE به طور پیش‌فرض در اتصالات IKEv2 فعال است و امکان جابجایی کلاینت‌ها و چندمسیری (multi-homing) در کارسازها را با مهاجرت تونل‌های فعال IPsec فراهم می‌سازد.

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

بازه زمانی برای بررسی فعال زنده‌بودن همتا با استفاده از تبادلات INFORMATIONAL در IKEv2 یا پیام‌های R_U_THERE در IKEv1. بررسی فعال DPD تنها زمانی اجبار می‌شود که هیچ بسته IKE یا ESP/AH برای مدت زمان تأخیر DPD پیکربندی‌شده دریافت نشده باشد.
دیمن charon به طور پیش‌فرض از سازوکار بازtransmissions معمولی و مهلت‌های زمانی برای بررسی زنده‌بودن همتا استفاده می‌کند، زیرا همه پیام‌ها برای بررسی زنده‌بودن به کار می‌روند. به دلایل سازگاری، در IKEv1 می‌توان بازه زمانی سفارشی مشخص کرد؛ این گزینه تأثیری بر اتصالات IKEv2 ندارد.
استفاده از تکه‌تکه‌سازی (fragmentation) پیام‌های IKE (افزونه اختصاصی IKEv1 یا تکه‌تکه‌سازی RFC 7383 در IKEv2). مقادیر مجاز عبارتند از yes (پیش‌فرض)، accept، force و no. اگر روی yes تنظیم شود و همتا از آن پشتیبانی کند، پیام‌های بیش از حد بزرگ IKE در قطعات تکه‌تکه ارسال می‌شوند. اگر روی accept تنظیم شود، پشتیبانی از تکه‌تکه‌سازی به همتا اعلام می‌شود اما دیمن پیام‌های خودش را تکه‌تکه نمی‌کند. اگر روی force تنظیم شود (تنها در IKEv1 پشتیبانی می‌شود)، نخستین پیام IKE نیز در صورت نیاز تکه‌تکه خواهد شد. سرانجام، تنظیم گزینه روی no اعلام پشتیبانی از این ویژگی را غیرفعال می‌کند.

توجه داشته باشید که پیام‌های تکه‌تکه‌شده IKE ارسالی توسط همتا، صرف‌نظر از مقدار این گزینه همواره پذیرفته می‌شوند (حتی در صورت تنظیم روی no).

استفاده از آغازش IKE_SA بدون فرزند (childless) بر اساس RFC 6023 برای IKEv2، به طوری که نخستین CHILD_SA با یک تبادل جداگانه CREATE_CHILD_SA ایجاد شود (برای نمونه برای استفاده از تبادل کلید مستقل برای همه CHILD_SAها). مقادیر مجاز عبارتند از allow (پیش‌فرض)، prefer، force و never. اگر روی allow تنظیم شود، پاسخ‌دهندگان IKE_SAهای بدون فرزند را می‌پذیرند (همان‌گونه که از طریق اعلان در پاسخ IKE_SA_INIT مشخص می‌شود)، در حالی که آغازگران همچنان به ایجاد IKE_SAهای عادی با نخستین CHILD_SA ایجادشده در طول IKE_AUTH ادامه می‌دهند، مگر اینکه IKE_SA صراحتاً بدون هیچ فرزندی آغاز شود (که در صورت عدم پشتیبانی یا غیرفعال بودن این افزونه در پاسخ‌دهنده، ناموفق خواهد بود). تأثیر prefer در نقش پاسخ‌دهنده مانند allow است، اما در نقش آغازگر، چنانچه پاسخ‌دهنده پشتیبانی کند، یک IKE_SA بدون فرزند آغاز خواهد شد. اگر روی force تنظیم شود، تنها آغازش بدون فرزند در هر دو نقش پذیرفته می‌شود. در پایان، تنظیم گزینه روی never پشتیبانی از IKE_SAهای بدون فرزند را در نقش پاسخ‌دهنده غیرفعال می‌کند.
ارسال محموله‌های درخواست گواهی (certificate request) برای ارائه گواهی‌های ریشه CA معتمد به همتا. درخواست‌های گواهی به همتا کمک می‌کنند گواهی/کلید خصوصی مناسب را برای احراز اصالت برگزیند و به طور پیش‌فرض فعال است.

غیرفعال‌سازی درخواست‌های گواهی می‌تواند زمانی سودمند باشد که تعداد زیادی گواهی ریشه CA معتمد نصب شده باشد، چرا که هر درخواست گواهی اندازه بسته‌های اولیه IKE را افزایش می‌دهد.

ارسال محموله‌های گواهی هنگام استفاده از احراز اصالت مبتنی بر گواهی. با مقدار پیش‌فرض ifasked دیمن محموله‌های گواهی را تنها در صورتی ارسال می‌کند که درخواست گواهی دریافت شده باشد. مقدار never ارسال محموله‌های گواهی را به کلی غیرفعال می‌کند؛ مقدار always باعث می‌شود هر زمان که احراز اصالت مبتنی بر گواهی استفاده شود، محموله‌های گواهی بدون قید و شرط ارسال شوند.
ارسال درخواست‌های وضعیت OCSP در محموله‌های درخواست گواهی و/یا ارسال پاسخ وضعیت OCSP در محموله‌های گواهی هنگام استفاده از احراز اصالت مبتنی بر گواهی. با مقدار پیش‌فرض reply دیمن در صورتی که درخواست وضعیت OCSP در یک درخواست گواهی دریافت شده باشد، پاسخ وضعیت OCSP را در محموله‌های گواهی ارسال می‌کند. مقدار never ارسال درخواست‌ها و پاسخ‌های وضعیت OCSP را به کلی غیرفعال می‌کند؛ مقدار request باعث می‌شود هر زمان که احراز اصالت مبتنی بر گواهی به کار رود، درخواست‌های وضعیت OCSP در محموله‌های درخواست گواهی ارسال شوند؛ مقدار both هر دو حالت reply و request را با هم ترکیب می‌کند.
رشته‌ای که کلید از پیش اشتراک‌گذاشته‌شده پساکوانتومی (PPK) مورد استفاده را مشخص می‌کند.
مشخص می‌کند که آیا کلید از پیش اشتراک‌گذاشته‌شده پساکوانتومی (PPK) برای این اتصال الزامی است یا خیر.
تعداد توالی‌های ارسال مجدد برای انجام در طول اتصال اولیه. به جای انصراف از آغازش پس از نخستین توالی ارسال مجدد با مقدار پیش‌فرض 1، می‌توان توالی‌های بیشتری را بر اساس مقدار پیکربندی‌شده آغاز کرد. مقدار 0 یک توالی جدید را تا زمان برقراری اتصال یا مواجهه با خطای دائمی تکرار می‌کند.
سیاست یکتایی اتصال برای اعمال. به منظور جلوگیری از اتصالات چندگانه توسط یک کاربر، می‌توان سیاست یکتایی را اعمال کرد. مقدار never هرگز چنین سیاستی را اعمال نمی‌کند، حتی اگر همتا پیام‌های اعلان INITIAL_CONTACT را ارسال کرده باشد، در حالی که مقدار no در صورت وجود اعلان INITIAL_CONTACT در اتصال جدید، اتصالات موجود برای همان هویت را جایگزین می‌کند. مقدار keep در صورتی که همان کاربر اتصال فعالی داشته باشد، تلاش‌های جدید برای برقراری اتصال را رد می‌کند، و مقدار replace در صورت برقراری اتصال جدید برای همان کاربر، هر اتصال موجود را حذف می‌کند.

برای مقایسه اتصالات از نظر یکتایی، از هویت IKE راه دور استفاده می‌شود. در صورت درگیر بودن احراز اصالت EAP یا XAuth، به جای آن از EAP-Identity یا نام کاربری XAuth برای اعمال سیاست یکتایی بهره گرفته می‌شود.

در آغازگران، این تنظیم مشخص می‌کند که آیا در طول IKE_AUTH در صورتی که اتصال موجودی با همتای دوردست یافت نشود (که توسط هویت‌های دور نخست احراز اصالت تعیین می‌شود)، اعلان INITIAL_CONTACT ارسال شود یا خیر. مگر اینکه روی never تنظیم شده باشد، کلاینت اعلان را ارسال خواهد کرد.

زمان زمان‌بندی احراز اصالت مجدد IKE. احراز اصالت مجدد IKE پیمان امنیتی IKE/ISAKMP SA را از ابتدا بازسازی کرده و اطلاعات اعتبارسنجی را دوباره ارزیابی می‌کند. در پیکربندی‌های نامتقارن (با EAP یا محموله‌های پیکربندی) ممکن است امکان احراز اصالت مجدد فعال به عنوان پاسخ‌دهنده وجود نداشته باشد. مذاکره طول عمر احراز اصالت مجدد در IKEv2 می‌تواند به کلاینت دستور دهد احراز اصالت مجدد را انجام دهد.

احراز اصالت مجدد به طور پیش‌فرض غیرفعال است. فعال‌سازی آن معمولاً می‌تواند به وقفه‌های کوتاه‌مدت در اتصال منجر شود، حتی در صورت استفاده از رویکرد پیش‌فرض کنونی یعنی make-before-break (ایجاد پیش از قطع). هرچند، این وقفه‌ها به مراتب کوتاه‌تر از رویکرد قدیمی break-before-make (قطع پیش از ایجاد) هستند.

کلیدگذاری مجدد (rekeying) IKE مواد کلید را با استفاده از تبادل دیفی-هلمن تازه می‌کند، اما اطلاعات اعتبارسنجی مرتبط را دوباره بررسی نمی‌کند. این ویژگی تنها در IKEv2 پشتیبانی می‌شود؛ IKEv1 در عوض فرآیند احراز اصالت مجدد را اجرا می‌کند.

با مقدار پیش‌فرض، کلیدگذاری مجدد IKE هر ۴ ساعت زمان‌بندی می‌شود، منهای مقدار پیکربندی‌شده در rand_time. اگر reauth_time پیکربندی شده باشد، مقدار پیش‌فرض rekey_time صفر خواهد بود که کلیدگذاری مجدد را غیرفعال می‌کند؛ برای اعمال هر دو مورد کلیدگذاری مجدد و احراز اصالت مجدد، هر دو را صراحتاً مقداردهی کنید.

طول عمر سخت IKE_SA در صورت عدم تکمیل کلیدگذاری مجدد/احراز اصالت مجدد، به صورت زمان. برای جلوگیری از زنده ماندن IKE/ISAKMP در شرایطی که احراز اصالت مجدد یا کلیدگذاری مجدد به طور مداوم با شکست مواجه می‌شود، می‌توان یک طول عمر سخت بیشینه مشخص کرد. اگر IKE_SA نتواند ظرف زمان تعیین‌شده عملیات را به پایان برساند، IKE_SA بسته می‌شود.

برخلاف کلیدگذاری مجدد CHILD_SA، گزینه over_time نسبت به مقادیر rekey_time و reauth_time سنجیده می‌شود، چرا که بر هر دو اعمال می‌گردد.

مقدار پیش‌فرض ۱۰ درصد از مقدار بزرگ‌تر میان rekey_time و reauth_time است.

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

مقدار پیش‌فرض برابر با مقدار پیکربندی‌شده در over_time است.

فهرست جداشده با ویرگول از استخرهای IP نام‌گذاری‌شده برای تخصیص نشانی‌های IP مجازی و سایر ویژگی‌های پیکربندی. هر نام به استخری در بخش pools یا یک استخر خارجی ارجاع می‌دهد.
شناسه رابط XFRM تنظیم‌شده روی سیاست‌ها/SAهای ورودی، که می‌تواند توسط پیکربندی فرزند لغو شود؛ برای جزئیات به آن بخش مراجعه کنید.

مقدار ویژه %unique یک شناسه رابط یکتا به ازای هر IKE_SA تخصیص می‌دهد که توسط تمام CHILD_SAهای آن به ارث برده می‌شود (مگر اینکه در آنجا لغو شده باشد)؛ افزون بر آن مقدار %unique-dir یک شناسه رابط یکتای متفاوت برای هر جهت (ورودی/خروجی) تخصیص می‌دهد.

شناسه رابط XFRM تنظیم‌شده روی سیاست‌ها/SAهای خروجی، که می‌تواند توسط پیکربندی فرزند لغو شود؛ برای جزئیات به آن بخش مراجعه کنید.

مقدار ویژه %unique یک شناسه رابط یکتا به ازای هر IKE_SA تخصیص می‌دهد که توسط تمام CHILD_SAهای آن به ارث برده می‌شود (مگر اینکه در آنجا لغو شده باشد)؛ افزون بر آن مقدار %unique-dir یک شناسه رابط یکتای متفاوت برای هر جهت (ورودی/خروجی) تخصیص می‌دهد.

مشخص می‌کند که آیا این اتصال یک اتصال میانجی (mediation) است یا خیر؛ یعنی آیا این اتصال برای میانجی‌گری سایر اتصالات با استفاده از افزونه میانجی‌گری IKEv2 به کار می‌رود. اتصالات میانجی هیچ CHILD_SAای ایجاد نمی‌کنند.
نام اتصالی که این اتصال از طریق آن میانجی‌گری می‌شود. در صورت تعیین، اتصال از طریق اتصال میانجی نام‌برده میانجی‌گری خواهد شد. اتصال میانجی باید گزینه mediation فعال داشته باشد.
هویتی که همتا با آن در کارساز میانجی ثبت شده است؛ یعنی هویت IKE که طرف دیگر این اتصال به عنوان هویت محلی خود در اتصال به کارساز میانجی استفاده می‌کند. این هویتی است که ما از کارساز میانجی درخواست می‌کنیم ما را با آن میانجی‌گری کند. تنها در اتصالاتی مرتبط است که mediated_by را تنظیم کرده باشند. در صورت عدم تعیین، از هویت دوردست IKE در نخستین دور احراز اصالت این اتصال استفاده خواهد شد.

بخش مربوط به یک دور احراز اصالت محلی. یک دور احراز اصالت محلی قوانینی را تعریف می‌کند که بر اساس آن احراز اصالت برای همتای محلی انجام می‌شود. می‌توان چندین دور برای استفاده از احراز اصالت چندگانه RFC 4739 در IKEv2 یا XAuth در IKEv1 تعریف کرد.

هر دور در بخشی با پیشوند local و یک پسوند یکتای اختیاری تعریف می‌شود. برای تعریف یک دور احراز اصالت تکی، می‌توان از پسوند صرف‌نظر کرد.

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

گواهی مورد استفاده برای احراز اصالت بر اساس محموله‌های درخواست گواهی دریافت شده انتخاب می‌شود. در صورتی که هیچ مرجع صدور گواهی (CA) مناسبی پیدا نشود، نخستین گواهی استفاده می‌شود.

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

در هر بخش، یا این گزینه یا handle را پیکربندی کنید، نه هر دو را.

شناسه هگزادسیمال CKA_ID گواهی روی یک توکن امنیتی.

در هر بخش، یا این گزینه یا file را پیکربندی کنید، نه هر دو را.

شماره اسلات اختیاری توکنی که گواهی را ذخیره می‌کند.
نام ماژول اختیاری PKCS#11.
فهرست جداشده با ویرگول از نامزدهای کلید عمومی خام برای استفاده در احراز اصالت. کلیدهای عمومی می‌توانند از یک مسیر نسبی از شاخه swanctl pubkey یا یک مسیر مطلق استفاده کنند.

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

احراز اصالتی که باید به صورت محلی انجام گیرد. مقدار pubkey از احراز اصالت کلید عمومی با استفاده از یک کلید خصوصی مرتبط با یک گواهی معتبر استفاده می‌کند. مقدار psk از احراز اصالت با کلید از پیش اشتراک‌گذاشته‌شده بهره می‌برد. کلیدواژه xauth مخصوص IKEv1 برای احراز اصالت XAuth یا Hybrid استفاده می‌شود، در حالی که کلیدواژه eap مخصوص IKEv2 احراز اصالت EAP را تعریف می‌کند.

برای xauth، می‌توان یک نام backend خاص را با یک خط فاصله پیوست کرد. backend مناسب xauth برای اجرای تبادل XAuth انتخاب می‌شود. برای XAuth سنتی، روش xauth معمولاً در دومین دور احراز اصالت پس از دور اولیه pubkey (یا psk) تعریف می‌شود. استفاده از xauth در دور نخست، احراز اصالت کلاینت در حالت Hybrid را انجام می‌دهد.

برای eap، می‌توان یک نام روش EAP خاص را با یک خط فاصله پیوست کرد. یک ماژول EAP که روش مناسب را پیاده‌سازی کرده است برای انجام مکالمه EAP انتخاب می‌شود.

چنانچه هر دو همتا از RFC 7427 ("احراز اصالت امضا در IKEv2") پشتیبانی کنند، می‌توان الگوریتم‌های هش مشخصی را برای استفاده در طول احراز اصالت IKEv2 پیکربندی کرد. برای این منظور از ike: به همراه محدودیت طرح امضای زنجیره اعتماد استفاده کنید (شرح کلیدواژه auth در بخش remote را ببینید). برای نمونه، با ike:pubkey-sha384-sha256 یک طرح امضای کلید عمومی با SHA-384 یا SHA-256 برای احراز اصالت به کار می‌رود، به همان ترتیب و بسته به الگوریتم‌های هش پشتیبانی‌شده توسط همتا. اگر هیچ الگوریتم هش مشخصی پیکربندی نشود، پیش‌فرض ترجیح الگوریتمی است که با استحکام کلید امضا برابری کند یا از آن فراتر رود. اگر هیچ محدودیتی با پیشوند ike: پیکربندی نشود، هر محدودیت طرح امضا (بدون پیشوند ike:) بر احراز اصالت IKEv2 نیز اعمال خواهد شد، مگر اینکه در strongswan.conf(5) غیرفعال شده باشد. برای استفاده از امضاهای RSASSA-PSS، از rsa/pss به جای pubkey یا rsa استفاده کنید، مانند ike:rsa/pss-sha256. اگر محدودیت‌های pubkey یا rsa پیکربندی شده باشند، امضاهای RSASSA-PSS تنها در صورتی استفاده می‌شوند که در strongswan.conf(5) فعال شده باشند.

هویت IKE برای استفاده در دور احراز اصالت. هنگام استفاده از احراز اصالت مبتنی بر گواهی، هویت IKE باید در گواهی، یا به عنوان subject یا به عنوان subjectAltName موجود باشد.

هویت می‌تواند یک نشانی IP، یک نام دامنه کاملاً واجد شرایط (FQDN)، یک نشانی رایانامه یا یک نام متمایز (DN) باشد که نوع شناسه به طور خودکار تعیین شده و رشته به کدگذاری مناسب تبدیل می‌شود. برای اجبار یک نوع شناسه خاص، می‌توان از یک پیشوند و به دنبال آن دو نقطه (:) استفاده کرد. اگر نماد هش (#) پس از دو نقطه بیاید، داده‌های باقیمانده به عنوان کدگذاری هگز تفسیر می‌شوند، در غیر این صورت رشته دقیقاً همان‌گونه که هست به عنوان داده‌های شناسایی به کار می‌رود. توجه داشته باشید که این به این معنی است که هیچ تبدیلی برای هویت‌های غیررشته‌ای انجام نمی‌گیرد. برای نمونه، ipv4:10.0.0.1 یک هویت معتبر ID_IPV4_ADDR در IKE ایجاد نمی‌کند، زیرا به مقدار باینری 0x0a000001 تبدیل نمی‌شود. در عوض می‌توان از ipv4:#0a000001 برای داشتن یک هویت معتبر استفاده کرد، اما استفاده از نوع ضمنی با تبدیل خودکار معمولاً ساده‌تر است. همین امر در مورد انواع کدگذاری‌شده با ASN1 نیز صدق می‌کند. پیشوندهای شناخته‌شده عبارتند از: ipv4، ipv6، rfc822، email، userfqdn، fqdn، dns، asn1dn، asn1gn و keyid. پیشوندهای سفارشی را می‌توان با قرار دادن مقدار عددی نوع درون آکولاد مشخص کرد.

هویت EAP-Identity کلاینت برای استفاده در تبادل EAP-Identity و روش EAP.
هویت EAP-Identity سمت کارساز که در روش EAP انتظار می‌رود. برخی از روش‌های EAP، مانند EAP-TLS، از یک هویت برای کارساز جهت انجام احراز اصالت متقابل استفاده می‌کنند. این هویت ممکن است با هویت IKE متفاوت باشد، به‌ویژه زمانی که احراز اصالت EAP از پاسخ‌دهنده IKE به یک backend اختصاصی AAA واگذار شده باشد.

برای EAP-(T)TLS، این هویت مشخص می‌کند که کارساز برای چه هویتی باید در تبادل TLS گواهی ارائه دهد.

نام کاربری XAuth کلاینت که در تبادل XAuth استفاده می‌شود.

بخش مربوط به یک دور احراز اصالت دوردست. یک دور احراز اصالت دوردست، محدودیت‌های نحوه احراز اصالت همتایان را برای استفاده از این اتصال تعریف می‌کند. چندین دور می‌تواند برای استفاده از احراز اصالت چندگانه RFC 4739 در IKEv2 یا XAuth در IKEv1 تعریف شود.

هر دور در بخشی با پیشوند remote و یک پسوند یکتای اختیاری تعریف می‌شود. برای تعریف یک دور احراز اصالت تکی، می‌توان از پسوند صرف‌نظر کرد.

شناسه عددی اختیاری که دورهای احراز اصالت بر اساس آن مرتب می‌شوند. در صورت عدم تعیین، دورها بر اساس موقعیت قرارگیری‌شان در پرونده پیکربندی یا پیام VICI مرتب می‌شوند.
هویت IKE که برای این دور احراز اصالت انتظار می‌رود. برای جزئیات به شرح کلیدواژه id در بخش local مراجعه کنید.

امکان استفاده از نویسه‌های عمومی (wildcard) برای تطبیق هویت‌های دوردست وجود دارد (مانند *@strongswan.org، *.strongswan.org، یا C=CH,O=strongSwan,CN=*). اتصالاتی با تطابق دقیق اولویت دارند. هنگام استفاده از نام‌های متمایز با نویسه‌های عمومی، گزینه charon.rdn_matching در strongswan.conf(5) چگونگی تطبیق RDNها را مشخص می‌کند.

عبارات باقاعده گسترده POSIX نیز برای تطبیق هویت‌های دوردست پشتیبانی می‌شوند. آنها باید با یک پیشوند نوع صریح آغاز شوند، به دنبال آن نویسه توان ('^') بیاید، و با علامت دلار ('$') پایان یابند تا یک الگوی لنگردار را نشان دهند. هنگام پیکربندی هویت‌ها درون علامت نقل‌قول دوتایی، حتماً نویسه‌های بک‌اسلش را فرار دهید (escape کنید). انواع پشتیبانی‌شده عبارتند از rfc822، email، userfqdn، fqdn، dns، و asn1dn. اگرچه عبارات باقاعده همیشه با نمایش رشته‌ای سایر هویت‌ها تطبیق داده می‌شوند، نوع هویت نیز باید مطابقت داشته باشد. تطبیق بدون حساسیت به بزرگی و کوچکی حروف انجام می‌شود. نمونه‌ها: email:^(moon|sun)@strongswan\.org$، fqdn:^vpn[0-9]+\.strongswan\.org$، "asn1dn:^.*CN=.+\\.strongswan\\.org$".

استفاده از روش EAP-Identity برای درخواست هویت از کلاینت جهت تطبیق و استفاده در طول احراز اصالت EAP. در حال حاضر مفهومی به عنوان "بهترین" تطبیق وجود ندارد، پیکربندی‌ها به ترتیبی که بارگذاری می‌شوند تطبیق داده می‌شوند.

نویسه‌های عمومی و عبارات باقاعده پشتیبانی می‌شوند؛ برای جزئیات به کلیدواژه id مراجعه کنید.

فهرست جداشده با ویرگول از عضویت‌های گروهی مجوزدهی مورد نیاز. همتا باید عضویت در دست‌کم یکی از گروه‌های مشخص‌شده را اثبات کند. عضویت در گروه می‌تواند با روش‌های گوناگونی تأیید شود، برای نمونه با گواهی‌های ویژگی (Attribute Certificates) مناسب یا از طریق یک backend مربوط به AAA که در احراز اصالت درگیر است.
فهرست جداشده با ویرگول از OIDهای سیاست گواهی که گواهی همتا باید دارا باشد. OIDها با استفاده از نمایش عددی نقطه‌دار مشخص می‌شوند.
فهرست جداشده با ویرگول از گواهی‌ها برای پذیرش در احراز اصالت. گواهی‌ها می‌توانند از یک مسیر نسبی از شاخه swanctl x509 یا یک مسیر مطلق استفاده کنند.
بخش مربوط به یک گواهی جهت پذیرش در احراز اصالت. گواهی‌ها در certs به صورت داده‌های دودویی خام ارسال می‌شوند؛ این بخش‌ها انعطاف‌پذیری بیشتری را ارائه می‌دهند.
مسیر مطلق گواهی برای بارگذاری. به همان صورت به دیمن ارسال می‌شود، بنابراین باید برای دیمن خواندنی باشد.

در هر بخش، یا این گزینه یا handle را پیکربندی کنید، نه هر دو را.

شناسه هگزادسیمال CKA_ID گواهی روی یک توکن سخت‌افزاری/امنیتی.

در هر بخش، یا این گزینه یا file را پیکربندی کنید، نه هر دو را.

شماره اسلات اختیاری توکنی که گواهی را ذخیره می‌کند.
نام اختیاری ماژول PKCS#11.
فهرست جداشده با ویرگول از گواهی‌های CA جهت پذیرش در احراز اصالت. گواهی‌ها می‌توانند از یک مسیر نسبی از شاخه swanctl x509ca یا یک مسیر مطلق استفاده کنند.
بخش مربوط به یک گواهی CA جهت پذیرش در احراز اصالت. گواهی‌ها در cacerts به صورت داده‌های دودویی خام ارسال می‌شوند؛ این بخش‌ها انعطاف‌پذیری بیشتری را ارائه می‌دهند.
مسیر مطلق گواهی برای بارگذاری. به همان صورت به دیمن ارسال می‌شود، بنابراین باید برای آن خواندنی باشد.

در هر بخش، یا این گزینه یا handle را پیکربندی کنید، نه هر دو را.

شناسه هگزادسیمال CKA_ID گواهی CA روی یک توکن امنیتی.

در هر بخش، یا این گزینه یا file را پیکربندی کنید، نه هر دو را.

شماره اسلات اختیاری توکنی که گواهی CA را ذخیره می‌کند.
نام اختیاری ماژول PKCS#11.
هویت مشخص‌شده باید در یکی از مراجع صدور گواهی (CA) میانی در زنجیره اعتماد همتای دوردست، یا به عنوان subject یا به عنوان subjectAltName موجود باشد. این گزینه همان تأثیر مشخص کردن cacerts را دارد تا کلاینت‌های تحت یک CA خاص را به اتصالات ویژه‌ای ملزم کند؛ این گزینه نیازی به وجود محلی گواهی CA ندارد و می‌تواند در طول تبادل IKE از همتا دریافت شود.
فهرست جداشده با ویرگول از کلیدهای عمومی خام جهت پذیرش در احراز اصالت. کلیدهای عمومی می‌توانند از یک مسیر نسبی از شاخه swanctl pubkey یا یک مسیر مطلق استفاده کنند.
سیاست ابطال گواهی برای ابطال با CRL یا OCSP.

سیاست ابطال strict در صورتی که هیچ اطلاعات ابطالی در دسترس نباشد ناموفق خواهد بود؛ به این معنی که عدم ابطال گواهی محرز نشده باشد.

سیاست ifuri تنها زمانی با شکست مواجه می‌شود که یک آدرس URI برای CRL/OCSP در دسترس باشد، اما بررسی ابطال گواهی شکست بخورد؛ یعنی باید اطلاعات ابطال در دسترس می‌بود اما دریافت آن میسر نشد.

سیاست ابطال پیش‌فرض یعنی relaxed تنها در صورتی با شکست مواجه می‌شود که گواهی باطل شده باشد؛ به این معنی که صراحتاً مشخص شود گواهی نامعتبر است.

احراز اصالتی که از طرف دوردست انتظار می‌رود. شرح کلیدواژه auth در بخش local را برای جزئیات سازوکارهای پشتیبانی‌شده ببینید.

برای الزام استحکام کلید عمومی زنجیره اعتماد برای سمت دوردست، نوع کلید را مشخص کرده و به دنبال آن حداقل استحکام به بیت را ذکر کنید (برای نمونه ecdsa-384 یا rsa-2048-ecdsa-256). برای محدود کردن مجموعه الگوریتم‌های هش قابل قبول برای اعتبارسنجی زنجیره اعتماد، الگوریتم‌های هش را به pubkey یا به یک تعریف استحکام کلید پیوست کنید (برای نمونه pubkey-sha256-sha512، rsa-2048-sha256-sha384-sha512 یا rsa-2048-sha256-ecdsa-256-sha256-sha384). مگر اینکه در strongswan.conf(5) غیرفعال شده باشد، یا محدودیت‌های صریح امضای IKEv2 پیکربندی شده باشد (برای جزئیات به شرح کلیدواژه auth در بخش local مراجعه کنید)، این‌گونه انواع کلید و الگوریتم‌های هش به عنوان محدودیت‌هایی بر طرح‌های احراز اصالت امضای IKEv2 مورد استفاده در طرف دوردست نیز اعمال می‌شوند. برای الزام امضاهای RSASSA-PSS، از rsa/pss به جای pubkey یا rsa استفاده کنید، مانند rsa/pss-sha256. اگر محدودیت‌های pubkey یا rsa پیکربندی شده باشند، امضاهای RSASSA-PSS تنها در صورتی پذیرفته می‌شوند که در strongswan.conf(5) فعال شده باشند.

برای تعیین محدودیت‌های زنجیره اعتماد برای EAP-(T)TLS، یک دو نقطه به روش EAP اضافه کرده و نوع/اندازه کلید و الگوریتم هش را همان‌طور که در بالا بحث شد پیوست کنید (برای نمونه eap-tls:ecdsa-384-sha384).


زیربخش پیکربندی CHILD_SA. هر تعریف اتصال می‌تواند یک یا چند بخش در زیربخش children خود داشته باشد. نام بخش، نام پیکربندی CHILD_SA را مشخص می‌کند که باید درون اتصال یکتا باشد.
پیشنهادهای AH برای ارائه جهت CHILD_SA. یک پیشنهاد مجموعه‌ای از الگوریتم‌ها است. برای AH، این شامل یک الگوریتم یکپارچگی و یک روش تبادل کلید اختیاری است. اگر یک روش KE مشخص شود، کلیدگذاری مجدد CHILD_SA/Quick Mode و مذاکره اولیه از یک تبادل کلید جداگانه با استفاده از روش مذاکره‌شده بهره می‌برند (برای جزئیات به esp_proposals مراجعه کنید).

با همتایانی که از چندین تبادل کلید در IKEv2 پشتیبانی می‌کنند (RFC 9370)، تا هفت تبادل کلید اضافی می‌تواند مذاکره شود. می‌توان آنها را با افزودن پیشوند keX_ (که در آن X عددی بین 1 تا 7 است) به کلیدواژه الگوریتم پیکربندی کرد.

برای IKEv2، چند الگوریتم از یک نوع را می‌توان در یک پیشنهاد واحد مشخص کرد که یکی از آنها انتخاب می‌شود. برای IKEv1، تنها یک الگوریتم از هر نوع در هر پیشنهاد مجاز است؛ الگوریتم‌های بیشتر به طور ضمنی حذف می‌شوند. برای ارائه ترکیب‌های الگوریتمی متفاوت در IKEv1 از چندین پیشنهاد استفاده کنید.

کلیدواژه‌های الگوریتم با خط فاصله جدا می‌شوند. چندین پیشنهاد ممکن است با ویرگول از هم جدا شوند. مقدار ویژه default یک پیشنهاد پیش‌فرض از الگوریتم‌های پشتیبانی‌شده و ایمن را تشکیل می‌دهد، و معمولاً انتخاب خوبی برای سازگاری متقابل است. به طور پیش‌فرض هیچ پیشنهاد AH گنجانده نشده است، در عوض ESP پیشنهاد می‌شود.

پیشنهادهای ESP برای ارائه جهت CHILD_SA. یک پیشنهاد مجموعه‌ای از الگوریتم‌ها است. برای پیشنهادهای ESP غیر-AEAD، این شامل یک الگوریتم یکپارچگی، یک الگوریتم رمزنگاری، یک روش تبادل کلید اختیاری و یک شناساگر حالت شماره توالی گسترده اختیاری است. برای پیشنهادهای AEAD، به جای الگوریتم‌های رمزنگاری/یکپارچگی جداگانه، از یک الگوریتم حالت ترکیبی استفاده می‌شود.

اگر روش تبادل کلید مذاکره شود، کلیدگذاری مجدد CHILD_SA/Quick Mode و مذاکره اولیه از یک تبادل کلید جداگانه با استفاده از روش مشخص‌شده بهره می‌برند. با این حال، در IKEv2، کلیدهای CHILD_SA که به طور ضمنی با IKE_SA ایجاد می‌شوند همواره از مواد کلید IKE_SA مشتق خواهند شد. بنابراین هر روش تبادل کلید مشخص‌شده در اینجا تنها زمانی اعمال می‌شود که CHILD_SA بعداً کلیدگذاری مجدد شود یا با یک تبادل جداگانه CREATE_CHILD_SA ایجاد گردد. از این رو ممکن است عدم تطابق پیشنهاد در هنگام برقراری اولیه SA متوجه نشود، اما بعداً موجب شکست در کلیدگذاری مجدد گردد. اگر یک یا چند روش تبادل کلید در یک پیشنهاد پیکربندی شده باشد، تبادل کلید را می‌توان با افزودن none اختیاری کرد.

با همتایانی که از تبادل کلید چندگانه در IKEv2 پشتیبانی می‌کنند (RFC 9370)، تا هفت تبادل کلید اضافی می‌تواند مذاکره شود. آنها را می‌توان با افزودن پیشوند keX_ (که در آن X عددی بین 1 تا 7 است) به کلیدواژه الگوریتم پیکربندی کرد. تبادلات کلید اضافی را می‌توان با افزودن keX_none به یک پیشنهاد، اختیاری نمود.

پشتیبانی از شماره توالی گسترده (Extended Sequence Number) را می‌توان با مقادیر esn و noesn مشخص کرد؛ هر دو را می‌توان برای اعلام پشتیبانی از هر دو حالت گنجاند. در صورت عدم ذکر، noesn فرض می‌شود.

برای IKEv2، چند الگوریتم از یک نوع را می‌توان در یک پیشنهاد واحد مشخص کرد که یکی از آنها انتخاب می‌شود. برای IKEv1، تنها یک الگوریتم از هر نوع در هر پیشنهاد مجاز است؛ الگوریتم‌های بیشتر به طور ضمنی حذف می‌شوند. برای ارائه ترکیب‌های مختلف الگوریتمی در IKEv1 از چندین پیشنهاد استفاده کنید.

کلیدواژه‌های الگوریتم با خط فاصله جدا می‌شوند. چندین پیشنهاد ممکن است با ویرگول از هم جدا شوند. مقدار ویژه default یک پیشنهاد پیش‌فرض از الگوریتم‌های پشتیبانی‌شده و ایمن تشکیل می‌دهد، و معمولاً انتخاب خوبی برای سازگاری متقابل است. اگر هیچ الگوریتمی نه برای AH و نه برای ESP مشخص نشود، مجموعه الگوریتم‌های default برای ESP گنجانده می‌شود.

در پروتکل IPsec از HMAC-SHA-256 با کوتاه‌سازی (truncation) ۱۲۸ بیتی استفاده می‌شود. برای سازگاری با پیاده‌سازی‌هایی که به اشتباه از کوتاه‌سازی ۹۶ بیتی استفاده می‌کنند، می‌توان این گزینه را فعال کرد تا طول کوتاه‌سازی کوتاه‌تر در هسته سیستم‌عامل پیکربندی شود. این مورد مذاکره نمی‌شود، بنابراین تنها با همتایانی کار می‌کند که از طول کوتاه‌سازی نادرست استفاده می‌کنند (یا این گزینه در آنها فعال است).
فهرست جداشده با ویرگول از انتخاب‌گرهای ترافیک (traffic selectors) محلی برای گنجاندن در CHILD_SA. هر انتخاب‌گر یک تعریف زیرشبکه CIDR است که به دنبال آن یک انتخاب‌گر اختیاری پروتکل/درگاه می‌آید. مقدار ویژه dynamic می‌تواند به جای تعریف زیرشبکه به کار رود، که در صورت مذاکره با نشانی بیرونی تونل یا IP مجازی جایگزین می‌شود. این مقدار پیش‌فرض است.

انتخاب‌گر پروتکل/درگاه در میان قلاب‌های باز و بسته ([]) قرار می‌گیرد. بین این قلاب‌ها، می‌توان یک شماره پروتکل یا نام پروتکل بر اساس getservent(3) را مشخص کرد. پس از محدودیت اختیاری پروتکل، می‌توان محدودیت اختیاری درگاه را با یک ممیز (/) مشخص نمود. محدودیت درگاه می‌تواند عددی، نام سرویس در getservent(3) یا مقدار ویژه opaque برای انتخاب‌گرهای OPAQUE بر اساس RFC 4301 باشد. محدوده‌های درگاه نیز می‌توانند مشخص شوند، هرچند در حال حاضر هیچ‌یک از backendهای هسته از محدوده‌های درگاه پشتیبانی نمی‌کنند. اگر پروتکل icmp یا ipv6-icmp باشد، درگاه در صورتی که کمتر از ۲۵۶ باشد به عنوان نوع پیام ICMP و در صورتی که بزرگ‌تر یا مساوی ۲۵۶ باشد به عنوان نوع و کد تفسیر می‌شود، به گونه‌ای که نوع در ۸ بیت پرارزش‌تر و کد در ۸ بیت کم‌ارزش‌تر قرار می‌گیرد.

هنگام استفاده از IKEv1 تنها نخستین انتخاب‌گر تفسیر می‌شود، مگر اینکه افزونه Cisco Unity به کار رفته باشد. این به دلیل محدودیت پروتکل IKEv1 است که تنها یک جفت انتخاب‌گر را در هر CHILD_SA مجاز می‌داند. بنابراین برای هدایت ترافیک منطبق بر چندین جفت انتخاب‌گر در IKEv1 به درون تونل، باید چندین فرزند (CHILD_SA) تعریف شوند که انتخاب‌گرها را پوشش دهند.

دیمن IKE از باریک‌سازی انتخاب‌گر ترافیک (narrowing) برای IKEv1 استفاده می‌کند، همان‌گونه که برای IKEv2 استانداردسازی و پیاده‌سازی شده است. هرچند این ممکن است در ارتباط با سایر پیاده‌سازی‌ها به مشکلاتی بینجامد. برای جلوگیری از آن، در چنین سناریوهایی انتخاب‌گرهای یکسان پیکربندی کنید.

فهرست جداشده با ویرگول از انتخاب‌گرهای دوردست برای گنجاندن در CHILD_SA. ساختار نحوی انتخاب‌گر را در local_ts ببینید.
زمان زمان‌بندی کلیدگذاری مجدد CHILD_SA. کلیدگذاری مجدد CHILD_SA مواد کلید را تازه می‌کند، و در صورت تعیین گروه در پیشنهاد، اختیاری از تبادل دیفی-هلمن بهره می‌برد.

برای جلوگیری از تداخل کلیدگذاری مجدد ناشی از آغاز هم‌زمان توسط هر دو طرف، مقداری در بازه rand_time کسر می‌شود تا طول عمر نرم مؤثر حاصل شود.

اگر life_time به صورت صریح پیکربندی شده باشد، مقدار پیش‌فرض rekey_time ۱۰ درصد کمتر از آن خواهد بود؛ در غیر این صورت کلیدگذاری مجدد CHILD_SA هر یک ساعت یک‌بار، منهای rand_time زمان‌بندی می‌شود.

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

مقدار پیش‌فرض ۱۰ درصد بیشتر از rekey_time است.

بازه زمانی برای انتخاب یک مقدار تصادفی جهت کسر از rekey_time. مقدار پیش‌فرض، تفاضل میان life_time و rekey_time است.
تعداد بایت‌های پردازش‌شده پیش از آغاز کلیدگذاری مجدد CHILD_SA. کلیدگذاری مجدد CHILD_SA مواد کلید را تازه می‌کند، و در صورت تعیین گروه در پیشنهاد، اختیاری از تبادل دیفی-هلمن بهره می‌برد.

برای جلوگیری از تداخل در کلیدگذاری مجدد، مقداری در بازه rand_bytes کسر می‌شود تا حد حجم نرم مؤثر تشکیل شود.

کلیدگذاری مجدد CHILD_SA مبتنی بر حجم به طور پیش‌فرض غیرفعال است. اگر life_bytes به طور صریح پیکربندی شود، rekey_bytes به طور پیش‌فرض ۱۰ درصد کمتر از آن خواهد بود.

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

مقدار پیش‌فرض ۱۰ درصد بیشتر از rekey_bytes است.

بازه بایت برای انتخاب یک مقدار تصادفی جهت کسر از rekey_bytes. مقدار پیش‌فرض تفاضل میان life_bytes و rekey_bytes است.
تعداد بسته‌های پردازش‌شده پیش از آغاز کلیدگذاری مجدد CHILD_SA. کلیدگذاری مجدد CHILD_SA مواد کلید را تازه می‌کند، و در صورت تعیین گروه در پیشنهاد، اختیاری از تبادل دیفی-هلمن بهره می‌برد.

برای جلوگیری از تداخل، مقداری در بازه rand_packets کسر می‌شود تا حد شمارش بسته نرم مؤثر به دست آید.

کلیدگذاری مجدد CHILD_SA بر اساس شمارش بسته به طور پیش‌فرض غیرفعال است. اگر life_packets صراحتاً پیکربندی شود، rekey_packets به طور پیش‌فرض ۱۰ درصد کمتر از آن خواهد بود.

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

مقدار پیش‌فرض ۱۰ درصد بیشتر از rekey_bytes است.

بازه بسته‌ها برای انتخاب یک مقدار تصادفی جهت کسر از rekey_packets. مقدار پیش‌فرض تفاضل میان life_packets و rekey_packets است.
اسکریپت updown برای فراخوانی هنگام رخدادهای بالا آمدن (up) و پایین رفتن (down) مربوط به CHILD_SA.
متغیر hostaccess برای ارسال به اسکریپت updown.
حالت IPsec برای برقراری CHILD_SA. مقدار tunnel پیمان امنیتی CHILD_SA را در حالت تونل (Tunnel Mode) مذاکره می‌کند، در حالی که transport از حالت انتقال (Transport Mode) بهره می‌برد. مقدار transport_proxy نشان‌دهنده حالت ویژه پروکسی انتقال Mobile IPv6 است. مقدار iptfs حالت تونل IP-TFS همراه با تجمیع و تکه‌تکه‌سازی است. مقدار beet حالت ترکیبی Bound End to End Tunnel است که با نشانی‌های داخلی ثابت و بدون نیاز به گنجاندن آنها در هر بسته کار می‌کند.

حالت‌های transport، iptfs و beet مشمول مذاکره حالت هستند؛ در صورتی که حالت ترجیحی در دسترس نباشد، حالت tunnel مذاکره می‌شود.

مقادیر pass و drop برای نصب سیاست‌های انحرافی (shunt policies) به کار می‌روند که ترافیک تعریف‌شده را به طور صریح به ترتیب از پردازش IPsec معاف می‌کنند یا آن را دور می‌ریزند (drop می‌کنند).

نصب یا عدم نصب سیاست‌های IPsec. غیرفعال‌سازی این مورد در برخی سناریوها مانند MIPv6 سودمند است، که در آنها سیاست‌ها توسط دیمن IKE مدیریت نمی‌شوند.
نصب یا عدم نصب سیاست‌های IPsec برای بازپخش خروجی (outbound FWD). فعال‌سازی این گزینه در حالتی لازم است که یک سیاست drop وجود داشته باشد که با ترافیک بازپخش‌شده برای این CHILD_SA تطبیق یافته و آن را مسدود کند.
اقدامی که در صورت پایان مهلت زمانی DPD برای این CHILD_SA انجام می‌گیرد. مقدار پیش‌فرض clear پیمان امنیتی CHILD_SA را می‌بندد و اقدام دیگری انجام نمی‌دهد. مقدار trap یک سیاست تله (trap policy) نصب می‌کند که ترافیک منطبق را به دام انداخته و سعی می‌کند تونل را در صورت تقاضا مجدداً مذاکره کند (توجه داشته باشید که اگر start_action شامل trap باشد، این مورد افزونه و تکراری است). مقدار restart بی‌درنگ تلاش می‌کند CHILD_SA را تحت یک IKE_SA تازه مجدداً مذاکره کند.
فعال‌سازی فشرده‌سازی IPComp پیش از رمزنگاری. در صورت فعال بودن، IKE تلاش می‌کند فشرده‌سازی IPComp را برای فشرده‌سازی داده‌های محموله ESP پیش از رمزنگاری مذاکره نماید.
مهلت زمانی پیش از بستن CHILD_SA پس از عدم فعالیت. اگر در هیچ‌یک از جهات برای مدت زمان پیکربندی‌شده ترافیکی پردازش نشود، CHILD_SA به دلیل عدم فعالیت بسته می‌شود. مقدار پیش‌فرض 0 بررسی‌های عدم فعالیت را غیرفعال می‌کند.
شناسه reqid ثابت برای استفاده در این CHILD_SA. این گزینه ممکن است در برخی سناریوها مفید باشد، اما تنها در صورتی کار می‌کند که هر پیکربندی CHILD_SA بیش از یک بار نمونه‌سازی نشود. مقدار پیش‌فرض 0 از reqidهای پویا که به صورت افزایشی تخصیص می‌یابند استفاده می‌کند.
اولویت ثابت اختیاری برای سیاست‌های IPsec. این گزینه می‌تواند برای نصب سیاست‌های drop با اولویت بالا مفید باشد. مقدار پیش‌فرض 0 از اولویت‌هایی استفاده می‌کند که به طور پویا بر اساس اندازه انتخاب‌گرهای ترافیک محاسبه می‌شوند.
نام اختیاری رابط برای محدود کردن سیاست‌های IPsec.
علامت و ماسک Netfilter برای ترافیک ورودی. در لینوکس، Netfilter ممکن است نیاز به علامت‌گذاری روی هر بسته داشته باشد تا با SA/سیاستی که این گزینه در آن تنظیم شده تطبیق یابد. این امر امکان نصب سیاست‌های تکراری را فراهم ساخته و قوانین Netfilter را قادر می‌سازد تا SAها/سیاست‌های خاصی را برای ترافیک ورودی انتخاب کنند. توجه داشته باشید که علائم ورودی به طور پیش‌فرض تنها روی سیاست‌ها تنظیم می‌شوند، مگر اینکه *mark_in_sa* فعال باشد. مقدار ویژه %unique یک علامت یکتا روی هر نمونه CHILD_SA تنظیم می‌کند؛ فراتر از آن مقدار %unique-dir علامت یکتای متفاوتی را برای هر جهت CHILD_SA (ورودی/خروجی) تخصیص می‌دهد.

یک ماسک اضافی می‌تواند با ممیز (/) به علامت اضافه شود. در صورت عدم ذکر، ماسک پیش‌فرض 0xffffffff است.

تنظیم یا عدم تنظیم *mark_in* روی SA ورودی. به طور پیش‌فرض، علامت ورودی تنها روی سیاست ورودی تنظیم می‌شود. چندتایی نشانی مقصد، پروتکل و SPI یکتا است و برای یافتن SA درست نیازی به علامت نیست؛ این امر امکان می‌دهد ترافیک پس از رمزگشایی علامت‌گذاری شود (جایی که می‌توان از انتخاب‌گرهای خاص‌تری استفاده کرد) تا با سیاست‌های مختلف تطبیق داده شود. علامت‌گذاری بسته‌ها پیش از رمزگشایی همچنان امکان‌پذیر است، حتی اگر هیچ علامتی روی SA تنظیم نشده باشد.
علامت و ماسک Netfilter برای ترافیک خروجی. در لینوکس، Netfilter ممکن است نیاز به علامت‌گذاری روی هر بسته داشته باشد تا با سیاست/SA دارای این تنظیم تطبیق یابد. این امر امکان نصب سیاست‌های تکراری را فراهم ساخته و به قوانین Netfilter اجازه می‌دهد سیاست‌ها/SAهای مشخصی را برای ترافیک خروجی انتخاب کنند. مقدار ویژه %unique یک علامت یکتا روی هر نمونه CHILD_SA تنظیم می‌کند؛ فراتر از آن مقدار %unique-dir علامت یکتای متفاوتی برای هر جهت CHILD_SA (ورودی/خروجی) تخصیص می‌دهد.

یک ماسک اضافی می‌تواند با ممیز (/) به علامت اضافه شود. در صورت عدم ذکر، ماسک پیش‌فرض 0xffffffff است.

علامت Netfilter اعمال‌شده بر بسته‌ها پس از پردازش توسط IPsec SA ورودی. بدین ترتیب نیازی به علامت‌گذاری بسته‌ها از طریق Netfilter پیش از رمزگشایی یا بلافاصله پس از آن برای تطبیق سیاست‌ها یا پردازش متفاوت آنها (مانند مسیریابی بر اساس سیاست) نیست.

یک ماسک اضافی می‌تواند با ممیز (/) به علامت اضافه شود. در صورت عدم ذکر، ماسک پیش‌فرض 0xffffffff است. مقدار ویژه %same از مقدار (نه ماسک) mark_in به عنوان مقدار علامت استفاده می‌کند، که می‌تواند مقدار ثابت، %unique یا %unique-dir باشد.

تنظیم علامت در ورودی XFRM نیازمند لینوکس 4.19 یا بالاتر است.

علامت Netfilter اعمال‌شده بر بسته‌ها پس از پردازش توسط IPsec SA خروجی. این امر امکان می‌دهد بسته‌های ESP به طور متفاوتی نسبت به ترافیک اصلی پردازش شوند (برای نمونه از طریق مسیریابی بر اساس سیاست).

یک ماسک اضافی می‌تواند با ممیز (/) به علامت اضافه شود. در صورت عدم ذکر، ماسک پیش‌فرض 0xffffffff است. مقدار ویژه %same از مقدار (نه ماسک) mark_out به عنوان مقدار علامت بهره می‌برد، که می‌تواند ثابت، %unique یا %unique-dir باشد.

تنظیم علامت در خروجی XFRM از لینوکس 4.14 پشتیبانی می‌شود. تنظیم ماسک دست‌کم به لینوکس 4.19 نیاز دارد.

شناسه رابط XFRM تنظیم‌شده روی سیاست‌ها/SAهای ورودی. این گزینه امکان نصب سیاست‌ها/SAهای تکراری را فراهم کرده و آنها را با رابطی با همان شناسه مرتبط می‌سازد. مقدار ویژه %unique یک شناسه رابط یکتا روی هر نمونه CHILD_SA تنظیم می‌کند؛ فراتر از آن مقدار %unique-dir شناسه رابط یکتای متفاوتی را برای هر جهت CHILD_SA (ورودی/خروجی) تخصیص می‌دهد.
شناسه رابط XFRM تنظیم‌شده روی سیاست‌ها/SAهای خروجی. این گزینه امکان نصب سیاست‌ها/SAهای تکراری را فراهم کرده و آنها را با رابطی با همان شناسه مرتبط می‌سازد. مقدار ویژه %unique یک شناسه رابط یکتا روی هر نمونه CHILD_SA تنظیم می‌کند؛ فراتر از آن مقدار %unique-dir شناسه رابط یکتای متفاوتی برای هر جهت CHILD_SA (ورودی/خروجی) تخصیص می‌دهد.

دیمن برای CHILD_SAهایی که این گزینه در آنها تنظیم شده مسیری نصب نخواهد کرد.

برچسب امنیتی اختیاری (برای نمونه بافت SELinux)، فقط در IKEv2. برای جزئیات نحوه پردازش برچسب‌ها به label_mode مراجعه کنید.
حالتی را تعریف می‌کند که برچسب امنیتی پیکربندی‌شده در آن استفاده می‌شود. مقدار پیش‌فرض system در صورتی که strongSwan با پشتیبانی SELinux ساخته شده باشد و SELinux در هسته فعال باشد گزینه selinux را برمی‌گزیند؛ در غیر این صورت simple انتخاب خواهد شد.

اگر روی simple تنظیم شود، برچسب دقیقاً به همان صورت به عنوان شناسه/انتخاب‌گر اضافی در سطح IKEv2 هنگام مذاکره CHILD_SAها و انتخاب پیکربندی‌ها استفاده می‌شود، برچسب‌ها در هسته نصب نمی‌شوند و برچسب‌های دریافتی باید دقیقاً مطابقت داشته باشند.

اگر روی selinux تنظیم شود، که تنها در صورت قابل استفاده بودن SELinux در سیستم مجاز است، انتظار می‌رود برچسب پیکربندی‌شده یک بافت عمومی باشد (مانند system_u:object_r:ipsec_spd_t:s0) که جریان‌هایی که بافت آنها از طریق association:polmatch با آن مطابقت دارد، در صورتی که هنوز SAای برای بافت خاص آن جریان وجود نداشته باشد، یک درخواست دریافت (acquire) را تحریک می‌کنند. برچسب پیکربندی‌شده روی سیاست‌های تله نصب می‌شود، بنابراین به طور کلی باید با trap در start_action ترکیب شود. با این حال، اگر اتصال مستقیماً بدون acquire آغاز شود، یک IKE_SA بدون فرزند برقرار شده و سیاست‌های تله مناسب در هر دو انتها نصب می‌شوند. برچسب‌های دریافتی از همتایان در صورتی که از طریق association:polmatch با برچسب پیکربندی‌شده مطابقت داشته باشند پذیرفته می‌شوند.

بسته‌های ESP را با داده‌های اضافی لایه‌گذاری (pad) می‌کند تا اندازه بسته ESP یکنواخت باشد و محرمانگی جریان ترافیک (TFC) بهبود یابد. لایه‌گذاری حداقل اندازه تمام بسته‌های ESP ارسالی را مشخص می‌کند.

مقدار پیش‌فرض 0 لایه‌گذاری TFC را غیرفعال می‌کند؛ مقدار ویژه mtu لایه‌گذاری TFC را به گونه‌ای اضافه می‌کند که اندازه بسته برابر با حداکثر واحد انتقال مسیر (MTU) شود.

پنجره بازپخش IPsec برای پیکربندی در این CHILD_SA. مقادیر بزرگ‌تر از مقدار پیش‌فرض ۳۲ تنها با استفاده از backend مربوط به Netlink پشتیبانی می‌شوند؛ مقدار 0 حفاظت از بازپخش IPsec را غیرفعال می‌کند.
فعال‌سازی CHILD_SAهای به ازای هر پردازنده (per-CPU). مستلزم تعیین trap در start_action است.

مقدار encap نوع خاصی از کپسوله‌سازی UDP را فعال می‌کند (در صورت عدم وجود NAT، نیازمند فعال‌سازی encap برای اتصال است)، که در آن از یک درگاه مبدأ تصادفی برای هر SA خروجی به ازای هر پردازنده استفاده می‌شود (درگاه مقصد برای همه آنها 4500 باقی می‌ماند). این امر امکان استفاده از درگاه را برای RSS فراهم می‌سازد اگر نتوان از SPI استفاده کرد. توجه داشته باشید که این نوع رفتار استاندارد نبوده و مذاکره نمی‌شود. بنابراین صرف‌نظر از فعال بودن این گزینه، SAهای ورودی به ازای هر پردازنده با کپسوله‌سازی UDP همواره درگاه مبدأ روی 0 تنظیم دارند، چرا که درگاه تصادفی همتا در صورت فعال بودن این گزینه ناشناخته است.

فعال‌سازی تخلیه بار سخت‌افزاری (hardware offload) برای این CHILD_SA، در صورت پشتیبانی توسط پیاده‌سازی IPsec. مقادیر crypto یا packet تخلیه بار رمزنگاری یا کامل بسته را اجبار می‌کنند و در صورت عدم پشتیبانی حالت انتخابی توسط هسته یا دستگاه، نصب با شکست مواجه خواهد شد. در لینوکس، مقدار packet سیاست‌ها، از جمله سیاست‌های تله را نیز به سخت‌افزار منتقل می‌کند. مقدار auto در صورت پشتیبانی، تخلیه بار کامل بسته یا رمزنگاری را فعال می‌کند، اما در غیر این صورت نصب با شکست روبرو نمی‌شود.
کپی کردن یا نکردن بیت DF (Don't Fragment) به سرآیند بیرونی IPv4 در حالت تونل. این امر عملاً کشف MTU مسیر (PMTUD) را غیرفعال می‌سازد. کنترل این رفتار توسط تمام رابط‌های هسته پشتیبانی نمی‌شود.
کپی کردن یا نکردن فیلد سرآیند اعلان ازدحام صریح (ECN) به/از سرآیند IP بیرونی در حالت تونل. کنترل این رفتار توسط تمام رابط‌های هسته پشتیبانی نمی‌شود.
کپی کردن یا نکردن فیلد سرآیند DSCP به/از سرآیند IP بیرونی در حالت تونل. مقدار out تنها فیلد را از سرآیند درونی به بیرونی کپی می‌کند، مقدار in عکس آن عمل کرده و تنها فیلد را از سرآیند بیرونی به درونی هنگام کپسوله‌زدایی کپی می‌کند، مقدار yes فیلد را در هر دو جهت کپی می‌کند، و مقدار no کپی فیلد را به طور کامل غیرفعال می‌سازد. تنظیم این گزینه روی yes یا in می‌تواند به مهاجم اجازه دهد بر سایر ترافیک‌ها در گیرنده تأثیر منفی بگذارد، به همین دلیل پیش‌فرض out است. کنترل این رفتار توسط تمام رابط‌های هسته پشتیبانی نمی‌شود.
پیام‌های خطای ICMP، مانند Destination Unreachable، Time Exceeded یا Fragmentation Needed، ممکن است توسط میزبان‌هایی تولید شوند که نشانی IP آنها در انتخاب‌گرهای ترافیک مذاکره‌شده وجود ندارد و بنابراین با سیاست‌های IPsec مطابقت ندارند. اگر این گزینه فعال باشد و هسته از آن پشتیبانی کند، چنین بسته‌هایی همچنان می‌توانند بازپخش (forward) شوند. از آنجا که خطاهای ICMP حاوی بخش‌هایی از بسته IP آغازگر خطا هستند، هسته تصمیم خود را بر اساس یک جستجوی سیاست معکوس با استفاده از آن سرآیند IP اتخاذ خواهد کرد.
اقدامی که باید پس از بارگذاری پیکربندی انجام شود. مقدار پیش‌فرض none تنها اتصال را بارگذاری می‌کند، که سپس می‌تواند به صورت دستی آغاز شود یا به عنوان پیکربندی پاسخ‌دهنده به کار رود.

مقدار trap یک سیاست تله (trap policy) نصب می‌کند که به محض شناسایی ترافیک منطبق، تونل را فعال می‌سازد. مقدار start اتصال را به صورت فعال آغاز می‌کند. این دو حالت را می‌توان با trap|start ترکیب کرد تا بلافاصله اتصالی که سیاست‌های تله برای آن نصب شده است آغاز شود.

هنگام تخلیه از حافظه (unload) یا جایگزینی پیکربندی CHILD_SA که دارای مقدار start_action متفاوتی از none است، اقدام معکوس انجام می‌گیرد. پیکربندی‌های با مقدار start بسته می‌شوند، در حالی که پیکربندی‌های دارای trap حذف نصب می‌شوند (برای اتصالات با مقدار trap|start هر دو رخ می‌دهد).

اقدامی که باید پس از بسته شدن CHILD_SA توسط همتا انجام گیرد. مقدار پیش‌فرض none هیچ اقدامی انجام نمی‌دهد، مقدار trap یک سیاست تله برای CHILD_SA نصب می‌کند (توجه داشته باشید که اگر start_action شامل trap باشد، این مورد افزونه و تکراری است). مقدار start تلاش می‌کند بلافاصله CHILD_SA را مجدداً ایجاد کند.

گزینه close_action هیچ تضمینی برای زنده نگه داشتن CHILD_SA ارائه نمی‌دهد. این گزینه تنها بر روی پیام‌های صریح بسته‌شدن عمل می‌کند، نه بر روی شکست‌های مذاکره. برای بازسازی مطمئن CHILD_SAهای شکست‌خورده از سیاست‌های تله استفاده کنید.


بخشی که اطلاعات سرّی (secrets) را برای احراز اصالت IKE/EAP/XAuth و رمزگشایی کلید خصوصی تعریف می‌کند. بخش secrets زیربخش‌هایی با پیشوند مشخص می‌پذیرد که نوع اطلاعات سرّی را تعیین می‌کند.

تعریف عبارت‌های عبور رمزگشایی کلید خصوصی توصیه نمی‌شود، زیرا در این صورت داشتن کلیدهای رمزشده هیچ مزیت امنیتی واقعی ندارد. کلید را یا به صورت رمزنmatched (بدون رمزنگاری) ذخیره کنید یا هنگام بارگذاری اعتبارنامه‌ها، کلیدها را به صورت تعاملی وارد نمایید.


بخش اطلاعات سرّی EAP برای یک سرّ خاص. هر سرّ EAP در یک بخش یکتا با پیشوند eap تعریف می‌شود. اطلاعات سرّی EAP برای احراز اصالت XAuth نیز به کار می‌روند.
مقدار سرّ EAP/XAuth. این مقدار می‌تواند یک رشته ASCII، یک رشته با کدگذاری هگز در صورت داشتن پیشوند 0x یا یک رشته با کدگذاری Base64 در صورت داشتن پیشوند 0s باشد.
هویتی که سرّ EAP/XAuth به آن تعلق دارد. اگر یک سرّ بین چندین کاربر به اشتراک گذاشته شده باشد، می‌توان چندین هویت یکتا را که هر یک دارای پیشوند id هستند مشخص کرد.

بخش اطلاعات سرّی XAuth برای یک سرّ خاص. xauth تنها یک نام مستعار برای eap است؛ اسرار تحت هر دو پیشوند بخش برای احراز اصالت EAP و XAuth به کار می‌روند.

بخش اطلاعات سرّی NTLM برای یک سرّ خاص. هر سرّ NTLM در یک بخش یکتا با پیشوند ntlm تعریف می‌شود. اسرار NTLM تنها می‌توانند برای احراز اصالت EAP-MSCHAPv2 استفاده شوند.
مقدار سرّ NTLM، که همان درهم‌سازی NT از سرّ واقعی است، یعنی MD4(UTF-16LE(secret)). مقدار ۱۶ بایتی حاصل می‌تواند به صورت یک رشته با کدگذاری هگز با پیشوند 0x یا یک رشته با کدگذاری Base64 با پیشوند 0s داده شود.
هویتی که سرّ NTLM به آن تعلق دارد. اگر سرّ بین چندین کاربر به اشتراک گذاشته شده باشد، می‌توان چندین هویت یکتا با پیشوند id تعیین کرد.

بخش سرّ از پیش اشتراک‌گذاشته‌شده IKE برای یک سرّ خاص. هر PSK در IKE در بخشی یکتا با پیشوند ike تعریف می‌شود.
مقدار سرّ از پیش اشتراک‌گذاشته‌شده IKE. می‌تواند یک رشته ASCII، یک رشته کدگذاری‌شده با هگز با پیشوند 0x یا یک رشته با کدگذاری Base64 با پیشوند 0s باشد.
هویت IKE که سرّ از پیش اشتراک‌گذاشته‌شده IKE به آن تعلق دارد. اگر سرّ بین چندین همتا به اشتراک گذاشته شود، می‌توان چندین هویت یکتا با پیشوند id تعیین کرد.

بخش کلید از پیش اشتراک‌گذاشته‌شده پساکوانتومی (PPK) برای یک سرّ خاص. هر PPK در یک بخش یکتا با پیشوند ppk تعریف می‌شود.
مقدار PPK. می‌تواند یک رشته ASCII، یک رشته با کدگذاری هگز با پیشوند 0x یا یک رشته با کدگذاری Base64 با پیشوند 0s باشد. برای امنیت ۱۲۸ بیتی باید دست‌کم ۲۵۶ بیت انتروپی داشته باشد.
هویت PPK که PPK به آن تعلق دارد. اگر سرّ بین چندین همتا مشترک باشد، می‌توان چندین هویت یکتا با پیشوند id تعیین نمود.

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

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

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

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

عبارت عبور رمزگشایی PKCS#12 برای یک ظرف در پوشه pkcs12.
نام پرونده در پوشه pkcs12 که این عبارت عبور باید برای آن استفاده شود.
مقدار عبارت عبور رمزگشایی برای ظرف PKCS#12.

تعریف برای یک کلید خصوصی که روی یک توکن/کارت هوشمند ذخیره شده است.
شناسه هگز CKA_ID مربوط به کلید خصوصی روی توکن.
شماره اسلات اختیاری برای دسترسی به توکن.
نام ماژول اختیاری PKCS#11 برای دسترسی به توکن.
کد PIN اختیاری لازم برای دسترسی به کلید روی توکن. در صورت عدم ارائه، در طول فراخوانی تعاملی --load-creds از کاربر پرسیده می‌شود.

بخشی که استخرهای نام‌گذاری‌شده را تعریف می‌کند. استخرهای نام‌گذاری‌شده می‌توانند توسط اتصالات با گزینه pools مورد ارجاع قرار گیرند تا IPهای مجازی و سایر ویژگی‌های پیکربندی را تخصیص دهند.

بخشی که یک استخر منفرد را با یک نام یکتا تعریف می‌کند.
زیرشبکه یا محدوده‌ای که نشانی‌های تخصیص‌یافته در استخر را مشخص می‌کند. یک زیرشبکه تکی CIDR که استخر نشانی‌ها را تعریف می‌کند یا یک محدوده نشانی (<از>-<تا>) را می‌پذیرد. اگر نشانی در نمادگذاری CIDR شناسه شبکه (network ID) زیرشبکه نباشد (برای نمونه 10.1.0.5/24 به جای 10.1.0.0/24)، نشانی‌های پایین‌تر از آن به کلاینت‌ها تخصیص نخواهند یافت (آنها می‌توانند برای نمونه به طور دستی به میزبان‌های داخلی مانند خود سرور VPN تخصیص داده شوند). استخرها باید یکتا بوده و هم‌پوشانی نداشته باشند.
فهرست جداشده با ویرگول از ویژگی‌های اضافی از نوع <attr>. نوع ویژگی می‌تواند یکی از مقادیر dns، nbns، dhcp، netmask، server، subnet، p_cscf، split_include و split_exclude برای تعیین نشانی‌ها یا زیرشبکه‌های CIDR برای انواع ویژگی مربوطه باشد. به عنوان گزینه دیگر، <attr> می‌تواند یک شناسه عددی باشد، که برای آن مقادیر ویژگی رشته‌ای نیز پذیرفته می‌شوند.

بخشی که ویژگی‌های مراجع صدور گواهی (CA) را تعریف می‌کند.

بخشی که یک مرجع صدور گواهی را با نامی یکتا تعریف می‌کند.
گواهی CA متعلق به مرجع صدور گواهی. گواهی‌ها می‌توانند از یک مسیر نسبی از شاخه swanctl x509ca یا یک مسیر مطلق استفاده کنند.

در هر بخش یکی از گزینه‌های cacert، file، یا handle را پیکربندی کنید.

مسیر مطلق گواهی برای بارگذاری. به همان صورت به دیمن ارسال می‌شود، بنابراین باید برای آن خواندنی باشد.

در هر بخش یکی از گزینه‌های cacert، file، یا handle را پیکربندی کنید.

شناسه هگز CKA_ID مربوط به گواهی CA روی یک توکن سخت‌افزاری/امنیتی.

در هر بخش یکی از گزینه‌های cacert، file، یا handle را پیکربندی کنید.

شماره اسلات اختیاری توکنی که گواهی CA را ذخیره می‌کند.
نام ماژول اختیاری PKCS#11.
فهرست جداشده با ویرگول از نقاط توزیع فهرست ابطال گواهی (CRL) (شامل URIهای پرونده، ldap یا http).
فهرست جداشده با ویرگول از URIهای مربوط به OCSP.
نشانی URI پایه را برای ویژگی هش و نشانی (Hash and URL) پشتیبانی‌شده در IKEv2 تعریف می‌کند. به جای تبادل گواهی‌های کامل، IKEv2 اجازه می‌دهد یک نشانی اینترنتی ارسال شود که به گواهی کدگذاری‌شده DER تفکیک می‌شود. نشانی‌های گواهی با پیوست کردن هش SHA1 گواهی‌های کدگذاری‌شده DER به این URI پایه ساخته می‌شوند. 

/etc/swanctl/swanctl.conf       پرونده پیکربندی

swanctl(8)

6.1.0