IPSEC.CONF(5) strongSwan IPSEC.CONF(5)

ipsec.conf - پیکربندی و اتصالات IPsec

پرونده اختیاری ipsec.conf بیشتر اطلاعات پیکربندی و کنترلی را برای زیرسیستم IPsec نرم‌افزار strongSwan مشخص می‌کند. استثنای اصلی، رازها (secrets) برای احراز هویت هستند؛ به ipsec.secrets(5) مراجعه کنید. محتویات این پرونده از نظر امنیتی حساس نیستند.

این پرونده یک پرونده متنی است که از یک یا چند بخش(section) تشکیل شده است. فاصله سفید که به دنبال آن # و هر متنی تا پایان خط بیاید، یک کامنت (توضیح) محسوب شده و نادیده گرفته می‌شود؛ همچنین خطوط خالی که درون یک بخش قرار ندارند نیز نادیده گرفته می‌شوند.

خطی که شامل include و یک نام پرونده باشد که با فاصله سفید از هم جدا شده‌اند، با محتویات آن پرونده جایگزین می‌شود. اگر نام پرونده یک مسیر کامل نباشد، به عنوان مسیری نسبی نسبت به شاخهٔ حاوی پروندهٔ دربرگیرنده در نظر گرفته می‌شود. این پرونده‌های گنجانده‌شده می‌توانند به صورت تو در تو باشند. تنها یک نام پرونده مجاز است و نباید شامل فاصله سفید باشد، اما می‌تواند شامل نویسه‌های عام پوسته (wildcards) باشد (به sh(1) مراجعه کنید)؛ برای نمونه:

include ipsec.*.conf

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

یک بخش با خطی به شکل زیر آغاز می‌شود:

type name

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

خطوط درون یک بخش عموماً به شکل زیر هستند:

     parameter=value

(به فاصله سفید اجباری در ابتدای خط توجه کنید). در هر دو طرف = می‌تواند فاصله سفید وجود داشته باشد. نام پارامترها مختص نوع بخش است.

یک value خالی به معنای مقدار پیش‌فرض سیستم (در صورت وجود) برای آن پارامتر است؛ به این معنی که تقریباً معادل حذف کامل خط پارامتر است. این می‌تواند برای پاک کردن تنظیمی که از یک بخش %default یا از طریق پارامتر also به ارث رسیده مفید باشد (به زیر مراجعه کنید). یک value می‌تواند شامل تک‌فاصله‌ها باشد (فاصله‌های سفید اضافی به یک فاصله کاهش می‌یابند). برای حفظ فاصله‌های سفید دقیقاً همان‌طور که نوشته شده‌اند، کل value را در جفت‌گیومه (") قرار دهید؛ در چنین مقادیری خود جفت‌گیومه‌ها را می‌توان با پیشوند قرار دادن نویسه‌های  گریز داد (escape کرد). یک رشته داخل گیومه می‌تواند با قرار دادن نویسه‌های  در انتهای خطوط در چند خط امتداد یابد (خطوط بعدی نیازی نیست با فاصله سفید شروع شوند، زیرا حفظ خواهد شد). علاوه بر این، نویسه‌های کنترلی زیر می‌توانند در رشته‌های داخل گیومه کدگذاری شوند: \n, \r, \t, \b, \f.

مقادیر عددی یا به صورت یک «عدد صحیح» (دنباله‌ای از ارقام) یا یک «عدد اعشاری» (دنباله‌ای از ارقام که به صورت اختیاری با `.' و دنباله دیگری از ارقام همراه است) مشخص می‌شوند.

در حال حاضر یک پارامتر وجود دارد که در هر نوع بخشی در دسترس است:

مقدار آن نام یک بخش است؛ پارامترهای آن بخش توسط بخش جاری به ارث برده می‌شوند. پارامترهای موجود در بخش جاری همیشه بر پارامترهای به ارث رسیده برتری دارند و آن‌ها را بازنویسی (override) می‌کنند، حتی اگر یک also بعد از آن‌ها بیاید. بخش مشخص‌شده باید وجود داشته باشد و باید نوع بخش یکسانی داشته باشد؛ فرقی نمی‌کند که قبل یا بعد از بخش جاری تعریف شده باشد. تودرتویی مجاز است و می‌تواند بیش از یک also در یک بخش واحد وجود داشته باشد (پارامترهای بخش‌های ارجاع داده شده به ترتیب همین پارامترهای also به ارث برده شده و بازنویسی می‌شوند).

بخشی با نام %default پیش‌فرض‌ها را برای بخش‌های هم‌نوع مشخص می‌کند. تمام پارامترهای موجود در آن توسط سایر بخش‌های آن نوع به ارث برده می‌شوند.

در حال حاضر سه نوع بخش وجود دارد: یک بخش config اطلاعات پیکربندی عمومی IPsec را مشخص می‌کند، یک بخش conn یک اتصال IPsec را مشخص می‌نماید، در حالی که یک بخش ca ویژگی‌های خاص یک مرجع صدور گواهی (CA) را مشخص می‌کند.

یک بخش conn شامل یک مشخصات اتصال (connection specification) است که یک اتصال شبکه‌ای را که قرار است با استفاده از IPsec برقرار شود، تعریف می‌کند. نام داده شده دلخواه است و برای شناسایی اتصال به کار می‌رود. در اینجا یک مثال ساده آورده شده است:

conn snt
	left=192.168.0.1
	leftsubnet=10.1.0.0/16
	right=192.168.0.2
	rightsubnet=10.1.0.0/16
	keyingtries=%forever
	auto=add

نکته‌ای درباره اصطلاحات: دو نوع ارتباط در جریان است: انتقال بسته‌های IP کاربر، و مذاکرات بین دروازه‌ای برای کلیدگذاری، کلیدگذاری مجدد و کنترل عمومی. مسیر کنترل اتصال در پروتکل IKEv1 به نام 'ISAKMP SA' و در پروتکل IKEv2 به نام 'IKE SA' شناخته می‌شود. آن چیزی که مذاکره می‌شود یعنی مسیر داده در سطح هسته، 'IPsec SA' یا 'Child SA' نامیده می‌شود. نرم‌افزار strongSwan پیش‌تر از دو دیمن کلیدگذاری مجزا به نام‌های pluto و charon استفاده می‌کرد. این راهنما دیگر به گزینه‌های pluto نمی‌پردازد، بلکه تنها به charon اختصاص دارد که از نسخه 5.0 strongSwan از هر دو پروتکل IKEv1 و IKEv2 پشتیبانی می‌کند.

برای جلوگیری از ویرایش‌های جزئی پرونده پیکربندی به منظور سازگاری با هر سامانه درگیر در اتصال، مشخصات اتصال بر اساس شرکت‌کنندگان left (چپ) و right (راست) نوشته می‌شوند، نه بر اساس محلی (local) و دوردست (remote). اینکه کدام شرکت‌کننده left یا right در نظر گرفته شود اختیاری است؛ برای هر توصیف اتصال تلاشی صورت می‌گیرد تا مشخص شود نقطه پایانی محلی باید به عنوان left عمل کند یا right. این کار با تطبیق نشانی‌های IP تعریف‌شده برای هر دو نقطه پایانی با نشانی‌های IP اختصاص‌یافته به رابط‌های شبکه محلی انجام می‌شود. اگر تطابقی یافت شود، نقشی (چپ یا راست) که مطابقت دارد، محلی در نظر گرفته خواهد شد. اگر در هنگام راه‌اندازی تطابقی یافت نشود، left محلی در نظر گرفته می‌شود. این امر اجازه می‌دهد از مشخصات اتصال یکسان در هر دو انتها استفاده شود. مواردی وجود دارد که در آن‌ها تقارن وجود ندارد؛ یک قرارداد خوب این است که از left برای سمت محلی و از right برای سمت دوردست استفاده شود (حروف اول در انگلیسی یک یادافزای مناسب هستند).

بسیاری از پارامترها به یکی از شرکت‌کنندگان مربوط می‌شوند؛ تنها پارامترهای مربوط به left در اینجا فهرست شده‌اند، اما هر پارامتری که نامش با left آغاز می‌شود، یک معادل با right دارد که توضیحات آن یکسان است اما جای left و right معکوس شده است.

پارامترها اختیاری هستند مگر اینکه به صورت '(required)' (اجباری) مشخص شده باشند.

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

هویت زیرسیستم پشتیبان AAA را که در طول احراز هویت IKEv2 EAP استفاده می‌شود، تعریف می‌کند. این گزینه در صورتی لازم است که کلاینت EAP از روشی استفاده کند که هویت سرور را اعتبارسنجی می‌کند (مانند EAP-TLS)، اما این هویت با هویت درگاه IKEv2 مطابقت نداشته باشد.
مشخص می‌کند که از حالت تهاجمی (Aggressive Mode) در IKEv1 استفاده شود یا حالت اصلی (Main Mode، پیش‌فرض).
فهرست جداشده با کاما از الگوریتم‌های AH که برای اتصال استفاده می‌شوند، به عنوان مثال sha1-sha256-modp1024. شیوه نگارش به صورت integrity[-dhgroup] است. برای IKEv2، چندین الگوریتم (جداشده با -) از یک نوع را می‌توان در یک پیشنهاد واحد گنجاند. IKEv1 تنها اولین الگوریتم را در یک پیشنهاد می‌گنجاند. تنها یکی از کلیدواژه‌های ah یا esp می‌تواند استفاده شود؛ بسته‌های ترکیبی AH+ESP پشتیبانی نمی‌شوند.

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

اگر dh-group مشخص شده باشد، راه‌اندازی و کلیدگذاری مجدد CHILD_SA/Quick Mode شامل یک تبادل Diffie-Hellman جداگانه خواهد بود (برای جزئیات به کلیدواژه esp مراجعه کنید).

بخش conn با نام <name> را می‌گنجاند.
توسط دیمن IKEv1 به نام pluto برای استفاده از حفاظت یکپارچگی AH برای بسته‌های رمزگذاری‌شده با ESP استفاده می‌شد، اما در charon پشتیبانی نمی‌شود. کلیدواژه ah الگوریتم‌های مورد استفاده برای حفاظت یکپارچگی با AH (اما بدون رمزنگاری) را مشخص می‌کند. بسته‌های ترکیبی AH+ESP پشتیبانی نمی‌شوند.
نحوه احراز هویت متقابل دو درگاه امنیتی؛ مقادیر قابل قبول عبارتند از psk یا secret برای کلیدهای از پیش به اشتراک گذاشته شده (pre-shared secrets)، pubkey (پیش‌فرض) برای امضاهای کلید عمومی و همچنین معادل‌های آن یعنی rsasig برای امضاهای دیجیتال RSA و ecdsasig برای امضاهای منحنی بیضوی DSA. مقدار never می‌تواند در صورتی استفاده شود که هرگز قرار نباشد مذاکره‌ای انجام یا پذیرفته شود (مفید برای اتصالات فقط شنت / shunt-only). امضاهای دیجیتال از هر نظر نسبت به رازهای به اشتراک گذاشته شده برتر هستند. IKEv1 علاوه بر این از مقادیر xauthpsk و xauthrsasig پشتیبانی می‌کند که احراز هویت گسترده (XAUTH) را علاوه بر حالت اصلی IKEv1 بر اساس رازهای مشترک یا امضاهای دیجیتال RSA فعال می‌کنند. این پارامتر منسوخ شده است، زیرا در IKEv2 دو همتا نیازی به توافق بر سر یک روش احراز هویت یکسان ندارند. در عوض از پارامتر leftauth برای تعریف روش‌های احراز هویت استفاده کنید.
چه عملیاتی، در صورت وجود، باید به طور خودکار در زمان راه‌اندازی IPsec انجام شود؛ مقادیر پذیرفته‌شده در حال حاضر عبارتند از add، route، start و ignore (پیش‌فرض). add یک اتصال را بدون شروع آن بارگذاری می‌کند. route یک اتصال را بارگذاری کرده و تله‌های هسته (kernel traps) را نصب می‌کند. اگر ترافیکی بین leftsubnet و rightsubnet تشخیص داده شود، اتصال برقرار می‌شود. start یک اتصال را بارگذاری کرده و بلافاصله آن را بالا می‌آورد. ignore اتصال را نادیده می‌گیرد. این معادل حذف اتصال از پرونده پیکربندی است. تنها به صورت محلی مرتبط است و طرف دیگر نیازی به توافق بر سر آن ندارد.
عملی را تعریف می‌کند که در صورت بسته شدن غیرمنتظره یک CHILD_SA توسط همتای دوردست باید انجام شود (برای معنای مقادیر به dpdaction مراجعه کنید). گزینه closeaction نباید در صورتی که همتا از احراز هویت مجدد (reauthentication) یا بررسی شناسه‌های یکتا (uniqueids) استفاده می‌کند استفاده شود، زیرا این رویدادها ممکن است عمل تعریف‌شده را در زمانی که مطلوب نیست تحریک کنند.
آیا فشرده‌سازی محتوا با IPComp در اتصال پیشنهاد شود یا خیر (فشرده‌سازی در سطح پیوند روی داده‌های رمزگذاری‌شده کار نمی‌کند، بنابراین برای مؤثر بودن، فشرده‌سازی باید پیش از رمزنگاری انجام شود)؛ مقادیر قابل قبول عبارتند از yes و no (پیش‌فرض). مقدار yes باعث می‌شود دیمن هر دو حالت فشرده و غیرفشرده را پیشنهاد دهد و فشرده را ترجیح دهد. مقدار no مانع از پیشنهاد یا پذیرش فشرده‌سازی توسط دیمن می‌شود.
استفاده از پروتکل تشخیص همتای مرده (DPD، بر اساس RFC 3706) را کنترل می‌کند که در آن پیام‌های اعلان R_U_THERE (در IKEv1) یا پیام‌های خالی INFORMATIONAL (در IKEv2) به صورت دوره‌ای برای بررسی زنده بودن همتای IPsec ارسال می‌شوند. مقادیر clear، hold و restart همگی DPD را فعال می‌کنند و عمل انجام‌شونده هنگام اتمام مهلت (timeout) را مشخص می‌سازند. با clear اتصال بدون اقدام دیگری بسته می‌شود. hold یک سیاست تله نصب می‌کند که ترافیک منطبق را گرفته و در صورت نیاز تلاش می‌کند اتصال را مجدداً مذاکره کند. restart بلافاصله تلاشی را برای مذاکره مجدد اتصال تحریک می‌کند. مقدار پیش‌فرض none است که ارسال فعال پیام‌های DPD را غیرفعال می‌کند.
فاصله زمانی دوره‌ای را تعریف می‌کند که با آن پیام‌های R_U_THERE یا تبادلات INFORMATIONAL به همتا ارسال می‌شوند. این پیام‌ها تنها زمانی ارسال می‌شوند که ترافیک دیگری دریافت نشده باشد. در IKEv2، مقدار 0 هیچ پیام INFORMATIONAL اضافی ارسال نمی‌کند و فقط از پیام‌های استاندارد (مانند پیام‌های مربوط به تجدید کلید) برای تشخیص همتایان مرده استفاده می‌نماید.
فاصله زمانی اتمام مهلت را تعریف می‌کند که پس از آن در صورت عدم فعالیت، تمام اتصالات به یک همتا حذف می‌شوند. این گزینه فقط برای IKEv1 اعمال می‌شود؛ در IKEv2 مهلت پیش‌فرض ارسال مجدد اعمال می‌گردد زیرا هر تبادلی برای تشخیص همتایان مرده استفاده می‌شود.
فاصله زمانی اتمام مهلت را تعریف می‌کند که پس از آن اگر یک CHILD_SA هیچ ترافیکی ارسال یا دریافت نکرده باشد، بسته می‌شود. شمارنده عدم فعالیت در طول تجدید کلید CHILD_SA بازنشانی می‌شود. این بدان معناست که مهلت عدم فعالیت برای داشتن اثر باید کمتر از فاصله تجدید کلید باشد.
هویتی را تعریف می‌کند که کلاینت برای پاسخ به درخواست EAP Identity از آن استفاده می‌کند. اگر روی سرور EAP تعریف شود، هویت تعریف‌شده به عنوان هویت همتا در طول احراز هویت EAP استفاده خواهد شد. مقدار ویژه %identity از روش EAP Identity برای درخواست هویت EAP از کلاینت استفاده می‌کند. در صورت عدم تعریف، از هویت IKEv2 به عنوان هویت EAP استفاده خواهد شد.
فهرست جداشده با کاما از الگوریتم‌های رمزنگاری/احراز هویت ESP برای اتصال، مانند aes128-sha256. شیوه نگارش به صورت encryption-integrity[-dhgroup][-esnmode] است. برای IKEv2، چندین الگوریتم (جداشده با -) از یک نوع می‌توانند در یک پیشنهاد واحد گنجانده شوند. IKEv1 تنها اولین الگوریتم را در یک پیشنهاد می‌گنجاند. تنها یکی از کلیدواژه‌های ah یا esp می‌تواند استفاده شود؛ بسته‌های ترکیبی AH+ESP پشتیبانی نمی‌شوند.

پیش‌فرض آن aes128-sha256 است. دیمن پیشنهاد پیش‌فرض گسترده خود را به این پیش‌فرض یا مقدار پیکربندی‌شده اضافه می‌کند. برای محدود کردن آن به پیشنهاد پیکربندی‌شده می‌توان یک علامت تعجب (!) در انتها اضافه کرد.

نکته: دیمن به عنوان پاسخ‌دهنده (responder)، به طور پیش‌فرض اولین پیشنهاد پیکربندی‌شده را که توسط همتا نیز پشتیبانی می‌شود انتخاب می‌کند. این رفتار را می‌توان از طریق strongswan.conf(5) تغییر داد تا در عوض اولین پیشنهاد قابل قبولی که توسط همتا ارسال شده است انتخاب شود. برای محدود کردن پاسخ‌دهنده به پذیرش تنها مجموعه‌های رمزنگاری خاص، می‌توان از پرچم سخت‌گیرانه (!، علامت تعجب) استفاده کرد، برای نمونه: aes256-sha512-modp4096!

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

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

کپسوله‌سازی UDP را برای بسته‌های ESP اجباری می‌کند حتی اگر هیچ شرایط NAT شناسایی نشود. این امر ممکن است به عبور از فایروال‌های محدودکننده کمک کند. به منظور وادار کردن همتا به کپسوله‌سازی بسته‌ها، بارهای داده تشخیص NAT جعل می‌شوند.
مشخص می‌کند که آیا قطعه‌بندی IKE (افزونه اختصاصی IKEv1 یا قطعه‌بندی IKEv2 طبق RFC 7383) استفاده شود یا خیر. مقادیر قابل قبول عبارتند از yes (پیش‌فرض)، accept، force و no. اگر روی yes تنظیم شود و همتا از آن پشتیبانی کند، پیام‌های بیش از حد بزرگ IKE به صورت قطعه‌قطعه ارسال می‌شوند. اگر روی accept تنظیم شود، پشتیبانی از قطعه‌بندی به همتا اعلام می‌شود اما دیمن پیام‌های خود را به صورت قطعه‌قطعه ارسال نمی‌کند. اگر روی force تنظیم شود (تنها برای IKEv1 پشتیبانی می‌شود)، پیام اولیه IKE در صورت نیاز از همان ابتدا قطعه‌بندی خواهد شد. در نهایت، تنظیم گزینه روی no اعلام پشتیبانی از این ویژگی را غیرفعال می‌کند.

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

فهرست جداشده با کاما از الگوریتم‌های رمزنگاری/احراز هویت IKE/ISAKMP SA مورد استفاده، مانند aes128-sha256-modp3072. شیوه نگارش به صورت encryption-integrity[-prf]-dhgroup است. اگر هیچ PRF تعیین نشود، الگوریتم‌های تعریف‌شده برای یکپارچگی (integrity) برای PRF استفاده می‌شوند. کلیدواژه‌های prf همانند الگوریتم‌های یکپارچگی هستند اما دارای پیشوند prf می‌باشند (مانند prfsha1، prfsha256 یا prfaesxcbc).
در IKEv2، چندین الگوریتم و پیشنهاد می‌توانند گنجانده شوند، مانند aes128-aes256-sha1-modp3072-modp2048,3des-sha1-md5-modp1024.

پیش‌فرض آن aes128-sha256-modp3072 است. دیمن پیشنهاد پیش‌فرض گسترده خود را به این پیش‌فرض یا مقدار پیکربندی‌شده اضافه می‌کند. برای محدود کردن آن به پیشنهاد پیکربندی‌شده می‌توان یک علامت تعجب (!) در انتها اضافه کرد.

نکته: دیمن به عنوان پاسخ‌دهنده اولین پیشنهاد پشتیبانی‌شده دریافتی از همتا را می‌پذیرد. برای محدود کردن پاسخ‌دهنده به پذیرش تنها مجموعه‌های رمزنگاری خاص، می‌توان از پرچم سخت‌گیرانه (!، علامت تعجب) استفاده کرد، مانند: aes256-sha512-modp4096!

نقطه کد فیلد خدمات تفکیک‌شده (DSCP) برای تنظیم روی بسته‌های خروجی IKE ارسال‌شده از این اتصال. مقدار یک رشته کدگذاری‌شده باینری شش رقمی است که نقطه کد تنظیمی را طبق RFC 2474 تعریف می‌کند.
مدت زمانی که کانال کلیدگذاری یک اتصال (ISAKMP یا IKE SA) باید پیش از مذاکره مجدد دوام داشته باشد. همچنین بخش انقضا/تولید مجدد کلید (EXPIRY/REKEY) را در زیر ببینید.
مشخص می‌کند که آیا سیاست‌های IPsec توسط دیمن charon در هسته برای یک اتصال معین نصب شوند یا خیر. این امکان همکاری مسالمت‌آمیز را مثلاً با دیمن Mobile IPv6 به نام mip6d که می‌خواهد سیاست‌های هسته را کنترل کند فراهم می‌سازد. مقادیر قابل قبول عبارتند از yes (پیش‌فرض) و no.
کدام پروتکل تبادل کلید باید برای آغاز اتصال استفاده شود. اتصالات مشخص‌شده با ike در زمان شروع از IKEv2 استفاده می‌کنند، اما هنگام پاسخ دادن هر نسخه پروتکلی را می‌پذیرند.
چند تلاش (یک عدد صحیح یا %forever) باید برای مذاکره یک اتصال یا جایگزینی برای آن قبل از تسلیم شدن انجام شود (پیش‌فرض 3). مقدار %forever به معنای «هرگز تسلیم نشو» است. تنها به صورت محلی مرتبط است و طرف دیگر نیازی به توافق بر سر آن ندارد.
نشانی IP رابط شبکه عمومی شرکت‌کننده سمت چپ یا یکی از چندین مقدار جادویی. مقدار %any (پیش‌فرض) برای نقطه پایانی محلی نشان‌دهنده نشانی‌ای است که باید (توسط کلیدگذاری خودکار) در طول مذاکره پر شود. اگر همتای محلی راه‌اندازی اتصال را آغاز کند، جدول مسیریابی برای تعیین نشانی IP محلی صحیح بررسی می‌شود. در صورتی که همتای محلی به راه‌اندازی اتصال پاسخ دهد، هر نشانی IP که به یک رابط محلی اختصاص یافته باشد پذیرفته خواهد شد.

پیشوند % در جلوی یک نام دامنه کاملاً واجد شرایط (FQDN) یا یک نشانی IP به طور ضمنی مقدار leftallowany=yes را تنظیم می‌کند.

اگر %any برای نقطه پایانی دوردست استفاده شود، به معنای واقعی کلمه هر نشانی IP است.

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

برای محدود کردن اتصال به محدوده خاصی از میزبان‌ها، می‌توان یک محدوده ( 10.1.0.0-10.2.255.255 ) یا یک زیرشبکه ( 10.1.0.0/16 ) را مشخص کرد، و چندین نشانی، محدوده و زیرشبکه را می‌توان با کاما از هم جدا نمود. در حالی که می‌توان این موارد را آزادانه ترکیب کرد، برای شروع اتصال حداقل یک مورد غیر محدوده/زیرشبکه لازم است.

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

یک تغییردهنده برای left، که باعث می‌شود مانند %any رفتار کند هرچند یک نشانی IP یا نام دامنه مشخص تعیین شده باشد.
روش احراز هویت برای استفاده محلی (left) یا الزام برای سمت دوردست (right). مقادیر قابل قبول عبارتند از pubkey برای احراز هویت کلید عمومی (RSA/ECDSA)، psk برای احراز هویت با کلید از پیش به اشتراک گذاشته شده، eap برای (الزام به) استفاده از پروتکل احراز هویت گسترش‌پذیر (EAP) در IKEv2، و xauth برای احراز هویت گسترده IKEv1 (XAuth).

برای الزام قدرت کلید عمومی زنجیره اعتماد برای سمت دوردست، نوع کلید را به دنبال حداقل قدرت به بیت مشخص کنید (برای مثال 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 پیکربندی شده باشد (زیر را ببینید)، این نوع کلیدها و الگوریتم‌های هش به عنوان محدودیت‌هایی در برابر طرح‌های احراز هویت امضای IKEv2 مورد استفاده توسط سمت دوردست نیز اعمال می‌شوند.

اگر هر دو همتا از RFC 7427 («احراز هویت امضا در IKEv2») پشتیبانی کنند، الگوریتم‌های هش خاصی برای استفاده در طول احراز هویت IKEv2 می‌توانند پیکربندی شوند. نحو همانند بالا است، اما با پیشوند ike:. برای مثال، با ike:pubkey-sha384-sha256 یک طرح امضای کلید عمومی با SHA-384 یا SHA-256 برای احراز هویت استفاده می‌شود، به همان ترتیب و بسته به الگوریتم‌های هش پشتیبانی‌شده توسط همتا. اگر الگوریتم هش خاصی پیکربندی نشده باشد، پیش‌فرض ترجیح دادن الگوریتمی است که با قدرت کلید امضا مطابقت داشته باشد یا از آن بیشتر باشد. اگر هیچ محدودیتی با پیشوند ike: پیکربندی نشده باشد، هر محدودیت طرح امضا (بدون پیشوند ike:) برای احراز هویت IKEv2 نیز اعمال خواهد شد، مگر اینکه این مورد در strongswan.conf(5) غیرفعال شده باشد.

برای استفاده یا الزام امضاهای RSASSA-PSS از rsa/pss به جای rsa استفاده کنید مانند ike:rsa/pss-sha256. اگر محدودیت‌های pubkey یا rsa پیکربندی شده باشند، امضاهای RSASSA-PSS تنها در صورتی استفاده/پذیرفته می‌شوند که در strongswan.conf(5) فعال شده باشند.

برای eap، یک روش اختیاری EAP می‌تواند اضافه شود. روش‌های تعریف‌شده فعلی عبارتند از eap-aka، eap-gtc، eap-md5، eap-mschapv2، eap-peap، eap-sim، eap-tls، eap-ttls، eap-dynamic و eap-radius. به عنوان جایگزین، شماره‌های روش EAP اختصاص‌یافته توسط IANA پذیرفته می‌شوند. روش‌های EAP مختص فروشنده به شکل eap-type-vendor (مانند eap-7-12345) تعریف می‌شوند. برای تعیین محدودیت‌های امضا و زنجیره اعتماد برای EAP-(T)TLS، یک دونقطه (:) به روش EAP اضافه کنید و پس از آن نوع/اندازه کلید و الگوریتم هش را همان‌طور که در بالا توضیح داده شد ذکر کنید. برای xauth، یک زیرسیستم احراز هویت XAuth می‌تواند مشخص شود، مانند xauth-generic یا xauth-eap. اگر XAuth در leftauth استفاده شود، احراز هویت ترکیبی (Hybrid) استفاده می‌شود. برای احراز هویت سنتی XAuth، مقدار XAuth را در leftauth2 تعریف کنید.

مشابه leftauth، اما یک تبادل احراز هویت اضافی را تعریف می‌کند. در IKEv1، تنها XAuth می‌تواند در دور دوم احراز هویت استفاده شود. IKEv2 از چندین دور کامل احراز هویت با استفاده از «Multiple Authentication Exchanges» تعریف‌شده در RFC 4739 پشتیبانی می‌کند. این ویژگی به عنوان مثال امکان احراز هویت جداگانه میزبان و کاربر را فراهم می‌سازد.
نام متمایز (DN) مرجع صدور گواهی که باید در مسیر اعتماد از گواهی شرکت‌کننده سمت چپ تا مرجع صدور گواهی ریشه قرار داشته باشد. %same به این معنی است که مقدار پیکربندی‌شده برای شرکت‌کننده سمت راست باید مجدداً استفاده شود.
مشابه leftca، اما برای دور دوم احراز هویت (تنها در IKEv2).
مسیر گواهی X.509 شرکت‌کننده سمت چپ. پرونده می‌تواند در قالب PEM یا DER کدگذاری شود. گواهی‌های OpenPGP نیز پشتیبانی می‌شوند. هم مسیرهای مطلق و هم مسیرهای نسبی نسبت به /etc/ipsec.d/certs پذیرفته می‌شوند. به طور پیش‌فرض leftcert مقدار leftid را برابر با نام متمایز (DN) موضوع گواهی قرار می‌دهد. با این حال، شناسه شرکت‌کننده سمت چپ را می‌توان با تعیین مقدار leftid که باید توسط گواهی تأیید شود، تغییر داد.
مقداری به شکل %smartcard[<slot nr>[@<module>]]:<keyid> یک گواهی خاص را برای بارگذاری از یک زیرسیستم PKCS#11 برای این اتصال تعریف می‌کند. برای جزئیات در مورد تعاریف کارت هوشمند به ipsec.secrets(5) مراجعه کنید. گزینه leftcert تنها در صورتی لازم است که انتخاب گواهی با leftid کافی نباشد، مثلاً اگر چندین گواهی از یک موضوع یکسان استفاده کنند.
چندین مسیر گواهی یا زیرسیستم‌های PKCS#11 را می‌توان در یک فهرست جداشده با کاما مشخص کرد. دیمن در صورت امکان گواهی را بر اساس درخواست‌های گواهی دریافتی قبل از اعمال اولین مورد انتخاب می‌کند.
مشابه leftcert، اما برای دور دوم احراز هویت (تنها در IKEv2).
فهرست جداشده با کاما از شناسه شیءهای (OID) سیاست گواهی که گواهی همتا باید داشته باشد. OIDها با استفاده از نمایش عددی نقطه‌دار مشخص می‌شوند.
فهرست جداشده با کاما از نشانی‌های سرور DNS برای تبادل به عنوان ویژگی‌های پیکربندی. در آغازگر (initiator)، سرور یک نشانی ثابت IPv4/IPv6 یا %config4/%config6 برای درخواست ویژگی‌ها بدون نشانی است. در پاسخ‌دهنده (responder)، تنها نشانی‌های ثابت IPv4/IPv6 مجاز هستند و سرورهای DNS اختصاص داده شده به کلاینت را تعریف می‌کنند.
آیا شرکت‌کننده سمت چپ با استفاده از iptables برای ترافیک از leftsubnet عملیات دیوار آتش بازارسال (شامل تغییر چهره / masquerading) انجام می‌دهد، که باید پس از برقراری اتصال (برای ترافیک به زیرشبکه دیگر) خاموش شود یا خیر؛ مقادیر قابل قبول عبارتند از yes و no (پیش‌فرض). نباید در همان توصیف اتصال همراه با leftupdown استفاده شود. به عنوان یک پارامتر برای اسکریپت پیش‌فرض ipsec _updown پیاده‌سازی شده است. یادداشت‌های زیر را ببینید. تنها به صورت محلی مرتبط است و طرف دیگر نیازی به توافق بر سر آن ندارد.

اگر یک یا هر دو دروازه امنیتی عملیات دیوار آتش بازارسال (احتمالاً شامل ماسکرادینگ) را انجام می‌دهند و این مورد با استفاده از پارامترهای firewall مشخص شده باشد، تونل‌های برقرار شده با IPsec از آن مستثنی می‌شوند تا بسته‌ها بتوانند بدون تغییر از میان تونل‌ها عبور کنند. (این بدان معنی است که تمام زیرشبکه‌های متصل‌شده به این روش باید بلوک‌های نشانی زیرشبکه متمایز و غیرهمپوشان داشته باشند.) این کار توسط اسکریپت پیش‌فرض ipsec _updown انجام می‌شود.

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

یک فهرست جداشده با کاما از نام گروه‌ها. اگر پارامتر leftgroups حاضر باشد، همتا باید عضو حداقل یکی از گروه‌های تعریف‌شده توسط این پارامتر باشد.
مشابه leftgroups، اما برای دور دوم احراز هویت تعریف‌شده با leftauth2.
یک جفت قانون INPUT و OUTPUT در iptables با استفاده از اسکریپت پیش‌فرض ipsec _updown درج می‌کند، بنابراین در صورتی که رابط داخلی میزبان بخشی از زیرشبکه کلاینت مذاکره‌شده باشد، دسترسی به خود میزبان را امکان‌پذیر می‌سازد. مقادیر قابل قبول عبارتند از yes و no (پیش‌فرض).
نحوه شناسایی شرکت‌کننده سمت چپ برای احراز هویت؛ پیش‌فرض آن left یا موضوع گواهی پیکربندی‌شده با leftcert است. اگر leftcert پیکربندی شده باشد، هویت باید توسط گواهی تأیید شود.

می‌تواند یک نشانی IP، یک نام دامنه کاملاً واجد شرایط (FQDN)، یک نشانی ایمیل یا یک نام متمایز (DN) باشد که نوع شناسه به طور خودکار تعیین شده و رشته به کدگذاری مناسب تبدیل می‌شود. قوانین این تبدیل در بخش تجزیه هویت (IDENTITY PARSING) در زیر توضیح داده شده است.

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

برای IKEv2 و rightid پیشوند % در جلوی هویت مانع از ارسال IDr توسط دیمن در درخواست IKE_AUTH خود می‌شود و به آن اجازه می‌دهد هویت پیکربندی‌شده را با موضوع و subjectAltNames موجود در گواهی پاسخ‌دهنده اعتبارسنجی کند (در غیر این صورت فقط با IDr بازگردانده شده توسط پاسخ‌دهنده مقایسه می‌شود). IDr ارسال‌شده توسط آغازگر ممکن است در صورتی که پاسخ‌دهنده مقدار متفاوتی را برای leftid پیکربندی کرده باشد، مانع از یافتن پیکربندی توسط آن شود.

هویت مورد استفاده برای احراز هویت دوم برای شرکت‌کننده سمت چپ (فقط در IKEv2)؛ پیش‌فرض آن leftid است.
درگاه UDP که شرکت‌کننده سمت چپ برای ارتباط IKE استفاده می‌کند. اگر مشخص نشود، از درگاه 500 استفاده می‌شود و در صورت شناسایی NAT یا فعال بودن MOBIKE، درگاه به 4500 شناور می‌شود. تعیین یک درگاه محلی IKE متفاوت از مقدار پیش‌فرض علاوه بر این نیاز به پیاده‌سازی سوکتی دارد که روی این درگاه گوش دهد.
انتخاب‌کننده ترافیک را به یک پروتکل و/یا درگاه واحد محدود می‌کند. این گزینه اکنون منسوخ شده است، اطلاعات پروتکل/درگاه را می‌توان برای هر زیرشبکه مستقیماً در leftsubnet تعریف کرد.
کلید عمومی شرکت‌کننده سمت چپ برای احراز هویت امضای کلید عمومی، در قالب PKCS#1 با استفاده از کدگذاری شانزده‌شانزدهی (پیشوند 0x) یا base64 (پیشوند 0s). با پیشوند اختیاری dns: یا ssh: در جلوی 0x یا 0s، کلید عمومی به ترتیب در قالب کلید عمومی RFC 3110 (نه کل RR، فقط بخش کلید RSA) یا RFC 4253 مورد انتظار است. همچنین مسیر پرونده حاوی کلید عمومی با کدگذاری PEM، DER یا SSH پذیرفته می‌شود. هم مسیرهای مطلق و هم مسیرهای نسبی نسبت به /etc/ipsec.d/certs پذیرفته می‌شوند.
مقادیر پذیرفته‌شده عبارتند از never یا no، always یا yes، و ifasked (پیش‌فرض)، که مورد اخیر به این معنی است که همتا باید یک بار داده درخواست گواهی ارسال کند تا گواهی را در پاسخ دریافت نماید.
فهرست جداشده با کاما از IPهای مبدا داخلی برای استفاده در یک تونل، که به عنوان IP مجازی نیز شناخته می‌شود. اگر مقدار یکی از مترادف‌های %config، %cfg، %modeconfig، یا %modecfg باشد، یک نشانی (از خانواده نشانی تونل) از همتا درخواست می‌شود. با %config4 و %config6 نشانی از خانواده نشانی مشخص‌شده به طور صریح درخواست خواهد شد. اگر یک نشانی IP پیکربندی شده باشد، از پاسخ‌دهنده درخواست می‌شود، که البته در پاسخ دادن با نشانی متفاوت آزاد است.
فهرست جداشده با کاما از IPهای مبدا داخلی برای استفاده در یک تونل برای همتای دوردست. اگر مقدار %config در سمت پاسخ‌دهنده باشد، آغازگر باید نشانی‌ای را پیشنهاد دهد که سپس پس‌فرستاده می‌شود. همچنین استخرهای نشانی به صورت network/netmask و from-to یا استفاده از استخر نشانی IP خارجی با استفاده از %poolname پشتیبانی می‌شوند، که در آن poolname نام استخر نشانی IP استفاده‌شده برای جستجو است.
زیرشبکه خصوصی پشت شرکت‌کننده سمت چپ، که به صورت network/netmask بیان می‌شود؛ در صورت حذف، اساساً برابر با left/32 فرض می‌شود، به این معنی که انتهای چپ اتصال فقط به شرکت‌کننده سمت چپ می‌رود. زیرشبکه‌های پیکربندی‌شده همتاها ممکن است متفاوت باشند؛ پروتکل آن را به بزرگترین زیرشبکه مشترک محدود می‌کند. در IKEv1، این ممکن است به مشکلاتی با سایر پیاده‌سازی‌ها منجر شود، مطمئن شوید که زیرشبکه‌های یکسانی را در چنین پیکربندی‌هایی تنظیم کنید. IKEv2 از چندین زیرشبکه جداشده با کاما پشتیبانی می‌کند. IKEv1 فقط اولین زیرشبکه چنین تعریفی را تفسیر می‌کند، مگر اینکه افزونه Cisco Unity فعال باشد. این به دلیل محدودیت پروتکل IKEv1 است که فقط یک جفت زیرشبکه را در هر CHILD_SA مجاز می‌داند. بنابراین برای تونل کردن چندین زیرشبکه، باید برای هر جفت زیرشبکه یک مدخل conn تعریف شده و بالا آورده شود.

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

نمونه‌ها: leftsubnet=10.0.0.1[tcp/http],10.0.0.2[6/80] یا leftsubnet=fec1::1[udp],10.0.0.0/16[/53]. به جای حذف هر مقدار، می‌توان از %any برای همان اثر استفاده کرد، مانند: leftsubnet=fec1::1[udp/%any],10.0.0.0/16[%any/53].

اگر پروتکل icmp یا ipv6-icmp باشد، اگر مقدار درگاه کمتر از 256 باشد به عنوان نوع پیام ICMP تفسیر می‌شود یا اگر بزرگتر یا مساوی 256 باشد به عنوان نوع و کد تفسیر می‌شود، با نوع در باارزش‌ترین 8 بیت و کد در کم‌ارزش‌ترین 8 بیت.

مقدار درگاه می‌تواند به صورت جایگزین مقدار %opaque را برای انتخاب‌کننده‌های OPAQUE طبق RFC 4301 بگیرد، یا یک محدوده عددی به شکل 1024-65535. در حال حاضر هیچ‌کدام از زیرسیستم‌های هسته از محدوده‌های مات یا درگاه پشتیبانی نمی‌کنند و در عوض از %any برای نصب سیاست استفاده می‌نمایند.

به جای تعیین یک زیرشبکه، می‌توان از %dynamic برای جایگزینی آن با نشانی IKE استفاده کرد، که همان اثر حذف کامل leftsubnet را دارد. استفاده از %dynamic می‌تواند برای تعریف چندین انتخاب‌کننده پویا استفاده شود که هر کدام به طور بالقوه دارای تعریف پروتکل/درگاه متفاوتی هستند.

چه اسکریپت «updown»ی برای تنظیم مسیریابی و/یا دیوار آتش در زمان تغییر وضعیت اتصال اجرا شود (پیش‌فرض ipsec _updown). می‌تواند شامل پارامترهای مکانی جداشده با فاصله باشد (اگرچه این کار مستلزم قرار دادن کل رشته در گیومه است)؛ گنجاندن فراکاراکترهای پوسته غیرعاقلانه است. تنها به صورت محلی مرتبط است و طرف دیگر نیازی به توافق بر سر آن ندارد. Charon از اسکریپت updown فقط برای درج قوانین دیوار آتش استفاده می‌کند، زیرا مسیریابی مستقیماً در خود دیمن پیاده‌سازی شده است.
تعداد بایت‌های منتقل‌شده روی یک IPsec SA پیش از انقضای آن.
تعداد بسته‌های منتقل‌شده روی یک IPsec SA پیش از انقضای آن.
مدت زمانی که یک نمونه خاص از اتصال (مجموعه‌ای از کلیدهای رمزنگاری/احراز هویت برای بسته‌های کاربر) باید از زمان مذاکره موفق تا انقضا دوام داشته باشد؛ مقادیر قابل قبول یک عدد صحیح اختیاری همراه با s (زمان به ثانیه) یا یک عدد اعشاری همراه با m، h، یا d (زمان به ترتیب به دقیقه، ساعت یا روز) (پیش‌فرض 1h، حداکثر 24h). به طور معمول، اتصال قبل از انقضا (از طریق کانال کلیدگذاری) مجدداً مذاکره می‌شود (به margintime مراجعه کنید). دو طرف نیازی به توافق دقیق بر سر lifetime ندارند، اگرچه اگر توافق نداشته باشند، مقداری اتصالات جایگزین‌شده روی طرفی که فکر می‌کند طول عمر طولانی‌تر است انباشته خواهد شد. همچنین بخش انقضا/تولید مجدد کلید (EXPIRY/REKEY) را در زیر ببینید.
چند بایت قبل از انقضای IPsec SA (به lifebytes مراجعه کنید) باید تلاش‌ها برای مذاکره یک جایگزین آغاز شود.
چند بسته قبل از انقضای IPsec SA (به lifepackets مراجعه کنید) باید تلاش‌ها برای مذاکره یک جایگزین آغاز شود.
چه مدت قبل از انقضای اتصال یا انقضای کانال کلیدگذاری باید تلاش‌ها برای مذاکره یک جایگزین آغاز شود؛ مقادیر قابل قبول مانند lifetime است (پیش‌فرض 9m). تنها به صورت محلی مرتبط است و طرف دیگر نیازی به توافق بر سر آن ندارد. همچنین بخش انقضا/تولید مجدد کلید (EXPIRY/REKEY) را در زیر ببینید.
یک نشان XFRM روی سیاست ورودی و IPsec SA و سیاست خروجی تنظیم می‌کند. اگر ماسک وجود نداشته باشد، ماسک پیش‌فرض 0xffffffff فرض می‌شود. مقدار ویژه %unique یک مقدار یکتا به هر IPsec SA تازه ایجادشده اختصاص می‌دهد. برای اینکه نشان برای هر جهت IPsec SA (ورودی/خروجی) نیز یکتا باشد، می‌توان از مقدار ویژه %unique-dir استفاده کرد.
یک نشان XFRM روی سیاست ورودی تنظیم می‌کند (نه روی SA). اگر ماسک وجود نداشته باشد، ماسک پیش‌فرض 0xffffffff فرض می‌شود.
یک نشان XFRM روی IPsec SA و سیاست خروجی تنظیم می‌کند. اگر ماسک وجود نداشته باشد، ماسک پیش‌فرض 0xffffffff فرض می‌شود.
پروتکل MOBIKE در IKEv2 تعریف‌شده در RFC 4555 را فعال می‌کند. مقادیر پذیرفته‌شده عبارتند از yes (پیش‌فرض) و no. اگر روی no تنظیم شود، دیمن charon به طور فعال MOBIKE را به عنوان آغازگر پیشنهاد نخواهد داد و اعلان MOBIKE_SUPPORTED را به عنوان پاسخ‌دهنده نادیده می‌گیرد.
مشخص می‌کند که از کدام حالت برای اختصاص IP مجازی استفاده شود. مقادیر پذیرفته‌شده عبارتند از push و pull (پیش‌فرض). حالت Push در حال حاضر با IKEv2 پشتیبانی نمی‌شود. تنظیمات باید در هر دو طرف یکسان باشد.
آیا تجدید کلید یک IKE_SA باید همتا را نیز مجدداً احراز هویت کند یا خیر. در IKEv1، احراز هویت مجدد همیشه انجام می‌شود. در IKEv2، مقدار no بدون حذف IPsec SAها تجدید کلید می‌کند، مقدار yes (پیش‌فرض) یک IKE_SA جدید را از ابتدا ایجاد کرده و سعی می‌کند تمام IPsec SAها را دوباره ایجاد کند.
آیا یک اتصال باید زمانی که در حال انقضا است مجدداً مذاکره شود یا خیر؛ مقادیر قابل قبول عبارتند از yes (پیش‌فرض) و no. دو طرف نیازی به توافق ندارند، اما در حالی که مقدار no مانع از درخواست مذاکره مجدد توسط charon می‌شود، مانع از پاسخگویی به مذاکره مجدد درخواست‌شده از طرف مقابل نمی‌گردد، بنابراین no تا حد زیادی بی‌اثر خواهد بود مگر اینکه هر دو طرف بر سر آن توافق کنند. همچنین به reauth مراجعه کنید.
حداکثر درصدی که marginbytes، marginpackets و margintime باید به طور تصادفی افزایش یابند تا فواصل تجدید کلید تصادفی شوند (برای میزبان‌های با اتصالات متعدد مهم است)؛ مقادیر قابل قبول یک عدد صحیح است که ممکن است از 100 بیشتر باشد و به دنبال آن `%' می‌آید (پیش‌فرض 100%). مقدار marginTYPE پس از این افزایش تصادفی نباید از lifeTYPE تجاوز کند (که در آن TYPE یکی از bytes، packets یا time است). مقدار 0% تصادفی‌سازی را سرکوب می‌کند. تنها به صورت محلی مرتبط است و طرف دیگر نیازی به توافق بر سر آن ندارد. همچنین بخش انقضا/تولید مجدد کلید (EXPIRY/REKEY) را در زیر ببینید.
اندازه پنجره بازپخش (replay window) در IPsec برای این اتصال. با مقدار پیش‌فرض 1- مقدار پیکربندی‌شده با charon.replay_window در strongswan.conf(5) استفاده می‌شود. مقادیر بزرگتر از 32 تنها با استفاده از زیرسیستم Netlink پشتیبانی می‌شوند؛ مقدار 0 حفاظت از بازپخش IPsec را غیرفعال می‌کند.
شناسه reqid را برای یک اتصال معین روی یک مقدار ثابت از پیش پیکربندی‌شده تنظیم می‌کند.
الگوریتم HMAC-SHA-256 با برش 128 بیتی در IPsec استفاده می‌شود. برای سازگاری با پیاده‌سازی‌هایی که به اشتباه از برش 96 بیتی استفاده می‌کنند، این گزینه ممکن است برای پیکربندی طول برش کوتاه‌تر در هسته فعال شود. این گزینه مذاکره نمی‌شود، بنابراین فقط با همتایانی کار می‌کند که از طول برش نادرست استفاده می‌کنند (یا این گزینه را فعال کرده‌اند).
تعداد بایت‌ها برای پدینگ (فاصله‌گذاری) داده‌های بار مفید ESP. محرمانگی جریان ترافیک (TFC) در حال حاضر در IKEv2 پشتیبانی می‌شود و فقط برای بسته‌های خروجی اعمال می‌گردد. مقدار ویژه %mtu بسته‌های ESP را با پدینگ پر می‌کند تا اندازه MTU را داشته باشند.
نوع اتصال؛ مقادیر پذیرفته‌شده در حال حاضر عبارتند از tunnel (پیش‌فرض) که نشان‌دهنده تونل میزبان به میزبان، میزبان به زیرشبکه یا زیرشبکه به زیرشبکه است؛ transport که نشان‌دهنده حالت انتقال میزبان به میزبان است؛ transport_proxy که نشان‌دهنده حالت پروکسی انتقال ویژه Mobile IPv6 است؛ passthrough که نشان می‌دهد اصلاً هیچ پردازش IPsec نباید انجام شود؛ drop که نشان می‌دهد بسته‌ها باید دور انداخته شوند.
نقش در پروتکل XAuth را در صورت فعال شدن با authby=xauthpsk یا authby=xauthrsasig مشخص می‌کند. مقادیر پذیرفته‌شده عبارتند از server و client (پیش‌فرض).
هویت/نام کاربری را تعریف می‌کند که کلاینت برای پاسخ به درخواست XAuth از آن استفاده می‌کند. اگر تعریف نشود، هویت IKEv1 به عنوان هویت XAuth استفاده خواهد شد.

پارامترهای زیر فقط به عملکرد افزونه میانجی‌گری IKEv2 مربوط می‌شوند.

آیا این اتصال یک اتصال میانجی‌گری است یا خیر، یعنی آیا از این اتصال برای میانجی‌گری اتصالات دیگر استفاده می‌شود یا خیر. اتصالات میانجی‌گری هیچ Child SA ایجاد نمی‌کنند. مقادیر قابل قبول عبارتند از no (پیش‌فرض) و yes.
نام اتصالی که این اتصال باید از طریق آن میانجی‌گری شود. در صورت ارائه، اتصال از طریق اتصال میانجی‌گری نام‌برده میانجی‌گری خواهد شد. اتصال میانجی‌گری باید دارای mediation=yes باشد.
شناسه‌ای که همتا با آن در سرور میانجی‌گری شناخته می‌شود، یعنی شناسه‌ای که طرف دیگر این اتصال به عنوان leftid خود در اتصالش به سرور میانجی‌گری استفاده می‌کند. این شناسه‌ای است که ما از سرور میانجی‌گری درخواست می‌کنیم تا ما را با آن میانجی‌گری کند. اگر me_peerid داده نشود، از rightid این اتصال به عنوان شناسه همتا استفاده خواهد شد.

این بخش‌ها اختیاری هستند و می‌توانند برای اختصاص پارامترهای خاص به یک مرجع صدور گواهی (CA) استفاده شوند. از آنجا که دیمن‌ها به طور خودکار گواهی‌های CA را از /etc/ipsec.d/cacerts وارد می‌کنند، نیازی به اضافه کردن صریح آن‌ها با یک بخش CA وجود ندارد، مگر اینکه بخواهید پارامترهای خاصی (مانند یک CRL) را به یک CA اختصاص دهید.

بخش ca با نام <name> را می‌گنجاند.
در حال حاضر می‌تواند مقدار ignore (پیش‌فرض) یا add داشته باشد.
مسیری را به گواهی CA یا به صورت نسبی نسبت به /etc/ipsec.d/cacerts یا به عنوان یک مسیر مطلق تعریف می‌کند.
مقداری به شکل %smartcard[<slot nr>[@<module>]]:<keyid> یک گواهی CA خاص را برای بارگذاری از یک زیرسیستم PKCS#11 برای این CA تعریف می‌کند. برای جزئیات در مورد تعاریف کارت هوشمند به ipsec.secrets(5) مراجعه کنید.
یک نقطه توزیع CRL را تعریف می‌کند (URI از نوع ldap، http یا پرونده).
مترادف برای crluri.
یک نقطه توزیع جایگزین CRL را تعریف می‌کند (URI از نوع ldap، http یا پرونده).
یک URI برای OCSP تعریف می‌کند.
مترادف برای ocspuri.
یک URI جایگزین برای OCSP تعریف می‌کند.
آدرس پایه URI را برای ویژگی Hash and URL که توسط IKEv2 پشتیبانی می‌شود تعریف می‌کند. به جای تبادل گواهی‌های کامل، IKEv2 اجازه می‌دهد تا یک URI ارسال شود که به گواهی کدگذاری‌شده با DER اشاره دارد. URIهای گواهی با افزودن هش SHA1 گواهی‌های کدگذاری‌شده با DER به این URI پایه ساخته می‌شوند.

در حال حاضر، تنها بخش config شناخته‌شده برای نرم‌افزار IPsec، بخش با نام setup است که شامل اطلاعات مورد استفاده در زمان راه‌اندازی نرم‌افزار می‌باشد. نام‌های پارامتر پذیرفته‌شده فعلی در بخش config setup عبارتند از:

در صورت فعال بودن، فهرست‌های ابطال گواهی (CRL) که از طریق HTTP یا LDAP دریافت می‌شوند، در /etc/ipsec.d/crls/ تحت یک نام پرونده یکتا که از کلید عمومی مرجع صدور گواهی مشتق شده است ذخیره (کَش) می‌شوند.
میزان خروجی اشکال‌زدایی charon که باید ثبت شود. یک فهرست جداشده با کاما شامل جفت‌های نوع/سطح می‌تواند مشخص شود، به عنوان مثال: dmn 3, ike 1, net -1. مقادیر قابل قبول برای انواع عبارتند از dmn،mgr،ike،chd،job،cfg،knl،net،asn،enc،lib،esp،tls، tnc،imc،imv،pts و سطح یکی از مقادیر -1, 0, 1, 2, 3, 4 (برای خاموش، حسابرسی، کنترل، کنترل بیشتر، خام، خصوصی) است. به طور پیش‌فرض، سطح برای همه انواع روی 1 تنظیم شده است. برای انعطاف‌پذیری بیشتر به بخش LOGGER CONFIGURATION در strongswan.conf(5) مراجعه کنید.
تعریف می‌کند که آیا برای موفقیت احراز هویت همتا بر اساس امضاهای RSA، باید یک CRL تازه در دسترس باشد یا خیر. IKEv2 علاوه بر این مقدار ifuri را می‌شناسد که اگر حداقل یک CRL URI تعریف شده باشد به yes و اگر هیچ URI شناخته‌شده‌ای نباشد به no تبدیل می‌شود.
آیا شناسه یک شرکت‌کننده خاص باید یکتا نگه داشته شود، به طوری که هر IKE_SA جدید با استفاده از یک شناسه، جایگزین همه نمونه‌های قدیمی با آن شناسه تلقی شود؛ مقادیر قابل قبول عبارتند از yes (پیش‌فرض)، no و never. شناسه‌های شرکت‌کنندگان معمولاً یکتا هستند، بنابراین یک IKE_SA جدید با استفاده از همان شناسه تقریباً همیشه به قصد جایگزینی یک نمونه قدیمی است. تفاوت بین no و never در این است که اگر گزینه no باشد، دیمن هنگام دریافت اعلان INITIAL_CONTACT نمونه‌های قدیمی IKE_SA را جایگزین می‌کند، اما اگر never پیکربندی شده باشد این اعلان‌ها را نادیده می‌گیرد. دیمن همچنین مقدار replace را می‌پذیرد که معادل yes است و مقدار keep را برای رد راه‌اندازی IKE_SA جدید و حفظ نمونه تکراری که زودتر برقرار شده است می‌پذیرد.

نوع و کدگذاری باینری رشته‌های هویت مشخص‌شده در leftid به صورت زیر تشخیص داده می‌شوند:

•
اگر مقدار رشته حاوی علامت مساوی (=) باشد، فرض می‌شود که یک نام متمایز (Distinguished Name) است، با RDNهایی که با کاما (,) یا اسلش (/ - رشته برای استفاده از این نحو باید با اسلش شروع شود) از هم جدا شده‌اند. تلاشی برای ایجاد یک کدگذاری باینری ASN.1 از این رشته انجام می‌شود. در صورت عدم موفقیت، نوع به KEY_ID تغییر می‌یابد و مقدار رشته به صورت تحت‌اللفظی به عنوان کدگذاری پذیرفته می‌شود.
•
اگر مقدار رشته شامل @ باشد، نوع آن به موقعیت آن نویسه بستگی دارد:
•
اگر رشته با @# شروع شود، نوع روی KEY_ID تنظیم می‌شود و رشته بعد از آن پیشوند به عنوان مقدار باینری با کدگذاری شانزده‌شانزدهی هویت در نظر گرفته می‌شود.
•
اگر رشته با @@ شروع شود، نوع روی USER_FQDN تنظیم می‌شود و کدگذاری، رشته تحت‌اللفظی بعد از آن پیشوند است.
•
اگر رشته با @ شروع شود، نوع روی FQDN تنظیم می‌شود و کدگذاری، رشته تحت‌اللفظی بعد از آن پیشوند است.
•
تمام رشته‌های باقی‌مانده حاوی @ به عنوان نوع USER_FQDN/RFC822 با مقدار رشته تحت‌اللفظی به عنوان کدگذاری در نظر گرفته می‌شوند.
•
اگر مقدار فاقد هرگونه نویسه @ یا = باشد، به صورت زیر تجزیه می‌شود:
•
اگر مقدار یک رشته خالی باشد، یا برابر با %any[6]، 0.0.0.0، :: یا * باشد، نوع روی ID_ANY تنظیم می‌شود که با هر هویت دیگری مطابقت دارد.
•
اگر مقدار حاوی دو‌نقطه (:) باشد، فرض می‌شود یک نشانی IPv6 است. اما اگر تجزیه نشانی و تبدیل آن به کدگذاری باینری ناموفق باشد، نوع روی KEY_ID تنظیم شده و کدگذاری مقدار تحت‌اللفظی خواهد بود.
•
برای تمام رشته‌های دیگر، تلاشی برای تجزیه آن‌ها به عنوان نشانی‌های IPv4 انجام می‌شود. اگر ناموفق باشد، نوع روی FQDN تنظیم شده و مقدار تحت‌اللفظی به عنوان کدگذاری پذیرفته می‌شود (اینجا جایی است که نام‌های دامنه و نام‌های ساده قرار می‌گیرند).

نشست‌های IKE SA و IPsec SA مذاکره‌شده توسط دیمن را می‌توان به گونه‌ای پیکربندی کرد که پس از مدت زمان مشخصی منقضی شوند. برای IPsec SAها این امر می‌تواند پس از تعداد مشخصی بسته ارسالی یا بایت‌های ارسالی نیز رخ دهد. تنظیمات زیر را می‌توان برای پیکربندی این مورد استفاده کرد:

تنظیم پیش‌فرض تنظیم پیش‌فرض
IKE SA IPsec SA
 ikelifetime 3h  lifebytes -
   lifepackets -
   lifetime 1h

نشست‌های IKE SA و همچنین IPsec SA را می‌توان قبل از انقضا مجدداً کلیدگذاری کرد. این مورد را می‌توان با استفاده از تنظیمات زیر پیکربندی نمود:

تنظیم پیش‌فرض تنظیم پیش‌فرض
IKE و IPsec SA IPsec SA
 margintime 9m  marginbytes -
   marginpackets -

برای جلوگیری از برخوردها، حاشیه‌های مشخص‌شده قبل از کسر شدن از محدودیت‌های انقضا، به طور تصادفی افزایش می‌یابند (فرمول زیر را ببینید). این مورد توسط تنظیم rekeyfuzz کنترل می‌شود:

تنظیم پیش‌فرض
IKE و IPsec SA
 rekeyfuzz 100%

تصادفی‌سازی را می‌توان با تنظیم rekeyfuzz روی 0% غیرفعال کرد.

فرمول زیر برای محاسبه زمان کلیدگذاری مجدد IPsec SAها استفاده می‌شود:

rekeytime = lifetime - (margintime + random(0, margintime * rekeyfuzz))

این فرمول به طور یکسان برای IKE SAها و محدودیت‌های بایت و بسته برای IPsec SAها اعمال می‌شود.

بیایید پیکربندی پیش‌فرض را در نظر بگیریم:

lifetime = 1h
margintime = 9m
rekeyfuzz = 100%

از فرمول بالا نتیجه می‌شود که زمان کلیدگذاری مجدد بین مقادیر زیر قرار می‌گیرد:

rekeytime_min = 1h - (9m + 9m) = 42m
rekeytime_max = 1h - (9m + 0m) = 51m

بنابراین، دیمن تلاش خواهد کرد تا IPsec SA را در یک زمان تصادفی بین 42 تا 51 دقیقه پس از برقراری SA تجدید کلید کند. یا به عبارت دیگر، بین 9 تا 18 دقیقه قبل از انقضای SA.

•
از آنجا که تجدید کلید یک SA به مقداری زمان نیاز دارد، مقادیر حاشیه (margin) نباید خیلی کم باشند.
•
مقدار margin... + margin... * rekeyfuzz نباید از حد اصلی تجاوز کند. به عنوان مثال، تعیین margintime = 30m در پیکربندی پیش‌فرض ایده بدی است زیرا این احتمال وجود دارد که زمان تجدید کلید برابر با صفر شود و بنابراین تجدید کلید غیرفعال گردد. 

/etc/ipsec.conf
/etc/ipsec.d/aacerts
/etc/ipsec.d/acerts
/etc/ipsec.d/cacerts
/etc/ipsec.d/certs
/etc/ipsec.d/crls

strongswan.conf(5), ipsec.secrets(5), ipsec(8)

در ابتدا توسط Henry Spencer برای پروژه FreeS/WAN نوشته شد. توسط Tobias Brunner، Andreas Steffen و Martin Willi برای پروژه strongSwan http://www.strongswan.org به‌روزرسانی و گسترش یافت.

2012-06-26 6.1.0