'\" t .\" Man page generated from reStructuredText .\" by the Docutils 0.23 manpage writer. . . .nr rst2man-indent-level 0 . .de1 rstReportMargin \\$1 \\n[an-margin] level \\n[rst2man-indent-level] level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] - \\n[rst2man-indent0] \\n[rst2man-indent1] \\n[rst2man-indent2] .. .de1 INDENT .\" .rstReportMargin pre: . RS \\$1 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] . nr rst2man-indent-level +1 .\" .rstReportMargin post: .. .de UNINDENT . RE .\" indent \\n[an-margin] .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]] .nr rst2man-indent-level -1 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] .in \\n[rst2man-indent\\n[rst2man-indent-level]]u .. .TH "KEA-ARM" "1" "Jul 09, 2026" "3.2.0" "Kea" .SH "نام (NAME)" kea-arm \- مستندات راهنمای مرجع مدیر سیستم Kea [تصویر] .sp ‏Kea یک پیاده‌سازی متن‌باز از سرورهای پروتکل پیکربندی پویای میزبان (DHCP) است که توسط Internet Systems Consortium (ISC) توسعه یافته و نگهداری می‌شود. .sp این راهنمای مرجع برای Kea نسخهٔ 3.2.0\& است. پیوندهای مربوط به جدیدترین نسخهٔ این سند (در قالب‌های PDF، HTML و متن ساده) را می‌توان در Read the Docs به نشانی \%\& یافت. سایر اطلاعات مفید Kea در پایگاه دانش ما به نشانی \%\& در دسترس است. .SH "مقدمه (INTRODUCTION)" .sp ‏Kea نسل بعدی نرم‌افزارهای DHCP است که توسط Internet Systems Consortium (ISC) توسعه یافته است. این برنامه هم از پروتکل‌های DHCPv4 و هم از DHCPv6 به همراه الحاقات آن‌ها، مانند واگذاری پیشوند (prefix delegation) و به‌روزرسانی‌های پویای DNS پشتیبانی می‌کند. .sp این راهنما نسخهٔ 3.2.0\& Kea را پوشش می‌دهد. .sp برای دریافت اطلاعات دربارهٔ پلتفرم‌های پشتیبانی‌شده، بخش پلتفرم‌های پشتیبانی‌شده (Supported Platforms)\& را ببینید. .SS "پلتفرم‌های پشتیبانی‌شده (Supported Platforms)" .sp به‌طور کلی، این نسخه از Kea روی هر سیستم سازگار با POSIX که دارای کامپایلر ++C (با پشتیبانی از C++14)، کتابخانهٔ رمزنگاری Botan، کتابخانهٔ ثبت لاگ log4cplus و کتابخانهٔ سیستمی Boost باشد ساخته و اجرا می‌شود. .sp ‏ISC به‌طور منظم Kea را روی سیستم‌عامل‌ها و معماری‌های متعددی آزمایش می‌کند، اما منابع کافی برای آزمایش همهٔ آن‌ها را ندارد. در نتیجه، ISC تنها می‌تواند پشتیبانی را بر پایهٔ \(dqبیشترین تلاش (best\-effort)\(dq برای برخی از آن‌ها ارائه دهد. .SS "پلتفرم‌های آزمایش‌شده به‌طور منظم (Regularly Tested Platforms)" .sp ‏Kea به‌طور رسمی روی سیستم‌های Alpine، Debian، Fedora، FreeBSD، RHEL و Ubuntu پشتیبانی می‌شود. ساخت‌های Kea\-3.2.0 روی سیستم‌های زیر آزمایش شده‌اند: .INDENT 0.0 .IP \(bu 2 Alpine — 3.21, 3.22, 3.23, 3.24 .IP \(bu 2 Debian — 11, 12, 13 .IP \(bu 2 Fedora — 44 .IP \(bu 2 FreeBSD — 15 .IP \(bu 2 RHEL — 8, 9, 10 .IP \(bu 2 Ubuntu — 22.04, 24.04, 26.04 .UNINDENT .sp در حال حاضر برنامه‌ای برای پورت کردن Kea به سیستم‌های Windows وجود ندارد. .SS "بیشترین تلاش (Best\-Effort)" .sp موارد زیر پلتفرم‌هایی هستند که ساخته‌شدن و اجرای Kea روی آن‌ها تأیید شده است. ‏ISC تمام توان خود را برای رفع باگ‌ها در این پلتفرم‌ها به کار می‌گیرد، اما ممکن است به دلیل کمبود سخت‌افزار، آشنایی کمتر کادر مهندسی و سایر محدودیت‌ها قادر به انجام سریع آن نباشد. .INDENT 0.0 .IP \(bu 2 macOS — 14, 15, 26 .UNINDENT .SS "نگه‌داری‌شده توسط جامعه (Community\-Maintained)" .sp این سیستم‌ها زمانی به‌طور منظم آزمایش می‌شدند، اما پشتیبانی رسمی از آن‌ها متوقف شده است؛ که معمولاً به دلیل پایان یافتن پشتیبانی از سوی توسعه‌دهندگان خود آن سیستم‌ها است. نسخه‌های قدیمی‌تر ممکن است پیش‌نیازهای لازم برای ساخت آسان Kea را در دسترس نداشته باشند، هرچند در بسیاری از موارد امکان کامپایل مستقیم از روی کد منبع روی آن‌ها وجود دارد. جامعهٔ کاربری و افراد علاقه‌مند می‌توانند در نگه‌داری کمک کنند و ما از مشارکت در قالب وصله (patch) استقبال می‌کنیم، اگرچه نمی‌توانیم پذیرش آن‌ها را تضمین نماییم. تمام مشارکت‌ها از نظر ریسک تأثیر منفی بر پلتفرم‌های رسماً پشتیبانی‌شده سنجیده می‌شوند. .sp این پلتفرم‌ها مواردی را در بر می‌گیرند که تاریخ پایان عمر (EOL) آن‌ها گذشته است، مانند: .INDENT 0.0 .IP \(bu 2 Alpine — 3.20 (EOL 1 Apr 2026) و قدیمی‌تر .IP \(bu 2 Debian — 10 (EOL 30 Jun 2024) و قدیمی‌تر .IP \(bu 2 Fedora — 43 (EOL 9 Dec 2026) و قدیمی‌تر .IP \(bu 2 FreeBSD — 14 (EOL 31 Dec 2026) و قدیمی‌تر .IP \(bu 2 RHEL — 7 (EOL 30 Jun 2024) و قدیمی‌تر .IP \(bu 2 Ubuntu — 20.04 (EOL 31 May 2025) و قدیمی‌تر .IP \(bu 2 macOS — 13 (EOL 15 Sep 2025) و قدیمی‌تر .UNINDENT.SS "پلتفرم‌های پشتیبانی‌نشده (Unsupported Platforms)" .sp این‌ها پلتفرم‌هایی هستند که مشخص شده است نسخه‌های Kea از نگارش 1.7 به بعد روی آن‌ها ساخته یا اجرا \fIنمی‌شوند\fP: .INDENT 0.0 .IP \(bu 2 Windows (همه نسخه‌ها) .IP \(bu 2 Windows Server (همه نسخه‌ها) .IP \(bu 2 هر پلتفرمی با OpenSSL نسخه 1.0.1 یا قدیمی‌تر که به عنوان جایگزین Botan ندارد .IP \(bu 2 هر پلتفرمی با log4cplus نسخه 1.0.2 یا قدیمی‌تر. .IP \(bu 2 هر پلتفرمی با کامپایلری که از C++14 پشتیبانی نمی‌کند. .UNINDENT .SS "نرم‌افزارهای مورد نیاز هنگام اجرا (Required Software at Runtime)" .sp ‏Kea از بسته‌های نرم‌افزاری جانبی متعددی استفاده می‌کند که ممکن است در نصب پیش‌فرض برخی از سیستم‌عامل‌ها یا در مخازن بسته‌های استاندارد ارائه نشده باشند. ممکن است لازم باشد این نرم‌افزارهای مورد نیاز به‌طور جداگانه نصب شوند. (برای پیش‌نیازهای ساخت، همچنین پیش‌نیازهای ساخت \%<#\:build-requirements>\& را ببینید.) .INDENT 0.0 .IP \(bu 2 ‏Kea از دو کتابخانه رمزنگاری پشتیبانی می‌کند: Botan و OpenSSL. در هنگام کامپایل تنها نصب یکی از آن‌ها الزامی است. Kea از کتابخانه Botan برای C++ (\%)، نسخه 2.0 یا جدیدتر استفاده می‌کند؛ پشتیبانی از نسخه‌های Botan قدیمی‌تر از 2.0 از زمان انتشار Kea 1.7.0 حذف شد. به عنوان جایگزینی برای Botan، نرم‌افزار Kea می‌تواند از کتابخانه رمزنگاری OpenSSL (\%)، نسخه 1.0.2 یا بالاتر استفاده کند. .IP \(bu 2 ‏Kea از کتابخانه لاگ‌گیری log4cplus برای C++ (\%) استفاده می‌کند. این برنامه به log4cplus نسخه 1.0.3 یا جدیدتر نیاز دارد. .IP \(bu 2 ‏Kea به کتابخانه سیستمی Boost (\%) نیاز دارد. ساخت با نسخه header\-only کتابخانه Boost دیگر توصیه نمی‌شود. .UNINDENT .sp برخی از ویژگی‌های اختیاری Kea دارای وابستگی‌های بیشتری هستند. .INDENT 0.0 .IP \(bu 2 برای ذخیره اطلاعات اجاره (lease) در یک پایگاه داده MySQL، برنامه Kea به هدرها و کتابخانه‌های MySQL نیاز دارد. این یک وابستگی اختیاری است؛ Kea می‌تواند بدون پشتیبانی از MySQL ساخته شود. .IP \(bu 2 برای ذخیره اطلاعات اجاره در یک پایگاه داده PostgreSQL، برنامه Kea به هدرها و کتابخانه‌های PostgreSQL نیاز دارد. این یک وابستگی اختیاری است؛ Kea می‌تواند بدون پشتیبانی از PostgreSQL ساخته شود. .IP \(bu 2 ‏Kea یک رابط NETCONF با عامل \fBkea\-netconf\fP ارائه می‌دهد. این ماژول Kea هنگام استفاده به نرم‌افزار Sysrepo نیاز دارد. ساخت Kea با پشتیبانی از NETCONF نیازمند نصب وابستگی‌های متعددی است که در نصب NETCONF \%<#\:netconf-install>\& با جزئیات بیشتر شرح داده شده است. این یک وابستگی اختیاری است؛ Kea می‌تواند بدون پشتیبانی از NETCONF ساخته شود. .IP \(bu 2 برای امضا و اعتبارسنجی به‌روزرسانی‌های DNS، سرور Kea DDNS ممکن است از GSS\-TSIG استفاده کند که به کتابخانه‌های MIT Kerberos 5 یا Heimdal نیاز دارد. وابستگی‌هایی که باید نصب شوند با جزئیات بیشتر در کامپایل GSS\-TSIG \%<#\:gss-tsig-install>\& توضیح داده شده‌اند. این یک وابستگی اختیاری است؛ Kea می‌تواند بدون پشتیبانی از GSS\-TSIG ساخته شود. .UNINDENT .SS "نرم‌افزار Kea (Kea Software)" .sp ‏Kea یک راهکار ماژولار سرور DHCP است. این ماژولار بودن با به‌کارگیری چندین فرآیند همکار محقق می‌شود که در کنار یکدیگر عملکردهای سرور را فراهم می‌آورند. نرم‌افزارهای زیر همراه با Kea ارائه شده‌اند: .INDENT 0.0 .IP \(bu 2 \fBkeactrl\fP \%<#\:std-iscman-keactrl> — این ابزار سرورهای Kea را راه‌اندازی و متوقف کرده، مجدداً پیکربندی نموده و وضعیت آن‌ها را گزارش می‌دهد. .IP \(bu 2 \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> — فرآیند سرور DHCPv4. این فرآیند به درخواست‌های DHCPv4 از سوی کلاینت‌ها پاسخ می‌دهد. .IP \(bu 2 \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> — فرآیند سرور DHCPv6. این فرآیند به درخواست‌های DHCPv6 از سوی کلاینت‌ها پاسخ می‌دهد. .IP \(bu 2 \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> — فرآیند Dynamic DNS مربوط به DHCP. این فرآیند به عنوان یک واسطه بین سرورهای DHCP و سرورهای خارجی DNS عمل می‌کند؛ درخواست‌های به‌روزرسانی نام را از سرورهای DHCP دریافت کرده و پیام‌های به‌روزرسانی DNS را به سرورهای DNS ارسال می‌کند. .IP \(bu 2 \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> — این ابزاری مفید برای نگهداری بک‌اند پایگاه داده است (ایجاد پایگاه داده جدید، بررسی نسخه‌ها، ارتقا و غیره). .IP \(bu 2 \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> — این فرآیند اطلاعات تکراری و اضافی را از فایل‌هایی که برای ذخیره‌سازی پایدار بک‌اند پایگاه داده memfile استفاده می‌شوند، حذف می‌کند. اگرچه می‌تواند به صورت مستقل اجرا شود، معمولاً در زمان و صورت نیاز توسط سرورهای DHCP Kea اجرا می‌شود. .IP \(bu 2 \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> \- عامل kea\-netconf رابطی بر پایه YANG/NETCONF برای پیکربندی Kea فراهم می‌کند. .IP \(bu 2 \fBkea\-shell\fP \%<#\:std-iscman-kea-shell> — این کلاینت متنی ساده از رابط REST برای اتصال به سرور Kea استفاده می‌کند. .IP \(bu 2 \fBperfdhcp\fP \%<#\:std-iscman-perfdhcp> — این ابزاری برای محک‌زدن (benchmarking) کارایی DHCP است که چندین کلاینت را شبیه‌سازی می‌کند تا عملکرد هر دو سرور DHCPv4 و DHCPv6 را آزمایش کند. .UNINDENT .sp ابزارها و ماژول‌ها با جزئیات کامل در این راهنما پوشش داده شده‌اند. افزون بر این، صفحات راهنما (man pages) نیز در نصب پیش‌فرض ارائه شده‌اند. .sp ‏Kea همچنین کتابخانه‌های C++ و رابط‌های برنامه‌نویسی برای DHCP فراهم می‌کند. این موارد شامل مستندات جامع توسعه‌دهنده و نمونه‌کدها هستند. .SH "شروع سریع (QUICK START)" .sp این بخش گام‌های اولیه‌ی لازم برای راه‌اندازی و اجرای Kea را شرح می‌دهد. برای جزئیات بیشتر، سفارشی‌سازی‌های کامل و عیب‌یابی، به فصل‌های مربوطه در سایر بخش‌های این «راهنمای مرجع مدیر سیستم Kea» (ARM) مراجعه کنید. .SS "راهنمای شروع سریع با استفاده از tarball (Quick Start Guide Using tarball)" .INDENT 0.0 .IP 1. 3 وابستگی‌های لازم برای زمان اجرا و ساخت را نصب کنید. برای جزئیات به پیش‌نیازهای ساخت \%<#\:build-requirements> مراجعه کنید. .IP 2. 3 بسته tarball سورس Kea را از صفحه اصلی دانلودهای isc.org \%، سایت دانلودهای ISC \% یا صفحه Cloudsmith مربوط به ISC \%\& دریافت کنید. .IP 3. 3 بسته tarball را استخراج کنید. برای مثال: .INDENT 3.0 .INDENT 3.5 .sp .EX $ tar \-Jxvf kea\-3.2.0\&.tar.xz .EE .UNINDENT .UNINDENT .IP 4. 3 به دایرکتوری سورس بروید و فرآیند ساخت را برپا کنید: .INDENT 3.0 .INDENT 3.5 .sp .EX $ cd kea\-3.2.0 $ meson setup build [your extra parameters] .EE .UNINDENT .UNINDENT .IP 5. 3 آن را بسازید: .INDENT 3.0 .INDENT 3.5 .sp .EX $ meson compile \-C build .EE .UNINDENT .UNINDENT .IP 6. 3 آن را نصب کنید (به‌طور پیش‌فرض در \fB/usr/local/\fP قرار خواهد گرفت، بنابراین به احتمال زیاد برای این مرحله به دسترسی‌های ریشه (root) نیاز است): .INDENT 3.0 .INDENT 3.5 .sp .EX $ meson install \-C build .EE .UNINDENT .UNINDENT .UNINDENT.SS راهنمای شروع سریع با استفاده از بسته‌های بومی (Native) .sp شرکت ISC بسته‌های بومی Alpine، deb و RPM را ارائه می‌دهد که نصب Kea را بسیار آسان‌تر از ساخت آن از کد منبع می‌سازد. مگر در مواردی که گزینه‌های کامپایل خاصی مد نظر باشد، معمولاً نصب Kea با استفاده از بسته‌های بومی ساده‌تر است. .INDENT 0.0 .IP 1. 3 به صفحهٔ Kea در cloudsmith.io بروید: \%\&. .IP 2. 3 مخزن Cloudsmith مورد نظر را انتخاب کنید؛ برای نمونه kea\-3\-2 برای Kea 3.2.0\&. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تمامی نسخه‌های پایدار در مخازن جداگانه نگهداری می‌شوند، مانند kea\-2\-6، kea\-3\-0 و غیره. تمامی نسخه‌های در حال توسعه، که استفاده از آن‌ها در محیط‌های عملیاتی توصیه نمی‌شود، در مخزن kea\-dev قرار دارند. .UNINDENT .UNINDENT .INDENT 0.0 .IP 3. 3 روی پیکان کنار دکمهٔ \(dqSet Me Up\(dq کلیک کرده و توزیع سیستم‌عامل مورد نظر را انتخاب کنید: Alpine، Debian یا RedHat. .IP 4. 3 دستورالعمل‌های روی صفحه را دنبال کنید. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برای نمونه، دستورالعمل‌های راه‌اندازی Debian برای Kea 3.0 در اینجا در دسترس است: \% .sp منوی کشویی بالای صفحه، دستورالعمل‌های مربوط به سایر سیستم‌عامل‌ها را ارائه می‌دهد. .UNINDENT .UNINDENT .INDENT 0.0 .IP 5. 3 برنامهٔ Kea به بسته‌های گوناگونی تقسیم شده است. کل فهرست در صفحهٔ مخزن Cloudsmith زیر بخش \fBPackages\fP موجود است، یا می‌توان آن را با استفاده از \fBapk\fP/\fBapt\fP/\fBdnf\fP دریافت کرد\&. .UNINDENT .TS box center; l|l. T{ Debian/Ubuntu T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ apt search isc\-kea .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 بسته‌های \fBisc\-kea\-dhcp4\-server\fP و \fBisc\-kea\-dhcp6\-server\fP بسته‌های خالی انتقالی (transitional) هستند. بسته‌های اصلی سرور \fBisc\-kea\-dhcp4\fP و \fBisc\-kea\-dhcp6\fP می‌باشند\&. .UNINDENT .UNINDENT T} _ T{ Fedora/RedHat T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ dnf search \(aqisc\-kea*\(aq .EE .UNINDENT .UNINDENT T} _ T{ Alpine T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ apk search isc\-kea .EE .UNINDENT .UNINDENT T} .TE .INDENT 0.0 .IP 6. 3 نصب فرا\-بسته (metapackage) شامل تمامی ابزارها، کتابخانه‌ها، سرورها، مستندات و هوک‌های (hooks) متن‌باز: .UNINDENT .TS box center; l|l. T{ Debian/Ubuntu T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ sudo apt install isc\-kea .EE .UNINDENT .UNINDENT T} _ T{ Fedora/RedHat T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ sudo dnf install isc\-kea .EE .UNINDENT .UNINDENT T} _ T{ Alpine T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX # apk add isc\-kea .EE .UNINDENT .UNINDENT T} .TE .sp یا بسته‌های مشخص: .TS box center; l|l. T{ Debian/Ubuntu T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ sudo apt install isc\-kea\-dhcp6 .EE .UNINDENT .UNINDENT T} _ T{ Fedora/RedHat T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ sudo dnf install isc\-kea\-dhcp6 .EE .UNINDENT .UNINDENT T} _ T{ Alpine T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ apk add isc\-kea\-dhcp6 .EE .UNINDENT .UNINDENT T} .TE .sp یا تمامی بسته‌های مرتبط با Kea، شامل هدرهای توسعه، نمادهای اشکال‌زدایی (debug symbols) و هوک‌های مشترکین (در صورت موجود بودن): .TS box center; l|l. T{ Debian/Ubuntu T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ sudo apt install \(aqisc\-kea*\(aq .EE .UNINDENT .UNINDENT T} _ T{ Fedora/RedHat T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ sudo dnf install \(aqisc\-kea*\(aq .EE .UNINDENT .UNINDENT T} _ T{ Alpine T} T{ نصب بسته‌ها از طریق الگوهای تطبیق نام (\fB*\fP) در Alpine در دسترس نیست، اما می‌توان آن را با دستور زیر شبیه‌سازی کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX # apk search isc\-kea | sed \(aqs/\-[0\-9].*//g\(aq | xargs apk add .EE .UNINDENT .UNINDENT T} .TE .sp یا تمامی بسته‌ها با یک شماره نسخهٔ مشخص: .TS box center; l|l. T{ Debian/Ubuntu T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ sudo apt install \(aqisc\-kea*=2.4.0\-isc20230921141113\(aq .EE .UNINDENT .UNINDENT T} _ T{ Fedora/RedHat T} T{ .INDENT 0.0 .INDENT 3.5 .sp .EX $ sudo dnf install \(aqisc\-kea*2.4.0\-isc20230921141113*\(aq .EE .UNINDENT .UNINDENT T} _ T{ Alpine T} T{ نصب بسته‌ها از طریق الگوهای تطبیق نام (\fB*\fP) در Alpine در دسترس نیست، اما می‌توان آن را با دستور زیر شبیه‌سازی کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX # apk search isc\-kea | sed \(aqs/\-[0\-9].*//g\(aq | grep r20230921141113 | xargs apk add .EE .UNINDENT .UNINDENT T} .TE .INDENT 0.0.IP 8. 3 اکنون تمام بسته‌های نصب‌شده باید در دسترس باشند. .INDENT 3.0 .INDENT 3.5 می‌توانید سرور را به‌صورت دستی راه‌اندازی کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX # kea\-dhcp6 \-c /etc/kea/kea\-dhcp6.conf .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp یا با استفاده از systemd: .INDENT 3.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX # systemctl restart kea\-dhcp6 .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp یا با استفاده از OpenRC در Alpine: .INDENT 3.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX # service kea\-dhcp6 restart .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 ابزار \fBkeactrl\fP \%<#\:std-iscman-keactrl> در بسته‌ها ارائه نشده است، چرا که عملکرد مشابه توسط اسکریپت‌های بومی systemctl فراهم شده است. .UNINDENT .UNINDENT .INDENT 0.0 .IP 9. 3 در سیستم‌های Debian/Ubuntu، هنگام نصب بسته، سرویس به‌طور خودکار در زمان بوت فعال می‌شود. در Fedora/RHEL و Alpine، سرویس به‌صورت خودکار فعال نمی‌شود؛ بنابراین در صورت نیاز، باید به‌طور دستی فعال گردد. .INDENT 3.0 .INDENT 3.5 با systemd در Fedora/RedHat: .INDENT 0.0 .INDENT 3.5 .sp .EX # systemctl enable kea\-dhcp6 .EE .UNINDENT .UNINDENT .sp با OpenRC در Alpine: .INDENT 0.0 .INDENT 3.5 .sp .EX # rc\-update add kea\-dhcp6 .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .UNINDENT .SS راهنمای شروع سریع با استفاده از کانتینرهای Docker .INDENT 0.0 .IP 1. 3 به مخزن داکر ISC در cloudsmith.io \%\& بروید. .IP 2. 3 یک شبکه ipvlan متصل به رابط میزبان رو به کلاینت و اختصاص‌یافته به زیرشبکه‌ای که توسط Kea سرویس‌دهی می‌شود، ایجاد کنید. .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ docker network create \-\-driver ipvlan \-\-ipv6 \-\-subnet 2001:db8::/64 \-\-opt parent=eth0 ipvlan0 .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 3. 3 ایمیج دلخواه را انتخاب کرده و آن را به‌صورت محلی pull کنید. .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ docker pull docker.cloudsmith.io/isc/docker/kea\-dhcp6 .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 4. 3 یک کانتینر از ایمیج بسازید. در صورت نیاز، حجم پیکربندی و حجم داده را سوار (mount) کنید. .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ docker create \e \-\-name kea\-dhcp6 \e \-\-network ipvlan0 \e \-\-volume /local/kea/config:/etc/kea \e \-\-volume /local/kea/data:/var/lib/kea \e docker.cloudsmith.io/isc/docker/kea\-dhcp6 .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 5. 3 کانتینر داکر را راه‌اندازی کنید. .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ docker start kea\-dhcp6 .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 6. 3 برای متوقف کردن کانتینر داکر، اجرا کنید: .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ docker stop kea\-dhcp6 .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برای سناریوهای پیچیده‌تر، به راهنمای kea\-docker در \% مراجعه کنید. .UNINDENT .UNINDENT.SS راهنمای شروع سریع برای سرویس‌های DHCPv4 و DHCPv6 .INDENT 0.0 .IP 1. 3 فایل‌های پیکربندی Kea را که به‌طور پیش‌فرض در دایرکتوری \fB\(dq[kea\-install\-dir]/etc/kea/\(dq\fP نصب می‌شوند ویرایش کنید. این فایل‌ها عبارتند از: \fBkea\-dhcp4.conf\fP، \fBkea\-dhcp6.conf\fP، \fBkea\-dhcp\-ddns.conf\fP، و \fBkeactrl.conf\fP که به‌ترتیب مربوط به کارساز DHCPv4، کارساز DHCPv6، D2 و اسکریپت keactrl هستند. .IP 2. 3 برای راه‌اندازی کارساز DHCPv4 در پس‌زمینه، دستور زیر را (به‌عنوان root) اجرا کنید: .INDENT 3.0 .INDENT 3.5 .sp .EX # keactrl start \-s dhcp4 .EE .UNINDENT .UNINDENT .sp یا دستور زیر را برای راه‌اندازی کارساز DHCPv6 اجرا کنید: .INDENT 3.0 .INDENT 3.5 .sp .EX # keactrl start \-s dhcp6 .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که راه‌اندازی هم‌زمان تمامی کارسازها نیز ممکن است: .INDENT 3.0 .INDENT 3.5 .sp .EX # keactrl start .EE .UNINDENT .UNINDENT .IP 3. 3 بررسی کنید که کارساز(های) Kea در حال اجرا هستند: .INDENT 3.0 .INDENT 3.5 .sp .EX # keactrl status .EE .UNINDENT .UNINDENT .sp وضعیت \(dqinactive\(dq برای یک کارساز می‌تواند نشان‌دهنده خطای پیکربندی باشد. لطفاً فایل گزارش لاگ را (که به‌طور پیش‌فرض با نام \fB\(dq[kea\-install\-dir]/var/log/kea/kea\-dhcp4.log\(dq\fP، \fB\(dq[kea\-install\-dir]/var/log/kea/kea\-dhcp6.log\(dq\fP، یا \fB\(dq[kea\-install\-dir]/var/log/kea/kea\-ddns.log\(dq\fP شناخته می‌شود) برای مشاهده جزئیات خطاها بررسی کنید. .IP 4. 3 اگر کارساز با موفقیت راه‌اندازی شد، آزمایش کنید که آیا به پرس‌وجوهای DHCP پاسخ می‌دهد و کلاینت پیکربندی را از کارساز دریافت می‌کند یا خیر؛ برای مثال، از کلاینت ISC DHCP در \%\& استفاده کنید. .IP 5. 3 برای متوقف کردن کارساز(ها): .INDENT 3.0 .INDENT 3.5 .sp .EX # keactrl stop .EE .UNINDENT .UNINDENT .UNINDENT .sp برای دستورالعمل‌های ویژه‌ی هر سیستم، لطفاً یادداشت‌های اختصاصی سیستم \% را که در بخش Kea در پایگاه دانش ISC به نشانی \%\& موجود است مطالعه کنید. .sp جزئیات مربوط به نحوه استفاده از اسکریپت \fBkeactrl\fP \%<#\:std-iscman-keactrl> را می‌توانید در Managing Kea with keactrl \%<#\:keactrl>\& بیابید. .sp پس از راه‌اندازی و اجرای سرویس‌های Kea، استقرار یک راهکار داشبورد را برای نظارت بر سرویس‌های فعال در نظر بگیرید. برای جزئیات بیشتر، Monitoring Kea With Stork \%<#\:stork>\& را ببینید. .SS اجرای مستقیم کارسازهای Kea .sp کارسازهای Kea را می‌توان مستقیماً و بدون نیاز به استفاده از \fBkeactrl\fP \%<#\:std-iscman-keactrl> یا \fBsystemctl\fP\& راه‌اندازی کرد. برای راه‌اندازی کارساز DHCPv4 دستور زیر را اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX # kea\-dhcp4 \-c /path/to/your/kea4/config/file.json .EE .UNINDENT .UNINDENT .sp به همین ترتیب، برای راه‌اندازی کارساز DHCPv6، دستور زیر را اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX # kea\-dhcp6 \-c /path/to/your/kea6/config/file.json .EE .UNINDENT .UNINDENT .SH "نصب (INSTALLATION)" .SS بسته‌ها .sp سازمان ISC بسته‌های محلی RPM، deb و APK و همچنین فایل‌های فشرده tarball حاوی کد منبع را منتشر می‌کند. این بسته‌ها در مخازن Cloudsmith مربوط به ISC به نشانی \%\& در دسترس هستند. بسته‌های بومی را می‌توان با استفاده از سیستم مدیریت بسته موجود در توزیع مورد نظر (مانند dpkg یا rpm) دریافت و نصب کرد. همچنین می‌توان مخزن Kea را به سیستم اضافه کرد تا نصب به‌روزرسانی‌ها آسان‌تر شود. برای دریافت جزئیات، لطفاً به \% مراجعه کرده، نسخه Kea مورد نظر را انتخاب نمایید، و سپس بر روی دکمه \(dqSet Me Up\(dq کلیک کنید. برای دستورالعمل‌های دقیق‌تر، لطفاً به این مقاله در پایگاه دانش \%\& مراجعه فرمایید. .sp سازمان ISC دو نوع مخزن را نگهداری می‌کند: پایدار (stable) و توسعه (development). مخازن پایدار شامل یک انتشار پایدار مشخص (مانند kea\-2\-6 یا kea\-3\-0) به همراه تمامی به‌روزرسانی‌های نگهداری آن هستند. ایجاد مخازن مجزا برای به حداقل رساندن خطر ارتقای ناخواسته از یک انتشار پایدار به انتشار پایدار دیگر صورت گرفته است. .sp مخزن توسعه، با عنوان kea\-dev، شامل نسخه‌های توسعه فعلی و آتی است که ISC استفاده از آن‌ها را برای محیط‌های عملیاتی توصیه نمی‌کند. بسته‌های موجود در مخزن kea\-dev مشمول پاک‌سازی دوره‌ای هستند و ممکن است نسخه‌های قدیمی‌تر از روی آن حذف شوند..SS نصب از طریق بسته‌های Cloudsmith .sp شرکت ISC بسته‌های Kea را برای Alpine، Debian، Fedora، RHEL و Ubuntu ارائه می‌دهد. روش پیشنهادی برای نصب Kea روی هر یک از این سیستم‌ها، نصب فرابسته \fBisc\-kea\fP از مخزن Cloudsmith است. این فرابسته در تمام توزیع‌های پشتیبانی‌شده موجود است و تمامی سرویس‌های ارائه‌شده توسط مجموعه نرم‌افزاری Kea را نصب می‌کند. .sp اجزای خاص Kea را می‌توان به‌صورت جداگانه از طریق هر یک از بسته‌های زیر نصب کرد: .INDENT 0.0 .IP \(bu 2 \fBisc\-kea\-dhcp4\fP — بسته کارگزار Kea DHCPv4 .IP \(bu 2 \fBisc\-kea\-dhcp6\fP — بسته کارگزار Kea DHCPv6 .IP \(bu 2 \fBisc\-kea\-dhcp\-ddns\fP — کارگزار Kea DHCP DDNS .IP \(bu 2 \fBisc\-kea\-admin\fP — ابزارهای مدیریت پایگاه‌داده Kea .IP \(bu 2 \fBisc\-kea\-hooks\fP — قلاب‌های متن‌باز Kea DHCP .UNINDENT .sp بسته‌های قلاب مشترکین Kea در بسته \fBisc\-kea\-hooks\fP گنجانده نشده‌اند. برای مشتریان ISC با دسترسی به قلاب‌های مشترکین، آن بسته‌ها دارای پیشوند \fBisc\-kea\-subscriber\-\fP هستند. کاربرانی که علاقه‌مند به خرید خدمات پشتیبانی حرفه‌ای از ISC و دسترسی به قلاب‌های مشترکین هستند، می‌توانند فرم تماس را در \%\& تکمیل نمایند. .sp پس از نصب، سرویس‌ها را می‌توان از طریق مدیر سرویس توزیع مدیریت کرد. نام این سرویس‌ها عبارت است از: \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> و \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نام‌های واقعی سرویس در Debian و Ubuntu جهت حفظ سازگاری با برخی اسکریپت‌های قدیمی‌تر، کمی با نام بسته‌ها تفاوت دارند. از یک نام مستعار در سرویس systemd استفاده شده است تا کاربران بتوانند با نام‌های کوتاه‌تر به آن‌ها ارجاع دهند. اجرای دستور \fBsystemctl enable\fP روی این سرویس‌ها نیازمند نام‌های واقعی سرویس است، که عبارتند از: \fBisc\-kea\-dhcp4\-server\fP، \fBisc\-kea\-dhcp6\-server\fP و \fBisc\-kea\-dhcp\-ddns\-server\fP\&. .UNINDENT .UNINDENT .SS هشدارهای هنگام ارتقای بسته‌های Kea .sp برای ارتقا به نسخه فعلی Kea از نسخه 2.3.2 یا پیش‌تر روی سیستم‌های Debian و Ubuntu، به جای دستور معمول \fBapt upgrade\fP دستور \fBapt dist\-upgrade\fP را اجرا کنید. پس از تکمیل این ارتقا، می‌توان به‌صورت معمول با استفاده از \fBapt upgrade\fP در سیستم‌های Debian و Ubuntu نسخه‌های بعدی را ارتقا داد. .sp کاربران ممکن است متوجه تفاوت‌هایی میان بسته‌های توزیع‌شده در نسخه‌های پیش از 2.3.2 نرم‌افزار Kea و بسته‌های ارائه‌شده در نسخه 2.3.2 و بعد از آن شوند. در پی بازنگری کلی در طراحی بسته‌بندی در آن انتشار، برخی بسته‌ها تغییر نام یافته یا حذف شدند. برای اطمینان از پیش رفتن هرچه روان‌تر فرایند ارتقا، دقت کنید که چه بسته‌هایی طی تراکنش ارتقا حذف و نصب می‌شوند و مطمئن شوید که تمامی بسته‌های مورد نیاز مجدداً نصب شده‌اند. .sp به‌ویژه، بسته به اینکه در ابتدا چه بسته‌هایی نصب شده بودند، احتمال دارد بسته‌های زیر طی ارتقا حذف شوند: .INDENT 0.0 .IP \(bu 2 \fBisc\-kea\-dhcp4\fP .IP \(bu 2 \fBisc\-kea\-dhcp6\fP .IP \(bu 2 \fBisc\-kea\-dhcp\-ddns\fP .IP \(bu 2 \fBisc\-kea\-hooks\fP .UNINDENT .sp برای نصب کامل مجموعه نرم‌افزاری Kea، کافی است پس از ارتقا دستور \fBapt install isc\-kea\fP را اجرا کنید که تمامی زیربسته‌های مرتبط تشکیل‌دهنده Kea را نصب خواهد کرد. .sp این مشکل مسیر ارتقا برای سیستم‌های RPM و Alpine وجود ندارد. .sp از مشتریان دارای قرارداد پشتیبانی ISC که در ارتقا با دشواری مواجه می‌شوند دعوت می‌شود یک تیکت در صف پشتیبانی خود ثبت کنند. به سایر کاربران توصیه می‌شود وضعیت خود را در فهرست پستی kea\-users در \% مطرح کنند تا از پشتیبانی دیگر اعضای فهرست بهره‌مند گردند. .SS ساختار سلسله‌مراتبی نصب .sp در زیر ساختار دایرکتوری‌های یک نصب کامل Kea آورده شده است. (تمام مسیرهای دایرکتوری نسبت به دایرکتوری نصب در نظر گرفته شده‌اند.) .INDENT 0.0 .IP \(bu 2 \fBetc/kea/\fP — فایل‌های پیکربندی. .IP \(bu 2 \fBinclude/\fP — فایل‌های هدر توسعه C++. .IP \(bu 2 \fBlib/\fP — کتابخانه‌ها. .IP \(bu 2 \fBlib/kea/hooks\fP — کتابخانه‌های قلاب الحاقی. .IP \(bu 2 \fBsbin/\fP — نرم‌افزار کارگزار و دستورهای مورد استفاده مدیر سیستم. .IP \(bu 2 \fBshare/doc/kea/\fP — این راهنما، سایر مستندات تکمیلی، و مثال‌ها. .IP \(bu 2 \fBshare/kea/\fP — مثال‌های دستورات API و اسکریپت‌های طرحواره پایگاه‌داده (schema). .IP \(bu 2 \fBshare/man/\fP — صفحات راهنما (مستندات برخط). .IP \(bu 2 \fBvar/lib/kea/\fP — فایل‌های شناسه کارگزار (DHCPv6) و پایگاه‌داده اجاره (lease). .IP \(bu 2 \fBvar/log/kea/\fP \- فایل‌های گزارش (log). .IP \(bu 2 \fBvar/run/kea\fP \- فایل PID و فایل قفل لاگر. .UNINDENT .SS پیش‌نیازهای ساخت .sp علاوه بر پیش‌نیازهای زمان اجرا (فهرست‌شده در نرم‌افزارهای مورد نیاز در زمان اجرا \%<#\:required-software>)، ساخت Kea از کد منبع نیازمند هدرهای مختلف توسعه و ابزارهای تولید برنامه است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برخی سیستم‌عامل‌ها بسته‌های توزیع خود را به دو بسته زمان اجرا و توسعه تفکیک کرده‌اند. برای ساخت Kea از کد منبع، باید نسخه‌های بسته توسعه که حاوی فایل‌های هدر و کتابخانه‌ها هستند نصب شوند. .UNINDENT .UNINDENT .sp ساخت از کد منبع مستلزم نصب نرم‌افزارهای زیر روی سیستم است: .INDENT 0.0 .IP \(bu 2 ابزارهای توسعه meson، ninja و pkg\-config. .IP \(bu 2 کتابخانه‌های C++ بست Boost (\%) (حداقل نسخه 1.66). روی نسخه‌های قدیمی‌تر از 1.69 کتابخانه Boost system نیز باید نصب باشد. .IP \(bu 2 ‏OpenSSL (حداقل نسخه 1.0.2) یا Botan (حداقل نسخه 3.4.0). نسخه 1.1.1 یا جدیدتر OpenSSL اکیداً توصیه می‌شود. .IP \(bu 2 هدرهای توسعه log4cplus (حداقل نسخه 1.0.3). .IP \(bu 2 یک کامپایلر C++ (با پشتیبانی از C++14) و هدرهای استاندارد توسعه. .IP \(bu 2 کلاینت MySQL و کتابخانه‌های توسعه کلاینت، هنگام استفاده از پرچم پیکربندی \fB\-D mysql=enabled\fP برای ساخت بک‌اند پایگاه‌داده MySQL نرم‌افزار Kea. در این حالت، به یک نمونه در حال اجرای سرور MySQL به صورت محلی یا روی ماشینی در دسترس از طریق شبکه نیاز است. توجه داشته باشید که اجرای آزمون‌های واحد (unit tests) نیازمند سرور MySQL محلی است. .IP \(bu 2 کلاینت PostgreSQL و کتابخانه‌های توسعه کلاینت، هنگام استفاده از پرچم پیکربندی \fB\-D postgresql=enabled\fP برای ساخت بک‌اند پایگاه‌داده PostgreSQL نرم‌افزار Kea. در این حالت به یک نمونه در حال اجرای سرور PostgreSQL به صورت محلی یا روی ماشینی در دسترس از طریق شبکه نیاز است. توجه داشته باشید که اجرای آزمون‌های واحد نیازمند سرور PostgreSQL محلی است. .IP \(bu 2 ‏Sysrepo نسخه 1.4.140 و libyang نسخه 1.0.240، که برای اتصال به یک پایگاه داده Sysrepo مورد نیاز هستند. نسخه‌های قبلی دیگر پشتیبانی نمی‌شوند. هنگام کامپایل از کد منبع، سوییچ پیکربندی قابل استفاده \fB\-D netconf=enabled\fP است. اگر این وابستگی‌ها در مسیرهای سفارشی نصب شده‌اند، PKG_CONFIG_PATH را به سمت آن‌ها تنظیم کنید. .IP \(bu 2 کتابخانه‌های MIT Kerberos 5 یا Heimdal توسط سرور Kea DDNS برای امضا و اعتبارسنجی به‌روزرسانی‌های DNS با استفاده از GSS\-TSIG نیاز هستند. سوییچ پیکربندی که این قابلیت را فعال می‌کند \fB\-D krb5=enabled\fP است. اگر این وابستگی در مسیری سفارشی نصب شده است، PKG_CONFIG_PATH را به فایل .pc یا PATH را به ابزار krb5\-config هدایت نمایید. .IP \(bu 2 ‏googletest (نسخه 1.8 یا بالاتر) هنگام استفاده از گزینه پیکربندی \fB\-D tests=enabled\fP برای ساخت آزمون‌های واحد الزامی است. .IP \(bu 2 ابزارهای تولید مستندات Sphinx \%، ‏texlive به همراه افزونه‌های آن، و Doxygen برای ایجاد مستندات. به‌ویژه در Fedora بسته‌های \fBpython3\-sphinx\fP، \fBpython3\-sphinx_rtd_theme\fP، \fBtexlive\fP و \fBtexlive\-collection\-latexextra\fP ضروری هستند. در Ubuntu بسته‌های \fBpython3\-sphinx\fP، \fBpython3\-sphinx\-rtd\-theme\fP، \fBtexlive\fP و \fBtexlive\-latex\-extra\fP مورد نیاز می‌باشند. چنانچه بسته‌های LaTeX یافت نشوند، Kea از ساخت PDF صرف‌نظر کرده و تنها اسناد HTML تولید می‌کند. .UNINDENT .sp برای نکات نصب اختصاصی هر سیستم، از پایگاه دانش ISC به نشانی \% دیدن کنید..SS نصب از کد منبع .sp اگرچه ممکن است Kea به‌صورت بسته‌های از پیش کامپایل‌شده و آمادهٔ استفاده از سوی توزیع‌کنندگان سیستم‌عامل ارائه شده باشد، اما این نرم‌افزار، یک نرم‌افزار متن‌باز است که به زبان ++C نوشته شده است. به همین جهت، به‌صورت کد منبع آزاد و در قالب یک فایل tar قابل بارگیری از سوی ISC عرضه می‌شود. همچنین کد منبع را می‌توان از مخزن گیت‌لب Kea در \%\& دریافت کرد. این بخش نحوهٔ ساخت Kea از روی کد منبع را شرح می‌دهد. .SS بارگیری فایل Tar .sp فایل‌های فشردهٔ (tarball) انتشار Kea را می‌توان از نشانی زیر بارگیری کرد: \%\&. .SS اعتبارسنجی امضای فایل Tar .sp فایل tar حاوی کد منبع به همراه امضای GPG آن توزیع می‌شود. امضا، فایلی هم‌نام با فایل tar است که پسوند \fB\&.asc\fP به انتهای آن اضافه شده است. می‌توانید فایل امضا را در صفحهٔ بارگیری ما، FTP یا CloudSmith پیدا کنید. .sp این امضا با استفاده از کلید امضای کد ISC ایجاد شده است. مجموعهٔ فعلی کلیدهای امضای کد ISC از طریق وب‌سایت ISC در \% (پیوند Current Set of ISC Code\-Signing Keys در \%) در دسترس است. .sp امضا را می‌توان با استفاده از ابزار \fBgpg\fP از GnuPG اعتبارسنجی کرد. دستورهای زیر کلیدهای امضای کد (\fBisc\-keyblock.asc\fP) را وارد (import) کرده و امضا را بررسی می‌کنند: .INDENT 0.0 .INDENT 3.5 .sp .EX $ gpg \-\-import isc\-keyblock.asc $ gpg \-\-verify kea\-X.Y.Z.tar.xz.asc kea\-X.Y.Z.tar.xz .EE .UNINDENT .UNINDENT .sp این اعتبارسنجی به کاربران اجازه می‌دهد مطمئن شوند فایل tar دستکاری نشده و توسط ISC ساخته شده است. .SS دریافت از Git .sp جدیدترین کدهای در حال توسعه در GitLab در دسترس است (ببینید: \%). کد منبع Kea عمومی است و توسعه در شاخهٔ «master» انجام می‌شود. .sp بارگیری این کدِ \(dqbleeding edge\(dq تنها به توسعه‌دهندگان یا کاربران پیشرفته پیشنهاد می‌شود. استفاده از کدهای در حال توسعه در محیط‌های عملیاتی توصیه نمی‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگام ساخت از روی کد منبع دریافت‌شده از طریق git، به نرم‌افزارهای جانبی نیاز است: automake (نسخهٔ 1.11 یا بالاتر)، libtoolize و autoconf (نسخهٔ 2.69 یا بالاتر). ممکن است نیاز به نصب این موارد داشته باشید. .UNINDENT .UNINDENT .sp کد را می‌توان از \fBhttps://gitlab.isc.org/isc\-projects/kea.git\fP دریافت (clone) کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ git clone https://gitlab.isc.org/isc\-projects/kea.git .EE .UNINDENT .UNINDENT .sp کد دریافت شده از مخزن git شامل فایل‌های ساخت نیست. آن‌ها را می‌توان با اجرای \fBmeson setup build\fP ایجاد کرد\&. .sp دسترسی نوشتن به مخزن Kea تنها به کارکنان ISC اعطا می‌شود. توسعه‌دهندگانی که قصد مشارکت در Kea را دارند باید به راهنمای مشارکت‌کنندگان (Contributor\(aqs Guide) در \%\& مراجعه کنند. راهنمای توسعه‌دهندگان Kea (Kea Developer\(aqs Guide) در \% حاوی اطلاعات بیشتری دربارهٔ این فرآیند است و نیازمندی‌های پذیرش کد مشارکت‌شده توسط ISC را شرح می‌دهد. .SS آماده‌سازی ساخت .sp نرم‌افزار Kea از ابزار Meson برای شناسایی جزئیات محیط ساخت استفاده می‌کند. برای تولید فایل ninja با استفاده از مقادیر پیش‌فرض، کافی است دستور زیر را اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ meson setup build .EE .UNINDENT .UNINDENT .sp برای مشاهدهٔ گزینه‌های مختلف ساخت، دستور \fBmeson configure\fP را اجرا کنید. برخی از گزینه‌های پرکاربرد عبارت‌اند از: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fB\-\-prefix\fP تعیین محل نصب (پیش‌فرض \fB/usr/local\fP است). .IP \(bu 2 \fB\-D mysql=enabled\fP ساخت Kea به همراه کدی که امکان ذخیرهٔ اجاره‌ها (leases) و رزروهای میزبان (host reservations) را در یک پایگاه‌دادهٔ MySQL فراهم می‌کند. .IP \(bu 2 \fB\-D postgresql=enabled\fP ساخت Kea به همراه کدی که امکان ذخیرهٔ اجاره‌ها و رزروهای میزبان را در یک پایگاه‌دادهٔ PostgreSQL فراهم می‌کند. .IP \(bu 2 \fB\-D krb5=enabled\fP ساخت Kea با پشتیبانی از Kerberos5 به همراه GSS\-API که توسط \fBlibddns_gss_tsig.so\fP \%<#\:std-ischooklib-libddns_gss_tsig\:.so>\& الزامی است. .IP \(bu 2 \fB\-D netconf=enabled\fP ساخت Kea با پشتیبانی از libyang و sysrepo که توسط \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf>\& الزامی است. .IP \(bu 2 \fB\-D crypto=botan\fP استفاده از کتابخانهٔ رمزنگاری Botan به جای OpenSSL. ابزار Meson کتابخانه‌های pkg\-config مربوط به \(aqbotan\-3\(aq و \(aqbotan\(aq را جستجو می‌کند. .IP \(bu 2 \fB\-\-D crypto=openssl\fP استفاده از کتابخانهٔ رمزنگاری OpenSSL. به‌طور پیش‌فرض مقدار گزینهٔ \(aqcrypto\(aq برابر با \(aqopenssl\(aq است. .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برای دستورالعمل‌های مربوط به نصب و پیکربندی بک‌اند‌های پایگاه‌داده برای Kea، بخش DHCP Database Installation and Configuration را ببینید\&. .UNINDENT .UNINDENT .sp اگر اجرای \fBmeson setup build\fP ناموفق بود، ممکن است به دلیل وابستگی‌های مفقود یا قدیمی باشد. .sp هنگامی که \fBmeson setup build\fP با موفقیت انجام شود، گزارشی از پارامترهای استفاده‌شده برای ساخت کد را نمایش می‌دهد. این گزارش در فایل \fBbuild/config.report\fP ذخیره شده و همچنین در باینری‌های اجرایی تعبیه می‌شود؛ مانند \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>\&..SS ساخت .sp پس از تکمیل مرحلهٔ برپایی (setup)، با اجرای فرمان زیر فایل‌های اجرایی را از کد C++ ساخته و اسکریپت‌های Python را آماده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ meson compile \-C build .EE .UNINDENT .UNINDENT .SS نصب .sp برای نصب فایل‌های اجرایی، فایل‌های پشتیبان، و مستندات Kea، فرمان زیر را صادر کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ meson install \-C build .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مرحلهٔ نصب ممکن است به دسترسی‌های مدیر سیستم (superuser) نیاز داشته باشد. .UNINDENT .UNINDENT .sp این کار نباید لازم باشد، اما اگر کتابخانه‌های اشتراکی در زمان اجرا پیدا نشدند، می‌توانید \fBldconfig\fP را با دسترسی ریشه (root) و قرار دادن \fB/usr/local/lib\fP (یا با \fB${prefix}/lib\fP اگر با \fB\-\-prefix\fP برپا شده باشد) در \fB/etc/ld.so.conf\fP (یا فایل پیکربندی مربوط به کش پیونددهنده در سیستم‌عامل) اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ldconfig .EE .UNINDENT .UNINDENT .sp اگر \fBldconfig\fP در جایی که لازم است اجرا نشود، کاربران ممکن است با خطاهایی مانند زیر مواجه شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX program: error while loading shared libraries: libkea\-something.so.1: cannot open shared object file: No such file or directory .EE .UNINDENT .UNINDENT .SS نصب و پیکربندی پایگاه‌داده DHCP .sp Kea اطلاعات اجاره‌های خود (leases) را در یک پایگاه‌دادهٔ اجاره ذخیره می‌کند. این نرم‌افزار به گونه‌ای نوشته شده است که امکان انتخاب محصول پایگاه‌داده برای ذخیرهٔ اطلاعات اجاره را فراهم می‌سازد. Kea از سه backend پایگاه‌داده پشتیبانی می‌کند: MySQL، PostgreSQL، و memfile. برای محدود کردن وابستگی‌های خارجی، پشتیبانی از MySQL و PostgreSQL به‌طور پیش‌فرض غیرفعال است و تنها memfile در دسترس می‌باشد. پشتیبانی از backend اختیاری پایگاه‌دادهٔ خارجی باید هنگام ساخت Kea به‌صراحت گنجانده شود. این بخش نحوهٔ ساخت Kea به همراه یکی از backendهای اختیاری و ایجاد پایگاه‌دادهٔ اجاره را پوشش می‌دهد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگامی که آزمون‌های واحد (unit tests) به همراه Kea ساخته می‌شوند (یعنی گزینهٔ پیکربندی \fB\-D tests=enabled\fP مشخص شده باشد)، پایگاه‌های داده برای اجرای آزمون‌های واحد باید به‌صورت دستی از پیش پیکربندی شوند. جزئیات این پیکربندی را می‌توان در Kea Developer\(aqs Guide \%\& یافت. .UNINDENT .UNINDENT .SS ساخت با پشتیبانی از MySQL .sp MySQL را بر اساس دستورالعمل‌های سیستم خود نصب کنید. کتابخانه‌های توسعهٔ کلاینت (client development libraries) باید نصب شده باشند. .sp Kea را طبق آنچه در بخش Installation شرح داده شده است بسازید و نصب کنید، با این تغییر که: برای فعال‌سازی کد پایگاه‌دادهٔ MySQL، در مرحلهٔ برپایی (نگاه کنید به Set Up the Build)، سوییچ \fB\-D mysql=enabled\fP باید مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX $ meson setup build \-D mysql=enabled .EE .UNINDENT .UNINDENT .sp اگر MySQL در مکان پیش‌فرض نصب نشده باشد، می‌توان این مکان را با مقداردهی \fBPKG_CONFIG_PATH=/path/to/mariadb.pc:${PKG_CONFIG_PATH}\fP یا \fBPATH=/path/to/mariadb\-config:${PATH}\fP پیش از اجرای \fBmeson setup\fP مشخص کرد. .INDENT 0.0 .INDENT 3.5 .sp .EX $ PKG_CONFIG_PATH=/opt/mariadb/lib/pkgconfig PATH=/opt/mariadb/bin meson setup build \-D mysql=enabled .EE .UNINDENT .UNINDENT .sp برای جزئیات مربوط به پیکربندی پایگاه‌دادهٔ MySQL، به First\-Time Creation of the MySQL Database \%<#\:mysql-database-create> مراجعه کنید. .SS ساخت با پشتیبانی از PostgreSQL .sp PostgreSQL را بر اساس دستورالعمل‌های سیستم نصب کنید. کتابخانه‌های توسعهٔ کلاینت باید نصب شده باشند. کتابخانه‌های توسعهٔ کلاینت اغلب در بسته‌ای به نام \fBlibpq\fP عرضه می‌شوند. .sp Kea را همان‌طور که در بخش Installation شرح داده شده است بسازید و نصب کنید، با این تغییر که: برای فعال‌سازی کد پایگاه‌دادهٔ PostgreSQL، در مرحلهٔ برپایی (نگاه کنید به Set Up the Build)، سوییچ \fB\-D postgresql=enabled\fP باید مشخص شود. .sp اگر PostgreSQL در مکان پیش‌فرض نصب نشده باشد، می‌توان این مکان را با مقداردهی \fBPKG_CONFIG_PATH=/path/to/libpq.pc:${PKG_CONFIG_PATH}\fP یا \fBPATH=/path/to/pg_config:${PATH}\fP پیش از اجرای \fBmeson setup\fP تعیین کرد. .INDENT 0.0 .INDENT 3.5 .sp .EX $ PKG_CONFIG_PATH=/opt/postgresql/lib/pkgconfig PATH=/opt/postgresql/bin meson setup build \-D postgresql=enabled .EE .UNINDENT .UNINDENT .sp برای جزئیات مربوط به پیکربندی پایگاه‌دادهٔ PostgreSQL، به First\-Time Creation of the PostgreSQL Database \%<#\:pgsql-database-create> مراجعه کنید..SS ابزار ساخت Hammer .sp برنامهٔ Hammer یک اسکریپت Python 3 است که به کاربران اجازه می‌دهد وظایف مربوط به ساخت Kea را به‌طور خودکار انجام دهند، مانند راه‌اندازی ماشین‌های مجازی، نصب وابستگی‌های Kea، کامپایل Kea با گزینه‌های گوناگون، اجرای unit\-testها و موارد دیگر. این ابزار اساساً برای اهداف تضمین کیفیت (QA) داخلی در ISC ایجاد شده است و در توزیع Kea گنجانده نشده است؛ با این حال، در مخزن git متعلق به Kea در دسترس است. این ابزار اساساً برای اهداف داخلی توسعه یافته است و ISC نمی‌تواند عملکرد صحیح آن را تضمین کند. مدیران سیستمی که تصمیم به استفاده از آن می‌گیرند باید این کار را با احتیاط انجام دهند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 استفاده از این ابزار کاملاً اختیاری است. هر کاری که این ابزار انجام می‌دهد را می‌توان به‌صورت دستی انجام داد. .UNINDENT .UNINDENT .sp به کاربری که برای نخستین بار از آن استفاده می‌کند اکیداً توصیه می‌شود به راهنمای توکار Hammer نگاهی بیندازد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./hammer.py \-\-help .EE .UNINDENT .UNINDENT .sp این دستور پارامترهای موجود را فهرست خواهد کرد. .sp ابزار Hammer قادر است سیستم‌عامل‌های گوناگونی را که در LXC یا VirtualBox اجرا می‌شوند راه‌اندازی کند. برای مشاهدهٔ فهرستی از سیستم‌های پشتیبانی‌شده، از دستور \fBsupported\-systems\fP استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./hammer.py supported\-systems fedora: \- 37: lxc \- 38: centos: \- 8: lxc, virtualbox \- 9: rhel: \- 8: virtualbox \- 9: ubuntu: \- 18.04: lxc, virtualbox \- 20.04: lxc \- 22.04: lxc debian: \- 10: lxc, virtualbox \- 11: lxc \- 12: lxc freebsd: \- 12.0: virtualbox \- 12.1: \- 13.0: virtualbox alpine: \- 3.15: lxc \- 3.16: lxc \- 3.17: lxc .EE .UNINDENT .UNINDENT .sp همچنین امکان اجرای ساخت به‌صورت محلی، در سیستم جاری وجود دارد (اگر سیستم‌عامل پشتیبانی شود). .sp نخست، باید وابستگی‌های Hammer نصب شوند: Vagrant و یکی از دو برنامهٔ VirtualBox یا LXC. برنامهٔ Hammer می‌تواند Vagrant و افزونه‌های مورد نیاز Vagrant را با استفاده از دستور زیر نصب کند: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./hammer.py ensure\-hammer\-deps .EE .UNINDENT .UNINDENT .sp برنامه‌های VirtualBox و LXC باید به‌صورت دستی نصب شوند. .sp کارکردهای پایه‌ای ارائه‌شده توسط Hammer عبارتند از آماده‌سازی محیط ساخت و انجام فرآیند واقعی ساخت، و اجرای unit testها به‌صورت محلی در سیستم جاری. این کار را می‌توان با اجرای دستور زیر انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./hammer.py build \-p local .EE .UNINDENT .UNINDENT .sp دامنهٔ فرآیند را می‌توان با استفاده از گزینه‌های \fB\-\-with\fP (\fB\-w\fP) و \fB\-\-without\fP (\fB\-x\fP) تعیین کرد. به‌طور پیش‌فرض، دستور \fBbuild\fP برنامهٔ Kea را به همراه مستندات می‌سازد، آن را به‌صورت محلی نصب می‌کند، و unit testها را اجرا می‌نماید. .sp برای مستثنی کردن نصب و تولید مستندات، وارد کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./hammer.py build \-p local \-x install docs .EE .UNINDENT .UNINDENT .sp دامنهٔ پایه را می‌توان با mysql، pgsql، native\-pkg، shell و forge گسترش داد. لطفاً برای جزئیات بیشتر به \fB\&./hammer.py build \-\-help\fP مراجعه کنید. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در صورت ساخت محلی Kea، به وابستگی‌های Hammer مانند Vagrant نیازی نیست. .UNINDENT .UNINDENT .sp می‌توان به Hammer فرمان داد تا یک ماشین مجازی جدید با یک سیستم‌عامل مشخص‌شده را بدون انجام ساخت راه‌اندازی کند: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./hammer.py prepare\-system \-p virtualbox \-s freebsd \-r 12.0 .EE .UNINDENT .UNINDENT .sp به این ترتیب، می‌توان سیستمی را برای استفادهٔ خود آماده کرد. .sp برای آماده‌سازی چنین سیستمی با استفاده از SSH، دستور زیر را اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./hammer.py ssh \-p virtualbox \-s freebsd \-r 12.0 .EE .UNINDENT .UNINDENT .sp می‌توان سرعت ساخت‌های بعدی Hammer را از طریق ccache \%\& افزایش داد. در حین کامپایل، ccache اشیاء را در یک پوشهٔ اشتراکی ذخیره می‌کند. در اجراهای بعدی، ccache به‌جای انجام یک کامپایل واقعی، اشیاء ذخیره‌شدهٔ پیشین را بازمی‌گرداند. حافظهٔ کش محتوی این اشیاء جهت استفادهٔ مجدد باید در خارج از VM یا LXC ذخیره شود. برای مشخص کردن این پوشه، پارامتر \fB\-\-ccache\-dir\fP باید برای Hammer درج شود. در پوشهٔ تعیین‌شده، برای هر سیستم‌عامل مقصد اشیاء ذخیره‌شدهٔ جداگانه‌ای وجود دارد. .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./hammer.py build \-p lxc \-s ubuntu \-r 18.04 \-\-ccache\-dir ~/kea\-ccache .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر ccache در Hammer فقط برای LXC پشتیبانی می‌شود؛ پشتیبانی از VirtualBox ممکن است بعداً افزوده شود. .UNINDENT .UNINDENT .sp برای اطلاعات بیشتر بررسی کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./hammer.py \-\-help .EE .UNINDENT .UNINDENT.SS اجرای Kea از حساب کاربری غیرریشه (Non\-root) در لینوکس .sp هر دو کارساز DHCPv4 و DHCPv6 در Kea عملیاتی را انجام می‌دهند که به‌طور کلی نیازمند دسترسی‌ها و امتیازات کاربر ریشه (root) است. به‌ویژه، DHCPv4 سوکت‌های raw را باز می‌کند و هر دو کارساز DHCPv4 و DHCPv6 سوکت‌های UDP را روی درگاه‌های ممتاز (privileged) باز می‌کنند. با این حال، با انجام برخی پیکربندی‌های سیستمی اضافی، امکان اجرای Kea از حساب‌های کاربری غیرریشه وجود دارد. .sp ابتدا، باید یک حساب کاربری عادی ایجاد شود: .INDENT 0.0 .INDENT 3.5 .sp .EX useradd admin .EE .UNINDENT .UNINDENT .sp سپس، مالکیت و گروه فایل‌های اجرایی (binaries) را به کاربر جدید تغییر دهید. توجه داشته باشید که مسیر دقیق ممکن است متفاوت باشد. لطفاً به پارامتر \fB\-\-prefix\fP که به \fBmeson setup\fP داده شده است مراجعه کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX chown \-R admin /opt/kea chgrp \-R admin /opt/kea chown \-R admin /var/log/kea/kea\-dhcp4.log chgrp \-R admin /var/log/kea/kea\-dhcp4.log chown \-R admin /var/log/kea/kea\-dhcp6.log chgrp \-R admin /var/log/kea/kea\-dhcp6.log .EE .UNINDENT .UNINDENT .sp در صورت استفاده از systemd، فایل سرویس آن را ویرایش کنید (برای نمونه /etc/systemd/system/kea\-dhcp6.service): .INDENT 0.0 .INDENT 3.5 .sp .EX User=admin Group=admin .EE .UNINDENT .UNINDENT .sp مهم‌ترین مرحله، تنظیم قابلیت‌های (capabilities) فایل‌های باینری است. برای اطلاعات بیشتر به صفحهٔ راهنمای سیستم‌عامل برای \fIcapabilities\fP مراجعه کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX setcap \(aqcap_net_bind_service,cap_net_raw=+ep\(aq /opt/kea/sbin/kea\-dhcp4 setcap \(aqcap_net_bind_service=+ep\(aq /opt/kea/sbin/kea\-dhcp6 .EE .UNINDENT .UNINDENT .sp در صورت استفاده از systemd، این مقدار را نیز به فایل سرویس اضافه کنید (برای نمونه /etc/systemd/system/kea\-dhcp6.service): .INDENT 0.0 .INDENT 3.5 .sp .EX ExecStartPre=setcap \(aqcap_net_bind_service=+ep\(aq /opt/kea/sbin/kea\-dhcp6 .EE .UNINDENT .UNINDENT .sp پس از تکمیل این مرحله، کاربر admin باید قادر به اجرای Kea باشد. توجه داشته باشید که کارساز DHCPv4 به‌طور پیش‌فرض سوکت‌های raw را باز می‌کند. اگر شبکه فقط از ترافیک بازپخش‌شده (relayed) استفاده می‌کند، می‌توان Kea را طوری تنظیم کرد که از سوکت‌های معمولی UDP استفاده کند (به پارامتر \fBdhcp\-socket\-type\fP در بخش پیکربندی رابط \%<#\:dhcp4-interface-configuration> مراجعه کنید) و در نتیجه می‌توان از قابلیت \fBcap_net_raw\fP صرف‌نظر کرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 امکان جلوگیری از اجرای Kea با امتیازات ریشه با هدایت Kea به استفاده از درگاه‌های غیرممتاز (بزرگ‌تر از 1024) و بازهدایت (redirecting) ترافیک وجود دارد. با این حال، این روش فقط برای ترافیک رله‌شده کار می‌کند. این رویکرد به‌طور کلی آزمایشی در نظر گرفته می‌شود و برای به‌کارگیری در محیط‌های عملیاتی آزمایش نشده است. با احتیاط استفاده کنید! .sp برای استفاده از این روش، کارساز را طوری پیکربندی کنید که با اجرای فرایند به همراه گزینهٔ \fB\-p\fP در \fB/etc/systemd/system/kea\-dhcp4.service\fP روی دیگر درگاه‌های غیرممتاز (مانند 1547 و 1548) شنود کند: .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX ExecStart=/opt/kea/sbin/kea\-dhcp4 \-d \-c /etc/kea/kea\-dhcp4.conf \-p 2067 .EE .UNINDENT .UNINDENT .sp و در \fB/etc/systemd/system/kea\-dhcp4.service\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX ExecStart=/opt/kea/sbin/kea\-dhcp6 \-d \-c /etc/kea/kea\-dhcp6.conf \-p 1547 .EE .UNINDENT .UNINDENT .sp سپس بازهدایت درگاه را با iptables و ip6tables برای درگاه‌های جدید (مانند 1547 و 1548) پیکربندی کنید. حتماً \fBens4\fP را با نام رابط شبکهٔ موردنظر جایگزین کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX iptables \-t nat \-A PREROUTING \-i ens4 \-p udp \-\-dport 67 \-j REDIRECT \-\-to\-port 2067 iptables \-t nat \-A PREROUTING \-i ens4 \-p udp \-\-dport 2068 \-j REDIRECT \-\-to\-port 68 ip6tables \-t nat \-A PREROUTING \-i ens4 \-p udp \-\-dport 547 \-j REDIRECT \-\-to\-port 1547 ip6tables \-t nat \-A PREROUTING \-i ens4 \-p udp \-\-dport 1548 \-j REDIRECT \-\-to\-port 548 .EE .UNINDENT .UNINDENT .SS ویژگی‌های منسوخ‌شده (Deprecated Features) .sp این بخش ویژگی‌های مهمی را که حذف شده‌اند یا قرار است حذف شوند فهرست می‌کند. ما تلاش می‌کنیم پیش از حذف ویژگی‌ها، آن‌ها را منسوخ اعلام کنیم تا کاربران فعلی فرصت برنامه‌ریزی برای مهاجرت را داشته باشند. کاربران جدید نباید به ویژگی‌های منسوخ‌شده تکیه کنند..SS Sysrepo 0.x یا 1.x .sp در نسخه 2.3.2 از Kea پشتیبانی از Sysrepo 2.x معرفی شد. متأسفانه Sysrepo همچنان دستخوش تغییرات اساسی ناسازگار با نسخه‌های پیشین (backward\-incompatible) است، و نسخه‌های کنونی Kea از نگارش‌های پیش از 2.x در Sysrepo پشتیبانی نمی‌کنند. .SH "مدیریت پایگاه داده KEA (KEA DATABASE ADMINISTRATION)" .SS پایگاه‌های داده و نسخه‌های اسکیما (Databases and Schema Versions) .sp می‌توان Kea را به گونه‌ای پیکربندی کرد که از یک پایگاه داده به عنوان محل ذخیره‌سازی اجاره‌ها (leases) یا به عنوان منبعی برای پیکربندی سرورها و رزروهای میزبان (یعنی تخصیص ایستا برای نشانی‌ها، پیشوندها، گزینه‌ها و غیره) استفاده نماید. با به‌روزرسانی Kea، اسکیماهای (schemas) جدیدی برای پایگاه داده معرفی می‌شوند تا پیاده‌سازی قابلیت‌های جدید تسهیل شده و اشکالات کشف‌شده در اسکیماهای پیشین برطرف گردند. .sp هر نسخه از Kea ساختار اسکیمای مشخصی را انتظار دارد و با بررسی نسخه پایگاه داده‌ای که استفاده می‌کند، این مورد را ارزیابی می‌نماید. شماره نسخه‌های مجزایی برای اسکیماها مستقل از نسخه خودِ Kea نگهداری می‌شوند. این امکان وجود دارد که نسخه اسکیما در طول چندین بازنگری Kea ثابت بماند؛ به همین ترتیب این احتمال وجود دارد که نسخه اسکیما در جریان یک ارتقای تکی نسخه Kea، چندین نگارش افزایش یابد. نسخه‌ها برای هر نوع بک‌اند (backend) نیز مستقل هستند، بنابراین افزایش نسخه در بک‌اند MySQL به معنای افزایش در نسخه PostgreSQL نخواهد بود. .sp نسخه‌های اسکیما در قالب major.minor مشخص می‌شوند. در جدیدترین نسخه‌ها، نسخه minor همیشه صفر بوده و تنها نسخه major افزایش می‌یابد. .sp از نظر تاریخی، نسخه minor زمانی افزایش می‌یافت که تغییرات سازگار با گذشته (backward\-compatible) در اسکیما اعمال می‌شد؛ برای نمونه، هنگامی که یک نمایه (index) جدید افزوده می‌شد. این امر در مقابل افزایش نسخه major بود که تغییر ناسازگار در اسکیما را نشان می‌داد؛ برای نمونه تغییر نوع یک ستون موجود. اگر Kea تلاش کند روی اسکیمایی اجرا شود که بیش از حد قدیمی است (همان‌طور که از عدم تطابق نسخه اسکیما مشخص می‌شود)، ناموفق خواهد بود؛ در این حالت برای ارتقای اسکیما به اقدام مدیریتی نیاز است. .SS ابزار \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> .sp برای مدیریت پایگاه‌های داده، Kea ابزار \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> را ارائه می‌دهد. این ابزار می‌تواند یک بک‌اند جدید را مقداردهی اولیه کند، شماره نسخه آن را بررسی نماید، ارتقای بک‌اند را انجام دهد، و داده‌های اجاره (lease) را در یک فایل متنی ذخیره (dump) کند. .sp دستور \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> دو پارامتر اجباری دریافت می‌کند: \fBcommand\fP و \fBbackend\fP\&. گزینه‌های غیراجباری دیگری نیز ممکن است مشخص شوند. دستورهای پشتیبانی‌شده کنونی عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBdb\-init\fP — یک اسکیمای جدید پایگاه داده را مقداردهی اولیه می‌کند که هنگام نصب تازه Kea سودمند است. پایگاه داده جدید مطابق با نسخه Kea در حال نصب به‌روزرسانی می‌شود. در صورتی که حین راه‌اندازی یا پیکربندی مجدد سرورهای Kea DHCP عدم وجود اسکیما تشخیص داده شود، \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> به طور خودکار با این دستور فراخوانی می‌شود. .IP \(bu 2 \fBdb\-version\fP — شماره نسخه بک‌اند پایگاه داده را گزارش می‌دهد. این مقدار لزوماً با شماره نسخه Kea یکسان نیست، چرا که هر بک‌اند طرح نسخه‌گذاری مختص به خود را دارد. .IP \(bu 2 \fBdb\-upgrade\fP — یک ارتقای اسکیمای پایگاه داده را انجام می‌دهد. این دستور هنگام ارتقای Kea کاربرد دارد. .IP \(bu 2 \fBlease\-dump\fP — محتویات پایگاه داده اجاره را (برای بک‌اندهای MySQL یا PostgreSQL) در یک فایل متنی CSV (مقادیر جداشده با کاما) استخراج می‌کند (dump). .sp خط نخست این فایل حاوی نام ستون‌ها است. این کار می‌تواند راهکاری برای تغییر از یک بک‌اند پایگاه داده به یک بک‌اند memfile باشد. از سوی دیگر، می‌توان از آن به عنوان یک ابزار عیب‌یابی استفاده کرد که قالب قابل حملی از داده‌های اجاره را فراهم می‌سازد. .IP \(bu 2 \fBlease\-upload\fP — اجاره‌ها را از یک فایل متنی CSV (مقادیر جداشده با کاما) به یک پایگاه داده اجاره MySQL یا PostgreSQL بارگذاری می‌کند. فایل CSV باید در قالب memfile باشد. .UNINDENT .sp پارامتر \fBbackend\fP نوع پایگاه داده بک‌اند را مشخص می‌کند. انواع پشتیبانی‌شده کنونی عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBmemfile\fP — اطلاعات اجاره بر روی دیسک در یک فایل متنی ذخیره می‌شود. .IP \(bu 2 \fBmysql\fP — اطلاعات در یک پایگاه داده رابطه‌ای MySQL ذخیره می‌شود. .IP \(bu 2 \fBpgsql\fP — اطلاعات در یک پایگاه داده رابطه‌ای PostgreSQL ذخیره می‌شود. .UNINDENT .sp بسته به راه‌اندازی و عملیات مورد نظر، ممکن است به پارامترهای بیشتری نیاز باشد: نام کاربری (username)، گذرواژه (password)، و نام پایگاه داده یا دایرکتوری محل قرارگیری فایل‌های مشخص. برای جزئیات به صفحه راهنمای مربوطه مراجعه کنید (\fBman 8 kea\-admin\fP). .SS بک‌اندهای پشتیبانی‌شده (Supported Backends) .sp جدول زیر قابلیت‌های بک‌اندهای موجود را نشان می‌دهد. لطفاً برای درک بهتر توانایی‌ها و محدودیت‌ها به بخش‌های اختصاصی هر بک‌اند مراجعه کنید. انتخاب بک‌اند مناسب برای موفقیت استقرار حیاتی است. .SS فهرست بک‌اندهای موجود .TS box center; l|l|l|l. T{ ویژگی T} T{ Memfile T} T{ MySQL T} T{ PostgreSQL T} _ T{ وضعیت T} T{ پایدار T} T{ پایدار T} T{ پایدار T} _ T{ قالب داده T} T{ فایل CSV T} T{ SQL RMDB T} T{ SQL RMDB T} _ T{ اجاره‌ها T} T{ بله T} T{ بله T} T{ بله T} _ T{ رزروهای میزبان T} T{ خیر T} T{ بله T} T{ بله T} _ T{ گزینه‌های تعریف‌شده برای هر میزبان T} T{ خیر T} T{ بله T} T{ بله T} _ T{ بک‌اند پیکربندی T} T{ خیر T} T{ بله T} T{ بله T} .TE.SS Memfile .sp بک‌اند memfile قادر به ذخیره اطلاعات اجاره (lease) است، اما نمی‌تواند جزئیات رزرو میزبان را ذخیره کند؛ این اطلاعات باید در فایل پیکربندی ذخیره شوند. (هیچ برنامه‌ای برای افزودن قابلیت ذخیره‌سازی رزروهای میزبان به این بک‌اند وجود ندارد.) .sp هیچ مرحله راه‌اندازی اولیه‌ی خاصی برای بک‌اند memfile لازم نیست. در طول نخستین اجرا، هم \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و هم \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> در صورت عدم وجود فایل اجاره، یک فایل اجاره‌ی خالی ایجاد می‌کنند. داشتن مجوز لازم برای نوشتن روی دیسک مورد نیاز است. .SS "ارتقای فایل‌های اجاره Memfile از نسخه‌های پیشین Kea" .sp برای ارتقای فایل‌های اجاره memfile میان نسخه‌های Kea به هیچ مرحله‌ی خاصی نیاز نیست. در زمان راه‌اندازی، کارسازها نسخه شمای فایل‌های اجاره را با نسخه شمای خود بررسی و تطبیق می‌دهند. اگر عدم تطابقی وجود داشته باشد، کارسازها به‌طور خودکار فرایند LFC را اجرا می‌کنند تا فایل‌ها را به نسخه شمای کارساز تبدیل کند. در حالی که هدف اصلی این سازوکار تسهیل فرایند ارتقا به نسخه‌های جدیدتر Kea است، در صورت نیاز می‌تواند برای تنزیل نسخه (downgrade) نیز به کار رود. هنگام ارتقا، به هر مقداری که در فایل‌های اجاره اولیه موجود نباشد، مقادیر پیش‌فرض مناسب اختصاص می‌یابد. هنگام تنزیل، هر داده‌ای که در فایل‌ها موجود باشد اما در شمای کارساز وجود نداشته باشد، حذف می‌شود. برای تبدیل دستی فایل‌ها پیش از راه‌اندازی کارسازها، فرایند پاک‌سازی فایل اجاره (LFC) را اجرا کنید. برای اطلاعات بیشتر بخش «فرایند LFC» \%<#\:kea-lfc> را ببینید. .SS MySQL .sp پایگاه داده MySQL قادر است اجاره‌ها، رزروهای میزبان، گزینه‌های تعریف‌شده به‌ازای هر میزبان، و زیرمجموعه‌ای از پارامترهای پیکربندی کارساز را ذخیره کند (و به‌عنوان بک‌اند پیکربندی عمل نماید). .SS "مقایسه MySQL 5.7 با MySQL 8 و MariaDB 10 و 11" .sp در آزمایش‌های کارایی Kea، نسخه MySQL 8 افتی ۶۰ تا ۹۰ درصدی در سرعت در مقایسه با MySQL 5.7 نشان می‌دهد. با توجه به پایان عمر (EOL) قریب‌الوقوع MySQL 5.7، توصیه می‌کنیم به جای MySQL 8 از MariaDB استفاده کنید. .sp نسخه‌های MySQL 5.7، MySQL 8، MariaDB 10، و MariaDB 11 کاملاً سازگار، قابل جایگزینی با یکدیگر، و همراه با Kea آزمایش شده‌اند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نگارش MySQL یا MariaDB مورد استفاده شما باید از پردازش JSON پشتیبانی کند. مواردی که در بالا فهرست شده‌اند یا جدیدتر باید پشتیبانی کنند. این موضوع را می‌توان با دستور SQL زیر بررسی کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX mysql> SELECT JSON_EXTRACT(\(aq{ \(dqfoo\-bar\(dq: 1 }\(aq, \(aq$.\(dqfoo\-bar\(dq\(aq); +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | JSON_EXTRACT(\(aq{ \(dqfoo\-bar\(dq: 1 }\(aq, \(aq$.\(dqfoo\-bar\(dq\(aq) | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | 1 | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ 1 row in set (0.01 sec) .EE .UNINDENT .UNINDENT .sp هر نتیجه‌ی دیگری نشان می‌دهد که از JSON پشتیبانی نمی‌شود. .UNINDENT .UNINDENT .SS "ایجاد پایگاه داده MySQL برای نخستین بار" .sp پیش از آماده‌سازی هر پایگاه داده و جدول‌های ویژه Kea، پایگاه داده MySQL باید طوری پیکربندی شود که از منطقه زمانی سیستم استفاده کند. توصیه می‌شود هم برای سیستم و هم برای پایگاه داده MySQL از UTC به‌عنوان منطقه زمانی استفاده شود. .sp برای بررسی منطقه زمانی سیستم: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX date +%Z .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp برای بررسی منطقه زمانی MySQL: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX mysql> SELECT @@system_time_zone; mysql> SELECT @@global.time_zone; mysql> SELECT @@session.time_zone; .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp برای پیکربندی منطقه زمانی MySQL برای یک کارساز خاص، لطفاً به مستندات نسخه نصب‌شده مراجعه کنید. .sp معمولاً این تنظیم در بخش [mysqld] در فایل‌های \fB/etc/mysql/my.cnf\fP، \fB/etc/mysql/mysql.cnf\fP، \fB/etc/mysql/mysqld.cnf\fP، یا \fB/etc/mysql/mysql.conf.d/mysqld.cnf\fP پیکربندی می‌شود\&. .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX [mysqld] # using default\-time\-zone default\-time\-zone=\(aq+00:00\(aq # or using timezone timezone=\(aqUTC\(aq .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp هنگام راه‌اندازی پایگاه داده MySQL برای نخستین بار، فضای پایگاه داده باید در MySQL ایجاد شده و شناسه کاربری MySQL که Kea از طریق آن به پایگاه داده دسترسی خواهد داشت تنظیم شود. این کار باید به‌صورت دستی انجام شود، نه از طریق \fBkea\-admin\fP \%<#\:std-iscman-kea-admin>\&. .sp برای ساخت پایگاه داده: .INDENT 0.0 .IP 1. 3 با کاربر \(dqroot\(dq وارد MySQL شوید: .INDENT 3.0 .INDENT 3.5 .sp .EX $ mysql \-u root \-p Enter password: mysql> .EE .UNINDENT .UNINDENT .IP 2. 3 پایگاه داده MySQL را ایجاد کنید: .INDENT 3.0 .INDENT 3.5 .sp .EX mysql> CREATE DATABASE database_name; .EE .UNINDENT .UNINDENT .sp (\fBdatabase_name\fP نام انتخاب‌شده برای پایگاه داده است.) .IP 3. 3 کاربری را که Kea از طریق آن به پایگاه داده دسترسی خواهد داشت ایجاد کنید (و به آن گذرواژه بدهید)، سپس دسترسی به جدول‌های پایگاه داده را به آن اعطا کنید: .INDENT 3.0 .INDENT 3.5 .sp .EX mysql> CREATE USER \(aquser\-name\(aq@\(aqlocalhost\(aq IDENTIFIED BY \(aq1234\(aq; mysql> GRANT ALL ON database\-name.* TO \(aquser\-name\(aq@\(aqlocalhost\(aq; .EE .UNINDENT .UNINDENT .sp (\fBuser\-name\fP و \fBpassword\fP شناسه کاربری و گذرواژه‌ای هستند که برای دسترسی دادن به Kea به نمونه MySQL استفاده می‌شوند. تمام علامت‌های آپوستروف در خطوط فرمان بالا الزامی هستند.) .IP 4. 3 پایگاه داده را بسازید. .INDENT 3.0 .INDENT 3.5 از کلاینت MySQL خارج شوید .INDENT 0.0 .INDENT 3.5 .sp .EX mysql> quit Bye .EE .UNINDENT .UNINDENT .sp سپس از ابزار \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> برای ایجاد پایگاه داده استفاده کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-admin db\-init mysql \-u database\-user \-p database\-password \-n database\-name .EE .UNINDENT .UNINDENT .sp اگرچه امکان ساخت پایگاه داده از داخل کلاینت MySQL وجود دارد، توصیه می‌کنیم از ابزار \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> استفاده کنید؛ چرا که این ابزار برخی اعتبارسنجی‌های لازم را انجام می‌دهد تا اطمینان حاصل شود Kea می‌تواند در زمان اجرا به پایگاه داده دسترسی داشته باشد. از جمله این بررسی‌ها، اطمینان از این است که شما فاقد هرگونه جدول از پیش موجود باشد؛ هر جدول از پیش موجود باید به‌صورت دستی حذف شود. یک بررسی دیگر، توانایی کاربر در ساخت توابع و تریگرها را ارزیابی می‌کند. خطای زیر نشان می‌دهد که کاربر مجوزهای لازم برای ایجاد توابع یا تریگرها را ندارد: .INDENT 0.0 .INDENT 3.5 .sp .EX ERROR 1419 (HY000) at line 1: You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) ERROR/kea\-admin: mysql_can_create cannot trigger, check user permissions, mysql status = 1 mysql: [Warning] Using a password on the command line interface can be insecure. ERROR/kea\-admin: Create failed, the user, keatest, has insufficient privileges. .EE .UNINDENT .UNINDENT .sp ساده‌ترین راهکار برای حل این مشکل، تنظیم متغیر سراسری MySQL یعنی \fBlog_bin_trust_function_creators\fP روی 1 از طریق کلاینت MySQL است. توجه داشته باشید که این کار باید توسط کاربری با امتیازات SUPER انجام شود: .INDENT 0.0 .INDENT 3.5 .sp .EX mysql> set @@global.log_bin_trust_function_creators = 1; Query OK, 0 rows affected (0.00 sec) .EE .UNINDENT .UNINDENT .sp برای ایجاد مستقیم پایگاه داده با MySQL، مراحل زیر را دنبال کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX mysql> CONNECT database\-name; mysql> SOURCE path\-to\-kea/share/kea/scripts/mysql/dhcpdb_create.mysql .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp (که در آن \fBpath\-to\-kea\fP مکانی است که Kea در آن نصب شده است.) .INDENT 3.0 .INDENT 3.5 همچنین می‌توان پایگاه داده را به‌صورت دستی به شکل زیر حذف (drop) کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX mysql> CONNECT database\-name; mysql> SOURCE path\-to\-kea/share/kea/scripts/mysql/dhcpdb_drop.mysql .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp (که در آن \fBpath\-to\-kea\fP مکانی است که Kea در آن نصب شده است.) .UNINDENT .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 حذف پایگاه داده منجر به از دست رفتن غیرقابل بازیابی تمامی داده‌های موجود در آن می‌شود. .UNINDENT .UNINDENT .INDENT 0.0.IP 5. 3 خروج از MySQL: .INDENT 3.0 .INDENT 3.5 .sp .EX mysql> quit Bye .EE .UNINDENT .UNINDENT .UNINDENT .sp اگر جدول‌ها در مرحله 4 ساخته نشده‌اند، اکنون ابزار \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> را برای ایجاد آن‌ها اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-admin db\-init mysql \-u database\-user \-p database\-password \-n database\-name .EE .UNINDENT .UNINDENT .sp اگر جدول‌ها در مرحله 4 ساخته شده‌اند، این کار را انجام ندهید. ابزار \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> بررسی‌های اولیه‌ای انجام می‌دهد؛ اگر پایگاه داده حاوی هرگونه جدول موجود باشد، از مقداردهی اولیه آن خودداری خواهد کرد. برای شروع از ابتدا، همه داده‌ها باید به‌صورت دستی حذف شوند. (این فرآیند عمداً یک عملیات دستی است تا از خطاهای تصادفی و جبران‌ناپذیر توسط \fBkea\-admin\fP \%<#\:std-iscman-kea-admin>\& جلوگیری شود.) .SS ارتقای پایگاه داده MySQL از نسخه پیشین Kea .sp گاهی یک نسخه جدید Kea از شمای پایگاه داده جدیدتری استفاده می‌کند، بنابراین پایگاه داده موجود باید ارتقا یابد. این کار را می‌توان با استفاده از دستور \fBkea\-admin db\-upgrade\fP انجام داد. .sp برای بررسی نسخه فعلی پایگاه داده، از دستور زیر استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-admin db\-version mysql \-u database\-user \-p database\-password \-n database\-name .EE .UNINDENT .UNINDENT .sp (برای بحث درباره نسخه‌بندی، بخش Databases and Schema Versions را ببینید.) اگر نسخه با حداقل مقدار لازم برای نسخه جدید Kea (همان‌طور که در یادداشت‌های انتشار آمده است) مطابقت ندارد، پایگاه داده باید ارتقا یابد. .sp پیش از ارتقا، لطفاً اطمینان حاصل کنید که از پایگاه داده نسخه پشتیبان تهیه شده است. فرآیند ارتقا هیچ داده‌ای را حذف نمی‌کند، اما بسته به ماهیت تغییرات، ممکن است پس از آن امکان بازگشت (downgrade) به نسخه پیشین وجود نداشته باشد. .sp برای انجام ارتقا، دستور زیر را اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-admin db\-upgrade mysql \-u database\-user \-p database\-password \-n database\-name .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برای جستجوی رزروهای میزبان (host reservations) بر اساس hostname، بسیار حیاتی است که ترتیب تطبیق (collation) ستون hostname در جدول host به بزرگی و کوچکی حروف حساس نباشد (case\-insensitive). خوشبختانه این حالت پیش‌فرض در MySQL است، اما می‌توان با این دستور آن را تایید کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX mysql> SELECT COLLATION(\(aq\(aq); +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | COLLATION(\(aq\(aq) | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | utf8_general_ci | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ .EE .UNINDENT .UNINDENT .sp طبق قواعد نام‌گذاری MySQL، هنگامی که نام به \fB_ci\fP ختم می‌شود، تطبیق (collation) به بزرگی و کوچکی حروف غیرحساس است. .UNINDENT .UNINDENT .SS بهبود کارایی با MySQL .sp تغییر مقدار درونی MySQL یعنی \fBinnodb_flush_log_at_trx_commit\fP از مقدار پیش‌فرض 1 به 2 می‌تواند منجر به بهبود چشمگیری در کارایی Kea شود. در برخی از پیاده‌سازی‌ها، این بهبود بیش از 1000% بوده است (هنگام تنظیم روی 2، در مقایسه با مقدار پیش‌فرض 1، ۱۰ برابر سریع‌تر شده است). برای آزمایش، می‌توان آن را به‌ازای هر نشست (per\-session) تنظیم کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX mysql> SET GLOBAL innodb_flush_log_at_trx_commit=2; mysql> SHOW SESSION VARIABLES LIKE \(aqinnodb_flush_log%\(aq; .EE .UNINDENT .UNINDENT .sp یا به‌صورت دائمی در \fB/etc/mysql/my.cnf\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX [mysqld] innodb_flush_log_at_trx_commit=2 .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که تغییر این مقدار ممکن است در طول بازیابی داده‌ها پس از فروپاشی (crash) مشکلاتی ایجاد کند، بنابراین پیشنهاد می‌کنیم مستندات MySQL \%\& را بررسی کنید. با مقدار پیش‌فرض 1، MySQL پس از هر پرس‌وجوی INSERT یا UPDATE تغییرات را روی دیسک می‌نویسد (در اصطلاح Kea، هر بار که یک کلاینت یک اجاره جدید دریافت می‌کند یا اجاره موجود را تمدید می‌کند). هنگامی که \fBinnodb_flush_log_at_trx_commit\fP روی 2 تنظیم شده باشد، MySQL تغییرات را در فواصل زمانی حداکثر ۱ ثانیه می‌نویسد. دسته‌بندی عملیات‌های نوشتن، شتاب قابل‌توجهی به کارایی می‌دهد. با این حال، موازنه این است که در بدترین سناریو، ممکن است تمام تغییرات در آخرین ثانیه قبل از فروپاشی از دست بروند. با توجه به اینکه Kea نرم‌افزاری پایدار است و بسیار به‌ندرت دچار فروپاشی می‌شود، بیشتر پیاده‌سازی‌ها این موازنه را سودمند می‌دانند..SS PostgreSQL .sp پایگاه داده‌ی PostgreSQL می‌تواند اجاره‌ها (leases)، رزروهای میزبان (host reservations) و گزینه‌های تعریف‌شده بر اساس هر میزبان (per\-host) را ذخیره کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نسخهٔ PostgreSQL مورد استفاده شما باید از پردازش JSON پشتیبانی کند. هر نسخه‌ای از 9.4 به بعد باید از آن پشتیبانی نماید. این موضوع را می‌توان با دستور SQL زیر بررسی کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX => SELECT proname FROM pg_proc WHERE proname = \(aqjson_extract_path\(aq; proname \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- json_extract_path (1 row) .EE .UNINDENT .UNINDENT .sp هر نتیجهٔ دیگری نشان‌دهندهٔ عدم پشتیبانی از JSON است. .UNINDENT .UNINDENT .SS ساخت اولیه پایگاه داده PostgreSQL .sp پیش از آماده‌سازی هرگونه پایگاه داده و جدول‌های ویژهٔ Kea، پایگاه دادهٔ PostgreSQL باید طوری پیکربندی شود که از منطقه زمانی (timezone) سیستم استفاده کند. توصیه می‌شود برای منطقه زمانی سیستم و پایگاه دادهٔ PostgreSQL از UTC استفاده شود. .sp برای بررسی منطقه زمانی سیستم: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX date +%Z .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp برای بررسی منطقه زمانی PostgreSQL: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX postgres=# show timezone; postgres=# SELECT * FROM pg_timezone_names WHERE name = current_setting(\(aqTIMEZONE\(aq); .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp برای پیکربندی منطقه زمانی PostgreSQL برای یک سرور خاص، لطفاً به مستندات نسخهٔ نصب‌شده مراجعه کنید. .sp معمولاً این تنظیم در فایل \fBpostgresql.conf\fP با مسیر متغیر بر اساس نسخه یعنی \fB/etc/postgresql//main/postgresql.conf\fP پیکربندی می‌شود، اما در برخی سیستم‌ها ممکن است این فایل‌ها در \fB/var/lib/pgsql/data\fP قرار داشته باشند\&. .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX timezone = \(aqUTC\(aq .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp نخستین کار، ساخت پایگاه داده و کاربری است که کارگزارها با آن به پایگاه داده دسترسی خواهند داشت. چندین مرحله لازم است: .INDENT 0.0 .IP 1. 3 با کاربر \(dqpostgres\(dq به PostgreSQL وارد شوید: .INDENT 3.0 .INDENT 3.5 .sp .EX $ sudo \-u postgres psql postgres Enter password: postgres=# .EE .UNINDENT .UNINDENT .IP 2. 3 پایگاه داده را بسازید: .INDENT 3.0 .INDENT 3.5 .sp .EX postgres=# CREATE DATABASE database\-name; CREATE DATABASE postgres=# .EE .UNINDENT .UNINDENT .sp (\fBdatabase\-name\fP نام انتخاب‌شده برای پایگاه داده است.) .IP 3. 3 کاربری را که Kea از طریق آن به پایگاه داده دسترسی خواهد داشت بسازید (و برای آن گذرواژه‌ای تعیین کنید)، سپس دسترسی به پایگاه داده را به آن اعطا نمایید: .INDENT 3.0 .INDENT 3.5 .sp .EX postgres=# CREATE USER user\-name WITH PASSWORD \(aq1234\(aq; CREATE ROLE postgres=# GRANT ALL PRIVILEGES ON DATABASE database\-name TO user\-name; GRANT postgres=# \ec database\-name You are now connected to database \(dqdatabase\-name\(dq as user \(dqpostgres\(dq. postgres=# GRANT ALL PRIVILEGES ON SCHEMA public TO user\-name; GRANT postgres=# .EE .UNINDENT .UNINDENT .IP 4. 3 از PostgreSQL خارج شوید: .INDENT 3.0 .INDENT 3.5 .sp .EX postgres=# \eq Bye $ .EE .UNINDENT .UNINDENT .IP 5. 3 در این مرحله، جدول‌های پایگاه داده را یا با استفاده از ابزار \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> آن‌گونه که در بخش بعدی توضیح داده شده است بسازید (توصیه‌شده)، یا به صورت دستی. برای ساخت دستی جدول‌ها، دستور زیر را وارد کنید. PostgreSQL از مدیر سیستم می‌خواهد گذرواژهٔ کاربر جدید را که در مرحله ۳ تعیین شده بود وارد کند. پس از تکمیل دستور، Kea به اعلان خط فرمان بازخواهد گشت. خروجی باید شبیه به موارد زیر باشد: .INDENT 3.0 .INDENT 3.5 .sp .EX $ psql \-d database\-name \-U user\-name \-f path\-to\-kea/share/kea/scripts/pgsql/dhcpdb_create.pgsql Password for user user\-name: CREATE TABLE CREATE INDEX CREATE INDEX CREATE TABLE CREATE INDEX CREATE TABLE START TRANSACTION INSERT 0 1 INSERT 0 1 INSERT 0 1 COMMIT CREATE TABLE START TRANSACTION INSERT 0 1 COMMIT $ .EE .UNINDENT .UNINDENT .sp (\fBpath\-to\-kea\fP محل نصب Kea است.) .sp چنانچه به جای آن با خطایی مواجه شدید، مانند: .INDENT 3.0 .INDENT 3.5 .sp .EX psql: FATAL: no pg_hba.conf entry for host \(dq[local]\(dq, user \(dquser\-name\(dq, database \(dqdatabase\-name\(dq, SSL off .EE .UNINDENT .UNINDENT .sp \&... پیکربندی PostgreSQL نیاز به تغییر خواهد داشت. Kea هنگام اتصال به پایگاه داده از احراز هویت با گذرواژه استفاده می‌کند و باید مدخل‌های مناسب به فایل pg_hba.conf در PostgreSQL اضافه شوند. این فایل معمولاً در دایرکتوری اصلی داده‌های کارگزار PostgreSQL قرار دارد. مسیر دقیق ممکن است بسته به سیستم‌عامل و نسخه متفاوت باشد، اما مکان پیش‌فرض برای PostgreSQL مسیر \fB/etc/postgresql/*/main/postgresql.conf\fP است\&. با این حال، در برخی سیستم‌ها این فایل ممکن است در \fB/var/lib/pgsql/data\fP قرار داشته باشد\&. .sp با این فرض که Kea روی همان میزبانِ PostgreSQL اجرا می‌شود، افزودن خطوطی شبیه به موارد زیر برای فراهم کردن دسترسی مبتنی بر احراز هویت گذرواژه‌ای به پایگاه دادهٔ Kea کافی خواهد بود: .INDENT 3.0 .INDENT 3.5 .sp .EX local database\-name user\-name password host database\-name user\-name 127.0.0.1/32 password host database\-name user\-name ::1/128 password .EE .UNINDENT .UNINDENT .sp این ویرایش‌ها عمدتاً به عنوان یک نقطهٔ شروع در نظر گرفته شده‌اند و مرجعی قطعی برای مدیریت PostgreSQL یا امنیت پایگاه داده نیستند. لطفاً پیش از اعمال این تغییرات با راهنمای کاربری PostgreSQL مشورت کنید، زیرا این کار ممکن است سایر پایگاه‌های دادهٔ در حال اجرا را در معرض دسترسی قرار دهد. برای اعمال تغییرات ممکن است راه‌اندازی مجدد PostgreSQL لازم باشد. .UNINDENT.SS مقداردهی اولیه پایگاه داده PostgreSQL با استفاده از \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> .sp اگر جدول‌ها به‌صورت دستی ایجاد نشده‌اند، اکنون با اجرای ابزار \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> این کار را انجام دهید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-admin db\-init pgsql \-u database\-user \-p database\-password \-n database\-name .EE .UNINDENT .UNINDENT .sp اگر جدول‌ها قبلاً به‌صورت دستی ایجاد شده‌اند، این کار را انجام ندهید. \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> بررسی‌های اولیه‌ای انجام می‌دهد؛ اگر پایگاه داده شامل هرگونه جدول موجود باشد، از مقداردهی اولیه آن خودداری خواهد کرد. برای شروع از ابتدا، تمام داده‌ها باید به‌صورت دستی حذف شوند. (این فرآیند عمداً یک عملیات دستی در نظر گرفته شده است تا از خطاهای تصادفی و جبران‌ناپذیر توسط \fBkea\-admin\fP \%<#\:std-iscman-kea-admin>\& جلوگیری شود.) .SS ارتقای موتور PostgreSQL از یک نسخه قدیمی‌تر .sp اگر PostgreSQL خود را از نسخه‌ای قدیمی‌تر از 15.0 ارتقا داده‌اید، نیاز است مجوزهای اضافی به کاربر اعطا کنید: .sp ابتدا، با عنوان کاربر \(dqpostgres\(dq وارد PostgreSQL شوید: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX $ sudo \-u postgres psql \-d database\-name \-U postgres Enter password: postgres=# .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp سپس، دسترسی به طرح‌واره (schema) \fBpublic\fP را اعطا کنید. .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX postgres=# GRANT ALL PRIVILEGES ON SCHEMA public TO user\-name; GRANT postgres=# .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp اکنون، از کلاینت PostgreSQL خارج شوید: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX postgres=# \eq Bye $ .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .SS ارتقای پایگاه داده PostgreSQL از نسخه قدیمی‌تر Kea .sp طرح‌واره پایگاه داده PostgreSQL را می‌توان با استفاده از همان ابزار و دستورهای شرح‌داده‌شده در «ارتقای پایگاه داده MySQL از نسخه قدیمی‌تر Kea» ارتقا داد، با این استثنا که باید از نوع backend پایگاه داده \(dqpgsql\(dq در دستورها استفاده شود. .sp برای بررسی نسخه فعلی طرح‌واره از دستور زیر استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-admin db\-version pgsql \-u database\-user \-p database\-password \-n database\-name .EE .UNINDENT .UNINDENT .sp برای انجام ارتقا از دستور زیر استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-admin db\-upgrade pgsql \-u database\-user \-p database\-password \-n database\-name .EE .UNINDENT .UNINDENT .SS بهبود کارایی با PostgreSQL .sp تغییر مقدار داخلی \fBsynchronous_commit\fP در PostgreSQL از مقدار پیش‌فرض ON به OFF می‌تواند منجر به بهبود چشمگیر کارایی Kea شود؛ در سیستم‌های کند، این بهبود می‌تواند بیش از ۱۰۰۰٪ باشد. برای آزمایش، می‌توان آن را به ازای هر نشست (per\-session) تنظیم کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX postgres=# SET synchronous_commit = OFF; .EE .UNINDENT .UNINDENT .sp یا به صورت دائمی از طریق دستور (روش ترجیحی): .INDENT 0.0 .INDENT 3.5 .sp .EX postgres=# ALTER SYSTEM SET synchronous_commit=OFF; .EE .UNINDENT .UNINDENT .sp یا به صورت دائمی در فایل \fB/etc/postgresql/[version]/main/postgresql.conf\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX synchronous_commit = off .EE .UNINDENT .UNINDENT .sp تغییر این مقدار می‌تواند در طول بازیابی داده‌ها پس از خرابی ناگهانی (crash) مشکلاتی ایجاد کند، بنابراین توصیه می‌کنیم مستندات PostgreSQL را به نشانی \%\& با دقت مطالعه کنید. با مقدار پیش‌فرض ON، پایگاه داده PostgreSQL تغییرات را پس از هر پرس‌وجوی INSERT یا UPDATE روی دیسک می‌نویسد (در اصطلاح Kea، هر بار که یک کلاینت یک اجاره (lease) جدید دریافت می‌کند یا اجاره موجود را تمدید می‌کند). هنگامی که \fBsynchronous_commit\fP روی OFF تنظیم شود، PostgreSQL قبل از نوشتن تغییرات مقداری تأخیر ایجاد می‌کند. دسته‌بندی نوشتن‌ها بهبود کارایی قابل‌توجهی به همراه دارد، اما در بدترین سناریو، ممکن است تمام تغییرات در آخرین لحظات قبل از خرابی ناگهانی از دست بروند. از آنجا که Kea نرم‌افزاری پایدار است و بسیار به‌ندرت دچار خرابی می‌شود، در اغلب استقرارها مزایای کارایی بر خطرات احتمالی برتری دارد..SS استفاده از پایگاه‌های داده فقط‌خواندنی با رزروهای میزبان .sp اگر از یک پایگاه داده فقط‌خواندنی برای ذخیره رزروهای میزبان (host reservations) استفاده شود، Kea باید صریحاً برای کار با پایگاه داده در حالت فقط‌خواندنی (read\-only) پیکربندی شود. بخش‌های Using Read\-Only Databases for Host Reservations With DHCPv4 \%<#\:read-only-database-configuration4> و Using Read\-Only Databases for Host Reservations with DHCPv6 \%<#\:read-only-database-configuration6> توضیح می‌دهند که چه زمانی چنین پیکربندی‌ای ممکن است لازم باشد و چگونه Kea را برای کار به این شیوه برای هر دو پروتکل DHCPv4 و DHCPv6 پیکربندی کنید. .SS محدودیت‌های مربوط به استفاده از پایگاه‌های داده SQL .SS مسئله سال ۲۰۳۸ .sp زمان انقضای اجاره (lease) در Kea برای هر اجاره به عنوان یک مقدار برچسب زمان (timestamp) در پایگاه داده SQL ذخیره می‌شود. توسعه‌دهندگان Kea مشاهده کرده‌اند که پایگاه داده MySQL برچسب‌های زمانی فراتر از 2147483647 ثانیه (بیشینه عدد علامت‌دار ۳۲ بیتی) از ابتدای مبدأ یونیکس (00:00:00 در ۱ ژانویه ۱۹۷۰) را نمی‌پذیرد. برخی از نسخه‌های PostgreSQL مقادیر بزرگ‌تر را می‌پذیرند، اما مقدار هنگام بازخوانی دستخوش تغییر می‌شود. به همین دلیل، بخش‌های پشتیبان (backends) پایگاه داده اجاره، محدودیتی را بر روی بیشینه برچسب زمانی قابل ذخیره در پایگاه داده اعمال می‌کنند که برابر با بیشینه عدد علامت‌دار ۳۲ بیتی است. این امر عملاً به این معنی است که نسخه فعلی Kea نمی‌تواند اجاره‌هایی را ذخیره کند که زمان انقضای آن‌ها دیرتر از 2147483647 ثانیه از آغاز مبدأ زمانی (حدود سال ۲۰۳۸) باشد. این مورد هنگامی که پشتیبانی پایگاه داده از برچسب‌های زمانی طولانی‌تر فراهم شود، برطرف خواهد شد. .SH "امنیت KEA (KEA SECURITY)" .sp نرم‌افزار Kea در ابتدا برای نصب در یک محیط محافظت‌شده، در یک مرکز داده شبکه طراحی شده بود؛ این نرم‌افزار امکانات امنیتی سخت‌گیرانه‌ای ارائه نمی‌داد. با این حال، به دلیل تقاضای کاربران و نیازمندی‌های رو به تحول شبکه، پشتیبانی از احراز هویت پایه‌ای HTTP و پروتکل امنیت لایه انتقال (TLS) به Kea اضافه شده است. .SS پشتیبانی از TLS/HTTPS .sp از نسخه Kea 1.9.6، می‌توان از TLS برای امن‌سازی ارتباطات HTTP استفاده کرد. سه سطح حفاظتی ممکن وجود دارد: .INDENT 0.0 .IP \(bu 2 بدون TLS. اتصال به صورت متن ساده (plain\-text) و HTTP رمزگذاری‌نشده است. (این تنها گزینه موجود در نسخه‌های پیش از Kea 1.9.6 است.) .IP \(bu 2 رمزنگاری، که در برابر حملات غیرفعال (passive) و شنود محافظت می‌کند. در این حالت، هویت کارگزار احراز می‌شود اما کلاینت احراز هویت نمی‌شود. این حالت معمول هنگام امن‌سازی یک وب‌سایت است، جایی که کلاینت‌ها و کارگزارها تحت کنترل یک نهاد مشترک نیستند. .IP \(bu 2 احراز هویت متقابل (دوطرفه) بین کلاینت و کارگزار. این سخت‌گیرانه‌ترین حالت امنیتی است و هنگامی که TLS فعال باشد، حالت پیش‌فرض است. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 احراز هویت متقابل TLS صرفاً مختص موجودیت‌های TLS است. هنگامی که TLS و یک طرح احراز هویت HTTP همراه با یکدیگر استفاده می‌شوند، هیچ پیوندی بین این دو سازوکار امنیتی وجود ندارد، و بنابراین هیچ اثباتی مبنی بر اینکه کلاینت و کارگزار TLS همان کلاینت و کارگزار احراز هویت HTTP هستند وجود ندارد. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 توصیه می‌شود برای مقابله با حملات محلی (توسط کاربرانی که به سیستمی که کارگزارها/عامل‌های Kea روی آن اجرا می‌شوند متصل هستند)، از پورت‌های دارای دسترسی ویژه (privileged ports) برای HTTP/HTTPS استفاده شود. این اقدام همچنین از جعل هویت در HTTP و به‌طور کلی از حملات منع خدمت (Denial of Service) جلوگیری می‌کند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کارگزار هنگام تغییر نوع سوکت از HTTP به HTTPS یا از HTTPS به HTTP با استفاده از آدرس و پورت یکسان، خطا صادر خواهد کرد. این عمل مجاز نیست چرا که ممکن است به دلیل اشتباه سهوی کاربر، یک رخنه امنیتی ایجاد کند. هنگام استفاده از دستور \(dqconfig\-set\(dq برای جابه‌جایی از HTTP به HTTPS یا از HTTPS به HTTP، باید یک آدرس یا پورت متفاوت مشخص شود. همین موضوع هنگام ویرایش فایل پیکربندی و سپس اجرای دستور \(dqconfig\-reload\(dq نیز صدق می‌کند. .UNINDENT .UNINDENT .SS ساخت Kea با پشتیبانی از TLS/HTTPS .sp پشتیبانی از TLS/HTTPS با هر دو کتابخانه رمزنگاری OpenSSL یا Botan در دسترس است. محدودیت‌هایی بر روی کتابخانه Boost وجود دارد که باید رعایت شوند: .INDENT 0.0 .IP \(bu 2 نسخه‌های OpenSSL قدیمی‌تر از 1.0.2 منسوخ شده‌اند و نباید استفاده شوند. پشتیبانی Kea از TLS با این نسخه‌ها آزمایش نشده و پشتیبانی نمی‌شود. .IP \(bu 2 نسخه OpenSSL 1.0.2 دارای پشتیبانی تمدیدشده است، اما فقط برای مشتریان ویژه OpenSSL. پشتیبانی TLS در Kea با این نسخه آزمایش شده اما پشتیبانی نمی‌شود. .IP \(bu 2 نسخه‌های OpenSSL 1.1.x و جدیدتر آزمایش شده‌اند و پشتیبانی می‌شوند. بسیاری از نسخه‌های اخیر سیستم‌عامل‌ها شامل پشتیبانی از TLS 1.3 هستند. .IP \(bu 2 نسخه OpenSSL 3.x منتشر شده است و Kea با آن کامپایل و ساخته می‌شود. .IP \(bu 2 نسخه LibreSSL 3.2.4 آزمایش شده است. LibreSSL دارای رابط برنامه‌نویسی (API) مشترک با OpenSSL 1.0.2 است، بنابراین باید کار کند، اما پشتیبانی نمی‌شود. .IP \(bu 2 نسخه‌های Botan 1.x و 2.x منسوخ شده‌اند و نباید استفاده شوند. .IP \(bu 2 نسخه‌های Botan 3.4.0 و جدیدتر آزمایش شده‌اند و پشتیبانی می‌شوند. پشتیبانی Kea از TLS نیازمند چهار فایل سرآیند Asio است که در بسته‌های Botan گنجانده شده‌اند و تنها در صورتی نصب می‌شوند که Botan با گزینه \fB\-\-with\-boost\fP پیکربندی شده باشد. .sp بسیاری از بسته‌های ارائه‌شده توسط سیستم‌عامل‌ها، مانند Ubuntu 20.10، کتابخانه Botan را با پشتیبانی Boost نمی‌سازند، که باعث می‌شود این بسته‌ها برای Kea همراه با TLS غیرقابل استفاده باشند. .sp همچنان امکان دریافت این فایل‌ها از توزیع متناظر Botan و نصب دستی آن‌ها در پوشه include مربوط به Botan وجود دارد، اما این کار باید به عنوان آخرین راهکار در نظر گرفته شود. .sp بدون این فایل‌های سرآیند، یا با نسخه‌ای از Botan قدیمی‌تر از 3.4.0، برنامه Kea ساخته نمی‌شود زیرا پشتیبانی TLS/HTTPS برای امنیت، ضروری در نظر گرفته می‌شود. .IP \(bu 2 نسخه‌های بسیار قدیمی Boost پشتیبانی از SSL را (بر پایه OpenSSL) بدون ارائه امکان انتخاب نسخه TLS فراهم می‌کنند؛ Kea همچنان می‌تواند از آن‌ها استفاده کند، اما توصیه نمی‌شوند. .IP \(bu 2 نسخه‌های Boost پیش از 1.64 پشتیبانی از SSL را با یک نسخه ثابت TLS ارائه می‌دهند؛ Kea در این نسخه‌ها استفاده از TLS 1.2 را اجباری می‌کند. .IP \(bu 2 نسخه‌های Boost 1.64 یا جدیدتر، پشتیبانی از SSL را با نسخه عمومی TLS ارائه می‌دهند؛ بهترین (بالاترین) نسخه موجود در هر دو طرف ارتباط انتخاب می‌شود. .UNINDENT.SS پیکربندی TLS/HTTPS .sp پارامترهای پیکربندی TLS عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBtrust\-anchor\fP \- این پارامتر رشته‌ای، نام یک فایل یا دایرکتوری را مشخص می‌کند که گواهی مرجع صدور گواهی (CA) طرف مقابل در آن یافت می‌شود. در OpenSSL، دایرکتوری باید شامل پیوندهای نمادین هش (hash symbolic links) باشد. در Botan، دایرکتوری به‌صورت بازگشتی برای یافتن گواهی‌ها جستجو می‌شود. .IP \(bu 2 \fBcert\-file\fP \- این پارامتر رشته‌ای، نام فایلی را مشخص می‌کند که حاوی گواهی نهاد نهایی (end\-entity) نمونه‌ی Kea در حال پیکربندی است. .IP \(bu 2 \fBkey\-file\fP \- این پارامتر رشته‌ای، کلید خصوصی گواهی نهاد نهایی نمونه‌ی Kea در حال پیکربندی را مشخص می‌کند. این فایل نباید رمزگذاری شده باشد؛ اکیداً توصیه می‌شود دسترسی به آن محدود گردد. .UNINDENT .sp این سه پارامتر رشته‌ای باید یا همگی نامشخص باشند (TLS غیرفعال) یا همگی مشخص شوند (TLS فعال). .sp پروتکل TLS نامتقارن است: احراز هویت سرور توسط کلاینت اجباری است، اما احراز هویت کلاینت توسط سرور اختیاری می‌باشد. از نظر اصطلاحات TLS، این بدان معناست که سرور ممکن است گواهی کلاینت را الزامی بداند یا نداند؛ یک پارامتر TLS مخصوص سرور برای این منظور وجود دارد. .INDENT 0.0 .IP \(bu 2 \fBcert\-required\fP \- این پارامتر بولی (boolean) به سرور اجازه می‌دهد که گواهی کلاینت را الزامی نداند. مقدار پیش‌فرض آن \fBtrue\fP است، به این معنی که گواهی کلاینت الزامی است و کلاینت باید احراز هویت شود. این پرچم در سمت کلاینت هیچ مفهومی ندارد؛ سرور همواره گواهی‌ای ارائه می‌دهد که توسط کلاینت اعتبارسنجی می‌شود. .UNINDENT .sp اشیاء درون فایل‌ها باید در قالب PEM باشند. فایل‌ها می‌توانند حاوی بیش از یک گواهی باشند، اما این مورد آزمایش نشده و پشتیبانی نمی‌شود. .sp کتابخانه Botan الزام می‌کند که گواهی‌های CA دارای ویژگی‌های استاندارد گواهی CA باشند، بررسی می‌کند که گواهی‌های نهاد نهایی حتماً نسخه ۳ باشند (همان‌طور که استاندارد TLS الزامی کرده است)، و برای کلید خصوصی فقط از فایل‌های PKCS 8 پشتیبانی می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برخی از کتابخانه‌های رمزنگاری (مانند Botan و نگارش‌های اخیر OpenSSL) حداقل استحکام (یعنی طول کلید) را اعمال می‌کنند، به عنوان مثال حداقل ۲۰۴۸ برای RSA. .UNINDENT .UNINDENT .sp مجموعه‌ای نمونه از گواهی‌ها و اشیاء وابسته در مسیر \fBsrc/lib/asiolink/testutils/ca\fP در سورس‌های Kea به همراه فایل \fBdoc.txt\fP که نحوه تولید آن‌ها با استفاده از دستور \fBopenssl\fP را توضیح می‌دهد، موجود است. این فایل‌ها صرفاً برای اهداف آزمایشی هستند. \fBاز آن‌ها در محیط عملیاتی استفاده نکنید.\fP .sp دست‌تکانی TLS (یا TLS handshake)، مرحله‌ای که در آن پارامترهای رمزنگاری تبادل شده و احراز هویت اعتبارسنجی می‌شود، می‌تواند به روش‌های گوناگونی با شکست مواجه شود. پیام‌های خطا اغلب برای شناسایی دقیق منبع مشکل کمکی نمی‌کنند. هر دو ابزار OpenSSL و Botan یک ابزار خط فرمانی به همراه دستور \fBverify\fP ارائه می‌دهند که می‌توان از آن برای درک و رفع مشکلات دست‌تکانی استفاده کرد. .SS تنظیم دقیق OpenSSL .sp نرم‌افزار Kea پارامترهای پیش‌فرض پیکربندی OpenSSL را می‌پذیرد، اما مدیران سیستم همچنین می‌توانند تنظیمات OpenSSL را به‌دقت تنظیم کنند. به عنوان مثال، ممکن است محدود کردن نسخه TLS مطلوب باشد. .sp فایل پیکربندی پیش‌فرض OpenSSL با نام \fBopenssl.cnf\fP\& شناخته می‌شود. این فایل در یک دایرکتوری \fBetc\fP وابسته به سیستم قرار دارد و مکان آن را می‌توان با استفاده از متغیر محیطی \fBOPENSSL_CONF\fP بازنویسی کرد. برای نگارش‌های OpenSSL بالاتر از 1.0.2، حداقل پروتکل قابل قبول را می‌توان از طریق متغیر \fBMinProtocol\fP تعیین کرد. .sp برای این مثال‌ها فرض می‌کنیم که هیچ متغیری از قبل تنظیم نشده و هیچ بخشی از قبل وجود ندارد؛ البته امکان استفاده مجدد از متغیرها و بخش‌های موجود نیز وجود دارد. .sp در برنامه کاربردی پیش‌فرض، یعنی \fBopenssl_conf\fP، متغیر مربوطه باید روی نام بخشی تنظیم شود که مقادیر پیش‌فرض را مدیریت می‌کند: در این مثال، \fBdefault_conf\fP\&. اگر \fBopenssl_conf\fP هنوز تنظیم نشده است، این خط را در ابتدای فایل پیکربندی OpenSSL (پیش از بخش نخست) اضافه کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX openssl_conf = default_conf .EE .UNINDENT .UNINDENT .sp در بخش \fBdefault_conf\fP، متغیر \fBssl_conf\fP باید روی نام بخشی تنظیم شود که پیش‌فرض‌های SSL/TLS را مدیریت می‌کند: در این مثال، \fBssl_sect\fP\&. .INDENT 0.0 .INDENT 3.5 .sp .EX [ default_conf ] ssl_conf = ssl_sect .EE .UNINDENT .UNINDENT .sp در بخش \fBssl_sect\fP، متغیر \fBsystem_default\fP باید روی نام بخشی تنظیم شود که پیش‌فرض‌های سیستم را مدیریت می‌کند: در این مثال، \fBsystem_default_sect\fP\&. .INDENT 0.0 .INDENT 3.5 .sp .EX [ ssl_sect ] system_default = system_default_sect .EE .UNINDENT .UNINDENT .sp در بخش \fBsystem_default_sect\fP، متغیر \fBMinProtocol\fP باید روی حداقل نگارش مطلوب SSL/TLS تنظیم شود: در این مثال، \fBTLSv1.2\fP\&. .INDENT 0.0 .INDENT 3.5 .sp .EX [ system_default_sect ] MinProtocol = TLSv1.2 .EE .UNINDENT .UNINDENT .sp در صورت تمایل، می‌توان از همین مراحل برای اعمال سایر پارامترهای رمزنگاری نیز استفاده کرد. .sp اکیداً توصیه می‌شود صفحه راهنمای \fBopenssl.cnf\fP مطالعه شود، که معمولاً \fBconfig.5ssl\fP نامیده شده و با دستور \fBman config\fP\& نمایش داده می‌شود..SS کانال کنترلی امن Kea .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این بخش مربوط به Kea Control Agent بود که اکنون منسوخ (حذف) شده است، اما برای سوکت‌های کنترلی HTTPS پشتیبانی‌شده توسط کارگزارهای Kea نیز صدق می‌کند. .UNINDENT .UNINDENT .sp سوکت‌های کنترلی کارگزارهای Kea به‌طور ذاتی از اتصال‌های امن HTTP با استفاده از TLS پشتیبانی می‌کنند. این امر امکان محافظت در برابر کاربرانی از گره محل اجرای عامل را فراهم می‌سازد؛ چیزی که یک پروکسی معکوس (reverse proxy) قادر به ارائهٔ آن نیست. اطلاعات بیشتر دربارهٔ پشتیبانی از TLS/HTTPS در Kea را می‌توان در TLS/HTTPS Support یافت\&. .sp پیکربندی TLS با استفاده از سه پارامتر رشته‌ای حاوی نام فایل‌ها و یک پارامتر بولی (boolean) انجام می‌شود: .INDENT 0.0 .IP \(bu 2 پارامتر \fBtrust\-anchor\fP نام فایل یا مسیر دایرکتوری مرجع صدور گواهی (Certification Authority) را مشخص می‌کند. .IP \(bu 2 پارامتر \fBcert\-file\fP نام فایل گواهی کارگزار را مشخص می‌کند. .IP \(bu 2 پارامتر \fBkey\-file\fP نام فایل کلید خصوصی را مشخص می‌کند. این فایل نباید رمزنگاری شده باشد. .IP \(bu 2 پارامتر \fBcert\-required\fP مشخص می‌کند که آیا گواهی‌های کلاینت الزامی هستند یا اختیاری. پیش‌فرض بر الزامی بودن آن‌ها و انجام احراز هویت متقابل (mutual authentication) است. .UNINDENT .sp قالب فایل PEM است. یا باید تمام پارامترهای رشته‌ای مشخص شوند و HTTP روی TLS (همان HTTPS) استفاده گردد، یا هیچ‌کدام مشخص نشوند و HTTP معمولی به کار رود. پیکربندی تنها یک یا دو پارامتر رشته‌ای منجر به خطا خواهد شد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگامی که گواهی‌های کلاینت الزامی نباشند، تنها سمت کارگزار احراز هویت می‌شود، یعنی ارتباط با یک کلاینت ناشناس رمزنگاری می‌گردد. این حالت تنها در برابر حملات غیرفعال (passive) محافظت می‌کند؛ حملات فعال مانند \(dqمرد میانی\(dq (man\-in\-the\-middle) همچنان امکان‌پذیر خواهند بود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هیچ طرح احراز هویت استاندارد HTTP موجودیت پایانی (end entity) خود را به‌صورت رمزنگاری‌شده به TLS مقید نمی‌کند. این بدان معناست که کلاینت و کارگزار TLS می‌توانند احراز هویت متقابل شوند، اما هیچ اثباتی وجود ندارد که آن‌ها همان هویت‌های احراز هویت HTTP باشند. .UNINDENT .UNINDENT .sp ابزار \fBkea\-shell\fP \%<#\:std-iscman-kea-shell> نیز از TLS پشتیبانی می‌کند. .SS ایمن‌سازی استقرار Kea .sp در ادامه فهرستی از ملاحظات برای مدیران سیستمی که مایل به ارتقای امنیت Kea هستند آورده شده است. در بسیاری از موارد، بین راحتی و امنیت مصالحه‌هایی وجود دارد. .SS طراحی مبتنی بر مؤلفه .sp معماری Kea ماژولار است و از دیمن‌های مجزا برای وظایف مختلف بهره می‌برد. یک استقرار Kea ممکن است شامل دیمن‌های DHCPv4، DHCPv6 و Dynamic DNS باشد؛ ابزار کمکی \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> برای پاک‌سازی دوره‌ای فایل‌های اجاره (lease)؛ پایگاه‌های دادهٔ MySQL و یا PostgreSQL که یا به‌صورت محلی روی کارگزارهای برنامه اجرا می‌شوند یا از طریق شبکهٔ داخلی در دسترس هستند؛ یک دیمن Netconf برای انجام نظارت بر پیکربندی و آمار کارگزارهای Kea؛ و یک سامانهٔ مانیتورینگ Stork. این معماری ماژولار به مدیر سیستم اجازه می‌دهد تا با به حداقل رساندن کدهای بارگذاری و اجرا شده، سطح حمله (attack surface) را به کمترین میزان برساند. به‌عنوان مثال، \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> نباید اجرا شود مگر اینکه به‌روزرسانی‌های DNS مورد نیاز باشد. به همین ترتیب، اگر memfile استفاده نشود، \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> هرگز فراخوانی نمی‌شود (و می‌توان آن را با خیال راحت حذف کرد یا هرگز نصب ننمود). مشکلات امنیتی بالقوهٔ Kea را می‌توان با اجرای تنها آن فرایندهایی که در محیط محلی مورد نیاز هستند به حداقل رساند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 2.7.9 به بعد، \fBdata\-directory\fP (فقط در DHCPv6) منسوخ شده است. فایل‌های اجاره (DHCPv4 و DHCPv6) و فایل duid (فقط در DHCPv6) تنها می‌توانند از دایرکتوری تعیین‌شده در حین کامپایل بارگذاری شوند: \fB\(dq[kea\-install\-dir]/var/lib/kea\(dq\fP\&. این مسیر می‌تواند در هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_DHCP_DATA_DIR\fP به مسیر دلخواه بازنویسی شود. اگر مسیری غیر از این مقدار در \fBname\fP یا \fBdata\-directory\fP استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی خودداری می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت می‌کند. این محدودیت برای نوشتن فایل اجاره با استفاده از دستورهای \fBlease4\-write\fP و \fBlease6\-write\fP نیز اعمال می‌شود. اگر مسیری غیر از این مقدار در \fBfilename\fP استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی خودداری می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت خواهد کرد. برای سهولت در تعیین یک نام فایل سفارشی، کافی است بخش مسیر را از \fBfilename\fP حذف کنید\&. همین محدودیت همچنین برای نوشتن فایل حافظهٔ پنهان (cache) با استفاده از دستور \fBcache\-write\fP اعمال می‌شود. برای سهولت در تعیین یک نام فایل سفارشی، کافی است بخش مسیر را از \fBfilename\fP حذف کنید\&. متغیر محیطی \fBKEA_DHCP_DATA_DIR\fP همچنین برای تغییر مکان پیش‌فرض فایل شناسه کارگزار تولیدشدهٔ DHCPv6 (kea\-dhcp6\-serverid) استفاده می‌شود. .UNINDENT .UNINDENT .SS محدود کردن مجوزهای برنامه کاربردی .sp پروتکل‌های DHCPv4 و DHCPv6 فرض می‌کنند که کارگزار پورت دارای امتیاز UDP 67 (در DHCPv4) یا 547 (در DHCPv6) را باز می‌کند که در شرایط عادی به دسترسی ریشه (root) نیاز دارد. با این حال، از طریق سازوکار قابلیت‌ها (capabilities) در سیستم‌های لینوکس، Kea می‌تواند از یک حساب کاربری بدون امتیاز اجرا شود. برای جزئیات در مورد نحوهٔ اجرای Kea بدون دسترسی ریشه، «Running Kea From a Non\-root Account on Linux» \%<#\:non-root> را ببینید. .SS ایمن‌سازی دسترسی مدیریتی Kea .sp هر سه دیمن اصلی Kea (\fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> و \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>) همگی از یک کانال کنترلی که به‌صورت سوکت UNIX پیاده‌سازی شده است پشتیبانی می‌کنند. این کانال کنترلی که یک سوکت UNIX باز می‌کند، به‌طور پیش‌فرض غیرفعال است؛ با این حال، نمونه‌های پیکربندی متعددی آن را فعال کرده‌اند، زیرا ویژگی بسیار محبوبی است. برای خواندن از این سوکت یا نوشتن در آن، عموماً به دسترسی ریشه (root) نیاز است، هرچند اگر Kea برای اجرا به عنوان کاربر غیرریشه (non\-root) پیکربندی شده باشد، مالک فرایند می‌تواند در آن بنویسد. دسترسی را می‌توان با استفاده از کنترل دسترسی معمول به فایل در سیستم‌های POSIX (مالک، گروه، سایرین، خواندن/نوشتن) کنترل کرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 2.7.9 به بعد، سوکت‌های کنترلی تنها می‌توانند در دایرکتوری تعیین‌شده در حین کامپایل یعنی \fB\(dq[kea\-install\-dir]/var/run/kea\(dq\fP قرار گیرند که همچنین باید دارای مجوزهای دسترسی \fB0750\fP باشد. این مسیر می‌تواند در هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_CONTROL_SOCKET_DIR\fP به مسیر دلخواه بازنویسی شود. اگر مسیری غیر از این مقدار در \fBsocket\-name\fP استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی امتناع می‌ورزد یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت می‌کند. برای سهولت در استفاده، کافی است مؤلفهٔ مسیر را از \fBsocket\-name\fP حذف کنید\&. .UNINDENT .UNINDENT .sp از نسخهٔ Kea 2.7.2 به بعد، کارگزارهای DHCP از کانال‌های کنترلی HTTP/HTTPS پشتیبانی می‌کنند و از نسخهٔ Kea 3.1.8 عامل کنترلی (Control Agent) حذف شده است. .sp از نسخهٔ Kea\-2.7.6 به بعد، Kea از چندین اتصال HTTP/HTTPS پشتیبانی می‌کند. هر دو نشانی IPv4 و IPv6 قابل استفاده هستند. با پیکربندی اتصال‌های HTTPS برای تمام دیمن‌ها، می‌توان امنیت را ارتقا داد. .sp پیکربندی Kea توسط یک فایل JSON بر روی کارگزار Kea کنترل می‌شود. این فایل می‌تواند توسط هر کاربری با مجوزهای فایل مربوطه (که توسط سیستم‌عامل کنترل می‌شود) مشاهده یا ویرایش گردد. توجه داشته باشید که گذرواژه‌ها به‌صورت متن ساده (clear text) در فایل پیکربندی ذخیره می‌شوند، بنابراین هر کسی با دسترسی خواندن فایل پیکربندی می‌تواند این اطلاعات را بیابد. از منظر عملی، هر کسی با مجوز ویرایش فایل پیکربندی، کنترل Kea را در دست دارد. محدود کردن مجوزهای کاربر برای خواندن یا نوشتن فایل پیکربندی Kea، یک اقدام امنیتی مهم است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 2.7.9 به بعد، فایل پیکربندی (با استفاده از دستور \fBconfig\-write\fP) تنها می‌تواند در همان دایرکتوری‌ای نوشته شود که فایل پیکربندی استفاده‌شده هنگام راه‌اندازی Kea (ارائه‌شده به عنوان آرگومان \fB\-c\fP) در آن قرار دارد. .UNINDENT .UNINDENT.SS ایمن‌سازی اتصال‌های پایگاه داده .sp Kea می‌تواند از یک پایگاه داده خارجی MySQL یا PostgreSQL برای ذخیره‌سازی پیکربندی، رزروهای میزبان، و/یا اجاره‌ها (leases)، و/یا برای لاگ‌گیری قانونی (forensic logging) استفاده کند. استفاده از پایگاه‌های داده یک ویژگی محبوب است، اما اختیاری است؛ همچنین ذخیره داده‌ها در یک فایل ساده (flat file) روی دیسک نیز امکان‌پذیر است. .sp هنگام استفاده از پایگاه داده، Kea مشخصات اعتبارسنجی زیر را برای احراز هویت در پایگاه داده ذخیره کرده و به کار می‌برد: نام کاربری، گذرواژه، میزبان، درگاه (port) و نام پایگاه داده. \fBاین مقادیر به صورت متن آشکار (clear text) در فایل پیکربندی ذخیره می‌شوند.\fP .sp بسته به پیکربندی پایگاه داده، بررسی تطابق کاربر سیستم با نام کاربری پایگاه داده نیز امکان‌پذیر است. برای جزئیات بیشتر به راهنمای MySQL یا PostgreSQL مراجعه کنید. .sp Kea از تنظیمات کلاینت SSL/TLS برای پایگاه داده MySQL و PostgreSQL پشتیبانی می‌کند و باید به‌طور صریح برای تمام اتصال‌های مورد استفاده (پیکربندی، رزروها، اجاره‌ها، لاگ‌گیری قانونی) پیکربندی شود. برای جزئیات بخش اتصال پایگاه داده (Database Connectivity \%<#\:database-connectivity>) را ببینید. .SS نشت اطلاعات از طریق لاگ‌گیری .sp امکان دارد که Kea کل یک فایل پیکربندی، از جمله گذرواژه‌ها و داده‌های محرمانه را لاگ کند. از نسخه 1.9.7 در Kea، این مشکل با جایگزینی مقدار تمام ورودی‌هایی که به \fBpassword\fP یا \fBsecret\fP ختم می‌شوند با علامت ستاره برطرف شده است، همان‌طور که پیش‌تر برای لاگ‌های پایگاه داده انجام می‌شد. .sp لاگ‌ها به stdout، stderr، فایل‌ها یا syslog ارسال می‌شوند؛ مجوزهای فایل‌های سیستم برای stdout/stderr و فایل‌ها اعمال می‌گردد. syslog ممکن است لاگ‌ها را روی شبکه ارسال کند که این امر آن‌ها را بیشتر در معرض شنود احتمالی قرار می‌دهد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 2.7.9 در Kea، فایل‌های لاگ فقط می‌توانند در دایرکتوری خروجی تعیین‌شده در زمان کامپایل نوشته شوند: \fB\(dq[kea\-install\-dir]/var/log/kea\(dq\fP\&. این مسیر می‌تواند هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_LOG_FILE_DIR\fP به مسیر دلخواه جایگزین (override) شود. اگر مسیری غیر از این مقدار در \fBoutput\fP استفاده شود، Kea خطا داده و از اجرا خودداری می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی ثبت خواهد کرد. برای سهولت در استفاده، بخش مسیر را از \fBoutput\fP حذف کرده و تنها نام فایل را مشخص کنید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 2.7.9 در Kea، فایل‌های لاگ قانونی (legal log) فقط می‌توانند در دایرکتوری خروجی تعیین‌شده در زمان کامپایل نوشته شوند: \fB\(dq[kea\-install\-dir]/var/log/kea\(dq\fP\&. این مسیر می‌تواند هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_LEGAL_LOG_DIR\fP به مسیر دلخواه جایگزین شود. اگر مسیری غیر از این مقدار در \fBpath\fP استفاده شود، Kea خطا داده و از راه‌اندازی امتناع می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی ثبت خواهد کرد. برای سهولت در استفاده، کافی است پارامتر \fBpath\fP را حذف کنید. .UNINDENT .UNINDENT .SS خلاصه‌ای از محدودیت‌های مسیر .sp محدودیت‌های مسیر ذکرشده در این بخش را می‌توان طبق جدول زیر خلاصه کرد: .TS box center; l|l|l. T{ عنصر محدودشده T} T{ مقدار پیش‌فرض T} T{ بازنویسی با متغیر محیطی T} _ T{ فایل‌های پیکربندی (\fBconfig\-write\fP) T} T{ دایرکتوری یکسان با فایل پیکربندی اولیه T} T{ N/A T} _ T{ فایل‌های حافظه موقت میزبان (\fBcache\-write\fP) T} T{ \fBvar/lib/kea\fP T} T{ \fBKEA_DHCP_DATA_DIR\fP T} _ T{ فایل‌های اجاره (Lease) T} T{ \fBvar/lib/kea\fP T} T{ \fBKEA_DHCP_DATA_DIR\fP T} _ T{ فایل شناسه کارگزار DHCPv6 T} T{ \fBvar/lib/kea\fP T} T{ \fBKEA_DHCP_DATA_DIR\fP T} _ T{ فایل‌های لاگ T} T{ \fBvar/log/kea\fP T} T{ \fBKEA_LOG_FILE_DIR\fP T} _ T{ فایل‌های لاگ قانونی (Forensic) T} T{ \fBvar/log/kea\fP T} T{ \fBKEA_LEGAL_LOG_DIR\fP T} _ T{ سوکت‌های یونیکس (Unix Sockets) T} T{ \fBvar/run/kea\fP T} T{ \fBKEA_CONTROL_SOCKET_DIR\fP T} _ T{ اسکریپت‌های مورد استفاده کتابخانه‌های Hook T} T{ \fBshare/kea/scripts/\fP T} T{ \fBKEA_HOOK_SCRIPTS_PATH\fP T} .TE.SS مؤلفه‌های رمزنگاری .sp Kea از هر یک از دو کتابخانه رمزنگاری زیر پشتیبانی می‌کند: Botan یا OpenSSL. این انتخاب در زمان کامپایل انجام می‌شود و وابستگی‌های زمان کامپایل و زمان اجرا را میان Kea و کتابخانه انتخاب‌شده ایجاد می‌کند. با وجود اینکه OpenSSL محبوب‌ترین انتخاب برای محیط‌های عملیاتی است، Botan نیز یک جایگزین کاملاً پشتیبانی‌شده باقی می‌ماند. .sp موارد کاربرد اصلی کتابخانه‌های رمزنگاری عبارتند از: .INDENT 0.0 .IP \(bu 2 پشتیبانی از TLS برای کانال‌های کنترلی HTTPS، معرفی‌شده در Kea 1.9.6. .IP \(bu 2 امضاهای TSIG هنگام ارسال به‌روزرسانی‌های DNS. .IP \(bu 2 محاسبه رکوردهای DHCID هنگام ارسال به‌روزرسانی‌های DNS. .IP \(bu 2 تولید اعداد تصادفی (اما نه برای مواردی که به تولیدکننده در سطح رمزنگاری پیشرفته نیاز دارند). .UNINDENT .sp برای OpenSSL و Botan، تنها از رابط رمزنگاری سطح پایین استفاده می‌شود (مانند libcrypto). برنامه Kea با libssl پیوند (link) برقرار نمی‌کند. برخی از سامانه‌های نرم‌افزاری وابسته، مانند کتابخانه‌های کلاینت پایگاه داده، نیز می‌توانند به یک کتابخانه رمزنگاری وابسته باشند. .sp یک راه برای محدود کردن خطرات ناشی از آسیب‌پذیری‌های بالقوه OpenSSL یا Botan، عدم استفاده از DDNS است. کتابخانه‌ها همچنان برای ساخت و اجرای Kea مورد نیاز خواهند بود، اما کدهای آن‌ها هرگز اجرا نخواهد شد، بنابراین هرگونه باگ بالقوه در کتابخانه‌ها قابل بهره‌برداری نخواهد بود. .SS امضاهای TSIG .sp برنامه Kea هنگام امضای به‌روزرسانی‌های DNS با امضاهای TSIG، از الگوریتم‌های زیر پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 HMAC\-MD5 .IP \(bu 2 HMAC\-SHA1 .IP \(bu 2 HMAC\-SHA224 .IP \(bu 2 HMAC\-SHA256 .IP \(bu 2 HMAC\-SHA384 .IP \(bu 2 HMAC\-SHA512 .UNINDENT .sp برای دیدن فهرست به‌روز، فهرست کلیدهای TSIG را در \%<#\:d2-tsig-key-list-config> ببینید. .sp برنامه Kea برای محاسبه رکوردهای DHCID از SHA256 استفاده می‌کند. این موضوع از دیدگاه رمزنگاری حائز اهمیت نیست، زیرا رکورد DHCID صرفاً برای ایجاد شناسه‌های منحصربه‌فرد برای دو دستگاهی به کار می‌رود که ممکن است در زمان‌های مختلف یک آدرس IP یکسان به آن‌ها اختصاص یافته باشد. .SS پشتیبانی از سوکت خام (Raw Socket) .sp به طور کلی، Kea DHCPv4 از سوکت‌های خام (raw sockets) برای دریافت ترافیک از کلاینت‌ها استفاده می‌کند. چالش اصلی، دریافت بسته‌ها از دستگاه‌هایی است که هنوز هیچ آدرس IPv4 ندارند. هنگام مدیریت ترافیک مستقیم (حالتی که کلاینت و سرور هر دو به یک پیوند متصل هستند و رله‌ها آن‌ها را جدا نکرده‌اند)، کرنل به طور پیش‌فرض بسته را دور می‌اندازد زیرا آدرس IP مبدأ 0.0.0.0 است. بنابراین، Kea باید سوکت‌های خام را باز کند تا بتواند این ترافیک را دریافت کند. .sp با این حال، اگر تمام ترافیک از طریق رله‌ها عبور کند (که در بسیاری از شبکه‌ها رایج است)، این کار ضرورتی ندارد. در این حالت می‌توان به‌جای آن از سوکت‌های استاندارد UDP استفاده کرد. پارامتری به نام \fBdhcp\-socket\-type\fP وجود دارد که این رفتار را کنترل می‌کند. .sp حالت پیش‌فرض، مجاز دانستن استفاده از سوکت خام است، چرا که انعطاف‌پذیری بیشتری دارد. .sp هنگام استفاده از سوکت‌های خام، Kea می‌تواند بسته‌های خام لایه ۲ را دریافت کرده و اکثر فایروال‌ها (شامل iptables) را دور بزند. این عملاً بدین معناست که هنگام استفاده از سوکت‌های خام، نمی‌توان از iptables برای مسدود کردن ترافیک DHCP استفاده کرد. این ویژگی، از تصمیمات طراحی در کرنل لینوکس است. .sp می‌توان Kea را طوری تنظیم کرد که از سوکت‌های UDP استفاده کند. این گزینه زمانی کاربرد دارد که تمام ترافیک رله شود. با این حال، برای دستگاه‌هایی که مستقیماً متصل هستند کارایی ندارد. اگر Kea به سوکت‌های UDP محدود شود، iptables باید به درستی عمل کند. .sp در صورتی که نیازی به سوکت‌های خام نباشد، غیرفعال کردن این دسترسی می‌تواند امنیت را افزایش دهد. .SS دسترسی مدیریتی از راه دور .sp سرورهای DHCP و DDNS یک RESTful API را روی HTTP یا HTTPS (یعنی HTTP بر بستر TLS) ارائه می‌دهند. این کانال‌های کنترلی ویژگی‌های اختیاری هستند که به صورت پیش‌فرض غیرفعال‌اند، اما کاربرد فراوانی دارند. در صورت فعال‌سازی، به صورت پیش‌فرض روی آدرس loopback (یعنی 127.0.0.1 یا ::1) شنود می‌کنند، مگر اینکه طور دیگری پیکربندی شده باشند. برای کسب اطلاعات بیشتر در مورد حفاظت از ترافیک TLS، بخش پشتیبانی از TLS/HTTPS را ببینید. محدود کردن اتصالات ورودی با یک فایروال، مانند iptables، اکیداً توصیه می‌شود. .sp توجه داشته باشید که در استقرارهای دارای دسترسی‌پذیری بالا (HA)، می‌توان یک شنونده اختصاصی چندنخی (multi\-threaded) را برای ارائه پروتکل HA از طریق RESTful API با گره‌های همتا (peers) پیکربندی کرد. .sp برنامه Kea همچنین از چندین اتصال HTTP/HTTPS پشتیبانی می‌کند. هر دو آدرس IPv4 و IPv6 قابل استفاده هستند. با پیکربندی اتصالات HTTPS برای تمامی دیمن‌ها، می‌توان امنیت را ارتقا داد. .SS احراز هویت برای RESTful API در Kea .sp در Kea 1.9.0 پشتیبانی از احراز هویت پایه HTTP (استاندارد RFC 7617 \%) برای کنترل دسترسی دستورات ورودی REST روی HTTP اضافه شد. اطلاعات هویتی (نام کاربری، گذرواژه) در یک فایل پیکربندی محلی Kea بر روی دیسک ذخیره می‌شوند. نام کاربری همراه با دستور API ثبت می‌شود، بنابراین می‌توان مشخص کرد که کدام کاربر احراز هویت‌شده هر دستور را اجرا کرده است. جزئیات کنترل دسترسی با استفاده از یک ثبت‌کننده وقایع (logger) اختصاصی به نام \fBauth\fP ثبت می‌شود. احراز هویت پایه HTTP به خودی خود ضعیف است زیرا در معرض حملات دیکشنری شناخته‌شده قرار دارد، اما این حملات نیازمند یک «حمله مرد میانی» (\(dqman in the middle\(dq) برای دستیابی به ترافیک HTTP هستند. این مشکل را می‌توان با استفاده انحصاری از احراز هویت پایه HTTP روی TLS برطرف کرد. در حقیقت، در صورت امکان، استفاده از گواهی‌های کلاینت برای TLS بهتر از استفاده از احراز هویت پایه HTTP است. .sp در Kea 1.9.2 یک نقطه قلاب (hook point) جدید به نام \fBauth\fP معرفی شد. با استفاده از این نقطه قلاب جدید، می‌توان یک کتابخانه قلاب خارجی را برای گسترش کنترل‌های دسترسی، ادغام با سایر مراجع احراز هویت، یا افزودن کنترل دسترسی مبتنی بر نقش (RBAC) به کانال‌های کنترلی توسعه داد. این نقطه قلاب به \fBhttp_auth\fP تغییر نام یافت و از نسخه 2.7.2 Kea توسط سرورهای DHCP و DDNS نیز پشتیبانی می‌شود. .sp هر سه دیمن اصلی Kea (\fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> و \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>) همگی از یک کانال کنترلی که به عنوان سوکت UNIX پیاده‌سازی شده، پشتیبانی می‌کنند. این کانال کنترلی که یک سوکت UNIX باز می‌کند، به صورت پیش‌فرض غیرفعال است. .SS آسیب‌پذیری Blast RADIUS .sp آسیب‌پذیری Blast\-RADIUS نقصی است که بر پروتکل RADIUS پیاده‌سازی‌شده توسط کتابخانه قلاب RADIUS تأثیر می‌گذارد. برای جزئیات بیشتر، هشدار امنیتی \%<#\:radius-security-warning> را ببینید. .SS بررسی خط‌مشی امنیتی زمان اجرای Kea .sp بررسی خط‌مشی امنیتی در زمان اجرا ابتدا در نسخه 2.7.9 Kea به دیمن‌های Kea شامل \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> و \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>\& اضافه شد. در Kea 3.0 بررسی‌های بیشتری افزوده شدند. به طور پیش‌فرض، هنگامی که یک دیمن نقض خط‌مشی امنیتی را تشخیص می‌دهد، یک پیام خطای لاگ ارسال کرده و خارج می‌شود. بررسی‌های زیر انجام می‌شوند: .INDENT 0.0 .IP \(bu 2 استفاده از مسیرهای فایل یا مجوزهای پشتیبانی‌نشده بر اساس جزئیات ارائه‌شده در خلاصه محدودیت‌های مسیر .IP \(bu 2 استفاده از عبارت متنی واضح (clear text) برای \(aquser\(aq یا \(aqpassword\(aq در احراز هویت HTTP (در Kea 3.0) .IP \(bu 2 استفاده از عبارت متنی واضح برای \(aqsecret\(aq در پیکربندی کلید TSIG (در Kea 3.0) .IP \(bu 2 استفاده از کانال‌های API پروتکل HTTP بدون احراز هویت (در Kea 3.0) .IP \(bu 2 اجرای سرور Kea تحت کاربر root. (توجه داشته باشید که این مورد تنها یک لاگ هشدار ایجاد می‌کند و هرگز متوقف‌کننده نیست) .UNINDENT .sp از نسخه 3.0 Kea، راه‌اندازی دیمن‌ها با گزینه خط فرمان \(aq\-X\(aq به آن‌ها دستور می‌دهد که در مورد خطرات امنیتی هشدار دهند اما در هر صورت به کار خود ادامه دهند. شناسه‌های پیام برای تمام این هشدارها به پسوند \(dq_SECURITY_WARNING\(dq ختم می‌شوند. .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 سرورها را بدون ارزیابی دقیق و اعمال اقدامات احتیاطی لازم با گزینه \(aq\-X\(aq اجرا نکنید. عدم رعایت این نکته می‌تواند استقرارها را در معرض آسیب‌پذیری‌های امنیتی قرار دهد. .UNINDENT .UNINDENT.SS فرآیندهای امنیتی Kea .sp بخش‌های زیر نحوه اطمینان تیم توسعه Kea DHCP از کیفیت کد و مدیریت آسیب‌پذیری‌ها را شرح می‌دهند. .SS مدیریت آسیب‌پذیری‌ها (Vulnerability Handling) .sp مجموعه ISC مشارکت‌کننده‌ای باسابقه و فعال در فرآیند استاندارد صنعتی افشای آسیب‌پذیری‌ها است و مستندات دقیقی درباره فرآیندها و آسیب‌پذیری‌های نرم‌افزارهای ISC نگهداری می‌کند. برای مشاهده خط‌مشی افشای نقایص نرم‌افزاری و آسیب‌پذیری‌های امنیتی ISC به \% مراجعه کنید. .sp در صورت بروز یک آسیب‌پذیری امنیتی در Kea، ISC پیش از هرگونه افشای عمومی، به مشتریان پشتیبانی اطلاع داده و وصله (patch) و/یا بسته نصبی به‌روزشده‌ای را برای رفع آسیب‌پذیری ارائه می‌دهد. .sp هنگامی که یک به‌روزرسانی امنیتی منتشر می‌شود، فایل‌های فشرده سورس (tarball) و بسته‌های نگهداری‌شده توسط ISC در همان روز منتشر می‌گردند. این امر کاربران سازوکارهای به‌روزرسانی بومی لینوکس (مانند apt در Debian و Ubuntu یا dnf در RedHat) را قادر می‌سازد تا سیستم‌های خود را فوراً به‌روزرسانی کنند. .SS کیفیت کد و آزمایش (Code Quality and Testing) .sp پروژه Kea در طول فرآیند توسعه خود تحت آزمایش‌های گسترده‌ای قرار می‌گیرد. موارد زیر برخی از فرآیندهایی هستند که برای اطمینان از کیفیت مناسب کد استفاده می‌شوند: .INDENT 0.0 .IP \(bu 2 هر خط کد پیش از پذیرفته شدن، از یک بازبینی رسمی (formal review) عبور می‌کند. فرآیند بازبینی مستند شده و به صورت عمومی در دسترس است. .IP \(bu 2 تقریباً ۵۰٪ از کد منبع به آزمون‌های واحد (unit tests) اختصاص دارد. تا مه ۲۰۲۴، بیش از ۱۲۰۰۰ آزمون واحد وجود داشت و این تعداد با گذشت زمان در حال افزایش است. گذراندن آزمون‌های واحد برای commit کردن هر ویژگی جدید الزامی است. .IP \(bu 2 حدود ۲۰۰۰ آزمون سیستم برای Kea وجود دارد. این آزمون‌ها هم وضعیت‌های صحیح و هم وضعیت‌های نامعتبر را شبیه‌سازی می‌کنند و بسته‌های شبکه (عمدتاً DHCP، و همچنین DNS، HTTP، HTTPS و غیره)، استفاده از خط فرمان، فراخوانی‌های API، تعاملات پایگاه داده، اسکریپت‌ها و موارد دیگر را پوشش می‌دهند. .IP \(bu 2 آزمون‌های کارایی با بیش از ۸۰ سناریو وجود دارند که کارایی کلی و تاب‌آوری Kea را در سطوح مختلف ترافیک می‌سنجند و معیارهای گوناگونی را اندازه‌گیری می‌کنند (تأخیر، اجاره‌ها بر ثانیه، بسته‌ها بر ثانیه، مصرف CPU، بهره‌وری حافظه و موارد دیگر). .IP \(bu 2 پروژه Kea از یکپارچه‌سازی مداوم (CI) استفاده می‌کند. این بدان معناست که بخش عمده آزمایش‌ها (همه آزمون‌های واحد و سیستم، و در برخی موارد آزمون‌های کارایی) به ازای هر commit اجرا می‌شوند. بسیاری از آزمایش‌های \(dqسبک‌تر\(dq روی شاخه‌ها، حتی پیش از پذیرفته شدن کد اجرا می‌شوند. .IP \(bu 2 بسیاری از آزمون‌های واحد و سیستم سناریوهای منفی را بررسی می‌کنند؛ مانند بسته‌ها، دستورات API و فایل‌های پیکربندی ناقص، خراب یا بریده‌شده (truncated)، و همچنین توالی‌های نادرست (مانند ارسال بسته‌ها با ترتیبی نامعتبر) و موارد دیگر. .IP \(bu 2 تیم توسعه Kea از ابزارهای متعددی استفاده می‌کند که بررسی‌های خودکار کیفیت کد را انجام می‌دهند، مانند danger و همچنین ابزارهای بررسی سلامت (sanity checkers) که در داخل تیم توسعه یافته‌اند. .IP \(bu 2 تیم Kea از تحلیل‌گرهای ایستای کد (static code analyzers) زیر استفاده می‌کند: Coverity Scan، cppcheck، clang\-static\-analyzer، shellcheck، flawfinder، semgrep و danger. .IP \(bu 2 تیم Kea از تحلیل‌گرهای پویای کد (dynamic code analyzers) زیر استفاده می‌کند: Valgrind، Thread Sanitizer (TSAN)، Address Sanitizer (ASAN) و Undefined Behavior Sanitizer (UBSAN). .UNINDENT .SS آزمون فازینگ (Fuzz Testing) .sp تیم Kea فرآیندی برای اجرای آزمون فازینگ دارد. فازینگ یک روش آزمون نرم‌افزار است که در آن داده‌های تولیدشده گوناگونی به عنوان ورودی به برنامه داده می‌شود و رفتارهای غیرعادی برنامه مانند فروپاشی (crash) یا قفل کردن (hang) مورد پایش قرار می‌گیرد. .sp دو روش برای فاز کردن Kea وجود دارد: .sp گزینه ۱. با تابع مهارکننده (harness function) مربوط به libfuzzer به نام LLVMFuzzerTestOneInput. .sp گزینه ۲. با کامپایلر AFL (American Fuzzy Lop \%). .sp استفاده از تابع مهارکننده LLVMFuzzerTestOneInput: .sp این حالت از فازینگ تقریباً با هر کامپایلری کار می‌کند. .sp چهار نوع فازر در این حالت پیاده‌سازی شده است: .INDENT 0.0 .IP \(bu 2 فازر Config .IP \(bu 2 فازر نقطه پایانی HTTP .IP \(bu 2 فازر Packet .IP \(bu 2 فازر سوکت Unix .UNINDENT .sp دو فایل باینری تحت آزمون وجود دارند: .INDENT 0.0 .IP \(bu 2 \fIkea\-dhcp4\fP .IP \(bu 2 \fIkea\-dhcp6\fP .UNINDENT .SS یکپارچگی انتشار (Release Integrity) .sp تمام نسخه‌های منتشرشده نرم‌افزارهای ISC با PGP امضا شده و از طریق وب‌سایت ISC توزیع می‌شوند؛ وب‌سایتی که خود با DNSSEC امضا شده است، بنابراین کاربران می‌توانند مطمئن باشند که در نرم‌افزار دستکاری صورت نگرفته است. .SS ضریب اتوبوس (Bus Factor) .sp طبق اعلام پروژه Core Infrastructure \%، \(dqضریب اتوبوس\(dq یا \(dqضریب کامیون\(dq حداقل تعداد اعضای پروژه است که باید ناگهان از پروژه ناپدید شوند (\(dqبا یک اتوبوس تصادف کنند\(dq) قبل از اینکه پروژه به دلیل کمبود افراد آگاه یا دارای صلاحیت متوقف شود. تخمین دقیق آن دشوار است، اما ضریب اتوبوس برای Kea حدود پنج نفر است. تا سال ۲۰۲۱، شش توسعه‌دهنده اصلی و دو مهندس تضمین کیفیت به همراه مشارکت‌کنندگان جانبی متعدد (مدیر محصول، تیم پشتیبانی، IT و غیره) وجود دارند. این تیم از نظر جغرافیایی پراکنده است. .SS متفرقه (Miscellaneous) .SS ایجاد فایل‌های core dump .sp کرنل‌ها در صورت فعال بودن این ویژگی، هنگام فروپاشی یک فرآیند یا دریافت سیگنالی متناظر با این عمل، فایل‌های core dump ایجاد می‌کنند. روش فعال‌سازی فایل‌های core dump وابسته به سیستم است، اما دارای کنترل‌های مشترکی نظیر محدودیت \fBcoredumpsize\fP یا \fBcore file size\fP است که می‌توان آن‌ها را با استفاده از دستورات \fBulimit\fP یا \fBlimit\fP یا دستورات توکار شل مشاهده کرد و تغییر داد. .sp مستند پایگاه دانش با عنوان «What to do if your BIND, Kea DHCP, Stork, or ISC DHCP server has crashed» در \% جزئیات مربوط به هر سیستم را در بخش \fIThings to check if a core file does not get generated\fP توضیح می‌دهد. .sp روش دیگر برای ایجاد یک فایل core dump، دستور \fBgcore\fP است که چنین فایل‌ها / ایمیج‌هایی را از یک فرآیند در حال اجرا ایجاد می‌کند. لطفاً برای درک نحوه استفاده از آن، به صفحه راهنمای آن مراجعه کنید. دو نکته حائز اهمیت است: .INDENT 0.0 .IP \(bu 2 آیا \fBgcore\fP فرآیندی را که از آن dump گرفته می‌شود معلق (suspend) می‌کند یا گزینه‌ای برای تعلیق آن ارائه می‌دهد؟ .IP \(bu 2 نام فایل core dump تولیدشده (که برای فایل‌های core dump ایجادشده توسط هسته نیز کاربرد دارد). .UNINDENT .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 توجه داشته باشید که فایل‌های core dump ممکن است بسیار حجیم باشند و به راحتی سیستم فایلی که در آن ذخیره می‌شوند را پر کنند... برای مثال فراموش نکنید در صورتی که نیازی به این ویژگی نیست یا دیگر نیازی به آن ندارید، آن را فعال رها نکنید. .UNINDENT .UNINDENT.SH "پیکربندی KEA (KEA CONFIGURATION)" .sp ‏Kea از ساختارهای JSON برای نمایش پیکربندی‌های کارساز استفاده می‌کند. بخش‌های زیر نحوه سازمان‌دهی این ساختارهای پیکربندی را شرح می‌دهند. .SS "پیکربندی JSON (JSON Configuration)" .sp ‏JSON نشانه‌گذاری مورد استفاده در سراسر پروژه Kea است. آشکارترین کاربرد آن برای فایل پیکربندی است، اما از JSON برای ارسال دستورها از طریق Management API (ببینید: Management API \%<#\:ctrl-channel>) و ارتباط بین کارسازهای DHCP و دیمن به‌روزرسانی DDNS نیز استفاده می‌شود. .sp کاربرد معمول بر این فرض است که کارسازها از خط فرمان، به‌صورت مستقیم یا با استفاده از یک اسکریپت مانند \fBkeactrl\fP \%<#\:std-iscman-keactrl>\& راه‌اندازی می‌شوند. فایل پیکربندی هنگام راه‌اندازی با استفاده از پارامتر \fB\-c\fP مشخص می‌شود. .SS "نحو JSON (JSON Syntax)" .sp فایل‌های پیکربندی برای ماژول‌های DHCPv4، DHCPv6، DDNS و NETCONF در قالب گسترش‌یافته‌ای از JSON تعریف می‌شوند. نگارش پایه JSON در RFC 7159 \% و ECMA 404 \%\& تعریف شده است. به‌ویژه، تنها مقادیر بولی مجاز true یا false (تماماً با حروف کوچک) هستند. نگارش‌های با حروف بزرگ (True یا False) پذیرفته نمی‌شوند. .sp اگرچه استاندارد JSON (یا ECMA 404) نیازی ندارد که اشیای JSON (یعنی نگاشت‌های نام/مقدار) ورودی‌های یکتا داشته باشند، Kea آن‌ها را با استفاده از map در C++ STL با ورودی‌های یکتا پیاده‌سازی می‌کند. از این رو، اگر چندین مقدار برای یک نام در یک شیء/نگاشت وجود داشته باشد، آخرین مقدار بر مقادیر قبلی بازنویسی می‌شود. از نسخه Kea 1.9.0 به بعد، تجزیه‌کننده‌های فایل پیکربندی در چنین مواردی خطای نحو برمی‌انگیزند. .sp مؤلفه‌های Kea از JSON گسترش‌یافته با قابلیت‌های اضافی مجاز زیر استفاده می‌کنند: .INDENT 0.0 .IP \(bu 2 کامنت‌های شل: هر متنی پس از نویسه هش (#) نادیده گرفته می‌شود. .IP \(bu 2 کامنت‌های C: هر متنی پس از نویسه دو اسلش (//) نادیده گرفته می‌شود. .IP \(bu 2 کامنت‌های چندخطی: هر متنی بین /* و */ نادیده گرفته می‌شود. این کامنت می‌تواند در چند خط امتداد یابد. .IP \(bu 2 شامل‌سازی فایل: فایل‌های JSON می‌توانند فایل‌های JSON دیگر را با استفاده از گزاره‌ای به شکل شامل شوند. .IP \(bu 2 ویرگول‌های اضافی: جهت رفع مشکل خطاهای ناشی از ویرگول‌های باقی‌مانده پس از اعمال تغییرات در پیکربندی. هنگام تجزیه، هشداری همراه با مکان ویرگول چاپ می‌شود تا به کاربر امکان اصلاح اشتباه احتمالی داده شود. .UNINDENT .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 این قابلیت‌ها برای استفاده در فایل پیکربندی JSON در نظر گرفته شده‌اند. استفاده از آن‌ها به هر روش دیگر ممکن است به بروز خطا منجر شود. .UNINDENT .UNINDENT .sp فایل پیکربندی از یک شیء منفرد (که اغلب در اصطلاح عامیانه نگاشت نامیده می‌شود) تشکیل شده است که با یک آکوالاد باز شروع می‌شود. این فایل تنها شامل یکی از اشیای \(dqDhcp4\(dq، \(dqDhcp6\(dq، \(dqDhcpDdns\(dq یا \(dqNetconf\(dq است. تعریف عناصر اضافی امکان‌پذیر است اما نادیده گرفته خواهند شد. .sp یک پیکربندی بسیار ساده برای DHCPv4 می‌تواند به این شکل باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX # The whole configuration starts here. { # DHCPv4 specific configuration starts here. \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth0\(dq ], \(dqdhcp\-socket\-type\(dq: \(dqraw\(dq }, \(dqvalid\-lifetime\(dq: 4000, \(dqrenew\-timer\(dq: 1000, \(dqrebind\-timer\(dq: 2000, \(dqsubnet4\(dq: [{ \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1\-192.0.2.200\(dq } ], \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqid\(dq: 1 }], # Now loggers are inside the DHCPv4 object. \(dqloggers\(dq: [{ \(dqname\(dq: \(dq*\(dq, \(dqseverity\(dq: \(dqDEBUG\(dq }] } # The whole configuration structure ends here. } .EE .UNINDENT .UNINDENT .sp مثال‌های بیشتر در دایرکتوری نصب‌شده \fBshare/doc/kea/examples\fP در دسترس هستند. .sp برای جلوگیری از تکرار ساختارهای عمدتاً مشابه، مثال‌های بخش‌های بعدی این راهنما تنها زیرمجموعه‌ای از پارامترهای مناسب برای یک بافت مشخص را نمایش می‌دهند. برای مثال، هنگام بحث درباره پیکربندی زیرشبکه‌های IPv6 در DHCPv6، تنها پارامترهای subnet6 ذکر خواهند شد. بدیهی است که سایر عناصر (نگاشت سراسری که شامل Dhcp6 است) وجود دارند، اما برای وضوح بیشتر حذف شده‌اند. معمولاً مکان‌هایی که پارامترهای اضافی ممکن است ظاهر شوند با سه‌نقطه (...) مشخص شده‌اند. .SS "کامنت‌ها و بافت کاربری (Comments and User Context)" .sp در صورتی که فایل پیکربندی JSON به‌صورت محلی استفاده شود، کامنت‌های به سبک شل، C یا C++ همگی در آن مجاز هستند. این روش راحت است و در موارد ساده‌ای که پیکربندی به‌صورت ایستا با استفاده از یک فایل محلی نگهداری می‌شود کارایی دارد. با این حال، از آنجا که کامنت‌ها بخشی از نحو JSON نیستند، بیشتر ابزارهای JSON آن‌ها را به عنوان خطا تشخیص می‌دهند. مشکل دیگر این است که به محض بارگیری پیکربندی توسط Kea، کامنت‌های به سبک شل، C و C++ نادیده گرفته می‌شوند. اگر دستورهایی مانند \fBconfig\-get\fP \%<#\:std-isccmd-config-get> یا \fBconfig\-write\fP \%<#\:std-isccmd-config-write> استفاده شوند، آن کامنت‌ها از دست می‌روند. نمونه‌ای از این کامنت‌ها در بخش پیشین ارائه شد. .sp از نظر تاریخی، برای رفع این مشکل، کد Kea استفاده از رشته‌های \fIcomment\fP را به عنوان موجودیت‌های معتبر JSON مجاز دانست. این ویژگی این مزیت را داشت که در طول عملیات مختلف (مانند \fBconfig\-get\fP \%<#\:std-isccmd-config-get>) حفظ می‌شد یا امکان پردازش توسط ابزارهای JSON را فراهم می‌کرد. نمونه‌ای از یک کامنت JSON بدین صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [{ \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq }], \(dqcomment\(dq: \(dqsecond floor\(dq }] } .EE .UNINDENT .UNINDENT .sp با این حال، این واقعیت که کامنت تنها می‌توانست تک‌خطی باشد و امکان افزودن اطلاعات دیگر در قالبی ساختاریافته‌تر وجود نداشت، ناامیدکننده بود. یک نمونه مشخص، درخواست برای افزودن شماره طبقات و ساختمان‌ها به زیرشبکه‌ها بود. این امر یکی از دلایلی بود که مفهوم بافت کاربری (user context) معرفی شد؛ مفهومی که اجازه افزودن یک ساختار دلخواه JSON را به اکثر ساختارهای پیکربندی Kea می‌دهد. .sp این روش در مقایسه با رویکردهای پیشین مزایای متعددی دارد. اولاً کاملاً با ابزارهای JSON و دستورهای Kea سازگار است. ثانیاً علاوه بر ذخیره رشته‌های ساده کامنت، می‌تواند داده‌های بسیار پیچیده‌تری را ذخیره کند، مانند چند خط (به‌صورت آرایه‌ای از رشته‌ها)، داده‌های نوع‌دار اضافی (مانند شماره طبقات به‌صورت عددی واقعی) و موارد دیگر. ثالثاً این داده‌ها در دسترس قلاب‌ها قرار می‌گیرند، بنابراین امکان توسعه قلاب‌های شخص ثالث که از این اطلاعات اضافی بهره می‌برند وجود دارد. نمونه‌ای از یک بافت کاربری بدین شکل است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [{ \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq }], \(dquser\-context\(dq: { \(dqcomment\(dq: \(dqsecond floor\(dq, \(dqfloor\(dq: 2 } }] } .EE .UNINDENT .UNINDENT .sp بافت‌های کاربری تا زمانی که از نحو معتبر JSON پیروی کنند و عنصر سطح بالای آن‌ها یک نگاشت باشد (یعنی داده‌ها باید درون آکوالاد قرار گیرند)، می‌توانند هر فایل داده دلخواهی را ذخیره کنند. با این حال، برخی از کتابخانه‌های قلاب ممکن است قالب‌بندی خاصی را انتظار داشته باشند؛ لطفاً برای جزئیات به مستندات کتابخانه قلاب مربوطه مراجعه کنید. .sp سازوکار user\-context جایگزین قابلیت‌های کامنت JSON شده است؛ ISC به مدیران سیستم توصیه می‌کند به‌جای سازوکارهای قدیمی‌تر، از user context استفاده کنند. برای ترویج این شیوه ذخیره کامنت‌ها، Kea کامنت‌های JSON را به‌صورت خودکار و بلادرنگ به user context تبدیل می‌کند. .sp با این حال، اگر پیکربندی از روش قدیمی کامنت JSON استفاده کند، دستور \fBconfig\-get\fP \%<#\:std-isccmd-config-get> یک پیکربندی اندکی تغییریافته را برمی‌گرداند. این مورد غیرمعمول نیست که فراخوانی \fBconfig\-set\fP \%<#\:std-isccmd-config-set> و به دنبال آن \fBconfig\-get\fP \%<#\:std-isccmd-config-get> ساختاری کمی متفاوت را دریافت کند. بهترین راه برای جلوگیری از این مشکل این است که استفاده از کامنت‌های JSON را کنار گذاشته و از user context استفاده کنید. .sp ‏Kea از بافت‌های کاربری در سطوح زیر پشتیبانی می‌کند: دامنه سراسری (global scope)، پیکربندی رابط‌ها (interfaces configuration)، چندریسمانی (multi\-threading)، شبکه‌های اشتراکی (shared networks)، زیرشبکه‌ها (subnets)، کلاس‌های کلاینت (client classes)، داده‌ها و تعاریف گزینه‌ها (option data and definitions)، استخرها (pools)، استخرهای واگذاری پیشوند (prefix delegation pools)، رزروهای میزبان (host reservations)، سوکت کنترل (control socket)، سرآیند HTTP، احراز هویت (authentication)، کلاینت‌ها (clients)، کنترل صف (queue control)، ‏DHCP\-DDNS، ثبت‌کننده‌ها (loggers)، اجاره‌ها (leases) و شناسه سرور (server ID). این موارد در هر دو DHCPv4 و DHCPv6 پشتیبانی می‌شوند، به استثنای استخرهای واگذاری پیشوند و شناسه سرور که تنها مختص DHCPv6 هستند. .sp بافت کاربری را می‌توان در ساختارهای پشتیبانی‌شده توسط دستورها افزود و ویرایش کرد. .sp ما کاربران Kea را تشویق می‌کنیم که از این توابع برای ذخیره اطلاعات مورد استفاده سایر سامانه‌ها و قلاب‌های سفارشی استفاده کنند. .sp برای مثال، می‌توان از دستور \fBsubnet4\-update\fP \%<#\:std-isccmd-subnet4-update> برای افزودن داده‌های بافت کاربری به یک زیرشبکه موجود استفاده کرد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.20.30.0/24\(dq, \(dquser\-context\(dq: { \(dqbuilding\(dq: \(dqMain\(dq, \(dqfloor\(dq: 1 } } ] } .EE .UNINDENT .UNINDENT .sp همین کار را می‌توان با بسیاری از دستورهای دیگر، مانند \fBlease6\-add\fP \%<#\:std-isccmd-lease6-add> و غیره نیز انجام داد. .sp ‏Kea همچنین از بافت کاربری برای ذخیره داده‌های غیراستاندارد استفاده می‌کند. در حال حاضر، تنها Storing Extended Lease Information \%<#\:dhcp4-store-extended-info> از این قابلیت استفاده می‌کند. .sp در صورت فعال بودن، کلید ISC در \fBuser\-context\fP اضافه می‌شود تا محتوای اضافه‌شده خودکار را متمایز کند. .sp نمونه‌ای از اطلاعات رله ذخیره‌شده در یک اجاره: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqclient\-id\(dq: \(dq42:42:42:42:42:42:42:42\(dq, \(dqcltt\(dq: 12345678, \(dqfqdn\-fwd\(dq: false, \(dqfqdn\-rev\(dq: true, \(dqhostname\(dq: \(dqmyhost.example.com.\(dq, \(dqhw\-address\(dq: \(dq08:08:08:08:08:08\(dq, \(dqip\-address\(dq: \(dq192.0.2.1\(dq, \(dqstate\(dq: 0, \(dqsubnet\-id\(dq: 44, \(dqvalid\-lft\(dq: 3600, \(dquser\-context\(dq: { \(dqISC\(dq: { \(dqrelays\(dq: [ { \(dqhop\(dq: 2, \(dqlink\(dq: \(dq2001:db8::1\(dq, \(dqpeer\(dq: \(dq2001:db8::2\(dq }, { \(dqhop\(dq: 1, \(dqlink\(dq: \(dq2001:db8::3\(dq, \(dqoptions\(dq: \(dq0x00C800080102030405060708\(dq, \(dqpeer\(dq: \(dq2001:db8::4\(dq }] } } } } .EE .UNINDENT .UNINDENT .sp بافت کاربری می‌تواند پیکربندی مربوط به چندین قلاب و کامنت را به‌طور هم‌زمان ذخیره کند. .sp برای بررسی نحوه استفاده از بافت کاربری در قلاب‌ها، به User Contexts in Hooks \%<#\:user-context-hooks>\& مراجعه کنید..SS "نشانه‌گذاری ساده‌شده (Simplified Notation)" .sp گاهی اوقات ارجاع به یک عنصر خاص در سلسله‌مراتب پیکربندی راحت‌تر است. هر سطح سلسله‌مراتب با یک اسلش جدا می‌شود. اگر آرایه‌ای وجود داشته باشد، به نمونه‌ای خاص درون آن آرایه با عددی در داخل قلاب‌ها ارجاع داده می‌شود (با شماره‌گذاری که از صفر آغاز می‌شود). برای نمونه، در پیکربندی بالا، valid\-lifetime در مؤلفه Dhcp4 می‌تواند به‌صورت Dhcp4/valid\-lifetime، و pool در نخستین زیرشبکه تعریف‌شده در پیکربندی DHCPv4 به‌صورت Dhcp4/subnet4[0]/pool ارجاع داده شود. .SS "گنجاندن فایل‌های پیکربندی (Configuration Files Inclusion)" .sp تجزیه‌کننده قابلیت گنجاندن فایل‌ها را فراهم می‌آورد. نحو دستور به‌گونه‌ای انتخاب شده است که شبیه به نحوه گنجاندن اسکریپت‌های PHP در کد HTML توسط Apache به نظر برسد. این نحو خاص برای تأکید بر این موضوع انتخاب شده است که دستور include یک ویژگی اضافی است و بخشی از نحو JSON به شمار نمی‌رود. .sp گنجاندن به‌صورت پشته‌ای از فایل‌ها پیاده‌سازی شده است. می‌توانید از دستور include در گنجاندن‌های تودرتو استفاده کنید. حداکثر ده سطح تودرتویی پشتیبانی می‌شود. این محدودیت که به‌طور دلخواه انتخاب شده، محافظتی در برابر گنجاندن‌های بازگشتی است. .sp دستور include فرم زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX .EE .UNINDENT .UNINDENT .sp الگوی \fI[PATH]\fP باید با یک مسیر مطلق یا یک مسیر نسبت به دایرکتوری کاری جاری در زمان اجرای فرایند Kea جایگزین شود. .sp برای گنجاندن یک فایل درون فایلی دیگر، از نحو زیر استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dq*\(dq ]}, \(dqpreferred\-lifetime\(dq: 3000, \(dqrebind\-timer\(dq: 2000, \(dqrenew\-timer\(dq: 1000, \(dqvalid\-lifetime\(dq: 4000 } } .EE .UNINDENT .UNINDENT .sp جایی که محتوای \(dqsubnets.json\(dq می‌تواند چنین باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqid\(dq: 123, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq }, { \(dqid\(dq: 234, \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq }, { \(dqid\(dq: 345, \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq } ], \&... } .EE .UNINDENT .UNINDENT .SS "پس‌زمینه پیکربندی Kea (Kea Configuration Backend)" .SS "کاربردپذیری (Applicability)" .sp پس‌زمینه پیکربندی Kea (به اختصار CB یا config backend) به سرورهای Kea این قابلیت را می‌دهد تا تقریباً همه پیکربندی خود را در یک یا چند پایگاه‌داده ذخیره کنند. .sp ویژگی‌ها و مزایای بالقوه شامل موارد زیر است: .INDENT 0.0 .IP \(bu 2 استفاده مجدد از بخش‌های پیکربندی یکسان در چندین سرور Kea .IP \(bu 2 یک \(dqمنبع واحد حقیقت\(dq برای همه سرورهای Kea .IP \(bu 2 انجام تمام پیکربندی‌ها از طریق یک API به همراه بررسی‌های منطقی بی‌درنگ .IP \(bu 2 یکپارچه‌سازی آسان‌تر با ابزارهای شخص ثالث یا خودکارسازی‌های درون‌سازمانی .IP \(bu 2 معماری پایگاه‌داده همزمانی، سازگاری و تفکیک‌ناپذیری (atomicity) را فراهم می‌کند .IP \(bu 2 قابلیت کاوش در پایگاه‌داده برای استخراج آمار و گزارش‌گیری .IP \(bu 2 استفاده از همانندسازی (replication) پایگاه‌داده برای تحمل خطای بی‌درنگ .UNINDENT .sp معایب بالقوه شامل موارد زیر است: .INDENT 0.0 .IP \(bu 2 تلاش اولیه قابل‌توجه برای آماده‌سازی یکپارچه‌سازی و/یا خودکارسازی .IP \(bu 2 سناریوهای پشتیبانی‌شده برای بیشتر پیکربندی‌ها به استفاده از API نیاز دارند .IP \(bu 2 این API تنها برای مشتریان ISC با یک قرارداد پشتیبانی پولی در دسترس است .IP \(bu 2 ناسازگار با برخی کاربردها، نرم‌افزارها و سناریوها .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 استفاده از یک پایگاه‌داده برای ذخیره‌سازی اجاره‌ها (leases) و/یا رزروهای میزبان (host reservations) بدون استفاده از CB امکان‌پذیر است. دستورالعمل‌های پیکربندی \fBhost\-databases\fP و \fBlease\-database\fP را ببینید. .UNINDENT .UNINDENT.SS سناریوی نمونه .sp سازمان بزرگی را با چندین شعبه (site) در نظر بگیرید که در هر یک، یک جفت کارساز Kea در پیکربندی دسترسی‌پذیری بالا (HA) مستقر شده است. معمولاً چنین استقرارهایی از پیکربندی‌های استانداردسازی‌شده استفاده می‌کنند که منجر به پارامترهای پیکربندی مشابه برای هر شعبه می‌شود. اعضای هر جفت HA اغلب تقریباً کاملاً یکسان هستند و فقط در نام با یکدیگر تفاوت دارند. اغلب استقرارهایی با این ابعاد از سطح بالایی از اتوماسیون، شامل سامانه‌های تدارک (provisioning) و مدیریت بهره می‌برند. .sp بک‌اند پیکربندی (CB) برای چنین استقرارهایی ایده‌آل است. اگرچه ادغام آن با اتوماسیون تدارک به مقداری تلاش نیاز دارد، اما پس از انجام، استقرار کارسازهای جدید Kea می‌تواند تقریباً خودکار باشد. می‌توان از یک پیکربندی JSON اولیه و حداقلی (\(dqstub\(dq) که برای هر کارساز یکسان است استفاده کرد و تمام پیکربندی‌های باقی‌مانده (شبکه‌های مشترک، زیرشبکه‌ها، استخرها و غیره) را از پایگاه‌داده مرکزی CB بارگذاری نمود. هرگونه به‌روزرسانی در پایگاه‌داده مرکزی CB به‌طور خودکار به تمام نمونه‌های Kea منتشر می‌شود. بدین ترتیب CB به \(dqتنها منبع حقیقت\(dq (single source of truth) برای DHCP در سراسر سازمان تبدیل می‌شود. .SS محدودیت‌ها و هشدارها .SS دسترسی‌پذیری .sp \fBlibdhcp_cb_cmds.so\fP \%<#\:std-ischooklib-libdhcp_cb_cmds\:.so> تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس است. برای کسب اطلاعات بیشتر درباره گزینه‌های اشتراک، لطفاً فرم موجود در \%\& را تکمیل کنید. اگرچه از نظر تئوری استفاده از CB بدون این قلاب (hook) امکان‌پذیر است، اما این کار نه پشتیبانی می‌شود و نه توصیه می‌گردد. .SS نیازمندی به آماده‌سازی .sp بک‌اند پیکربندی (Configuration Backend) یک راهکار آماده و خودکار (\(dqplug\-and\-play\(dq) نیست. سناریوهای پشتیبانی‌شده به استفاده از دستورهای CB API نیاز دارند. اطلاعات پیکربندی باید با استفاده از API در پایگاه‌داده CB بارگذاری شوند تا CB تأثیرگذار باشد. هدف کلی این است که CB به عنوان بخشی از یک راهکار تدارک (provisioning) بزرگ‌تر یکپارچه شود. لطفاً تا زمانی که کارهای آماده‌سازی لازم را انجام نداده‌اید، \fBconfig\-databases\fP را تعریف نکنید. .SS مدیریت پایگاه‌داده .sp تنها روش پشتیبانی‌شده برای مدیریت محتوای پایگاه‌داده CB، از طریق قلاب \fBlibdhcp_cb_cmds.so\fP \%<#\:std-ischooklib-libdhcp_cb_cmds\:.so> است که دستورهای API را برای بک‌اندهای پیکربندی ارائه می‌دهد. از نظر عملی، برای استفاده از CB، باید تقریباً تمام پیکربندی Kea را از طریق CB API انجام دهید. .sp اگرچه از نظر تئوری امکان استفاده از CB بدون API (با استفاده از ابزارهایی مانند MySQL Workbench یا کلاینت خط فرمانی MySQL) وجود دارد، اما این روش‌ها نه توصیه می‌شوند و نه پشتیبانی دارند. .SS تداخل‌های پیکربندی .sp ما قویاً توصیه می‌کنیم از ادغام اطلاعات پیکربندی CB و فایل پیکربندی JSON خودداری کنید. به عبارت دیگر، از هر دو روش تعاریف پیکربندی JSON و CB برای پیکربندی انواع یکسان اشیاء استفاده نکنید. در حالت ایده‌آل، هنگام استفاده از CB، فایل‌های پیکربندی Kea باید حاوی حداقل‌های ضروری مطلق باشند و هر چیز دیگری از طریق CB تأمین شود. .sp استفاده هم‌زمان از CB و JSON به عنوان منبع پیکربندی، خطر تداخل تعاریف را به همراه دارد. چنین تداخل‌هایی در بهترین حالت گیج‌کننده هستند و معمولاً منجر به رفتارهای ناخواسته یا بروز خطا از جانب Kea می‌شوند. .sp در صورت بروز تداخل، دستورالعمل‌های پیکربندی پایگاه‌داده CB معمولاً نسبت به دستورالعمل‌های فایل JSON اولویت دارند. .sp در برخی سناریوهای به‌دقت کنترل‌شده، ممکن است از نظر فنی استفاده از هر دو روش امکان‌پذیر باشد. به عنوان مثال، تعریف یک زیرشبکه در فایل JSON و زیرشبکه دوم (متفاوت) در پایگاه‌داده CB تداخلی ایجاد نمی‌کند. با این حال، ساختارهای دیگر به طور کامل جایگزین می‌شوند. برای مثال، اگر کلاس‌های کلاینت (client classes) در پایگاه‌داده CB تعریف شده باشند، کارساز DHCP تمام کلاس‌های کلاینت تعریف‌شده در فایل JSON را نادیده می‌گیرد. .sp به طور خلاصه، اگر از CB استفاده می‌کنید، باید تنها از CB استفاده کنید. .SS نرم‌افزارهای ناسازگار .sp دستورهای API که پیکربندی Kea را تغییر می‌دهند (به غیر از CB API) منع شده‌اند. این شامل قلاب \fBlibdhcp_subnet_cmds.so\fP \%<#\:std-ischooklib-libdhcp_subnet_cmds\:.so> نیز می‌شود. توابع API این قلاب پیکربندی درون حافظه (in\-memory) کارساز Kea را تغییر می‌دهند و این تغییرات تنها با استفاده از \fBconfig\-write\fP جهت نوشتن یک فایل پیکربندی JSON جدید ماندگار می‌شوند. .sp مجموعه مدیریتی Stork \% در حال حاضر از CB پشتیبانی نمی‌کند. Stork تمامی تغییرات پیکربندی را از طریق روش‌های API انجام می‌دهد که انتظار دارند تغییرات در فایل پیکربندی JSON نوشته شوند. پشتیبانی از CB برای انتشار آینده Stork برنامه‌ریزی شده است. .sp در برخی سناریوهای به‌دقت کنترل‌شده، ممکن است استفاده از این ابزارها همراه با CB امکان‌پذیر باشد؛ به ویژه اگر به صورت کاملاً \(dqفقط‌خواندنی\(dq (read\-only) صرفاً برای بازیابی اطلاعات Kea و نه هرگز برای تغییر آن به کار روند. با این حال، هیچ محافظتی در برابر تغییرات تصادفی وجود ندارد، بنابراین این روش توصیه نمی‌شود. .SS محدودیت‌ها .sp در حال حاضر، Kea CB دارای محدودیت‌های زیر است: .INDENT 0.0 .IP \(bu 2 تنها برای پایگاه‌های داده MySQL و PostgreSQL پشتیبانی می‌شود. .IP \(bu 2 تنها برای دیمن‌های DHCPv4 و DHCPv6 پشتیبانی می‌شود؛ دیمن D2 و دیمن NETCONF را نمی‌توان از پایگاه‌داده پیکربندی کرد. .IP \(bu 2 تنها پارامترهای پیکربندی خاصی از DHCP را می‌توان در پایگاه‌داده تنظیم کرد: پارامترهای سراسری، تعاریف گزینه‌ها، گزینه‌های سراسری، کلاس‌های کلاینت، شبکه‌های مشترک و زیرشبکه‌ها. سایر پارامترهای پیکربندی باید از یک فایل پیکربندی JSON تأمین شوند. .UNINDENT .SS گزینه‌های سفارشی .sp استفاده از قالب‌های گزینه‌ سفارشی نیازمند ایجاد تعاریف برای این گزینه‌ها است. فرض کنید کاربری بخواهد داده‌های گزینه را در بک‌اند پیکربندی تنظیم کند. در این صورت، توصیه می‌کنیم تعریف مربوط به آن گزینه را نیز در بک‌اند پیکربندی مشخص نمایید. این امر زمانی ضروری است که چندین کارساز از طریق بک‌اند پیکربندی مدیریت می‌شوند و ممکن است پیکربندی‌های متفاوتی داشته باشند. تجزیه‌گر داده‌های گزینه می‌تواند تعاریف گزینه‌ای را جستجو کند که متناسب با کارسازی باشد که داده‌های گزینه برای آن تعیین شده است. .sp در یک استقرار تک‌کارساز، یا زمانی که همه کارسازها اطلاعات فایل پیکربندی یکسانی را به اشتراک می‌گذارند، می‌توان تعاریف گزینه‌ها را در فایل‌های پیکربندی و داده‌های گزینه را در بک‌اند پیکربندی مشخص کرد. کارسازی که دستوری برای تنظیم داده‌های گزینه دریافت می‌کند، حتی زمانی که داده‌های گزینه را برای کارساز دیگری تنظیم می‌کند، باید تعریفی معتبر در فایل پیکربندی خود داشته باشد. .sp مشخص کردن تعاریف گزینه‌ها در بک‌اند پیکربندی و داده‌های متناظر گزینه در فایل‌های پیکربندی کارساز پشتیبانی نمی‌شود. .SS اجزاء .sp راهکار Kea Configuration Backend متشکل از ماژول‌های CB (کتابخانه‌های قلاب)، رابط برنامه‌نویسی دستورهای CB (کتابخانه قلاب اختصاصی خود)، نرم‌افزار پایگاه‌داده خارجی (MySQL یا PostgreSQL)، طرح‌واره (schema) پایگاه‌داده و اطلاعات پیکربندی Kea ذخیره‌شده در پایگاه‌داده است. .sp در این مستندات، اصطلاح \(dqConfiguration Backend\(dq ممکن است به ماژول خاصی از Kea نیز اشاره داشته باشد که پشتیبانی از آن نوع پایگاه‌داده را فراهم می‌کند. به عنوان مثال، بک‌اند پیکربندی MySQL، یعنی \fBlibdhcp_mysql.so\fP \%<#\:std-ischooklib-libdhcp_mysql\:.so>، مجموعه‌ای کامل از توابع را برای مدیریت و واکشی اطلاعات پیکربندی از یک پایگاه‌داده MySQL فراهم می‌سازد. بک‌اند پیکربندی PostgreSQL، یعنی \fBlibdhcp_pgsql.so\fP \%<#\:std-ischooklib-libdhcp_pgsql\:.so>، ماژول متناظر برای PostgreSQL است. به همین ترتیب، اصطلاح \(dqپایگاه‌داده\(dq برای اشاره به هر دو پایگاه‌داده MySQL یا PostgreSQL به کار می‌رود. .sp رابط برنامه‌نویسی دستورهای CB مجموعه‌ای کامل از دستورها را برای مدیریت اطلاعات پیکربندی Kea، همان‌گونه که در پایگاه‌داده ذخیره شده است، ارائه می‌دهد. این API در کتابخانه قلاب اختصاصی خود، یعنی \fBlibdhcp_cb_cmds.so\fP \%<#\:std-ischooklib-libdhcp_cb_cmds\:.so>\& پیاده‌سازی شده است. این کتابخانه را می‌توان به هر دو نمونه کارساز DHCPv4 و DHCPv6 متصل کرد. این ماژول بسیاری از عملیات متداول، مانند فهرست‌کردن، افزودن، واکشی و حذف پارامترهای سراسری، شبکه‌های مشترک، زیرشبکه‌ها، استخرها، گزینه‌ها، تعاریف گزینه‌ها و کلاس‌های کلاینت را ساده می‌کند. علاوه بر این، منطق تجاری ضروری را برای تضمین یکپارچگی منطقی داده‌ها فراهم می‌آورد. تمامی دستورهای CB API با \fBremote\-\fP\& آغاز می‌شوند. برای اطلاعات بیشتر به libdhcp_cb_cmds.so: Configuration Backend Commands \%<#\:hooks-cb-cmds> مراجعه کنید. .sp نصب و نگهداری نرم‌افزارهای پایگاه‌داده خارجی فراتر از حوزه این راهنما است. .sp طرح‌واره (schema) پایگاه‌داده معمولاً از طریق ابزار \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> نصب می‌شود. برای اطلاعات بیشتر به Installation مراجعه کنید. اسکریپت‌های خام ایجاد طرح‌واره عبارتند از: dhcpdb_create.mysql \% و dhcpdb_create.pgsql \%\&. .sp برای مقداردهی و پر کردن پایگاه‌داده با اطلاعات پیکربندی Kea، از API دستورهای CB استفاده کنید. .sp اسناد طراحی مرتبط در GitLab ما در دسترس هستند: .INDENT 0.0 .IP \(bu 2 طراحی CB \% .IP \(bu 2 طراحی کلاس‌های کلاینت در CB \% .UNINDENT.SS "نصب (Installation)" .sp برای استفاده از هر یک از Backendهای پیکربندی، کتابخانهٔ ماژول مناسب (\fBlibdhcp_mysql.so\fP \%<#\:std-ischooklib-libdhcp_mysql\:.so> یا \fBlibdhcp_pgsql.so\fP \%<#\:std-ischooklib-libdhcp_pgsql\:.so>) باید در حین ساخت Kea کامپایل شود. سوییچ \fB\-D\fP مشخص می‌کند که در صورت وجود، کدام ماژول پایگاه‌داده ساخته شود: \fB\-D mysql=enabled\fP یا \fB\-D postgresql=enabled\fP\&. کتابخانه‌های کلاینت پایگاه‌داده و فایل‌های هدر مناسب باید پیش از ساخت نصب شده باشند. برای اطلاعات بیشتر دربارهٔ ساخت Kea با پشتیبانی از پایگاه‌داده، به «نصب و پیکربندی پایگاه‌دادهٔ DHCP» \%<#\:dhcp-install-configure> مراجعه کنید. بسته‌بندی‌های Kea ارائه‌شده توسط ISC، و همچنین برخی از توزیع‌های شخص ثالث، بسته‌های جداگانه‌ای را برای هر نوع پایگاه‌داده ارائه می‌دهند. .sp سرور پایگاه‌داده‌ای که میزبان جدول‌های CB است باید با شِمای Kea آماده‌سازی شود. هنگام ارتقای یک نصب موجود از Kea، ممکن است شِمای پایگاه‌داده نیز به ارتقا نیاز داشته باشد. از ابزار \fBkea\-admin\fP \%<#\:std-iscman-kea-admin> می‌توان برای اعمال راحت‌تر شِما استفاده کرد، همان‌طور که در «ابزار kea\-admin» \%<#\:kea-admin> شرح داده شده است\&. .sp در زمان اجرا، سرورهای DHCP باید برای بارگیری ماژول در بخش \fBhooks\-libraries\fP پیکربندی شوند. سپس باید از دستورالعمل \fBconfig\-databases\fP برای هدایت Kea به بارگیری پیکربندی با استفاده از backend پایگاه‌داده استفاده شود. پیکربندی‌های خاص سرورهای DHCPv4 و DHCPv6 برای CB و همچنین فهرست پارامترهای پیکربندی پشتیبانی‌شده، به‌ترتیب در «Backend پیکربندی در DHCPv4» \%<#\:dhcp4-cb> و «Backend پیکربندی در DHCPv6» \%<#\:dhcp6-cb> یافت می‌شوند. .sp پس از اتمام نصب، می‌توان از API دستورات CB برای پر کردن پایگاه‌داده با اطلاعات پیکربندی Kea استفاده کرد. .SS "اشتراک‌گذاری پیکربندی و برچسب‌های سرور (Configuration Sharing and Server Tags)" .sp پایگاه‌دادهٔ پیکربندی برای ذخیرهٔ اطلاعات پیکربندی چندین سرور Kea طراحی شده است. بسته به مورد استفاده، کل پیکربندی ممکن است میان تمام سرورها به اشتراک گذاشته شود؛ بخش‌هایی از پیکربندی ممکن است توسط چندین سرور به اشتراک گذاشته شده و باقی پیکربندی برای این سرورها متفاوت باشد؛ یا هر سرور ممکن است پیکربندی غیرمشترک مخصوص به خود را داشته باشد. .sp عناصر پیکربندی در پایگاه‌داده با استفاده از \(dqبرچسب‌های سرور\(dq (server tags) به سرورها منتسب می‌شوند. برچسب سرور یک رشتهٔ دلخواه حاوی نام نمونهٔ سرور Kea است. برچسب‌های سرورهای DHCPv4 و DHCPv6 در پایگاه‌داده مستقل هستند، یعنی می‌توان همان برچسب سرور را برای هر دو سرور DHCPv4 و DHCPv6 ایجاد کرد. این مقدار با استفاده از پارامتر \fBserver\-tag\fP در حوزهٔ \fBDhcp4\fP یا \fBDhcp6\fP پیکربندی می‌شود. برچسب سرور فعلی را می‌توان با دستور \fBserver\-tag\-get\fP \%<#\:std-isccmd-server-tag-get> بررسی کرد. .sp تعریف سرور، که شامل برچسب سرور و توضیحات سرور است، باید پیش از ایجاد پیکربندی اختصاصی برای آن سرور، در پایگاه‌دادهٔ پیکربندی ذخیره شود. در مواردی که همهٔ سرورها از پیکربندی یکسانی استفاده می‌کنند، مانند یک جفت سرور که به‌عنوان همتایان دسترسی‌پذیری بالا (High Availability) اجرا می‌شوند، نیازی به پیکربندی برچسب‌های سرور برای این سرورها در پایگاه‌داده نیست. .sp دستوراتی که شامل سرور منطقی \fIall\fP هستند بر تمام سرورهای متصل به پایگاه‌داده اعمال می‌شوند. سرور \fIall\fP را نمی‌توان حذف یا ویرایش کرد، و در نتیجهٔ دستورهای \fBremote\-server4\-get\-all\fP \%<#\:std-isccmd-remote-server4-get-all> و \fBremote\-server6\-get\-all\fP \%<#\:std-isccmd-remote-server6-get-all> در میان سرورهای دیگر بازگردانده نمی‌شود. .sp در بیشتر موارد، هیچ برچسب سروری در پایگاه‌دادهٔ پیکربندی تعریف نشده است؛ همهٔ سرورهای متصل‌شونده، بدون در نظر گرفتن برچسب سروری که استفاده می‌کنند، پیکربندی یکسانی دریافت می‌کنند. برچسب سروری که یک نمونهٔ خاص Kea برای دریافت پیکربندی خود به پایگاه‌داده ارائه می‌دهد، در فایل پیکربندی Kea با استفاده از نگاشت \fIconfig\-control\fP مشخص می‌شود (لطفاً برای جزئیات به «فعال‌سازی Backend پیکربندی» \%<#\:dhcp4-cb-json> و «فعال‌سازی Backend پیکربندی» \%<#\:dhcp6-cb-json> مراجعه کنید). به تمام نمونه‌های Kea که برچسب سرور یکسانی را به پایگاه‌دادهٔ پیکربندی ارائه می‌دهند، پیکربندی یکسانی داده می‌شود. .sp این به انتخاب مدیر سیستم بستگی دارد که چندین نمونهٔ Kea از یک برچسب سرور استفاده کنند یا هر نمونهٔ Kea از برچسب سرور متفاوتی بهره ببرد. هیچ الزامی وجود ندارد که نمونه‌های در حال اجرا بر روی یک ماشین فیزیکی یا مجازی یکسان، از برچسب سرور مشابهی استفاده کنند. حتی امکان پیکربندی سرور Kea بدون انتساب برچسب سرور به آن نیز وجود دارد. در چنین حالتی، به سرور پیکربندیِ مشخص‌شده برای سرورهای \fIall\fP داده خواهد شد. .sp برای تفکیک میان پیکربندی‌های مختلف سرور Kea، فهرستی از برچسب‌های سرور استفاده‌شده توسط سرورها باید در پایگاه‌داده ذخیره شود. برای سرورهای DHCPv4 و DHCPv6، این کار می‌تواند با استفاده از دستورهای \fBremote\-server4\-set\fP \%<#\:std-isccmd-remote-server4-set> و \fBremote\-server6\-set\fP \%<#\:std-isccmd-remote-server6-set> انجام شود. سپس می‌توان از برچسب‌های سرور برای انتساب اطلاعات پیکربندی به سرورها استفاده کرد. با این حال، توجه به این نکته مهم است که برخی از عناصر پیکربندی DHCP ممکن است با چندین برچسب سرور مرتبط شوند (معروف به عناصر \(dqاشتراک‌پذیر\(dq)، در حالی که سایر عناصر پیکربندی ممکن است تنها با یک برچسب سرور مرتبط باشند (عناصر \(dqغیرقابل‌اشتراک\(dq). بخش‌های «Backend پیکربندی در DHCPv4» \%<#\:dhcp4-cb> و «Backend پیکربندی در DHCPv6» \%<#\:dhcp6-cb> عناصر پیکربندی اشتراک‌پذیر و غیرقابل‌اشتراک مختص DHCP را فهرست می‌کنند؛ با این حال، در این بخش تفاوت‌های میان آن‌ها را به اختصار شرح می‌دهیم. .sp یک عنصر پیکربندی اشتراک‌پذیر عنصری است که دارای یک ویژگی منحصربه‌فردِ شناسایی‌کننده بوده و ممکن است تنها یک‌بار در پایگاه‌داده وجود داشته باشد. مثالی از یک عنصر DHCP اشتراک‌پذیر، نمونهٔ یک زیرشبکه (subnet) است: زیرشبکه بخشی از توپولوژی شبکه است و فرض می‌کنیم که هر زیرشبکهٔ خاص تنها می‌تواند یک تعریف در این شبکه داشته باشد. هر زیرشبکه دارای دو شناسهٔ منحصربه‌فرد است: شناسهٔ زیرشبکه و پیشوند زیرشبکه. شناسهٔ زیرشبکه در Kea برای شناسایی یکتای زیرشبکه در شبکه و اتصال آن به سایر عناصر پیکربندی، مثلاً در رزروهای میزبان (host reservations)، استفاده می‌شود. برخی از دستورات ارائه‌شده توسط \fBlibdhcp_cb_cmds.so\fP \%<#\:std-ischooklib-libdhcp_cb_cmds\:.so> امکان دسترسی به اطلاعات زیرشبکه را از طریق شناسهٔ زیرشبکه یا پیشوند فراهم می‌کنند، و استفاده از برچسب سرور را برای دسترسی به زیرشبکه صراحتاً منع می‌نمایند. علت این است که به‌طور کلی، تعریف زیرشبکه به‌جای یک سرور واحد، با چندین سرور مرتبط است. در واقع، حتی ممکن است با هیچ سروری مرتبط نباشد (تخصیص‌نیافته یا unassigned). با این وجود، زیرشبکهٔ تخصیص‌نیافته دارای شناسه و پیشوندی است که می‌توان از آن‌ها برای دسترسی به زیرشبکه استفاده کرد. .sp یک عنصر پیکربندی اشتراک‌پذیر ممکن است با چندین سرور، یک سرور، یا هیچ سروری مرتبط باشد. حذف سروری که با عنصر اشتراک‌پذیر مرتبط است موجب حذف عنصر اشتراک‌پذیر نمی‌شود. این کار صرفاً ارتباطِ سرورِ حذف‌شده را با آن عنصر پاک می‌کند. .sp برخلاف یک عنصر اشتراک‌پذیر، یک عنصر غیرقابل‌اشتراک نباید صراحتاً با بیش از یک سرور مرتبط شود و پس از حذف سرور نباید باقی بماند (نباید بدون تخصیص باقی بماند). یک عنصر غیرقابل‌اشتراک فقط در بافتار (context) سرور وجود دارد. نمونه‌ای از یک عنصر غیرقابل‌اشتراک در DHCP، یک پارامتر سراسری مانند \fIrenew\-timer\fP\& است. تایمر تمدید مقداری است که باید توسط یک سرور خاص و صرفاً همین سرور استفاده شود. سرورهای دیگر ممکن است تایمرهای تمدید مربوط به خود را با مقادیر یکسان یا متفاوتی تنظیم کرده باشند. پارامتر تایمر تمدید فاقد هرگونه شناسهٔ منحصربه‌فردی است که بتوان از طریق آن بدان دسترسی یافت، ویرایشش کرد، یا به شیوهٔ دیگری از آن استفاده نمود. پارامترهای سراسری مانند تایمر تمدید می‌توانند با نام پارامتر و برچسب سروری که برای آن پیکربندی شده‌اند در دسترس قرار گیرند. برای مثال، دستورهای \fBremote\-global\-parameter4\-get\fP \%<#\:std-isccmd-remote-global-parameter4-get> و \fBremote\-global\-parameter6\-get\fP \%<#\:std-isccmd-remote-global-parameter6-get> امکان دریافت مقدار پارامتر سراسری را با نام پارامتر و نام سرور فراهم می‌آورند. دریافت پارامتر سراسری صرفاً بر اساس نام آن (بدون مشخص کردن برچسب سرور) امکان‌پذیر نیست، زیرا ممکن است پارامترهای سراسری متعددی با یک نام مشخص در پایگاه‌داده وجود داشته باشد. .sp هنگامی که سرور مرتبط با یک عنصر پیکربندی غیرقابل‌اشتراک حذف می‌شود، عنصر پیکربندی به‌طور خودکار به همراه سرور از پایگاه‌داده حذف می‌گردد زیرا عنصر غیرقابل‌اشتراک باید همواره به یک سرور (یا سرور منطقی \fIall\fP) تخصیص یافته باشد. .sp اصطلاحات \(dqاشتراک‌پذیر\(dq و \(dqغیرقابل‌اشتراک\(dq تنها برای ارتباطات با سرورهای تعریف‌شده توسط کاربر به‌کار می‌روند؛ تمامی عناصر پیکربندی مرتبط با سرور منطقی \fIall\fP بنا به تعریف، اشتراک‌پذیر هستند. برای مثال: پارامتر \fIrenew\-timer\fP مرتبط با سرورهای \fIall\fP توسط تمامی سرورهای متصل به پایگاه‌داده که تایمرهای تمدید خاص خود را تعریف نکرده‌اند استفاده می‌شود. در یک حالت خاص، زمانی که هیچ‌یک از عناصر پیکربندی با سرورهای تعریف‌شده توسط کاربر مرتبط نباشند، کل پیکربندی موجود در پایگاه‌داده اشتراک‌پذیر است زیرا تمامی بخش‌های آن به سرورهای \fIall\fP تعلق دارند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگام مرتبط کردن عناصر پیکربندی با برچسب‌های سرور مختلف بسیار محتاط باشید. Backend پیکربندی در برابر برخی از پیکربندی‌های نادرست احتمالی که ممکن است ناشی از انتساب‌های اشتباه برچسب‌های سرور باشند، محافظت نمی‌کند. برای مثال: اگر یک شبکهٔ مشترک (shared network) به یک سرور و زیرشبکه‌های متعلق به این شبکهٔ مشترک به سرور دیگری اختصاص داده شوند، سرورها در هنگام تلاش برای دریافت و استفاده از این پیکربندی با خطا مواجه خواهند شد. سروری که زیرشبکه‌ها را واکشی می‌کند آگاه خواهد بود که این زیرشبکه‌ها با شبکهٔ مشترک مرتبط هستند، اما شبکهٔ مشترک توسط این سرور پیدا نخواهد شد زیرا متعلق به آن نیست. در چنین حالتی، هم شبکهٔ مشترک و هم زیرشبکه‌ها باید به مجموعهٔ یکسانی از سرورها اختصاص یابند. .UNINDENT .UNINDENT.SH "مدیریت KEA با KEACTRL (MANAGING KEA WITH KEACTRL)" .SS "نمای کلی (Overview)" .sp اسکریپت شل \fBkeactrl\fP \%<#\:std-iscman-keactrl> راه‌اندازی، خاموش کردن و پیکربندی مجدد سرورهای Kea (شامل \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>، \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> و \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf>) را کنترل می‌کند. این اسکریپت همچنین امکاناتی را برای بررسی وضعیت فعلی سرورها و تعیین فایل‌های پیکربندی در حال استفاده فراهم می‌آورد. .sp ابزار \fBkeactrl\fP \%<#\:std-iscman-keactrl> تنها زمانی در دسترس است که Kea از سورس ساخته شده باشد. هنگام نصب Kea با استفاده از بسته‌های بومی توزیع، اسکریپت‌های بومی \fBsystemd\fP ارائه می‌شوند. برای جزئیات، به بخش Native Packages and systemd مراجعه کنید. .SS "گزینه‌های خط فرمان (Command Line Options)" .sp \fBkeactrl\fP \%<#\:std-iscman-keactrl> به صورت زیر اجرا می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX # keactrl [\-c keactrl\-config\-file] [\-s server[,server,...]] .EE .UNINDENT .UNINDENT .sp آرگومان \fB\fP یکی از دستورات شرح داده شده در Commands است\&. .sp گزینه اختیاری \fB\-c keactrl\-config\-file\fP امکان تعیین یک فایل پیکربندی جایگزین برای \fBkeactrl\fP \%<#\:std-iscman-keactrl> را فراهم می‌کند. (\fB\-\-ctrl\-config\fP مترادفی برای \fB\-c\fP است\&.) در صورت عدم استفاده از \fB\-c\fP، \fBkeactrl\fP \%<#\:std-iscman-keactrl> از فایل پیکربندی پیش‌فرض \fB\(dq[kea\-install\-dir]/etc/kea/keactrl.conf\(dq\fP استفاده می‌کند\&. .sp گزینه اختیاری \fB\-s server[,server,...]\fP سرورهایی را که دستور برای آن‌ها صادر می‌شود مشخص می‌کند. (\fB\-\-server\fP مترادفی برای \fB\-s\fP است\&.) در صورت عدم استفاده، دستور به تمامی سرورهای فعال‌شده در فایل پیکربندی \fBkeactrl\fP \%<#\:std-iscman-keactrl> ارسال می‌شود. اگر چندین سرور مشخص شوند، باید با کاما و بدون فاصله میان آن‌ها از یکدیگر جدا شوند. .SS "فایل پیکربندی \fBkeactrl\fP \%<#\:std-iscman-keactrl>" .sp بسته به نیازمندی‌های مدیر سیستم، ممکن است نیازی به اجرای تمام سرورهای موجود نباشد. فایل پیکربندی \fBkeactrl\fP \%<#\:std-iscman-keactrl> مشخص می‌کند که کدام سرورها فعال و کدام غیرفعال هستند. فایل پیکربندی پیش‌فرض \fB\(dq[kea\-install\-dir]/etc/kea/keactrl.conf\(dq\fP است، اما می‌توان آن را برای هر دستور به صورت جداگانه با استفاده از گزینه \fB\-c\fP بازنویسی کرد. .sp محتویات \fBkeactrl.conf\fP به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX # This is a configuration file for keactrl script which controls # the startup, shutdown, reconfiguration and gathering the status # of the Kea processes. # prefix holds the location where the Kea is installed. prefix=@prefix@ # Location of Kea configuration file. kea_dhcp4_config_file=@sysconfdir@/@PACKAGE@/kea\-dhcp4.conf kea_dhcp6_config_file=@sysconfdir@/@PACKAGE@/kea\-dhcp6.conf kea_dhcp_ddns_config_file=@sysconfdir@/@PACKAGE@/kea\-dhcp\-ddns.conf kea_netconf_config_file=@sysconfdir@/@PACKAGE@/kea\-netconf.conf # Location of Kea binaries. exec_prefix=@exec_prefix@ dhcp4_srv=@sbindir@/kea\-dhcp4 dhcp6_srv=@sbindir@/kea\-dhcp6 dhcp_ddns_srv=@sbindir@/kea\-dhcp\-ddns netconf_srv=@sbindir@/kea\-netconf # Start DHCPv4 server? dhcp4=yes # Start DHCPv6 server? dhcp6=yes # Start DHCP DDNS server? dhcp_ddns=no # Start Netconf? netconf=no # Be verbose? kea_verbose=no .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در مثال بالا، رشته‌هایی به شکل @something@ هنگام نصب Kea با مقادیر مناسب جایگزین می‌شوند. .UNINDENT .UNINDENT .sp تنظیم پارامترهای \fBdhcp4\fP، \fBdhcp6\fP، \fBdhcp_ddns\fP و \fBnetconf\fP روی مقدار \(dqyes\(dq، ابزار \fBkeactrl\fP \%<#\:std-iscman-keactrl> را برای مدیریت (راه‌اندازی، پیکربندی مجدد) تمام سرورها پیکربندی می‌کند، یعنی \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>، \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> و \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf>\&. هنگامی که هر یک از این پارامترها روی \(dqno\(dq تنظیم شود، \fBkeactrl\fP \%<#\:std-iscman-keactrl> سرور مربوطه را در هنگام راه‌اندازی یا پیکربندی مجدد Kea نادیده می‌گیرد. برخی دیمن‌ها (dhcp_ddns و netconf) به‌طور پیش‌فرض غیرفعال هستند. .sp به‌طور پیش‌فرض، سرورهای Kea که توسط \fBkeactrl\fP \%<#\:std-iscman-keactrl> مدیریت می‌شوند در مسیر \fB\(dq[kea\-install\-dir]/sbin\(dq\fP قرار دارند\&. این مسیر برای بیشتر نصب‌ها مناسب است. اگر نیاز به تغییر مکان پیش‌فرض باشد، باید مسیرهای مشخص‌شده در پارامترهای \fBdhcp4_srv\fP، \fBdhcp6_srv\fP، \fBdhcp_ddns_srv\fP و \fBnetconf_srv\fP ویرایش شوند. .sp پارامتر \fBkea_verbose\fP میزان پرگویی گزارش‌ها را برای سرورهای در حال راه‌اندازی مشخص می‌کند. هنگامی که \fBkea_verbose\fP روی \fByes\fP تنظیم شود، سطح گزارش‌گیری سرور روی DEBUG قرار می‌گیرد. تغییر سطح اهمیت گزارش‌گیری در فایل پیکربندی، همان‌طور که در Logging \%<#\:logging> شرح داده شده است، تا زمانی که \fBkea_verbose\fP روی \(dqyes\(dq تنظیم باشد هیچ اثری نخواهد داشت. تنظیم آن روی \(dqno\(dq باعث می‌شود سرور از سطوح گزارش‌گیری مشخص‌شده در فایل پیکربندی Kea استفاده کند. اگر هیچ پیکربندی برای گزارش‌گیری تعیین نشده باشد، تنظیمات پیش‌فرض به کار گرفته می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 میزان پرگویی گزارش‌ها هنگام راه‌اندازی سرور تنظیم می‌شود. پس از راه‌اندازی، این میزان تنها با متوقف کردن سرور و اجرای مجدد آن با مقدار جدید پارامتر \fBkea_verbose\fP قابل تغییر است. .UNINDENT .UNINDENT.SS "دستورها (Commands)" .sp دستورهای زیر توسط \fBkeactrl\fP \%<#\:std-iscman-keactrl> پشتیبانی می‌شوند: .INDENT 0.0 .IP \(bu 2 \fBstart\fP \- سرورهای انتخاب‌شده را راه‌اندازی می‌کند. .IP \(bu 2 \fBstop\fP \- تمام سرورهای در حال اجرا را متوقف می‌کند. .IP \(bu 2 \fBreload\fP \- با ارسال سیگنال SIGHUP به سرورهای انتخاب‌شده، پیکربندی مجدد آن‌ها را فعال می‌کند. .IP \(bu 2 \fBstatus\fP \- وضعیت سرورها (فعال یا غیرفعال) و نام فایل‌های پیکربندی در حال استفاده را بازمی‌گرداند. .IP \(bu 2 \fBversion\fP \- نسخه خود ابزار \fBkeactrl\fP \%<#\:std-iscman-keactrl> را به همراه نسخه دیمن‌های Kea چاپ می‌کند. .UNINDENT .sp خروجی معمول \fBkeactrl\fP \%<#\:std-iscman-keactrl> هنگام راه‌اندازی سرورها شبیه به مورد زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX $ keactrl start INFO/keactrl: Starting kea\-dhcp4 \-c /usr/local/etc/kea/kea\-dhcp4.conf \-d INFO/keactrl: Starting kea\-dhcp6 \-c /usr/local/etc/kea/kea\-dhcp6.conf \-d INFO/keactrl: Starting kea\-dhcp\-ddns \-c /usr/local/etc/kea/kea\-dhcp\-ddns.conf \-d INFO/keactrl: Starting kea\-netconf \-c /usr/local/etc/kea/kea\-netconf.conf \-d .EE .UNINDENT .UNINDENT .sp سرورهای Kea هنگام راه‌اندازی، فایل‌های PID ایجاد می‌کنند. این فایل‌ها توسط \fBkeactrl\fP \%<#\:std-iscman-keactrl> برای تعیین اینکه آیا یک سرور مشخص در حال اجرا است یا خیر استفاده می‌شوند. اگر هنگام اجرای دستور start، یک یا چند سرور در حال اجرا باشند، خروجی مشابه زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX $ keactrl start INFO/keactrl: kea\-dhcp4 appears to be running, see: PID 10918, PID file: /usr/local/var/run/kea/kea.kea\-dhcp4.pid. INFO/keactrl: kea\-dhcp6 appears to be running, see: PID 10924, PID file: /usr/local/var/run/kea/kea.kea\-dhcp6.pid. INFO/keactrl: kea\-dhcp\-ddns appears to be running, see: PID 10930, PID file: /usr/local/var/run/kea/kea.kea\-dhcp\-ddns.pid. INFO/keactrl: kea\-netconf appears to be running, see: PID 10123, PID file: /usr/local/var/run/kea/kea.kea\-netconf.pid. .EE .UNINDENT .UNINDENT .sp در طول خاموش شدن‌های عادی، این فایل‌های PID حذف می‌شوند؛ با این حال، ممکن است پس از فروپاشی سیستم (crash) به عنوان بقایا باقی بمانند. این امکان وجود دارد، اگرچه بسیار بعید است، که پس از راه‌اندازی مجدد سیستم، PIDهایی که این فایل‌ها شامل می‌شوند در واقع به فرآیندهای نامرتبط با Kea اشاره کنند. این وضعیت باعث می‌شود \fBkeactrl\fP \%<#\:std-iscman-keactrl> تشخیص دهد که سرورها در حال اجرا هستند، در حالی که در واقعیت این‌گونه نیست. در چنین مواردی فایل‌های PID فهرست‌شده در خروجی \fBkeactrl\fP \%<#\:std-iscman-keactrl> باید به صورت دستی حذف شوند. .sp دستور زیر تمام سرورها را متوقف می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX $ keactrl stop INFO/keactrl: Stopping kea\-dhcp4... INFO/keactrl: Stopping kea\-dhcp6... INFO/keactrl: Stopping kea\-dhcp\-ddns... INFO/keactrl: Stopping kea\-netconf... .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که دستور \fBstop\fP تلاش می‌کند تمام سرورها را صرف‌نظر از اینکه در \fBkeactrl.conf\fP \(dqفعال\(dq (enabled) شده‌اند یا خیر متوقف کند. اگر هر یک از سرورها در حال اجرا نباشند، یک پیام اطلاعاتی مانند خروجی دستور \fBstop\fP در زیر نمایش داده می‌شود. .INDENT 0.0 .INDENT 3.5 .sp .EX $ keactrl stop INFO/keactrl: kea\-dhcp4 isn\(aqt running. INFO/keactrl: kea\-dhcp6 isn\(aqt running. INFO/keactrl: kea\-dhcp\-ddns isn\(aqt running. INFO/keactrl: kea\-netconf isn\(aqt running. .EE .UNINDENT .UNINDENT .sp همان‌طور که پیش‌تر اشاره شد، پیکربندی مجدد هر سرور Kea با سیگنال SIGHUP آغاز می‌شود. دستور \fBreload\fP سیگنال SIGHUP را به هر سروری که در فایل پیکربندی \fBkeactrl\fP \%<#\:std-iscman-keactrl> فعال شده باشد و در حال حاضر در حال اجرا باشد ارسال می‌کند. هنگامی که یک سرور سیگنال SIGHUP را دریافت می‌کند، فایل پیکربندی خود را دوباره می‌خواند و در صورتی که پیکربندی جدید معتبر باشد، از پیکربندی جدید استفاده می‌کند. اگر پیکربندی جدید نامعتبر باشد، سرور پیکربندی فعلی خود را حفظ می‌کند؛ با این حال، در برخی موارد یک پیام خطای مهلک ثبت می‌شود که نشان می‌دهد سرور دیگر هیچ سرویسی ارائه نمی‌دهد: در این حالت یک پیکربندی سالم باید در اسرع وقت بارگذاری شود. .sp یک بارگذاری مجدد به صورت زیر اجرا می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX $ keactrl reload INFO/keactrl: Reloading kea\-dhcp4... INFO/keactrl: Reloading kea\-dhcp6... INFO/keactrl: Reloading kea\-dhcp\-ddns... .EE .UNINDENT .UNINDENT .sp اگر هر یک از سرورها در حال اجرا نباشند، یک پیام اطلاعاتی مانند خروجی دستور \fBreload\fP در زیر نمایش داده می‌شود. \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> از سیگنال SIGHUP پشتیبانی نمی‌کند. در صورتی که پیکربندی آن تغییر کرده است، لطفاً آن را متوقف کرده و مجدداً راه‌اندازی کنید تا تغییرات اعمال شوند. .INDENT 0.0 .INDENT 3.5 .sp .EX $ keactrl stop INFO/keactrl: kea\-dhcp4 isn\(aqt running. INFO/keactrl: kea\-dhcp6 isn\(aqt running. INFO/keactrl: kea\-dhcp\-ddns isn\(aqt running. INFO/keactrl: kea\-netconf isn\(aqt running. .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 ویژگی NETCONF یک قابلیت اختیاری است که به صورت پیش‌فرض غیرفعال است و می‌تواند در زمان کامپایل فعال شود. اگر Kea بدون پشتیبانی از NETCONF کامپایل شده باشد، \fBkeactrl\fP \%<#\:std-iscman-keactrl> اطلاعاتی درباره آن ارائه نمی‌دهد. ورودی‌های NETCONF همچنان در فایل \fBkeactrl.conf\fP موجود هستند، اما وضعیت NETCONF نمایش داده نمی‌شود و سایر دستورها آن را نادیده می‌گیرند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر \fBkeactrl\fP \%<#\:std-iscman-keactrl> در هنگام راه‌اندازی یا پیکربندی مجدد سرور، خطاهای پیکربندی را گزارش نمی‌کند. برای بررسی اینکه آیا پیکربندی سرور موفقیت‌آمیز بوده است یا خیر، لاگ Kea باید برای یافتن خطاها بررسی شود. به صورت پیش‌فرض، لاگ‌ها در فایل \fIsyslog\fP نوشته می‌شوند. .UNINDENT .UNINDENT .sp گاهی اوقات بررسی اینکه کدام سرورها در حال اجرا هستند مفید است. دستور \fBstatus\fP این موضوع را گزارش می‌دهد و خروجی نمونه آن به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX $ keactrl status DHCPv4 server: active DHCPv6 server: inactive DHCP DDNS: active Netconf agent: inactive Kea configuration file: /usr/local/etc/kea/kea.conf Kea DHCPv4 configuration file: /usr/local/etc/kea/kea\-dhcp4.conf Kea DHCPv6 configuration file: /usr/local/etc/kea/kea\-dhcp6.conf Kea DHCP DDNS configuration file: /usr/local/etc/kea/kea\-dhcp\-ddns.conf Kea Netconf configuration file: /usr/local/etc/kea/kea\-netconf.conf keactrl configuration file: /usr/local/etc/kea/keactrl.conf .EE .UNINDENT .UNINDENT .sp دستور \fBkeactrl status\fP قابلیت‌های گزارش‌دهی پایه‌ای را ارائه می‌دهد. برای به دست آوردن دیدگاه جامع‌تر نسبت به سلامت و وضعیت Kea، استقرار Stork را مد نظر قرار دهید. برای اطلاعات بیشتر، به Monitoring Kea With Stork \%<#\:stork>\& مراجعه کنید..SS "بازنویسی انتخاب سرور (Overriding the Server Selection)" .sp گزینه اختیاری \fB\-s\fP امکان انتخاب سرور(هایی) را فراهم می‌کند که دستور \fBkeactrl\fP \%<#\:std-iscman-keactrl> برای آن‌ها صادر می‌شود. برای نمونه، دستور زیر به \fBkeactrl\fP \%<#\:std-iscman-keactrl> اعلام می‌کند که سرورهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> را متوقف کرده و اجازه دهد \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> در حال اجرا باقی بماند: .INDENT 0.0 .INDENT 3.5 .sp .EX $ keactrl stop \-s dhcp4,dhcp6 .EE .UNINDENT .UNINDENT .sp به‌طور مشابه، دستور زیر تنها سرورهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> را اجرا می‌کند، اما نه \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>\&. .INDENT 0.0 .INDENT 3.5 .sp .EX $ keactrl start \-s dhcp4,dhcp_ddns .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که رفتار گزینه \fB\-s\fP در دستورهای \fBstart\fP و \fBreload\fP با رفتار آن در دستور \fBstop\fP متفاوت است. در دستورهای \fBstart\fP و \fBreload\fP، برنامه \fBkeactrl\fP \%<#\:std-iscman-keactrl> بررسی می‌کند که آیا سرورهای ارائه‌شده به عنوان پارامتر به گزینه \fB\-s\fP در فایل پیکربندی \fBkeactrl\fP \%<#\:std-iscman-keactrl> فعال شده‌اند یا خیر؛ در غیر این صورت، سرور نادیده گرفته می‌شود. اما برای \fBstop\fP، این بررسی انجام نمی‌شود؛ دستور بدون در نظر گرفتن اینکه سرورها در فایل فعال شده باشند یا خیر، بر روی تمام سرورهای فهرست‌شده اعمال می‌گردد. .sp کلیدواژه‌های زیر می‌توانند با گزینه خط فرمان \fB\-s\fP استفاده شوند: .INDENT 0.0 .IP \(bu 2 \fBdhcp4\fP برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>\&. .IP \(bu 2 \fBdhcp6\fP برای \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>\&. .IP \(bu 2 \fBdhcp_ddns\fP برای \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>\&. .IP \(bu 2 \fBnetconf\fP برای \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf>\&. .IP \(bu 2 \fBall\fP برای همه سرورها (پیش‌فرض). .UNINDENT .SS "بسته‌های بومی و \fBsystemd\fP (Native Packages and \fBsystemd\fP)" .sp اسکریپت \fBkeactrl\fP \%<#\:std-iscman-keactrl> برای کمک به مدیریت فرایندهای Kea توسعه یافته است. با این حال، تمامی سیستم‌عامل‌های امروزی اسکریپت‌های مدیریت فرایند اختصاصی خود را دارند، مانند \fBsystemd\fP\&. به‌طور کلی، توصیه می‌شود از این اسکریپت‌های بومی استفاده شود، زیرا دارای چندین مزیت هستند. اسکریپت‌های \fBsystemd\fP فرایندها را به روشی یکپارچه مدیریت می‌کنند، بنابراین با Kea مشابه با یک سرور HTTP یا سرور ایمیل رفتار می‌شود. دوم و مهم‌تر از آن، \fBsystemd\fP امکان تعریف وابستگی‌ها بین سرویس‌ها را فراهم می‌کند. برای نمونه، به‌راحتی می‌توان مشخص کرد که سرور Kea تا زمانی که رابط‌های شبکه عملیاتی نشده‌اند شروع به کار نکند. استفاده از اسکریپت‌های بومی مزایای دیگری نیز دارد، مانند امکان فعال‌سازی یا غیرفعال‌سازی سرویس‌ها با استفاده از دستورها، و قابلیت اجرای موقت یک سرویس غیرفعال‌شده. .sp بنابراین، توصیه می‌شود در صورت دردسترس بودن، از دستورهای \fBsystemctl\fP استفاده شود. بسته‌های بومی Kea اسکریپت \fBkeactrl\fP \%<#\:std-iscman-keactrl> را ارائه نمی‌دهند؛ در عوض تعاریف سرویس \fBsystemctl\fP ارائه شده‌اند. برای جزئیات به مستندات سیستم مراجعه کنید. .sp به‌طور خلاصه، در اینجا نمونه دستورهایی برای بررسی وضعیت، آغاز، توقف، و راه‌اندازی دوباره دیمن‌های مختلف Kea آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX # systemctl start kea\-dhcp4 # systemctl stop kea\-dhcp6 # systemctl restart kea\-dhcp\-ddns .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که نام سرویس‌ها ممکن است در توزیع‌های مختلف لینوکس کمی تفاوت داشته باشد؛ به‌طور کلی، ما از قواعد نام‌گذاری بسته‌های شخص ثالث پیروی کرده‌ایم. به‌ویژه، ممکن است در برخی سیستم‌ها پیشوند \fIisc\-\fP وجود نداشته باشد. .SH "سرور DHCPV4 (THE DHCPV4 SERVER)" .SS "راه‌اندازی و توقف سرور DHCPv4 (Starting and Stopping the DHCPv4 Server)" .sp توصیه می‌شود که سرور Kea DHCPv4 با استفاده از \fBkeactrl\fP \%<#\:std-iscman-keactrl> آغاز و متوقف شود (که در «مدیریت Kea با keactrl» \%<#\:keactrl> توضیح داده شده است)؛ با این حال، اجرای مستقیم سرور از طریق دستور \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> نیز امکان‌پذیر است، که سوئیچ‌های خط فرمان زیر را می‌پذیرد: .INDENT 0.0 .IP \(bu 2 \fB\-c file\fP \- فایل پیکربندی را مشخص می‌کند. این تنها سوئیچ اجباری است. .IP \(bu 2 \fB\-d\fP \- مشخص می‌کند که آیا ثبت وقایع سرور باید به حالت اشکال‌زدایی/پُرگویی تغییر یابد یا خیر. در حالت پرگویی، سطح شدت ثبت وقایع و debuglevel تعیین‌شده در فایل پیکربندی نادیده گرفته می‌شوند؛ شدت \(dqdebug\(dq و بیشترین debuglevel (عدد 99) فرض می‌شوند. این پرچم برای تغییر موقت سرور به حداکثر سطح گزارش‌دهی، مثلاً هنگام اشکال‌زدایی، مناسب است. .IP \(bu 2 \fB\-p server\-port\fP \- پورت محلی UDP را که سرور روی آن گوش می‌دهد مشخص می‌کند. این گزینه فقط در حین آزمایش مفید است، زیرا یک سرور DHCPv4 که روی پورت‌هایی غیر از پورت‌های استاندارد گوش می‌دهد، قادر به پردازش پرس‌وجوهای معمول DHCPv4 نخواهد بود. .IP \(bu 2 \fB\-P client\-port\fP \- پورت دوردست UDP را مشخص می‌کند که سرور تمام پاسخ‌ها را به آن ارسال می‌کند. این گزینه تنها در حین آزمایش کاربرد دارد، زیرا یک سرور DHCPv4 که پاسخ‌ها را به پورت‌هایی غیر از پورت‌های استاندارد ارسال می‌کند، قادر به مدیریت پرس‌وجوهای معمول DHCPv4 نخواهد بود. .IP \(bu 2 \fB\-t file\fP \- یک فایل پیکربندی را برای آزمایش مشخص می‌کند. \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> آن را بارگذاری کرده، صحت آن را بررسی نموده و خارج می‌شود. در حین آزمایش، پیام‌های گزارش در خروجی استاندارد و پیام‌های خطا در خطای استاندارد چاپ می‌شوند. نتیجه آزمایش از طریق وضعیت خروج گزارش می‌شود (0 = پیکربندی درست به نظر می‌رسد، 1 = خطا رخ داده است). این بررسی جامع نیست؛ بررسی‌های مشخصی تنها هنگام اجرای زنده سرور امکان‌پذیر هستند. .IP \(bu 2 \fB\-T file\fP \- یک فایل پیکربندی را برای آزمایش مشخص می‌کند. \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> آن را بارگذاری کرده، بررسی می‌کند و خارج می‌شود. این گزینه بررسی‌های بیشتری فراتر از آنچه \fB\-t\fP ارائه می‌دهد انجام می‌دهد، مانند برقراری اتصال‌های پایگاه‌داده (برای lease backend، پیشانه host reservations، پیشانه configuration و پیشانه forensic logging)، بارگذاری کتابخانه‌های قلاب (hook)، تجزیه پیکربندی‌های کتابخانه قلاب و غیره. این گزینه سوکت‌های UNIX یا TCP/UDP را باز نمی‌کند، فایل‌ها را قفل نمی‌کند، و همچنین فایل‌ها را باز نکرده یا دوره‌ای جایگزین (rotate) نمی‌کند، چرا که هرکدام از این اقدامات می‌تواند با یک فرایند در حال اجرا روی همان ماشین تداخل داشته باشد. .IP \(bu 2 \fB\-v\fP \- نسخه Kea را نمایش داده و خارج می‌شود. .IP \(bu 2 \fB\-V\fP \- نسخه تفصیلی Kea را به همراه پارامترهای اضافی نمایش داده و خارج می‌شود. این فهرست شامل نسخه‌های کتابخانه‌هایی است که به‌طور پویا با Kea پیوند خورده‌اند. .IP \(bu 2 \fB\-W\fP \- گزارش پیکربندی Kea را نمایش داده و خارج می‌شود. این گزارش رونوشتی از فایل \fBconfig.report\fP است که توسط \fBmeson setup\fP تولید شده؛ این گزارش در فایل اجرایی باینری تعبیه شده است. .sp محتویات فایل \fBconfig.report\fP را همچنین می‌توان با بررسی برخی کتابخانه‌ها در درخت نصب یا در درخت کد منبع به دست آورد. .INDENT 2.0 .INDENT 3.5 .sp .EX # from installation using libkea\-process.so $ strings ${prefix}/lib/libkea\-process.so | sed \-n \(aqs/;;;; //p\(aq # from sources using libkea\-process.so $ strings src/lib/process/.libs/libkea\-process.so | sed \-n \(aqs/;;;; //p\(aq # from sources using libkea\-process.a $ strings src/lib/process/.libs/libkea\-process.a | sed \-n \(aqs/;;;; //p\(aq # from sources using libcfgrpt.a $ strings src/lib/process/cfgrpt/.libs/libcfgrpt.a | sed \-n \(aqs/;;;; //p\(aq .EE .UNINDENT .UNINDENT .IP \(bu 2 \fB\-X\fP \- از نسخه Kea 3.0 به بعد، محدودیت‌های امنیتی را غیرفعال می‌کند. سرور همچنان موارد نقض را بررسی می‌کند، اما در صورت یافتن آن‌ها به جای متوقف شدن با خطا، هشدارهایی صادر خواهد کرد. لطفاً برای جزئیات به «بررسی خط‌مشی امنیتی زمان اجرای Kea» \%<#\:sec-kea-runtime-security-policy-checking> مراجعه کنید. .UNINDENT .sp هنگام راه‌اندازی، سرور رابط‌های شبکه موجود را شناسایی کرده و تلاش می‌کند سوکت‌های UDP را روی تمام رابط‌های فهرست‌شده در فایل پیکربندی باز کند. از آنجا که سرور DHCPv4 پورت‌های ممتاز (privileged) را باز می‌کند، به دسترسی ریشه (root) نیاز دارد؛ این دیمن باید توسط کاربر ریشه اجرا شود. .sp در طول راه‌اندازی، سرور تلاش می‌کند یک فایل PID به فرم \fB[pidfile_dir]/[conf name].kea\-dhcp4.pid\fP ایجاد کند که در آن: .INDENT 0.0 .IP \(bu 2 \fBpidfile_dir\fP \- برابر است با \fB[prefix]/[localstatedir]/run/kea\fP که در آن \fBprefix\fP و \fBlocalstatedir\fP مقادیری هستند که با استفاده از \fB\-\-prefix\fP و \fB\-\-localstatedir\fP به meson setup منتقل شده‌اند و به‌طور پیش‌فرض به ترتیب \fB/usr/local\fP و \fBvar\fP هستند. بنابراین کل مسیر \fBpidfile_dir\fP به‌طور پیش‌فرض برابر با \fB/usr/local/var\fP است\&. توجه داشته باشید که این مقدار ممکن است در زمان اجرا با تنظیم متغیر محیطی \fBKEA_PIDFILE_DIR\fP که اساساً برای اهداف آزمایشی در نظر گرفته شده، بازنویسی شود. .IP \(bu 2 \fBconf name\fP: نام فایل پیکربندی که برای راه‌اندازی سرور استفاده شده است، بدون تمام مسیرهای قبل از آن و پسوند فایل. برای مثال، به ازای یک نام مسیر مانند \fB/usr/local/etc/kea/myconf.txt\fP، بخش استفاده‌شده \fBmyconf\fP خواهد بود\&. .UNINDENT .sp اگر این فایل از قبل وجود داشته باشد و شامل PID یک فرایند در حال اجرا باشد، سرور یک پیام گزارش \fBDHCP4_ALREADY_RUNNING\fP صادر کرده و خارج می‌شود. این احتمال وجود دارد، هرچند بعید، که فایل باقی‌مانده از یک فروپاشی سیستم (system crash) باشد و فرایندی که PID متعلق به آن است ارتباطی به Kea نداشته باشد. در چنین حالتی، حذف دستی فایل PID ضروری خواهد بود. .sp سرور را می‌توان با استفاده از دستور \fBkill\fP متوقف کرد. هنگام اجرا در یک کنسول، سرور همچنین می‌تواند با فشردن Ctrl\-c متوقف شود. Kea این ترکیب کلید را شناسایی کرده و به‌صورت روان و تمیز خاموش می‌شود. .sp پیکربندی مجدد هر سرور Kea با دریافت سیگنال SIGHUP آغاز می‌شود. هنگامی که یک سرور سیگنال SIGHUP را دریافت می‌کند، فایل پیکربندی خود را دوباره می‌خواند و اگر پیکربندی جدید معتبر باشد، از آن استفاده می‌کند. چنانچه مشخص شود پیکربندی جدید نامعتبر است، سرور پیکربندی فعلی خود را حفظ می‌کند؛ با این حال، در برخی موارد یک پیام خطای مهلک ثبت می‌شود که نشان می‌دهد سرور دیگر هیچ سرویسی ارائه نمی‌دهد: در این صورت باید یک پیکربندی سالم در اسرع وقت بارگذاری شود..SS پیکربندی سرور DHCPv4 .SS مقدمه .sp این بخش نحوهٔ پیکربندی سرور DHCPv4 مربوط به Kea را با استفاده از یک فایل پیکربندی شرح می‌دهد. .sp پیش از راه‌اندازی DHCPv4، باید فایل پیکربندی آن ایجاد شود. پیکربندی پایه به شرح زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { # DHCPv4 configuration starts on the next line \(dqDhcp4\(dq: { # First we set up global values \(dqvalid\-lifetime\(dq: 4000, \(dqrenew\-timer\(dq: 1000, \(dqrebind\-timer\(dq: 2000, # Next we set up the interfaces to be used by the server. \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth0\(dq ] }, # And we specify the type of lease database \(dqlease\-database\(dq: { \(dqtype\(dq: \(dqmemfile\(dq, \(dqpersist\(dq: true, \(dqname\(dq: \(dq/var/lib/kea/dhcp4.leases\(dq }, # Finally, we list the subnets from which we will be leasing addresses. \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.200\(dq } ] } ] # DHCPv4 configuration ends with the next line } } .EE .UNINDENT .UNINDENT .sp بندهای زیر پیش‌نمایشی اجمالی از پارامترهای موجود در مثال بالا به همراه قالب آن‌ها ارائه می‌دهند. بخش‌های بعدی این فصل، این پارامترها و پارامترهای دیگر را با جزئیات بسیار بیشتری بررسی می‌کنند. .sp خطوطی که با هش (#) آغاز می‌شوند، توضیح (کامنت) هستند و سرور آن‌ها را نادیده می‌گیرد؛ آن‌ها به هیچ شکلی بر عملکرد آن اثر نمی‌گذارند. .sp پیکربندی در خط نخست با براکت مجعد بازشوندهٔ اولیه (یا آکولاد باز) شروع می‌شود. هر پیکربندی باید شامل شیئی باشد که پیکربندی ماژول Kea به‌کارگیرندهٔ آن را مشخص کند. در مثال بالا، این شیء \fBDhcp4\fP نام دارد\&. .sp پیکربندی \fBDhcp4\fP با خط \fB\(dqDhcp4\(dq: {\fP آغاز شده و با آکولاد بستهٔ متناظر آن (در مثال بالا، آکولاد پس از آخرین توضیح) به پایان می‌رسد. هر آنچه میان این خطوط تعریف شده باشد، پیکربندی \fBDhcp4\fP به شمار می‌آید. .sp به‌طور کلی، ترتیبی که این پارامترها درج می‌شوند اهمیتی ندارد، اما دو نکته وجود دارد. نکتهٔ نخست این است که فایل پیکربندی باید یک JSON خوش‌ساخت (well\-formed) باشد؛ بدین معنا که پارامترها برای هر حوزهٔ (scope) معین باید با کاما از هم جدا شوند، و نباید بعد از آخرین پارامتر کامایی قرار گیرد. هنگام مرتب‌سازی مجدد یک فایل پیکربندی، انتقال یک پارامتر به آخرین جایگاه در یک حوزه یا خارج کردن آن از آخرین جایگاه ممکن است نیازمند جابه‌جایی کاما نیز باشد. نکتهٔ دوم این است که تکرار چندین‌بارهٔ یک پارامتر، گرچه در ساختار JSON مجاز است، اما نامعمول می‌باشد. در صورت وقوع این اتفاق، آخرین تکرار یک پارامتر معین در یک حوزهٔ خاص استفاده می‌شود، در حالی که تمامی موارد پیشین نادیده گرفته می‌شوند. بعید است این موضوع سبب سردرگمی شود، چرا که در عمل هیچ دلیلی برای نگهداری چندین نسخه از یک پارامتر یکسان در فایل پیکربندی وجود ندارد. .sp چند مؤلفهٔ نخست پیکربندی DHCPv4 برخی پارامترهای سراسری (global) را تعریف می‌کنند. \fBvalid\-lifetime\fP تعیین می‌کند نشانی‌های (اجاره‌های) واگذارشده توسط سرور تا چه مدت معتبر هستند؛ حالت پیش‌فرض این است که یک کلاینت مجاز باشد از یک نشانی مشخص برای ۴۰۰۰ ثانیه استفاده کند. (توجه داشته باشید که اعداد صحیح به همان صورت، بدون هیچ‌گونه گیومه در اطرافشان، مشخص می‌شوند.) \fBrenew\-timer\fP و \fBrebind\-timer\fP مقادیری (همچنین به ثانیه) هستند که زمان‌سنج‌های T1 و T2 را تعریف می‌کنند؛ این زمان‌سنج‌ها زمان آغاز فرایندهای تمدید (renewal) و اتصال مجدد (rebind) توسط کلاینت را کنترل می‌کنند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 طول‌عمر معتبر اجاره به‌صورت یک سه‌تایی با مقادیر کمینه، پیش‌فرض، و بیشینه با استفاده از مدخل‌های پیکربندی \fBmin\-valid\-lifetime\fP، \fBvalid\-lifetime\fP و \fBmax\-valid\-lifetime\fP بیان می‌شود\&. از نسخهٔ Kea 1.9.5 به بعد، این مقادیر می‌توانند در کلاس‌های کلاینت مشخص شوند. روالی که سرور برای انتخاب مقدار طول‌عمر مورد استفاده به کار می‌برد به شرح زیر است: .sp اگر پرس‌وجوی کلاینت یک پرس‌وجوی BOOTP باشد، سرور همواره از زمان اجارهٔ نامحدود (مانند 0xffffffff) استفاده می‌کند. در غیر این صورت، سرور باید با جستجو در تمامی کلاس‌های اختصاص‌یافته به پرس‌وجو و سپس زیرشبکهٔ انتخاب‌شده برای پرس‌وجو، تعیین کند کدام سه‌تاییِ پیکربندی‌شده باید استفاده شود. .sp کلاس‌ها به همان ترتیبی که به پرس‌وجو اختصاص یافته‌اند جستجو می‌شوند؛ سرور از سه‌تاییِ نخستین کلاسی که آن را مشخص کرده باشد استفاده می‌کند. اگر هیچ کلاسی این سه‌تایی را مشخص نکرده باشد، سرور از سه‌تایی مشخص‌شده توسط زیرشبکهٔ انتخاب‌شده برای کلاینت استفاده می‌کند. اگر زیرشبکه صراحتاً آن را مشخص نکرده باشد، سرور در مرحلهٔ بعد shared\-network مربوط به زیرشبکه را (در صورت وجود) بررسی می‌کند، سپس به دنبال مشخصهٔ سراسری می‌گردد، و در نهایت مقدار پیش‌فرض سراسری را به کار می‌گیرد. .sp اگر کلاینت مقدار طول‌عمری را از طریق DHCP option 51 درخواست کرده باشد، آن‌گاه مقدار طول‌عمر استفاده‌شده همان مقدار درخواستی خواهد بود که توسط سه‌تاییِ پیکربندی‌شده محدود می‌شود. به عبارت دیگر، اگر طول‌عمر درخواستی کمتر از کمینهٔ پیکربندی‌شده باشد، کمینهٔ پیکربندی‌شده استفاده می‌شود؛ اگر بیشتر از بیشینهٔ پیکربندی‌شده باشد، بیشینهٔ پیکربندی‌شده به کار می‌رود. اگر کلاینت مقداری را درخواست نکرده باشد، مقدار طول‌عمر استفاده‌شده، مقدار پیش‌فرض سه‌تایی خواهد بود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هر دو پارامتر \fBrenew\-timer\fP و \fBrebind\-timer\fP اختیاری هستند. سرور تنها در صورتی \fBrebind\-timer\fP را از طریق DHCPv4 option code 59 به کلاینت ارسال می‌کند که کمتر از \fBvalid\-lifetime\fP باشد؛ و تنها در صورتی \fBrenew\-timer\fP را از طریق DHCPv4 option code 58 ارسال می‌کند که کمتر از \fBrebind\-timer\fP باشد (یا کمتر از \fBvalid\-lifetime\fP اگر \fBrebind\-timer\fP مشخص نشده باشد). در غیاب آن‌ها، کلاینت باید مقادیر زمان‌سنج‌های T1 و T2 را بر اساس RFC 2131 \%\& انتخاب کند. برای جزئیات بیشتر در مورد تولید T1 و T2، به بخش Sending T1 (Option 58) and T2 (Option 59) مراجعه کنید. .UNINDENT .UNINDENT .sp نگاشت \fBinterfaces\-config\fP رابط‌های شبکه‌ای را مشخص می‌کند که سرور باید روی آن‌ها به پیام‌های DHCP گوش دهد. پارامتر \fBinterfaces\fP فهرستی از رابط‌های شبکه را که سرور باید روی آن‌ها شنود کند مشخص می‌سازد. فهرست‌ها با براکت‌های مربعی (قلاب) باز و بسته می‌شوند و عناصر با کاما از هم جدا می‌گردند. برای شنود روی دو رابط، عنصر \fBinterfaces\-config\fP باید بدین صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth0\(dq, \(dqeth1\(dq ] }, \&... } .EE .UNINDENT .UNINDENT .sp خطوط بعدی پایگاه‌دادهٔ اجاره (lease database) را تعریف می‌کنند؛ محلی که سرور اطلاعات اجاره‌های خود را در آن ذخیره می‌کند. این مثال ویژه به سرور دستور می‌دهد از memfile استفاده کند که ساده‌ترین و سریع‌ترین backend پایگاه‌داده است. این بک‌اند از یک پایگاه‌داده در حافظه (in\-memory) استفاده کرده و اجاره‌ها را روی دیسک در یک فایل CSV (مقادیر جداشده با کاما) ذخیره می‌کند. این یک مثال پیکربندی بسیار ساده است؛ معمولاً پیکربندی پایگاه‌دادهٔ اجاره جامع‌تر بوده و دربردارندهٔ پارامترهای اضافی است. توجه داشته باشید که \fBlease\-database\fP یک شیء است و یک حوزهٔ جدید را با استفاده از یک آکولاد باز آغاز می‌کند. پارامترهای آن (در این مثال تنها یک مورد: \fBtype\fP) در ادامه می‌آیند. اگر بیش از یکی وجود داشت، با کاما از هم جدا می‌شدند. این حوزه با یک آکولاد بسته خاتمه می‌یابد. از آنجا که پارامترهای بیشتری برای تعریف \fBDhcp4\fP به دنبال آن می‌آیند، یک کامای پایانی وجود دارد. .sp در نهایت، باید فهرستی از زیرشبکه‌های IPv4 را تعریف کنیم. این مهم‌ترین ساختار پیکربندی DHCPv4 است، چرا که سرور از این اطلاعات برای پردازش درخواست‌های کلاینت‌ها استفاده می‌کند. این ساختار تمام زیرشبکه‌هایی را که انتظار می‌رود سرور درخواست‌های DHCP را از آن‌ها دریافت کند، تعریف می‌کند. زیرشبکه‌ها با پارامتر \fBsubnet4\fP مشخص می‌شوند. این پارامتر یک فهرست است، بنابراین با براکت‌های مربعی باز و بسته می‌شود. هر تعریف زیرشبکه در فهرست، دارای چندین مشخصهٔ مرتبط با خود است، بنابراین یک ساختار بوده و با آکولاد باز و بسته می‌شود. در کمترین حالت، یک تعریف زیرشبکه باید دست‌کم دو پارامتر داشته باشد: \fBsubnet\fP، که کل زیرشبکه را تعریف می‌کند؛ و \fBpools\fP، که فهرستی از استخرهای تخصیص‌پذیر پویا (dynamically allocated pools) تحت مدیریت سرور DHCP است. .sp این مثال شامل یک زیرشبکهٔ منفرد است. اگر بیش از یک مورد تعریف می‌شد، عناصر اضافی در پارامتر \fBsubnet4\fP مشخص شده و با کاما از هم جدا می‌شدند. برای نمونه، جهت تعریف سه زیرشبکه، از نحو (syntax) زیر استفاده می‌شد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.200\(dq } ], \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq }, { \(dqid\(dq: 2, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.3.100 \- 192.0.3.200\(dq } ], \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq }, { \(dqid\(dq: 3, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.4.1 \- 192.0.4.254\(dq } ], \(dqsubnet\(dq: \(dq192.0.4.0/24\(dq } ], \&... } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که تورفتگی اختیاری است و صرفاً برای خوانایی و زیبایی به کار می‌رود. در برخی موارد ممکن است ترجیح داده شود از نشانه‌گذاری فشرده‌تری استفاده گردد. .sp پس از اینکه تمام پارامترها مشخص شدند، دو زمینه (context) باز وجود دارد: \fBglobal\fP و \fBDhcp4\fP؛ از این رو، باید از دو براکت مجعد بسته (آکولاد بسته) برای بستن آن‌ها استفاده شود..SS "ذخیره‌سازی اجاره‌ها (Lease Storage)" .sp همهٔ اجاره‌های صادرشده توسط سرور در پایگاه دادهٔ اجاره ذخیره می‌شوند. سه بک‌اند پایگاه داده در دسترس است: memfile (پیش‌فرض)، MySQL و PostgreSQL. .SS "Memfile \- ذخیره‌سازی پایه برای اجاره‌ها (Memfile \- Basic Storage for Leases)" .sp سرور قادر است داده‌های اجاره را در مخازن مختلفی ذخیره کند. در استقرارهای بزرگ‌تر ممکن است ذخیرهٔ اجاره‌ها در یک پایگاه داده ترجیح داده شود؛ بخش Lease Database Configuration این گزینه را شرح می‌دهد. با این حال، در استقرارهای معمولی و کوچک‌تر، سرور اطلاعات اجاره را به جای پایگاه داده در یک فایل CSV ذخیره می‌کند. استفاده از یک فایل برای ذخیره‌سازی علاوه بر اینکه به مدیریت کمتری نیاز دارد، این مزیت را نیز دارد که وابستگی به نرم‌افزارهای پایگاه دادهٔ شخص ثالث را از بین می‌برد. .sp پیکربندی بک‌اند memfile از طریق پارامترهای \fBDhcp4\fP/\fBlease\-database\fP کنترل می‌شود. پارامتر \fBtype\fP اجباری است و از طریق مقدار \fB\(dqmemfile\(dq\fP مشخص می‌کند که سرور باید از کدام فضای ذخیره‌سازی برای اجاره‌ها استفاده کند. فهرست زیر پارامترهای اختیاری دیگری را ارائه می‌دهد که می‌توان از آن‌ها برای پیکربندی بک‌اند memfile استفاده کرد. .INDENT 0.0 .IP \(bu 2 \fBpersist\fP: کنترل می‌کند که آیا اجاره‌های جدید و به‌روزرسانی‌های اجاره‌های موجود روی فایل نوشته شوند یا خیر. اکیداً توصیه می‌شود مقدار این پارامتر در تمام طول فعالیت عادی سرور همواره روی \fBtrue\fP تنظیم باشد. ننوشتن اجاره‌ها روی دیسک به این معناست که اگر سرور مجدداً راه‌اندازی شود (مثلاً پس از قطع برق)، متوجه نخواهد شد که چه آدرس‌هایی اختصاص داده شده‌اند. در نتیجه، ممکن است به کلاینت‌های جدید آدرس‌هایی را تخصیص دهد که هم‌اکنون در حال استفاده هستند. مقدار \fBfalse\fP عمدتاً برای اهداف آزمایش عملکرد مفید است. مقدار پیش‌فرض پارامتر \fBpersist\fP برابر با \fBtrue\fP است که فعال‌سازِ نوشتن به‌روزرسانی‌های اجاره در فایل اجاره می‌باشد. .IP \(bu 2 \fBname\fP: فایل اجاره‌ای را که اجاره‌های جدید و به‌روزرسانی‌های اجاره در آن ثبت می‌شوند مشخص می‌کند. مقدار پیش‌فرض این پارامتر برابر است با: \fB\(dq[kea\-install\-dir]/var/lib/kea/kea\-leases4.csv\(dq\fP\&. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 2.7.9 به بعد، فایل‌های اجاره تنها می‌توانند از دایرکتوری داده‌ای که در حین کامپایل مشخص شده است بارگذاری شوند: \fB\(dq[kea\-install\-dir]/var/lib/kea\(dq\fP\&. این مسیر را می‌توان در هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_DHCP_DATA_DIR\fP روی مسیر مورد نظر بازنویسی (override) کرد. اگر مسیری به غیر از این مقدار در \fBname\fP استفاده شود، Kea با صدور خطا از راه‌اندازی خودداری می‌کند، یا در صورتی که در حال اجرا باشد، یک خطای غیرقابل‌بازیابی را ثبت خواهد کرد. جهت سهولت در تعیین یک نام فایل سفارشی، کافی است بخش مسیر را از \fBname\fP حذف کنید. .UNINDENT .UNINDENT .INDENT 0.0 .IP \(bu 2 \fBlfc\-interval\fP: بازهٔ زمانی را بر حسب ثانیه مشخص می‌کند که سرور در آن، پاک‌سازی فایل اجاره (LFC) را انجام می‌دهد. این عملیات اطلاعات اضافی (تاریخچه‌ای) را از فایل اجاره حذف کرده و به‌طور مؤثری حجم فایل اجاره را کاهش می‌دهد. فرایند پاک‌سازی در ادامهٔ این بخش با جزئیات بیشتری توضیح داده شده است. مقدار پیش‌فرض \fBlfc\-interval\fP برابر با \fB3600\fP است. مقدار \fB0\fP قابلیت LFC را غیرفعال می‌کند. .IP \(bu 2 \fBmax\-row\-errors\fP: تعداد خطاهای ردیف را قبل از اینکه سرور از تلاش برای بارگذاری فایل اجاره دست بکشد مشخص می‌کند. هنگامی که سرور یک فایل اجاره را بارگذاری می‌کند، آن را ردیف به ردیف پردازش می‌نماید که هر ردیف حاوی یک اجاره است. اگر ردیفی معیوب باشد و نتواند به درستی پردازش شود، سرور آن را لاگ کرده، ردیف را نادیده می‌گیرد و به سراغ ردیف بعدی می‌رود. از این پارامتر می‌توان برای تعیین سقف مجاز بر روی تعداد چنین ردیف‌های نادیده‌گرفته‌شده‌ای استفاده کرد، که پس از آن سرور تلاش را متوقف کرده و خارج می‌شود. مقدار پیش‌فرض \fB0\fP این محدودیت را غیرفعال می‌کند و به سرور اجازه می‌دهد بدون در نظر گرفتن تعداد ردیف‌های نادیده‌گرفته‌شده، کل فایل را پردازش کند. .UNINDENT .sp یک نمونه از پیکربندی بک‌اند memfile در زیر ارائه شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqtype\(dq: \(dqmemfile\(dq, \(dqpersist\(dq: true, \(dqname\(dq: \(dqkea\-leases4.csv\(dq, \(dqlfc\-interval\(dq: 1800, \(dqmax\-row\-errors\(dq: 100 } } .EE .UNINDENT .UNINDENT .sp این پیکربندی، فایل \fBkea\-leases4.csv\fP را به عنوان فضای ذخیره‌سازی اطلاعات اجاره انتخاب کرده و پایایی (نوشتن به‌روزرسانی‌های اجاره در این فایل) را فعال می‌سازد. همچنین بک‌اند را به‌گونه‌ای تنظیم می‌کند که پاک‌سازی دوره‌ای فایل اجاره را هر 1800 ثانیه (30 دقیقه) انجام دهد و حداکثر تعداد خطاهای ردیف را روی 100 تعیین می‌نماید. .SS "چرا پاک‌سازی فایل اجاره ضروری است؟ (Why Is Lease File Cleanup Necessary?)" .sp برای درک اینکه چرا پاک‌سازی دوره‌ای فایل اجاره ضروری است، مهم است بدانیم که محتویات فایل اجاره چگونه سازمان‌دهی می‌شوند. هر بار که سرور اجاره‌ای را به‌روزرسانی می‌کند یا اجارهٔ جدیدی برای یک کلاینت ایجاد می‌نماید، اطلاعات اجارهٔ جدید باید در فایل اجاره ثبت شود. سرور به دلایل کارایی و عملکرد، اجارهٔ موجود کلاینت را در فایل بازنویسی نمی‌کند، چرا که این کار بالقوه نیازمند بازنویسی کل فایل است. در عوض، به سادگی اطلاعات اجارهٔ جدید را به انتهای فایل اضافه (append) می‌کند؛ ورودی‌های قبلی اجاره برای آن کلاینت حذف نمی‌شوند. هنگامی که سرور اجاره‌ها را از فایل اجاره بارگذاری می‌کند (مثلاً هنگام راه‌اندازی سرور)، فرض را بر این می‌گذارد که آخرین ورودی اجاره برای کلاینت، ورودی معتبر است. ورودی‌های پیشین نادیده گرفته می‌شوند، بدین معنی که سرور می‌تواند اطلاعات دقیقی دربارهٔ اجاره‌ها بازسازی کند، حتی اگر ورودی‌های متعددی برای هر کلاینت وجود داشته باشد. با این حال، ذخیرهٔ ورودی‌های زیاد برای هر کلاینت منجر به حجیم شدن بیش از حد فایل اجاره شده و به عملکرد راه‌اندازی و بازپیکربندی سرور آسیب می‌زند، چرا که نیاز به پردازش تعداد بیشتری از ورودی‌های اجاره خواهد داشت. .sp پاک‌سازی فایل اجاره (LFC) تمام ورودی‌های پیشین مربوط به هر کلاینت را حذف کرده و تنها آخرین ورودی‌ها را باقی می‌گذارد. بازه‌ای که پاک‌سازی در آن انجام می‌شود قابل‌پیکربندی است و باید با توجه به بسامد تمدید اجاره توسط کلاینت‌ها انتخاب گردد. هرچه تمدیدها مکررتر باشد، مقدار \fBlfc\-interval\fP باید کوچک‌تر باشد. با این حال توجه داشته باشید که عملیات LFC زمان‌بر است و بنابراین این احتمال (هرچند نامحتمل) وجود دارد که اگر \fBlfc\-interval\fP بیش از حد کوتاه باشد، یک پاک‌سازی جدید در حالی آغاز شود که پاک‌سازی پیشین هنوز در حال اجراست. سرور با نادیده گرفتن پاک‌سازی جدید در هنگام تشخیص در جریان بودن پاک‌سازی قبلی، این وضعیت را مدیریت می‌کند، اما این امر بدین معناست که پاک‌سازی‌های واقعی در فواصل طولانی‌تری نسبت به بازهٔ پیکربندی‌شده انجام خواهند شد. علاوه بر این، راه‌اندازی یک پاک‌سازی جدید بار اضافی (overhead) بر سرور تحمیل می‌کند، زیرا در بازهٔ زمانی کوتاهی که فرایند پاک‌سازی جدید ایجاد (spawn) می‌شود، سرور قادر به پاسخگویی به درخواست‌های جدید نیست. بنابراین، توصیه می‌شود مقدار \fBlfc\-interval\fP به گونه‌ای انتخاب شود که به LFC اجازه دهد پیش از شروع یک پاک‌سازی جدید، فرایند پاک‌سازی فعلی را تکمیل کند. .sp پاک‌سازی فایل اجاره توسط یک فرایند جداگانه (در پس‌زمینه) انجام می‌شود تا از تأثیر منفی بر عملکرد فرایند اصلی سرور جلوگیری شود. برای جلوگیری از تداخل بین دو فرایند که از فایل‌های اجارهٔ یکسانی استفاده می‌کنند، فرایند LFC با باز کردن یک فایل اجارهٔ جدید توسط Kea آغاز می‌شود؛ فرایند واقعی LFC بر روی فایل اجاره‌ای عمل می‌کند که دیگر توسط سرور استفاده نمی‌شود. همچنین فایل‌های دیگری نیز به عنوان اثر جانبی پاک‌سازی فایل اجاره ایجاد می‌شوند. شرح تفصیلی فرایند LFC در بخش‌های بعدی این Kea Administrator\(aqs Reference Manual تحت عنوان The LFC Process \%<#\:kea-lfc>\& آمده است..SS پیکربندی پایگاه‌داده اجاره‌ها (Lease Database Configuration) .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اطلاعات دسترسی به پایگاه‌داده اجاره‌ها باید برای کارساز DHCPv4 پیکربندی شود، حتی اگر پیش‌تر برای کارساز DHCPv6 پیکربندی شده باشد. کارسازها اطلاعات خود را به‌طور مستقل ذخیره می‌کنند، بنابراین هر کارساز می‌تواند از یک پایگاه‌داده جداگانه استفاده کند یا هر دو کارساز می‌توانند از یک پایگاه‌داده یکسان استفاده نمایند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برنامه Kea نیازمند آن است که منطقه زمانی (timezone) پایگاه‌داده با منطقه زمانی سیستم مطابقت داشته باشد. برای جزئیات بیشتر، First\-Time Creation of the MySQL Database \%<#\:mysql-database-create> و First\-Time Creation of the PostgreSQL Database \%<#\:pgsql-database-create>\& را ببینید. .UNINDENT .UNINDENT .sp پیکربندی پایگاه‌داده اجاره‌ها از طریق پارامترهای \fBDhcp4\fP/\fBlease\-database\fP کنترل می‌شود. نوع پایگاه‌داده باید روی \fBmemfile\fP، \fBmysql\fP یا \fBpostgresql\fP تنظیم شود، برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqtype\(dq: \(dqmysql\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp سپس، نام پایگاه‌داده‌ای که اجاره‌ها را در خود نگه می‌دارد باید مشخص شود؛ این همان نامی است که هنگام ایجاد پایگاه‌داده استفاده شده است (ببینید First\-Time Creation of the MySQL Database \%<#\:mysql-database-create> یا First\-Time Creation of the PostgreSQL Database \%<#\:pgsql-database-create>). .sp برای MySQL یا PostgreSQL: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqname\(dq: \(dqdatabase\-name\(dq , ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر پایگاه‌داده در سیستمی متفاوت از کارساز DHCPv4 قرار دارد، نام میزبان (host name) پایگاه‌داده نیز باید مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqhost\(dq: \(dqremote\-host\-name\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp به‌طور معمول، پایگاه‌داده روی همان ماشین کارساز DHCPv4 قرار دارد. در این حالت، مقدار را روی رشته خالی تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqhost\(dq : \(dq\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر پایگاه‌داده از درگاهی به غیر از درگاه پیش‌فرض استفاده کند، می‌توان آن را نیز مشخص کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqport\(dq : 12345, ... }, ... } .EE .UNINDENT .UNINDENT .sp چنانچه پایگاه‌داده در سیستم دیگری قرار داشته باشد، ممکن است مدیر سیستم نیاز داشته باشد بازه زمانی طولانی‌تری را برای مهلت زمانی اتصال (connection timeout) مشخص کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqconnect\-timeout\(dq : timeout\-in\-seconds, ... }, ... } .EE .UNINDENT .UNINDENT .sp مقدار پیش‌فرض پنج ثانیه باید برای اتصالات محلی کاملاً کافی باشد. با این حال، در صورت تعیین مهلت زمانی، این مقدار باید یک عدد صحیح بزرگ‌تر از صفر باشد. .sp حداکثر دفعاتی که کارساز پس از قطع ارتباط، به‌طور خودکار تلاش می‌کند تا دوباره به پایگاه‌داده اجاره‌ها متصل شود، می‌تواند مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqmax\-reconnect\-tries\(dq : number\-of\-tries, ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر کارساز پس از انجام حداکثر دفعات تلاش نتواند مجدداً به پایگاه‌داده متصل شود، کارساز خارج خواهد شد. مقدار 0 (پیش‌فرض) بازیابی خودکار را غیرفعال می‌کند و کارساز بلافاصله پس از تشخیص قطعی اتصال خارج می‌شود (فقط در MySQL و PostgreSQL). .sp تعداد میلی‌ثانیه‌هایی که کارساز بین دفعات تلاش برای اتصال مجدد به پایگاه‌داده اجاره‌ها پس از قطع اتصال منتظر می‌ماند نیز می‌تواند مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqreconnect\-wait\-time\(dq : number\-of\-milliseconds, ... }, ... } .EE .UNINDENT .UNINDENT .sp مقدار پیش‌فرض برای MySQL و PostgreSQL برابر با 0 است که بازیابی خودکار را غیرفعال کرده و باعث می‌شود کارساز بلافاصله پس از تشخیص قطعی اتصال خارج شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqon\-fail\(dq : \(dqstop\-retry\-exit\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp مقادیر ممکن عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBstop\-retry\-exit\fP \- سرویس DHCP را در حین تلاش برای بازیابی خودکار اتصالات قطع‌شده غیرفعال می‌کند، و در صورت شکست پس از به پایان رسیدن \fBmax\-reconnect\-tries\fP، کارساز را خاموش می‌نماید. این مقدار پیش‌فرض برای بک‌اند اجاره‌ها، بک‌اند میزبان‌ها و بک‌اند پیکربندی است. .IP \(bu 2 \fBserve\-retry\-exit\fP \- سرویس DHCP را در حین تلاش برای بازیابی خودکار اتصالات قطع‌شده ادامه می‌دهد، و در صورت شکست پس از به پایان رسیدن \fBmax\-reconnect\-tries\fP، کارساز را خاموش می‌کند. .IP \(bu 2 \fBserve\-retry\-continue\fP \- سرویس DHCP را ادامه می‌دهد و حتی در صورت ناموفق بودن بازیابی، کارساز را خاموش نمی‌کند. این مقدار پیش‌فرض برای forensic logging است. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اتصال مجدد خودکار به بک‌اندهای پایگاه‌داده به‌طور مجزا برای هر بک‌اند پیکربندی می‌شود؛ این قابلیت به کاربران امکان می‌دهد تا پارامترهای بازیابی را متناسب با هر بک‌اندی که استفاده می‌کنند تنظیم نمایند. ما پیشنهاد می‌کنیم که کاربران آن را یا برای همه بک‌اندها فعال کنند یا برای هیچ‌کدام، تا رفتار سیستم یکپارچه و سازگار باشد. .sp از دست رفتن ارتباط با بک‌اندی که اتصال مجدد برای آن غیرفعال است (در صورت پیکربندی) منجر به خاموش شدن کارساز خواهد شد. این موضوع مواردی را نیز در بر می‌گیرد که بک‌اند پایگاه‌داده اجاره‌ها و بک‌اند پایگاه‌داده میزبان‌ها به یک نمونه (instance) پایگاه‌داده یکسان متصل هستند. .sp اکیداً توصیه می‌شود تنظیم پیش‌فرض \fBstop\-retry\-exit\fP را برای مدیر اجاره‌ها تغییر ندهید، چرا که فعال بودن اتصال در حین پردازش ترافیک DHCP بسیار حیاتی است. این مورد را تنها در صورتی تغییر دهید که کارساز منحصراً به‌عنوان یک ابزار پیکربندی استفاده شود. .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqretry\-on\-startup\(dq : true, ... }, ... } .EE .UNINDENT .UNINDENT .sp در حین راه‌اندازی کارساز، ناتوانی در اتصال به هر یک از بک‌اندهای پیکربندی‌شده تنها در صورتی یک خطای مهلک تلقی می‌شود که \fBretry\-on\-startup\fP روی \fBfalse\fP (پیش‌فرض) تنظیم شده باشد. با این فرض که پیکربندی در زمان راه‌اندازی باید معتبر باشد، یک خطای مهلک ثبت شده و کارساز خارج می‌شود. خروج به سیستم‌عامل این امکان را به اسکریپت‌های ناظر (nanny scripts) می‌دهد تا مشکل را تشخیص دهند. اگر \fBretry\-on\-startup\fP روی \fBtrue\fP تنظیم شود، کارساز تلاش‌های اتصال مجدد را حتی در زمان راه‌اندازی کارساز یا در هنگام رویدادهای پیکربندی مجدد آغاز می‌کند و اقدام مشخص‌شده در پارامتر \fBon\-fail\fP را رعایت می‌نماید. .sp پارامتر host توسط بک‌اندهای MySQL و PostgreSQL استفاده می‌شود. .sp در نهایت، باید اعتبارنامه‌های حسابی که کارساز تحت آن به پایگاه‌داده دسترسی خواهد داشت تعیین شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dquser\(dq: \(dquser\-name\(dq, \(dqpassword\(dq: \(dq1234\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر حساب کاربری رمز عبور ندارد، گذرواژه را روی یک رشته خالی \fB\(dq\(dq\fP تنظیم کنید. (این حالت پیش‌فرض است.).SS تنظیم مهلت‌های زمانی پایگاه داده (Tuning Database Timeouts) .sp در موارد نادر، ممکن است عملیات خواندن یا نوشتن در پایگاه داده معلق شود (hang کند). این امر می‌تواند ناشی از یک مشکل موقتی شبکه، یا پیکربندی نادرست سرور پراکسی باشد که اتصال را میان نمونه‌های مختلف پایگاه داده جابه‌جا می‌کند. این شرایط نادر هستند، اما کاربران گزارش داده‌اند که Kea گاهی هنگام انجام عملیات‌های ورودی/خروجی (IO) پایگاه داده متوقف می‌شود. تنظیم مقادیر مناسب برای مهلت زمانی (timeout) می‌تواند چنین مشکلاتی را کاهش دهد. .sp پایگاه داده MySQL دو گزینهٔ اتصال مجزا را برای پیکربندی مهلت‌های زمانی خواندن و نوشتن ارائه می‌دهد. پارامترهای پیکربندی متناظر \fBread\-timeout\fP و \fBwrite\-timeout\fP در Kea، مهلت‌های زمانی را بر حسب ثانیه مشخص می‌کنند. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqread\-timeout\(dq : 10, \(dqwrite\-timeout\(dq: 20, ... }, ... } .EE .UNINDENT .UNINDENT .sp تنظیم این پارامترها روی 0 معادل مشخص نکردن آن‌ها است و سبب می‌شود سرور Kea با مقادیر پیش‌فرض MySQL به پایگاه داده متصل شود. در این حالت، Kea برای تکمیل عملیات‌های خواندن و نوشتن به‌طور نامحدود منتظر می‌ماند. .sp نسخه‌های قدیمی‌تر از 5.6 در MySQL از تنظیم مهلت زمانی برای عملیات خواندن و نوشتن پشتیبانی نمی‌کنند. علاوه‌بر این، پارامترهای \fBread\-timeout\fP و \fBwrite\-timeout\fP تنها می‌توانند برای بک‌اند MySQL مشخص شوند؛ تنظیم آن‌ها برای هر نوع بک‌اند پایگاه دادهٔ دیگر موجب خطای پیکربندی خواهد شد. .sp برای تنظیم مهلت زمانی بر حسب ثانیه در PostgreSQL، از پارامتر \fBtcp\-user\-timeout\fP استفاده کنید. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqlease\-database\(dq: { \(dqtcp\-user\-timeout\(dq : 10, ... }, ... } .EE .UNINDENT .UNINDENT .sp مشخص کردن این پارامتر برای انواع دیگر بک‌اند موجب خطای پیکربندی خواهد شد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مهلت‌های زمانی شرح داده شده در اینجا تنها برای اتصالات TCP مؤثر هستند. لطفاً توجه داشته باشید که کتابخانه کلاینت MySQL مورداستفاده در سرورهای Kea، معمولاً هنگامی که پارامتر \fBhost\fP روی \fBlocalhost\fP تنظیم شده باشد، از طریق یک سوکت دامنه یونیکس (UNIX domain socket) به پایگاه داده متصل می‌شود، اما برای \fB127.0.0.1\fP یک اتصال TCP برقرار می‌کند\&. .UNINDENT .UNINDENT .sp از Kea.2.7.4 به بعد، کتابخانهٔ قلاب libdhcp_mysql.so باید بارگذاری شود تا بتوان اجاره‌ها را در بک‌اند پایگاه دادهٔ اجارهٔ MySQL ذخیره کرد. مکان کتابخانهٔ قلاب بک‌اند اجاره را مشخص کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { // the MySQL lease backend hook library required for lease storage. \(dqlibrary\(dq: \(dqlibdhcp_mysql.so\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp از Kea.2.7.4 به بعد، کتابخانهٔ قلاب libdhcp_pgsql.so باید بارگذاری شود تا بتوان اجاره‌ها را در بک‌اند پایگاه دادهٔ اجارهٔ PostgreSQL ذخیره کرد. مکان کتابخانهٔ قلاب بک‌اند اجاره را مشخص کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { // the PostgreSQL lease backend hook library required for lease storage. \(dqlibrary\(dq: \(dqlibdhcp_pgsql.so\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .SS ذخیره‌سازی میزبان‌ها (Hosts Storage) .sp همچنین Kea قادر است اطلاعات مربوط به رزروهای میزبان (host reservations) را در پایگاه داده ذخیره کند. پیکربندی پایگاه دادهٔ میزبان‌ها از همان ساختار نحوی پایگاه دادهٔ اجاره‌ها استفاده می‌کند. در واقع، سرور Kea برای هر هدف، چه اطلاعات اجاره و چه میزبان‌ها، اتصال‌های مستقلی باز می‌کند که بیشترین انعطاف‌پذیری را فراهم می‌آورد. Kea می‌تواند اجاره‌ها و رزروهای میزبان را به‌طور جداگانه نگهداری کند، اما می‌تواند به یک پایگاه دادهٔ یکسان نیز اشاره داشته باشد. در حال حاضر، انواع پایگاه دادهٔ میزبان‌های پشتیبانی‌شده MySQL و PostgreSQL هستند. .sp از پیکربندی زیر می‌توان برای تنظیم اتصال به MySQL استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqtype\(dq: \(dqmysql\(dq, \(dqname\(dq: \(dqkea\(dq, \(dquser\(dq: \(dqkea\(dq, \(dqpassword\(dq: \(dq1234\(dq, \(dqhost\(dq: \(dqlocalhost\(dq, \(dqport\(dq: 3306 } } .EE .UNINDENT .UNINDENT .sp بسته به پیکربندی پایگاه داده، بسیاری از پارامترها ممکن است اختیاری باشند. .sp لطفاً توجه داشته باشید که استفاده از ذخیره‌سازی میزبان‌ها اختیاری است. کاربر می‌تواند تمامی رزروهای میزبان را در فایل پیکربندی تعریف کند و چنانچه تعداد رزروها اندک باشد، این شیوه توصیه‌شده است. با این حال، هنگامی که تعداد رزروها افزایش می‌یابد، استفاده از فضای ذخیره‌سازی میزبان راحت‌تر خواهد بود. لطفاً در نظر داشته باشید که هر دو روش ذخیره‌سازی (فایل پیکربندی و یکی از پایگاه‌های دادهٔ پشتیبانی‌شده) می‌توانند هم‌زمان استفاده شوند. اگر میزبان‌ها در هر دو مکان تعریف شده باشند، ابتدا تعاریف فایل پیکربندی بررسی می‌شوند و سپس در صورت لزوم، فضای ذخیره‌سازی خارجی بررسی خواهد شد. .sp اطلاعات میزبان می‌تواند در چندین مخزن قرار داده شود. عملیات‌ها بر اساس ترتیبی که مخازن در فایل پیکربندی تعریف شده‌اند روی آن‌ها انجام می‌شود، هرچند این امر در صورت افزودن رزرو میزبان به محدودیتی در ترتیب منجر می‌شود؛ مخازن فقط‌خواندنی (read\-only) باید پس از یک مخزن خواندنی\-نوشتنی (read\-write) الزامی پیکربندی شوند، وگرنه عملیات افزودن با شکست مواجه خواهد شد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در Kea الزامی است که منطقه زمانی (timezone) پایگاه داده با منطقه زمانی سیستم مطابقت داشته باشد. برای جزئیات بیشتر، First\-Time Creation of the MySQL Database \%<#\:mysql-database-create> و First\-Time Creation of the PostgreSQL Database \%<#\:pgsql-database-create> را ببینید\&. .UNINDENT .UNINDENT.SS پیکربندی پایگاه‌داده میزبان‌های DHCPv4 .sp پیکربندی پایگاه‌داده میزبان‌ها از طریق پارامترهای \fBDhcp4\fP/\fBhosts\-database\fP کنترل می‌شود. در صورت فعال بودن، نوع پایگاه‌داده باید روی \fBmysql\fP یا \fBpostgresql\fP تنظیم شود\&. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqtype\(dq: \(dqmysql\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp سپس، نام پایگاه‌داده‌ای که رزروها را نگهداری می‌کند باید مشخص شود؛ این همان نامی است که هنگام ایجاد پایگاه‌داده اجاره‌ها (lease) استفاده شده است (برای دستورالعمل‌های نحوه راه‌اندازی نوع پایگاه‌داده مورد نظر، بخش پس‌انه‌های پشتیبانی‌شده \%<#\:supported-databases> را ببینید): .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqname\(dq: \(dqdatabase\-name\(dq , ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر پایگاه‌داده روی سیستمی متفاوت از کارساز DHCPv4 قرار دارد، نام میزبان پایگاه‌داده نیز باید مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqhost\(dq: remote\-host\-name, ... }, ... } .EE .UNINDENT .UNINDENT .sp به طور معمول، پایگاه‌داده روی همان رایانه‌ای قرار دارد که کارساز DHCPv4 اجرا می‌شود. در این حالت، مقدار را روی یک رشته خالی تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqhost\(dq : \(dq\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر پایگاه‌داده از درگاهی غیر از پیش‌فرض استفاده کند، آن درگاه نیز می‌تواند مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqport\(dq : 12345, ... }, ... } .EE .UNINDENT .UNINDENT .sp حداکثر دفعاتی که کارساز پس از قطع ارتباط، به طور خودکار برای اتصال دوباره به پایگاه‌داده میزبان تلاش می‌کند را می‌توان مشخص کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqmax\-reconnect\-tries\(dq : number\-of\-tries, ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر کارساز پس از انجام حداکثر دفعات تلاش نتواند دوباره به پایگاه‌داده متصل شود، کارساز خارج خواهد شد. مقدار 0 (پیش‌فرض) بازیابی خودکار را غیرفعال می‌کند و کارساز بلافاصله پس از تشخیص قطعی اتصال خارج می‌شود (تنها در MySQL و PostgreSQL). .sp تعداد میلی‌ثانیه‌هایی که کارساز میان دفعات تلاش برای اتصال دوباره به پایگاه‌داده میزبان پس از قطعی اتصال منتظر می‌ماند نیز می‌تواند تعیین شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqreconnect\-wait\-time\(dq : number\-of\-milliseconds, ... }, ... } .EE .UNINDENT .UNINDENT .sp مقدار پیش‌فرض برای MySQL و PostgreSQL برابر با 0 است که بازیابی خودکار را غیرفعال کرده و باعث می‌شود کارساز بلافاصله پس از تشخیص قطعی اتصال متوقف شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqon\-fail\(dq : \(dqstop\-retry\-exit\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp مقدارهای ممکن عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBstop\-retry\-exit\fP \- هنگام تلاش برای بازیابی خودکار اتصالات قطع‌شده، سرویس DHCP را غیرفعال می‌کند. در صورت شکست پس از پایان دفعات مجاز \fBmax\-reconnect\-tries\fP، کارساز را خاموش می‌کند\&. این مقدار پیش‌فرض برای MySQL و PostgreSQL است. .IP \(bu 2 \fBserve\-retry\-exit\fP \- هنگام تلاش برای بازیابی خودکار اتصالات قطع‌شده، به سرویس‌دهی DHCP ادامه می‌دهد. در صورت شکست پس از پایان دفعات مجاز \fBmax\-reconnect\-tries\fP، کارساز را خاموش می‌کند\&. .IP \(bu 2 \fBserve\-retry\-continue\fP \- به سرویس‌دهی DHCP ادامه می‌دهد و حتی اگر بازیابی شکست بخورد، کارساز را خاموش نمی‌کند. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اتصال دوباره خودکار به پس‌انه‌های پایگاه‌داده به صورت جداگانه برای هر پس‌انه پیکربندی می‌شود. این به کاربران امکان می‌دهد پارامترهای بازیابی را متناسب با هر پس‌انه‌ای که استفاده می‌کنند تنظیم کنند. پیشنهاد می‌کنیم کاربران آن را یا برای همه پس‌انه‌ها فعال کنند یا برای هیچ‌کدام، تا رفتار سیستم یکپارچه باقی بماند. .sp از دست رفتن ارتباط با پس‌انه‌ای که اتصال مجدد برای آن غیرفعال است منجر (در صورت پیکربندی) به خاموش شدن خودکار کارساز می‌شود. این مورد شامل شرایطی نیز می‌شود که در آن، پس‌انه پایگاه‌داده اجاره‌ها و پس‌انه پایگاه‌داده میزبان‌ها به یک نمونه یکسان از پایگاه‌داده متصل هستند. .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqretry\-on\-startup\(dq : true, ... }, ... } .EE .UNINDENT .UNINDENT .sp در طول راه‌اندازی کارساز، ناتوانی در اتصال به هر یک از پس‌انه‌های پیکربندی‌شده تنها در صورتی مهلک تلقی می‌شود که \fBretry\-on\-startup\fP روی \fBfalse\fP (پیش‌فرض) تنظیم شده باشد. یک خطای مهلک ثبت شده و کارساز خارج می‌شود، بر این مبنا که پیکربندی در زمان راه‌اندازی باید معتبر باشد. خروج و بازگشت به سیستم‌عامل به اسکریپت‌های ناظر (nanny scripts) امکان می‌دهد تا مشکل را شناسایی کنند. اگر \fBretry\-on\-startup\fP روی \fBtrue\fP تنظیم شود، کارساز حتی در زمان راه‌اندازی یا رویدادهای بازپیکربندی نیز تلاش‌ها برای اتصال دوباره را آغاز می‌کند و اقدام مشخص‌شده در پارامتر \fBon\-fail\fP را به کار می‌بندد. .sp در پایان، اعتبارنامه‌های حسابی که کارساز تحت آن به پایگاه‌داده دسترسی خواهد داشت باید تنظیم شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dquser\(dq: \(dquser\-name\(dq, \(dqpassword\(dq: \(dq1234\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر حساب گذرواژه‌ای ندارد، گذرواژه را روی رشته خالی \fB\(dq\(dq\fP تنظیم کنید\&. (این حالت پیش‌فرض است.) .sp افزونه multiple\-storage از نحو مشابهی استفاده می‌کند؛ پیکربندی به جای یک مدخل \fBhosts\-database\fP در یک فهرست \fBhosts\-databases\fP قرار می‌گیرد، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-databases\(dq: [ { \(dqtype\(dq: \(dqmysql\(dq, ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp اگر یک میزبان یکسان هم درون فایل (in\-file) و هم درون پایگاه‌داده (in\-database) پیکربندی شده باشد، Kea هشداری صادر نمی‌کند، برخلاف زمانی که هر دو در یک منبع داده یکسان مشخص شده باشند. در عوض، میزبان پیکربندی‌شده درون فایل نسبت به میزبان پیکربندی‌شده درون پایگاه‌داده اولویت دارد..SS استفاده از پایگاه‌های داده فقط\-خواندنی برای رزروهای میزبان با DHCPv4 .sp در برخی استقرارها، کاربری که نامش در پیکربندی backend پایگاه داده مشخص شده است، ممکن است مجوز نوشتن روی پایگاه داده را نداشته باشد. این موضوع اغلب ناشی از سیاست‌های یک شبکه برای محافظت از داده‌ها در برابر تغییرات ناخواسته است. در بسیاری از موارد مدیران سیستم پایگاه‌های داده انبارگردانی (inventory) را مستقر کرده‌اند که حاوی اطلاعات به مراتب بیشتری درباره میزبان‌ها نسبت به صرفاً رزروهای ایستا اختصاص‌یافته به آن‌هاست. پایگاه داده انبارگردانی می‌تواند برای ایجاد یک نما (view) از پایگاه داده میزبان‌های Kea مورد استفاده قرار گیرد و چنین نمایی اغلب فقط\-خواندنی (read\-only) است. .sp بک‌اندهای پایگاه داده میزبان Kea با یک پیکربندی ضمنی برای خواندن و نوشتن هم‌زمان در پایگاه داده کار می‌کنند. اگر کاربر دسترسی نوشتن به پایگاه داده میزبان را نداشته باشد، راه‌اندازی بک‌اند با شکست مواجه شده و سرور از شروع به کار (یا بازپیکربندی) سر باز می‌زند. با این حال، اگر دسترسی به یک پایگاه داده میزبانِ فقط\-خواندنی برای بازیابی رزروهای کلاینت‌ها و/یا انتساب نشانی‌ها و گزینه‌های خاص مورد نیاز باشد، می‌توان Kea را صریحاً برای اجرا در حالت \(dqread\-only\(dq پیکربندی کرد. این حالت توسط پارامتر بولی \fBreadonly\fP به صورت زیر کنترل می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhosts\-database\(dq: { \(dqreadonly\(dq: true, ... }, ... } .EE .UNINDENT .UNINDENT .sp تنظیم این پارامتر روی \fBfalse\fP، بک‌اند پایگاه داده را برای فعالیت در حالت \(dqread\-write\(dq پیکربندی می‌کند، که در صورت مشخص نشدن پارامتر، پیکربندی پیش‌فرض نیز همین است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پارامتر \fBreadonly\fP تنها برای پایگاه‌های داده MySQL و PostgreSQL پشتیبانی می‌شود. .UNINDENT .UNINDENT .sp از نسخه Kea.2.7.4 به بعد، کتابخانه قلاب (hook library) libdhcp_mysql.so باید بارگیری شود تا رزروهای میزبان در MySQL Host Database Backend ذخیره شوند. مکان کتابخانه قلاب بک‌اند اجاره (lease) را مشخص کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { // the MySQL host backend hook library required for host storage. \(dqlibrary\(dq: \(dqlibdhcp_mysql.so\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp از نسخه Kea.2.7.4 به بعد، کتابخانه قلاب libdhcp_pgsql.so باید بارگیری شود تا رزروهای میزبان در PostgreSQL Host Database Backend ذخیره شوند. مکان کتابخانه قلاب بک‌اند اجاره را مشخص کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { // the PostgreSQL host backend hook library required for host storage. \(dqlibrary\(dq: \(dqlibdhcp_pgsql.so\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .SS تنظیم مهلت‌های زمانی پایگاه داده برای ذخیره‌سازی میزبان‌ها .sp بخش Tuning Database Timeouts را ببینید\&. .SS پیکربندی رابط‌های شبکه (Interface Configuration) .sp سرور DHCPv4 باید طوری پیکربندی شود که روی رابط‌های شبکه خاصی شنود کند. ساده‌ترین پیکربندی رابط شبکه به سرور می‌گوید روی تمام رابط‌های در دسترس گوش فرا دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dq*\(dq ] }, ... } .EE .UNINDENT .UNINDENT .sp علامت ستاره نقش یک کاراکتر عام (wildcard) را ایفا می‌کند و به معنای \(dqگوش دادن روی همه رابط‌ها\(dq است. با این حال، معمولاً بهتر است نام رابط‌ها را به‌طور صریح مشخص کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq ] }, ... } .EE .UNINDENT .UNINDENT .sp امکان استفاده از کاراکتر عام رابط (*) هم‌زمان با نام‌های صریح رابط‌ها وجود دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq, \(dq*\(dq ] }, ... } .EE .UNINDENT .UNINDENT .sp این قالب تنها زمانی باید استفاده شود که بخواهید موقتاً فهرستی از نام‌های رابط را نادیده گرفته و روی تمام رابط‌ها گوش دهید. .sp برخی از استقرارهای سرورهای DHCP نیازمند آن هستند که سرورها روی رابط‌هایی با چندین نشانی IPv4 پیکربندی‌شده گوش دهند. در این وضعیت‌ها، نشانی مورد نظر را می‌توان با پیوست کردن یک نشانی IPv4 به نام رابط به روش زیر انتخاب کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1/10.0.0.1\(dq, \(dqeth3/192.0.2.3\(dq ] }, ... } .EE .UNINDENT .UNINDENT .sp اگر نیاز باشد سرور روی چندین نشانی IPv4 اختصاص‌یافته به یک رابط مشترک گوش دهد، می‌توان مانند مثال زیر چندین نشانی را برای یک رابط تعیین کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1/10.0.0.1\(dq, \(dqeth1/10.0.0.2\(dq ] }, ... } .EE .UNINDENT .UNINDENT .sp روش دیگر این است که اگر سرور باید روی تمام نشانی‌های یک رابط خاص گوش دهد، نام رابط بدون هیچ نشانی مشخص شود. .sp سرور Kea از پاسخ‌دهی به کلاینت‌های مستقیماً متصل که نشانی پیکربندی‌شده‌ای ندارند پشتیبانی می‌کند. این کار مستلزم آن است که سرور نشانی سخت‌افزاری مقصد را در لایه پیوند داده (data\-link layer) بسته ارسالی به کلاینت تزریق کند. سرور DHCPv4 برای دستیابی به این هدف از سوکت‌های خام (raw sockets) استفاده کرده و کل پشته IP/UDP را برای بسته‌های خروجی ایجاد می‌کند. با این حال، نکته منفی استفاده از سوکت خام این است که بسته‌های ورودی و خروجی فایروال‌ها (مانند iptables) را دور می‌زنند. .sp مدیریت ترافیک روی چندین نشانی IPv4 اختصاص‌یافته به یک رابط مشترک می‌تواند یک چالش باشد، چرا که سوکت‌های خام به خود رابط متصل (bind) می‌شوند. هنگامی که سرور DHCP پیکربندی می‌شود تا از سوکت خام روی یک رابط برای دریافت ترافیک DHCP استفاده کند، باید روش‌های پیشرفته فیلتر کردن بسته (مانند BPF) به کار گرفته شوند تا ترافیک تک‌پخشی (unicast) روی نشانی‌های مد نظر اختصاص‌یافته به رابط دریافت شود. اینکه کلاینت‌ها از سوکت خام یا سوکت UDP استفاده کنند، به این بستگی دارد که مستقیماً متصل شده‌اند (سوکت خام) یا بازپخش‌شده (relayed) هستند (سوکت خام یا سوکت UDP). .sp بنابراین، در استقرارهایی که نیازی نیست سرور کلاینت‌های مستقیماً متصل را پیکربندی کند و تنها بسته‌های تک‌پخشی (unicast) را از عامل‌های بازپخش (relay agents) دریافت می‌کند، سرور Kea باید طوری پیکربندی شود که به جای سوکت‌های خام از سوکت‌های UDP استفاده کند. پیکربندی زیر نشان می‌دهد که این کار چگونه انجام‌پذیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq ], \(dqdhcp\-socket\-type\(dq: \(dqudp\(dq }, ... } .EE .UNINDENT .UNINDENT .sp پارامتر \fBdhcp\-socket\-type\fP مشخص می‌کند که سوکت‌های IP/UDP روی تمام رابط‌هایی که سرور روی آن‌ها گوش می‌دهد (یعنی در این مثال \(dqeth1\(dq و \(dqeth3\(dq) باز خواهند شد. اگر \fBdhcp\-socket\-type\fP روی \fBraw\fP تنظیم شود، سرور را پیکربندی می‌کند تا در عوض از سوکت‌های خام استفاده کند. اگر مقدار \fBdhcp\-socket\-type\fP مشخص نشود، مقدار پیش‌فرض \fBraw\fP به کار می‌رود. .sp استفاده از سوکت‌های UDP به‌طور خودکار دریافت بسته‌های همگانی (broadcast) از کلاینت‌های متصل مستقیم را غیرفعال می‌کند. این عملاً بدین معناست که سوکت‌های UDP تنها برای ترافیک بازپخش‌شده (relayed) قابل استفاده هستند. هنگام استفاده از سوکت‌های خام، هم ترافیک کلاینت‌های متصل مستقیم و هم ترافیک بازپخش‌شده مدیریت می‌شوند. .sp هنگام پیکربندی سرور برای باز کردن چندین سوکت خام روی رابطی با چند نشانی IPv4 اختصاص‌یافته، باید احتیاط کرد. اگر کلاینت مستقیماً متصل پیامی را به نشانی همگانی (broadcast) ارسال کند، تمام سوکت‌های روی این پیوند این پیام را دریافت کرده و چندین پاسخ به کلاینت فرستاده خواهد شد. بنابراین، در صورتی که کلاینت‌های مستقیماً متصل روی آن پیوند فعالیت می‌کنند، نباید از پیکربندی با چندین نشانی IPv4 اختصاص‌یافته به رابط استفاده شود. برای استفاده از یک نشانی واحد در چنین رابطی، باید از ساختار \(dqinterface\-name/address\(dq استفاده شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مشخص کردن مقدار \fBraw\fP به عنوان نوع سوکت تضمین نمی‌کند که حتماً از سوکت‌های خام استفاده خواهد شد! استفاده از سوکت‌های خام برای مدیریت ترافیک کلاینت‌های متصل مستقیم در حال حاضر تنها روی سیستم‌های Linux و BSD پشتیبانی می‌شود. اگر سوکت‌های خام در سیستم‌عامل مورد استفاده پشتیبانی نشوند، سرور یک هشدار صادر کرده و به استفاده از سوکت‌های IP/UDP بازمی‌گردد. .UNINDENT .UNINDENT .sp در یک محیط معمولی، انتظار می‌رود سرور DHCP پاسخ را روی همان رابط شبکه‌ای بازگرداند که پرس‌وجو از آن دریافت شده است. این رفتار پیش‌فرض است. با این حال، در برخی استقرارها مطلوب است که بسته‌های خروجی (پاسخ) به عنوان ترافیک عادی ارسال شوند و رابط خروجی توسط جدول‌های مسیریابی تعیین گردد. این نوع ترافیک نامتقارن، غیرمعمول اما معتبر است. سرور Kea از پارامتری به نام \fBoutbound\-interface\fP پشتیبانی می‌کند که این رفتار را کنترل می‌نماید. این پارامتر دو مقدار می‌پذیرد: مقدار نخست، \fBsame\-as\-inbound\fP، به Kea می‌گوید پاسخ را روی همان رابطی بازگرداند که بسته پرس‌وجو دریافت شده بود. این رفتار پیش‌فرض است. پارامتر دوم، \fBuse\-routing\fP، به Kea می‌گوید بسته‌های عادی UDP را ارسال کند و اجازه دهد جدول مسیریابی هسته مناسب‌ترین رابط را تعیین کند. این گزینه تنها زمانی کار می‌کند که \fBdhcp\-socket\-type\fP روی \fBudp\fP تنظیم شده باشد\&. یک نمونه پیکربندی به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq ], \(dqdhcp\-socket\-type\(dq: \(dqudp\(dq, \(dqoutbound\-interface\(dq: \(dquse\-routing\(dq }, ... } .EE .UNINDENT .UNINDENT .sp رابط‌ها در هر بازپیکربندی دوباره شناسایی می‌شوند. این رفتار را می‌توان با تنظیم مقدار \fBre\-detect\fP روی \fBfalse\fP غیرفعال کرد، برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq ], \(dqre\-detect\(dq: false }, ... } .EE .UNINDENT .UNINDENT .sp سازوکار شناسایی مجدد (re\-detect) معمولاً رابط‌های شناسایی‌شده پیشین را حذف کرده و سپس تمام رابط‌های شناسایی‌شده فعلی را اضافه می‌کند. توجه داشته باشید که هنگام اجرای دستورات \fBconfig\-test\fP \%<#\:std-isccmd-config-test> یا \fBconfig\-set\fP \%<#\:std-isccmd-config-set> رابط‌ها مجدداً شناسایی نمی‌شوند. با این حال، رابط‌های جدید شناسایی شده و برای استفاده توسط پیکربندی جدید ارسال‌شده به دستورات \fBconfig\-test\fP \%<#\:std-isccmd-config-test> و \fBconfig\-set\fP \%<#\:std-isccmd-config-set> در دسترس خواهند بود. .sp معمولاً رابط‌های بازگشتی (مانند رابط \fBlo\fP یا \fBlo0\fP) پیکربندی نمی‌شوند، اما اگر یک رابط بازگشتی به‌طور صریح پیکربندی شود و سوکت‌های IP/UDP مشخص گردند، رابط بازگشتی پذیرفته می‌شود. .sp برای مثال، این ساختار می‌تواند برای اجرای Kea در یک FreeBSD jail که تنها یک رابط بازگشتی دارد، جهت سرویس‌دهی به یک درخواست DHCP بازپخش‌شده (relayed) استفاده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqlo0\(dq ], \(dqdhcp\-socket\-type\(dq: \(dqudp\(dq }, ... } .EE .UNINDENT .UNINDENT .sp سرور Kea هنگام راه‌اندازی، سوکت‌های سرویس را به هر رابط متصل می‌کند (bind). اگر فرایند دیگری در حال استفاده از یک درگاه (port) باشد، Kea پیام مربوطه را ثبت کرده و از اعلام خطا جلوگیری می‌کند. در این حالت سرویس DHCP اجرا می‌شود، اما روی برخی رابط‌ها در دسترس نخواهد بود. .sp گزینه \(dqservice\-sockets\-require\-all\(dq باعث می‌شود Kea نیاز داشته باشد که تمام سوکت‌ها با موفقیت متصل شوند. در صورت بروز هرگونه شکست در باز کردن سوکت‌ها، Kea فرایند مقداردهی اولیه را متوقف کرده و با یک وضعیت غیرصفر خارج می‌شود (پیش‌فرض false است). .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq ], \(dqservice\-sockets\-require\-all\(dq: true }, ... } .EE .UNINDENT .UNINDENT .sp گاهی اوقات توقف فوری گزینه مناسبی نیست، چرا که درگاه ممکن است تنها به‌صورت موقت در دسترس نباشد. در این حالت، تلاش مجدد برای باز کردن ممکن است مشکل را رفع کند. سرور Kea دو گزینه برای تعیین تلاش مجدد فراهم می‌کند: \fBservice\-sockets\-max\-retries\fP و \fBservice\-sockets\-retry\-wait\-time\fP\&. .sp گزینه اول حداکثر تعداد دفعاتی را تعیین می‌کند که Kea برای باز کردن یک سوکت دوباره تلاش می‌نماید. مقدار صفر (پیش‌فرض) بدین معناست که Kea این فرایند را تکرار نمی‌کند. .sp گزینه دوم زمان انتظار (بر حسب میلی‌ثانیه) بین تلاش‌ها را مشخص می‌کند. مقدار پیش‌فرض 5000 (5 ثانیه) است. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq ], \(dqservice\-sockets\-max\-retries\(dq: 5, \(dqservice\-sockets\-retry\-wait\-time\(dq: 5000 }, ... } .EE .UNINDENT .UNINDENT .sp اگر \(dqservice\-sockets\-max\-retries\(dq غیرصفر باشد و \(dqservice\-sockets\-require\-all\(dq روی false تنظیم شده باشد، Kea در صورت نیاز تلاش مجدد را انجام می‌دهد، اما در صورتی که هر سوکت همچنان باز نشود متوقف نخواهد شد..SS مشکلات پاسخ‌های تک‌پخشی (Unicast) به DHCPINFORM .sp استفاده از سوکت‌های UDP در استقرارهایی که کارگزار فقط ترافیک رله‌شده را دریافت می‌کند، مزایای خاصی دارد؛ این مزایا در Interface Configuration ذکر شده‌اند. از دیدگاه مدیر سیستم، اغلب مطلوب است که دیوار آتش سامانه برای فیلتر کردن ترافیک ناخواسته پیکربندی شود، و استفاده از سوکت‌های UDP این کار را تسهیل می‌کند. با این حال، مدیر سیستم باید از پیامدهای مربوط به فیلتر کردن انواع خاصی از ترافیک نیز آگاه باشد، زیرا ممکن است عملکرد کارگزار DHCP را مختل کند. .sp در این بخش، ما روی حالتی تمرکز می‌کنیم که کارگزار پیام DHCPINFORM را از طریق یک رله از کلاینت دریافت می‌کند. بر اساس RFC 2131 \%، کارگزار باید پاسخ DHCPACK را به‌صورت unicast به آدرس موجود در فیلد \fBciaddr\fP ارسال کند. هنگامی که سوکت UDP در حال استفاده است، کارگزار DHCP برای ساخت لایه‌های پیوند داده (data link)، IP و UDP پیام خروجی، به توابع سطح پایین سیستم‌عامل متکی است. معمولاً، اگر آدرس کلاینت از یک تراکنش قبلی کلاینت با کارگزار در حافظهٔ موقت ذخیره نشده باشد، سیستم‌عامل ابتدا از ARP برای به‌دست آوردن آدرس لایهٔ پیوند کلاینت جهت درج در سرآیند فریم استفاده می‌کند. هنگامی که تبادل ARP موفقیت‌آمیز باشد، پیام DHCP می‌تواند با استفاده از آدرس به‌دست‌آمده، به‌صورت unicast به کلاینت ارسال شود. .sp برخی از مدیران سیستم پیام‌های ARP را در شبکهٔ خود مسدود می‌کنند، که این امر در هنگام پاسخ کارگزار به پیام‌های DHCPINFORM مشکلاتی ایجاد می‌کند؛ زیرا اگر ارتباط ARP قبلی با شکست مواجه شود، کارگزار قادر به ارسال DHCPACK نخواهد بود. از آنجا که سیستم‌عامل به‌طور کامل مسئول ارتباط ARP و سپس ارسال بستهٔ DHCP بر روی بستر شبکه است، کارگزار DHCP راهی برای تشخیص شکست در تبادل ARP و دور انداخته شدن (drop) پیام پاسخ DHCP ندارد. بنابراین، هنگامی که پاسخ DHCP خروجی دور انداخته می‌شود، کارگزار هیچ پیام خطایی ثبت نمی‌کند. هم‌زمان، تمام قلاب‌های (hooks) مربوط به عملیات ارسال بسته فراخوانی خواهند شد، حتی اگر پیام هرگز به مقصد خود نرسد. .sp توجه داشته باشید که مشکل توصیف‌شده در این بخش هنگام استفاده از سوکت‌های raw مشاهده نمی‌شود، زیرا در این حالت، کارگزار DHCP تمام لایه‌های پیام خروجی را خودش می‌سازد و از ARP استفاده نمی‌کند. در عوض، مقدار حمل‌شده در فیلد \fBchaddr\fP از پیام DHCPINFORM را در لایهٔ پیوند درج می‌کند. .sp مدیران کارگزاری که مایل به پشتیبانی از پیام‌های DHCPINFORM از طریق رله‌ها هستند، نباید ترافیک ARP را در شبکه‌های خود مسدود کنند، یا باید به‌جای سوکت‌های UDP از سوکت‌های raw استفاده نمایند. .SS شناسه زیرشبکه IPv4 .sp شناسهٔ زیرشبکه (subnet ID) یک شمارهٔ یکتا است که با یک زیرشبکهٔ خاص پیوند دارد. در اصل، برای مرتبط کردن اجاره‌های (leases) کلاینت‌ها با زیرشبکه‌های مربوطه‌شان استفاده می‌شود. پیکربندی کارگزار باید شامل شناسه‌های یکتا و پایدار برای تمام زیرشبکه‌ها باشد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 شناسه‌های زیرشبکه (Subnet ID) باید بزرگ‌تر از صفر و کوچک‌تر از 4294967295 باشند. .UNINDENT .UNINDENT .sp پیکربندی زیر شناسهٔ زیرشبکهٔ مشخص‌شده را به یک زیرشبکهٔ تازه‌پیکربندی‌شده اختصاص می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqid\(dq: 1024, ... } ] } .EE .UNINDENT .UNINDENT .SS پیشوند زیرشبکه IPv4 .sp پیشوند زیرشبکه راه دوم برای شناسایی یک زیرشبکه است. Kea می‌تواند آدرس‌های زیرشبکهٔ غیرمعیار (non\-canonical) را بپذیرد؛ برای نمونه، این پیکربندی پذیرفته می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.1/24\(dq, ... } ] } .EE .UNINDENT .UNINDENT .sp این قابلیت حتی در صورتی که زیرشبکهٔ دیگری با پیشوند \(dq192.0.2.0/24\(dq وجود داشته باشد کار می‌کند؛ جهت جلوگیری از موارد تکراری، تنها شکل متنی زیرشبکه‌ها با یکدیگر مقایسه می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 سوءاستفاده از این ویژگی می‌تواند منجر به انتخاب نادرست زیرشبکه شود (بخش How the DHCPv4 Server Selects a Subnet for the Client را ببینید). .UNINDENT .UNINDENT .SS پیکربندی استخرهای آدرس IPv4 .sp نقش اصلی یک کارگزار DHCPv4 تخصیص آدرس است. برای این منظور، کارگزار باید با حداقل یک زیرشبکه و یک استخر (pool) از آدرس‌های پویا برای مدیریت پیکربندی شود. برای مثال، فرض کنید کارگزار به یک بخش شبکه متصل است که از پیشوند 192.0.2.0/24 استفاده می‌کند. مدیر آن شبکه تصمیم می‌گیرد که آدرس‌های محدودهٔ 192.0.2.10 تا 192.0.2.20 توسط کارگزار DHCPv4 مدیریت شوند. چنین پیکربندی‌ای می‌تواند به روش زیر انجام شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq } ], ... } ] } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که \fBsubnet\fP به عنوان یک رشتهٔ ساده تعریف شده است، اما پارامتر \fBpools\fP در واقع فهرستی از استخرها است؛ به همین دلیل، تعریف استخر درون براکت قرار گرفته است، حتی اگر فقط یک محدوده از آدرس‌ها مشخص شده باشد. .sp هر \fBpool\fP ساختاری است که حاوی پارامترهای توصیف‌کنندهٔ یک استخر منفرد می‌باشد. در حال حاضر تنها یک پارامتر وجود دارد، \fBpool\fP، که محدودهٔ آدرس‌های درون استخر را مشخص می‌کند. .sp تعریف بیش از یک استخر در یک زیرشبکه امکان‌پذیر است؛ در ادامهٔ مثال قبلی، فرض کنید 192.0.2.64/26 نیز باید توسط کارگزار مدیریت شود. این مقدار را می‌توان به صورت 192.0.2.64 تا 192.0.2.127 نوشت، یا ساده‌تر به شکل 192.0.2.64/26 بیان کرد. هر دو قالب توسط \fBDhcp4\fP پشتیبانی می‌شوند و می‌توان آن‌ها را در فهرست استخر ترکیب کرد. برای نمونه، استخرهای زیر را می‌توان تعریف کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10\-192.0.2.20\(dq }, { \(dqpool\(dq: \(dq192.0.2.64/26\(dq } ], ... } ], ... } .EE .UNINDENT .UNINDENT .sp فاصله‌های خالی (white space) در تعریف استخرها نادیده گرفته می‌شوند، بنابراین فاصله‌های قبل و بعد از خط تیره اختیاری هستند. می‌توان از آن‌ها برای بهبود خوانایی استفاده کرد. .sp تعداد استخرها محدودیتی ندارد، اما به دلایل کارایی توصیه می‌شود تا جای ممکن از تعداد کمتری استفاده شود. .sp کارگزار ممکن است برای سرویس‌دهی به بیش از یک زیرشبکه پیکربندی شود. برای افزودن زیرشبکهٔ دوم، از ساختاری مشابه زیر استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.200\(dq } ], ... }, { \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.3.100 \- 192.0.3.200\(dq } ], ... }, { \(dqsubnet\(dq: \(dq192.0.4.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.4.1 \- 192.0.4.254\(dq } ], ... } ] } .EE .UNINDENT .UNINDENT .sp هنگام پیکربندی یک کارگزار DHCPv4 با استفاده از نمادگذاری پیشوند/طول (prefix/length)، لطفاً به مقادیر مرزی توجه کنید. وقتی مشخص می‌کنید که کارگزار می‌تواند از یک استخر مشخص استفاده کند، این کارگزار همچنین قادر است اولین آدرس (معمولاً آدرس شبکه) و آخرین آدرس (معمولاً آدرس پخش همگانی یا broadcast) آن استخر را نیز تخصیص دهد. در مثال پیشین استخر 192.0.3.0/24، هر دو آدرس 192.0.3.0 و 192.0.3.255 نیز ممکن است تخصیص یابند. این امر در برخی از پیکربندی‌های شبکه ممکن است نامعتبر باشد. برای جلوگیری از این موضوع، از نمادگذاری \fBmin\-max\fP استفاده کنید. .sp در زیرشبکه‌ای که طول پیشوند آن کمتر از 24 است، ممکن است کاربران تمایل داشته باشند همهٔ آدرس‌هایی را که به .0 و .255 ختم می‌شوند از تخصیص پویا مستثنی کنند. به عنوان مثال، در زیرشبکهٔ 10.0.0.0/8، یک مدیر سیستم ممکن است بخواهد 10.x.y.0 و 10.x.y.255 را برای تمام مقادیر x و y مستثنی کند، با اینکه بر اساس استانداردهای RFC تنها 10.0.0.0 و 10.255.255.255 باید مستثنی شوند. پرچم سازگاری پیکربندی \fBexclude\-first\-last\-24\fP (بخش Kea DHCPv4 Compatibility Configuration Parameters) این کار را به‌طور خودکار انجام می‌دهد، به‌جای اینکه نیاز به پیکربندی صریح استخرهای متعدد یا رزرو برای میزبان‌های ساختگی باشد. هنگامی که مقدار آن \fBtrue\fP باشد، تنها برای زیرشبکه‌هایی با طول پیشوند 24 یا کوچک‌تر (یعنی فضای آدرس بزرگ‌تر) اعمال می‌شود؛ مقدار پیش‌فرض \fBfalse\fP است\&. .sp در این حالت، \(dqexclude\(dq (مستثنی کردن) به معنای نادیده گرفتن این آدرس‌ها در روال انتخاب آدرس آزاد موتور تخصیص است؛ اگر یک کلاینت صریحاً آدرسی منتهی به .0 یا .255 را درخواست کند یا رزرو میزبانی برای آن داشته باشد، آن را دریافت خواهد کرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در ادامه برخی از اختیارات و محدودیت‌های مقادیری که زیرشبکه‌ها و استخرها می‌توانند در پیکربندی‌های غیرمعمول Kea داشته باشند، آورده شده است: .TS box center; l|l|l. T{ حالت پیکربندی Kea T} T{ مجاز T} T{ توضیح T} _ T{ هم‌پوشانی زیرشبکه‌ها T} T{ بله T} T{ مدیر سیستم باید نحوهٔ تطبیق کلاینت‌ها با این زیرشبکه‌ها را در نظر بگیرد. T} _ T{ هم‌پوشانی استخرها در یک زیرشبکه T} T{ خیر T} T{ خطای راه‌اندازی: DHCP4_PARSER_FAIL T} _ T{ هم‌پوشانی استخرهای آدرس در زیرشبکه‌های متفاوت T} T{ بله T} T{ مشخص کردن یک استخر آدرس یکسان در زیرشبکه‌های مختلف می‌تواند به عنوان معادل یک استخر آدرس سراسری (global) استفاده شود. در این حالت، کارگزار می‌تواند صرف‌نظر از زیرشبکهٔ کلاینت، آدرس‌هایی را از همان محدوده تخصیص دهد. اگر آدرسی از چنین استخری به کلاینتی در یک زیرشبکه تخصیص یابد، در صورت جابه‌جایی کلاینت به زیرشبکه‌ای دیگر، همان آدرس برای این کلاینت تمدید خواهد شد. به کلاینت دیگری در یک زیرشبکهٔ متفاوت، آدرسی که قبلاً به این کلاینت در هر یک از زیرشبکه‌ها تخصیص داده شده است، تخصیص داده نخواهد شد. T} _ T{ استخرهایی که با پیشوند زیرشبکه مطابقت ندارند T} T{ خیر T} T{ خطای راه‌اندازی: DHCP4_PARSER_FAIL T} .TE .UNINDENT .UNINDENT.SS ارسال T1 (گزینه ۵۸) و T2 (گزینه ۵۹) .sp مطابق با RFC 2131 \%، کارگزارها باید برای T1 و T2 به ترتیب مقادیری معادل ۵۰٪ و ۸۷.۵٪ از طول‌عمر اجاره را ارسال کنند. به‌طور پیش‌فرض، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> هیچ‌یک از این مقادیر را ارسال نمی‌کند؛ می‌توان آن را طوری پیکربندی کرد که مقادیر مشخص‌شده به‌صورت صریح یا مقادیر محاسبه‌شده بر اساس درصدی از زمان اجاره را ارسال کند. رفتار کارگزار توسط ترکیبی از پارامترهای پیکربندی کنترل می‌شود که دو مورد از آن‌ها پیش‌تر ذکر شده است. برای ارسال مقادیر مشخص و ثابت از دو پارامتر زیر استفاده کنید: .INDENT 0.0 .IP \(bu 2 \fBrenew\-timer\fP \- مقدار T1 را بر حسب ثانیه مشخص می‌کند. .IP \(bu 2 \fBrebind\-timer\fP \- مقدار T2 را بر حسب ثانیه مشخص می‌کند. .UNINDENT .sp کارگزار تنها زمانی T2 را ارسال می‌کند که کمتر از زمان اجاره معتبر باشد. T1 تنها در صورتی ارسال می‌شود که T2 در حال ارسال بوده و T1 کمتر از T2 باشد؛ یا اینکه T2 ارسال نشود و T1 کمتر از زمان اجاره معتبر باشد. .sp محاسبه مقادیر توسط سه پارامتر زیر کنترل می‌شود: .INDENT 0.0 .IP \(bu 2 \fBcalculate\-tee\-times\fP \- زمانی که \fBtrue\fP باشد، T1 و T2 به‌صورت درصدی از زمان اجاره معتبر محاسبه می‌شوند. مقدار پیش‌فرض آن \fBfalse\fP است. .IP \(bu 2 \fBt1\-percent\fP \- درصد زمان اجاره معتبر برای استفاده در T1. این مقدار به‌صورت یک عدد حقیقی بین 0.0 و 1.0 بیان شده و باید کمتر از \fBt2\-percent\fP باشد. مقدار پیش‌فرض آن طبق RFC 2131 برابر با 0.50 است. .IP \(bu 2 \fBt2\-percent\fP \- درصد زمان اجاره معتبر برای استفاده در T2. این مقدار به‌صورت یک عدد حقیقی بین 0.0 و 1.0 بیان شده و باید بزرگتر از \fBt1\-percent\fP باشد. مقدار پیش‌فرض آن طبق RFC 2131 برابر با .875 است. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در صورتی که هم مقادیر صریح مشخص شده باشند و هم \fBcalculate\-tee\-times\fP روی \fBtrue\fP تنظیم شده باشد، کارگزار از مقادیر صریح استفاده خواهد کرد. مدیرانی با ساختاری که در آن برخی زیرشبکه‌ها یا shared\-networkها از مقادیر صریح و برخی از مقادیر محاسبه‌شده استفاده می‌کنند، نباید مقادیر صریح را در سطحی بالاتر از جایی که استفاده خواهند شد تعریف کنند. به ارث بردن آن‌ها از یک محدوده بیش از حد بالا، مانند محدوده سراسری (global)، باعث می‌شود در تمامی سطوح زیرین (shared\-networks و زیرشبکه‌ها) دارای مقدار صریح شوند که عملاً مقادیر محاسبه‌شده را غیرفعال می‌کند. .UNINDENT .UNINDENT .SS گزینه‌های استاندارد DHCPv4 .sp یکی از قابلیت‌های اصلی کارگزار DHCPv4، توانایی ارائه گزینه‌های پیکربندی به کلاینت‌ها است. بیشتر گزینه‌ها تنها در صورتی توسط کارگزار ارسال می‌شوند که کلاینت صراحتاً آن‌ها را با استفاده از گزینه Parameter Request List درخواست کرده باشد. مواردی که نیازی به گنجانده شدن در گزینه Parameter Request List ندارند گزینه‌های پرکاربرد هستند، مانند \(dqDomain Server\(dq، و همچنین گزینه‌هایی که نیازمند رفتار خاصی هستند، مانند \(dqClient FQDN\(dq که در صورت قرار گرفتن در پیام ارسالی کلاینت به کارگزار، به کلاینت بازگردانده می‌شود. .sp «فهرست گزینه‌های استاندارد DHCPv4 قابل پیکربندی توسط مدیر»، دربرگیرنده فهرستی از گزینه‌های استاندارد DHCPv4 است که مقادیر آن‌ها را می‌توان با استفاده از ساختارهای پیکربندی شرح داده‌شده در این بخش تنظیم کرد. این جدول گزینه‌هایی را که نیازمند پردازش خاص بوده و در نتیجه نمی‌توان آن‌ها را با مقادیر ثابت پیکربندی کرد، مستثنی می‌کند. ستون آخر جدول مشخص می‌کند کدام گزینه‌ها می‌توانند حتی در صورت عدم درخواست در گزینه Parameter Request List توسط کارگزار ارسال شوند، و کدام موارد تنها در صورت درخواست صریح ارسال می‌شوند. .sp مثال زیر نحوه پیکربندی نشانی‌های کارگزارهای DNS را نشان می‌دهد، که یکی از پرکاربردترین گزینه‌ها است. گزینه‌هایی که به این روش تعیین می‌شوند سراسری تلقی شده و به تمام زیرشبکه‌های پیکربندی‌شده اعمال می‌شوند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqcode\(dq: 6, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq192.0.2.1, 192.0.2.2\(dq }, ... ] } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که تعیین یکی از دو مورد \fBname\fP یا \fBcode\fP الزامی است؛ نیازی به مشخص کردن هر دوی آن‌ها نیست. \fBspace\fP مقدار پیش‌فرض \fBdhcp4\fP دارد، بنابراین در صورت تعریف یک گزینه معمولی (غیر کپسوله‌شده) DHCPv4 می‌توان از آن نیز صرف‌نظر کرد. در نهایت، مقدار پیش‌فرض \fBcsv\-format\fP برابر با \fBtrue\fP است، بنابراین می‌توان از آن نیز صرف‌نظر کرد، مگر اینکه مقدار گزینه به صورت یک رشته هگزادسیمال مشخص شود. بنابراین، مثال بالا را می‌توان به این صورت ساده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqdata\(dq: \(dq192.0.2.1, 192.0.2.2\(dq }, ... ] } .EE .UNINDENT .UNINDENT .sp گزینه‌های تعریف‌شده هنگام درخواست کلاینت به پاسخ اضافه می‌شوند، به استثنای چند مورد خاص که همواره افزوده می‌گردند. برای اجبار به افزودن یک گزینه خاص، پرچم \fBalways\-send\fP را مانند زیر روی \fBtrue\fP تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqdata\(dq: \(dq192.0.2.1, 192.0.2.2\(dq, \(dqalways\-send\(dq: true }, ... ] } .EE .UNINDENT .UNINDENT .sp اثر این کار همانند آن است که کلاینت کد گزینه را در گزینه Parameter Request List (یا معادل آن برای گزینه‌های سازنده/vendor) قرار داده باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqdata\(dq: \(dq192.0.2.1, 192.0.2.2\(dq, \(dqalways\-send\(dq: true }, ... ], \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqdata\(dq: \(dq192.0.3.1, 192.0.3.2\(dq }, ... ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp در مثال بالا، گزینه \fBdomain\-name\-servers\fP از پرچم سراسری \fBalways\-send\fP پیروی کرده و همواره به پاسخ‌ها افزوده می‌شود، اما برای زیرشبکه \fB192.0.3.0/24\fP، مقدار آن از مشخصات داده‌های گزینه در سطح زیرشبکه برداشته می‌شود. .sp برخلاف \fBalways\-send\fP، اگر پرچم \fBnever\-send\fP برای یک گزینه خاص روی \fBtrue\fP تنظیم شود، کارگزار آن را به پاسخ اضافه نمی‌کند. اثر این کار همانند آن است که کلاینت کد گزینه را از گزینه Parameter Request List (یا معادل آن برای گزینه‌های vendor) حذف کرده باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqdata\(dq: \(dq192.0.2.1, 192.0.2.2\(dq }, ... ], \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqnever\-send\(dq: true }, ... ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp در مثال بالا، گزینه \fBdomain\-name\-servers\fP هرگز به پاسخ‌ها در زیرشبکه \fB192.0.3.0/24\fP افزوده نمی‌شود. \fBnever\-send\fP بر \fBalways\-send\fP تقدم دارد؛ بنابراین اگر هر دو \fBtrue\fP باشند، گزینه اضافه نمی‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پرچم‌های \fBalways\-send\fP و \fBnever\-send\fP چسبنده (sticky) هستند؛ بدین معنا که از قوانین معمول توارث پیکربندی پیروی نمی‌کنند. در عوض، اگر در طول زنجیره توارث پیکربندی حداقل یک‌بار فعال شوند، اعمال می‌گردند \- حتی اگر در بخش‌های دیگری که معمولاً اولویت بالاتری دارند، غیرفعال شده باشند. برای نمونه، اگر یکی از این پرچم‌ها در محدوده سراسری فعال باشد اما در سطح زیرشبکه غیرفعال شود، با نادیده گرفتن تنظیمات سطح زیرشبکه، فعال باقی خواهد ماند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پرچم \fBnever\-send\fP نسبت به \fBlibdhcp_flex_option.so\fP \%<#\:std-ischooklib-libdhcp_flex_option\:.so> قدرت کمتری دارد؛ برای نمونه، هیچ اثری بر گزینه‌هایی که توسط خود کارگزار مدیریت می‌شوند ندارد. هر دو پرچم \fBalways\-send\fP و \fBnever\-send\fP بر گزینه‌هایی که قابل درخواست نیستند، مانند گزینه‌های یک فضای سفارشی (custom space)، بی‌اثر هستند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه Kea 2.7.4 به بعد، گنجاندن گزینه‌ها را می‌توان از طریق برچسب‌گذاری کلاس گزینه نیز کنترل کرد؛ به Option Class\-Tagging \%<#\:option-class-tagging> مراجعه کنید. .UNINDENT .UNINDENT .sp پارامتر \fBname\fP نام گزینه را مشخص می‌کند. برای مشاهده فهرستی از نام‌های پشتیبانی‌شده در حال حاضر، بخش «فهرست گزینه‌های استاندارد DHCPv4 قابل پیکربندی توسط مدیر» در زیر را ببینید. پارامتر \fBcode\fP کد گزینه را مشخص می‌کند که باید با یکی از مقادیر آن فهرست مطابقت داشته باشد. خط بعدی فضای گزینه (option space) را مشخص می‌کند که همواره باید روی \fBdhcp4\fP تنظیم شود چرا که این‌ها گزینه‌های استاندارد DHCPv4 هستند. برای سایر فضاهای گزینه، از جمله فضاهای گزینه سفارشی، به Nested DHCPv4 Options (Custom Option Spaces) مراجعه کنید. خط بعدی قالبی را مشخص می‌کند که داده‌ها در آن وارد می‌شوند؛ استفاده از CSV (مقادیر جداشده با کاما) توصیه می‌شود. خط ششم مقدار واقعی ارسال‌شونده به کلاینت‌ها را تعیین می‌کند. پارامتر data به صورت متن معمولی مشخص می‌شود و در صورتی که بیش از یک مقدار مجاز باشد، مقادیر با کاما جدا می‌شوند. .sp گزینه‌ها را می‌توان به‌صورت مقادیر هگزادسیمال نیز پیکربندی کرد. اگر \fBcsv\-format\fP روی \fBfalse\fP تنظیم شود، داده‌های گزینه باید به‌صورت یک رشته هگزادسیمال مشخص شوند. دستورهای زیر گزینه \fBdomain\-name\-servers\fP را برای تمامی زیرشبکه‌ها با نشانی‌های روبه‌رو پیکربندی می‌کنند: 192.0.3.1 و 192.0.3.2. توجه داشته باشید که \fBcsv\-format\fP روی \fBfalse\fP تنظیم شده است. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqcode\(dq: 6, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcsv\-format\(dq: false, \(dqdata\(dq: \(dqC0 00 03 01 C0 00 03 02\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp سامانه Kea هنگام تعیین داده‌های هگزادسیمال از قالب‌های زیر پشتیبانی می‌کند: .INDENT 0.0.IP \(bu 2 \fBDelimited octets\fP \- یک یا چند اوکتت (بایت) که با دو‌نقطه یا فاصله (\(dq:\(dq یا \(dq \(dq) از یکدیگر جدا شده‌اند. گرچه هر اوکتت می‌تواند شامل یک یا دو رقم باشد، اکیداً توصیه می‌کنیم همیشه از دو رقم استفاده کنید. نمونه‌های معتبر شامل \(dqab:cd:ef\(dq و \(dqab cd ef\(dq هستند. .IP \(bu 2 \fBString of digits\fP \- یک رشته پیوسته از ارقام هگزادسیمال با یا بدون پیشوند \(dq0x\(dq. نمونه‌های معتبر شامل \(dq0xabcdef\(dq و \(dqabcdef\(dq هستند. .UNINDENT .sp هنگام استفاده از قالب هگزادسیمال باید در به‌کارگیری کدگذاری مناسب دقت شود؛ توانایی Kea در اعتبارسنجی صحت داده‌ها در قالب هگزادسیمال محدود است. .sp همچنین می‌توان داده‌ها را برای گزینه‌های باینری، مطابق آنچه نشان داده شده است، به صورت یک رشته متنی درون نقل‌قول تکی داخل نقل‌قول دوتایی تعیین کرد (توجه داشته باشید که \fBcsv\-format\fP باید روی \fBfalse\fP تنظیم شود): .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dquser\-class\(dq, \(dqcode\(dq: 77, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcsv\-format\(dq: false, \(dqdata\(dq: \(dq\(aqconvert this text to binary\(aq\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp بیشتر پارامترها در ساختار \fBoption\-data\fP اختیاری هستند و در برخی شرایط می‌توان از آن‌ها صرف‌نظر کرد، همان‌طور که در Unspecified Parameters for DHCPv4 Option Configuration توضیح داده شده است. .sp امکان تعیین یا بازنویسی (override) گزینه‌ها بر پایه هر زیرشبکه وجود دارد. اگر انتظار می‌رود کلاینت‌های متصل به بیشتر زیرشبکه‌ها مقادیر یکسانی از یک گزینه خاص را دریافت کنند، مدیران سیستم باید از گزینه‌های سراسری (global) استفاده کنند. از سوی دیگر، اگر مقادیر متفاوتی در هر زیرشبکه استفاده می‌شود، مشخص کردن مقادیر سراسری برای گزینه‌ها منطقی نیست؛ بلکه فقط باید گزینه‌های مختص به هر زیرشبکه تنظیم شوند. .sp دستورات زیر گزینه سراسری کارسازهای DNS را برای یک زیرشبکه خاص بازنویسی کرده و یک کارساز DNS منفرد با نشانی 192.0.2.3 تعیین می‌کنند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqcode\(dq: 6, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq192.0.2.3\(dq }, ... ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp در برخی موارد، مرتبط ساختن برخی گزینه‌ها با یک استخر نشانی (address pool) که به کلاینت از آن اجاره داده می‌شود، مفید است. مقادیر گزینه‌های مختص استخر، مقادیر مختص زیرشبکه و سراسری را بازنویسی می‌کنند؛ اولویت‌بندی انتساب گزینه‌های مختص استخر از طریق ترتیب اعلان استخرها در پیکربندی سرور امکان‌پذیر نیست. .sp قطعه‌پیکربندی زیر نحوه تعیین گزینه سرورهای DNS را نشان می‌دهد که فقط در صورتی به کلاینت اختصاص می‌یابد که کلاینت نشانی خود را از استخر داده‌شده دریافت کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.200\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqdata\(dq: \(dq192.0.2.3\(dq }, ... ], ... }, ... ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp گزینه‌ها را همچنین می‌توان در حوزه class یا host\-reservation مشخص کرد. ترتیب اولویت فعلی گزینه‌ها در Kea (از بیشترین به کمترین) عبارت است از: host reservation، سپس pool، سپس subnet، سپس shared network، سپس class و در نهایت global. .sp هنگامی که یک فیلد داده یک رشته باشد و آن رشته حاوی نویسه کاما (\fB,\fP؛ U+002C) باشد، کاما باید با دو بک‌اسلش (\fB\e\e,\fP؛ U+005C) گریز داده شود (escape شود). این گریز دوتایی به این دلیل لازم است که هم روال تفکیک داده‌های CSV به فیلدها و هم JSON از نویسه گریز یکسانی استفاده می‌کنند؛ یک گریز تکی (\fB\e,\fP) ساختار JSON را نامعتبر می‌کند. برای نمونه، رشته \(dqfoo,bar\(dq باید به صورت زیر نمایش داده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqpools\(dq: [ { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqboot\-file\-name\(dq, \(dqdata\(dq: \(dqfoo\e\e,bar\(dq } ] }, ... ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp برخی گزینه‌ها به صورت آرایه تعیین شده‌اند، به این معنی که بیش از یک مقدار برای آن‌ها مجاز است. به عنوان مثال، گزینه \fBtime\-servers\fP امکان تعیین بیش از یک نشانی IPv4 را فراهم می‌آورد و کلاینت‌ها را قادر می‌سازد تا نشانی‌های چندین سرور NTP را به دست آورند. .sp بخش Custom DHCPv4 Options نحو پیکربندی را برای ایجاد تعاریف (قالب‌های) سفارشی گزینه شرح می‌دهد. ایجاد تعاریف سفارشی برای گزینه‌های استاندارد عموماً مجاز نیست، حتی اگر تعریف ایجادشده دقیقاً با قالب واقعی گزینه که در RFCها تعریف شده مطابقت داشته باشد. با این حال، یک استثنا برای این قاعده در مورد گزینه‌های استانداردی وجود دارد که Kea در حال حاضر تعریفی برای آن‌ها ارائه نمی‌دهد. برای استفاده از چنین گزینه‌هایی، مدیر سیستم باید تعریفی را همان‌طور که در Custom DHCPv4 Options شرح داده شده، در فضای گزینه \fBdhcp4\fP ایجاد کند. این تعریف باید با قالب گزینه شرح داده شده در RFC مربوطه مطابقت داشته باشد، اما سازوکار پیکربندی هر قالب گزینه‌ای را مجاز می‌داند زیرا در حال حاضر راهی برای اعتبارسنجی آن وجود ندارد. .sp گزینه‌های استاندارد DHCPv4 که در حال حاضر پشتیبانی می‌شوند در جدول زیر فهرست شده‌اند. \(dqName\(dq و \(dqCode\(dq مقادیری هستند که باید به عنوان name/code در ساختارهای option\-data استفاده شوند. \(dqType\(dq قالب داده‌ها را مشخص می‌کند؛ معانی انواع مختلف در List of standard DHCP option types ذکر شده است..SS فهرست گزینه‌های استاندارد DHCPv4 قابل پیکربندی توسط مدیر سیستم .TS box center; l|l|l|l|l. T{ نام T} T{ کد T} T{ نوع T} T{ آرایه؟ T} T{ بازگردانی در صورت عدم درخواست؟ T} _ T{ time\-offset T} T{ 2 T} T{ int32 T} T{ false T} T{ false T} _ T{ routers T} T{ 3 T} T{ ipv4\-address T} T{ true T} T{ true T} _ T{ time\-servers T} T{ 4 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ name\-servers T} T{ 5 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ domain\-name\-servers T} T{ 6 T} T{ ipv4\-address T} T{ true T} T{ true T} _ T{ log\-servers T} T{ 7 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ cookie\-servers T} T{ 8 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ lpr\-servers T} T{ 9 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ impress\-servers T} T{ 10 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ resource\-location\-servers T} T{ 11 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ boot\-size T} T{ 13 T} T{ uint16 T} T{ false T} T{ false T} _ T{ merit\-dump T} T{ 14 T} T{ string T} T{ false T} T{ false T} _ T{ domain\-name T} T{ 15 T} T{ fqdn T} T{ false T} T{ true T} _ T{ swap\-server T} T{ 16 T} T{ ipv4\-address T} T{ false T} T{ false T} _ T{ root\-path T} T{ 17 T} T{ string T} T{ false T} T{ false T} _ T{ extensions\-path T} T{ 18 T} T{ string T} T{ false T} T{ false T} _ T{ ip\-forwarding T} T{ 19 T} T{ boolean T} T{ false T} T{ false T} _ T{ non\-local\-source\-routing T} T{ 20 T} T{ boolean T} T{ false T} T{ false T} _ T{ policy\-filter T} T{ 21 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ max\-dgram\-reassembly T} T{ 22 T} T{ uint16 T} T{ false T} T{ false T} _ T{ default\-ip\-ttl T} T{ 23 T} T{ uint8 T} T{ false T} T{ false T} _ T{ path\-mtu\-aging\-timeout T} T{ 24 T} T{ uint32 T} T{ false T} T{ false T} _ T{ path\-mtu\-plateau\-table T} T{ 25 T} T{ uint16 T} T{ true T} T{ false T} _ T{ interface\-mtu T} T{ 26 T} T{ uint16 T} T{ false T} T{ false T} _ T{ all\-subnets\-local T} T{ 27 T} T{ boolean T} T{ false T} T{ false T} _ T{ broadcast\-address T} T{ 28 T} T{ ipv4\-address T} T{ false T} T{ false T} _ T{ perform\-mask\-discovery T} T{ 29 T} T{ boolean T} T{ false T} T{ false T} _ T{ mask\-supplier T} T{ 30 T} T{ boolean T} T{ false T} T{ false T} _ T{ router\-discovery T} T{ 31 T} T{ boolean T} T{ false T} T{ false T} _ T{ router\-solicitation\-address T} T{ 32 T} T{ ipv4\-address T} T{ false T} T{ false T} _ T{ static\-routes T} T{ 33 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ trailer\-encapsulation T} T{ 34 T} T{ boolean T} T{ false T} T{ false T} _ T{ arp\-cache\-timeout T} T{ 35 T} T{ uint32 T} T{ false T} T{ false T} _ T{ ieee802\-3\-encapsulation T} T{ 36 T} T{ boolean T} T{ false T} T{ false T} _ T{ default\-tcp\-ttl T} T{ 37 T} T{ uint8 T} T{ false T} T{ false T} _ T{ tcp\-keepalive\-interval T} T{ 38 T} T{ uint32 T} T{ false T} T{ false T} _ T{ tcp\-keepalive\-garbage T} T{ 39 T} T{ boolean T} T{ false T} T{ false T} _ T{ nis\-domain T} T{ 40 T} T{ string T} T{ false T} T{ false T} _ T{ nis\-servers T} T{ 41 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ ntp\-servers T} T{ 42 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ vendor\-encapsulated\-options T} T{ 43 T} T{ empty T} T{ false T} T{ false T} _ T{ netbios\-name\-servers T} T{ 44 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ netbios\-dd\-server T} T{ 45 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ netbios\-node\-type T} T{ 46 T} T{ uint8 T} T{ false T} T{ false T} _ T{ netbios\-scope T} T{ 47 T} T{ string T} T{ false T} T{ false T} _ T{ font\-servers T} T{ 48 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ x\-display\-manager T} T{ 49 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ dhcp\-option\-overload T} T{ 52 T} T{ uint8 T} T{ false T} T{ false T} _ T{ dhcp\-server\-identifier T} T{ 54 T} T{ ipv4\-address T} T{ false T} T{ true T} _ T{ dhcp\-message T} T{ 56 T} T{ string T} T{ false T} T{ false T} _ T{ dhcp\-max\-message\-size T} T{ 57 T} T{ uint16 T} T{ false T} T{ false T} _ T{ vendor\-class\-identifier T} T{ 60 T} T{ string T} T{ false T} T{ false T} _ T{ nwip\-domain\-name T} T{ 62 T} T{ string T} T{ false T} T{ false T} _ T{ nwip\-suboptions T} T{ 63 T} T{ binary T} T{ false T} T{ false T} _ T{ nisplus\-domain\-name T} T{ 64 T} T{ string T} T{ false T} T{ false T} _ T{ nisplus\-servers T} T{ 65 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ tftp\-server\-name T} T{ 66 T} T{ string T} T{ false T} T{ false T} _ T{ boot\-file\-name T} T{ 67 T} T{ string T} T{ false T} T{ false T} _ T{ mobile\-ip\-home\-agent T} T{ 68 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ smtp\-server T} T{ 69 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ pop\-server T} T{ 70 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ nntp\-server T} T{ 71 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ www\-server T} T{ 72 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ finger\-server T} T{ 73 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ irc\-server T} T{ 74 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ streettalk\-server T} T{ 75 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ streettalk\-directory\-assistance\-server T} T{ 76 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ user\-class T} T{ 77 T} T{ binary T} T{ false T} T{ false T} _ T{ slp\-directory\-agent T} T{ 78 T} T{ record (boolean, ipv4\-address) T} T{ true T} T{ false T} _ T{ slp\-service\-scope T} T{ 79 T} T{ record (boolean, string) T} T{ false T} T{ false T} _ T{ nds\-servers T} T{ 85 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ nds\-tree\-name T} T{ 86 T} T{ string T} T{ false T} T{ false T} _ T{ nds\-context T} T{ 87 T} T{ string T} T{ false T} T{ false T} _ T{ bcms\-controller\-names T} T{ 88 T} T{ fqdn T} T{ true T} T{ false T} _ T{ bcms\-controller\-address T} T{ 89 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ client\-system T} T{ 93 T} T{ uint16 T} T{ true T} T{ false T} _ T{ client\-ndi T} T{ 94 T} T{ record (uint8, uint8, uint8) T} T{ false T} T{ false T} _ T{ uuid\-guid T} T{ 97 T} T{ record (uint8, binary) T} T{ false T} T{ false T} _ T{ uap\-servers T} T{ 98 T} T{ string T} T{ false T} T{ false T} _ T{ geoconf\-civic T} T{ 99 T} T{ binary T} T{ false T} T{ false T} _ T{ pcode T} T{ 100 T} T{ string T} T{ false T} T{ false T} _ T{ tcode T} T{ 101 T} T{ string T} T{ false T} T{ false T} _ T{ v6\-only\-preferred T} T{ 108 T} T{ uint32 T} T{ false T} T{ false T} _ T{ netinfo\-server\-address T} T{ 112 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ netinfo\-server\-tag T} T{ 113 T} T{ string T} T{ false T} T{ false T} _ T{ v4\-captive\-portal T} T{ 114 T} T{ string T} T{ false T} T{ false T} _ T{ auto\-config T} T{ 116 T} T{ uint8 T} T{ false T} T{ false T} _ T{ name\-service\-search T} T{ 117 T} T{ uint16 T} T{ true T} T{ false T} _ T{ domain\-search T} T{ 119 T} T{ fqdn T} T{ true T} T{ false T} _ T{ classless\-static\-route T} T{ 121 T} T{ internal T} T{ false T} T{ false T} _ T{ cablelabs\-client\-conf T} T{ 122 T} T{ empty T} T{ false T} T{ false T} _ T{ vivco\-suboptions T} T{ 124 T} T{ record (uint32, binary) T} T{ false T} T{ false T} _ T{ vivso\-suboptions T} T{ 125 T} T{ uint32 T} T{ false T} T{ false T} _ T{ pana\-agent T} T{ 136 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ v4\-lost T} T{ 137 T} T{ fqdn T} T{ false T} T{ false T} _ T{ capwap\-ac\-v4 T} T{ 138 T} T{ ipv4\-address T} T{ true T} T{ false T} _ T{ sip\-ua\-cs\-domains T} T{ 141 T} T{ fqdn T} T{ true T} T{ false T} _ T{ v4\-sztp\-redirect T} T{ 143 T} T{ tuple T} T{ true T} T{ false T} _ T{ rdnss\-selection T} T{ 146 T} T{ record (uint8, ipv4\-address, ipv4\-address, fqdn) T} T{ true T} T{ false T} _ T{ v4\-portparams T} T{ 159 T} T{ record (uint8, psid) T} T{ false T} T{ false T} _ T{ v4\-dnr T} T{ 162 T} T{ record (uint16, uint16, uint8, fqdn, binary) T} T{ false T} T{ false T} _ T{ option\-6rd T} T{ 212 T} T{ record (uint8, uint8, ipv6\-address, ipv4\-address) T} T{ true T} T{ false T} _ T{ v4\-access\-domain T} T{ 213 T} T{ fqdn T} T{ false T} T{ false T} .TE .sp می‌توانید نمونه‌ای از نحوه پیکربندی این گزینه‌ها را در kea4/all\-options.json \%<#\:config-example-kea4-all-options-json>\& مشاهده کنید. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 گزینه \fBdefault\-url\fP در Kea 2.1.2 با \fBv4\-captive\-portal\fP جایگزین شد، همان‌طور که در RFC 8910 \%\& معرفی شده است. گزینه جدید دقیقاً همان ساختار گزینه پیشین را دارد. برداشت عمومی بر این است که \fBdefault\-url\fP به‌ندرت استفاده می‌شد. کاربرانی که در حال مهاجرت هستند باید \fBdefault\-url\fP را در پیکربندی‌های خود با \fBv4\-captive\-portal\fP جایگزین کنند. .UNINDENT .UNINDENT .sp Kea همچنین از گزینه‌های دیگری به‌جز موارد ذکرشده در بالا پشتیبانی می‌کند؛ گزینه‌های زیر توسط خود موتور Kea بازگردانده می‌شوند و به‌طور کلی نباید به‌صورت دستی پیکربندی شوند..SS فهرست گزینه‌های استاندارد DHCPv4 که به‌طور مستقل توسط Kea مدیریت می‌شوند و مستقیماً توسط مدیر سیستم قابل پیکربندی نیستند .TS box center; l|l|l|l. T{ نام T} T{ کد T} T{ نوع T} T{ توضیحات T} _ T{ subnet\-mask T} T{ 1 T} T{ ipv4\-address T} T{ به‌طور خودکار، بر اساس تعریف زیرشبکه محاسبه می‌شود. T} _ T{ host\-name T} T{ 12 T} T{ string T} T{ توسط کلاینت ارسال می‌شود، معمولاً توسط پیکربندی DNS تعیین می‌گردد. T} _ T{ dhcp\-requested\-address T} T{ 50 T} T{ ipv4\-address T} T{ ممکن است توسط کلاینت ارسال شود و سرور نباید آن را تنظیم کند. T} _ T{ dhcp\-lease\-time T} T{ 51 T} T{ uint32 T} T{ به‌طور خودکار بر اساس پارامتر \fBvalid\-lifetime\fP تنظیم می‌شود. T} _ T{ dhcp\-message\-type T} T{ 53 T} T{ string T} T{ توسط کلاینت‌ها و سرورها ارسال می‌شود. بسته به شرایط توسط موتور Kea تنظیم شده و هرگز نباید به‌طور صریح پیکربندی شود. T} _ T{ dhcp\-parameter\-request\-list T} T{ 55 T} T{ uint8 array T} T{ توسط کلاینت‌ها ارسال می‌شود و هرگز نباید توسط سرور ارسال گردد. T} _ T{ dhcp\-renewal\-time T} T{ 58 T} T{ uint32 T} T{ توسط پارامتر \fBrenew\-timer\fP تعیین می‌شود. T} _ T{ dhcp\-rebinding\-time T} T{ 59 T} T{ uint32 T} T{ توسط پارامتر \fBrebind\-timer\fP تعیین می‌شود. T} _ T{ dhcp\-client\-identifier T} T{ 61 T} T{ binary T} T{ توسط کلاینت ارسال می‌شود، با مقداری که کلاینت ارسال کرده بازتاب داده می‌شود. T} _ T{ fqdn T} T{ 81 T} T{ record (uint8, uint8, uint8, fqdn) T} T{ بخشی از پیکربندی DDNS و D2. T} _ T{ dhcp\-agent\-options T} T{ 82 T} T{ empty T} T{ توسط کارگزار رله (relay agent) ارسال می‌شود. این یک گزینهٔ دربرگیرندهٔ خالی است؛ به جزئیات گزینهٔ RAI در ادامهٔ این بخش مراجعه کنید. T} _ T{ authenticate T} T{ 90 T} T{ binary T} T{ توسط کلاینت ارسال می‌شود، Kea هنوز آن را اعتبارسنجی نمی‌کند. T} _ T{ client\-last\-transaction\-time T} T{ 91 T} T{ uint32 T} T{ توسط کلاینت ارسال می‌شود، سرور آن را تنظیم نمی‌کند. T} _ T{ associated\-ip T} T{ 92 T} T{ ipv4\-address array T} T{ توسط کلاینت ارسال می‌شود، سرور با فهرستی از نشانی‌ها پاسخ می‌دهد. T} _ T{ subnet\-selection T} T{ 118 T} T{ ipv4\-address T} T{ اگر در پیام‌های کلاینت وجود داشته باشد، در فرآیند انتخاب زیرشبکه استفاده خواهد شد. T} _ T{ status\-code T} T{ 151 T} T{ record (uint8, string) T} T{ توسط سرور در پاسخ‌های bulk leasequery تنظیم می‌شود. T} _ T{ base\-time T} T{ 152 T} T{ uint32 T} T{ توسط سرور در پاسخ‌های bulk leasequery تنظیم می‌شود. T} _ T{ start\-time\-of\-state T} T{ 153 T} T{ uint32 T} T{ توسط سرور در پاسخ‌های bulk leasequery تنظیم می‌شود. T} _ T{ query\-start\-time T} T{ 154 T} T{ uint32 T} T{ توسط درخواست‌کننده در طول bulk leasequery تنظیم می‌شود. T} _ T{ query\-end\-time T} T{ 155 T} T{ uint32 T} T{ توسط درخواست‌کننده در طول bulk leasequery تنظیم می‌شود. T} _ T{ dhcp\-state T} T{ 156 T} T{ uint8 T} T{ توسط سرور در پاسخ‌های bulk leasequery تنظیم می‌شود. T} _ T{ data\-source T} T{ 157 T} T{ uint8 T} T{ توسط سرور در پاسخ‌های bulk leasequery تنظیم می‌شود. T} .TE .sp جدول زیر تمام انواع گزینه‌های استفاده‌شده در دو جدول قبلی را همراه با توضیحی دربارهٔ مقادیر قابل‌قبول برای آن‌ها فهرست می‌کند..SS "فهرست انواع استاندارد گزینه‌های DHCP (List of standard DHCP option types)" .TS box center; l|l. T{ نام T} T{ مفهوم T} _ T{ binary T} T{ یک رشته دلخواه از بایت‌ها که به‌صورت مجموعه‌ای از ارقام هگزادسیمال مشخص می‌شود. T} _ T{ boolean T} T{ یک مقدار بولی با مقادیر مجاز true یا false. T} _ T{ empty T} T{ بدون مقدار؛ داده‌ها در زیرگزینه‌ها (sub\-options) حمل می‌شوند. T} _ T{ fqdn T} T{ نام دامنه کاملاً واجد شرایط (مانند www.example.com). T} _ T{ ipv4\-address T} T{ آدرس IPv4 در نماد نقطه‌ـ‌ده‌دهی معمول (مانند 192.0.2.1). T} _ T{ ipv6\-address T} T{ آدرس IPv6 در نماد دونقطه‌ای معمول (مانند 2001:db8::1). T} _ T{ ipv6\-prefix T} T{ پیشوند IPv6 و طول پیشوند مشخص‌شده با نمادگذاری CIDR، مانند 2001:db8:1::/64. این نوع داده برای نمایش یک فیلد ۸ بیتی حامل طول پیشوند و مقدار پیشوند با طول متغیر استفاده می‌شود. T} _ T{ psid T} T{ ‏PSID و طول PSID که با ممیز از یکدیگر جدا شده‌اند، مثلاً 3/4 مشخص‌کننده PSID=3 و طول PSID برابر با ۴ است. در قالب انتقال روی شبکه (wire format)، با یک فیلد ۸ بیتی حامل طول PSID (در این حالت برابر با ۴) و فیلد ۱۶ بیتی مقدار PSID (در این حالت برابر با \(dq0011000000000000b\(dq در نماد دودویی) نمایش داده می‌شود. مقادیر مجاز برای طول PSID بین ۰ تا ۱۶ است. برای جزئیات مربوط به قالب نمایش PSID در شبکه به RFC 7597 \% مراجعه کنید. T} _ T{ record T} T{ داده‌های ساختاریافته که می‌توانند از هر نوعی (به‌جز \(dqrecord\(dq و \(dqempty\(dq) تشکیل شوند. نشانگر (flag) آرایه فقط بر روی فیلد آخر اعمال می‌شود. T} _ T{ string T} T{ هر نوع متن. لطفاً توجه داشته باشید که Kea هنگام باز کردن بسته‌های دریافتی، کاراکترهای نال (null) پایانی را از انتهای گزینه‌های \(dqstring\(dq بدون هشدار حذف می‌کند. این رفتار مطابق با بخش ۲ از RFC 2132 \%\& است. T} _ T{ tuple T} T{ یک فیلد طول که به‌صورت عدد صحیح بدون علامت ۸ یا ۱۶ بیتی کدگذاری شده و پس از آن رشته‌ای با همین طول می‌آید. معمولاً برای DHCPv4 طول ۸ بیتی و برای DHCPv6 طول ۱۶ بیتی است. با این حال، استثناهایی برای این قاعده وجود دارد؛ برای نمونه در گزینه DHCPv4 SZTP Redirect Option، مقدار bootstrap\-server\-list به‌صورت فهرستی از تاپل‌ها (tuples) کدگذاری می‌شود که در آن URI\-length در هر تاپل یک عدد صحیح بدون علامت ۱۶ بیتی است. T} _ T{ uint8 T} T{ یک عدد صحیح بدون علامت ۸ بیتی با مقادیر مجاز ۰ تا ۲۵۵. T} _ T{ uint16 T} T{ یک عدد صحیح بدون علامت ۱۶ بیتی با مقادیر مجاز ۰ تا ۶۵۵۳۵. T} _ T{ uint32 T} T{ یک عدد صحیح بدون علامت ۳۲ بیتی با مقادیر مجاز ۰ تا ۴۲۹۴۹۶۷۲۹۵. T} _ T{ int8 T} T{ یک عدد صحیح علامت‌دار ۸ بیتی با مقادیر مجاز \-128 تا 127. T} _ T{ int16 T} T{ یک عدد صحیح علامت‌دار ۱۶ بیتی با مقادیر مجاز \-32768 تا 32767. T} _ T{ int32 T} T{ یک عدد صحیح علامت‌دار ۳۲ بیتی با مقادیر مجاز \-2147483648 تا 2147483647. T} .TE .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 گزینه \fBclassless\-static\-route\fP دارای نوع داده اختصاصی خود یعنی \(dqinternal\(dq است و رشته‌ای با الگوی زیر را به‌عنوان مقدار می‌پذیرد: subnet1/prefix_len1 \- router1, subnetN/prefix_lenN \- routerN. .sp برای مثال: 10.229.0.128/25 \- 10.229.0.1, 10.198.122.47/32 \- 10.198.122.1 .UNINDENT .UNINDENT .sp همچنین Kea از گزینه Relay Agent Information (اطلاعات کارگزار رله یا RAI، تعریف‌شده در RFC 3046 \%) که گاهی اوقات relay option،‏ agent option یا به‌سادگی option 82 نامیده می‌شود، پشتیبانی می‌کند. خود این گزینه تنها یک نگه‌دارنده (container) است و به‌تنهایی هیچ اطلاعاتی را منتقل نمی‌کند. جدول زیر شامل فهرستی از زیرگزینه‌های RAI است که Kea قادر به درک آن‌هاست. گزینه RAI و زیرگزینه‌های آن توسط کارگزار رله درج شده و توسط Kea دریافت می‌شوند؛ نیازی به پیکربندی Kea با این گزینه‌ها وجود ندارد. قابلیت‌های دسته‌بندی و شناسه منعطف (flexible ID) در بخش رزروهای میزبان Kea می‌توانند برای پردازش این گزینه‌ها و سایر گزینه‌هایی که در جدول زیر ذکر نشده‌اند، مورد استفاده قرار گیرند..SS فهرست زیرگزینه‌های RAI قابل درک برای Kea .TS box center; l|l|l. T{ نام T} T{ کد T} T{ توضیحات T} _ T{ circuit\-id T} T{ 1 T} T{ هنگامی استفاده می‌شود که host\-reservation\-identifiers روی \fIcircuit\-id\fP تنظیم شده باشد\&. T} _ T{ remote\-id T} T{ 2 T} T{ می‌تواند همراه با flex\-id برای شناسایی میزبان‌ها استفاده شود\&. T} _ T{ link\-selection T} T{ 5 T} T{ در صورت وجود، برای انتخاب زیرشبکه مناسب استفاده می‌شود\&. T} _ T{ subscriber\-id T} T{ 6 T} T{ می‌تواند همراه با flex\-id برای شناسایی میزبان‌ها استفاده شود\&. T} _ T{ server\-id\-override T} T{ 11 T} T{ در صورت ارسال توسط رله، Kea آن را به عنوان \fIserver\-id\fP می‌پذیرد\&. T} _ T{ relay\-id T} T{ 12 T} T{ رله را شناسایی می‌کند T} _ T{ relay\-port T} T{ 19 T} T{ در صورت ارسال توسط رله، Kea پاسخ‌های خود را به این درگاه ارسال می‌کند\&. T} .TE .sp تمام زیرگزینه‌های دیگر RAI (از جمله مواردی که در اینجا ذکر نشده‌اند) را می‌توان در دسته‌بندی کلاینت‌ها برای اختصاص بسته‌های ورودی به کلاس‌های خاص، و/یا توسط \fBlibdhcp_flex_id.so\fP \%<#\:std-ischooklib-libdhcp_flex_id\:.so> جهت ایجاد یک شناسه دستگاه یکتا به کار برد. برای اطلاعات بیشتر درباره عبارات مورد استفاده در دسته‌بندی کلاینت و شناسه‌های انعطاف‌پذیر، «دسته‌بندی کلاینت» (Client Classification) \%<#\:classify>\& را ببینید. با استفاده از \fBrelay4[option\-code].hex\fP می‌توان به زیرگزینه‌های RAI ارجاع داد؛ برای نمونه، جهت دسته‌بندی بسته‌ها بر اساس \fBremote\-id\fP (کد زیرگزینه ۲)، از \fBrelay4[2].hex\fP استفاده می‌شود\&. نمونه‌ای از یک کلاس کلاینت که تمام بسته‌های دارای مقدار مشخصی از \fBremote\-id\fP را شامل می‌شود به شکل زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqremote\-id\-1020304\(dq, \(dqtest\(dq: \(dqrelay4[2].hex == 0x01020304\(dq, ... } ], ... } .EE .UNINDENT .UNINDENT .sp از کلاس‌ها می‌توان برای تفکیک ترافیک به تعداد نسبتاً اندکی گروه استفاده کرد که سپس برای انتخاب زیرشبکه‌ها، استخرها (pools)، گزینه‌های اضافی و موارد دیگر به کار می‌روند. در صورتی که رفتار اختصاصی به ازای هر میزبان مورد نیاز باشد، استفاده از رزروهای میزبان (host reservations) همراه با شناسه‌های انعطاف‌پذیر اکیداً توصیه می‌شود. .SS زیرگزینه‌های CableLabs Client Conf .sp گزینه پیکربندی کلاینت کیبل‌لبز (\(dqcablelabs\-client\-conf\(dq با کد ۱۲۲) حاوی زیرگزینه‌هایی در فضای \(dqcablelabs\-client\-conf\(dq است که در جدول زیر فهرست شده‌اند. .SS فهرست زیرگزینه‌های CableLabs Client Conf قابل درک برای Kea .TS box center; l|l|l. T{ نام T} T{ کد T} T{ قالب T} _ T{ tsp\-primary\-server T} T{ 1 T} T{ آدرس IPv4 T} _ T{ tsp\-secondary\-server T} T{ 2 T} T{ آدرس IPv4 T} _ T{ tsp\-as\-parameters T} T{ 4 T} T{ رکوردی متشکل از ۳ مقدار uint32 T} _ T{ tsp\-ap\-parameters T} T{ 5 T} T{ رکوردی متشکل از ۳ مقدار uint32 T} _ T{ tsp\-realm T} T{ 6 T} T{ نام دامنه کاملاً مشخص (FQDN) T} _ T{ tsp\-use\-tgt T} T{ 7 T} T{ بولی (boolean) T} _ T{ tsp\-provisioning\-timer T} T{ 8 T} T{ uint8 T} _ T{ tsp\-sct T} T{ 9 T} T{ uint16 T} _ T{ kdc\-server T} T{ 10 T} T{ آرایه‌ای از آدرس‌های IPv4 T} .TE .sp این زیرگزینه‌ها در RFC 3495 \% (شامل اصلاحیه آن که قالب realm را مشخص می‌کند)، RFC 3594 \% و RFC 3634 \%\& تعریف شده‌اند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 زیرگزینه ۳ آدرس کارساز تامین TSP را یا به صورت آدرس IPv4 یا به صورت FQDN حمل می‌کند. این مورد را نمی‌توان در Kea تعریف کرد، بنابراین هیچ زیرگزینه استانداردی برای کد ۳ تعریف نشده است و این انتخاب باقی می‌ماند که محتوای آن به صورت یک مقدار باینری پیکربندی شود، یا اگر فقط به عنوان یک آدرس IPv4 یا FQDN استفاده می‌شود، به صورت رکوردی از یک \fBuint8\fP (تنظیم‌شده روی 0) و \fBipv4\-address\fP، یا رکوردی از یک \fBuint8\fP (تنظیم‌شده روی 1) و یک \fBfqdn\fP تعریف شود تا امکان استفاده از داده‌های با قالب CSV فراهم گردد. .UNINDENT .UNINDENT.SS گزینه‌های سفارشی DHCPv4 (Custom DHCPv4 Options) .sp Kea از گزینه‌های سفارشی (غیر استاندارد) DHCPv4 پشتیبانی می‌کند. فرض کنید می‌خواهیم یک گزینهٔ جدید DHCPv4 به نام \fBfoo\fP تعریف کنیم که دارای کد 222 بوده و حامل یک مقدار عدد صحیح بی‌علامت 32 بیتی منفرد باشد. چنین گزینه‌ای را می‌توان با قرار دادن ورودی زیر در فایل پیکربندی تعریف کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqcode\(dq: 222, \(dqtype\(dq: \(dquint32\(dq, \(dqarray\(dq: false, \(dqrecord\-types\(dq: \(dq\(dq, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqencapsulate\(dq: \(dq\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp مقدار \fBfalse\fP برای پارامتر \fBarray\fP مشخص می‌کند که این گزینه شامل آرایه‌ای از مقادیر \fBuint32\fP نیست، بلکه در عوض یک مقدار منفرد است. دو پارامتر دیگر خالی گذاشته شده‌اند: \fBrecord\-types\fP و \fBencapsulate\fP\&. پارامتر اول، در صورتی که گزینه شامل رکوردی از فیلدهای داده باشد، فهرستی جداشده با کاما از فیلدهای دادهٔ گزینه را مشخص می‌کند. مقدار \fBrecord\-types\fP در صورتی که \fBtype\fP بر روی \(dqrecord\(dq تنظیم شده باشد باید غیرخالی باشد؛ در غیر این صورت باید خالی بماند. پارامتر دوم، نام فضای گزینه‌ای را تعیین می‌کند که توسط این گزینهٔ خاص کپسوله‌سازی می‌شود. اگر این گزینهٔ خاص هیچ فضای گزینه‌ای را کپسوله‌سازی نمی‌کند، این پارامتر باید خالی رها شود. توجه داشته باشید که عبارت پیکربندی \fBoption\-def\fP تنها قالب یک گزینه را تعریف می‌کند و مقدار (یا مقادیر) آن را تنظیم نمی‌نماید. .sp پارامترهای \fBname\fP، \fBcode\fP و \fBtype\fP الزامی هستند؛ سایر پارامترها اختیاری می‌باشند. مقدار پیش‌فرض پارامتر \fBarray\fP برابر با \fBfalse\fP است\&. مقادیر پیش‌فرض پارامترهای \fBrecord\-types\fP و \fBencapsulate\fP خالی (\fB\(dq\(dq\fP) می‌باشند. مقدار پیش‌فرض \fBspace\fP برابر با \fBdhcp4\fP است\&. .sp پس از تعریف قالب گزینهٔ جدید، مقدار آن به همان روش یک گزینهٔ استاندارد تنظیم می‌شود. برای نمونه، دستورهای زیر مقداری سراسری را تنظیم می‌کنند که بر تمام زیرشبکه‌ها اعمال می‌شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqcode\(dq: 222, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq12345\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp گزینه‌های جدید می‌توانند اَشکال پیچیده‌تری نسبت به استفادهٔ ساده از انواع اولیه (مانند uint8، string، ipv4\-address و غیره) به خود بگیرند؛ امکان تعریف گزینه‌ای متشکل از چندین نوع اولیهٔ موجود وجود دارد. .sp برای مثال، فرض کنید می‌خواهیم گزینهٔ جدیدی تعریف کنیم که متشکل از یک نشانی IPv4، به دنبال آن یک عدد صحیح بی‌علامت 16 بیتی، سپس یک مقدار بولی (boolean) و در ادامه یک رشتهٔ متنی باشد. چنین گزینه‌ای را می‌توان به شیوهٔ زیر تعریف کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqbar\(dq, \(dqcode\(dq: 223, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqtype\(dq: \(dqrecord\(dq, \(dqarray\(dq: false, \(dqrecord\-types\(dq: \(dqipv4\-address, uint16, boolean, string\(dq, \(dqencapsulate\(dq: \(dq\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp پارامتر \fBtype\fP بر روی \fB\(dqrecord\(dq\fP تنظیم شده است تا نشان دهد که این گزینه شامل چندین مقدار از انواع مختلف است. این نوع‌ها به‌صورت یک فهرست جداشده با کاما در فیلد \fBrecord\-types\fP مشخص می‌شوند و باید از میان موارد فهرست‌شده در «فهرست انواع استاندارد گزینه‌های DHCP» (List of standard DHCP option types) باشند\&. .sp مقادیر گزینه در یک عبارت \fBoption\-data\fP به شرح زیر تنظیم می‌شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqbar\(dq, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcode\(dq: 223, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq192.0.2.100, 123, true, Hello World\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp پارامتر \fBcsv\-format\fP بر روی \fBtrue\fP تنظیم می‌شود تا نشان دهد فیلد \fBdata\fP شامل فهرستی از مقادیر جداشده با کاما است. مقادیر موجود در \fBdata\fP باید با نوع‌های تعیین‌شده در فیلد \fBrecord\-types\fP از تعریف گزینه مطابقت داشته باشند. .sp هنگامی که \fBarray\fP بر روی \fBtrue\fP و \fBtype\fP بر روی \fB\(dqrecord\(dq\fP تنظیم شود، فیلد پایانی یک آرایه خواهد بود؛ به این معنی که می‌تواند بیش از یک مقدار را شامل شود، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqbar\(dq, \(dqcode\(dq: 223, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqtype\(dq: \(dqrecord\(dq, \(dqarray\(dq: true, \(dqrecord\-types\(dq: \(dqipv4\-address, uint16\(dq, \(dqencapsulate\(dq: \(dq\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp محتوای گزینهٔ جدید، یک نشانی IPv4 و در پی آن یک یا چند عدد صحیح بی‌علامت 16 بیتی خواهد بود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 به‌طور کلی، مقادیر بولی به‌صورت \fBtrue\fP یا \fBfalse\fP، بدون نقل‌قول مشخص می‌شوند. برخی پارامترهای بولی خاص ممکن است \fB\(dqtrue\(dq\fP، \fB\(dqfalse\(dq\fP، \fB0\fP، \fB1\fP، \fB\(dq0\(dq\fP و \fB\(dq1\(dq\fP را نیز بپذیرند\&. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اعداد را می‌توان در قالب ده‌دهی (decimal) یا هگزادسیمال (hexadecimal) مشخص کرد. قالب هگزادسیمال می‌تواند به‌صورت ساده (مانند abcd) یا با پیشوند 0x (مانند 0xabcd) باشد. .UNINDENT .UNINDENT.SS گزینه‌های خصوصی DHCPv4 (DHCPv4 Private Options) .sp گزینه‌های دارای کدی بین 224 و 254 برای استفادهٔ خصوصی رزرو شده‌اند. می‌توان آن‌ها را در حوزهٔ سراسری (global scope) یا در حوزهٔ محلی client\-class تعریف کرد؛ این امر امکان استفاده از تعاریف گزینه‌ها را بسته به زمینه (context) فراهم کرده و داده‌های گزینه نیز متناسب با آن تنظیم می‌شوند. برای نمونه، جهت پیکربندی یک سازندهٔ قدیمی PXEClient: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqpxeclient\(dq, \(dqtest\(dq: \(dqoption[vendor\-class\-identifier].text == \(aqPXEClient\(aq\(dq, \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqconfigfile\(dq, \(dqcode\(dq: 209, \(dqtype\(dq: \(dqstring\(dq } ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp از آنجا که گزینهٔ Vendor\-Specific Information (VSI) (کد 43) قالبی مختص سازنده (vendor\-specific) دارد، یعنی می‌تواند حامل یک مقدار باینری خام یا زیرگزینه‌ها (sub\-options) باشد، این سازوکار برای این گزینه نیز در دسترس است. .sp در مثال زیر که از یک پیکربندی واقعی برداشته شده است، دو کلاس سازنده از گزینهٔ 43 برای اهدافی متفاوت و ناسازگار استفاده می‌کنند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqcookie\(dq, \(dqcode\(dq: 1, \(dqtype\(dq: \(dqstring\(dq, \(dqspace\(dq: \(dqAPC\(dq }, { \(dqname\(dq: \(dqmtftp\-ip\(dq, \(dqcode\(dq: 1, \(dqtype\(dq: \(dqipv4\-address\(dq, \(dqspace\(dq: \(dqPXE\(dq }, ... ], \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqAPC\(dq, \(dqtest\(dq: \(dqoption[vendor\-class\-identifier].text == \(aqAPC\(aq\(dq, \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqvendor\-encapsulated\-options\(dq, \(dqtype\(dq: \(dqempty\(dq, \(dqencapsulate\(dq: \(dqAPC\(dq } ], \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqcookie\(dq, \(dqspace\(dq: \(dqAPC\(dq, \(dqdata\(dq: \(dq1APC\(dq }, { \(dqname\(dq: \(dqvendor\-encapsulated\-options\(dq }, ... ], ... }, { \(dqname\(dq: \(dqPXE\(dq, \(dqtest\(dq: \(dqoption[vendor\-class\-identifier].text == \(aqPXE\(aq\(dq, \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqvendor\-encapsulated\-options\(dq, \(dqtype\(dq: \(dqempty\(dq, \(dqencapsulate\(dq: \(dqPXE\(dq } ], \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqmtftp\-ip\(dq, \(dqspace\(dq: \(dqPXE\(dq, \(dqdata\(dq: \(dq0.0.0.0\(dq }, { \(dqname\(dq: \(dqvendor\-encapsulated\-options\(dq }, ... ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp تعریف مورداستفاده برای رمزگشایی (decode) یک گزینهٔ VSI به شرح زیر است: .INDENT 0.0 .IP 1. 3 تعریف محلی کلاس کلاینتی که بستهٔ ورودی به آن تعلق دارد؛ .IP 2. 3 در صورت عدم وجود، تعریف سراسری (global)؛ .IP 3. 3 در صورت عدم وجود، تعریف آخرین راه‌حل (last\-resort) توصیف‌شده در بخش بعدی، DHCPv4 Vendor\-Specific Options (سازگار با نسخه‌های قبلی Kea). .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این تعریف آخرین راه‌حل برای گزینهٔ Vendor\-Specific Information (کد 43) با مقادیر باینری خام سازگار نیست. در مواردی که مشخص است یک مقدار باینری خام استفاده خواهد شد، باید یک client class تعریف شود که هم شامل یک عبارت دسته‌بندی مطابق با این موارد و هم یک تعریف گزینه برای گزینهٔ VSI با نوع binary و بدون کپسوله‌سازی (encapsulation) باشد. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 به‌طور پیش‌فرض، در گزینهٔ Vendor\-Specific Information (کد 43)، کدهای زیرگزینهٔ 0 و 255 بر اساس RFC 2132 \%\& به ترتیب به معنای PAD و END هستند. به بیان دیگر، مقادیر کد زیرگزینهٔ 0 و 255 رزرو شده‌اند. با این حال، Kea به کاربران اجازه می‌دهد کدهای زیرگزینه را از 0 تا 255 تعریف کنند. در صورتی که زیرگزینه‌هایی با کدهای 0 و/یا 255 تعریف شوند، بایت‌های دارای آن مقدار هنگام تجزیهٔ یک گزینهٔ VSI در یک پرس‌وجوی ورودی، دیگر به عنوان PAD یا END در نظر گرفته نشده، بلکه به عنوان کد زیرگزینه تلقی می‌شوند. .sp پردازش ورودی گزینهٔ 43 (که باز کردن بسته یا unpacking نیز نامیده می‌شود) به تعویق می‌افتد تا پس از مرحلهٔ دسته‌بندی (classification) انجام شود. این بدان معناست که کلاینت‌ها را نمی‌توان با استفاده از زیرگزینه‌های گزینهٔ 43 دسته‌بندی کرد. تعریفی که برای unpack کردن گزینهٔ 43 استفاده می‌شود به صورت زیر تعیین می‌گردد: .INDENT 0.0 .IP \(bu 2 اگر در حوزهٔ سراسری تعریف شده باشد، از این تعریف استفاده می‌شود. .IP \(bu 2 اگر در حوزهٔ client class تعریف شده باشد و بسته به این کلاس تعلق داشته باشد، از تعریف client class استفاده می‌شود. .IP \(bu 2 اگر نه در حوزهٔ سراسری و نه در یک client class که بسته به آن تعلق دارد تعریف نشده باشد، از تعریف پیش‌ساختهٔ آخرین راه‌حل استفاده می‌شود. این تعریف صرفاً بیان می‌کند که فضای زیرگزینه برابر با \fB\(dqvendor\-encapsulated\-options\-space\(dq\fP\& است. .UNINDENT .sp انتخاب تعریف خروجی کمی ساده‌تر است: .INDENT 0.0 .IP \(bu 2 اگر بسته به یک client class تعلق داشته باشد که گزینهٔ 43 را تعریف کرده است، از این تعریف استفاده شود. .IP \(bu 2 اگر در حوزهٔ سراسری تعریف شده باشد، از این تعریف استفاده شود. .IP \(bu 2 در غیر این صورت، از تعریف پیش‌ساختهٔ آخرین راه‌حل استفاده شود. .UNINDENT .sp از آنجا که زیرگزینه‌ها از یک فضای گزینهٔ خاص/به‌ازای هر سازنده (per vendor) استفاده می‌کنند، در حوزهٔ سراسری تعریف می‌شوند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تعاریف گزینه در کلاس‌های کلاینت تنها برای این مجموعه گزینهٔ محدود (کدهای 43 و از 224 تا 254)، و فقط برای DHCPv4 مجاز است. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 همچنین بازتعریف برخی از گزینه‌های استاندارد در Kea، از طریق قلاب (hook) مربوط به libdhcp_flex_option.so: Flexible Option Actions for Option Value Settings \%<#\:hooks-flex-option> امکان‌پذیر است. نمونه‌هایی از این سازوکار در این مقالهٔ پایگاه دانش (Knowledgebase) موجود است: \%\&. .UNINDENT .UNINDENT.SS گزینه‌های اختصاصی سازنده در DHCPv4 (DHCPv4 Vendor\-Specific Options) .sp در حال حاضر دو فضای گزینه (option space) برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> تعریف شده است: \fBdhcp4\fP (برای گزینه‌های سطح بالای DHCPv4) و \fB\(dqvendor\-encapsulated\-options\-space\(dq\fP، که به‌طور پیش‌فرض خالی است اما می‌توان گزینه‌هایی را در آن تعریف کرد. این گزینه‌ها در گزینهٔ اطلاعات اختصاصی سازنده (Vendor\-Specific Information - کد 43) حمل می‌شوند. مثال‌های زیر نحوهٔ تعریف گزینهٔ \fBfoo\fP با کد 1 را نشان می‌دهند که شامل یک آدرس IPv4، یک عدد صحیح بی‌علامت ۱۶ بیتی، و یک رشته است. گزینهٔ \fBfoo\fP در یک گزینهٔ Vendor\-Specific Information منتقل می‌شود. .sp گام نخست، تعریف قالب گزینه است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqcode\(dq: 1, \(dqspace\(dq: \(dqvendor\-encapsulated\-options\-space\(dq, \(dqtype\(dq: \(dqrecord\(dq, \(dqarray\(dq: false, \(dqrecord\-types\(dq: \(dqipv4\-address, uint16, string\(dq, \(dqencapsulate\(dq: \(dq\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که فضای گزینه روی \fB\(dqvendor\-encapsulated\-options\-space\(dq\fP تنظیم شده است\&. پس از تعریف قالب گزینه، گام بعدی تعیین مقادیر واقعی برای آن گزینه است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqspace\(dq: \(dqvendor\-encapsulated\-options\-space\(dq, \(dqcode\(dq: 1, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq192.0.2.3, 123, Hello World\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp در این مثال، ما گزینهٔ Vendor\-Specific Information را نیز که حامل زیرگزینهٔ \fBfoo\fP ما است می‌گنجانیم\&. این کار الزامی است؛ در غیر این صورت، گزینه در پیام‌های ارسال‌شده به کلاینت قرار نخواهد گرفت. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqvendor\-encapsulated\-options\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp همچنین می‌توان گزینه را با استفاده از کد آن مشخص کرد. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqcode\(dq: 43 } ], ... } .EE .UNINDENT .UNINDENT .sp گزینهٔ پرکاربرد دیگری که معمولاً تا حدی نادقیق \(dqvendor option\(dq نامیده می‌شود، گزینهٔ 125 است. نام درست آن \(dqvendor\-independent vendor\-specific information option\(dq یا \(dqvivso\(dq است. ایدهٔ پشت گزینه‌های vivso این است که هر سازنده مجموعهٔ منحصربه‌فردی از گزینه‌ها را با قالب‌های سفارشی خود دارد. سازنده با یک عدد صحیح بی‌علامت ۳۲ بیتی به نام \fBenterprise\-number\fP یا \fBvendor\-id\fP شناسایی می‌شود\&. .sp فضاهای استانداردی که در Kea تعریف شده‌اند و گزینه‌های آن‌ها عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBvendor\-4491\fP: متعلق به Cable Television Laboratories, Inc. برای گزینه‌های DOCSIS3: .UNINDENT .TS box center; l|l|l. T{ کد گزینه T} T{ نام گزینه T} T{ توضیحات گزینه T} _ T{ 1 T} T{ oro T} T{ مخفف ORO (یا Option Request Option)، که توسط کلاینت‌ها برای درخواست فهرستی از گزینه‌های مورد نظرشان استفاده می‌شود. T} _ T{ 2 T} T{ tftp\-servers T} T{ فهرستی از آدرس‌های IPv4 سرورهای TFTP که باید توسط مودم کابلی استفاده شوند. T} .TE .sp در Kea، هر سازنده با فضای سازنده (vendor space) خاص خود مشخص می‌شود. از آنجا که صدها سازنده وجود دارند و گاهی برای سخت‌افزارهای مختلف از تعاریف گزینه‌های متفاوتی استفاده می‌کنند، پشتیبانی توکار Kea از همهٔ آن‌ها غیرممکن است. خوشبختانه، تعریف پشتیبانی برای گزینه‌های سازندگان جدید آسان است. به عنوان مثال، دستگاه درگاه خانگی (home gateway) شرکت Genexis نیازمند آن است که گزینهٔ vivso 125 همراه با زیرگزینهٔ 2 که حاوی رشته‌ای شامل URL سرور TFTP است ارسال شود. برای پشتیبانی از چنین دستگاهی سه مرحله لازم است: نخست، ایجاد تعاریف گزینه که مشخص می‌کند ساختار گزینه چگونه باید باشد؛ دوم، تعیین مقادیر گزینه؛ و سوم، مشخص کردن زمان ارسال آن گزینه‌های خاص برای Kea از طریق دسته‌بندی کلاینت (client classification). .sp یک نمونه قطعه از پیکربندی می‌تواند شبیه به مورد زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { // First, we need to define that the sub\-option 2 in vivso option for // vendor\-id 25167 has a specific format (it\(aqs a plain string in this example). // After this definition, we can specify values for option tftp. \(dqoption\-def\(dq: [ { // We define a short name, so the option can be referenced by name. // The option has code 2 and resides within vendor space 25167. // Its data is a plain string. \(dqname\(dq: \(dqtftp\(dq, \(dqcode\(dq: 2, \(dqspace\(dq: \(dqvendor\-25167\(dq, \(dqtype\(dq: \(dqstring\(dq } ], \(dqclient\-classes\(dq: [ { // We now need to tell Kea how to recognize when to use vendor space 25167. // Usually we can use a simple expression, such as checking if the device // sent a vivso option with specific vendor\-id, e.g. \(dqvendor[4491].exists\(dq. // Unfortunately, Genexis is a bit unusual in this aspect, because it // doesn\(aqt send vivso. In this case we need to look into the vendor class // (option code 60) and see if there\(aqs a specific string that identifies // the device. Alternatively, one can make use of the automated \(gaVENDOR_CLASS_\(ga // client class and replace \(dqname\(dq and \(dqtest\(dq with \(ga\(dqname\(dq: \(dqVENDOR_CLASS_HMC1000\(dq\(ga // and no test expression. \(dqname\(dq: \(dqcpe_genexis\(dq, \(dqtest\(dq: \(dqsubstring(option[60].hex,0,7) == \(aqHMC1000\(aq\(dq, // Once the device is recognized, we want to send two options: // the vivso option with vendor\-id set to 25167, and a sub\-option 2. \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqvivso\-suboptions\(dq, \(dqdata\(dq: \(dq25167\(dq }, // The sub\-option 2 value is defined as any other option. However, // we want to send this sub\-option 2, even when the client didn\(aqt // explicitly request it (often there is no way to do that for // vendor options). Therefore we use always\-send to force Kea // to always send this option when 25167 vendor space is involved. { \(dqname\(dq: \(dqtftp\(dq, \(dqspace\(dq: \(dqvendor\-25167\(dq, \(dqdata\(dq: \(dqtftp://192.0.2.1/genexis/HMC1000.v1.3.0\-R.img\(dq, \(dqalways\-send\(dq: true } ] } ] } .EE .UNINDENT .UNINDENT .sp به‌طور پیش‌فرض، Kea تنها گزینه‌هایی را بازمی‌گرداند که توسط کلاینت درخواست شده باشند، مگر اینکه قواعد پروتکل به سرور DHCP دستور دهند که همواره گزینه‌ای را ارسال کند. این رویکرد در بیشتر موارد به‌خوبی عمل می‌کند و مانع از بروز مشکلاتی می‌شود که کلاینت‌ها پاسخ‌های حاوی گزینه‌های ناشناخته را رد می‌کنند. با این حال، وضعیت گزینه‌های سازنده پیچیده‌تر است، زیرا این گزینه‌ها مشابه سایر گزینه‌ها درخواست نمی‌شوند، در RFCهای رسمی به‌خوبی مستند نشده‌اند، یا بسته به سازنده متفاوت هستند. .sp برخی سازندگان (مانند DOCSIS که با گزینهٔ سازندهٔ 4491 مشخص می‌شود) سازوکاری برای درخواست گزینه‌های خاص سازنده دارند و Kea قادر است آن‌ها را رعایت کند (زیرگزینهٔ 1). متأسفانه برای بسیاری از سازندگان دیگر، مانند Genexis (شمارهٔ 25167 که در بالا بررسی شد)، Kea چنین سازوکاری ندارد، بنابراین نمی‌تواند هیچ زیرگزینه‌ای را به‌خودی‌خود ارسال کند. برای حل این مشکل، مفهوم گزینه‌های پایدار (persistent options) ابداع شده است. می‌توان به Kea دستور داد که گزینه‌ها را همیشه ارسال کند، حتی اگر کلاینت آن‌ها را درخواست نکرده باشد. این کار با افزودن \fB\(dqalways\-send\(dq: true\fP به ورودی داده‌های گزینه امکان‌پذیر است. توجه داشته باشید که در این مورد خاص، گزینه‌ای در فضای سازندهٔ 25167 تعریف شده است. با فعال بودن \fBalways\-send\fP، هر بار که نیازی به تعامل با فضای سازندهٔ 25167 باشد، این گزینه ارسال می‌شود. .sp همچنین به همین شیوه می‌توان \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> را برای ارسال چندین گزینهٔ سازنده از سازندگان مختلف، به همراه شناسهٔ سازندهٔ ویژهٔ هر کدام پیکربندی کرد. اگر لازم است این گزینه‌ها بدون توجه به اینکه کلاینت شمارهٔ سازمانی (enterprise number) را مشخص کرده باشد یا خیر توسط سرور ارسال شوند، باید \fB\(dqalways\-send\(dq: true\fP برای زیرگزینه‌هایی که درون گزینهٔ \fBvivso\-suboptions\fP (کد 125) قرار می‌گیرند پیکربندی شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ # Typically DHCPv4 clients will send a Parameter Request List option (code 55) for # vivso\-suboptions (code 125), and that is enough for Kea to understand that it needs to # send the option. These options still need to be defined in the configuration, one per # each vendor, but they don\(aqt need \(dqalways\-send\(dq enabled in that case. For misbehaving # clients that do not explicitly request it, one may alternatively set \(dqalways\-send\(dq # to true for them as well. This is referring to the following two entries in option\-data. { \(dqname\(dq: \(dqvivso\-suboptions\(dq, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqdata\(dq: \(dq2234\(dq }, { \(dqname\(dq: \(dqvivso\-suboptions\(dq, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqdata\(dq: \(dq3561\(dq }, { \(dqalways\-send\(dq: true, \(dqdata\(dq: \(dqtagged\(dq, \(dqname\(dq: \(dqtag\(dq, \(dqspace\(dq: \(dqvendor\-2234\(dq }, { \(dqalways\-send\(dq: true, \(dqdata\(dq: \(dqhttps://example.com:1234/path\(dq, \(dqname\(dq: \(dqurl\(dq, \(dqspace\(dq: \(dqvendor\-3561\(dq } ], \(dqoption\-def\(dq: [ { \(dqcode\(dq: 22, \(dqname\(dq: \(dqtag\(dq, \(dqspace\(dq: \(dqvendor\-2234\(dq, \(dqtype\(dq: \(dqstring\(dq }, { \(dqcode\(dq: 11, \(dqname\(dq: \(dqurl\(dq, \(dqspace\(dq: \(dqvendor\-3561\(dq, \(dqtype\(dq: \(dqstring\(dq } ] } .EE .UNINDENT .UNINDENT .sp امکان دیگر بازتعریف گزینه است؛ بخش «DHCPv4 Private Options» را ببینید\&. .sp ‏Kea به همراه چند فایل پیکربندی نمونه ارائه می‌شود. برخی از آن‌ها نحوهٔ پیکربندی گزینه‌های 60 و 43 را نشان می‌دهند. فایل‌های kea4/vendor\-specific.json \%<#\:config-example-kea4-vendor-specific-json> و kea4/vivso.json \%<#\:config-example-kea4-vivso-json> را ببینید\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> قادر است چندین گزینهٔ Vendor Class Identifier (کد 60) با شناسه‌های سازندهٔ مختلف را در درخواست‌های کلاینت تشخیص داده و چندین گزینهٔ vivso (کد 125) را در پاسخ‌ها، یکی به ازای هر سازنده، ارسال کند. .sp \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> زیرگزینهٔ 1 در DOCSIS (یعنی ORO) را رعایت می‌کند و تنها در صورتی که این زیرگزینه در درخواست کلاینت موجود باشد، گزینه‌های درخواست‌شده را اضافه می‌نماید. .sp در حال حاضر تنها از یک سازنده برای گزینهٔ \fBvivco\-suboptions\fP (کد 124) پشتیبانی می‌شود. مشخص کردن چندین شمارهٔ سازمانی درون یک نمونه از گزینه یا چندین گزینه با شماره‌های سازمانی مختلف پشتیبانی نمی‌شود. .UNINDENT .UNINDENT.SS گزینه‌های تودرتوی DHCPv4 (فضاهای گزینه سفارشی) .sp گاهی اوقات تعریف یک فضای گزینه کاملاً جدید سودمند است، مانند زمانی که کاربر گزینه جدیدی را در فضای استاندارد گزینه (\fBdhcp4\fP) ایجاد می‌کند و می‌خواهد این گزینه زیرگزینه‌ها (sub\-options) را منتقل کند. از آنجا که زیرگزینه‌ها در یک فضای جداگانه قرار دارند، کدهای آن‌ها از یک طرح شماره‌گذاری مجزا پیروی می‌کنند و ممکن است با کدهای گزینه‌های استاندارد هم‌پوشانی داشته باشند. .sp توجه داشته باشید که هنگام تعریف زیرگزینه‌ها برای یک گزینه استاندارد، نیازی به ایجاد فضای گزینه جدید نیست؛ چرا که اگر گزینه استاندارد قرار باشد زیرگزینه‌هایی را منتقل کند، به طور پیش‌فرض یک فضا ایجاد می‌شود (بخش DHCPv4 Vendor\-Specific Options را ببینید). .sp اگر یک گزینه DHCPv4 به نام \fBcontainer\fP با کد 222 بخواهیم که دو زیرگزینه با کدهای 1 و 2 را منتقل کند، ابتدا باید زیرگزینه‌های جدید را تعریف کنیم: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqsubopt1\(dq, \(dqcode\(dq: 1, \(dqspace\(dq: \(dqisc\(dq, \(dqtype\(dq: \(dqipv4\-address\(dq, \(dqrecord\-types\(dq: \(dq\(dq, \(dqarray\(dq: false, \(dqencapsulate\(dq: \(dq\(dq }, { \(dqname\(dq: \(dqsubopt2\(dq, \(dqcode\(dq: 2, \(dqspace\(dq: \(dqisc\(dq, \(dqtype\(dq: \(dqstring\(dq, \(dqrecord\-types\(dq: \(dq\(dq, \(dqarray\(dq: false, \(dqencapsulate\(dq: \(dq\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که ما گزینه‌ها را طوری تعریف کرده‌ایم که متعلق به یک فضای گزینه جدید باشند (در این مورد، \fB\(dqisc\(dq\fP). .sp مرحله بعد، تعریف یک گزینه معمولی DHCPv4 با کد مورد نظر و مشخص کردن این است که باید شامل گزینه‌هایی از فضای گزینه جدید باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqcontainer\(dq, \(dqcode\(dq: 222, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqtype\(dq: \(dqempty\(dq, \(dqarray\(dq: false, \(dqrecord\-types\(dq: \(dq\(dq, \(dqencapsulate\(dq: \(dqisc\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp نام فضای گزینه‌ای که زیرگزینه‌ها در آن تعریف شده‌اند در فیلد \fBencapsulate\fP تنظیم می‌شود. فیلد \fBtype\fP روی \fB\(dqempty\(dq\fP تنظیم می‌شود تا نشان دهد این گزینه هیچ داده‌ای به جز زیرگزینه‌ها را حمل نمی‌کند. .sp در نهایت، می‌توانیم مقادیر گزینه‌های جدید را مقداردهی کنیم: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqsubopt1\(dq, \(dqcode\(dq: 1, \(dqspace\(dq: \(dqisc\(dq, \(dqdata\(dq: \(dq192.0.2.3\(dq }, { \(dqname\(dq: \(dqsubopt2\(dq, \(dqcode\(dq: 2, \(dqspace\(dq: \(dqisc\(dq, \(dqdata\(dq: \(dqHello world\(dq }, { \(dqname\(dq: \(dqcontainer\(dq, \(dqcode\(dq: 222, \(dqspace\(dq: \(dqdhcp4\(dq } ] } } .EE .UNINDENT .UNINDENT .sp امکان ایجاد گزینه‌ای که علاوه بر زیرگزینه‌های تعریف‌شده در فضای گزینه کپسوله‌شده، داده‌هایی را نیز با خود حمل کند وجود دارد. برای مثال، اگر در نمونه قبلی نیاز بود که گزینه \fBcontainer\fP علاوه بر زیرگزینه‌ها یک مقدار uint16 را نیز انتقال دهد، مقدار \fBtype\fP در تعریف گزینه باید روی \fB\(dquint16\(dq\fP تنظیم می‌شد. (چنین گزینه‌ای در این صورت ساختار داده‌ای به این شکل خواهد داشت: سربرگ DHCP، مقدار uint16، زیرگزینه‌ها.) سپس مقداری که با پارامتر \fBdata\fP مشخص می‌شود — که باید یک عدد صحیح معتبر داخل نقل‌قول باشد، مانند \fB\(dq123\(dq\fP — به فیلد \fBuint16\fP در گزینه \fBcontainer\fP اختصاص می‌یابد..SS پارامترهای مشخص‌نشده برای پیکربندی گزینه DHCPv4 .sp در بسیاری از موارد نیازی به تعیین تمام پارامترها برای پیکربندی یک گزینه نیست و می‌توان از مقادیر پیش‌فرض استفاده کرد. با این حال، درک پیامدهای عدم تعیین برخی از آن‌ها مهم است، چرا که ممکن است به خطاهای پیکربندی منجر شود. فهرست زیر رفتار سرور را در حالتی که پارامتر خاصی به طور صریح تعیین نشده باشد، توضیح می‌دهد: .INDENT 0.0 .IP \(bu 2 \fBname\fP \- سرور برای شناسایی یک گزینه، به نام گزینه یا کد گزینه نیاز دارد. اگر این پارامتر مشخص نشده باشد، کد گزینه باید تعیین شود. .IP \(bu 2 \fBcode\fP \- سرور برای شناسایی یک گزینه به نام یا کد گزینه نیاز دارد؛ در صورتی که پارامتر \fBname\fP مشخص شده باشد، این پارامتر می‌تواند تعیین‌نشده باقی بماند. با این حال، این امر همچنین مستلزم آن است که گزینه مورد نظر تعریفی داشته باشد (چه به عنوان یک گزینه استاندارد یا تعریفی که توسط مدیر سیستم برای گزینه و با استفاده از ساختار \fBoption\-def\fP ایجاد شده باشد)، زیرا تعریف گزینه، آن را به نامی مشخص مرتبط می‌سازد. امکان پیکربندی گزینه‌ای که برای آن تعریفی وجود ندارد (قالب گزینه نامشخص) وجود دارد. پیکربندی چنین گزینه‌هایی مستلزم استفاده از کد گزینه است. .IP \(bu 2 \fBspace\fP \- اگر فضای گزینه مشخص نشده باشد، مقدار پیش‌فرض آن \fBdhcp4\fP خواهد بود که فضای گزینه‌ای حاوی گزینه‌های استاندارد DHCPv4 است. .IP \(bu 2 \fBdata\fP \- اگر داده‌های گزینه مشخص نشده باشد، مقدار پیش‌فرض آن تهی خواهد بود. مقدار تهی عمدتاً برای گزینه‌های فاقد بار داده (گزینه‌های بولی / boolean) استفاده می‌شود، اما تعیین مقادیر تهی برای برخی از گزینه‌های حامل داده با طول متغیر که استاندارد آن‌ها طول ۰ را مجاز می‌داند، قانونی و معتبر است. برای چنین گزینه‌هایی، پارامتر data می‌تواند در پیکربندی حذف شود. .IP \(bu 2 \fBcsv\-format\fP \- اگر این مقدار مشخص نشود، سرور فرض می‌کند که داده‌های گزینه به صورت فهرستی از مقادیر جداشده با کاما برای انتساب به فیلدهای منفرد گزینه DHCP مشخص شده‌اند. .UNINDENT .SS پشتیبانی از گزینه‌های طولانی .sp سرور \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> تا حدی از گزینه‌های طولانی (RFC 3396) پشتیبانی می‌کند. از نسخه Kea 2.1.6، سرور پیکربندی گزینه‌ها و زیرگزینه‌های طولانی (بیشتر از ۲۵۵ بایت) را می‌پذیرد. گزینه‌ها و زیرگزینه‌ها به صورت داخلی در قالب بسته‌بندی‌نشده (unwrapped) خود ذخیره می‌شوند و می‌توان آن‌ها را طبق معمول با استفاده از زبان تجزیه‌گر پردازش کرد. در هنگام ارسال، سرور گزینه‌ها و زیرگزینه‌های طولانی را با استفاده از کد گزینه مربوطه، به چندین گزینه و زیرگزینه تقسیم می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqoption\-def\(dq: [ { \(dqarray\(dq: false, \(dqcode\(dq: 240, \(dqencapsulate\(dq: \(dq\(dq, \(dqname\(dq: \(dqmy\-option\(dq, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqtype\(dq: \(dqstring\(dq } ], \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqoption\-data\(dq: [ { \(dqalways\-send\(dq: false, \(dqcode\(dq: 240, \(dqname\(dq: \(dqmy\-option\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dqdata \e \-00010203040506070809\-00010203040506070809\-00010203040506070809\-00010203040506070809 \e \-00010203040506070809\-00010203040506070809\-00010203040506070809\-00010203040506070809 \e \-00010203040506070809\-00010203040506070809\-00010203040506070809\-00010203040506070809 \e \-data\(dq, \(dqspace\(dq: \(dqdhcp4\(dq } ] } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در مثال بالا، داده‌ها برای وضوح بیشتر در چند خط شکسته شده‌اند، اما Kea از شکستن خطوط در فایل پیکربندی پشتیبانی نمی‌کند. .UNINDENT .UNINDENT .sp این مثال پیکربندی یک گزینه طولانی سفارشی (بیش از ۲۵۵ بایت) را در یک رزرو نشان می‌دهد. هنگام ارسال پاسخ، سرور این گزینه را به دو گزینه تقسیم می‌کند که هر کدام دارای کد ۲۴۰ هستند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر سرور از ذخیره گزینه‌های طولانی در پایگاه‌های داده، چه از طریق رزروهای میزبان و چه از طریق بک‌اند پیکربندی، پشتیبانی نمی‌کند. .UNINDENT .UNINDENT .sp سرور همچنین قادر به دریافت بسته‌هایی با گزینه‌های تقسیم‌شده (گزینه‌هایی با کد گزینه یکسان) و ادغام تکه‌های داده در یک گزینه واحد است. این قابلیت برای زیرگزینه‌ها نیز پشتیبانی می‌شود، مشروط بر اینکه هر تکه از داده‌های زیرگزینه شامل کد زیرگزینه و طول زیرگزینه نیز باشد. .SS پشتیبانی از گزینه IPv6\-Only Preferred .sp گزینه \fBv6\-only\-preferred\fP (کد ۱۰۸) در صورتی که در یک زیرشبکه یا یک شبکه اشتراکی پیکربندی شده باشد، توسط \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> به شیوه خاصی که در RFC 8925 \% شرح داده شده است مدیریت می‌شود: هنگامی که کلاینت این گزینه را درخواست می‌کند (یعنی کد ۱۰۸ را در گزینه فهرست درخواست پارامترهای DHCP قرار می‌دهد) و زیرشبکه یا شبکه اشتراکی انتخاب می‌شود، آدرس 0.0.0.0 پیشنهاد شده و گزینه در پاسخ بازگردانده می‌شود..SS پیکربندی بی‌حالت کارخواه‌های DHCPv4 .sp کارساز DHCPv4 از پیکربندی بی‌حالت (stateless) کارخواه پشتیبانی می‌کند، که در آن یک نشانی IP برای کارخواه پیکربندی شده است (برای نمونه با استفاده از پیکربندی دستی) و تنها برای دریافت دیگر پارامترهای پیکربندی مانند نشانی کارسازهای DNS با کارساز ارتباط برقرار می‌کند. جهت دریافت پارامترهای پیکربندی بی‌حالت، کارخواه پیام DHCPINFORM را با مقداردهی \fBciaddr\fP به نشانی‌ای که کارخواه در حال حاضر استفاده می‌کند به کارساز می‌فرستد. کارساز پیام DHCPACK را به‌صورت تک‌پخشی (unicast) به کارخواه ارسال می‌کند که شامل پیکربندی بی‌حالت است (\(dqyiaddr\(dq تنظیم نشده است). .sp کارساز زمانی به DHCPINFORM پاسخ می‌دهد که کارخواه با زیرشبکه‌ای که در پیکربندی کارساز تعریف شده است مرتبط باشد. نمونه‌ای از پیکربندی زیرشبکه به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqcode\(dq: 6, \(dqdata\(dq: \(dq192.0.2.200,192.0.2.201\(dq, \(dqcsv\-format\(dq: true, \(dqspace\(dq: \(dqdhcp4\(dq } ] } ] } .EE .UNINDENT .UNINDENT .sp این زیرشبکه گزینهٔ یکتایی را مشخص می‌کند که در پاسخ به DHCPINFORM، در پیام DHCPACK برای کارخواه گنجانده خواهد شد. اگر تعریف زیرشبکه صرفاً برای پیکربندی بی‌حالت به کار رود، نیازی به پیکربندی استخر نشانی (pool) ندارد. .sp کارساز در صورت برقراری یکی از شرایط زیر، زیرشبکه را با کارخواه مرتبط خواهد کرد: .INDENT 0.0 .IP \(bu 2 پیام DHCPINFORM بازپخش (relay) شده باشد و \fBgiaddr\fP با زیرشبکهٔ پیکربندی‌شده مطابقت داشته باشد. .IP \(bu 2 پیام DHCPINFORM به‌صورت تک‌پخشی از کارخواه ارسال شده باشد و \fBciaddr\fP با زیرشبکهٔ پیکربندی‌شده مطابقت داشته باشد. .IP \(bu 2 پیام DHCPINFORM به‌صورت تک‌پخشی از کارخواه ارسال شده و \fBciaddr\fP تنظیم نشده باشد، اما نشانی مبدأ بستهٔ IP با زیرشبکهٔ پیکربندی‌شده مطابقت داشته باشد. .IP \(bu 2 پیام DHCPINFORM بازپخش نشده باشد و نشانی IP روی رابطی که پیام در آن دریافت شده است با زیرشبکهٔ پیکربندی‌شده مطابقت داشته باشد. .UNINDENT .SS دسته‌بندی کارخواه‌ها در DHCPv4 .sp کارساز DHCPv4 شامل پشتیبانی از دسته‌بندی کارخواه‌ها (client classification) است. برای بررسی دقیق‌تر فرایند دسته‌بندی، Client Classification \%<#\:classify>\& را ببینید. .sp در موارد خاص، پیکربندی کارساز برای تمایز قائل شدن میان انواع کارخواه‌های DHCP و رفتار متناسب با آن‌ها سودمند است. از دسته‌بندی کارخواه‌ها می‌توان برای تغییر رفتار تقریباً هر بخشی از پردازش پیام‌های DHCP استفاده کرد. Kea در حال حاضر دسته‌بندی کارخواه‌ها را از طریق گزینه‌های اختصاصی و باز کردن باتأخیر گزینهٔ ۴۳ (deferred unpacking)؛ انتخاب زیرشبکه؛ انتخاب استخر؛ تخصیص گزینه‌های گوناگون؛ و برای مودم‌های کابلی، گزینه‌های ویژه جهت استفاده با نشانی کارساز TFTP و فیلد فایل راه‌اندازی (boot file) فراهم می‌کند. .sp می‌توان به Kea دستور داد تا دسترسی به زیرشبکه‌های مشخص را بر پایهٔ اطلاعات دسته محدود سازد. این قابلیت به‌ویژه در مواردی سودمند است که دو نوع دستگاه پیوند (link) مشترکی دارند و انتظار می‌رود از دو زیرشبکهٔ متفاوت سرویس‌دهی شوند. کاربرد اصلی چنین سناریویی شبکه‌های کابلی است، جایی که دو دسته دستگاه وجود دارد: خود مودم کابلی، که باید یک اجاره (lease) از زیرشبکهٔ A به آن تخصیص یابد؛ و همهٔ دستگاه‌های دیگرِ پشت مودم، که باید اجاره‌هایی از زیرشبکهٔ B دریافت کنند. این جداسازی برای جلوگیری از کنجکاوی بیش‌ازحد کاربران نهایی و دستکاری مودم‌های کابلی‌شان ضروری است. برای جزئیات در مورد نحوهٔ برپایی محدودیت‌های دسته روی زیرشبکه‌ها، Configuring Subnets With Class Information \%<#\:classification-subnets>\& را ببینید. .sp زمانی که زیرشبکه‌ها متعلق به یک شبکهٔ اشتراکی (shared network) باشند، دسته‌بندی بر روی انتخاب زیرشبکه اعمال می‌شود و نه استخرها؛ بدین معنا که اگر استخری که انتظار می‌رود کارخواه‌ها از آن استفاده کنند تمام شود، استخری در یک زیرشبکه که به دستهٔ خاصی محدود شده است همچنان می‌تواند توسط کارخواه‌هایی که عضو آن دسته نیستند استفاده شود. محدودیت دسترسی بر پایهٔ اطلاعات دسته در سطح استخرِ درون یک زیرشبکه نیز در دسترس است: Configuring Pools With Class Information \%<#\:classification-pools>\& را ببینید. این ویژگی برای جداسازی کارخواه‌های متعلق به یک زیرشبکه در محدوده‌های نشانی متفاوت کارآمد است. .sp به روشی مشابه، می‌توان یک استخر را با استفاده از دسته‌های داخلی \fBKNOWN\fP یا \fBUNKNOWN\fP محدود کرد تا تنها به کارخواه‌های شناخته‌شده (کارخواه‌هایی که دارای رزرو هستند) سرویس‌دهی کند. نشانی‌ها می‌توانند بدون اختصاص یک نشانی متفاوت به ازای هر رزرو، به کارخواه‌های ثبت‌شده تخصیص یابند: برای نمونه، زمانی که نشانی‌های در دسترس کافی نباشد. تشخیص اینکه آیا رزروی برای یک کارخواه مشخص وجود دارد یا خیر پس از انتخاب زیرشبکه صورت می‌گیرد، بنابراین استفاده از دسته‌های \fBKNOWN\fP/\fBUNKNOWN\fP برای انتخاب یک شبکهٔ اشتراکی یا یک زیرشبکه امکان‌پذیر نیست. .sp فرایند دسته‌بندی در پنج گام انجام می‌شود. گام نخست، بررسی بستهٔ ورودی و تخصیص آن به صفر یا چند دسته است. گام دوم، گزینش زیرشبکه است که احتمالاً بر پایهٔ اطلاعات دسته انجام می‌پذیرد. هنگامی که بستهٔ ورودی در دستهٔ ویژهٔ \fBDROP\fP قرار گیرد، دور انداخته می‌شود (drop) و یک پیام اشکال‌زدایی (debug) ثبت می‌گردد. گام بعدی، ارزیابی عبارت‌های دسته وابسته به دسته‌های داخلی \fBKNOWN\fP/\fBUNKNOWN\fP پس از جستجوی رزرو میزبان (host reservation lookup)، استفاده از آن‌ها برای انتخاب استخر و تخصیص دسته‌ها از رزروهای میزبان است. سپس فهرست دسته‌های مورد نیاز ساخته شده و عبارت هر دسته از فهرست ارزیابی می‌شود؛ زمانی که نتیجه \fBtrue\fP باشد، بسته به‌عنوان عضوی از آن دسته افزوده می‌شود. گام پایانی، تخصیص گزینه‌هاست که این مورد نیز می‌تواند بر پایهٔ اطلاعات دسته باشد. اطلاعات کامل‌تر و دقیق‌تر در Client Classification \%<#\:classify>\& در دسترس است. .sp دو روش اصلی برای دسته‌بندی وجود دارد. روش نخست خودکار است و بر بررسی مقادیر موجود در گزینه‌های دستهٔ سازنده (vendor class options) یا وجود رزرو میزبان تکیه دارد. اطلاعات از این گزینه‌ها استخراج شده، نام دسته‌ای از آن ساخته می‌شود و به فهرست دسته‌های بسته افزوده می‌گردد. روش دوم، عبارتی را مشخص می‌کند که برای هر بسته ارزیابی می‌شود. چنانچه نتیجهٔ ارزیابی \fBtrue\fP باشد، بسته عضوی از آن دسته خواهد بود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پرچم پارامتر سراسری جدید \fBearly\-global\-reservations\-lookup\fP، امکان جستجو برای رزروهای سراسری را پیش از مرحلهٔ انتخاب زیرشبکه فعال می‌سازد. این جستجو شبیه به جستجوی عمومی شرح‌داده‌شده در بالا است، با دو تفاوت: .INDENT 0.0 .IP \(bu 2 جستجو محدود به رزروهای سراسری میزبان است .IP \(bu 2 دستهٔ \fBUNKNOWN\fP هرگز تنظیم نمی‌شود .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در دسته‌بندی کارخواه‌ها باید دقت عمل به خرج داد، زیرا کارخواه‌هایی که معیارهای دسته را برآورده نمی‌کنند به‌سادگی ممکن است از دریافت هرگونه سرویسی محروم شوند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نسخهٔ 3.1.7 برنامهٔ Kea یک دستهٔ ویژهٔ دیگر به نام \fBREJECT\fP اضافه کرد که عملکردی مشابه دستهٔ \fBDROP\fP دارد، اما به‌جای نادیده گرفتن و دور انداختن کامل پرس‌وجوی ورودی، بخش تخصیص اجاره را رد می‌کند؛ بنابراین هیچ پاسخ DHCPOFFER در پاسخ به پرس‌وجوی DHCPDISCOVER ارسال نمی‌شود، و پاسخ به پرس‌وجوی DHCPREQUEST باید یک DHCPNAK باشد. .UNINDENT .UNINDENT.SS تنظیم فیلدهای ثابت در رده‌بندی .sp این امکان وجود دارد که مشخص شود کلاینت‌های متعلق به یک رده‌ی خاص، بسته‌هایی با مقادیر مشخص در فیلدهای ثابتِ معینی دریافت کنند. به‌طور خاص، سه فیلد ثابت پشتیبانی می‌شوند: \fBnext\-server\fP (حاوی یک آدرس IPv4 است که در فیلد \fBsiaddr\fP تنظیم می‌شود)، \fBserver\-hostname\fP (حاوی نام میزبان سرور است، می‌تواند تا ۶۴ بایت طول داشته باشد و در فیلد \fBsname\fP ارسال می‌شود) و \fBboot\-file\-name\fP (حاوی فایل پیکربندی است، می‌تواند تا ۱۲۸ بایت طول داشته باشد و با استفاده از فیلد \fBfile\fP ارسال می‌شود). .sp بدیهی است که راه‌های زیادی برای تخصیص کلاینت‌ها به رده‌های خاص وجود دارد، اما برای کلاینت‌های PXE، گزینه نوع معماری کلاینت (کد ۹۳) به‌طور ویژه‌ای برای ایجاد این تمایز مناسب به نظر می‌رسد. مثال زیر بررسی می‌کند که آیا کلاینت خود را به عنوان یک دستگاه PXE با معماری EFI x86\-64 معرفی می‌کند یا خیر، و در صورت تطابق، چندین فیلد را تنظیم می‌کند. برای مقادیر خاص، بخش 2.1 از RFC 4578 \% اصلاح‌شده توسط بخش خطاهای آن (errata) یا مستندات کلاینت را ببینید. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqipxe_efi_x64\(dq, \(dqtest\(dq: \(dqoption[93].hex == 0x0007\(dq, \(dqnext\-server\(dq: \(dq192.0.2.254\(dq, \(dqserver\-hostname\(dq: \(dqhal9000\(dq, \(dqboot\-file\-name\(dq: \(dq/dev/null\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp اگر یک بسته ورودی با چندین رده مطابقت داشته باشد، مقدار استفاده‌شده برای هر فیلد از اولین رده‌ای خواهد آمد که آن فیلد را مشخص کرده است، بر اساس ترتیبی که رده‌ها به بسته تخصیص داده شده‌اند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 ترتیب رده‌ها همان‌گونه است که در پیکربندی مشخص شده است. .UNINDENT .UNINDENT .SS استفاده از اطلاعات رده سازنده در رده‌بندی .sp سرور بررسی می‌کند که آیا بسته ورودی شامل گزینه شناسه رده سازنده (۶۰) است یا خیر. در صورت وجود، پیشوند \fBVENDOR_CLASS_\fP به محتوای آن گزینه اضافه شده و به عنوان یک رده تفسیر می‌شود. به عنوان مثال، مودم‌های کابلی مدرن این گزینه را با مقدار \fBdocsis3.0\fP ارسال می‌کنند، بنابراین بسته متعلق به رده \fBVENDOR_CLASS_docsis3.0\fP\& خواهد بود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اقدامات خاصی برای کلاینت‌های موجود در \fBVENDOR_CLASS_docsis3.0\fP را می‌توان با تعریف \fBVENDOR_CLASS_docsis3.0\fP و تنظیم مناسب مقادیر \fBnext\-server\fP و \fBboot\-file\-name\fP آن انجام داد. .UNINDENT .UNINDENT .sp این مثال پیکربندی‌ای را با استفاده از یک رده \fBVENDOR_CLASS_\fP که به‌صورت خودکار تولید شده نشان می‌دهد. مدیر شبکه تصمیم گرفته است که آدرس‌های محدوده 192.0.2.10 تا 192.0.2.20 توسط سرور Dhcp4 مدیریت شوند و تنها کلاینت‌های متعلق به رده کلاینت DOCSIS 3.0 مجاز به استفاده از این استخر (pool) باشند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq } ], \(dqclient\-classes\(dq: [ \(dqVENDOR_CLASS_docsis3.0\(dq ] } ], ... } .EE .UNINDENT .UNINDENT .SS تعریف و استفاده از رده‌های سفارشی .sp مثال زیر نشان می‌دهد که چگونه یک رده را با استفاده از یک عبارت و یک زیرشبکه (subnet) را با استفاده از آن رده پیکربندی کنید. این پیکربندی رده‌ای به نام \fBClient_foo\fP\& را تعریف می‌کند. این رده شامل همه کلاینت‌هایی است که شناسه کلاینت آن‌ها (گزینه ۶۱) با رشته \fBfoo\fP\& شروع می‌شود. به اعضای این رده آدرس‌هایی از 192.0.2.10 تا 192.0.2.20 اختصاص داده می‌شود و آدرس سرورهای DNS آن‌ها روی 192.0.2.1 و 192.0.2.2 تنظیم می‌گردد. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient_foo\(dq, \(dqtest\(dq: \(dqsubstring(option[61].hex,0,3) == \(aqfoo\(aq\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqcode\(dq: 6, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq192.0.2.1, 192.0.2.2\(dq } ] }, ... ], \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq } ], \(dqclient\-classes\(dq: [ \(dqClient_foo\(dq ] }, ... ], ... } .EE .UNINDENT .UNINDENT.SS "دسته‌بندی تکمیلی (Additional Classification)" .sp در برخی موارد، محدود کردن دامنه (scope) یک کلاس به یک pool، subnet یا shared network سودمند است. دو پارامتر وجود دارند که برای محدود کردن دامنه کلاس از طریق هدایت سرور به ارزیابی عبارت‌های آزمون (test expressions) در زمان نیاز، به کار می‌روند. .sp پارامتر \fBevaluate\-additional\-classes\fP که فهرستی از نام‌های کلاس را می‌پذیرد و در دامنه pool، subnet و shared network معتبر است. کلاس‌های موجود در این فهرست‌ها به عنوان تکمیلی (additional) علامت‌گذاری شده و پس از انتخاب آن pool/subnet/shared network خاص و پیش از پردازش گزینه‌های خروجی (output\-option) ارزیابی می‌شوند. .sp مورد دوم پرچم مختص هر کلاس \fBonly\-in\-additional\-list\fP است که به‌طور پیش‌فرض \fBfalse\fP می‌باشد. هنگامی که روی \fBtrue\fP تنظیم شود، عبارت آزمون کلاس در زمان دریافت بسته ورودی ارزیابی نمی‌شود، بلکه دیرتر و تنها در صورتی که کلاس در یک فهرست \fBevaluate\-additional\-classes\fP موجود باشد ارزیابی خواهد شد. .sp در این مثال، هنگامی که subnet مشخص‌شده استفاده شود، یک کلاس به بسته ورودی اختصاص می‌یابد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient_foo\(dq, \(dqtest\(dq: \(dqmember(\(aqALL\(aq)\(dq, \(dqonly\-in\-additional\-list\(dq: true }, ... ], \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq } ], \(dqevaluate\-additional\-classes\(dq: [ \(dqClient_foo\(dq ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp ارزیابی تکمیلی می‌تواند برای بیان وابستگی‌های پیچیده مانند عضویت در subnet استفاده شود. همچنین می‌تواند برای معکوس کردن اولویت‌ها (precedence) به کار رود؛ اگر \fBoption\-data\fP در یک subnet تنظیم شود، نسبت به \fBoption\-data\fP در یک کلاس اولویت دارد. اگر \fBoption\-data\fP به یک کلاس الزامی منتقل شده و در subnet الزامی شود، کلاسی که زودتر ارزیابی شده است ممکن است اولویت یابد. .sp ارزیابی تکمیلی در سطوح shared network و pool نیز در دسترس است. ترتیبی که در آن کلاس‌های تکمیلی در نظر گرفته می‌شوند به این صورت است: pool، subnet و shared network؛ یعنی به همان ترتیبی که \fBoption\-data\fP پردازش می‌شود. .sp از نسخه 2.7.4 نرم‌افزار Kea، کلاس‌های تکمیلی پیکربندی‌شده بدون عبارت آزمون به‌طور بدون قید و شرط اضافه می‌شوند؛ یعنی در نظر گرفته می‌شود که همیشه به \fBtrue\fP ارزیابی می‌شوند\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از آنجا که ارزیابی تکمیلی پس از تخصیص اجاره (lease assignment) رخ می‌دهد، پارامترهایی که در غیر این صورت بر طول عمر اجاره تأثیر می‌گذاشتند (مانند \fBvalid\-lifetime\fP و \fBoffer\-lifetime\fP)، هنگامی که در کلاسی مشخص شوند که \fBonly\-in\-additional\-list\fP آن نیز روی true تنظیم شده باشد، هیچ اثری نخواهند داشت. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 2.7.4 نرم‌افزار Kea، شناسه‌های \fBonly\-if\-required\fP و \fBrequire\-client\-classes\fP به‌ترتیب به \fBonly\-in\-additional\-list\fP و \fBevaluate\-additional\-classes\fP تغییر نام یافته‌اند. نام‌های اولیه همچنان به‌عنوان ورودی پذیرفته می‌شوند تا به کاربران اجازه مهاجرت داده شود، اما در نهایت رد خواهند شد. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 گزینه‌های Vendor\-Identifying Vendor Options یک حالت خاص هستند: برای سایر گزینه‌ها، یک گزینه بر اساس نقطه کد (code point) خود شناسایی می‌شود، اما \fBvivco\-suboptions\fP (کد 124) و \fBvivso\-suboptions\fP (کد 125) بر اساس جفت نقطه کد و شناسه فروشنده (vendor identifier) شناسایی می‌شوند. این موضوع تأثیر مشهودی بر \fBvivso\-suboptions\fP ندارد، چرا که مقدار آن همان شناسه فروشنده است، اما برای \fBvivco\-suboptions\fP متفاوت است؛ جایی که مقدار، یک رکورد شامل شناسه فروشنده و یک مقدار باینری است. برای نمونه، در: .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqvivco\-suboptions\(dq, \(dqalways\-send\(dq: true, \(dqdata\(dq: \(dq1234, 03666f6f\(dq }, { \(dqname\(dq: \(dqvivco\-suboptions\(dq, \(dqalways\-send\(dq: true, \(dqdata\(dq: \(dq5678, 03626172\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp اولین مدخل \fBoption\-data\fP مدخل دوم را پنهان نمی‌کند، زیرا شناسه‌های فروشنده (1234 و 5678) متفاوت هستند: پاسخ‌ها حامل دو نمونه از گزینه \fBvivco\-suboptions\fP خواهند بود که هر کدام مربوط به یک فروشنده متفاوت است..SS "DDNS برای DHCPv4" .sp همان‌طور که پیش‌تر ذکر شد، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> می‌تواند برای ایجاد درخواست‌ها به کارساز DHCP\-DDNS، یعنی \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>، (که در اینجا از آن با عنوان \(dqD2\(dq یاد می‌شود) جهت به‌روزرسانی مدخل‌های DNS پیکربندی شود. این درخواست‌ها تحت عنوان NameChangeRequests یا NCRها شناخته می‌شوند. هر NCR شامل اطلاعات زیر است: .INDENT 0.0 .IP 1. 3 آیا درخواستی برای افزودن (به‌روزرسانی) یا حذف مدخل‌های DNS است. .IP 2. 3 آیا تغییر، درخواست به‌روزرسانی‌های مستقیم DNS (رکوردهای A)، به‌روزرسانی‌های معکوس DNS (رکوردهای PTR) یا هر دو را دارد. .IP 3. 3 نام دامنه کاملاً مشخص (FQDN)، نشانی اجاره (lease) و DHCID (اطلاعات شناسایی کلاینت مرتبط با FQDN). .UNINDENT .sp پارامترهای مرتبط با DDNS به دو گروه تقسیم می‌شوند: .INDENT 0.0 .IP 1. 3 پارامترهای اتصال (Connectivity Parameters) .INDENT 3.0 .INDENT 3.5 این‌ها پارامترهایی هستند که مشخص می‌کنند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> کجا و چگونه به D2 متصل شده و با آن ارتباط برقرار می‌کند. این پارامترها تنها می‌توانند در بخش سطح‌بالای \fBdhcp\-ddns\fP در پیکربندی \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> مشخص شوند. پارامترهای اتصال در زیر فهرست شده‌اند: .INDENT 0.0 .IP \(bu 2 \fBenable\-updates\fP .IP \(bu 2 \fBserver\-ip\fP .IP \(bu 2 \fBserver\-port\fP .IP \(bu 2 \fBsender\-ip\fP .IP \(bu 2 \fBsender\-port\fP .IP \(bu 2 \fBmax\-queue\-size\fP .IP \(bu 2 \fBncr\-protocol\fP .IP \(bu 2 \fBncr\-format\fP .UNINDENT .UNINDENT .UNINDENT .IP 2. 3 پارامترهای رفتاری (Behavioral Parameters) .INDENT 3.0 .INDENT 3.5 این پارامترها بر رفتارهایی مانند نحوه مدیریت نام‌های میزبان کلاینت و گزینه‌های FQDN تأثیر می‌گذارند. آن‌ها از بخش \fBdhcp\-ddns\fP خارج شده‌اند تا بتوان آن‌ها را در سطوح global، shared\-network، subnet و/یا pool تعیین کرد. علاوه بر این، آن‌ها به صورت رو به پایین از global به shared\-network به subnet و به pool به ارث می‌رسند. به عبارت دیگر، اگر پارامتری در یک سطح معین مشخص نشده باشد، مقدار آن سطح از سطح بالایی گرفته می‌شود. پارامترهای رفتاری به شرح زیر هستند: .INDENT 0.0 .IP \(bu 2 \fBddns\-send\-updates\fP .IP \(bu 2 \fBddns\-override\-no\-update\fP .IP \(bu 2 \fBddns\-override\-client\-update\fP .IP \(bu 2 \fBddns\-replace\-client\-name\fP .IP \(bu 2 \fBddns\-generated\-prefix\fP .IP \(bu 2 \fBddns\-qualifying\-suffix\fP .IP \(bu 2 \fBddns\-update\-on\-renew\fP .IP \(bu 2 \fBddns\-conflict\-resolution\-mode\fP .IP \(bu 2 \fBddns\-ttl\fP .IP \(bu 2 \fBddns\-ttl\-percent\fP .IP \(bu 2 \fBddns\-ttl\-min\fP .IP \(bu 2 \fBddns\-ttl\-max\fP .IP \(bu 2 \fBhostname\-char\-set\fP .IP \(bu 2 \fBhostname\-char\-replacement\fP .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 Kea 2.7.6 پشتیبانی از این پارامترها را به سطح pool اضافه کرد. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پارامترهای رفتاری که بر FQDN تأثیر می‌گذارند، حتی اگر هر دو پارامتر \fBenable\-updates\fP و \fBddns\-send\-updates\fP برابر \fBfalse\fP باشند نیز اعمال می‌شوند، تا از محیط‌هایی که در آن‌ها کلاینت‌ها خود مسئول به‌روزرسانی‌های DNS خود هستند پشتیبانی شود. این قاعده شامل \fBddns\-replace\-client\-name\fP، \fBddns\-generated\-prefix\fP، \fBddns\-qualifying\-suffix\fP، \fBhostname\-char\-set\fP و \fBhostname\-char\-replacement\fP\& می‌شود. .UNINDENT .UNINDENT .sp پیکربندی و مقادیر پیش‌فرض به شکل زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqdhcp\-ddns\(dq: { // Connectivity parameters \(dqenable\-updates\(dq: false, \(dqserver\-ip\(dq: \(dq127.0.0.1\(dq, \(dqserver\-port\(dq:53001, \(dqsender\-ip\(dq:\(dq\(dq, \(dqsender\-port\(dq:0, \(dqmax\-queue\-size\(dq:1024, \(dqncr\-protocol\(dq:\(dqUDP\(dq, \(dqncr\-format\(dq:\(dqJSON\(dq }, // Behavioral parameters (global) \(dqddns\-send\-updates\(dq: true, \(dqddns\-override\-no\-update\(dq: false, \(dqddns\-override\-client\-update\(dq: false, \(dqddns\-replace\-client\-name\(dq: \(dqnever\(dq, \(dqddns\-generated\-prefix\(dq: \(dqmyhost\(dq, \(dqddns\-qualifying\-suffix\(dq: \(dq\(dq, \(dqddns\-update\-on\-renew\(dq: false, \(dqddns\-conflict\-resolution\-mode\(dq: \(dqcheck\-with\-dhcid\(dq, \(dqhostname\-char\-set\(dq: \(dq[^A\-Za\-z0\-9.\-]\(dq, \(dqhostname\-char\-replacement\(dq: \(dqx\(dq, ... } .EE .UNINDENT .UNINDENT .sp دو پارامتر وجود دارند که تعیین می‌کنند آیا \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> می‌تواند درخواست‌های DDNS را به D2 ارسال کند یا خیر: پارامتر موجود \fBdhcp\-ddns:enable\-updates\fP که اکنون تنها کنترل می‌کند آیا \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> به D2 متصل شود یا خیر؛ و پارامتر رفتاری جدید، \fBddns\-send\-updates\fP، که مشخص می‌کند آیا به‌روزرسانی‌های DDNS در یک سطح مشخص (مانند global، shared\-network یا subnet) فعال هستند یا خیر. جدول زیر نحوه عملکرد هم‌زمان این دو پارامتر را نشان می‌دهد:.SS فعال‌سازی و غیرفعال‌سازی به‌روزرسانی‌های DDNS .TS box center; l|l|l. T{ dhcp\-ddns: enable\-updates T} T{ سراسری ddns\-send\-updates T} T{ نتیجه T} _ T{ false (پیش‌فرض) T} T{ false T} T{ عدم به‌روزرسانی در هیچ حوزه‌ای T} _ T{ false T} T{ true (پیش‌فرض) T} T{ عدم به‌روزرسانی در هیچ حوزه‌ای T} _ T{ true T} T{ false T} T{ به‌روزرسانی تنها در حوزه‌هایی با مقدار محلی \fBtrue\fP برای \fBddns\-enable\-updates\fP T} _ T{ true T} T{ true T} T{ به‌روزرسانی در تمام حوزه‌ها به جز مواردی با مقدار محلی \fBfalse\fP برای \fBddns\-enable\-updates\fP T} .TE .sp در Kea 1.9.1 دو پارامتر جدید اضافه شد؛ نخستین مورد \fBddns\-update\-on\-renew\fP است\&. به‌طور معمول، هنگام تمدید اجاره‌ها، کارساز تنها در صورتی DNS را به‌روزرسانی می‌کند که اطلاعات DNS مربوط به اجاره (مانند FQDN یا پرچم‌های جهت به‌روزرسانی DNS) تغییر کرده باشد. تنظیم \fBddns\-update\-on\-renew\fP روی \fBtrue\fP به کارساز دستور می‌دهد هنگام تمدید اجاره همواره اطلاعات DNS را به‌روز کند، حتی اگر اطلاعات DNS آن تغییر نکرده باشد. این ویژگی به Kea امکان می‌دهد در صورتی که پیش‌تر نتوانسته ورودی‌های DNS را اضافه کند یا آن‌ها به نحوی توسط کارساز DNS از دست رفته باشند، «خودترمیمی» (\(dqself\-heal\(dq) کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تنظیم \fBddns\-update\-on\-renew\fP روی \fBtrue\fP ممکن است بر کارایی تأثیر منفی بگذارد، به‌ویژه برای کارسازهایی با کلاینت‌های متعدد که مکرراً تمدید انجام می‌دهند. .UNINDENT .UNINDENT .sp دومین پارامتر اضافه‌شده در Kea 1.9.1 پارامتر \fBddns\-use\-conflict\-resolution\fP است\&. این پارامتر بولی به D2 فرستاده می‌شد و حل تداخل را طبق توصیفات RFC 4703 \% فعال یا غیرفعال می‌کرد\&. از Kea 2.5.0 به بعد، این پارامتر منسوخ شده و با \fBddns\-conflict\-resolution\-mode\fP جایگزین شده است که چهار حالت رفتاری مرتبط با حل تداخل را ارائه می‌دهد: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBcheck\-with\-dhcid\fP \- این حالت (پیش‌فرض)، به D2 دستور می‌دهد تا حل تداخل منطبق با RFC 4703 را انجام دهد. ورودی‌های موجود DNS تنها در صورتی ممکن است بازنویسی شوند که دارای رکورد DHCID باشند و با DHCID کلاینت مطابقت داشته باشد. این معادل \fBddns\-use\-conflict\-resolution\fP: \fBtrue\fP است؛ .IP \(bu 2 \fBno\-check\-with\-dhcid\fP \- ورودی‌های موجود DNS می‌توانند توسط هر کلاینتی بازنویسی شوند، فارغ از اینکه آن ورودی‌ها شامل رکورد DHCID باشند یا خیر. ورودی‌های جدید شامل رکورد DHCID برای کلاینتی خواهند بود که به آن تعلق دارند. این معادل \fBddns\-use\-conflict\-resolution\fP: \fBfalse\fP است؛ .IP \(bu 2 \fBcheck\-exists\-with\-dhcid\fP \- ورودی‌های موجود DNS تنها در صورتی بازنویسی می‌شوند که دارای رکورد DHCID باشند. لزومی ندارد رکورد DHCID با DHCID کلاینت مطابقت داشته باشد. این حالت راهکاری برای محافظت از ورودی‌های ایستا DNS (آن‌هایی که رکورد DHCID ندارند) فراهم می‌کند در حالی که اجازه می‌دهد ورودی‌های پویا (آن‌هایی که دارای رکورد DHCID هستند) توسط هر کلاینتی بازنویسی شوند. این رفتار پیش از Kea 2.4.0 پشتیبانی نمی‌شد. .IP \(bu 2 \fBno\-check\-without\-dhcid\fP \- ورودی‌های موجود DNS می‌توانند توسط هر کلاینتی بازنویسی شوند؛ ورودی‌های جدید شامل رکوردهای DHCID نخواهند بود. این رفتار پیش از Kea 2.4.0 پشتیبانی نمی‌شد. .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برای سازگاری رو به عقب، \fBddns\-use\-conflict\-resolution\fP همچنان در پیکربندی JSON پذیرفته می‌شود. کارساز این مقدار را در درون خود با \fBddns\-conflict\-resolution\-mode\fP و مقدار مناسب جایگزین می‌کند: \fBcheck\-with\-dhcid\fP برای \fBtrue\fP و \fBno\-check\-with\-dhcid\fP برای \fBfalse\fP\&. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تنظیم \fBddns\-conflict\-resolution\-mode\fP روی هر مقداری غیر از \fBcheck\-with\-dhcid\fP، تدابیر حفاظتی بازنویسی را که قواعد حل تداخل (برگرفته از RFC 4703 \%) به‌منظور جلوگیری از آن‌ها تعبیه شده‌اند، غیرفعال می‌کند. این بدان معناست که ورودی‌های موجود برای یک FQDN یا یک نشانی IP که برای Client\-A ایجاد شده‌اند، می‌توانند توسط ورودی‌های Client\-B حذف یا جایگزین شوند. علاوه بر این، دو سناریو وجود دارد که طی آن‌ها ورودی‌های چند کلاینت برای یک کلید یکسان (مانند FQDN یا IP) ایجاد می‌شود: .sp ۱. کلاینت Client\-B از همان FQDN مربوط به Client\-A ولی یک نشانی IP متفاوت استفاده کند. در این حالت، ورودی‌های رو به جلو DNS (رکوردهای منبع A و DHCID) برای Client\-A حذف خواهند شد چون با FQDN مطابقت دارند، و ورودی‌های جدید برای Client\-B اضافه خواهند شد. با این حال، ورودی‌های معکوس DNS (رکوردهای منبع PTR و DHCID) برای Client\-A حذف نخواهند شد زیرا به نشانی IP متفاوتی تعلق دارند، در حالی که ورودی‌های جدید برای Client\-B همچنان افزوده خواهند شد. .sp ۲. کلاینت Client\-B از همان نشانی IP مربوط به Client\-A ولی یک FQDN متفاوت استفاده کند. در این حالت، ورودی‌های معکوس DNS (رکوردهای منبع PTR و DHCID) برای Client\-A حذف خواهند شد چون با نشانی IP مطابقت دارند، و ورودی‌های جدید برای Client\-B اضافه خواهند شد. اما ورودی‌های رو به جلو DNS (رکوردهای منبع A و DHCID) برای Client\-A حذف نخواهند شد، زیرا به یک FQDN متفاوت تعلق دارند، در حالی که ورودی‌های جدید برای Client\-B همچنان افزوده خواهند شد. .sp غیرفعال‌سازی حل تداخل تنها باید پس از بررسی دقیق موارد کاربرد خاص انجام گیرد. بهترین راه برای جلوگیری از ورودی‌های ناخواسته DNS این است که همیشه اطمینان حاصل شود پیش از تخصیص مجدد FQDNها یا نشانی‌های IP، تغییرات اجاره‌ها از طریق Kea پردازش شوند؛ چه آزاد شوند، چه منقضی گردند یا از طریق دستور \fBlease4\-del\fP \%<#\:std-isccmd-lease4-del> حذف شوند. انجام این کار باعث می‌شود \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> درخواست‌های حذف DNS را به D2 ارسال کند. .UNINDENT .UNINDENT .sp ورودی‌های DNS که Kea می‌سازد حاوی مقداری برای TTL (طول عمر) هستند. به‌طور پیش‌فرض، کارساز \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> این مقدار را بر اساس RFC 4702، بخش ۵ \% محاسبه می‌کند که پیشنهاد می‌دهد مقدار TTL برابر ۱/۳ طول عمر اجاره با حداقل مقدار ۱۰ دقیقه باشد. چهار پارامتر اختیاری وجود دارند که می‌توان از آن‌ها برای تأثیرگذاری بر محاسبه TTL استفاده کرد: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBddns\-ttl\fP \- در صورت تعیین و بزرگ‌تر بودن از ۰، بدون قید و شرط به عنوان مقدار TTL استفاده می‌شود. این مقدار بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض نامشخص است. .IP \(bu 2 \fBddns\-ttl\-percent\fP \- در صورت تعیین و بزرگ‌تر بودن از صفر، به عنوان درصد طول عمر اجاره استفاده می‌شود، در غیر این صورت از ۱/۳ (طبق RFC 4702) طول عمر اجاره استفاده خواهد شد. این پارامتر به عنوان یک درصد اعشاری (مانند 0.75، 0.50) مشخص می‌شود و به‌طور پیش‌فرض نامشخص است. .IP \(bu 2 \fBddns\-ttl\-min\fP \- در صورت تعیین و بزرگ‌تر بودن از ۰، به عنوان حداقل مقدار استفاده می‌شود؛ در غیر این صورت حداقل ۶۰۰ ثانیه (طبق RFC 4702) به کار می‌رود. اگر TTL محاسبه‌شده کمتر از مقدار حداقل باشد، حداقل بازگردانده می‌شود. این پارامتر بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض نامشخص است. .IP \(bu 2 \fBddns\-ttl\-max\fP \- در صورت تعیین و بزرگ‌تر بودن از صفر، مقدار محاسبه‌شده TTL را به مقدار آن محدود می‌کند. این مقدار بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض نامشخص است. .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مقدار صفر برای هر یک از پارامترهای TTL می‌تواند برای باطل کردن (یعنی «نامشخص کردن» یا \(dqunspecify\(dq) مقدار آن پارامتر که از یک حوزه بالاتر به ارث رسیده است، استفاده شود. .UNINDENT .UNINDENT.SS اتصال به سرور DHCP\-DDNS .sp برای اینکه NCRها به سرور D2 برسند، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> باید قادر به برقراری ارتباط با آن باشد. \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> از پارامترهای پیکربندی زیر برای کنترل این ارتباط استفاده می‌کند: .INDENT 0.0 .IP \(bu 2 \fBenable\-updates\fP \- اتصال به \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> را فعال می‌کند تا به‌روزرسانی‌های DDNS ساخته و ارسال شوند. برای اینکه NCRها تولید و به D2 فرستاده شوند، این مقدار باید \fBtrue\fP باشد. مقدار پیش‌فرض آن \fBfalse\fP است\&. .IP \(bu 2 \fBserver\-ip\fP \- این آدرس IP است که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض رابط محلی لوپ‌بک با آدرس 127.0.0.1 است. می‌توان هر یک از آدرس‌های IPv4 یا IPv6 را مشخص کرد. .IP \(bu 2 \fBserver\-port\fP \- این پورتی است که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض \fB53001\fP است\&. .IP \(bu 2 \fBsender\-ip\fP \- این آدرس IP است که \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> برای ارسال درخواست‌ها به D2 از آن استفاده می‌کند. مقدار پیش‌فرض خالی است، که به \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> دستور می‌دهد یک آدرس مناسب را انتخاب کند. .IP \(bu 2 \fBsender\-port\fP \- این پورتی است که \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> برای ارسال درخواست‌ها به D2 از آن استفاده می‌کند. مقدار پیش‌فرض \fB0\fP به \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> دستور می‌دهد یک پورت مناسب را انتخاب نماید. .IP \(bu 2 \fBmax\-queue\-size\fP \- این حداکثر تعداد درخواست‌های مجاز برای قرارگیری در صف هنگام انتظار برای ارسال به D2 است. این مقدار از انباشت مهارنشدنی درخواست‌ها در صورتی که سریع‌تر از توان تحویل تولید شوند، جلوگیری می‌کند. اگر تعداد درخواست‌های در صف برای مخابره به این مقدار برسد، به‌روزرسانی DDNS غیرفعال می‌شود تا زمانی که تراکم صف به اندازه کافی کاهش یابد. هدف این است که به سرور \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> اجازه داده شود بدون پذیرش ریسک رشد نامحدود حافظه، به عملیات اجاره (lease) ادامه دهد. مقدار پیش‌فرض \fB1024\fP است\&. .IP \(bu 2 \fBncr\-protocol\fP \- پروتکل سوکت مورد استفاده هنگام ارسال درخواست‌ها به D2 را مشخص می‌کند. در حال حاضر فقط UDP پشتیبانی می‌شود. .IP \(bu 2 \fBncr\-format\fP \- قالب بسته (packet format) برای ارسال درخواست‌ها به D2 را مشخص می‌کند. در حال حاضر فقط قالب JSON پشتیبانی می‌شود. .UNINDENT .sp به‌طور پیش‌فرض، فرض می‌شود که \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> روی همان ماشینی اجرا می‌شود که \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> روی آن فعال است، و تمام مقادیر پیش‌فرض ذکرشده در بالا باید کافی باشند. با این حال، اگر D2 به گونه‌ای پیکربندی شده باشد که روی آدرس یا پورت دیگری گوش دهد، این مقادیر باید بر همین اساس تغییر یابند. برای مثال، اگر D2 برای گوش دادن روی آدرس 192.168.1.10 و پورت 900 پیکربندی شده باشد، پیکربندی زیر الزامی است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqdhcp\-ddns\(dq: { \(dqserver\-ip\(dq: \(dq192.168.1.10\(dq, \(dqserver\-port\(dq: 900, ... }, ... } .EE .UNINDENT .UNINDENT .SS چه زمانی سرور \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یک درخواست DDNS ایجاد می‌کند؟ .sp سرور \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> از رفتار مقررشده برای سرورهای DHCP در RFC 4702 \%\& پیروی می‌کند. توجه به این نکته مهم است که \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> تصمیم اولیه مبنی بر زمان و مواردی که باید به‌روزرسانی شوند را اتخاذ می‌کند و آن اطلاعات را در قالب NCRها به D2 می‌فرستد. انجام به‌روزرسانی‌های واقعی DNS و رسیدگی به مسائلی همچون حل تعارض (conflict resolution) در حیطه وظایف خود D2 است (بخش The DHCP\-DDNS Server \%<#\:dhcp-ddns-server> را ببینید). این بخش توضیح می‌دهد که \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> چه زمانی NCRها را ایجاد می‌کند و از چه پارامترهای پیکربندی می‌توان برای تأثیرگذاری بر این تصمیم استفاده نمود. فرض این بخش بر این است که هم پارامتر اتصال \fBenable\-updates\fP و هم پارامتر رفتاری \fBddns\-send\-updates\fP روی \fBtrue\fP تنظیم شده‌اند\&. .sp به‌طور کلی، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> درخواست‌های به‌روزرسانی DDNS را در مواقع زیر ایجاد می‌کند: .INDENT 0.0 .IP 1. 3 یک اجاره جدید در پاسخ به یک DHCPREQUEST اعطا شود؛ .IP 2. 3 یک اجاره موجود تمدید شود اما FQDN مرتبط با آن تغییر کرده باشد؛ یا .IP 3. 3 یک اجاره موجود در پاسخ به یک DHCPRELEASE آزاد شود. .UNINDENT .sp در حالت دوم (تمدید اجاره)، دو درخواست DDNS صادر می‌شود: یک درخواست برای حذف ورودی‌های مربوط به FQDN قبلی، و درخواست دوم برای افزودن ورودی‌های FQDN جدید. در حالت سوم (آزادسازی اجاره)، یک درخواست DDNS تکی برای حذف ورودی‌های آن ارسال می‌شود. .sp اما در مورد حالت اول، تصمیمات مرتبط با اعطای اجاره جدید پیچیده‌تر است. هنگامی که یک اجاره جدید اعطا می‌شود، چنانچه DHCPREQUEST شامل گزینه FQDN (کد 81) یا گزینه Host Name (کد 12) باشد، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یک درخواست به‌روزرسانی DDNS ایجاد می‌کند. اگر هر دو گزینه موجود باشند، سرور از گزینه FQDN استفاده می‌کند. به‌طور پیش‌فرض، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> به پرچم‌های N و S مشخص‌شده توسط کلاینت برای FQDN، مطابق با جدول زیر احترام می‌گذارد: .SS رفتار پیش‌فرض پرچم‌های FQDN .TS box center; l|l|l|l. T{ پرچم‌های کلاینت: N\-S T} T{ قصد کلاینت T} T{ پاسخ سرور T} T{ پرچم‌های سرور: N\-S\-O T} _ T{ 0\-0 T} T{ کلاینت می‌خواهد به‌روزرسانی‌های مستقیم را انجام دهد، سرور باید به‌روزرسانی‌های معکوس را اعمال کند T} T{ سرور فقط درخواست به‌روزرسانی معکوس تولید می‌کند T} T{ 1\-0\-0 T} _ T{ 0\-1 T} T{ سرور باید هر دو به‌روزرسانی مستقیم و معکوس را انجام دهد T} T{ سرور درخواستی برای به‌روزرسانی هر دو جهت تولید می‌کند T} T{ 0\-1\-0 T} _ T{ 1\-0 T} T{ کلاینت می‌خواهد هیچ به‌روزرسانی‌ای انجام نشود T} T{ سرور درخواستی تولید نمی‌کند T} T{ 1\-0\-0 T} .TE .sp سطر اول در جدول بالا بیانگر \(dqواگذاری به کلاینت (client delegation)\(dq است. در اینجا کلاینت DHCP اعلام می‌کند که قصد دارد به‌روزرسانی‌های مستقیم DNS را خود انجام دهد و سرور باید به‌روزرسانی‌های معکوس را اعمال کند. به‌طور پیش‌فرض، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> به خواسته کلاینت احترام می‌گذارد و درخواستی برای DDNS به سرور D2 فقط جهت به‌روزرسانی داده‌های معکوس DNS ارسال می‌کند. از پارامتر \fBddns\-override\-client\-update\fP می‌توان برای واداشتن سرور به لغو و نادیده گرفتن درخواست‌های واگذاری به کلاینت استفاده کرد. هنگامی که این پارامتر \fBtrue\fP باشد، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> درخواست‌های واگذاری به کلاینت را نادیده گرفته و یک درخواست DDNS برای به‌روزرسانی داده‌های مستقیم و معکوس DNS تولید می‌کند. در این حالت، پرچم‌های N\-S\-O در پاسخ سرور به کلاینت به ترتیب 0\-1\-1 خواهند بود. .sp (توجه داشته باشید که بر اساس RFC 4702 \%\&، ترکیب پرچم‌های N=1, S=1 ممنوع است. در صورت دریافت چنین ترکیبی از سوی کلاینت، بسته توسط \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> دور انداخته می‌شود\&.) .sp برای لغو واگذاری به کلاینت، مقادیر زیر را در فایل پیکربندی تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqddns\-override\-client\-update\(dq: true, ... } .EE .UNINDENT .UNINDENT .sp سطر سوم جدول بالا وضعیتی را توصیف می‌کند که در آن کلاینت درخواست می‌کند هیچ به‌روزرسانی در DNS انجام نشود. از پارامتر \fBddns\-override\-no\-update\fP می‌توان برای واداشتن سرور به نادیده گرفتن خواسته کلاینت استفاده کرد. هنگامی که این پارامتر \fBtrue\fP باشد، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> حتی اگر کلاینت درخواست عدم به‌روزرسانی داده باشد، درخواست‌های به‌روزرسانی DDNS را به \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> ارسال می‌کند. پرچم‌های N\-S\-O در پاسخ سرور به کلاینت 0\-1\-1 خواهند بود. .sp برای لغو واگذاری به کلاینت، دستورات زیر را اعمال کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqddns\-override\-no\-update\(dq: true, ... } .EE .UNINDENT .UNINDENT .sp سرور \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> همواره در صورتی که درخواست کلاینت تنها شامل گزینه Host Name باشد، درخواست‌های به‌روزرسانی DDNS را تولید می‌کند. افزون بر این، یک گزینه FQDN را با پرچم‌های FQDN N\-S\-O که به ترتیب روی 0\-1\-0 تنظیم شده‌اند در پاسخ به کلاینت می‌گنجاند. بخش نام دامنه در گزینه FQDN، همان نامی است که در درخواست به‌روزرسانی DDNS به D2 ارسال می‌شود..SS \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> \- تولید نام برای درخواست‌های به‌روزرسانی DDNS .sp هر NameChangeRequest مسلماً باید شامل نام دامنه کاملاً واجد شرایط (FQDN) باشد که ورودی‌های DNS آن قرار است تحت تأثیر قرار گیرند. می‌توان \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> را طوری پیکربندی کرد که بر اساس آنچه در DHCPREQUEST از کلاینت دریافت می‌کند، بخشی از آن نام یا تمام آن را فراهم نماید. .sp قوانین پیش‌فرض برای ساخت FQDN که برای ورودی‌های DNS استفاده خواهد شد، عبارتند از: .INDENT 0.0 .IP 1. 3 اگر DHCPREQUEST حاوی گزینه FQDN کلاینت باشد، نام کاندید از آن گرفته می‌شود؛ در غیر این صورت، از گزینه Host Name اخذ خواهد شد. .IP 2. 3 اگر نام کاندید یک نام جزئی (یعنی کامل‌نشده یا unqualified) باشد، یک پسوند قابل‌پیکربندی به نام اضافه شده و نتیجه به عنوان FQDN استفاده می‌شود. .IP 3. 3 اگر نام کاندید ارائه‌شده خالی باشد، با استفاده از یک پیشوند و پسوند قابل‌پیکربندی، یک FQDN تولید می‌شود. .IP 4. 3 اگر کلاینت هیچ‌یک از این دو گزینه را ارائه نکند، هیچ عملیاتی روی DNS انجام نمی‌شود. .UNINDENT .sp این قوانین را می‌توان با تنظیم پارامتر \fBddns\-replace\-client\-name\fP اصلاح کرد، که حالت‌های رفتاری زیر را فراهم می‌کند: .INDENT 0.0 .IP \(bu 2 \fBnever\fP \- استفاده از نامی که کلاینت ارسال کرده است. اگر کلاینت نامی ارسال نکرد، نامی تولید نشود. این حالت پیش‌فرض است. .IP \(bu 2 \fBalways\fP \- جایگزین کردن نام ارسالی کلاینت. اگر کلاینت نامی ارسال نکرد، یکی برای کلاینت تولید شود. .IP \(bu 2 \fBwhen\-present\fP \- جایگزین کردن نام ارسالی کلاینت. اگر کلاینت نامی ارسال نکرد، نامی تولید نشود. .IP \(bu 2 \fBwhen\-not\-present\fP \- استفاده از نامی که کلاینت ارسال کرده است. اگر کلاینت نامی ارسال نکرد، یکی برای کلاینت تولید شود. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در نسخه‌های اولیه Kea، این پارامتر بولی (boolean) بود و تنها مقادیر \fBtrue\fP و \fBfalse\fP\& را می‌پذیرفت. مقادیر بولی منسوخ شده‌اند و دیگر پذیرفته نمی‌شوند. مدیرانی که در حال حاضر از مقادیر بولی استفاده می‌کنند، باید آن‌ها را با نام حالت مورد نظر جایگزین کنند. مقدار \fBtrue\fP به \fBwhen\-present\fP و \fBfalse\fP به \fBnever\fP\& نگاشت می‌شود. .UNINDENT .UNINDENT .sp برای مثال، جهت هدایت \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> به تولید همیشگی FQDN برای یک کلاینت، پارامتر \fBddns\-replace\-client\-name\fP را مطابق زیر روی \fBalways\fP تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqddns\-replace\-client\-name\(dq: \(dqalways\(dq, ... } .EE .UNINDENT .UNINDENT .sp پیشوندی که در تولید FQDN استفاده می‌شود توسط پارامتر \fBddns\-generated\-prefix\fP مشخص می‌گردد. مقدار پیش‌فرض \(dqmyhost\(dq است. برای تغییر مقدار آن، کافی است آن را روی رشته مورد نظر تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqddns\-generated\-prefix\(dq: \(dqanother.host\(dq, ... } .EE .UNINDENT .UNINDENT .sp پسوندی که هنگام تولید یک FQDN یا هنگام کامل کردن (qualifying) یک نام جزئی استفاده می‌شود، توسط پارامتر \fBddns\-qualifying\-suffix\fP مشخص می‌گردد. اکیداً توصیه می‌شود در صورت فعال بودن به‌روزرسانی‌های DDNS، کاربر مقداری برای این پسوند تعیین کند. به دلایل واضح، نمی‌توان مقدار پیش‌فرض معنی‌داری برای آن ارائه داد. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqddns\-qualifying\-suffix\(dq: \(dqfoo.example.org\(dq, ... } .EE .UNINDENT .UNINDENT .sp هنگام کامل کردن یک نام جزئی، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> نام را در این قالب می‌سازد: .sp \fB[candidate\-name].[ddns\-qualifying\-suffix].\fP .sp که در آن \fBcandidate\-name\fP نام جزئی ارائه‌شده در DHCPREQUEST است. برای مثال، اگر مقدار نام دامنه FQDN برابر \(dqsome\-computer\(dq و مقدار \fBddns\-qualifying\-suffix\fP برابر \(dqexample.com\(dq باشد، FQDN تولیدشده عبارت است از: .sp \fBsome\-computer.example.com.\fP .sp هنگام تولید کل نام، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> نام را در این قالب می‌سازد: .sp \fB[ddns\-generated\-prefix]\-[address\-text].[ddns\-qualifying\-suffix].\fP .sp که در آن \fBaddress\-text\fP صرفاً آدرس IP اجاره است که به یک رشته دارای خط پیوند (hyphenated) تبدیل شده است. برای مثال، اگر آدرس اجاره 172.16.1.10 باشد، پسوند تعیین‌شده \(dqexample.com\(dq بوده، و مقدار پیش‌فرض برای \fBddns\-generated\-prefix\fP استفاده شود، FQDN تولیدشده به صورت زیر خواهد بود: .sp \fBmyhost\-172\-16\-1\-10.example.com.\fP .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگامی که کلاینت گزینه host name را ارسال می‌کند، \fBkea\-dhcp4\fP هرگز نقطه‌ای به نام میزبان در گزینه بازگردانده‌شده اضافه نمی‌کند. این نام تنها در صورتی با نقطه پایان می‌یابد که کلاینت آن را از قبل به صورت واجد شرایط و منتهی به نقطه ارسال کرده باشد. هنگامی که کلاینت گزینه FQDN را ارسال می‌کند، FQDN بازگردانده‌شده در پاسخ همیشه با یک نقطه خاتمه می‌یابد. .UNINDENT .UNINDENT.SS پاک‌سازی نام میزبان و نام‌های FQDN کلاینت .sp برخی کلاینت‌های DHCP ممکن است در گزینهٔ Host Name (کد گزینهٔ ۱۲) یا گزینهٔ FQDN (کد گزینهٔ ۸۱) مقادیری ارائه دهند که حاوی نویسه‌های نامطلوب باشد. امکان پیکربندی \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> برای پاک‌سازی این مقادیر وجود دارد. رایج‌ترین مورد استفاده، اطمینان از این است که تنها نویسه‌های مجاز در RFC 1035 گنجانده شوند: A\-Z، a\-z، 0\-9، و \(dq\-\(dq. این کار می‌تواند با استفاده از دو پارامتر زیر انجام شود: .INDENT 0.0 .IP \(bu 2 \fBhostname\-char\-set\fP \- یک عبارت باقاعده که مجموعه نویسه‌های نامعتبر را توصیف می‌کند. این می‌تواند هر عبارت باقاعدهٔ معتبری با استفاده از نحو عبارات باقاعدهٔ گسترش‌یافتهٔ POSIX باشد. نویسه‌های تهی توکار (0x00) همیشه به عنوان یک نویسهٔ نامعتبر برای جایگزینی (یا حذف) در نظر گرفته می‌شوند. پیش‌فرض \fB\(dq[^A\-Za\-z0\-9.\-]\(dq\fP\& است. این الگو با هر نویسه‌ای به جز یک حرف، رقم، نقطه یا خط تیره مطابقت دارد. اکیداً توصیه می‌شود که این پارامتر را روی یک رشتهٔ خالی (\fB\(dq\(dq\fP) تنظیم نکنید، زیرا این کار اجازه می‌دهد نویسه‌های غیرقابل‌چاپ در بخش نام میزبان استفاده شوند. .IP \(bu 2 \fBhostname\-char\-replacement\fP \- رشته‌ای از صفر یا چند نویسه که هر نویسهٔ نامعتبر در نام میزبان با آن جایگزین می‌شود. یک رشتهٔ خالی باعث حذف شدن (OMITTED) نویسه‌های نامعتبر به جای جایگزینی آن‌ها می‌شود. پیش‌فرض \fB\(dq\(dq\fP\& است. .UNINDENT .sp پیکربندی زیر هر چیزی به جز یک حرف، رقم، نقطه یا خط تیره را با حرف \(dqx\(dq جایگزین می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhostname\-char\-set\(dq: \(dq[^A\-Za\-z0\-9.\-]\(dq, \(dqhostname\-char\-replacement\(dq: \(dqx\(dq, ... } .EE .UNINDENT .UNINDENT .sp بنابراین، مقدار ارائه‌شده از سوی کلاینت مانند \(dqmyhost\-$[123.org\(dq تبدیل به \(dqmyhost\-xx123.org\(dq خواهد شد. پاک‌سازی تنها روی بخشی از نام انجام می‌شود که توسط کلاینت ارائه شده است، و پیش از اعمال یک پسوند توصیف‌کننده (qualifying suffix، در صورت تعریف و نیاز) انجام می‌پذیرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هدف از پاک‌سازی نام، مهار موارد متداول‌تر نویسه‌های نامعتبر از طریق یک طرح نسبتاً سادهٔ جایگزینی نویسه است. طراحی طرحی که در تمامی موارد، هم برای گزینهٔ Host Name و هم برای گزینهٔ FQDN به خوبی کار کند دشوار است. مدیرانی که متوجه می‌شوند کلاینت‌هایی با حالات خاص و پیچیده از ترکیب نویسه‌ها دارند که به سادگی با این سازوکار قابل مدیریت نیست، باید نوشتن یک هوک (hook) را مد نظر قرار دهند که بتواند منطق به قدر کافی پیچیده‌ای را برای برآوردن نیازهای آن‌ها پیاده‌سازی کند. .sp اگر کلاینت‌ها نام‌های دامنه را در گزینهٔ Host Name بگنجانند و مدیر سیستم بخواهد این‌ها حفظ شوند، باید اطمینان حاصل کند که نقطه، \(dq.\(dq، توسط عبارت \fBhostname\-char\-set\fP به عنوان یک نویسهٔ معتبر در نظر گرفته شده باشد، مانند این: \fB\(dq[^A\-Za\-z0\-9.\-]\(dq\fP\&. این امر روی نقطه‌ها در مقادیر گزینهٔ FQDN تأثیری ندارد. هنگام پاک‌سازی FQDNها، نقطه‌ها به عنوان جداکننده در نظر گرفته شده و برای تفکیک مقدار گزینه به برچسب‌های دامنهٔ جداگانه استفاده می‌شوند که پاک‌سازی شده و سپس مجدداً سرهم می‌گردند. .sp اگر کلاینت‌ها مقادیری ارسال می‌کنند که تنها در نویسه‌هایی که توسط \fBhostname\-char\-set\fP نامعتبر شناخته شده‌اند تفاوت دارند، آگاه باشید که پاک‌سازی آن‌ها مقادیر یکسانی تولید خواهد کرد. در چنین مواردی، قواعد تداخل DDNS تنها به یکی از آن‌ها اجازهٔ ثبت نام را خواهد داد. .sp در نهایت، با توجه به دامنهٔ اختیاری که کلاینت‌ها در ارسال مقادیر دارند، عملاً غیرممکن است تضمین کرد که ترکیبی از این دو پارامتر همیشه نامی معتبر برای استفاده در DNS تولید کند. به عنوان مثال، استفاده از یک مقدار خالی برای \fBhostname\-char\-replacement\fP می‌تواند منجر به یک برچسب دامنهٔ خالی در یک نام شود، اگر آن برچسب تنها از نویسه‌های نامعتبر تشکیل شده باشد. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 امکان تعیین \fBhostname\-char\-set\fP و/یا \fBhostname\-char\-replacement\fP در حوزهٔ سراسری (global scope) وجود دارد. .sp کتابخانهٔ هوک کی \fBlibdhcp_ddns_tuning.so\fP \%<#\:std-ischooklib-libdhcp_ddns_tuning\:.so> این امکان را هم برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و هم برای \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> فراهم می‌کند تا نام‌های میزبان را به صورت رویه‌ای بر اساس یک عبارت تولید کنند، به‌روزرسانی‌های DDNS را به ازای هر کلاینت نادیده بگیرند، یا جنبه‌های مختلف به‌روزرسانی DNS را به‌دقت تنظیم نمایند. لطفاً برای گزینه‌های پیکربندی به مستندات libdhcp_ddns_tuning.so: DDNS Tuning \%<#\:hooks-ddns-tuning> مراجعه کنید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 با شروع از Kea 3.1.3، هنگامی که پاک‌سازی منجر به یک رشتهٔ خالی شود، گزینه (hostname یا FQDN) به گونه‌ای نادیده گرفته خواهد شد که گویی کلاینت آن را ارسال نکرده است. این حالت زمانی رخ می‌دهد که مقدار ارسال‌شده توسط کلاینت تنها شامل نویسه‌هایی باشد که توسط عبارت در \(aqhostname\-char\-set\(aq نامعتبر تشخیص داده شده‌اند و \(aqhostname\-char\-replacement\(aq خالی باشد، \(dq\(dq. .UNINDENT .UNINDENT .SS سرور بعدی (\fBsiaddr\fP) .sp در برخی موارد، کلاینت‌ها تمایل دارند پیکربندی را از یک سرور TFTP دریافت کنند. اگرچه گزینهٔ اختصاصی برای این منظور وجود دارد، اما برخی دستگاه‌ها ممکن است از فیلد \fBsiaddr\fP در بستهٔ DHCPv4 برای این هدف استفاده کنند. این فیلد خاص می‌تواند با استفاده از دستورالعمل \fBnext\-server\fP پیکربندی شود. امکان تعریف آن در حوزهٔ سراسری یا تنها برای یک زیرشبکهٔ مشخص وجود دارد. اگر هر دو تعریف شده باشند، مقدار زیرشبکه اولویت دارد. مقدار موجود در زیرشبکه می‌تواند روی \(dq0.0.0.0\(dq تنظیم شود، که به این معنی است که \fBnext\-server\fP نباید ارسال شود. همچنین می‌تواند روی یک رشتهٔ خالی تنظیم شود، که معادل با تعریف نشدن کامل آن است؛ یعنی از مقدار سراسری استفاده می‌کند. .sp دستورالعمل‌های \fBserver\-hostname\fP (که حامل یک نام میزبان سرور است، می‌تواند تا ۶۴ بایت طول داشته باشد، و در فیلد \fBsname\fP قرار دارد) و \fBboot\-file\-name\fP (که حامل فایل پیکربندی است، می‌تواند تا ۱۲۸ بایت طول داشته باشد، و با استفاده از فیلد \fBfile\fP ارسال می‌شود) به همان شیوهٔ \fBnext\-server\fP\& مدیریت می‌شوند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqnext\-server\(dq: \(dq192.0.2.123\(dq, \(dqboot\-file\-name\(dq: \(dq/dev/null\(dq, \(dqsubnet4\(dq: [ { \(dqnext\-server\(dq: \(dq192.0.2.234\(dq, \(dqserver\-hostname\(dq: \(dqsome\-name.example.org\(dq, \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, ... } ], ... } .EE .UNINDENT .UNINDENT.SS بازتاب Client\-ID (RFC 6842) .sp مشخصات اصلی DHCPv4 (سند RFC 2131 \%) بیان می‌کند که سرور DHCPv4 نباید هنگام پاسخ‌گویی به کلاینت‌ها، گزینه‌های client\-id را بازپس بفرستد. با این وجود، در برخی موارد این امر باعث سردرگمی کلاینت‌هایی می‌شود که فاقد نشانی MAC یا client\-id هستند؛ برای جزئیات به RFC 6842 \% مراجعه کنید. این رفتار با انتشار RFC 6842 \% تغییر کرد، که RFC 2131 \%\& را به‌روزرسانی نمود. آن به‌روزرسانی بیان می‌کند که اگر کلاینت گزینه client\-id را فرستاده باشد سرور باید آن را بازپس بفرستد، و این رفتار پیش‌فرض Kea است. با این حال، در بعضی موارد ممکن است دستگاه‌های قدیمی‌تری که از RFC 6842 \% پشتیبانی نمی‌کنند، از پذیرش پاسخ‌های حاوی گزینه client\-id خودداری کنند. برای فعال‌سازی سازگاری رو به عقب، یک پارامتر پیکربندی اختیاری معرفی شده است. برای پیکربندی آن، از عبارت پیکربندی زیر استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqecho\-client\-id\(dq: false, ... } .EE .UNINDENT .UNINDENT .SS استفاده از شناسه کلاینت و نشانی سخت‌افزاری .sp سرور DHCP باید بتواند کلاینتی را که پیامی از آن دریافت می‌کند شناسایی کرده و آن را از سایر کلاینت‌ها تمایز دهد. دلایل متعددی برای الزام این شناسایی وجود دارد که مهم‌ترین آن‌ها عبارت‌اند از: .INDENT 0.0 .IP \(bu 2 هنگامی که کلاینت برای تخصیص یک اجاره (lease) جدید با سرور ارتباط برقرار می‌کند، سرور باید اطلاعات شناسایی کلاینت را به عنوان کلید جستجو در پایگاه‌داده اجاره ذخیره کند. .IP \(bu 2 هنگامی که کلاینت تلاش می‌کند اجاره موجود را تمدید کند یا آزاد سازد، سرور باید بتواند با استفاده از اطلاعات شناسایی کلاینت به عنوان یک کلید جستجو، مدخل اجاره موجود در پایگاه‌داده را برای این کلاینت پیدا کند. .IP \(bu 2 برخی پیکربندی‌ها از رزروهای ایستا (static reservations) برای نشانی‌های IP و سایر اطلاعات پیکربندی استفاده می‌کنند. مدیر سرور از اطلاعات شناسایی کلاینت برای ایجاد این تخصیص‌های ایستا بهره می‌برد. .IP \(bu 2 در شبکه‌های دوپشته‌ای (dual\-stack) اغلب نیاز است که اطلاعات اجاره ذخیره‌شده در سرورهای DHCPv4 و DHCPv6 برای یک میزبان مشخص با یکدیگر تطبیق داده شوند. استفاده از اطلاعات شناسایی مشترک توسط کلاینت‌های DHCPv4 و DHCPv6 به مدیر شبکه اجازه می‌دهد تا این همبستگی را برقرار ساخته و شبکه را بهتر اداره نماید. از نگارش 2.1.2 به بعد، Kea از DUIDهای DHCPv6 تعبیه‌شده در گزینه‌های Client Identifier پروتکل DHCPv4، مطابق با آنچه در RFC 4361 \%\& تشریح شده، پشتیبانی می‌کند. .UNINDENT .sp پروتکل DHCPv4 از دو شناسه متمایز استفاده می‌کند که توسط کلاینت در پرس‌وجوهای ارسالی به سرور قرار می‌گیرند و توسط سرور در پاسخ‌های ارسالی به کلاینت کپی می‌شوند: \fBchaddr\fP و \fBclient\-identifier\fP\&. مورد نخست به عنوان بخشی از مشخصات BOOTP معرفی شد و همچنین توسط DHCP برای حمل نشانی سخت‌افزاری رابطی که برای ارسال پرس‌وجو به سرور به کار رفته است (نشانی MAC برای اترنت) استفاده می‌شود. مورد دوم در گزینه client\-identifier حمل می‌شود که در RFC 2132 \%\& معرفی شده است. .sp سند RFC 2131 \% مشخص می‌کند که سرور می‌تواند از هر دوی این شناسه‌ها برای شناسایی کلاینت استفاده کند، اما در صورت حضور شناسه کلاینت، بر \fBchaddr\fP اولویت و ارجحیت دارد. یکی از دلایل این امر آن است که شناسه کلاینت مستقل از سخت‌افزاری است که کلاینت برای برقراری ارتباط با سرور به کار می‌برد. برای مثال، اگر کلاینت با استفاده از یک کارت شبکه اجاره را دریافت کند و سپس کارت شبکه به میزبان دیگری منتقل شود، سرور به اشتباه آن میزبان دیگر را همان دریافت‌کننده اجاره شناسایی خواهد کرد. افزون بر این، سند RFC 4361 \% توصیه می‌کند که هنگام استفاده از شبکه‌های دوپشته‌ای، از یک DUID (ببینید RFC 9915 \%، مشخصات DHCPv6) که به عنوان یک شناسه کلاینت حمل می‌شود استفاده گردد تا بدون توجه به نوع پروتکل مورد استفاده، اطلاعات شناسایی یکپارچه‌ای برای کلاینت ارائه شود. Kea به این مشخصات پایبند است، و شناسه کلاینت به طور پیش‌فرض هنگام جستجو، ایجاد، به‌روزرسانی یا حذف اجاره کلاینت توسط سرور، بر مقدار موجود در فیلد \fBchaddr\fP اولویت دارد. .sp هنگامی که سرور یک پیام DHCPDISCOVER یا DHCPREQUEST از کلاینت دریافت می‌کند، سعی می‌کند بررسی کند که آیا کلاینت از پیش اجاره‌ای در پایگاه‌داده دارد یا خیر؛ در صورتی که داشته باشد، سرور به جای تخصیص اجاره‌ای نو، همان اجاره را واگذار می‌کند. هر اجاره در پایگاه‌داده اجاره‌ها با شناسه کلاینت و/یا \fBchaddr\fP مرتبط است. سرور ابتدا از شناسه کلاینت (در صورت وجود) برای جستجوی اجاره استفاده می‌کند؛ اگر موردی یافت شود، سرور این اجاره را متعلق به کلاینت در نظر می‌گیرد، حتی اگر \fBchaddr\fP کنونی و \fBchaddr\fP مرتبط با اجاره مطابقت نداشته باشند. این ویژگی فرایند سناریویی را آسان می‌کند که در آن، کارت شبکه سامانه کلاینت تعویض شده و در نتیجه نشانی MAC جدیدی در پیام‌های ارسالی کلاینت DHCP ظاهر می‌شود. اگر سرور موفق به یافتن اجاره با استفاده از شناسه کلاینت نشود، جستجوی دیگری را با استفاده از \fBchaddr\fP انجام می‌دهد. اگر این جستجو نیز نتیجه‌ای در بر نداشته باشد، کلاینت فاقد اجاره در نظر گرفته شده و یک اجاره جدید ایجاد می‌شود. .sp یک مشکل متداول که توسط گردانندگان شبکه گزارش می‌شود این است که پیاده‌سازی‌های ضعیف کلاینت‌ها از شناسه‌های کلاینت پایدار استفاده نمی‌کنند و در عوض، با هر بار اتصال کلاینت به شبکه، یک شناسه کلاینت جدید تولید می‌کنند. مورد شناخته‌شده دیگر این است که کلاینت شناسه کلاینت خود را در طول فرایند بوت چندمرحله‌ای (PXE) تغییر می‌دهد. در چنین مواردی، نشانی MAC رابط کلاینت ثابت می‌ماند، و استفاده از فیلد \fBchaddr\fP برای شناسایی کلاینت تضمین می‌کند که آن سامانه خاص با وجود تغییر یافتن شناسه کلاینتش، به عنوان همان کلاینت واحد شناخته شود. .sp برای رفع این مشکل، Kea شامل یک گزینه پیکربندی است که شناسایی کلاینت را تنها با استفاده از \fBchaddr\fP امکان‌پذیر می‌سازد. این امر به سرور دستور می‌دهد که در طول جستجوها و تخصیص‌های اجاره برای یک زیرشبکه خاص، شناسه کلاینت را نادیده بگیرد. پیکربندی ساده‌شده زیر از سرور را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqmatch\-client\-id\(dq: true, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.10.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.23\-192.0.2.87\(dq } ], \(dqmatch\-client\-id\(dq: false }, { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.23\-10.0.2.99\(dq } ] } ] } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBmatch\-client\-id\fP یک مقدار بولی است که این رفتار را کنترل می‌کند. مقدار پیش‌فرض \fBtrue\fP نشان می‌دهد که سرور از شناسه کلاینت برای جستجوهای اجاره استفاده می‌کند و اگر جستجوی نخست نتیجه‌ای در بر نداشته باشد به سراغ \fBchaddr\fP می‌رود. مقدار \fBfalse\fP بدین معناست که سرور تنها از \fBchaddr\fP برای جستجوی اجاره کلاینت استفاده خواهد کرد. اینکه DHCID برای به‌روزرسانی‌های DNS از شناسه کلاینت تولید شود یا از \fBchaddr\fP نیز از طریق همین پارامتر کنترل می‌شود. .sp پارامتر \fBmatch\-client\-id\fP می‌تواند هم در محدوده پیکربندی سراسری و هم ذیل هر اعلان زیرشبکه‌ای قرار گیرد. در مثال نشان‌داده‌شده در بالا، مقدار مؤثر \fBmatch\-client\-id\fP برای زیرشبکه 192.0.10.0/24 برابر با \fBfalse\fP خواهد بود، زیرا تنظیم مختص زیرشبکه این پارامتر بر مقدار سراسری آن اولویت داشته و آن را بازنویسی می‌کند. مقدار مؤثر \fBmatch\-client\-id\fP برای زیرشبکه 10.0.0.0/8 برابر با \fBtrue\fP تنظیم خواهد شد، زیرا اعلان زیرشبکه فاقد این پارامتر است و تنظیم سراسری به طور پیش‌فرض برای این زیرشبکه استفاده می‌شود. در واقع، در این حالت می‌شد از آوردن مدخل سراسری این پارامتر صرف‌نظر کرد، چرا که \fBtrue\fP مقدار پیش‌فرض است. .sp درک این موضوع حائز اهمیت است که در صورت دریافت اجاره توسط کلاینت تحت یک تنظیم از \fBmatch\-client\-id\fP و تمدید آن پس از تغییر یافتن این تنظیم، چه اتفاقی رخ می‌دهد. نخست، حالتی را در نظر بگیرید که کلاینت اجاره را دریافت می‌کند و \fBmatch\-client\-id\fP روی \fBtrue\fP تنظیم شده است. سرور اطلاعات اجاره را، شامل شناسه کلاینت (در صورت ارائه) و \fBchaddr\fP، در پایگاه‌داده اجاره ذخیره می‌کند. زمانی که این تنظیم تغییر کند و کلاینت اقدام به تمدید اجاره نماید، سرور تعیین می‌کند که باید از \fBchaddr\fP برای جستجوی اجاره موجود استفاده کند. اگر کلاینت نشانی MAC خود را تغییر نداده باشد، سرور باید با موفقیت اجاره موجود را بیابد. شناسه کلاینت مرتبط با اجاره بازگردانده‌شده نادیده گرفته خواهد شد و به کلاینت اجازه داده می‌شود تا از این اجاره استفاده کند. هنگام تمدید اجاره، مطابق با تنظیمات جدید سرور، تنها \fBchaddr\fP برای این اجاره ثبت خواهد شد. .sp در حالت دوم، کلاینت دارای اجاره‌ای است که تنها مقدار \fBchaddr\fP برای آن ثبت شده است. هنگامی که تنظیم \fBmatch\-client\-id\fP به \fBtrue\fP تغییر می‌یابد، سرور ابتدا سعی می‌کند از شناسه کلاینت برای پیدا کردن اجاره موجود کلاینت استفاده کند. این جستجو هیچ نتیجه‌ای در بر نخواهد داشت زیرا شناسه کلاینت برای این اجاره ثبت نشده بود. سپس سرور از \fBchaddr\fP استفاده خواهد کرد و اجاره یافت خواهد شد. اگر به نظر برسد که در اجاره هیچ شناسه کلاینتی ثبت نشده است، سرور فرض می‌کند که این اجاره متعلق به همین کلاینت است و با تنظیم پیشین \fBmatch\-client\-id\fP ایجاد شده است. با این حال، اگر اجاره حاوی شناسه کلاینتی باشد که با شناسه کلاینت استفاده‌شده توسط کلاینت متفاوت است، فرض می‌شود که اجاره به کلاینت دیگری تعلق دارد و یک اجاره جدید تخصیص داده خواهد شد. .sp برای نمای بصری‌تری از چگونگی بازشناسی کلاینت یکسان توسط Kea، لطفاً به بخش How Kea Recognizes the Same Client In Different DHCP Messages \%<#\:uml-recognizing-same-client>\& مراجعه فرمایید..SS رفتار کارگزار مقتدر DHCPv4 .sp مشخصات اصلی DHCPv4 (RFC 2131 \%) بیان می‌کند که اگر یک کلاینت در وضعیت INIT\-REBOOT آدرسی را درخواست کند که کارگزار شناختی از آن ندارد، کارگزار باید پاسخی ندهد (سکوت کند)، مگر اینکه کارگزار بداند کلاینت یک آدرس IP از شبکه اشتباه درخواست کرده است. به‌طور پیش‌فرض، Kea به جای این مشخصات، از رفتار دیمن ISC \fBdhcpd\fP پیروی می‌کند و در صورتی هم که کلاینت آدرس IP از شبکه اشتباه درخواست کند پاسخی نمی‌دهد، زیرا مشخص نیست که اطلاعات پیکربندی یک بخش شبکه (سگمنت) مشخص حتماً صحیح باشد. Kea تنها در صورتی درخواست DHCPREQUEST کلاینت را با یک پیام DHCPNAK رد می‌کند که از قبل اجاره‌ای (lease) برای آن کلاینت با یک آدرس IP متفاوت داشته باشد. مدیران سیستم می‌توانند با استفاده از تنظیم بولی \fBauthoritative\fP (به‌طور پیش‌فرض \fBfalse\fP) این رفتار را تغییر دهند. .sp در حالت مقتدر، زمانی که \fBauthoritative\fP روی \fBtrue\fP تنظیم شده باشد، Kea همواره درخواست‌های INIT\-REBOOT کلاینت‌های ناشناس را با پیام‌های DHCPNAK رد می‌کند. تنظیم \fBauthoritative\fP می‌تواند در حوزه پیکربندی سراسری (global)، شبکه اشتراکی (shared\-network) و زیرشبکه (subnet) مشخص شود و در صورت عدم تعیین، به‌طور خودکار از حوزه والد به ارث برده می‌شود. تمام زیرشبکه‌ها در یک shared\-network باید تنظیم \fBauthoritative\fP یکسانی داشته باشند. .SS DHCPv4\-over\-DHCPv6: سمت DHCPv4 .sp پشتیبانی از انتقال DHCPv4\-over\-DHCPv6 در RFC 7341 \% شرح داده شده است و با استفاده از همکاری کارگزارهای DHCPv4 و DHCPv6 پیاده‌سازی می‌شود. این بخش به پیکربندی سمت DHCPv4 می‌پردازد (سمت DHCPv6 در بخش DHCPv4\-over\-DHCPv6: سمت DHCPv6 \%<#\:dhcp6-dhcp4o6-config> شرح داده شده است). .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 جزئیات ارتباط بین‌پردازشی در DHCPv4\-over\-DHCPv6 ممکن است تغییر کند؛ برای نمونه، پشتیبانی از رله پورت (RFC 8357) تغییری ناسازگار ایجاد کرد. هر دو سمت DHCPv4 و DHCPv6 باید از نسخه یکسانی از Kea استفاده کنند. .UNINDENT .UNINDENT .sp پارامتر سراسری \fBdhcp4o6\-port\fP نخستین پورت از دو پورت متوالی سوکت‌های UDP مورد استفاده برای ارتباط میان کارگزارهای DHCPv6 و DHCPv4 را مشخص می‌کند. کارگزار DHCPv4 روی ::1 در \fBport\fP + 1 متصل (bound) شده و به ::1 در \fBport\fP متصل می‌شود. .sp در DHCPv4\-over\-DHCPv6، کارگزار DHCPv4 به چندین شناسه که به‌طور معمول برای انتخاب زیرشبکه استفاده می‌کرد دسترسی ندارد. برای رفع این مشکل، سه مدخل پیکربندی جدید فراهم شده است؛ وجود هر یک از این‌ها به زیرشبکه اجازه می‌دهد با DHCPv4\-over\-DHCPv6 استفاده شود. این مدخل‌ها عبارتند از: .INDENT 0.0 .IP \(bu 2 \fB4o6\-subnet\fP: یک پیشوند (یعنی یک آدرس IPv6 به همراه اسلش و طول پیشوند) دریافت می‌کند که با آدرس مبدأ تطبیق داده می‌شود. .IP \(bu 2 \fB4o6\-interface\-id\fP: مقدار گزینه شناسه رابط رله را دریافت می‌کند. .IP \(bu 2 \fB4o6\-interface\fP: نام یک رابط را دریافت می‌کند که با نام رابط ورودی تطبیق داده می‌شود. .UNINDENT .sp شرکت ISC پیکربندی زیر را آزمایش کرده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { # DHCPv4 conf \(dqDhcp4\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeno33554984\(dq ] }, \(dqlease\-database\(dq: { \(dqtype\(dq: \(dqmemfile\(dq, \(dqname\(dq: \(dqleases4\(dq }, \(dqvalid\-lifetime\(dq: 4000, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.10.10.0/24\(dq, \(dq4o6\-interface\(dq: \(dqeno33554984\(dq, \(dq4o6\-subnet\(dq: \(dq2001:db8:1:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.10.10.100 \- 10.10.10.199\(dq } ] } ], \(dqdhcp4o6\-port\(dq: 786, \(dqloggers\(dq: [ { \(dqname\(dq: \(dqkea\-dhcp4\(dq, \(dqoutput\-options\(dq: [ { \(dqoutput\(dq: \(dqkea\-dhcp4.log\(dq } ], \(dqseverity\(dq: \(dqDEBUG\(dq, \(dqdebuglevel\(dq: 0 } ] } } .EE .UNINDENT .UNINDENT .SS بررسی‌های صحت در DHCPv4 .sp یک جنبه مهم در اجرای صحیح سامانه DHCP، اطمینان از سازگاری داده‌ها است؛ با این حال، در برخی موارد ممکن است تحمل برخی از داده‌های ناسازگار مناسب باشد. برای نمونه، مدیر شبکه‌ای که موقتاً یک زیرشبکه را از پیکربندی حذف می‌کند، مایل نیست تمامی اجاره‌های مرتبط با آن از پایگاه‌داده اجاره‌ها ناپدید شوند. Kea سازوکاری برای اجرای بررسی‌های صحت (sanity checks) در چنین شرایطی دارد. .sp ‏Kea از یک حوزه پیکربندی به نام \fBsanity\-checks\fP پشتیبانی می‌کند. پارامتری به نام \fBlease\-checks\fP، بر اعتبارسنجی انجام‌شده هنگام بارگیری یک اجاره جدید از فایل اجاره نظارت دارد. این سازوکار به Kea امکان می‌دهد تا برای اصلاح داده‌های ناسازگار تلاش کند. .sp هر زیرشبکه یک مقدار \fBsubnet\-id\fP دارد؛ این روشی است که Kea به‌صورت داخلی زیرشبکه‌ها را شناسایی می‌کند. هر اجاره نیز یک پارامتر \fBsubnet\-id\fP دارد که مشخص می‌کند متعلق به کدام زیرشبکه است. با این حال، در صورت تغییر پیکربندی، ممکن است اجاره‌ای با یک \fBsubnet\-id\fP وجود داشته باشد اما هیچ زیرشبکه منطبقی با آن یافت نشود. همچنین ممکن است پیکربندی زیرشبکه تغییر یافته باشد و اکنون \fBsubnet\-id\fP متعلق به زیرشبکه‌ای باشد که با اجاره همخوانی ندارد. .sp الگوریتم تصحیح Kea ابتدا بررسی می‌کند که آیا زیرشبکه‌ای با \fBsubnet\-id\fP مشخص‌شده توسط اجاره وجود دارد یا خیر. اگر وجود داشته باشد، بررسی می‌کند که آیا اجاره متعلق به آن زیرشبکه است یا خیر. در غیر این صورت، بسته به تنظیم \fBlease\-checks\fP، اجاره نادیده گرفته می‌شود، هشداری نمایش داده می‌شود، یا زیرشبکه جدیدی برای اجاره انتخاب می‌شود که از لحاظ توپولوژیکی با آن مطابقت دارد. .sp پنج سطح پشتیبانی می‌شود: .INDENT 0.0 .IP \(bu 2 \fBnone\fP \- هیچ بررسی خاصی انجام نده؛ اجاره را همان‌طور که هست بپذیر. .IP \(bu 2 \fBwarn\fP \- در صورت تشخیص مشکل هشدار نمایش بده، اما در هر حال داده‌های اجاره را بپذیر. این مقدار پیش‌فرض است. .IP \(bu 2 \fBfix\fP \- در صورت مشاهده ناسازگاری در داده‌ها، سعی کن آن را تصحیح کنی. اگر تصحیح موفقیت‌آمیز نبود، داده‌های نادرست را در هر صورت درج کن. .IP \(bu 2 \fBfix\-del\fP \- در صورت مشاهده ناسازگاری در داده‌ها، سعی کن آن را تصحیح کنی. اگر تصحیح موفقیت‌آمیز نبود، اجاره را رد کن. این تنظیم صحت داده‌ها را تضمین می‌کند، اما ممکن است برخی از داده‌های نادرست از دست بروند. با احتیاط استفاده شود. .IP \(bu 2 \fBdel\fP \- در صورت تشخیص هرگونه ناسازگاری، اجاره را رد کن. این سخت‌گیرانه‌ترین حالت است؛ با احتیاط استفاده شود. .UNINDENT .sp این قابلیت در حال حاضر برای بک‌اند memfile پیاده‌سازی شده است. بررسی صحت بر روی پایگاه‌داده اجاره در حافظه اعمال می‌شود، نه بر روی فایل اجاره؛ بدین معنا که اجاره‌های ناسازگار در فایل اجاره باقی می‌مانند. .sp یک نمونه پیکربندی که این پارامتر را تنظیم می‌کند به شرح زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsanity\-checks\(dq: { \(dqlease\-checks\(dq: \(dqfix\-del\(dq }, ... } .EE .UNINDENT .UNINDENT.SS ذخیره‌سازی اطلاعات گسترش‌یافتهٔ اجاره (Storing Extended Lease Information) .sp برای پشتیبانی از قابلیت‌هایی مانند DHCP Leasequery (RFC 4388 \%) و گزینه‌های stash agent (Stash Agent Options)، باید اطلاعات اضافی به همراه هر اجاره (lease) ذخیره شود. از آنجا که حجم اطلاعات برای هر اجاره پیامدهایی از نظر کارایی و مصرف منابع سیستم به دنبال دارد، ذخیره‌سازی این اطلاعات اضافی از طریق پارامتر \fBstore\-extended\-info\fP قابل پیکربندی است. مقدار پیش‌فرض آن \fBfalse\fP است و می‌تواند در سطوح global، shared\-network و subnet تنظیم شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqstore\-extended\-info\(dq: true, ... } .EE .UNINDENT .UNINDENT .sp هنگامی که روی \fBtrue\fP تنظیم شود، اطلاعات مربوط به DHCPREQUEST درخواست‌کنندهٔ اجاره به عنوان یک عنصر نگاشت با برچسب \(dqISC\(dq به زمینهٔ کاربر (user context) اجاره اضافه می‌شود. هنگامی که DHCPREQUEST دریافت‌شده حاوی گزینهٔ (DHCP Option 82) باشد، این نگاشت شامل نگاشت \fBrelay\-agent\-info\fP با محتوای گزینهٔ (DHCP Option 82) در مدخل \fBsub\-options\fP و در صورت وجود، گزینه‌های \fBremote\-id\fP و \fBrelay\-id\fP خواهد بود. از آنجا که بعید است پیام‌های DHCPREQUEST ارسال‌شده به عنوان تمدید حاوی این اطلاعات باشند، مقادیر برگرفته از آخرین DHCPREQUEST که حاوی آن بوده است در اجاره حفظ می‌شوند. زمینهٔ کاربر اجاره شبیه به این خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqISC\(dq: { \(dqrelay\-agent\-info\(dq: { \(dqsub\-options\(dq: \(dq0x0104AABBCCDD\(dq } } } .EE .UNINDENT .UNINDENT .sp یا همراه با زیرگزینه‌های remote و relay: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqISC\(dq: { \(dqrelay\-agent\-info\(dq: { \(dqsub\-options\(dq: \(dq0x02030102030C03AABBCC\(dq, \(dqremote\-id\(dq: \(dq03010203\(dq, \(dqrelay\-id\(dq: \(dqAABBCC\(dq } } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 ممکن است سایر کتابخانه‌های قلاب (hook libraries) از قبل در حال استفاده از \fBuser\-context\fP باشند. فعال کردن \fBstore\-extended\-info\fP نباید با هیچ‌یک از محتویات دیگر \fBuser\-context\fP تداخلی ایجاد کند، تا زمانی که آن‌ها نیز از عنصری با برچسب \(dqISC\(dq استفاده نکنند. به بیان دیگر، \fBuser\-context\fP به عنوان محفظه‌ای انعطاف‌پذیر برای مقاصد متعدد در نظر گرفته شده است. تا زمانی که هدف دیگری نیز عنصری با نام \(dqISC\(dq را در \fBuser\-context\fP ننویسد، تعارضی رخ نخواهد داد. .UNINDENT .UNINDENT .sp اطلاعات گسترش‌یافتهٔ اجاره همچنین مشمول بررسی صحت (sanity checking) قابل پیکربندی است. پارامتر موجود در محدودهٔ \fBsanity\-checks\fP با نام \fBextended\-info\-checks\fP شناخته می‌شود و از این سطوح پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBnone\fP \- هیچ بررسی یا ارتقایی انجام ندهد. این سطح تنها زمانی باید استفاده شود که اطلاعات گسترش‌یافته اصلاً استفاده نمی‌شود یا انتظار نمی‌رود اطلاعات گسترش‌یافته با قالب‌بندی نادرست (از جمله استفاده از قالب قدیمی) وجود داشته باشد. .IP \(bu 2 \fBfix\fP \- رفع برخی ناسازگاری‌های متداول و ارتقای اطلاعات گسترش‌یافته با قالب قدیمی به قالب جدید. این سطح پیش‌فرض است و زمانی که کتابخانهٔ قلاب Leasequery بارگذاری نشده باشد، مناسب است. .IP \(bu 2 \fBstrict\fP \- رفع تمامی ناسازگاری‌هایی که روی کتابخانهٔ قلاب (Bulk) Leasequery تأثیر دارند. .IP \(bu 2 \fBpedantic\fP \- اعمال انطباق کامل با قالبی که توسط کد Kea تولید می‌شود؛ به عنوان مثال، هیچ مدخل اضافی به جز \fBcomment\fP مجاز نیست. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این قابلیت در حال حاضر تنها برای بک‌اند memfile پیاده‌سازی شده است. بررسی صحت بر روی پایگاه‌دادهٔ اجاره در حافظه اعمال می‌شود، نه روی فایل اجاره؛ بدین معنا که اجاره‌های ناسازگار در فایل اجاره باقی می‌مانند. .UNINDENT .UNINDENT .SS گزینه‌های Stash Agent (Stash Agent Options) .sp این پارامتر سراسری در نگارش 2.5.8 اضافه شد تا رفتاری مشابه قابلیتی را ارائه دهد که پیش‌تر در ISC DHCP در دسترس بود. هنگامی که پارامتر \fBstash\-agent\-options\fP روی \fBtrue\fP باشد، کارساز گزینه‌های اطلاعات کارگزار رله (relay agent information options) ارسال‌شده در پیام DHCPREQUEST اولیهٔ کلاینت (زمانی که کلاینت در وضعیت SELECTING بود) را ضبط می‌کند و به گونه‌ای عمل می‌کند که گویی آن گزینه‌ها در تمامی پیام‌های DHCPREQUEST بعدی که در وضعیت RENEWING ارسال می‌شوند گنجانده شده‌اند. این سازوکار مشکلی را دور می‌زند که در آن گزینه‌های اطلاعات کارگزار رله معمولاً در پیام‌های DHCPREQUEST ارسال‌شده توسط کلاینت در وضعیت RENEWING ظاهر نمی‌شوند؛ زیرا این پیام‌ها به صورت unicast مستقیماً به کارساز ارسال شده و از طریق یک کارگزار رله فرستاده نمی‌شوند. .sp مقدار پیش‌فرض \fBfalse\fP است. .SS تنظیمات چندریسمانی (Multi\-Threading Settings) .sp کارساز Kea می‌تواند به گونه‌ای پیکربندی شود که بسته‌ها را به صورت موازی با استفاده از چندین ریسمان (thread) پردازش کند. این تنظیمات در ساختار \fBmulti\-threading\fP یافت می‌شوند و عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBenable\-multi\-threading\fP \- استفاده از چندین ریسمان برای پردازش موازی بسته‌ها. مقدار پیش‌فرض \fBtrue\fP است. .IP \(bu 2 \fBthread\-pool\-size\fP \- تعیین تعداد ریسمان‌ها برای پردازش موازی بسته‌ها. می‌تواند روی \fB0\fP (تشخیص خودکار)، یا هر عدد مثبتی که تعداد ریسمان را به صراحت مشخص کند، تنظیم شود. مقدار پیش‌فرض \fB0\fP است. .IP \(bu 2 \fBpacket\-queue\-size\fP \- تعیین اندازهٔ صف مورد استفاده توسط استخر ریسمان (thread pool) جهت پردازش بسته‌ها. می‌تواند روی \fB0\fP (نامحدود)، یا هر عدد مثبتی که اندازهٔ صف را به صراحت تعیین می‌کند، تنظیم شود. مقدار پیش‌فرض \fB64\fP است. .UNINDENT .sp یک نمونه پیکربندی که این پارامترها را تنظیم می‌کند به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqmulti\-threading\(dq: { \(dqenable\-multi\-threading\(dq: true, \(dqthread\-pool\-size\(dq: 4, \(dqpacket\-queue\-size\(dq: 16 }, ... } .EE .UNINDENT .UNINDENT.SS تنظیمات چندریسمانی با پایگاه‌های داده پشتیبان مختلف .sp سرور Kea DHCPv4 توسط ISC محک‌زنی می‌شود تا مشخص شود کدام تنظیمات بهترین کارایی را ارائه می‌دهند. اگرچه این بخش نتایج ما را شرح می‌دهد، اما آنها صرفاً پیشنهاد هستند و به سخت‌افزار خاص مورد استفاده برای محک‌زنی بسیار وابسته‌اند. ما اکیداً توصیه می‌کنیم که مدیران سیستم محک‌زنی‌های کارایی خود را اجرا کنند. .sp گزارش کاملی از نتایج عملکرد برای آخرین نسخه پایدار Kea را می‌توان در اینجا \%\& مشاهده کرد. این گزارش شامل شرح سخت‌افزار و سناریوهای محک‌زنی، و همچنین نتایج کنونی است. .sp پس از فعال‌سازی چندریسمانی (multi\-threading)، تعداد ریسمان‌ها با پارامتر \fBthread\-pool\-size\fP تنظیم می‌شود. نتایج حاصل از آزمایش‌های ما نشان می‌دهد که بهترین تنظیمات برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBthread\-pool\-size\fP: مقدار ۴ هنگام استفاده از \fBmemfile\fP برای ذخیره اجاره‌ها. .IP \(bu 2 \fBthread\-pool\-size\fP: مقدار ۱۲ یا بیشتر هنگام استفاده از \fBmysql\fP برای ذخیره اجاره‌ها. .IP \(bu 2 \fBthread\-pool\-size\fP: مقدار ۸ هنگام استفاده از \fBpostgresql\fP\&. .UNINDENT .sp پارامتر بسیار مهم دیگر \fBpacket\-queue\-size\fP است؛ در محک‌زنی‌هایمان، ما از آن به عنوان ضریبی از \fBthread\-pool\-size\fP استفاده کردیم. مقدار واقعی به شدت به \fBthread\-pool\-size\fP وابسته است. .sp ما در محک‌زنی‌های خود بهترین نتایج را با تنظیمات زیر مشاهده کردیم: .INDENT 0.0 .IP \(bu 2 \fBpacket\-queue\-size\fP: برابر با 7 * \fBthread\-pool\-size\fP هنگام استفاده از \fBmemfile\fP برای ذخیره اجاره‌ها؛ در مورد ما 7 * 4 = 28 بود. این بدان معناست که در هر زمان، حداکثر تا ۲۸ بسته می‌توانست در صف قرار گیرد. .IP \(bu 2 \fBpacket\-queue\-size\fP: برابر با 66 * \fBthread\-pool\-size\fP هنگام استفاده از \fBmysql\fP برای ذخیره اجاره‌ها؛ در مورد ما 66 * 12 = 792 بود. این بدان معناست که حداکثر تا ۷۹۲ بسته می‌توانست در صف قرار گیرد. .IP \(bu 2 \fBpacket\-queue\-size\fP: برابر با 11 * \fBthread\-pool\-size\fP هنگام استفاده از \fBpostgresql\fP برای ذخیره اجاره‌ها؛ در مورد ما 11 * 8 = 88 بود. .UNINDENT .SS شبکه‌های با اولویت فقط IPv6 .sp سند RFC 8925 \% که اخیراً توسط IETF منتشر شده است، یک گزینه DHCPv4 را تعیین می‌کند تا نشان دهد میزبان از حالت فقط IPv6 پشتیبانی می‌کند و در صورتی که شبکه اتصال IPv6 را فراهم کند، مایل است از دریافت آدرس IPv4 صرف‌نظر کند. ایده کلی این است که مدیر شبکه می‌تواند این گزینه را فعال کند تا به دستگاه‌های دوپشته‌ای (dual\-stack) سازگار سیگنال دهد که اتصال IPv6 در دسترس است و می‌توانند پشته IPv4 خود را خاموش کنند. محتوای گزینه جدید \fBv6\-only\-preferred\fP یک عدد صحیح ۳۲ بیتی بدون علامت است و مشخص می‌کند که دستگاه چه مدت باید پشته خود را غیرفعال کند. این مقدار به ثانیه بیان می‌شود. .sp این RFC به تایمر \fBV6ONLY_WAIT\fP اشاره می‌کند. این قابلیت در Kea با تنظیم مقدار گزینه \fBv6\-only\-preferred\fP پیاده‌سازی شده است. این روند از شیوه معمول تنظیم گزینه‌ها پیروی می‌کند؛ مقدار گزینه را می‌توان در سطوح pool، subnet، shared network یا سطوح سراسری (global)، یا حتی از طریق رزروهای میزبان (host reservations) مشخص کرد. .sp هیچ پردازش خاصی درگیر نیست؛ این فرآیند از سازوکار استاندارد پردازش گزینه‌ها در Kea پیروی می‌کند. این گزینه پس فرستاده نمی‌شود مگر اینکه کارخواه صراحتاً آن را درخواست کند. برای مثال، جهت فعال‌سازی این گزینه برای کل زیرشبکه، می‌توان از پیکربندی زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.200\(dq } ], \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqoption\-data\(dq: [ { // This will make the v6\-only capable devices to disable their // v4 stack for half an hour and then try again \(dqname\(dq: \(dqv6\-only\-preferred\(dq, \(dqdata\(dq: \(dq1800\(dq } ] } ], \&... } .EE .UNINDENT .UNINDENT .SS حافظه پنهان اجاره‌ها (Lease Caching) .sp کارخواه‌هایی که در مدت‌زمانی کوتاه اقدام به تمدید مکرر می‌کنند می‌توانند موجب شوند که سرور مرتباً پایگاه‌داده را به‌روزرسانی کرده و روی آن بنویسد، که نتیجه آن افت کارایی سرور خواهد بود. پارامترهای کش به سرور DHCP دستور می‌دهند که از به‌روزرسانی بیش از حد اجاره‌ها خودداری کند و بدین ترتیب از این رفتار جلوگیری شود. در عوض، سرور همان اجاره را بدون هیچ تغییری به جز CLTT (زمان آخرین ارسال کارخواه یا Client Last Transmission Time) که نیازی به عملیات دیسک ندارد، تخصیص می‌دهد (یعنی از آن مجدداً استفاده می‌کند). .sp این دو پارامتر عبارتند از عدد اعشاری \fBcache\-threshold\fP و عدد صحیح \fBcache\-max\-age\fP. این پارامترها را می‌توان در سطوح global، shared\-network و subnet پیکربندی کرد. سطح subnet بر سطح shared\-network اولویت دارد، در حالی که از سطح global به عنوان آخرین راهکار استفاده می‌شود. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.200\(dq } ], \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqcache\-threshold\(dq: .25, \(dqcache\-max\-age\(dq: 600, \(dqvalid\-lifetime\(dq: 2000, ... } ], \&... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه Kea 3.0.0، مقدار پیش‌فرض برای \fBcache\-threshold\fP برابر 0.25 است در حالی که \fBcache\-max\-age\fP نامشخص رها شده است. این بدان معناست که کش کردن اجاره‌ها به صورت پیش‌فرض فعال است. می‌توان آن را در محدوده مورد نظر با تنظیم \fBcache\-threshold\fP روی 0.0 یا تنظیم \fBcache\-max\-age\fP روی 0 غیرفعال کرد. .UNINDENT .UNINDENT .sp هنگامی که یک اجاره از پیش واگذار شده بتواند پاسخگوی پرس‌وجوی کارخواه باشد: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 هرگونه تغییر مهم، مانند پارامتر DDNS، نام میزبان یا کاهش طول عمر معتبر، اجاره را غیرقابل استفاده مجدد می‌کند. .IP \(bu 2 سن اجاره، یعنی اختلاف بین زمان ایجاد یا آخرین ویرایش و زمان فعلی محاسبه می‌شود (مدت‌زمان سپری‌شده). .IP \(bu 2 اگر \fBcache\-max\-age\fP به طور صریح پیکربندی شده باشد، با سن اجاره مقایسه می‌شود؛ اجاره‌هایی که بیش از حد قدیمی باشند قابل استفاده مجدد نیستند. این بدان معناست که مقدار 0 برای \fBcache\-max\-age\fP قابلیت کش اجاره را غیرفعال می‌کند. .IP \(bu 2 اگر \fBcache\-threshold\fP به طور صریح پیکربندی شده و بین 0.0 و 1.0 باشد، درصدی از طول عمر معتبر اجاره را بیان می‌کند که برای سن اجاره مجاز شمرده می‌شود. مقادیر کمتر و مساوی 0.0 و مقادیر بزرگتر از 1.0 قابلیت کش اجاره را غیرفعال می‌کنند. .UNINDENT .UNINDENT .UNINDENT .sp در مثال ما، اجاره‌ای با طول عمر معتبر ۲۰۰۰ ثانیه در صورتی می‌تواند مجدداً استفاده شود که کمتر از ۵۰۰ ثانیه پیش ثبت شده باشد. با طول عمر ۳۰۰۰ ثانیه، حداکثر سن ۶۰۰ ثانیه اعمال می‌شود. .sp در پاسخ‌های ارسالی به کارخواه (مانند پیام‌های DHCPACK)، گزینه \fBdhcp\-lease\-time\fP روی طول عمر معتبر قابل استفاده مجدد تنظیم می‌شود، یعنی تاریخ انقضا تغییر نمی‌کند. سایر گزینه‌های مبتنی بر طول عمر معتبر، مانند \fBdhcp\-renewal\-time\fP و \fBdhcp\-rebinding\-time\fP نیز به طول عمر قابل استفاده مجدد وابسته هستند..SS "تخصیص موقت در DHCPDISCOVER" .sp به‌طور پیش‌فرض، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> هنگام پیشنهاد دادن یک آدرس به کلاینت در پاسخ به یک DHCPDISCOVER، اجاره‌ای را تخصیص نداده یا ذخیره نمی‌کند. به‌طور کلی، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> می‌تواند با به تعویق انداختن تخصیص و ذخیره‌سازی اجاره تا زمان دریافت DHCPREQUESTها برای آن‌ها، درخواست‌های کلاینت را سریع‌تر برآورده کند. پارامتر \fBoffer\-lifetime\fP در \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> (زمانی که صفر نباشد) به سرور دستور می‌دهد هنگام تولید یک DHCPOFFER، یک اجاره را تخصیص داده و پایدار (persist) کند. علاوه بر این: .INDENT 0.0 .IP \(bu 2 طول عمر اجاره‌ی پایدارشده برابر با \fBoffer\-lifetime\fP (به ثانیه) است. .IP \(bu 2 طول عمری که در DHCPOFFER از طریق گزینه ۵۱ (option 51) برای کلاینت ارسال می‌شود، همچنان بر اساس \fBvalid\-lifetime\fP است\&. این کار از بروز مشکل با کلاینت‌هایی که ممکن است پیشنهادهایی با طول عمر بیش از حد کوتاه را رد کنند، جلوگیری می‌کند. .IP \(bu 2 به‌روزرسانی‌های DDNS انجام نمی‌شوند. همانند رفتار پیش‌فرض، این به‌روزرسانی‌ها در DHCPREQUEST رخ می‌دهند. .IP \(bu 2 به‌روزرسانی‌ها به همتایان HA ارسال نمی‌شوند. .IP \(bu 2 آمار اجاره‌های تخصیص‌یافته افزایش می‌یابد. .IP \(bu 2 پردازش انقضا و بازپس‌گیری (reclamation) دقیقاً همانند اجاره‌های تخصیص‌یافته در طول پردازش DHCPREQUEST رفتار می‌کنند. .IP \(bu 2 کش‌کردن اجاره (Lease caching)، در صورت فعال بودن، رعایت می‌شود. .IP \(bu 2 در مراکزی که چندین نمونه از \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> را در مقابل یک مخزن اجاره‌ی مشترک اجرا می‌کنند، رقابت‌ها (races) برای مقادیر مشخص آدرس در طول پردازش DHCPDISCOVER از دست می‌روند نه در طول پردازش DHCPREQUEST. سرورهایی که رقابت را برای آدرس ببازند، به‌سادگی به کلاینت پاسخ نمی‌دهند، به جای اینکه به آن‌ها NAK ارسال کنند. کلاینت نیز به نوبه خود به‌سادگی DHCPDISCOVER خود را مجدداً تلاش می‌کند. این امر باید میزان ترافیکی را که چنین تداخل‌هایی ایجاد می‌کنند، کاهش دهد. .IP \(bu 2 به کلاینت‌هایی که DHCPDISCOVER را تکرار می‌کنند، هر بار همان آدرس پیشنهاد می‌شود. .UNINDENT .sp یک نمونه پیکربندی زیرشبکه در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.200\(dq } ], \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqoffer\-lifetime\(dq: 60, \(dqvalid\-lifetime\(dq: 2000, ... } ], \&... } .EE .UNINDENT .UNINDENT .sp در اینجا \fBoffer\-lifetime\fP روی ۶۰ ثانیه با یک \fBvalid\-lifetime\fP معادل ۲۰۰۰ ثانیه پیکربندی شده است. این به \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> دستور می‌دهد هنگام ارسال اجاره‌ها در DHCPOFFERها، آن‌ها را به مدت ۶۰ ثانیه پایدار کند و سپس هنگامی که کلاینت‌ها برای آن‌ها DHCPREQUEST ارسال می‌کنند، مدت آن‌ها را به ۲۰۰۰ ثانیه افزایش دهد. .sp این مقدار، که پیش‌فرض آن 0 است، در سطوح global، shared\-network، subnet و class پشتیبانی می‌شود. انتخاب یک مقدار مناسب برای \fBoffer\-lifetime\fP به‌شدت به ساختار شبکه وابسته است، اما مقداری بین ۶۰ تا ۱۲۰ ثانیه نقطه‌ی شروع معقولی است. .SS "گزینه‌های DNR (Discovery of Network\-designated Resolvers) برای DHCPv4" .sp گزینه‌ی Discovery of Network\-designated Resolvers یا DNR، در RFC 9463 \% به عنوان روشی برای اعلام مکان تحلیل‌کننده‌های DNS (resolvers) که از طریق روش‌هایی به غیر از DNS کلاسیک روی UDP روی پورت ۵۳ در دسترس هستند، معرفی شد. تا بهار ۲۰۲۴، فناوری‌های پشتیبانی‌شده عبارت‌اند از DoT (DNS\-over\-TLS)، DoH (DNS\-over\-HTTPS) و DoQ (DNS\-over\-QUIC)، اما این گزینه به‌گونه‌ای طراحی شده است که قابل توسعه باشد تا پروتکل‌های دیگر را در آینده در بر بگیرد. .sp گزینه‌ی DHCPv4 و گزینه‌های متناظر آن در DHCPv6 تقریباً کاملاً یکسان هستند، با این استثنا که در تعداد تفاوت دارند (cardinality): تنها یک گزینه‌ی DHCPv4 مجاز است، در حالی که گزینه‌های متعددی برای DHCPv6 مجازند. برای امکان انتقال چندین مدخل (entry)، گزینه‌ی DNR در DHCPv4 یک آرایه است که چندین نمونه‌ی DNS را ممکن می‌سازد. هر نمونه از نظر منطقی معادل یک گزینه‌ی DHCPv6 است؛ تنها تفاوت این است که به جای آدرس‌های IPv6 از آدرس‌های IPv4 استفاده می‌کند. گزینه‌های DNR در DHCPv4 امکان پیکربندی بیش از یک نمونه‌ی DNR را فراهم می‌کنند، و نمونه‌های DNR با نویسه‌ی «pipe» (\fB0x7C\fP) از یکدیگر جدا می‌شوند. .sp برای مشاهده‌ی یک مثال دقیق از نحوه‌ی پیکربندی گزینه‌ی DNR، به DNR (Discovery of Network\-designated Resolvers) Options for DHCPv6 \%<#\:dnr6-options>\& مراجعه کنید. .sp برای هر نمونه‌ی DNR، فیلدهای جداشده با کاما باید به ترتیب زیر ارائه شوند: .INDENT 0.0 .IP \(bu 2 اولویت سرویس Service Priority (اجباری)، .IP \(bu 2 نام دامنه کاملاً معین ADN FQDN (اجباری)، .IP \(bu 2 آدرس(های) IP (اختیاری؛ در صورت وجود بیش از یکی، باید با فاصله از هم جدا شوند) .IP \(bu 2 پارامترهای SvcParams به عنوان مجموعه‌ای از جفت‌های کلید=مقدار (key=value) (اختیاری؛ در صورت وجود بیش از یکی \- باید با فاصله از هم جدا شوند). برای ارائه‌ی بیش از یک \fBalpn\-id\fP، آن‌ها را با کاماهایی که با دو بک‌اسلش گریز (escape) داده شده‌اند جدا کنید (همانند مثال زیر). .UNINDENT .sp مثال استفاده: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqname\(dq: \(dqv4\-dnr\(dq, // 2 DNR Instances: // \- Service priority 2, ADN, resolver IPv4 address and Service Parameters // \- Service priority 3, ADN \- this is ADN\-only mode as per RFC 9463 3.1.6 \(dqdata\(dq: \(dq2, resolver.example., 10.0.5.6, alpn=dot\e\e,doq port=8530 | 3, fooexp.resolver.example.\(dq } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگر نویسه‌های «comma» یا «pipe» به جای جداکننده‌ی فیلد به عنوان متن استفاده شوند، باید با دو بک‌اسلش گریز داده شوند (\fB\e\e,\fP یا \fB\e\e|\fP). کاماهای گریز داده شده باید هنگام پیکربندی بیش از یک پروتکل \fBALPN\fP برای جداسازی آن‌ها استفاده شوند. نویسه‌ی «pipe» (\fB0x7C\fP) می‌تواند در پارامتر سرویس \fBdohpath\fP استفاده شود، زیرا در یک URI مجاز است. .UNINDENT .UNINDENT .sp مثال‌هایی برای گزینه‌های DNR در DHCPv4 که در سورس‌های Kea ارائه شده‌اند را می‌توان در kea4/all\-options.json \%<#\:config-example-kea4-all-options-json>\& یافت..SS "رزروهای میزبان در DHCPv4 (Host Reservations in DHCPv4)" .sp موارد بسیاری وجود دارد که در آن‌ها ارائهٔ پیکربندی بر پایهٔ هر میزبان (per\-host) مفید است. واضح‌ترین مورد، رزرو یک آدرس ثابت و مشخص برای استفادهٔ اختصاصی توسط یک کلاینت (میزبان) معین است؛ کلاینت هنگام بازگشت، هر بار همان آدرس را از سرور دریافت می‌کند و سایر کلاینت‌ها عموماً آن آدرس را دریافت نمی‌کنند. همچنین رزروهای میزبان زمانی که یک میزبان نیازمندی‌های خاصی دارد، مانند یک چاپگر که به گزینه‌های DHCP اضافی نیاز دارد، بسیار کارآمد هستند. یکی دیگر از کاربردهای ممکن، تعریف نام‌های یکتا برای میزبان‌ها است. .sp ممکن است مواردی پیش آید که رزرو جدیدی برای یک کلاینت روی آدرسی انجام شده باشد که در حال حاضر توسط کلاینت دیگری استفاده می‌شود. ما این وضعیت را \(dqتداخل\(dq (conflict) می‌نامیم. این تداخل‌ها با گذشت زمان به‌طور خودکار برطرف می‌شوند، همان‌طور که در بخش‌های بعدی شرح داده شده است. هنگامی که یک تداخل برطرف شد، کلاینت صحیح هنگام تمدید (renew)، پیکربندی رزروشده را دریافت خواهد کرد. .sp رزروهای میزبان به‌عنوان پارامترهایی برای هر زیرشبکه تعریف می‌شوند. هر میزبان باید شناسهٔ یکتای خود را داشته باشد، مانند آدرس سخت‌افزاری/MAC. یک آرایهٔ اختیاری \fBreservations\fP در ساختار \fBsubnet4\fP وجود دارد؛ هر عنصر در این آرایه ساختاری است که اطلاعات مربوط به رزروها را برای یک میزبان منفرد نگه می‌دارد. به‌ویژه، این ساختار دارای شناسه‌ای است که یک میزبان را به‌طور منحصربه‌فرد مشخص می‌کند. در زمینهٔ DHCPv4، این شناسه معمولاً یک آدرس سخت‌افزاری یا MAC است. در بیشتر موارد یک آدرس IP مشخص خواهد شد. همچنین می‌توان یک hostname، گزینه‌های مختص به میزبان، یا فیلدهای حمل‌شده در پیام DHCPv4 مانند \fBsiaddr\fP، \fBsname\fP یا \fBfile\fP را مشخص کرد\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 آدرس رزروشده باید درون زیرشبکه باشد. .UNINDENT .UNINDENT .sp مثال زیر نحوهٔ رزرو آدرس‌ها را برای میزبان‌های خاص در یک زیرشبکه نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.200\(dq } ], \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqinterface\(dq: \(dqeth0\(dq, \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dq1a:1b:1c:1d:1e:1f\(dq, \(dqip\-address\(dq: \(dq192.0.2.202\(dq }, { \(dqduid\(dq: \(dq0a:0b:0c:0d:0e:0f\(dq, \(dqip\-address\(dq: \(dq192.0.2.100\(dq, \(dqhostname\(dq: \(dqalice\-laptop\(dq }, { \(dqcircuit\-id\(dq: \(dq\(aqcharter950\(aq\(dq, \(dqip\-address\(dq: \(dq192.0.2.203\(dq }, { \(dqclient\-id\(dq: \(dq01:11:22:33:44:55:66\(dq, \(dqip\-address\(dq: \(dq192.0.2.204\(dq } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp مدخل نخست آدرس 192.0.2.202 را برای کلاینتی رزرو می‌کند که از آدرس MAC مقدار 1a:1b:1c:1d:1e:1f استفاده می‌کند. مدخل دوم آدرس 192.0.2.100 و نام میزبان \(dqalice\-laptop\(dq را برای کلاینتی که از DUID با مقدار 0a:0b:0c:0d:0e:0f استفاده می‌کند، رزرو می‌نماید. (اگر به‌روزرسانی‌های DNS برنامه‌ریزی شده باشند، اکیداً توصیه می‌شود که نام‌های میزبان یکتا باشند.) مثال سوم آدرس 192.0.3.203 را برای کلاینتی رزرو می‌کند که درخواست آن توسط یک کارگزار بازپخش (relay agent) رله می‌شود که گزینهٔ \fBcircuit\-id\fP را با مقدار \(dqcharter950\(dq درج می‌کند. مدخل چهارم آدرس 192.0.2.204 را برای کلاینتی که از شناسهٔ کلاینت با مقدار 01:11:22:33:44:55:66 استفاده می‌کند، رزرو می‌نماید. .sp مثال بالا صرفاً برای اهداف نمایشی آورده شده است؛ در استقرارهای واقعی توصیه می‌شود تا حد امکان از انواع کمتری (ترجیحاً فقط یک نوع) استفاده شود. برای بحث دقیق دربارهٔ این نکته، به Fine\-Tuning DHCPv4 Host Reservation مراجعه کنید. .sp ایجاد رزرو برای یک میزبان متحرک که ممکن است از چندین زیرشبکه بازدید کند، نیازمند تعریف میزبان جداگانه در هر زیرشبکه‌ای است که انتظار می‌رود آن میزبان در آن حضور یابد. تعریف چندین میزبان با آدرس سخت‌افزاری یکسان در یک زیرشبکهٔ واحد امکان‌پذیر نیست. تعاریف چندگانهٔ میزبان با آدرس سخت‌افزاری یکسان در صورتی معتبر هستند که هر یک در زیرشبکهٔ متفاوتی قرار داشته باشند. .sp افزودن رزروهای میزبان با افت کارایی همراه است. در اصل، زمانی که سروری که از رزرو میزبان پشتیبانی نمی‌کند به یک پرس‌وجو پاسخ می‌دهد، باید بررسی کند که آیا برای آدرس مورد نظر که برای تخصیص یا تمدید در نظر گرفته شده، اجاره‌ای (lease) وجود دارد یا خیر. سروری که از رزرو میزبان پشتیبانی می‌کند باید بررسی‌های بیشتری انجام دهد: نه تنها اینکه آیا آدرس در حال حاضر استفاده می‌شود (یعنی اجاره‌ای برای آن وجود دارد یا خیر)، بلکه اینکه آیا این آدرس ممکن است توسط شخص دیگری استفاده شود (یعنی رزروی برای آن وجود دارد یا خیر). این بررسی اضافی بار پردازشی بیشتری تحمیل می‌کند. .SS "انواع رزرو آدرس (Address Reservation Types)" .sp در یک سناریوی معمول Kea، یک زیرشبکهٔ IPv4 تعریف می‌شود (مانند 192.0.2.0/24) که بخش مشخصی از آن به تخصیص پویا توسط سرور DHCPv4 اختصاص می‌یابد. به این بخش پویا، یک استخر پویا (dynamic pool) یا به‌سادگی pool گفته می‌شود. در اصل، یک رزرو میزبان می‌تواند هر آدرسی را که متعلق به زیرشبکه است رزرو کند. رزروهایی که آدرس‌های متعلق به استخرهای پیکربندی‌شده را مشخص می‌کنند، \(dqرزروهای درون‌استخری\(dq (in\-pool reservations) نامیده می‌شوند. در مقابل، آن‌هایی که متعلق به استخرهای پویا نیستند، \(dqرزروهای برون‌استخری\(dq (out\-of\-pool reservations) نام دارند. هیچ تفاوت رسمی در نحو (syntax) رزرو وجود ندارد و هر دو نوع رزرو به‌طور یکسان مدیریت می‌شوند. .sp ابزار Kea از رزروهای سراسری میزبان پشتیبانی می‌کند. این‌ها رزروهایی هستند که در سطح سراسری (global) در پیکربندی مشخص می‌شوند و متعلق به هیچ زیرشبکهٔ خاصی نیستند. Kea همچنان بسته‌های ورودی کلاینت را مانند قبل با یک زیرشبکه تطبیق می‌دهد، اما هنگامی که حالت رزرو زیرشبکه روی \(dqglobal\(dq تنظیم شده باشد، Kea رزروهای میزبان را فقط در میان رزروهای سراسریِ تعریف‌شده جستجو می‌کند. معمولاً چنین رزروهایی برای رزرو نام‌های میزبان برای کلاینت‌هایی استفاده می‌شوند که ممکن است از یک زیرشبکه به زیرشبکهٔ دیگری جابه‌جا شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 رزروهای سراسری، اگرچه در شرایط خاصی مفید هستند، دارای جنبه‌هایی هستند که هنگام استفاده از آن‌ها باید به‌دقت مورد توجه قرار گیرند. لطفاً برای جزئیات بیشتر به Conflicts in DHCPv4 Reservations مراجعه کنید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 1.9.1 به بعد، حالت رزرو با سه پرچم بولی (boolean flags)، یعنی \fBreservations\-global\fP، \fBreservations\-in\-subnet\fP و \fBreservations\-out\-of\-pool\fP جایگزین شده است که امکان پیکربندی رزروهای میزبان را هم به‌صورت سراسری و هم درون زیرشبکه فراهم می‌کنند. در چنین مواردی، هنگامی که هر دو برای یک کلاینت یکسان وجود داشته باشند، رزرو میزبانِ زیرشبکه نسبت به رزرو سراسری اولویت دارد. .UNINDENT .UNINDENT.SS تداخل‌ها در رزروهای DHCPv4 (Conflicts in DHCPv4 Reservations) .sp از آنجا که اطلاعات مربوط به رزروها و اجاره‌ها به‌صورت جداگانه ذخیره می‌شوند، ممکن است تداخل‌هایی بروز کند. توالی رخدادهای زیر را در نظر بگیرید: کارساز استخر پویایی از نشانی‌ها را در محدودهٔ 192.0.2.10 تا 192.0.2.20 پیکربندی کرده است. میزبان Host A نشانی‌ای را درخواست می‌کند و 192.0.2.10 را دریافت می‌نماید. اکنون مدیر سیستم تصمیم می‌گیرد نشانی 192.0.2.10 را برای Host B رزرو کند. به‌طور کلی، رزرو نشانی‌ای که در حال حاضر به کس دیگری واگذار شده توصیه نمی‌شود، اما سناریوهای معتبری وجود دارد که چنین عملیاتی در آن‌ها توجیه‌پذیر است. .sp اکنون کارساز با تداخلی مواجه است که باید حل شود. اگر Host B بالا آمده و درخواستی برای یک نشانی ارسال کند، کارساز نمی‌تواند بلافاصله نشانی رزرو شدهٔ 192.0.2.10 را به آن اختصاص دهد. یک رویکرد ساده‌انگارانه این است که اجارهٔ فعلی Host A فوراً حذف شده و اجارهٔ جدیدی برای Host B ایجاد شود. با این حال این کار مشکل را برطرف نمی‌کند، زیرا به محض این‌که Host B نشانی را دریافت کند، متوجه می‌شود که این نشانی در حال حاضر (توسط Host A) در حال استفاده است و یک پیام DHCPDECLINE ارسال خواهد کرد. بنابراین، در چنین وضعیتی، کارساز باید موقتاً نشانی متفاوتی را از استخر پویا (که با آنچه رزرو شده مطابقت ندارد) به Host B اختصاص دهد. .sp هنگامی که Host A نشانی خود را تمدید می‌کند، کارساز متوجه خواهد شد نشانی‌ای که تمدید می‌شود اکنون برای میزبان دیگری \- Host B \- رزرو شده است. کارساز با ارسال یک پیام DHCPNAK به Host A اطلاع می‌دهد که دیگر مجاز به استفاده از آن نیست. با این حال کارساز اجاره را حذف نخواهد کرد، چرا که در شبکه‌های دارای اتلاف بسته (lossy)، احتمال اندکی وجود دارد که DHCPNAK تحویل داده نشود. اگر این اتفاق بیفتد، کلاینت هیچ پاسخی دریافت نمی‌کند و بنابراین بستهٔ DHCPREQUEST خود را دوباره ارسال خواهد کرد. به محض این‌که DHCPNAK توسط Host A دریافت شود، این میزبان به مرحلهٔ کشف کارساز (server discovery) بازگشته و در نهایت نشانی متفاوتی دریافت خواهد کرد. کارساز علاوه بر تخصیص اجارهٔ جدید، اجارهٔ قدیمی را نیز حذف خواهد کرد. در نتیجه، نشانی 192.0.2.10 آزاد خواهد شد. .sp هنگامی که Host B تلاش کند نشانی موقتاً تخصیص‌یافته‌اش را تمدید نماید، کارساز تشخیص می‌دهد که این میزبان دارای اجاره‌ای معتبر است، اما متوجه خواهد شد که یک رزرو برای نشانی دیگری وجود دارد. کارساز یک DHCPNAK ارسال می‌کند تا به Host B اطلاع دهد که نشانی آن دیگر قابل استفاده نیست، اما اجاره‌اش را نگه می‌دارد (مجدداً، ممکن است DHCPNAK گم شود، بنابراین کارساز آن را تا زمان بازگشت کلاینت برای دریافت نشانی جدید حفظ می‌کند). سپس Host B به فاز کشف کارساز بازگشته و سرانجام یک پیام DHCPREQUEST می‌فرستد. این بار کارساز درمی‌یابد که رزروی برای این میزبان ثبت شده و نشانی رزروشدهٔ 192.0.2.10 استفاده نمی‌شود، بنابراین آن را اعطا می‌کند. کارساز همچنین اجارهٔ مربوط به نشانی موقت قبلی Host B را حذف خواهد کرد. .sp این بازیابی حتی اگر سایر میزبان‌ها نیز تلاش کنند نشانی رزرو شده را دریافت نمایند، موفقیت‌آمیز خواهد بود. اگر Host C پس از ثبت رزرو، نشانی 192.0.2.10 را درخواست کند، کارساز یا نشانی دیگری را پیشنهاد می‌دهد (در پاسخ به DHCPDISCOVER) یا DHCPNAK ارسال می‌کند (در پاسخ به DHCPREQUEST). .sp این سازوکار به کارساز اجازه می‌دهد تا از شرایطی که رزروها با اجاره‌های موجود تداخل پیدا می‌کنند، به‌طور کامل بازیابی شود؛ با این حال، انجام این فرایند تقریباً به اندازهٔ مدت‌زمان تعیین‌شده در \fBrenew\-timer\fP\& زمان می‌برد. بهترین روش برای جلوگیری از چنین روندی، عدم تعریف رزروهای جدیدی است که با اجاره‌های موجود در تداخل هستند. توصیهٔ دیگر، استفاده از رزروهای خارج از استخر (out\-of\-pool) است؛ اگر نشانی رزروشده به هیچ استخری تعلق نداشته باشد، کلاینت‌های دیگر به هیچ وجه نمی‌توانند آن را دریافت کنند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 سازوکار حل تداخل برای رزروهای سراسری (global reservations) کار نمی‌کند. هرچند ویژگی رزرو سراسری نشانی ممکن است در پیکربندی‌های خاصی مفید باشد، عموماً توصیه می‌شود که از رزروهای سراسری برای نشانی‌ها استفاده نشود. مدیرانی که تصمیم به استفاده از رزروهای سراسری می‌گیرند، باید به‌صورت دستی اطمینان حاصل کنند که نشانی‌های رزروشده درون استخرهای پویا قرار ندارند. .UNINDENT .UNINDENT .SS رزرو نام میزبان (Reserving a Hostname) .sp هنگامی که رزرو برای یک کلاینت شامل \fBhostname\fP باشد، کارساز این نام میزبان را در گزینهٔ Client FQDN یا Hostname به کلاینت بازمی‌گرداند. کارساز تنها در صورتی با گزینهٔ Client FQDN پاسخ می‌دهد که کلاینت گزینهٔ Client FQDN را در پیام ارسالی خود به کارساز گنجانده باشد. در صورتی که کلاینت گزینهٔ Hostname را در پیام خود گنجانده باشد یا گزینهٔ Hostname را از طریق گزینهٔ Parameter Request List درخواست کرده باشد، کارساز با گزینهٔ Hostname پاسخ می‌دهد. کارساز حتی اگر برای انجام به‌روزرسانی‌های DNS پیکربندی نشده باشد نیز گزینهٔ Hostname را بازمی‌گرداند. نام میزبان رزروشده همواره بر نام میزبان ارائه‌شده توسط کلاینت یا نام میزبان خودتولیدشده (از روی نشانی IPv4) اولویت دارد. .sp کارساز نام میزبان رزروشده را با مقدار پارامتر \fBddns\-qualifying\-suffix\fP تکمیل (qualify) می‌کند. برای نمونه، پیکربندی زیرشبکهٔ زیر: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.10\-10.0.0.100\(dq } ], \(dqddns\-qualifying\-suffix\(dq: \(dqexample.isc.org.\(dq, \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqhostname\(dq: \(dqalice\-laptop\(dq } ] } ], \(dqdhcp\-ddns\(dq: { \(dqenable\-updates\(dq: true } } .EE .UNINDENT .UNINDENT .sp باعث تخصیص نام میزبان \(dqalice\-laptop.example.isc.org.\(dq به کلاینت دارای نشانی MAC برابر با \(dqaa:bb:cc:dd:ee:ff\(dq خواهد شد. اگر \fBddns\-qualifying\-suffix\fP مشخص نشده باشد، از مقدار پیش‌فرض (خالی) استفاده خواهد شد و در این حالت، مقدار ارائه‌شده در \fBhostname\fP به عنوان یک نام کاملاً واجد شرایط (FQDN) تلقی می‌شود. بدین ترتیب، با خالی گذاشتن \fBddns\-qualifying\-suffix\fP، امکان تخصیص نام‌های دامنهٔ متفاوت به کلاینت‌های گوناگون وجود خواهد داشت: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.10\-10.0.0.100\(dq } ], \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqhostname\(dq: \(dqalice\-laptop.isc.org.\(dq }, { \(dqhw\-address\(dq: \(dq12:34:56:78:99:AA\(dq, \(dqhostname\(dq: \(dqmark\-desktop.example.org.\(dq } ] } ], \(dqdhcp\-ddns\(dq: { \(dqenable\-updates\(dq: true } } .EE .UNINDENT .UNINDENT .sp مثال بالا منجر به اختصاص نام میزبان \(dqalice\-laptop.isc.org.\(dq به کلاینت با نشانی MAC برابر با \(dqaa:bb:cc:dd:ee:ff\(dq، و نام میزبان \(dqmark\-desktop.example.org.\(dq به کلاینت با نشانی MAC برابر با \(dq12:34:56:78:99:AA\(dq می‌گردد..SS گنجاندن گزینه‌های مشخص DHCPv4 در رزروها .sp Kea امکان تعیین گزینه‌ها را بر اساس هر میزبان فراهم می‌کند. این گزینه‌ها از همان قوانین حاکم بر سایر گزینه‌ها پیروی می‌کنند. این موارد می‌توانند گزینه‌های استاندارد (بخش Standard DHCPv4 Options را ببینید)، گزینه‌های سفارشی (بخش Custom DHCPv4 Options را ببینید)، یا گزینه‌های وابسته به سازنده (بخش DHCPv4 Vendor\-Specific Options را ببینید) باشند. مثال زیر نحوهٔ تعریف گزینه‌های استاندارد را نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqip\-address\(dq: \(dq192.0.2.1\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqcookie\-servers\(dq, \(dqdata\(dq: \(dq10.1.1.202,10.1.1.203\(dq }, { \(dqname\(dq: \(dqlog\-servers\(dq, \(dqdata\(dq: \(dq10.1.1.200,10.1.1.201\(dq } ] } ], ... } ], ... } .EE .UNINDENT .UNINDENT .sp گزینه‌های وابسته به سازنده را می‌توان به شیوه‌ای مشابه رزرو کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqip\-address\(dq: \(dq10.0.0.7\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqvivso\-suboptions\(dq, \(dqdata\(dq: \(dq4491\(dq }, { \(dqname\(dq: \(dqtftp\-servers\(dq, \(dqspace\(dq: \(dqvendor\-4491\(dq, \(dqdata\(dq: \(dq10.1.1.202,10.1.1.203\(dq } ] } ], ... } ], ... } .EE .UNINDENT .UNINDENT .sp گزینه‌های تعریف‌شده در سطح میزبان بالاترین اولویت را دارند. به عبارت دیگر، اگر گزینه‌هایی با نوع یکسان در سطوح سراسری، زیرشبکه، کلاس و میزبان تعریف شده باشند، مقادیر ویژهٔ میزبان استفاده می‌شوند. .SS رزرو Next Server، Server Hostname و Boot File Name .sp پیام‌های BOOTP/DHCPv4 شامل فیلدهای \(dqsiaddr\(dq، \(dqsname\(dq و \(dqfile\(dq هستند. اگرچه DHCPv4 شامل گزینه‌های متناظر مانند گزینهٔ ۶۶ و گزینهٔ ۶۷ است، اما ممکن است برخی کلاینت‌ها از این گزینه‌ها پشتیبانی نکنند. به همین دلیل، مدیران سرور اغلب به جای آن از فیلدهای \(dqsiaddr\(dq، \(dqsname\(dq و \(dqfile\(dq استفاده می‌کنند. .sp با Kea، انجام رزروهای ایستا برای این فیلدهای پیام DHCPv4 امکان‌پذیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqnext\-server\(dq: \(dq10.1.1.2\(dq, \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq, \(dqboot\-file\-name\(dq: \(dq/usr/local/share/kea/bootfile.efi\(dq } ], ... } ], ... } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که این پارامترها را می‌توان در ترکیب با سایر پارامترها برای یک رزرو مشخص کرد، مانند یک نشانی IPv4 رزروشده. این پارامترها اختیاری هستند؛ می‌توان زیرمجموعه‌ای از آن‌ها را مشخص کرد یا تمام آن‌ها را نادیده گرفت. .SS رزرو کلاس‌های کلاینت در DHCPv4 .sp بخش Using Expressions in Classification \%<#\:classification-using-expressions> نحوهٔ پیکربندی سرور را برای تخصیص کلاس‌ها به یک کلاینت، بر اساس محتوای گزینه‌هایی که آن کلاینت به سرور ارسال می‌کند، توضیح می‌دهد. سازوکارهای رزرو میزبان همچنین امکان تخصیص ایستای کلاس‌ها به کلاینت‌ها را فراهم می‌کنند. تعاریف این کلاس‌ها در فایل پیکربندی Kea یا یک پایگاه داده قرار می‌گیرد. قطعه‌پیکربندی زیر نحوهٔ تعیین تعلق یک کلاینت به کلاس‌های \fBreserved\-class1\fP و \fBreserved\-class2\fP را نشان می‌دهد. این کلاس‌ها با گزینه‌های خاصی که به کلاینت‌های متعلق به آن‌ها ارسال می‌شود، مرتبط هستند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqreserved\-class1\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq10.0.0.200\(dq } ] }, { \(dqname\(dq: \(dqreserved\-class2\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqdata\(dq: \(dq10.0.0.201\(dq } ] } ], \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.10\-10.0.0.100\(dq } ], \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqclient\-classes\(dq: [ \(dqreserved\-class1\(dq, \(dqreserved\-class2\(dq ] } ] } ] } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کلاس‌های فهرست‌شده در فهرست \fBclient\-classes\fP یک رزرو، بدون قید و شرط به کلاینتِ آن رزرو اختصاص داده می‌شوند، چه آن کلاس‌ها حاوی یک عبارت آزمون باشند و چه نباشند. برای جلوگیری از سردرگمی، پیشنهاد می‌شود که کلاس‌های کلاینتی که صرفاً از طریق رزروهای میزبان تخصیص می‌یابند، فاقد عبارت‌های آزمون باشند. .UNINDENT .UNINDENT .sp در برخی موارد می‌توان رزروهای میزبان را در ارتباط با کلاس‌های کلاینت مشخص‌شده در پیکربندی Kea استفاده کرد. به‌ویژه، هنگامی که یک رزرو میزبان برای یک کلاینت در یک زیرشبکهٔ معین وجود دارد، کلاس توکار \(dqKNOWN\(dq به کلاینت اختصاص می‌یابد. در مقابل، هنگامی که هیچ تخصیص ایستایی برای کلاینت وجود ندارد، کلاس \(dqUNKNOWN\(dq به کلاینت اختصاص داده می‌شود. عبارت‌های کلاسی در فایل پیکربندی Kea می‌توانند با استفاده از عملگر \(dqmember\(dq به کلاس‌های \(dqKNOWN\(dq یا \(dqUNKNOWN\(dq ارجاع دهند. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqdependent\-class\(dq, \(dqtest\(dq: \(dqmember(\(aqKNOWN\(aq)\(dq, \(dqonly\-in\-additional\-list\(dq: true } ] } .EE .UNINDENT .UNINDENT .sp پارامتر \fBonly\-in\-additional\-list\fP در اینجا برای اجبار به ارزیابی کلاس پس از تخصیص اجاره لازم است، تا کلاس رزروشده نیز تخصیص یافته باشد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کلاس‌های مشخص‌شده در رزروهای میزبان غیرسراسری، پس از ارزیابی تمام کلاس‌هایی که پارامتر \fBonly\-in\-additional\-list\fP آن‌ها روی \fBfalse\fP تنظیم شده است، به بستهٔ پردازش‌شده تخصیص می‌یابند. این بدان معناست که این کلاس‌ها نباید به کلاس‌های تخصیص‌یافتهٔ ایستا از طریق رزروهای میزبان وابسته باشند. اگر چنین وابستگی‌ای نیاز باشد، پارامتر \fBonly\-in\-additional\-list\fP برای کلاس‌های وابسته باید روی \fBtrue\fP تنظیم شود. این کلاس‌ها پس از اختصاص کلاس‌های ایستا به بسته، ارزیابی می‌شوند. با این حال، این امر بار پیکربندی اضافی تحمیل می‌کند، زیرا تمام کلاس‌هایی که با \fBonly\-in\-additional\-list\fP مشخص شده‌اند باید در فهرست \fBevaluate\-additional\-classes\fP برای هر زیرشبکه‌ای که در آن استفاده می‌شوند، ذکر شوند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کلاس‌های کلاینت مشخص‌شده در فایل پیکربندی Kea ممکن است به کلاس‌های مشخص‌شده در رزروهای سراسری میزبان وابسته باشند. در چنین حالتی به پارامتر \fBonly\-in\-additional\-list\fP نیازی نیست. برای موارد کاربرد خاص به بخش‌های Pool Selection with Client Class Reservations و Subnet Selection with Client Class Reservations مراجعه کنید. .UNINDENT .UNINDENT.SS ذخیره‌سازی رزروهای میزبان در MySQL یا PostgreSQL .sp کارساز Kea می‌تواند رزروهای میزبان را در MySQL یا PostgreSQL ذخیره کند. برای کسب اطلاعات در مورد نحوه پیکربندی Kea جهت استفاده از رزروهای ذخیره‌شده در MySQL یا PostgreSQL، بخش Hosts Storage را ببینید. کارساز Kea یک قلاب (hook) اختصاصی برای مدیریت رزروها در پایگاه داده ارائه می‌دهد؛ بخش libdhcp_host_cmds.so: Host Commands \%<#\:hooks-host-cmds> اطلاعات دقیقی را ارائه می‌کند. ویکی Kea در \% نمونه‌هایی از نحوه انجام عملیات‌های معمول رزرو میزبان ارائه می‌دهد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در Kea، حداکثر طول گزینه‌ای که به ازای هر رزرو میزبان (per\-host\-reservation) مشخص می‌شود، به‌طور قراردادی بر روی ۴۰۹۶ بایت تنظیم شده است. .UNINDENT .UNINDENT .SS تنظیم دقیق رزرو میزبان در DHCPv4 .sp قابلیت رزرو میزبان محدودیت‌های بیشتری را برای موتور تخصیص (بخشی از Kea که آدرسی را برای یک کلاینت انتخاب می‌کند) هنگام انتخاب و تمدید اجاره (lease) اعمال می‌کند. به‌ویژه، سه بررسی عمده ضروری است. نخست، هنگام انتخاب یک اجاره جدید، کافی نیست که اجاره کاندید صرفاً توسط کلاینت DHCP دیگری در حال استفاده نباشد؛ بلکه نباید برای کلاینت دیگری نیز رزرو شده باشد. به همین ترتیب، هنگام تمدید یک اجاره، باید بررسی دیگری انجام شود تا مشخص گردد آیا آدرسی که تمدید می‌شود برای کلاینت دیگری رزرو شده است یا خیر. در نهایت، هنگامی که یک میزبان آدرسی را تمدید می‌کند، کارساز باید بررسی کند که آیا رزروی برای این میزبان وجود دارد یا خیر؛ وجود رزرو به این معنا خواهد بود که آدرس فعلی (که به‌صورت پویا تخصیص یافته) باید لغو شده و آدرس رزروشده به جای آن استفاده شود. .sp برخی از این بررسی‌ها ممکن است در برخی استقرارها غیرضروری باشند و عدم انجام آن‌ها می‌تواند عملکرد را بهبود بخشد. کارساز Kea پارامترهای پیکربندی \fBreservations\-global\fP، \fBreservations\-in\-subnet\fP و \fBreservations\-out\-of\-pool\fP را برای انتخاب انواع رزروهای مجاز برای یک زیرشبکه خاص ارائه می‌دهد. هر نوع رزرو محدودیت‌های متفاوتی برای بررسی‌هایی دارد که باید توسط کارساز هنگام تخصیص یا تمدید اجاره برای کلاینت انجام شوند. .sp پرچم‌های پیکربندی عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBreservations\-in\-subnet\fP \- هنگامی که روی \fBtrue\fP تنظیم شود، انواع رزرو میزبان درون استخر (in\-pool) را فعال می‌کند. این تنظیم مقدار پیش‌فرض بوده و امن‌ترین و انعطاف‌پذیرترین حالت است. با این حال، از آنجا که تمام بررسی‌ها انجام می‌شوند، کندترین حالت نیز هست. این پرچم بررسی در برابر رزروهای سراسری را انجام نمی‌دهد. مقدار پیش‌فرض این پرچم \fBtrue\fP است\&. .IP \(bu 2 \fBreservations\-out\-of\-pool\fP \- هنگامی که روی \fBtrue\fP تنظیم شود، فقط رزروهای میزبان خارج از استخر (out\-of\-pool) را مجاز می‌کند. در این حالت کارساز فرض می‌کند که تمام رزروهای میزبان برای آدرس‌هایی هستند که به استخر پویا تعلق ندارند. بنابراین، می‌تواند بررسی‌های رزرو را هنگام سروکار داشتن با آدرس‌های درون استخر نادیده بگیرد و بدین ترتیب عملکرد را بهبود بخشد. در صورتی که هر یک از رزروها از آدرس‌های درون استخر استفاده می‌کنند از این حالت استفاده نکنید. هنگام استفاده از این تنظیم احتیاط توصیه می‌شود؛ Kea صحت رزروها را در برابر \fBreservations\-out\-of\-pool\fP بررسی نمی‌کند و پیکربندی نادرست ممکن است مشکلاتی ایجاد کند. مقدار پیش‌فرض این پرچم \fBfalse\fP است\&. .IP \(bu 2 \fBreservations\-global\fP \- رزروهای سراسری میزبان را مجاز می‌کند. با این تنظیم، کارساز رزروهای مربوط به یک کلاینت را در میان رزروهای سراسری تعریف‌شده جستجو می‌کند. در صورت مشخص بودن یک آدرس، کارساز بررسی‌های رزرو انجام‌شده در حالت‌های دیگر را نادیده می‌گیرد و بنابراین کارایی را بهبود می‌بخشد. هنگام استفاده از این تنظیم احتیاط توصیه می‌شود؛ Kea در صورتی که \fBreservations\-global\fP روی \fBtrue\fP تنظیم شده باشد، صحت رزروها را بررسی نمی‌کند و پیکربندی نادرست ممکن است مشکلاتی به وجود آورد. مقدار پیش‌فرض این پرچم \fBfalse\fP است\&. .UNINDENT .INDENT 0.0 .TP .B نکته: تنظیم تمام پرچم‌ها روی \fBfalse\fP پشتیبانی از رزرو میزبان را غیرفعال می‌کند. از آنجا که هیچ رزروی وجود ندارد، کارساز تمام بررسی‌ها را نادیده می‌گیرد. هر رزرو تعریف‌شده‌ای کاملاً نادیده گرفته می‌شود. از آنجا که بررسی‌ها نادیده گرفته می‌شوند، کارساز ممکن است در این حالت سریع‌تر کار کند. .UNINDENT .sp از Kea 1.9.1 به بعد پرچم‌های \fBreservations\-global\fP، \fBreservations\-in\-subnet\fP و \fBreservations\-out\-of\-pool\fP پشتیبانی می‌شوند. .sp پارامترهای \fBreservations\-global\fP، \fBreservations\-in\-subnet\fP و \fBreservations\-out\-of\-pool\fP می‌توانند در سطوح زیر مشخص شوند: .INDENT 0.0 .IP \(bu 2 سطح سراسری (global): \fB\&.Dhcp4[\(dqreservations\-global\(dq]\fP (پایین‌ترین اولویت: توسط سایر سطوح رونویسی می‌شود) .IP \(bu 2 سطح زیرشبکه (subnet): \fB\&.Dhcp4.subnet4[][\(dqreservations\-in\-subnet\(dq]\fP (اولویت پایین) .IP \(bu 2 سطح شبکه مشترک (shared\-network): \fB\&.Dhcp4[\(dqshared\-networks\(dq][][\(dqreservations\-out\-of\-pool\(dq]\fP (اولویت بالا) .IP \(bu 2 سطح زیرشبکه در شبکه مشترک (shared\-network subnet): \fB\&.Dhcp4[\(dqshared\-networks\(dq][].subnet4[][\(dqreservations\-out\-of\-pool\(dq]\fP (بالاترین اولویت: سایر سطوح را رونویسی می‌کند) .UNINDENT .sp برای تصمیم‌گیری در مورد استفاده از پرچم‌ها، نمودار تصمیم‌گیری زیر می‌تواند مفید باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX O | v +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | Is per\-host configuration needed, such as | | reserving specific addresses, | | assigning specific options or | | assigning packets to specific classes on per\-device basis? | +\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | no| yes| | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | | For all given hosts, | +\-\-> \(dqdisabled\(dq +\-\->+ can the reserved resources | | be used in all configured subnets? | +\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-+ | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ |no |yes | Is | | | | at least one reservation +<\-\-+ \(dqglobal\(dq <\-\-+ | used to reserve addresses? | +\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-+ | | no| yes| +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | | Is high leases\-per\-second | +\-\-> \(dqout\-of\-pool\(dq +\-\->+ performance or efficient | ^ | resource usage | | | (CPU ticks, RAM usage, | | | database roundtrips) | | | important to your setup? | | +\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+ | | | | yes| no| | | | | +\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | | | | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | | | Can it be guaranteed | | | +\-\->+ that the reserved | | | | addresses | | | | aren\(aqt part of the | | | | pools configured | | | | in the respective | | | | subnet? | | | +\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-+ | | | | | | yes| no| | | | | V +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +\-\-> \(dqin\-subnet\(dq .EE .UNINDENT .UNINDENT .sp نمونه‌ای از پیکربندی که رزروها را غیرفعال می‌کند به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10\-192.0.2.100\(dq } ], \(dqreservations\-global\(dq: false, \(dqreservations\-in\-subnet\(dq: false, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq } ] } } .EE .UNINDENT .UNINDENT .sp یک نمونه پیکربندی با استفاده از رزروهای سراسری در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqreservations\-global\(dq: true, \(dqreservations\(dq: [ { \(dqhostname\(dq: \(dqhost\-one\(dq, \(dqhw\-address\(dq: \(dq01:bb:cc:dd:ee:ff\(dq }, { \(dqhostname\(dq: \(dqhost\-two\(dq, \(dqhw\-address\(dq: \(dq02:bb:cc:dd:ee:ff\(dq } ], \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10\-192.0.2.100\(dq } ], \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq } ] } } .EE .UNINDENT .UNINDENT .sp معنای پرچم‌های رزرو عبارتند از: .INDENT 0.0.IP \(bu 2 \fBreservations\-global\fP: واکشی رزروهای سراسری. .IP \(bu 2 \fBreservations\-in\-subnet\fP: واکشی رزروهای زیرشبکه. برای یک شبکهٔ اشتراکی این شامل تمامی زیرشبکه‌های عضو آن شبکهٔ اشتراکی می‌شود. .IP \(bu 2 \fBreservations\-out\-of\-pool\fP: این گزینه تنها زمانی کاربرد دارد که پرچم \fBreservations\-in\-subnet\fP برابر با \fBtrue\fP باشد\&. هنگامی که \fBreservations\-out\-of\-pool\fP برابر با \fBtrue\fP باشد، کارساز فرض می‌کند که تمامی رزروهای میزبان برای نشانی‌هایی هستند که به استخر پویا تعلق ندارند. بنابراین، می‌تواند هنگام سروکار داشتن با نشانی‌های درون استخر از بررسی‌های رزرو صرف‌نظر کرده و بدین‌صورت کارایی را بهبود بخشد. کارساز نشانی‌های رزروشده‌ای را که درون استخرهای پویا قرار دارند به کلاینت‌های مربوطه اختصاص نخواهد داد. این همچنین بدان معناست که نشانی‌های منطبق بر رزروهای مربوطه از درون استخرهای پویا (در صورت وجود) می‌توانند به‌طور پویا به هر کلاینتی اختصاص یابند. .UNINDENT .sp پیکربندی \fBdisabled\fP معادل است با: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqreservations\-global\(dq: false, \(dqreservations\-in\-subnet\(dq: false } } .EE .UNINDENT .UNINDENT .sp پیکربندی \fBglobal\fP با استفاده از \fBreservations\-global\fP معادل است با: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqreservations\-global\(dq: true, \(dqreservations\-in\-subnet\(dq: false } } .EE .UNINDENT .UNINDENT .sp پیکربندی \fBout\-of\-pool\fP با استفاده از \fBreservations\-out\-of\-pool\fP معادل است با: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqreservations\-global\(dq: false, \(dqreservations\-in\-subnet\(dq: true, \(dqreservations\-out\-of\-pool\(dq: true } } .EE .UNINDENT .UNINDENT .sp و پیکربندی \fBin\-subnet\fP با استفاده از \fBreservations\-in\-subnet\fP معادل است با: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqreservations\-global\(dq: false, \(dqreservations\-in\-subnet\(dq: true, \(dqreservations\-out\-of\-pool\(dq: false } } .EE .UNINDENT .UNINDENT .sp برای فعال‌سازی هم‌زمان \fBglobal\fP و \fBin\-subnet\fP، می‌توان از ترکیب زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqreservations\-global\(dq: true, \(dqreservations\-in\-subnet\(dq: true, \(dqreservations\-out\-of\-pool\(dq: false } } .EE .UNINDENT .UNINDENT .sp برای فعال‌سازی هم‌زمان \fBglobal\fP و \fBout\-of\-pool\fP، می‌توان از ترکیب زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqreservations\-global\(dq: true, \(dqreservations\-in\-subnet\(dq: true, \(dqreservations\-out\-of\-pool\(dq: true } } .EE .UNINDENT .UNINDENT .sp فعال کردن \fBout\-of\-pool\fP و غیرفعال کردن \fBin\-subnet\fP به‌طور هم‌زمان پیشنهاد نمی‌شود؛ زیرا \fBout\-of\-pool\fP بر رزروهای میزبان در یک زیرشبکه اعمال می‌شود که تنها زمانی واکشی می‌شوند که پرچم \fBin\-subnet\fP برابر با \fBtrue\fP باشد\&. .sp این پارامتر می‌تواند در سطوح سراسری (global)، زیرشبکه (subnet) و شبکهٔ اشتراکی (shared\-network) مشخص شود. .sp یک نمونه پیکربندی که رزروها را غیرفعال می‌کند به شرح زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqreservations\-global\(dq: false, \(dqreservations\-in\-subnet\(dq: false, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqid\(dq: 1 } ] } } .EE .UNINDENT .UNINDENT .sp یک نمونه پیکربندی با استفاده از رزروهای سراسری در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqreservations\(dq: [ { \(dqhostname\(dq: \(dqhost\-one\(dq, \(dqhw\-address\(dq: \(dq01:bb:cc:dd:ee:ff\(dq }, { \(dqhostname\(dq: \(dqhost\-two\(dq, \(dqhw\-address\(dq: \(dq02:bb:cc:dd:ee:ff\(dq } ], \(dqreservations\-global\(dq: true, \(dqreservations\-in\-subnet\(dq: false, \(dqsubnet4\(dq: [ { \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10\-192.0.2.100\(dq } ], \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqid\(dq: 1 } ] } } .EE .UNINDENT .UNINDENT .sp برای جزئیات بیشتر در رابطه با رزروهای سراسری، به Global Reservations in DHCPv4 مراجعه کنید\&. .sp جنبهٔ دیگری از رزروهای میزبان، انواع مختلف شناسه‌ها است. Kea در حال حاضر از چهار نوع شناسه پشتیبانی می‌کند: \fBhw\-address\fP، \fBduid\fP، \fBclient\-id\fP و \fBcircuit\-id\fP\&. این قابلیت از دیدگاه کاربردپذیری سودمند است؛ با این حال، یک ایراد به همراه دارد. به ازای هر بستهٔ دریافتی، Kea باید هر نوع شناسه را استخراج کرده و سپس پایگاه‌داده را پرس‌وجو کند تا مشخص شود آیا رزروی با این شناسهٔ مشخص وجود دارد یا خیر. اگر موردی یافت نشود، شناسهٔ بعدی استخراج شده و پرس‌وجوی بعدی ارسال می‌شود. این فرآیند تا زمانی که رزروی پیدا شود یا تمامی انواع شناسه‌ها بررسی شوند ادامه می‌یابد. به مرور زمان و با افزایش تعداد انواع شناسه‌های پشتیبانی‌شده، Kea کندتر و کندتر خواهد شد. .sp برای برطرف کردن این مشکل، پارامتری با عنوان \fBhost\-reservation\-identifiers\fP ارائه شده است. این پارامتر فهرستی از انواع شناسه را دریافت می‌کند. Kea تنها آن دسته از انواع شناسه را بررسی می‌کند که در \fBhost\-reservation\-identifiers\fP برشمرده شده‌اند\&. از دیدگاه عملکرد، تعداد انواع شناسه باید در کمترین حد ممکن، ترجیحاً یک مورد، نگه داشته شود. اگر محیط شما از چندین نوع رزرو استفاده می‌کند، لطفاً آن‌ها را از پرکاربردترین به کم‌کاربردترین فهرست کنید؛ زیرا این کار احتمال یافتن رزرو توسط Kea با کمترین تعداد پرس‌وجو را بالا می‌برد. یک نمونه از پیکربندی \fBhost\-reservation\-identifiers\fP به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhost\-reservation\-identifiers\(dq: [ \(dqcircuit\-id\(dq, \(dqhw\-address\(dq, \(dqduid\(dq, \(dqclient\-id\(dq ], \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, ... } ], \&... } .EE .UNINDENT .UNINDENT .sp در صورت عدم تعیین، مقدار پیش‌فرض به شرح زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqhost\-reservation\-identifiers\(dq: [ \(dqhw\-address\(dq, \(dqduid\(dq, \(dqcircuit\-id\(dq, \(dqclient\-id\(dq ] .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 به محض یافتن یک رزرو میزبان، جستجو متوقف می‌شود؛ هنگامی که یک کلاینت دارای دو رزرو میزبان با استفاده از انواع مختلفی از شناسه‌های فعال باشد، همیشه نخستین مورد بازگردانده شده و مورد دوم نادیده گرفته می‌شود. به عبارت دیگر، این حالت معمولاً یک خطای پیکربندی محسوب می‌شود. در موارد نادری که داشتن دو رزرو برای یک میزبان منطقی باشد، رزروی که باید استفاده شود را می‌توان با مرتب‌سازی فهرست انواع شناسه‌ها در \fBhost\-reservation\-identifiers\fP تعیین کرد\&. .UNINDENT .UNINDENT.SS "رزروهای سراسری در DHCPv4" .sp در برخی پیاده‌سازی‌ها، مانند شبکه‌های تلفن همراه، کلاینت‌ها می‌توانند درون شبکه جابه‌جا شوند (roam کنند) و برخی پارامترها باید بدون در نظر گرفتن مکان فعلی کلاینت مشخص شوند. برای برآورده ساختن چنین نیازی، Kea سازوکار رزرو سراسری (global reservation) را ارائه می‌دهد. ایدهٔ نهفته در این سازوکار این است که رزروهای معمول میزبان با استفاده از یک subnet ID مشخص، به زیرشبکه‌های خاصی وابسته هستند. Kea می‌تواند رزروی سراسری تعیین کند که در تمام زیرشبکه‌های دارای رزرو سراسریِ فعال، قابل استفاده باشد. .sp از این ویژگی می‌توان برای تخصیص پارامترهای مشخصی مانند hostname یا دیگر گزینه‌های اختصاصی و ویژهٔ میزبان استفاده کرد. همچنین می‌توان از آن برای تخصیص آدرس‌ها نیز بهره برد. .sp آدرسی که از طریق رزرو سراسری میزبان تخصیص می‌یابد باید برای زیرشبکه‌ای که سرور برای کلاینت انتخاب می‌کند، امکان‌پذیر (feasible) باشد. به عبارت دیگر، آدرس باید در محدودهٔ زیرشبکه قرار داشته باشد؛ در غیر این صورت، نادیده گرفته می‌شود و سرور تلاش خواهد کرد تا آدرسی را به‌صورت پویا تخصیص دهد. اگر زیرشبکهٔ انتخاب‌شده به یک shared network تعلق داشته باشد، سرور امکان‌پذیر بودن را در مقایسه با زیرشبکه‌های هم‌ردیف (siblings) بررسی کرده و نخستین زیرشبکهٔ در محدوده را انتخاب می‌نماید. اگر چنین زیرشبکه‌ای وجود نداشته باشد، سرور به تخصیص پویای آدرس بازمی‌گردد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پیش از نسخهٔ 2.3.5، سرور بررسی‌های امکان‌پذیری را روی آدرس‌های رزروشده به‌صورت سراسری انجام نمی‌داد، که این امر اجازه می‌داد سرور به گونه‌ای پیکربندی شود که اجاره‌های (leases) بی‌معنی برای مقادیر دلخواه آدرس صادر کند. نسخه‌های بعدی Kea این بررسی‌ها را انجام می‌دهند. .UNINDENT .UNINDENT .sp برای استفاده از رزروهای سراسری میزبان، می‌توان از پیکربندی مشابه زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { # This specifies global reservations. # They will apply to all subnets that # have global reservations enabled. \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqhostname\(dq: \(dqhw\-host\-dynamic\(dq }, { \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqhostname\(dq: \(dqhw\-host\-fixed\(dq, # Use of IP addresses in global reservations is risky. # If used outside of a matching subnet, such as 192.0.1.0/24, # it will result in a broken configuration being handed # to the client. \(dqip\-address\(dq: \(dq192.0.1.77\(dq }, { \(dqduid\(dq: \(dq01:02:03:04:05\(dq, \(dqhostname\(dq: \(dqduid\-host\(dq }, { \(dqcircuit\-id\(dq: \(dq\(aqcharter950\(aq\(dq, \(dqhostname\(dq: \(dqcircuit\-id\-host\(dq }, { \(dqclient\-id\(dq: \(dq01:11:22:33:44:55:66\(dq, \(dqhostname\(dq: \(dqclient\-id\-host\(dq } ], \(dqvalid\-lifetime\(dq: 600, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/24\(dq, # Specify if the server should look up global reservations. \(dqreservations\-global\(dq: true, # Specify if the server should look up in\-subnet reservations. \(dqreservations\-in\-subnet\(dq: false, # Specify if the server can assume that all reserved addresses # are out\-of\-pool. It can be ignored because \(dqreservations\-in\-subnet\(dq # is false. # \(dqreservations\-out\-of\-pool\(dq: false, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.10\-10.0.0.100\(dq } ] } ] } .EE .UNINDENT .UNINDENT .sp هنگام استفاده از backendهای پایگاه‌داده، رزروهای سراسری میزبان با استفاده از مقدار 0 برای \fBsubnet\-id\fP از رزروهای عادی متمایز می‌شوند. .SS "انتخاب استخر با رزروهای کلاس کلاینت" .sp کلاس‌های کلاینت (Client classes) می‌توانند در فایل پیکربندی Kea و/یا از طریق رزروهای میزبان تعیین شوند. کلاس‌های مشخص‌شده در فایل پیکربندی Kea بلافاصله پس از دریافت بستهٔ DHCP ارزیابی می‌شوند و بنابراین می‌توان از آن‌ها برای اثرگذاری بر انتخاب زیرشبکه با استفاده از پارامتر \fBclient\-classes\fP مشخص‌شده در حوزهٔ (scope) زیرشبکه استفاده کرد. کلاس‌های مشخص‌شده درون رزروهای میزبان، پس از آن‌که سرور زیرشبکه‌ای را برای کلاینت انتخاب کرد، واکشی شده و به بسته اختصاص می‌یابند. این بدان معناست که کلاس کلاینت مشخص‌شده درون یک رزرو میزبان نمی‌تواند برای تأثیرگذاری بر تخصیص زیرشبکه به این کلاینت استفاده شود، مگر اینکه زیرشبکه متعلق به یک shared network باشد. اگر زیرشبکه متعلق به یک shared network باشد، ممکن است سرور هنگام تلاش برای تخصیص اجاره (lease)، تخصیص زیرشبکه را به‌صورت پویا تغییر دهد. اگر زیرشبکه به یک shared network تعلق نداشته باشد، زیرشبکه پس از یک‌بار انتخاب شدن، دیگر تغییر نخواهد کرد. .sp اگر زیرشبکه متعلق به یک shared network نباشد، می‌توان از دسته‌بندی کلاینت مبتنی بر رزرو میزبان برای انتخاب یک استخر (pool) در زیرشبکه، به شرح زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqreserved_class\(dq }, { \(dqname\(dq: \(dqunreserved_class\(dq, \(dqtest\(dq: \(dqnot member(\(aqreserved_class\(aq)\(dq } ], \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:fe\(dq, \(dqclient\-classes\(dq: [ \(dqunreserved_class\(dq ] } ], \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq, \(dqclient\-classes\(dq: [ \(dqunreserved_class\(dq ] }, { \(dqpool\(dq: \(dq192.0.2.30 \- 192.0.2.40\(dq, \(dqclient\-classes\(dq: [ \(dqreserved_class\(dq ] }, { \(dqpool\(dq: \(dq192.0.2.50 \- 192.0.2.60\(dq } ] } ] } } .EE .UNINDENT .UNINDENT .sp کلاس \fBreserved_class\fP بدون پارامتر \fBtest\fP اعلان شده است زیرا تنها می‌تواند از طریق سازوکار رزرو میزبان به یک کلاینت اختصاص یابد. کلاس دوم، \fBunreserved_class\fP، به کلاینت‌هایی اختصاص داده می‌شود که به \fBreserved_class\fP تعلق ندارند\&. .sp نخستین استخر در زیرشبکه برای کلاینت‌هایی استفاده می‌شود که چنین رزروی ندارند. استخر دوم تنها برای کلاینت‌هایی استفاده می‌شود که دارای رزروی برای \fBreserved_class\fP هستند\&. استخر سوم یک استخر بدون محدودیت برای همهٔ کلاینت‌هاست که شامل کلاینت‌های هر دو دستهٔ \fBreserved_class\fP و \fBunreserved_class\fP می‌شود\&. .sp این قطعه‌پیکربندی شامل یک رزرو میزبان است که باعث می‌شود کلاینت با آدرس MAC معادل \fBaa:bb:cc:dd:ee:fe\fP به \fBreserved_class\fP اختصاص یابد\&. بدین ترتیب، به این کلاینت یک آدرس IP از دومین استخر آدرس اختصاص داده می‌شود. .sp رزروهای تعریف‌شده در زیرشبکه‌ای که متعلق به یک shared network است، برای کلاینتی که در غیر این صورت با آن منطبق می‌بود قابل مشاهده نیستند؛ بنابراین نمی‌توان از آن‌ها برای انتخاب استخرها و همچنین زیرشبکه‌ها استفاده کرد..SS انتخاب زیرشبکه با رزروهای کلاس کلاینت (Subnet Selection with Client Class Reservations) .sp یک مورد کاربرد خاص وجود دارد که در آن انتخاب زیرشبکه ممکن است تحت تأثیر کلاس‌های کلاینت مشخص‌شده درون رزروهای میزبان قرار گیرد: زمانی که کلاینت به یک شبکهٔ اشتراکی (shared network) تعلق دارد. در چنین حالتی امکان استفاده از رده‌بندی برای انتخاب یک زیرشبکه درون این شبکهٔ اشتراکی وجود دارد. مثال زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqreserved_class\(dq }, { \(dqname\(dq: \(dqunreserved_class\(dq, \(dqtest\(dq: \(dqnot member(\(aqreserved_class\(aq)\(dq } ], \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:fe\(dq, \(dqclient\-classes\(dq: [ \(dqreserved_class\(dq ] } ], \(dqreservations\-global\(dq: true, \(dqreservations\-in\-subnet\(dq: false, \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqnet\(dq, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10\-192.0.2.20\(dq, \(dqclient\-classes\(dq: [ \(dqunreserved_class\(dq ] }, { \(dqpool\(dq: \(dq192.0.2.30\-192.0.2.40\(dq, \(dqclient\-classes\(dq: [ \(dqunreserved_class\(dq ] } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.3.10\-192.0.3.20\(dq, \(dqclient\-classes\(dq: [ \(dqreserved_class\(dq ] }, { \(dqpool\(dq: \(dq192.0.3.30\-192.0.3.40\(dq, \(dqclient\-classes\(dq: [ \(dqreserved_class\(dq ] } ] }, { \(dqid\(dq: 3, \(dqsubnet\(dq: \(dq192.0.4.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.4.10\-192.0.4.20\(dq }, { \(dqpool\(dq: \(dq192.0.4.30\-192.0.4.40\(dq } ] } ] } ] } } .EE .UNINDENT .UNINDENT .sp این شبیه به مثالی است که در Pool Selection with Client Class Reservations\& شرح داده شده است. با این حال، این بار سه زیرشبکه وجود دارد که استخرهای (pools) دو مورد اول هر کدام با یک کلاس متفاوت مرتبط هستند. .sp به کلاینت‌هایی که رزروی برای \fBreserved_class\fP ندارند، نشانی‌ای از زیرشبکهٔ اول تخصیص داده می‌شود و هنگامی که آن پر شد، از زیرشبکهٔ سوم. به کلاینت‌های دارای رزرو برای \fBreserved_class\fP، نشانی‌ای از زیرشبکهٔ دوم و هنگام پر شدن آن، از زیرشبکهٔ سوم تخصیص می‌یابد. .sp زیرشبکه‌ها باید متعلق به یک شبکهٔ اشتراکی یکسان باشند. .sp برای اینکه یک زیرشبکه به یک کلاس خاص محدود شود، یا از آن صرف‌نظر گردد، تمام استخرهای درون آن زیرشبکه باید به ترتیب توسط \fBreserved_class\fP یا \fBunreserved_class\fP محافظت شوند. .sp علاوه بر این، رزرو برای کلاس کلاینت باید در حوزهٔ سراسری (رزرو سراسری) مشخص شود و مقدار \fBreservations\-global\fP باید روی \fBtrue\fP تنظیم شده باشد\&. .sp در مثال بالا، پارامتر پیکربندی \fBclient\-classes\fP می‌توانست به جای سطح استخر در سطح زیرشبکه نیز مشخص شود و همان اثر را داشته باشد. .sp اگر زیرشبکه‌ها خارج از شبکه‌های اشتراکی تعریف می‌شدند و \fBclient\-classes\fP در سطح زیرشبکه مشخص می‌شد، آنگاه برای کارکرد انتخاب زیرشبکه، فعال بودن \fBearly\-global\-reservations\-lookup\fP نیز الزامی می‌بود. .SS رزروهای چندگانه برای یک IP یکسان (Multiple Reservations for the Same IP) .sp رزروهای میزبان برای جلوگیری از ایجاد چندین رزرو برای یک نشانی IP یکسان درون یک زیرشبکهٔ خاص طراحی شده‌اند تا از رقابت دو کلاینت مختلف بر سر یک نشانی جلوگیری شود. هنگام استفاده از تنظیمات پیش‌فرض، اگر سرور دو یا چند رزرو برای یک نشانی IP یکسان در یک زیرشبکه درون فایل پیکربندی Kea پیدا کند، خطای پیکربندی برمی‌گرداند. \fBlibdhcp_host_cmds.so\fP \%<#\:std-ischooklib-libdhcp_host_cmds\:.so> در پاسخ به دستور \fBreservation\-add\fP \%<#\:std-isccmd-reservation-add>، در صورتی که تشخیص دهد برای نشانی IP مورد نظری که رزرو جدید برای آن افزوده می‌شود رزروی در پایگاه داده وجود دارد، یک خطا برمی‌گرداند. .sp در برخی استقرارها، یک میزبان واحد می‌تواند یکی از چندین رابط شبکه را برای برقراری ارتباط با سرور DHCP انتخاب کند، و سرور باید بدون توجه به رابطِ استفاده‌شده، نشانی IP یکسانی را به میزبان تخصیص دهد. از آنجا که به هر رابط یک نشانی MAC متفاوت تخصیص می‌یابد، به این معنی است که باید چندین رزرو میزبان ایجاد شود تا تمام نشانی‌های MAC موجود در این میزبان را با نشانی‌های IP مرتبط کند. استفاده از نشانی‌های IP مختلف برای هر رابط غیرعملی است و اتلاف فضای نشانی IPv4 تلقی می‌شود، به‌ویژه از آنجا که میزبان معمولاً تنها از یک رابط برای ارتباط با سرور استفاده می‌کند و بنابراین تنها یک نشانی IP در حال استفاده است. .sp این امر نیاز به ایجاد چندین رزرو میزبان برای یک نشانی IP واحد درون یک زیرشبکه را ایجاد می‌کند؛ این امکان از نسخهٔ Kea 1.9.1 به عنوان یک حالت عملیاتی اختیاری پشتیبانی می‌شود که با پارامتر سراسری \fBip\-reservations\-unique\fP فعال می‌گردد. .sp پارامتر \fBip\-reservations\-unique\fP یک پارامتر بولی (boolean) است که مقدار پیش‌فرض آن \fBtrue\fP است و تعیین بیش از یک رزرو برای یک نشانی IP یکسان را در یک زیرشبکهٔ مشخص ممنوع می‌کند. تنظیم این پارامتر روی \fBfalse\fP اجازه می‌دهد تا چنین رزروهایی هم در فایل پیکربندی Kea و هم در بک‌اند پایگاه دادهٔ میزبان، از طریق \fBlibdhcp_host_cmds.so\fP \%<#\:std-ischooklib-libdhcp_host_cmds\:.so>\& ایجاد شوند. .sp تنظیم \fBip\-reservations\-unique\fP روی \fBfalse\fP هنگام استفاده از memfile، MySQL یا PostgreSQL پشتیبانی می‌شود. این تنظیم هنگام استفاده از Host Cache (نگاه کنید به libdhcp_host_cache.so: Host Cache Reservations for Improved Performance \%<#\:hooks-host-cache>) یا بک‌اند RADIUS (نگاه کنید به libdhcp_radius.so: RADIUS Server Support \%<#\:hooks-radius>) پشتیبانی نمی‌شود. این بک‌اندهای رزرو از چندین رزرو برای یک IP یکسان پشتیبانی نمی‌کنند؛ اگر هر یک از این قلاب‌ها (hooks) بارگذاری شده باشد و \fBip\-reservations\-unique\fP روی \fBfalse\fP تنظیم شود، آنگاه خطای پیکربندی صادر شده و سرور راه‌اندازی نمی‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگامی که \fBip\-reservations\-unique\fP روی \fBtrue\fP (مقدار پیش‌فرض) تنظیم شده باشد، سرور تضمین می‌کند که رزروهای IP برای یک زیرشبکه درون یک بک‌اند میزبان منفرد و/یا فایل پیکربندی Kea یکتا هستند. این کار تضمین نمی‌کند که رزروها در چندین بک‌اند یکتا باشند. هنگام راه‌اندازی سرور، تنها رزروهای IP تعریف‌شده در فایل پیکربندی Kea از نظر یکتایی بررسی می‌شوند. .UNINDENT .UNINDENT .sp در ادامه یک پیکربندی نمونه با دو رزرو برای یک نشانی IP یکسان اما با نشانی‌های MAC متفاوت آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqip\-reservations\-unique\(dq: false, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dq1a:1b:1c:1d:1e:1f\(dq, \(dqip\-address\(dq: \(dq192.0.2.11\(dq }, { \(dqhw\-address\(dq: \(dq2a:2b:2c:2d:2e:2f\(dq, \(dqip\-address\(dq: \(dq192.0.2.11\(dq } ] } ] } .EE .UNINDENT .UNINDENT .sp امکان کنترل پارامتر \fBip\-reservations\-unique\fP از طریق Configuration Backend در DHCPv4 وجود دارد\&. اگر تنظیم جدید این پارامتر با بک‌اندهای فعلی مورد استفاده در تضاد باشد (یعنی بک‌اندها از تنظیم جدید پشتیبانی نکنند)، تنظیم جدید نادیده گرفته شده و یک پیام ثبت وقایع هشداری ایجاد می‌شود. بک‌اندها با این فرض که رزروهای IP در هر زیرشبکه یکتا هستند، به استفاده از تنظیم پیش‌فرض ادامه می‌دهند. برای مجاز کردن ایجاد رزروهای IP غیریکتا، مدیر سیستم باید بک‌اندهایی را که از آن‌ها پشتیبانی نمی‌کنند از فایل پیکربندی حذف کند. .sp مدیران سیستم باید هنگامی که از رزروهای چندگانه برای یک نشانی IP یکسان استفاده کرده‌اند و بعداً تصمیم می‌گیرند به حالت پیش‌فرض بازگردند (که در آن این کار دیگر مجاز نیست)، دقت لازم را به عمل آورند. آن‌ها باید پیش از بازگشت به حالت پیش‌فرض، اطمینان حاصل کنند که حداکثر یک رزرو برای یک نشانی IP مشخص درون یک زیرشبکه وجود دارد. اگر چنین موارد تکراری در فایل پیکربندی باقی بمانند، سرور خطای پیکربندی گزارش می‌دهد. باقی گذاشتن چنین رزروهایی در پایگاه‌های دادهٔ میزبان باعث خطای پیکربندی نمی‌شود، اما ممکن است در حین کارکرد سرور هنگامی که به‌طور غیرمنتظره با چندین رزرو برای یک نشانی IP مواجه می‌شود، منجر به خطاهای تخصیص اجاره (lease) گردد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر، سرور Kea بررسی نمی‌کند که آیا با به‌روزرسانی \fBip\-reservations\-unique\fP از \fBfalse\fP به \fBtrue\fP، چندین رزرو برای یک نشانی IP در پایگاه‌های دادهٔ میزبان MySQL و/یا PostgreSQL وجود دارد یا خیر\&. این امر ممکن است باعث ایجاد مشکلاتی در تخصیص اجاره‌ها شود. مدیر سیستم باید پیش از به‌روزرسانی پیکربندی اطمینان حاصل کند که برای هر نشانی IP در هر زیرشبکه حداکثر یک رزرو وجود دارد. .UNINDENT .UNINDENT .sp پارامتر \fBreservations\-lookup\-first\fP یک پارامتر بولی است که کنترل می‌کند آیا جستجوی رزروهای میزبان باید پیش از جستجوی اجاره (lease lookup) انجام شود یا خیر. این پارامتر تنها زمانی تأثیرگذار است که چندریسمانی (multi\-threading) غیرفعال باشد. هنگامی که چندریسمانی فعال باشد، جستجوی رزروهای میزبان همواره ابتدا انجام می‌شود تا از قفل شدن منابع هنگام جستجوی اجاره جلوگیری شود. مقدار پیش‌فرض پارامتر \fBreservations\-lookup\-first\fP در زمان غیرفعال بودن چندریسمانی، \fBfalse\fP است..SS رزرو میزبان به‌عنوان کنترل دسترسی پایه‌ای .sp تعریف یک رزرو میزبان (host reservation) که تنها حاوی یک شناسه، بدون هیچ آدرس، گزینه یا مقداری باشد، امکان‌پذیر است. در برخی استقرارها این کار مفید است، چرا که میزبان‌های دارای رزرو به کلاس KNOWN تعلق دارند در حالی که سایر میزبان‌ها تعلق ندارند. از این قابلیت می‌توان به‌عنوان یک سازوکار پایه‌ای کنترل دسترسی استفاده کرد. .sp مثال زیر این مفهوم را نشان می‌دهد. این مثال یک زیرشبکه IPv4 واحد را مشخص می‌کند که تمام کارخواه‌ها آدرسی از آن دریافت خواهند کرد. با این حال، تنها کارخواه‌های شناخته‌شده (آن‌هایی که رزرو دارند) مسیریاب پیش‌فرضشان پیکربندی خواهد شد. رزروهای خالی، یعنی رزروهایی که تنها معیار شناسایی دارند، می‌توانند به‌عنوان روشی برای شناخته‌شدن کارخواه‌ها سودمند باشند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqKNOWN\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.2.250\(dq } ] } ], \(dqreservations\(dq: [ // کارخواه‌های این فهرست به کلاس KNOWN افزوده خواهند شد. { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:fe\(dq }, { \(dqhw\-address\(dq: \(dq11:22:33:44:55:66\(dq } ], \(dqreservations\-global\(dq: true, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1\-192.0.2.200\(dq } ] } ] } .EE .UNINDENT .UNINDENT .sp این مفهوم را می‌توان با استفاده از رزروها در ترکیب با برچسب‌گذاری کلاسی گزینه‌ها (ببینید Option Class\-Tagging \%<#\:option-class-tagging>) فراتر نیز گسترش داد. یک سناریوی واقعی مناسب می‌تواند وضعیتی باشد که در آن برخی از مشتریان یک ISP صورت‌حساب‌های خود را پرداخت نکرده‌اند. به این مشتریان باید یک مسیریاب جایگزین اختصاص داده شود که به‌جای هدایت و بازپخش ترافیک، آن‌ها را به یک پورتال ورود (captive portal) هدایت کرده و از آن‌ها بخواهد حساب‌های خود را تسویه کنند. می‌توان از رزروها برای تخصیص یک کارخواه به کلاس \(dqblocked\(dq استفاده کرد که متعاقباً برای تعیین مقدار گزینه مسیریاب همان‌طور که در زیر نشان داده شده است، به کار می‌رود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqblocked\(dq } ], \(dqreservations\(dq: [ // کارخواه‌های این فهرست به کلاس KNOWN افزوده خواهند شد. برخی // نیز به کلاس blocked افزوده می‌شوند. { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:fe\(dq, \(dqclient\-classes\(dq: [ \(dqblocked\(dq ] }, { \(dqhw\-address\(dq: \(dq11:22:33:44:55:66\(dq } ], \(dqreservations\-global\(dq: true, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1\-192.0.2.200\(dq } ], \(dqoption\-data\(dq: [ { // مسیریاب برای مشتریان مسدودشده. \(dqclient\-classes\(dq: [ \(dqblocked\(dq ], \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.2.251\(dq }, { // مسیریاب برای مشتریان خوش‌حساب. \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.2.250\(dq } ] } ] } .EE .UNINDENT .UNINDENT .SS شبکه‌های اشتراکی در DHCPv4 .sp کارسازهای DHCP اطلاعات زیرشبکه را به دو روش به کار می‌برند. این اطلاعات هم برای تعیین نقطه اتصال، یعنی جایی که کارخواه به شبکه متصل است، و هم برای گروه‌بندی اطلاعات مربوط به یک مکان خاص در شبکه استفاده می‌شود. گاهی اوقات استقرار بیش از یک زیرشبکه منطقی IP روی یک پیوند فیزیکی یکسان مفید است. درک این‌که دو یا چند زیرشبکه روی یک پیوند یکسان استفاده می‌شوند نیازمند منطق اضافی در کارساز DHCP است. این قابلیت در Kea با عنوان \(dqشبکه‌های اشتراکی\(dq (shared networks) و گاهی نیز \(dqshared subnets\(dq نامیده می‌شود؛ در نام‌گذاری Microsoft به آن \(dqmultinet\(dq گفته می‌شود. .sp موارد متعددی وجود دارد که ویژگی شبکه‌های اشتراکی در آن‌ها سودمند است؛ در این‌جا تنها به چند مورد از رایج‌ترین آن‌ها اشاره می‌کنیم. نخستین و تا حد زیادی رایج‌ترین مورد استفاده، یک شبکه IPv4 موجود است که گسترش یافته و فضای آدرس در دسترس آن رو به پایان است. به‌جای مهاجرت دادن تمام دستگاه‌ها به یک زیرشبکه جدید و بزرگ‌تر، آسان‌تر است که زیرشبکه‌های اضافی روی زیرشبکه موجود پیکربندی شوند. گاهی اوقات به دلیل تکه‌تکه شدن فضای آدرس (برای نمونه هنگامی که تنها چندین /24 ناپیوسته در دسترس است)، این تنها انتخاب ممکن است. همچنین، پیکربندی زیرشبکه‌های اضافی این مزیت را دارد که در عملکرد دستگاه‌های موجود اختلالی ایجاد نمی‌کند. .sp یک مورد استفاده بسیار متداول دیگر به شبکه‌های کابلی مربوط می‌شود. دو نوع دستگاه در شبکه‌های کابلی وجود دارد: مودم‌های کابلی و دستگاه‌های کاربر نهایی که پشت آن‌ها قرار دارند. این یک رویه معمول است که از زیرشبکه‌های متفاوتی برای مودم‌های کابلی استفاده شود تا از دستکاری آن‌ها توسط کاربران جلوگیری به عمل آید. در این حالت، تمایز بر اساس نوع دستگاه صورت می‌گیرد و نه بر اساس اتمام فضای آدرس. .sp به کارخواهی که به یک شبکه اشتراکی متصل است، ممکن است آدرسی از هر یک از استخرهای تعریف‌شده در زیرشبکه‌های متعلق به آن شبکه اشتراکی اختصاص داده شود. از نظر داخلی، کارساز یکی از زیرشبکه‌های متعلق به شبکه اشتراکی را انتخاب کرده و تلاش می‌کند آدرسی را از این زیرشبکه تخصیص دهد. اگر کارساز نتواند آدرسی از زیرشبکه انتخاب‌شده تخصیص دهد (به‌عنوان مثال به دلیل اتمام استخر آدرس)، از زیرشبکه دیگری از همان شبکه اشتراکی استفاده کرده و سعی می‌کند آدرسی از آن تخصیص دهد. کارساز معمولاً پیش از شروع تخصیص آدرس از سایر زیرشبکه‌های متعلق به همان شبکه اشتراکی، تمام آدرس‌های موجود در یک زیرشبکه مفروض را تخصیص می‌دهد. با این حال، در شرایط خاص ممکن است پیش از پایان یافتن استخرهای آدرس در زیرشبکه نخست، آدرسی از زیرشبکه دیگری به کارخواه اختصاص یابد؛ این حالت گاهی زمانی رخ می‌دهد که کارخواه یک نشانه (hint) متعلق به زیرشبکه دیگری ارائه دهد، یا کارخواه دارای رزروهایی در زیرشبکه‌ای غیر از پیش‌فرض باشد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 استقرارها نباید فرض کنند که Kea پیش از تخصیص آدرس از سایر زیرشبکه‌ها، حتماً منتظر می‌ماند تا تمام آدرس‌های زیرشبکه نخست در یک شبکه اشتراکی را تخصیص دهد. .UNINDENT .UNINDENT .sp برای تعریف یک شبکه اشتراکی، یک حوزه (scope) پیکربندی اضافی معرفی شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqshared\-networks\(dq: [ { # نام شبکه اشتراکی. این می‌تواند یک رشته دلخواه باشد # و باید میان تمام شبکه‌های اشتراکی یکتا باشد. \(dqname\(dq: \(dqmy\-secret\-lair\-level\-1\(dq, # انتخاب‌گر زیرشبکه می‌تواند در سطح shared\-network مشخص شود. # زیرشبکه‌های این شبکه اشتراکی برای کارخواه‌های متصل مستقیم # که درخواست‌ها را به رابط \(dqeth0\(dq کارساز می‌فرستند انتخاب خواهند شد. \(dqinterface\(dq: \(dqeth0\(dq, # این بخش فهرست زیرشبکه‌ها را در این شبکه اشتراکی آغاز می‌کند. # در این مثال دو زیرشبکه وجود دارد. \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.1 \- 10.0.0.99\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.100 \- 192.0.2.199\(dq } ] } ] } ], # پایان shared\-networks # احتمال دارد که در شبکه ترکیبی از زیرشبکه‌های عادی، # \(dqساده\(dq و شبکه‌های اشتراکی وجود داشته باشد. ترکیب آن‌ها # در همان فایل پیکربندی کاملاً مجاز است. # # این یک زیرشبکه عادی است. بخشی از هیچ شبکه اشتراکی نیست. \(dqsubnet4\(dq: [ { \(dqid\(dq: 3, \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.3.1 \- 192.0.3.200\(dq } ], \(dqinterface\(dq: \(dqeth1\(dq } ] } } .EE .UNINDENT .UNINDENT .sp همان‌طور که در مثال نشان داده شد، ترکیب زیرشبکه‌های اشتراکی و عادی (\(dqساده\(dq) امکان‌پذیر است. هر شبکه اشتراکی باید نامی یکتا داشته باشد. این نام مشابه شناسه (ID) برای زیرشبکه‌ها است، اما انعطاف‌پذیری بیشتری به مدیران سیستم می‌دهد. این نام برای ثبت وقایع (logging) و همچنین در سطوح داخلی برای شناسایی شبکه‌های اشتراکی به کار می‌رود. .sp در اصل، تعریف شبکه‌های اشتراکی که تنها شامل دو یا چند زیرشبکه باشند منطقی است. با این حال، برای اهداف آزمایشی، یک زیرشبکه خالی یا شبکه‌ای با تنها یک زیرشبکه مجاز است. این رویه در شبکه‌های عملیاتی توصیه نمی‌شود، چرا که منطق شبکه اشتراکی نیازمند پردازش اضافی بوده و در نتیجه کارایی کارساز را کاهش می‌دهد. برای جلوگیری از افت غیرضروری کارایی، زیرشبکه‌های اشتراکی تنها باید زمانی تعریف شوند که استقرار شبکه به آن‌ها نیاز داشته باشد. .sp شبکه‌های اشتراکی این امکان را فراهم می‌کنند که پارامترهای متعددی را در حوزه شبکه اشتراکی تعیین کنید که برای تمام زیرشبکه‌های درون آن اعمال می‌شوند. در صورت نیاز، این امکان وجود دارد که پارامتری در حوزه shared\-network مشخص شده و سپس مقدار آن در حوزه زیرشبکه بازنویسی شود. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqlab\-network3\(dq, \(dqinterface\(dq: \(dqeth0\(dq, # این مقدار برای تمام زیرشبکه‌های این شبکه اشتراکی اعمال می‌شود، مگر # این‌که مقادیر در حوزه زیرشبکه بازنویسی شوند. \(dqvalid\-lifetime\(dq: 600, # این گزینه در دسترس تمام زیرشبکه‌های این شبکه اشتراکی # قرار می‌گیرد. \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqlog\-servers\(dq, \(dqdata\(dq: \(dq1.2.3.4\(dq } ], \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.1 \- 10.0.0.99\(dq } ], # این زیرشبکه خاص از مقادیر متفاوتی استفاده می‌کند. \(dqvalid\-lifetime\(dq: 1200, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqlog\-servers\(dq, \(dqdata\(dq: \(dq10.0.0.254\(dq }, { \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq10.0.0.254\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.100 \- 192.0.2.199\(dq } ], # این زیرشبکه مقدار valid\-lifetime اختصاصی خود را مشخص نکرده است، # بنابراین از حوزه شبکه اشتراکی به ارث برده می‌شود. \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.2.1\(dq } ] } ] } ], ... } .EE .UNINDENT .UNINDENT .sp در این مثال، گزینه \fBlog\-servers\fP تعریف شده است که برای کارخواه‌ها در هر دو زیرشبکه این شبکه اشتراکی در دسترس است. همچنین، طول عمر معتبر (valid lifetime) روی ۱۰ دقیقه (600s) تنظیم شده است. با این حال، زیرشبکه نخست برخی از مقادیر را بازنویسی می‌کند (طول عمر معتبر ۲۰ دقیقه است و یک آدرس IP متفاوت برای \fBlog\-servers\fP وجود دارد)، و همچنین گزینه اختصاصی خود را اضافه می‌کند (آدرس مسیریاب). با فرض این‌که به کارخواهی که گزینه‌های مسیریاب و \fBlog\-servers\fP را درخواست می‌کند، یک اجاره (lease) از این زیرشبکه اختصاص یابد، اجاره‌ای به مدت ۲۰ دقیقه و مقدار 10.0.0.254 برای \fBlog\-servers\fP و routers دریافت خواهد کرد. اگر همان کارخواه به زیرشبکه دوم اختصاص یابد، یک اجاره ۱۰ دقیقه‌ای، مقدار 1.2.3.4 برای \fBlog\-servers\fP و routers تنظیم‌شده روی 192.0.2.1 را دریافت خواهد کرد..SS "ترافیک محلی و رله‌شده در شبکه‌های اشتراکی" .sp این امکان وجود دارد که نام یک رابط را در سطح shared\-network مشخص کنید تا به کارساز اعلام شود که این شبکه اشتراکیِ مشخص، مستقیماً (نه از طریق رله‌ها) و با استفاده از رابط شبکه محلی در دسترس است. از آنجا که انتظار می‌رود تمام زیرشبکه‌ها در یک شبکه اشتراکی روی پیوند فیزیکی یکسانی استفاده شوند، تلاش برای تعریف یک شبکه اشتراکی با زیرشبکه‌هایی که از طریق رابط‌های متفاوتی در دسترس هستند یک خطای پیکربندی محسوب می‌شود. به عبارت دیگر، تمام زیرشبکه‌های درون شبکه اشتراکی باید مقدار یکسانی برای پارامتر \fBinterface\fP داشته باشند. پیکربندی زیر نمونه‌ای از کاری است که \fBنباید\fP انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqoffice\-floor\-2\(dq, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.1 \- 10.0.0.99\(dq } ], \(dqinterface\(dq: \(dqeth0\(dq }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.100 \- 192.0.2.199\(dq } ], # Specifying the different interface name is a configuration # error. This value should rather be \(dqeth0\(dq or the interface # name in the other subnet should be \(dqeth1\(dq. \(dqinterface\(dq: \(dqeth1\(dq } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp برای به حداقل رساندن احتمال خطاهای پیکربندی، اغلب راحت‌تر است که نام رابط را به سادگی یک بار در سطح shared\-network مشخص کنید، همان‌طور که در مثال زیر نشان داده شده است. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqoffice\-floor\-2\(dq, # This tells Kea that the whole shared network is reachable over a # local interface. This applies to all subnets in this network. \(dqinterface\(dq: \(dqeth0\(dq, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.1 \- 10.0.0.99\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.100 \- 192.0.2.199\(dq } ] } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp در ترافیک رله‌شده، زیرشبکه‌ها معمولاً با استفاده از نشانی‌های عامل‌های رله انتخاب می‌شوند. اگر زیرشبکه‌ها به طور مستقل استفاده شوند (در یک شبکه اشتراکی گروه‌بندی نشده باشند)، می‌توان یک نشانی رله متفاوت برای هر یک از این زیرشبکه‌ها مشخص کرد. هنگامی که چندین زیرشبکه متعلق به یک شبکه اشتراکی هستند، باید از طریق همان نشانی رله یکسان انتخاب شوند و مشابه مورد ترافیک محلی که در بالا شرح داده شد، تعیین نشانی‌های رله متفاوت برای زیرشبکه‌های مربوطه در شبکه اشتراکی یک خطای پیکربندی است. پیکربندی زیر نمونه دیگری از کارهایی است که \fBنباید\fP انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqkakapo\(dq, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/26\(dq, \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq192.1.1.1\(dq ] }, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.63 \- 192.0.2.63\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq10.0.0.0/24\(dq, \(dqrelay\(dq: { # Specifying a different relay address for this # subnet is a configuration error. In this case # it should be 192.1.1.1 or the relay address # in the previous subnet should be 192.2.2.2. \(dqip\-addresses\(dq: [ \(dq192.2.2.2\(dq ] }, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.16 \- 10.0.0.16\(dq } ] } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp مجدداً، بهتر است نشانی رله در سطح shared\-network مشخص شود؛ این مقدار توسط تمام زیرشبکه‌های متعلق به شبکه اشتراکی به ارث برده خواهد شد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqkakapo\(dq, \(dqrelay\(dq: { # This relay address is inherited by both subnets. \(dqip\-addresses\(dq: [ \(dq192.1.1.1\(dq ] }, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/26\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.63 \- 192.0.2.63\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq10.0.0.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.16 \- 10.0.0.16\(dq } ] } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp اگرچه از نظر فنی امکان پیکربندی دو (یا چند) زیرشبکه در یک شبکه اشتراکی برای استفاده از نشانی‌های رله متفاوت وجود دارد، اما این کار تقریباً همیشه به رفتاری متفاوت از آنچه کاربر انتظار دارد منجر خواهد شد. در این حالت، کارساز Kea ابتدا یکی از زیرشبکه‌ها را با تطبیق نشانی رله در بسته کلاینت با پیکربندی زیرشبکه انتخاب می‌کند. با این حال، در صورتی که کلاینت از قبل اجاره‌ای در این زیرشبکه داشته باشد یا یک رزرو میزبان (host reservation) در این زیرشبکه داشته باشد، یا صرفاً اگر زیرشبکه انتخاب‌شده اولیه نشانی دردسترس دیگری نداشته باشد، کارساز ممکن است در نهایت از زیرشبکه دیگر استفاده کند (حتی اگر با نشانی رله مطابقت نداشته باشد). بنابراین، در صورتی که زیرشبکه‌ها متعلق به یک شبکه اشتراکی هستند، اکیداً توصیه می‌شود انتخاب‌کننده‌های زیرشبکه (رابط یا نشانی رله) همیشه در سطح shared\-network مشخص شوند، چرا که تعیین آن‌ها در سطح زیرشبکه به‌ندرت مفید است و ممکن است به خطاهای پیکربندی شرح داده شده در بالا منجر شود..SS کلاس‌بندی کلاینت در شبکه‌های اشتراکی .sp گاهی مطلوب است که کلاینت‌ها بر اساس ویژگی‌های معینی به زیرشبکه‌های مشخصی تفکیک شوند. این سازوکار «کلاس‌بندی کلاینت» نامیده می‌شود و در Client Classification \%<#\:classify>\& شرح داده شده است. .sp کلاس‌بندی کلاینت می‌تواند برای زیرشبکه‌های متعلق به شبکه‌های اشتراکی نیز دقیقاً به همان روشی که برای زیرشبکه‌های خارج از شبکه‌های اشتراکی به کار می‌رود، اعمال شود. درک نحوه انتخاب زیرشبکه برای کلاینت‌ها توسط سرور در زمان استفاده از کلاس‌بندی کلاینت اهمیت بالایی دارد، تا اطمینان حاصل شود که زیرشبکه مناسب برای یک نوع کلاینت خاص انتخاب می‌شود. .sp اگر یک زیرشبکه با یک یا چند کلاس مرتبط شده باشد، تنها کلاینت‌هایی که دست‌کم به یکی از این کلاس‌ها تعلق دارند می‌توانند از این زیرشبکه استفاده کنند. اگر کلاسی برای یک زیرشبکه مشخص نشده باشد، هر کلاینت متصل به یک شبکه اشتراکی مفروض می‌تواند از آن زیرشبکه استفاده کند. یک اشتباه رایج این است که فرض شود زیرشبکه‌ای که دارای کلاس کلاینت است بر زیرشبکه‌های بدون کلاس ترجیح داده می‌شود. .sp پارامتر \fBclient\-classes\fP را می‌توان در دامنه‌های شبکه اشتراکی (shared network)، زیرشبکه (subnet) و/یا استخر (pool) مشخص کرد. اگر برای یک شبکه اشتراکی مشخص شود، کلاینت‌ها باید حداقل عضو یکی از کلاس‌های تعیین‌شده برای آن شبکه باشند تا برای زیرشبکه‌های درون آن شبکه در نظر گرفته شوند. اگر برای یک زیرشبکه مشخص شود، کلاینت‌ها باید حداقل عضو یکی از کلاس‌های تعیین‌شده برای آن زیرشبکه باشند تا برای استخرها یا رزروهای میزبان (host reservations) آن زیرشبکه در نظر گرفته شوند. اگر برای یک pool مشخص شود، کلاینت‌ها باید حداقل به یکی از کلاس‌های مشخص‌شده برای آن pool تعلق داشته باشند تا یک اجاره (lease) از آن pool دریافت کنند. .sp مثال زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqb\-devices\(dq, \(dqtest\(dq: \(dqoption[93].hex == 0x0002\(dq } ], \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqgalah\(dq, \(dqinterface\(dq: \(dqeth0\(dq, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/26\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.63\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq10.0.0.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.2 \- 10.0.0.250\(dq } ], \(dqclient\-classes\(dq: [ \(dqb\-devices\(dq ] } ] } ] } .EE .UNINDENT .UNINDENT .sp اگر کلاینت به کلاس \(dqb\-devices\(dq تعلق داشته باشد (چون شامل option 93 با مقدار 0x0002 است)، این امر تضمین نمی‌کند که زیرشبکه 10.0.0.0/24 برای این کلاینت استفاده شود (یا ترجیح داده شود). سرور می‌تواند از هر یک از این دو زیرشبکه استفاده کند، چرا که زیرشبکه 192.0.2.0/26 نیز برای این کلاینت مجاز است. کلاس‌بندی کلاینت مورد استفاده در این مورد باید به عنوان راهکاری برای محدود کردن دسترسی به زیرشبکه‌های خاص در نظر گرفته شود، نه به عنوان روشی برای تعیین اولویت زیرشبکه. برای نمونه، اگر کلاینتی عضو کلاس \(dqb\-devices\(dq نباشد، فقط می‌تواند از زیرشبکه 192.0.2.0/26 استفاده کند و هرگز از زیرشبکه 10.0.0.0/24 استفاده نخواهد کرد. .sp یک کاربرد متداول برای کلاس‌بندی کلاینت در شبکه‌های کابلی (cable networks) است؛ جایی که مودم‌های کابلی باید از یک زیرشبکه و سایر دستگاه‌ها باید از زیرشبکه دیگری در همان شبکه اشتراکی استفاده کنند. در این حالت لازم است کلاس‌بندی بر روی تمام زیرشبکه‌ها اعمال شود. مثال زیر دو کلاس از دستگاه‌ها را تعریف می‌کند و انتخاب زیرشبکه بر اساس مقادیر option 93 صورت می‌گیرد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqa\-devices\(dq, \(dqtest\(dq: \(dqoption[93].hex == 0x0001\(dq }, { \(dqname\(dq: \(dqb\-devices\(dq, \(dqtest\(dq: \(dqoption[93].hex == 0x0002\(dq } ], \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqgalah\(dq, \(dqinterface\(dq: \(dqeth0\(dq, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/26\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.63\(dq } ], \(dqclient\-classes\(dq: [ \(dqa\-devices\(dq ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq10.0.0.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.2 \- 10.0.0.250\(dq } ], \(dqclient\-classes\(dq: [ \(dqb\-devices\(dq ] } ] } ] } .EE .UNINDENT .UNINDENT .sp در این مثال هر کلاس محدودیت خاص خود را دارد. تنها کلاینت‌هایی که متعلق به کلاس \(dqa\-devices\(dq هستند می‌توانند از زیرشبکه 192.0.2.0/26 استفاده کنند و تنها کلاینت‌های متعلق به \(dqb\-devices\(dq مجاز به استفاده از زیرشبکه 10.0.0.0/24 هستند. باید مراقبت کرد که قوانین کلاس‌بندی بیش از حد محدودکننده تعریف نشوند، چرا که کلاینت‌هایی که نتوانند از هیچ زیرشبکه‌ای استفاده کنند، رد سرویس خواهند شد. با این حال، اگر هدف ارائه‌ی سرویس فقط به کلاینت‌هایی با ویژگی‌های مشخص باشد (برای مثال، تنها تلفن‌های VoIP مجاز به اتصال روی یک پیوند باشند)، این رفتار می‌تواند نتیجه‌ی مطلوب باشد. .sp دستیابی به اثری مشابه با آنچه در این بخش مطرح شد، بدون استفاده از شبکه‌های اشتراکی نیز ممکن است. اگر زیرشبکه‌ها به جای شبکه اشتراکی در دامنه سراسری زیرشبکه‌ها (global subnets scope) قرار گیرند، سرور همچنان از قوانین کلاس‌بندی برای انتخاب زیرشبکه مناسب برای کلاس مشخصی از دستگاه‌ها استفاده خواهد کرد. مزیت عمده قرار دادن زیرشبکه‌ها درون شبکه اشتراکی این است که پارامترهای مشترک برای زیرشبکه‌هایی که به صورت منطقی گروه‌بندی شده‌اند، می‌تواند یک‌بار در دامنه shared\-network تعیین شود؛ مانند پارامتر \fBinterface\fP یا \fBrelay\fP. تمامی زیرشبکه‌های متعلق به این شبکه اشتراکی این پارامترها را به ارث خواهند برد..SS رزروهای میزبان در شبکه‌های اشتراکی (Host Reservations in Shared Networks) .sp زیرشبکه‌هایی که بخشی از یک شبکه اشتراکی (shared network) هستند، مانند زیرشبکه‌های معمولی امکان رزرو میزبان را فراهم می‌کنند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqfrog\(dq, \(dqinterface\(dq: \(dqeth0\(dq, \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.0/26\(dq, \(dqid\(dq: 100, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.63\(dq } ], \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqip\-address\(dq: \(dq192.0.2.28\(dq } ] }, { \(dqsubnet\(dq: \(dq10.0.0.0/24\(dq, \(dqid\(dq: 101, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.0.0.1 \- 10.0.0.254\(dq } ], \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dq11:22:33:44:55:66\(dq, \(dqip\-address\(dq: \(dq10.0.0.29\(dq } ] } ] } ] } .EE .UNINDENT .UNINDENT .sp شایان ذکر است که در صورت تعریف شبکه‌های اشتراکی، Kea هنگام پردازش یک بسته، بررسی‌های بیشتری انجام می‌دهد. نخست، Kea به‌جای بررسی ساده این موضوع که آیا برای یک کلاینت معین در زیرشبکه نخستینِ انتخاب‌شده رزروی وجود دارد یا خیر، تمام زیرشبکه‌های موجود در یک شبکه اشتراکی را برای یافتن رزرو جستجو می‌کند. این یکی از دلایلی است که تعریف یک شبکه اشتراکی ممکن است بر کارایی تأثیر بگذارد. اگر در هر زیرشبکه‌ای رزروی برای یک کلاینت وجود داشته باشد، همان زیرشبکه خاص برای کلاینت انتخاب می‌شود. هرچند از نظر فنی این یک خطا محسوب نمی‌شود، اما تعریف رزرو برای یک میزبان یکسان در چندین زیرشبکه متعلق به یک شبکه اشتراکی، شیوه‌ای نادرست (bad practice) تلقی می‌شود. .sp اگرچه کاملاً اجباری نیست، اما در صورتی که قرار است از پایگاه داده برای ذخیره رزروهای میزبان استفاده شود، اکیداً توصیه می‌شود از مقادیر صریح \(dqid\(dq برای زیرشبکه‌ها استفاده کنید. اگر یک شناسه مشخص نشود، مقادیر آن به‌طور خودکار تولید می‌شوند؛ بدین معنا که Kea مقادیر صحیح افزایشی را با شروع از ۱ اختصاص می‌دهد. بنابراین، شناسه‌های تولیدشده به‌طور خودکار در صورت تغییر پیکربندی پایدار نخواهند ماند. .SS شناسه سرور در DHCPv4 (Server Identifier in DHCPv4) .sp پروتکل DHCPv4 از یک \(dqشناسه سرور\(dq (server identifier) استفاده می‌کند تا به کلاینت‌ها امکان تمایز بین چندین سرور موجود روی یک پیوند (link) یکسان را بدهد؛ این مقدار، یک نشانی IPv4 متعلق به سرور است. سرور، نشانی IPv4 مربوط به رابطی را انتخاب می‌کند که پیام از کلاینت (یا عامل رله) روی آن دریافت شده است. یک نمونه منفرد سرور در صورتی که پرس‌وجوها را روی چندین رابط دریافت کند، از چندین شناسه سرور استفاده خواهد کرد. .sp امکان بازنویسی (override) مقادیر پیش‌فرض شناسه سرور با مشخص کردن گزینه \fBdhcp\-server\-identifier\fP وجود دارد. پیکربندی این گزینه تنها در سطوح زیرشبکه، شبکه اشتراکی، کلاس کلاینت و سراسری پشتیبانی می‌شود. این گزینه نباید در سطح رزرو میزبان (host-reservation) مشخص شود. هنگام پیکربندی گزینه \fBdhcp\-server\-identifier\fP در سطح کلاس کلاینت، کلاس نباید پرچم \fBonly\-in\-additional\-list\fP را تنظیم کند؛ زیرا این کلاس پیش از آنکه سرور تعیین کند آیا پیام DHCP دریافت‌شده باید برای پردازش پذیرفته شود یا خیر، ارزیابی نمی‌شود. چنین کلاس‌هایی پس از انتخاب زیرشبکه ارزیابی می‌شوند. برای جزئیات بیشتر به بخش دسته‌بندی اضافی (Additional Classification) مراجعه کنید. .sp مثال زیر نحوه بازنویسی شناسه سرور را برای یک زیرشبکه نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdhcp\-server\-identifier\(dq, \(dqdata\(dq: \(dq10.2.5.76\(dq } ], ... } ], \&... } .EE .UNINDENT .UNINDENT .SS نحوه انتخاب زیرشبکه برای کلاینت توسط سرور DHCPv4 .sp سرور DHCPv4 بین کلاینت‌های با اتصال مستقیم، کلاینت‌هایی که برای تمدید اجاره (lease) تلاش می‌کنند، و کلاینت‌هایی که پیام‌های خود را از طریق رله‌ها (relays) می‌فرستند تفاوت قائل می‌شود. برای کلاینت‌های مستقیماً متصل‌شده، سرور پیکربندی رابطی را که پیام روی آن دریافت شده بررسی می‌کند و در صورتی که پیکربندی سرور با هیچ زیرشبکه پیکربندی‌شده‌ای مطابقت نداشته باشد، پیام دور ریخته می‌شود. .sp یک پارامتر اختیاری interface در تعریف زیرشبکه در دسترس است تا مشخص کند زیرشبکه موردنظر محلی است؛ یعنی مستقیماً از طریق رابط تعیین‌شده قابل دسترسی است. به عنوان مثال، سروری که در نظر دارد از طریق eth0 به یک زیرشبکه محلی خدمات دهد، می‌تواند به صورت زیر پیکربندی شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.100 \- 192.0.2.199\(dq } ], \(dqinterface\(dq: \(dqeth0\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp با فرض اینکه رابط سرور با نشانی IPv4 برابر 192.0.2.3 پیکربندی شده باشد، سرور پیام‌های دریافت‌شده از طریق این رابط از یک کلاینت با اتصال مستقیم را تنها در صورتی پردازش می‌کند که زیرشبکه‌ای پیکربندی شده باشد که این نشانی IPv4 به آن تعلق دارد، مانند 192.0.2.0/24. سرور از این زیرشبکه برای اختصاص یک نشانی IPv4 به کلاینت استفاده می‌کند. .sp قاعده بالا زمانی که کلاینت پیام خود را به‌صورت تک‌پخشی (unicast) ارسال می‌کند، یعنی در حال تلاش برای تمدید اجاره خود است، اعمال نمی‌شود؛ چنین پیامی از طریق هر رابطی پذیرفته می‌شود. کلاینتِ در حال تمدید، \fBciaddr\fP را روی نشانی IPv4 فعلی مورد استفاده قرار می‌دهد و سرور از این نشانی برای انتخاب زیرشبکه کلاینت استفاده می‌کند (به‌ویژه برای تمدید اجاره با استفاده از این نشانی). .sp اگر پیام از طریق رله منتقل شده باشد، از طریق هر رابطی پذیرفته می‌شود. مقدار \fBgiaddr\fP تنظیم‌شده توسط عامل رله برای انتخاب زیرشبکه کلاینت به کار می‌رود. .sp همچنین امکان تعیین یک نشانی IPv4 برای عامل رله در یک زیرشبکه مشخص وجود دارد. این مورد می‌تواند برای تطبیق بسته‌های ورودی به یک زیرشبکه در پیکربندی‌های غیرمعمول، مانند شبکه‌های اشتراکی، استفاده شود. برای جزئیات به بخش استفاده از یک عامل رله خاص برای یک زیرشبکه (Using a Specific Relay Agent for a Subnet) مراجعه کنید. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 سازوکار انتخاب زیرشبکه که در این بخش شرح داده شده، مبتنی بر این فرض است که از دسته‌بندی کلاینت (client classification) استفاده نمی‌شود. سازوکار دسته‌بندی، بسته به کلاس‌هایی که کلاینت به آن‌ها تعلق دارد، روش انتخاب زیرشبکه برای کلاینت را تغییر می‌دهد. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگامی که زیرشبکه انتخاب‌شده عضوی از یک شبکه اشتراکی است، کل شبکه اشتراکی انتخاب می‌شود. .UNINDENT .UNINDENT.SS استفاده از یک عامل رله مشخص برای یک زیرشبکه .sp یک رله باید رابطی متصل به پیوندی داشته باشد که کلاینت‌ها روی آن پیکربندی می‌شوند. به‌طور معمول، رله دارای یک آدرس IPv4 پیکربندی‌شده روی آن رابط است که متعلق به زیرشبکه‌ای است که کارساز از آن آدرس تخصیص می‌دهد. در حالت عادی، کارساز قادر است از آدرس IPv4 درج‌شده توسط رله (در فیلد \fBgiaddr\fP بستهٔ DHCPv4) برای انتخاب زیرشبکهٔ مناسب استفاده کند. .sp با این حال، همیشه این‌گونه نیست. در برخی استقرارهای نامعمول — اما معتبر — ممکن است آدرس رله با زیرشبکه مطابقت نداشته باشد. این موضوع معمولاً به این معنی است که بیش از یک زیرشبکه برای یک پیوند مشخص تخصیص یافته است. دو مورد از رایج‌ترین نمونه‌های این وضعیت، شماره‌گذاری مجدد شبکه به‌صورت طولانی‌مدت (که در آن هر دو فضای آدرس قدیمی و جدید همچنان مورد استفاده قرار می‌گیرند) و یک شبکهٔ کابلی هستند. در یک شبکهٔ کابلی، هم مودم‌های کابلی و هم دستگاه‌های پشت آن‌ها به‌صورت فیزیکی به همان پیوند متصل هستند، اما از آدرس‌دهی متفاوتی استفاده می‌کنند. در چنین حالتی، کارساز DHCPv4 برای انتخاب صحیح زیرشبکهٔ مناسب به اطلاعات بیشتری (آدرس IPv4 رله) نیاز دارد. .sp مثال زیر فرض می‌کند که زیرشبکه‌ای با نشانی 192.0.2.0/24 وجود دارد که از طریق رله‌ای با آدرس IPv4 برابر با 10.0.0.1 قابل دسترسی است. کارساز می‌تواند این زیرشبکه را برای تمام بسته‌های ورودی که از سوی رله‌ای با آدرسی در زیرشبکهٔ 192.0.2.0/24 می‌آیند انتخاب کند. همچنین این زیرشبکه را برای رله‌ای با آدرس 10.0.0.1 نیز انتخاب می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq } ], \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq10.0.0.1\(dq ] } } ] } } .EE .UNINDENT .UNINDENT .sp اگر \fBrelay\fP مشخص شده باشد، پارامتر \fBip\-addresses\fP درون آن اجباری است. پارامتر \fBip\-addresses\fP از تعیین فهرستی از آدرس‌ها پشتیبانی می‌کند. .SS تفکیک کلاینت‌های IPv4 در یک شبکه کابلی .sp در برخی موارد، ترکیب اطلاعات آدرس رله (معرفی‌شده در «استفاده از یک عامل رله مشخص برای یک زیرشبکه») با دسته‌بندی کلاینت (توضیح‌داده‌شده در Client Classification \%<#\:classify>) مفید است. یک نمونهٔ خاص در شبکهٔ کابلی است، جایی که مودم‌ها معمولاً آدرس‌هایی از زیرشبکه‌ای متفاوت نسبت به تمامی دستگاه‌های متصل پشت خود دریافت می‌کنند. .sp فرض کنید یک Cable Modem Termination System (CMTS) با یک CM MAC (یک پیوند فیزیکی که مودم‌ها به آن متصل هستند) وجود دارد. می‌خواهیم مودم‌ها آدرس‌هایی از زیرشبکهٔ 10.1.1.0/24 دریافت کنند، در حالی که همهٔ دستگاه‌های متصل پشت مودم‌ها باید آدرس‌هایی از زیرشبکهٔ 192.0.2.0/24 بگیرند. دستگاه CMTS که به عنوان رله عمل می‌کند از آدرس 10.1.1.1 استفاده می‌نماید. پیکربندی زیر می‌تواند پاسخگوی این وضعیت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.1.1.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.1.1.2 \- 10.1.1.20\(dq } ], \(dqclient\-classes\(dq: [ \(dqdocsis3.0\(dq ], \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq10.1.1.1\(dq ] } }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq } ], \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq10.1.1.1\(dq ] } } ], ... } .EE .UNINDENT .UNINDENT .SS آدرس‌های تکراری (پشتیبانی از DHCPDECLINE) .sp کارساز DHCPv4 با استخر مشخصی از آدرس‌ها پیکربندی شده است که انتظار می‌رود آن‌ها را به کلاینت‌های DHCPv4 واگذار کند. فرض بر این است که کارساز معتبر (authoritative) بوده و اختیار کامل بر روی آن آدرس‌ها دارد. با این حال، به دلایل مختلفی مانند پیکربندی نادرست یا پیاده‌سازی معیوب در کلاینت که آدرس خود را پس از پایان طول‌عمر معتبر همچنان حفظ می‌کند، ممکن است دستگاه‌های متصلی وجود داشته باشند که بدون تأیید یا آگاهی کارساز از آن آدرس‌ها استفاده کنند. .sp چنین رویداد نامطلوبی را کلاینت‌های قانونی می‌توانند (با استفاده از سازوکارهای ARP یا ICMP Echo Request) شناسایی کرده و با استفاده از پیام DHCPDECLINE به کارساز DHCPv4 گزارش دهند. کارساز یک بررسی اعتبارسنجی اولیه (sanity check) انجام می‌دهد (تا ببیند آیا کلاینتی که آدرس را رد می‌کند واقعاً قرار بوده از آن استفاده کند یا خیر) و سپس یک عملیات پاک‌سازی را اجرا می‌کند. هرگونه مدخل DNS مرتبط با آن آدرس حذف شده، رویداد ثبت می‌شود و قلاب‌ها اجرا می‌گردند. پس از پایان این کار، آدرس به عنوان ردشده (declined) علامت‌گذاری می‌شود (که نشان می‌دهد توسط موجودیتی ناشناس در حال استفاده است و در نتیجه برای تخصیص در دسترس نیست) و یک زمان تعلیق (probation time) برای آن تعیین می‌شود. مگر اینکه خلاف آن پیکربندی شده باشد، دورهٔ تعلیق ۲۴ ساعت به طول می‌انجامد؛ پس از این زمان، کارساز اجاره (lease) را بازیابی می‌کند (یعنی آن را دوباره به وضعیت در دسترس بازمی‌گرداند) و آدرس مجدداً برای تخصیص در دسترس خواهد بود. باید توجه داشت که اگر مشکل بنیادین دستگاهی که پیکربندی نادرستی دارد حل نشود، سناریوی آدرس تکراری تکرار خواهد شد. در صورت پیکربندی صحیح، این سازوکار امکان بازیابی خودکار از چنین رویدادی را بدون نیاز به هیچ‌گونه مداخلهٔ مدیر سیستم فراهم می‌کند. .sp برای پیکربندی دورهٔ تعلیق رد شدن با مقداری غیر از پیش‌فرض، می‌توان از نحو دستوری زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqdecline\-probation\-period\(dq: 3600, \(dqsubnet4\(dq: [ { ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp این پارامتر بر حسب ثانیه بیان می‌شود، بنابراین مثال بالا به کارساز دستور می‌دهد تا اجاره‌های ردشده را پس از یک ساعت بازیافت کند. .sp چندین آمار و نقطهٔ قلاب (hook point) مرتبط با روال رسیدگی به رد شدن وجود دارد. نقطهٔ قلاب \fBlease4_decline\fP پس از اینکه پیام ورودی DHCPDECLINE اعتبارسنجی شد و کارساز در شرف رد کردن اجاره است فعال می‌شود. آمار \fBdeclined\-addresses\fP پس از بازگشت قلاب افزایش می‌یابد (هم در نوع سراسری و هم در نوع ویژهٔ زیرشبکه). (برای جزئیات بیشتر دربارهٔ آمارهای DHCPv4 و نقاط قلاب Kea، بخش Statistics in the DHCPv4 Server و Hook Libraries \%<#\:hooks-libraries> را ببینید.) .sp به محض سپری شدن زمان تعلیق، اجارهٔ ردشده با استفاده از روال استاندارد آزادسازی اجاره‌های منقضی‌شده، همراه با چند مرحلهٔ اضافی بازیابی می‌شود. به‌ویژه، هر دو آمار \fBdeclined\-addresses\fP (سراسری و ویژهٔ زیرشبکه) کاهش می‌یابند. در همان زمان، آمارهای \fBreclaimed\-declined\-addresses\fP (باز هم در دو گونهٔ سراسری و ویژهٔ زیرشبکه) افزایش می‌یابند. .sp یادداشتی دربارهٔ آمارها: کارساز Kea پس از دریافت و پردازش موفق یک DHCPDECLINE، آمار \fBassigned\-addresses\fP را کاهش نمی‌دهد. اگرچه از نظر فنی یک آدرس ردشده دیگر تخصیص‌یافته محسوب نمی‌شود، اما کاربرد اصلی آمار \fBassigned\-addresses\fP نظارت بر بهره‌برداری از استخر است. بیشتر افراد فراموش می‌کنند که \fBdeclined\-addresses\fP را در محاسبه بگنجانند و صرفاً از نسبت \fBassigned\-addresses\fP/\fBtotal\-addresses\fP\& استفاده می‌کنند. این امر باعث ایجاد تورش و کمتر نشان دادن میزان بهره‌برداری از استخر خواهد شد. از آنجا که این موضوع پتانسیل ایجاد سردرگمی جدی دارد، ISC تصمیم گرفت که بلافاصله پس از دریافت DHCPDECLINE آمار \fBassigned\-addresses\fP را کاهش ندهد، بلکه این کار را بعداً زمانی انجام دهد که Kea آدرس را دوباره به استخر در دسترس بازمی‌گرداند..SS "آمارها در کارساز DHCPv4" .sp کارساز DHCPv4 از آمارهای زیر پشتیبانی می‌کند: .SS "آمارهای DHCPv4" .TS box center; l|l|l. T{ آماره T} T{ نوع داده T} T{ توضیحات T} _ T{ pkt4\-received T} T{ integer T} T{ تعداد بسته‌های DHCPv4 دریافت‌شده. شامل همه بسته‌ها می‌شود: معتبر، ساختگی، مخدوش، ردشده، و غیره. انتظار می‌رود این آماره به سرعت رشد کند. T} _ T{ pkt4\-discover\-received T} T{ integer T} T{ تعداد بسته‌های DHCPDISCOVER دریافت‌شده. انتظار می‌رود این آماره افزایش یابد؛ افزایش آن بدین معناست که کارخواه‌هایی که به‌تازگی راه‌اندازی شده‌اند فرایند پیکربندی خود را آغاز کرده و بسته‌های اولیه آن‌ها به کارساز Kea رسیده است. T} _ T{ pkt4\-offer\-received T} T{ integer T} T{ تعداد بسته‌های DHCPOFFER دریافت‌شده. انتظار می‌رود این آماره همواره صفر بماند، زیرا بسته‌های DHCPOFFER توسط کارساز ارسال می‌شوند و هرگز انتظار نمی‌رود کارساز آن‌ها را دریافت کند. مقدار غیرصفر نشان‌دهنده یک خطاست. یکی از علل محتمل می‌تواند یک عامل رله با رفتار نادرست باشد که پیام‌های DHCPOFFER را به اشتباه به سمت کارساز بازمی‌فرستد، به جای آنکه به کارخواه‌ها ارسال کند. T} _ T{ pkt4\-request\-received T} T{ integer T} T{ تعداد بسته‌های DHCPREQUEST دریافت‌شده. انتظار می‌رود این آماره افزایش یابد. رشد آن بدین معناست که کارخواه‌هایی که به‌تازگی راه‌اندازی شده‌اند، پاسخ کارساز (DHCPOFFER) را دریافت و پذیرفته‌اند و اکنون در حال درخواست یک نشانی (DHCPREQUEST) هستند. T} _ T{ pkt4\-ack\-received T} T{ integer T} T{ تعداد بسته‌های DHCPACK دریافت‌شده. انتظار می‌رود این آماره همیشه صفر بماند، چرا که بسته‌های DHCPACK توسط کارساز ارسال می‌شوند و هرگز انتظار نمی‌رود کارساز آن‌ها را دریافت کند. یک مقدار غیرصفر نشان‌دهنده خطا است. یکی از علل محتمل می‌تواند عامل رله‌ای باشد که رفتار نادرست داشته و پیام‌های DHCPACK را به جای کارخواه‌ها، به اشتباه به سمت کارساز بازمی‌گرداند. T} _ T{ pkt4\-nak\-received T} T{ integer T} T{ تعداد بسته‌های DHCPNAK دریافت‌شده. انتظار می‌رود این آماره همیشه صفر بماند، چرا که بسته‌های DHCPNAK توسط کارساز ارسال می‌شوند و هرگز انتظار نمی‌رود کارساز آن‌ها را دریافت کند. یک مقدار غیرصفر نشان‌دهنده خطا است. یکی از علل محتمل می‌تواند عامل رله‌ای باشد که رفتار نادرست داشته و پیام‌های DHCPNAK را به جای کارخواه‌ها، به اشتباه به سمت کارساز بازمی‌گرداند. T} _ T{ pkt4\-release\-received T} T{ integer T} T{ تعداد بسته‌های DHCPRELEASE دریافت‌شده. انتظار می‌رود این آماره افزایش یابد. رشد آن نشان می‌دهد کارخواه‌هایی که دارای نشانی بوده‌اند در حال خاموش شدن هستند یا از استفاده از نشانی‌هایشان دست می‌کشند. T} _ T{ pkt4\-decline\-received T} T{ integer T} T{ تعداد بسته‌های DHCPDECLINE دریافت‌شده. انتظار می‌رود این آماره نزدیک به صفر باقی بماند. افزایش آن نشان می‌دهد که یک کارخواه نشانی‌ای را اجاره کرده، اما متوجه شده است که آن نشانی در حال حاضر توسط یک دستگاه ناشناس در جای دیگری از شبکه در حال استفاده است. T} _ T{ pkt4\-inform\-received T} T{ integer T} T{ تعداد بسته‌های DHCPINFORM دریافت‌شده. انتظار می‌رود این آماره افزایش یابد. رشد آن بدان معناست که کارخواه‌هایی وجود دارند که یا نیازی به نشانی ندارند یا از قبل نشانی دارند و تنها علاقه‌مند به دریافت پارامترهای پیکربندی اضافی هستند. T} _ T{ pkt4\-lease\-query\-received T} T{ integer T} T{ تعداد بسته‌های DHCPLEASEQUERY دریافت‌شده توسط کتابخانه قلاب leasequery. انتظار می‌رود این آماره افزایش یابد. T} _ T{ pkt4\-unknown\-received T} T{ integer T} T{ تعداد بسته‌های دریافتی با نوع ناشناخته. مقدار غیرصفر این آماره نشان می‌دهد که کارساز بسته‌ای را دریافت کرده که قادر به تشخیص آن نبوده است؛ یا با نوعی پشتیبانی‌نشده یا احتمالاً بدقواره (بدون گزینه message\-type). T} _ T{ pkt4\-sent T} T{ integer T} T{ تعداد بسته‌های DHCPv4 ارسال‌شده. انتظار می‌رود این آماره با هر بار ارسال یک بسته توسط کارساز، رشد کند. به‌طور کلی، این مقدار باید تقریباً با \fBpkt4\-received\fP همخوانی داشته باشد، زیرا بیشتر بسته‌های ورودی باعث پاسخ دادن کارساز می‌شوند. استثناهایی وجود دارد (مانند DHCPRELEASE)، بنابراین اگر کمتر از pkt4\-received بود جای نگرانی نیست. T} _ T{ pkt4\-offer\-sent T} T{ integer T} T{ تعداد بسته‌های DHCPOFFER ارسال‌شده. انتظار می‌رود این آماره در بیشتر موارد پس از پردازش یک DHCPDISCOVER افزایش یابد. مواردی نامتداول اما معتبر وجود دارد که بسته‌های ورودی DHCPDISCOVER دور انداخته می‌شوند، اما به‌طور کلی انتظار می‌رود این آماره به \fBpkt4\-discover\-received\fP نزدیک باشد\&. T} _ T{ pkt4\-ack\-sent T} T{ integer T} T{ تعداد بسته‌های DHCPACK ارسال‌شده. انتظار می‌رود این آماره در بیشتر موارد پس از پردازش یک DHCPREQUEST افزایش یابد؛ مواردی وجود دارد که به جای آن DHCPNAK ارسال می‌شود. به‌طور کلی، مجموع \fBpkt4\-ack\-sent\fP و \fBpkt4\-nak\-sent\fP باید نزدیک به \fBpkt4\-request\-received\fP باشد\&. T} _ T{ pkt4\-nak\-sent T} T{ integer T} T{ تعداد بسته‌های DHCPNAK ارسال‌شده. انتظار می‌رود این آماره زمانی که کارساز تصمیم می‌گیرد نشانی درخواست‌شده توسط کارخواه را واگذار نکند، افزایش یابد. به‌طور کلی، مجموع \fBpkt4\-ack\-sent\fP و \fBpkt4\-nak\-sent\fP باید نزدیک به \fBpkt4\-request\-received\fP باشد\&. T} _ T{ pkt4\-lease\-query\-response\-unassigned\-sent T} T{ integer T} T{ تعداد بسته‌های DHCPLEASEUNASSIGNED ارسال‌شده توسط کتابخانه قلاب leasequery. انتظار می‌رود این آماره افزایش یابد. T} _ T{ pkt4\-lease\-query\-response\-unknown\-sent T} T{ integer T} T{ تعداد بسته‌های DHCPLEASEUNKNOWN ارسال‌شده توسط کتابخانه قلاب leasequery. انتظار می‌رود این آماره افزایش یابد. T} _ T{ pkt4\-lease\-query\-response\-active\-sent T} T{ integer T} T{ تعداد بسته‌های DHCPLEASEACTIVE ارسال‌شده توسط کتابخانه قلاب leasequery. انتظار می‌رود این آماره افزایش یابد. T} _ T{ pkt4\-service\-disabled T} T{ integer T} T{ تعداد بسته‌های ورودی که هنگام غیرفعال بودن سرویس DHCP دور انداخته شدند. T} _ T{ pkt4\-parse\-failed T} T{ integer T} T{ تعداد بسته‌های ورودی که تجزیه آن‌ها ناموفق بود. مقدار غیرصفر این آماره نشان می‌دهد که کارساز بسته‌ای بدقواره یا ناقص دریافت کرده است. این ممکن است نشان‌دهنده مشکلات در شبکه، کارخواه‌های معیوب، یا وجود باگ در کارساز باشد. T} _ T{ pkt4\-queue\-full T} T{ integer T} T{ تعداد بسته‌های ورودی که به دلیل پر بودن صفی که قرار بود در آن قرار گیرند، دور انداخته شدند. T} _ T{ pkt4\-duplicate T} T{ integer T} T{ تعداد بسته‌های ورودی که به دلیل تکراری شناخته شدن دور انداخته شدند. T} _ T{ pkt4\-rfc\-violation T} T{ integer T} T{ تعداد بسته‌های ورودی که در راستای پیروی از مشخصات پروتکل دور انداخته شدند. T} _ T{ pkt4\-admin\-filtered T} T{ integer T} T{ تعداد بسته‌های ورودی که به دلیل پیکربندی کارساز برای این کار دور انداخته شدند، مثلاً با دسته‌بندی پرس‌وجو در کلاس \fBDROP\fP\&. T} _ T{ pkt4\-not\-for\-us T} T{ integer T} T{ تعداد بسته‌های ورودی که دور انداخته شدند زیرا باید توسط کارساز دیگری رسیدگی می‌شدند. T} _ T{ pkt4\-processing\-failed T} T{ integer T} T{ تعداد بسته‌های ورودی که دور انداخته شدند به این دلیل که خطایی غیرمنتظره در حین پردازش رخ داد. T} _ T{ pkt4\-limit\-exceeded T} T{ integer T} T{ تعداد بسته‌های ورودی که توسط کتابخانه قلاب \fBlimits\fP دور انداخته شدند. T} _ T{ pkt4\-receive\-drop T} T{ integer T} T{ تعداد بسته‌های ورودی که دور انداخته شدند. دلیل دقیق دور انداختن بسته‌ها در گزارش‌ها ثبت می‌شود، اما رایج‌ترین دلایل ممکن است دریافت نوع بسته غیرقابل‌قبول، ممنوع بودن پاسخ مستقیم، عدم تطابق شناسه کارساز ارسال‌شده توسط کارخواه با شناسه کارساز، یا بروز خطایی غیرمنتظره در حین پردازش باشد. T} _ T{ subnet[id].total\-addresses T} T{ integer T} T{ تعداد کل نشانی‌های موجود برای مدیریت DHCPv4 برای یک زیرشبکه مشخص؛ به بیان دیگر، این تعداد کل نشانی‌ها در همه استخرهای پیکربندی‌شده است. این آماره تنها هنگام به‌روزرسانی پیکربندی تغییر می‌کند. نشانی‌هایی که ممکن است به دلیل رزرو میزبان رزرو شده باشند را در نظر نمی‌گیرد. شناسه \fIid\fP شناسه زیرشبکه مربوط به یک زیرشبکه داده‌شده است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود و در طول رویداد پیکربندی مجدد، بازنشانی می‌شود. T} _ T{ subnet[id].pool[pid].total\-addresses T} T{ integer T} T{ تعداد کل نشانی‌های موجود برای مدیریت DHCPv4 برای یک استخر زیرشبکه مشخص؛ به بیان دیگر، این تعداد کل نشانی‌ها در استخر زیرشبکه پیکربندی‌شده است. این آماره تنها هنگام به‌روزرسانی پیکربندی تغییر می‌کند. نشانی‌هایی که ممکن است به دلیل رزرو میزبان رزرو شده باشند را در نظر نمی‌گیرد. شناسه \fIid\fP شناسه زیرشبکه مربوط به یک زیرشبکه مشخص است. مقدار \fIpid\fP شناسه استخر مربوط به یک استخر مشخص است. این آماره برای هر استخر زیرشبکه به طور جداگانه ارائه شده و در زمان رویداد پیکربندی مجدد، بازنشانی می‌شود. T} _ T{ assigned\-addresses T} T{ integer T} T{ تعداد نشانی‌های تخصیص‌یافته. با هر بار اختصاص یک اجاره جدید (در نتیجه دریافت پیام DHCPREQUEST) افزایش یافته و با هر بار آزادسازی یک اجاره (دریافت پیام DHCPRELEASE) یا انقضای آن کاهش می‌یابد، و در طول رویداد پیکربندی مجدد بازنشانی می‌شود. T} _ T{ cumulative\-assigned\-addresses T} T{ integer T} T{ تعداد تجمعی نشانی‌هایی که از زمان راه‌اندازی کارساز تخصیص داده شده‌اند. با هر بار تخصیص یک نشانی افزایش می‌یابد و در رویداد پیکربندی مجدد بازنشانی نمی‌شود. T} _ T{ subnet[id].cumulative\-assigned\-addresses T} T{ integer T} T{ تعداد تجمعی نشانی‌های تخصیص‌یافته در یک زیرشبکه مشخص. با هر بار اختصاص یک اجاره جدید (در نتیجه دریافت پیام DHCPREQUEST) افزایش می‌یابد و هرگز کاهش نمی‌یابد. شناسه \fIid\fP شناسه زیرشبکه است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود و در طول رویداد پیکربندی مجدد، بازنشانی می‌شود. T} _ T{ subnet[id].pool[pid].cumulative\-assigned\-addresses T} T{ integer T} T{ تعداد تجمعی نشانی‌های تخصیص‌یافته در یک استخر زیرشبکه مشخص. با هر بار اختصاص یک اجاره جدید (در نتیجه دریافت پیام DHCPREQUEST) افزایش می‌یابد و هرگز کاهش نمی‌یابد. شناسه \fIid\fP شناسه زیرشبکه است. مقدار \fIpid\fP شناسه استخر مربوط به استخر است. این آماره برای هر استخر زیرشبکه به صورت جداگانه ارائه می‌شود و در طول رویداد پیکربندی مجدد، بازنشانی می‌شود. T} _ T{ subnet[id].assigned\-addresses T} T{ integer T} T{ تعداد نشانی‌های تخصیص‌یافته در یک زیرشبکه مشخص. با هر بار اختصاص اجاره جدید (در نتیجه دریافت پیام DHCPREQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام DHCPRELEASE) یا انقضای آن کاهش می‌یابد. شناسه \fIid\fP شناسه زیرشبکه است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود و در طول رویداد پیکربندی مجدد، بازنشانی می‌شود. T} _ T{ subnet[id].pool[pid].assigned\-addresses T} T{ integer T} T{ تعداد نشانی‌های تخصیص‌یافته در یک استخر زیرشبکه مشخص. با هر بار اختصاص اجاره جدید (در نتیجه دریافت پیام DHCPREQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام DHCPRELEASE) یا انقضای آن کاهش می‌یابد. شناسه \fIid\fP شناسه زیرشبکه است. شناسه \fIpid\fP شناسه استخر مربوطه است. این آماره برای هر استخر زیرشبکه به طور جداگانه ارائه می‌شود و در رویداد پیکربندی مجدد، بازنشانی می‌گردد. T} _ T{ reclaimed\-leases T} T{ integer T} T{ تعداد اجاره‌های منقضی‌شده‌ای که از زمان راه‌اندازی کارساز بازپس گرفته شده‌اند. با هر بار بازپس‌گیری یک اجاره منقضی‌شده افزایش یافته و هرگز کاهش نمی‌یابد. این آماره می‌تواند به عنوان یک شاخص بلندمدت از تعداد واقعی اجاره‌های بازپس‌گرفته‌شده استفاده شود. این یک آماره سراسری است که همه زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].reclaimed\-leases T} T{ integer T} T{ تعداد اجاره‌های منقضی‌شده مرتبط با یک زیرشبکه مشخص که از زمان راه‌اندازی کارساز بازپس گرفته شده‌اند. با هر بار بازپس‌گیری یک اجاره منقضی‌شده افزایش می‌یابد. شناسه \fIid\fP شناسه زیرشبکه برای یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به طور جداگانه ارائه می‌شود. T} _ T{ subnet[id].pool[pid].reclaimed\-leases T} T{ integer T} T{ تعداد اجاره‌های منقضی‌شده مرتبط با یک استخر زیرشبکه مشخص که از زمان راه‌اندازی کارساز بازپس گرفته شده‌اند. با هر بار بازپس‌گیری یک اجاره منقضی‌شده افزایش می‌یابد. شناسه \fIid\fP شناسه زیرشبکه یک زیرشبکه مشخص است. شناسه \fIpid\fP شناسه استخر مربوطه است. این آماره برای هر استخر زیرشبکه به طور جداگانه ارائه می‌شود. T} _ T{ declined\-addresses T} T{ integer T} T{ تعداد نشانی‌های IPv4 که در حال حاضر رد شده‌اند (declined)؛ شمارشی از تعداد اجاره‌هایی که اکنون در دسترس نیستند. به محض بازیابی یک اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این آماره غیرصفر باشد یا افزایش یابد، مدیر شبکه باید بررسی کند که آیا دستگاهی با رفتار نادرست در شبکه وجود دارد یا خیر. این یک آماره سراسری است که همه زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].declined\-addresses T} T{ integer T} T{ تعداد نشانی‌های IPv4 که در حال حاضر در یک زیرشبکه مشخص رد شده‌اند؛ شمارشی از تعداد اجاره‌هایی که در حال حاضر در دسترس نیستند. به محض بازیابی یک اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این آماره غیرصفر باشد یا افزایش یابد، مدیر شبکه باید بررسی کند که آیا دستگاهی با رفتار نادرست در شبکه وجود دارد یا خیر. شناسه \fIid\fP شناسه زیرشبکه مربوط به یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود. T} _ T{ subnet[id].pool[pid].declined\-addresses T} T{ integer T} T{ تعداد نشانی‌های IPv4 که در حال حاضر در یک استخر زیرشبکه مشخص رد شده‌اند؛ شمارشی از تعداد اجاره‌هایی که در حال حاضر در دسترس نیستند. به محض بازیابی یک اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این آماره غیرصفر باشد یا افزایش یابد، مدیر شبکه باید بررسی کند که آیا دستگاهی با رفتار نادرست در شبکه وجود دارد یا خیر. شناسه \fIid\fP شناسه زیرشبکه یک زیرشبکه مشخص است. شناسه \fIpid\fP شناسه استخر مربوطه است. این آماره برای هر استخر زیرشبکه به صورت جداگانه ارائه می‌شود. T} _ T{ reclaimed\-declined\-addresses T} T{ integer T} T{ تعداد نشانی‌های IPv4 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف \fBdeclined\-addresses\fP، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان یک شاخص بلندمدت استفاده کرد که نشان می‌دهد چه تعداد رد معتبر واقعی پردازش شده و نشانی آن‌ها بازیابی شده است. این یک آماره سراسری است که همه زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].reclaimed\-declined\-addresses T} T{ integer T} T{ تعداد نشانی‌های IPv4 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف \fBdeclined\-addresses\fP، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان یک شاخص بلندمدت استفاده کرد که نشان می‌دهد چه تعداد رد معتبر واقعی پردازش شده و نشانی آن‌ها بازیابی شده است. شناسه \fIid\fP شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود. T} _ T{ subnet[id].pool[pid].reclaimed\-declined\-addresses T} T{ integer T} T{ تعداد نشانی‌های IPv4 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف \fBdeclined\-addresses\fP، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان یک شاخص بلندمدت استفاده کرد که نشان می‌دهد چه تعداد رد معتبر واقعی پردازش شده و نشانی آن‌ها بازیابی شده است. شناسه \fIid\fP شناسه زیرشبکه یک زیرشبکه مشخص است. مقدار \fIpid\fP شناسه استخر مربوطه است. این آماره برای هر استخر زیرشبکه به صورت جداگانه ارائه می‌شود. T} _ T{ pkt4\-lease\-query\-received T} T{ integer T} T{ تعداد بسته‌های DHCPLEASEQUERY برای IPv4 که دریافت شده‌اند. (تنها در صورتی وجود دارد که کتابخانه قلاب Leasequery بارگیری شده باشد.) T} _ T{ pkt4\-lease\-query\-response\-unknown\-sent T} T{ integer T} T{ تعداد پاسخ‌های DHCPLEASEUNKNOWN برای IPv4 که ارسال شده‌اند. (تنها در صورتی وجود دارد که کتابخانه قلاب Leasequery بارگیری شده باشد.) T} _ T{ pkt4\-lease\-query\-response\-unassigned\-sent T} T{ integer T} T{ تعداد پاسخ‌های DHCPLEASEUNASSIGNED برای IPv4 که ارسال شده‌اند. (تنها در صورتی وجود دارد که کتابخانه قلاب Leasequery بارگیری شده باشد.) T} _ T{ pkt4\-lease\-query\-response\-active\-sent T} T{ integer T} T{ تعداد پاسخ‌های DHCPLEASEACTIVE برای IPv4 که ارسال شده‌اند. (تنها در صورتی وجود دارد که کتابخانه قلاب Leasequery بارگیری شده باشد.) T} _ T{ v4\-allocation\-fail T} T{ integer T} T{ تعداد کل شکست‌های تخصیص نشانی برای یک کارخواه خاص. این شامل تعداد تلاش‌های تخصیص اجاره است که کارساز پیش از انصراف انجام داده، در صورتی که نتوانسته باشد از هیچ‌یک از استخرهای نشانی استفاده کند. این یک آماره سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].v4\-allocation\-fail T} T{ integer T} T{ تعداد کل شکست‌های تخصیص نشانی برای یک کارخواه خاص. این شامل تعداد تلاش‌های تخصیص اجاره است که کارساز پیش از انصراف انجام داده، در صورتی که نتوانسته باشد از هیچ‌یک از استخرهای نشانی استفاده کند. شناسه \fIid\fP شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود. T} _ T{ v4\-allocation\-fail\-shared\-network T} T{ integer T} T{ تعداد شکست‌های تخصیص نشانی برای یک کارخواه خاص متصل به یک شبکه مشترک (shared network). این یک آماره سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].v4\-allocation\-fail\-shared\-network T} T{ integer T} T{ تعداد شکست‌های تخصیص نشانی برای یک کارخواه خاص متصل به یک شبکه مشترک. شناسه \fIid\fP شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود. T} _ T{ v4\-allocation\-fail\-subnet T} T{ integer T} T{ تعداد شکست‌های تخصیص نشانی برای یک کارخواه خاص متصل به زیرشبکه‌ای که به یک شبکه مشترک تعلق ندارد. این یک آماره سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].v4\-allocation\-fail\-subnet T} T{ integer T} T{ تعداد شکست‌های تخصیص نشانی برای یک کارخواه خاص متصل به زیرشبکه‌ای که به یک شبکه مشترک تعلق ندارد. شناسه \fIid\fP شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود. T} _ T{ v4\-allocation\-fail\-no\-pools T} T{ integer T} T{ تعداد شکست‌های تخصیص نشانی به این دلیل که کارساز نتوانست از هیچ‌یک از استخرهای پیکربندی‌شده برای یک کارخواه خاص استفاده کند. همچنین ممکن است تمام زیرشبکه‌هایی که کارساز تلاش کرده از آن‌ها نشانی اختصاص دهد، فاقد استخر نشانی باشند. در این حالت، اگر اپراتور انتظار دارد به برخی کارخواه‌ها نشانی پویا تخصیص یابد، این وضعیت باید یک پیکربندی نادرست تلقی شود. این یک آماره سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].v4\-allocation\-fail\-no\-pools T} T{ integer T} T{ تعداد شکست‌های تخصیص نشانی به این دلیل که کارساز نتوانست از هیچ‌یک از استخرهای پیکربندی‌شده برای یک کارخواه خاص استفاده کند. همچنین ممکن است تمام زیرشبکه‌هایی که کارساز تلاش کرده از آن‌ها نشانی اختصاص دهد، فاقد استخر نشانی باشند. در این حالت، اگر اپراتور انتظار دارد به برخی کارخواه‌ها نشانی پویا تخصیص یابد، این وضعیت باید یک پیکربندی نادرست تلقی شود. شناسه \fIid\fP شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود. T} _ T{ v4\-allocation\-fail\-classes T} T{ integer T} T{ تعداد شکست‌های تخصیص نشانی هنگامی که بسته کارخواه متعلق به یک یا چند کلاس است. دلایل متعددی ممکن است برای عدم اختصاص اجاره وجود داشته باشد: به عنوان مثال، اگر همه استخرها نیاز داشته باشند که بسته‌ها به کلاس‌های خاصی تعلق داشته باشند و بسته ورودی به هیچ‌کدام تعلق نداشته باشد. حالت دیگری که این اطلاعات می‌تواند مفید باشد، نشان دادن این است که ظرفیت نشانی‌های استخر رزروشده برای یک کلاس خاص به پایان رسیده است. این یک آماره سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].v4\-allocation\-fail\-classes T} T{ integer T} T{ تعداد شکست‌های تخصیص نشانی هنگامی که بسته کارخواه متعلق به یک یا چند کلاس است. دلایل متعددی ممکن است برای عدم اختصاص اجاره وجود داشته باشد: به عنوان مثال، اگر همه استخرها نیاز داشته باشند که بسته‌ها به کلاس‌های خاصی تعلق داشته باشند و بسته ورودی به هیچ‌کدام تعلق نداشته باشد. حالت دیگری که این اطلاعات می‌تواند مفید باشد، نشان دادن این است که ظرفیت نشانی‌های استخر رزروشده برای یک کلاس خاص به پایان رسیده است. شناسه \fIid\fP شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود. T} _ T{ v4\-lease\-reuses T} T{ integer T} T{ تعداد دفعاتی که به عنوان بخشی از قابلیت کَش کردن اجاره (lease caching)، مقدار CLTT یک اجاره IPv4 در حافظه افزایش یافته و زمان انقضای آن در حافظه پایدار دست‌نخورده باقی مانده است. به این عمل «استفاده مجدد از اجاره» (lease reuse) گفته می‌شود. این آماره سراسری است. T} _ T{ subnet[id].v4\-lease\-reuses T} T{ integer T} T{ تعداد دفعاتی که به عنوان بخشی از قابلیت کَش کردن اجاره (lease caching)، مقدار CLTT یک اجاره IPv4 در حافظه افزایش یافته و زمان انقضای آن در حافظه پایدار دست‌نخورده باقی مانده است. به این عمل «استفاده مجدد از اجاره» گفته می‌شود. این آماره بر پایه هر زیرشبکه است. شناسه \fIid\fP شناسه زیرشبکه یک زیرشبکه مشخص است. T} _ T{ v4\-reservation\-conflicts T} T{ integer T} T{ تعداد تداخل‌های تخصیص رزرو میزبان که در تمامی زیرشبکه‌ها رخ داده است. هنگامی که یک کارخواه DHCP Discover ارسال می‌کند و با یک رزرو میزبان تطبیق داده می‌شود که پیش‌تر به کارخواه دیگری اجاره داده شده است، این شمارنده ۱ واحد افزایش می‌یابد. T} _ T{ subnet[id].v4\-reservation\-conflicts T} T{ integer T} T{ تعداد تداخل‌های تخصیص رزرو میزبان که در یک زیرشبکه مشخص رخ داده است. هنگامی که یک کارخواه DHCP Discover ارسال می‌کند و با یک رزرو میزبان تطبیق داده می‌شود که پیش‌تر به کارخواه دیگری اجاره داده شده است، این شمارنده ۱ واحد افزایش می‌یابد. T} .TE .sp بسته‌های ورودی دور انداخته‌شده می‌توانند در \fBpkt4\-receive\-drop\fP و یک شمارنده دوم با شرح علت دور انداختن شمرده شوند: .INDENT 0.0.IP \(bu 2 \fBpkt4\-service\-disabled\fP \- سرویس DHCP غیرفعال است .IP \(bu 2 \fBpkt4\-parse\-failed\fP \- تجزیه بسته با یک خطای مهلک مواجه شد .IP \(bu 2 \fBpkt4\-queue\-full\fP \- بسته‌ای که قرار بود در صف قرار گیرد، اما صف پر بود .IP \(bu 2 \fBpkt4\-duplicate\fP \- تکرار بسته‌ای که در حال پردازش است .IP \(bu 2 \fBpkt4\-rfc\-violation\fP \- نقض RFC (یعنی مشخصات پروتکل دستور به دور انداختن آنها می‌دهد) .IP \(bu 2 \fBpkt4\-admin\-filtered\fP \- توسط مدیر فیلتر شده است .IP \(bu 2 \fBpkt4\-not\-for\-us\fP \- باید توسط سرور دیگری مدیریت شود .IP \(bu 2 \fBpkt4\-processing\-failed\fP \- دریافت یک خطای غیرمنتظره در حین پردازش .IP \(bu 2 \fBpkt4\-limit\-exceeded\fP \- توسط کتابخانه هوکِ محدودیت‌ها (libdhcp_limits.so: Limits to Manage Lease Allocation and Packet Processing \%<#\:hooks-limits>) دور انداخته شد .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 شناسه استخر (pool ID) را می‌توان با تنظیم صریح پارامتر \fBpool\-id\fP در نگاشت پارامترهای استخر، روی هر استخر پیکربندی کرد. در صورت عدم پیکربندی، مقدار پیش‌فرض \fBpool\-id\fP برابر 0 خواهد بود. آمار مربوط به شناسه استخر 0 به تمام آمار همه استخرهایی اشاره دارد که \fBpool\-id\fP آنها پیکربندی نشده است\&. شناسه استخر نیازی نیست در درون زیرشبکه یا در میان زیرشبکه‌ها یکتا باشد. آمار مربوط به یک شناسه استخر مشخص در یک زیرشبکه، با سایر آمار تمام استخرهای دیگری که همان شناسه استخر را در آن زیرشبکه دارند ترکیب می‌شود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این بخش آمار ویژه DHCPv4 را شرح می‌دهد. برای بررسی اجمالی و نحوه استفاده از آمار، به Statistics \%<#\:stats>\& مراجعه کنید. .UNINDENT .UNINDENT .sp سرور DHCPv4 دو پارامتر سراسری را برای کنترل محدودیت‌های پیش‌فرض نمونه‌های آماری ارائه می‌دهد: .INDENT 0.0 .IP \(bu 2 \fBstatistic\-default\-sample\-count\fP \- حداکثر تعداد پیش‌فرض نمونه‌هایی را که باید نگهداری شوند تعیین می‌کند. مقدار ویژه 0 نشان می‌دهد که باید از حداکثر طول عمر پیش‌فرض استفاده شود. .IP \(bu 2 \fBstatistic\-default\-sample\-age\fP \- حداکثر طول عمر پیش‌فرض (به ثانیه) نمونه‌هایی که باید نگهداری شوند را تعیین می‌کند. .UNINDENT .sp به عنوان مثال، برای کاهش بار سربار نگهداری آمار، حداکثر تعداد نمونه پیش‌فرض را روی 1 تنظیم کنید تا فقط یک نمونه نگهداری شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqstatistic\-default\-sample\-count\(dq: 1, \(dqsubnet4\(dq: [ { ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp آمارها را می‌توان به‌صورت دوره‌ای بازیابی کرد تا بینش بیشتری نسبت به عملکرد Kea به دست آید. یکی از ابزارهایی که از این قابلیت بهره می‌برد ISC Stork است. برای جزئیات بیشتر به Monitoring Kea With Stork \%<#\:stork> مراجعه کنید. .SS "رابط مدیریتی سرور DHCPv4 (Management API for the DHCPv4 Server)" .sp رابط مدیریتی (management API) امکان صدور دستورهای مدیریتی خاص، مانند بازیابی آمار، بازپیکربندی، یا خاموش کردن را فراهم می‌کند. برای جزئیات بیشتر، به Management API \%<#\:ctrl-channel>\& مراجعه کنید. به‌طور پیش‌فرض هیچ سوکتی باز نیست؛ برای هدایت Kea به باز کردن یک سوکت، می‌توان از ورودی زیر در فایل پیکربندی استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqcontrol\-sockets\(dq: [ { \(dqsocket\-type\(dq: \(dqunix\(dq, \(dqsocket\-name\(dq: \(dq/path/to/the/unix/socket\(dq } ], \(dqsubnet4\(dq: [ { ... }, ... ], ... } .EE .UNINDENT .UNINDENT .SS "سوکت کنترلی یونیکس (UNIX Control Socket)" .sp تا نسخه 2.7.2 سرور Kea، تنها نوع کانال ارتباطی پشتیبانی‌شده، سوکت جریانی UNIX با \fBsocket\-type\fP تنظیم‌شده روی \fBunix\fP و \fBsocket\-name\fP به مسیر فایل سوکت UNIX/LOCAL بود. .sp طول مسیر مشخص‌شده توسط پارامتر \fBsocket\-name\fP با حداکثر طول نام سوکت UNIX در سیستم‌عامل مدیر سیستم، یعنی اندازه فیلد \fBsun_path\fP در ساختار \fBsockaddr_un\fP منهای ۱ محدود شده است. این مقدار در سیستم‌های عامل مختلف، بین ۹۱ تا ۱۰۷ نویسه متغیر است. مقادیر معمول در Linux برابر ۱۰۷ و در FreeBSD برابر ۱۰۳ است. .sp برنامه Kea تنها از یک سوکت کنترلی \fBunix\fP در فهرست \(dqcontrol\-sockets\(dq پشتیبانی می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از Kea 2.7.9 به بعد، سوکت‌های کنترلی فقط ممکن است در دایرکتوری تعیین‌شده در حین کامپایل به عنوان \fB\(dq[kea\-install\-dir]/var/run/kea\(dq\fP قرار گیرند، که همچنین باید دارای مجوزهای دسترسی \fB0750\fP باشد. این مسیر ممکن است در زمان راه‌اندازی با تنظیم متغیر محیطی \fBKEA_CONTROL_SOCKET_DIR\fP روی مسیر دلخواه بازنویسی شود. اگر مسیری غیر از این مقدار در \fBsocket\-name\fP استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی خودداری می‌کند یا اگر از قبل در حال اجرا باشد، یک خطای غیرقابل بازیابی را ثبت می‌کند. برای سهولت در استفاده، کافی است بخش مسیر را از \fBsocket\-name\fP حذف کنید\&. .UNINDENT .UNINDENT .sp ارتباط از طریق کانال کنترلی با استفاده از ساختارهای JSON انجام می‌شود. برای جزئیات بیشتر به بخش Control Channel در راهنمای توسعه‌دهندگان Kea Developer\(aqs Guide \% مراجعه کنید. .sp سرور DHCPv4 از دستورهای عملیاتی زیر پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBbuild\-report\fP \%<#\:std-isccmd-build-report> .IP \(bu 2 \fBconfig\-get\fP \%<#\:std-isccmd-config-get> .IP \(bu 2 \fBconfig\-hash\-get\fP \%<#\:std-isccmd-config-hash-get> .IP \(bu 2 \fBconfig\-reload\fP \%<#\:std-isccmd-config-reload> .IP \(bu 2 \fBconfig\-set\fP \%<#\:std-isccmd-config-set> .IP \(bu 2 \fBconfig\-test\fP \%<#\:std-isccmd-config-test> .IP \(bu 2 \fBconfig\-write\fP \%<#\:std-isccmd-config-write> .IP \(bu 2 \fBdhcp\-disable\fP \%<#\:std-isccmd-dhcp-disable> .IP \(bu 2 \fBdhcp\-enable\fP \%<#\:std-isccmd-dhcp-enable> .IP \(bu 2 \fBinterface\-add\fP \%<#\:std-isccmd-interface-add> .IP \(bu 2 \fBinterface\-list\fP \%<#\:std-isccmd-interface-list> .IP \(bu 2 \fBinterface\-redetect\fP \%<#\:std-isccmd-interface-redetect> .IP \(bu 2 \fBleases\-reclaim\fP \%<#\:std-isccmd-leases-reclaim> .IP \(bu 2 \fBlist\-commands\fP \%<#\:std-isccmd-list-commands> .IP \(bu 2 \fBshutdown\fP \%<#\:std-isccmd-shutdown> .IP \(bu 2 \fBstatus\-get\fP \%<#\:std-isccmd-status-get> .IP \(bu 2 \fBversion\-get\fP \%<#\:std-isccmd-version-get> .UNINDENT .sp همان‌طور که در Commands Supported by Both the DHCPv4 and DHCPv6 Servers \%<#\:commands-common>\& شرح داده شده است. علاوه بر این، از دستورهای زیر که مرتبط با آمار هستند نیز پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBstatistic\-get\fP \%<#\:std-isccmd-statistic-get> .IP \(bu 2 \fBstatistic\-reset\fP \%<#\:std-isccmd-statistic-reset> .IP \(bu 2 \fBstatistic\-remove\fP \%<#\:std-isccmd-statistic-remove> .IP \(bu 2 \fBstatistic\-get\fP \%<#\:std-isccmd-statistic-get>\-all .IP \(bu 2 \fBstatistic\-reset\fP \%<#\:std-isccmd-statistic-reset>\-all .IP \(bu 2 \fBstatistic\-remove\fP \%<#\:std-isccmd-statistic-remove>\-all .IP \(bu 2 \fBstatistic\-sample\-age\-set\fP \%<#\:std-isccmd-statistic-sample-age-set> .IP \(bu 2 \fBstatistic\-sample\-age\-set\fP \%<#\:std-isccmd-statistic-sample-age-set>\-all .IP \(bu 2 \fBstatistic\-sample\-count\-set\fP \%<#\:std-isccmd-statistic-sample-count-set> .IP \(bu 2 \fBstatistic\-sample\-count\-set\fP \%<#\:std-isccmd-statistic-sample-count-set>\-all .UNINDENT .sp همان‌طور که در Commands for Manipulating Statistics \%<#\:command-stats>\& شرح داده شده است..SS سوکت کنترل HTTP/HTTPS (HTTP/HTTPS Control Socket) .sp مقدار \fBsocket\-type\fP باید \fBhttp\fP یا \fBhttps\fP باشد (هنگامی که نوع \fBhttps\fP باشد، TLS الزامی است). پارامترهای \fBsocket\-address\fP (پیش‌فرض \fB127.0.0.1\fP) و \fBsocket\-port\fP (پیش‌فرض 8000) نشانی IP و درگاهی را مشخص می‌کنند که سرویس HTTP به آن مقید (bound) خواهد شد. .sp از Kea 2.7.5 به بعد، پارامتر \fBhttp\-headers\fP فهرستی از سرآیندهای اضافی HTTP را برای افزودن به پاسخ‌های HTTP مشخص می‌کند. .sp پارامترهای \fBtrust\-anchor\fP، \fBcert\-file\fP، \fBkey\-file\fP و \fBcert\-required\fP راه‌اندازی TLS را برای HTTP، یعنی HTTPS، مشخص می‌کنند. اگر این پارامترها مشخص نشوند، HTTP استفاده می‌شود. پشتیبانی از TLS/HTTPS در Kea در TLS/HTTPS Support \%<#\:tls>\& شرح داده شده است. .sp احراز هویت پایه HTTP (Basic HTTP authentication) در برابر استفاده‌های غیرمجاز از سرور توسط کاربران محلی محافظت می‌کند. برای محافظت در برابر مهاجمان از راه دور، HTTPS و reverse proxy امنیت قوی‌تری را فراهم می‌سازند. .sp احراز هویت در بلوک \fBauthentication\fP همراه با پارامتر اجباری \fBtype\fP که نوع احراز هویت را انتخاب می‌کند، شرح داده شده است. در حال حاضر تنها احراز هویت پایه HTTP (نوع basic) پشتیبانی می‌شود. .sp پارامتر احراز هویت \fBrealm\fP (پیش‌فرض \fBkea\-dhcpv4\-server\fP) برای پیام‌های خطا در شرایطی که احراز هویت پایه HTTP الزامی است اما کلاینت مجاز شناخته نشده، استفاده می‌شود. .sp هنگامی که فهرست احراز هویت \fBclients\fP پیکربندی شده و خالی نباشد، احراز هویت پایه HTTP الزامی است. هر عنصر از فهرست یک شناسه کاربر و یک گذرواژه را مشخص می‌کند. شناسه کاربر اجباری است، نباید خالی باشد، و نباید حاوی نویسه دونقطه (:) باشد. گذرواژه اختیاری است؛ هنگامی که مشخص نشود، یک گذرواژه خالی استفاده می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 شناسه کاربر و گذرواژه احراز هویت پایه HTTP با کدگذاری UTF\-8 کدگذاری می‌شوند، اما نحو JSON فعلی Kea تنها از زیرمجموعه یونیکد Latin\-1 (یعنی 0x00..0xff) پشتیبانی می‌کند. .UNINDENT .UNINDENT .sp برای جلوگیری از افشای شناسه کاربر و/یا گذرواژه مرتبط، این مقادیر را می‌توان از فایل‌ها خواند. نحو پیکربندی با موارد زیر گسترش یافته است: .INDENT 0.0 .IP \(bu 2 پارامتر احراز هویت \fBdirectory\fP، که بخش مشترک مسیرهای فایل را مدیریت می‌کند. مقدار پیش‌فرض یک رشته خالی است. .IP \(bu 2 پارامتر کلاینت \fBpassword\-file\fP، که در کنار پارامتر \fBdirectory\fP، مسیر فایلی را مشخص می‌کند که می‌تواند حاوی گذرواژه باشد، یا در صورتی که شناسه کاربر ارائه نشده باشد، کل عبارت محرمانه احراز هویت پایه HTTP را در بر گیرد. .IP \(bu 2 پارامتر کلاینت \fBuser\-file\fP، که همراه با پارامتر \fBdirectory\fP، مسیر فایلی را مشخص می‌کند که شناسه کاربر می‌تواند از آن خوانده شود. .UNINDENT .sp از نسخه Kea\-2.7.6 به بعد، Kea از چندین اتصال HTTP/HTTPS پشتیبانی می‌کند. هر دو نشانی IPv4 و IPv6 می‌توانند استفاده شوند. سرور در صورت تغییر نوع سوکت از HTTP به HTTPS یا از HTTPS به HTTP با استفاده از همان نشانی و درگاه، خطا صادر خواهد کرد. این عمل مجاز نیست زیرا ممکن است موجب بروز یک مشکل امنیتی ناشی از اشتباه تصادفی کاربر شود. هنگام استفاده از دستور \(dqconfig\-set\(dq برای تغییر از HTTP به HTTPS یا از HTTPS به HTTP، باید یک نشانی یا درگاه متفاوت مشخص شود. همین موضوع هنگام تغییر فایل پیکربندی و سپس اجرای دستور \(dqconfig\-reload\(dq نیز صدق می‌کند. .sp هنگامی که از فایل‌ها استفاده می‌شود، آن‌ها در زمان بارگذاری پیکربندی خوانده می‌شوند تا خطاهای پیکربندی در سریع‌ترین زمان ممکن شناسایی شوند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqcontrol\-sockets\(dq: [ { \(dqsocket\-type\(dq: \(dqhttps\(dq, \(dqsocket\-address\(dq: \(dq10.20.30.40\(dq, \(dqsocket\-port\(dq: 8004, \(dqhttp\-headers\(dq: [ { \(dqname\(dq: \(dqStrict\-Transport\-Security\(dq, \(dqvalue\(dq: \(dqmax\-age=31536000\(dq } ], \(dqtrust\-anchor\(dq: \(dq/path/to/the/ca\-cert.pem\(dq, \(dqcert\-file\(dq: \(dq/path/to/the/agent\-cert.pem\(dq, \(dqkey\-file\(dq: \(dq/path/to/the/agent\-key.pem\(dq, \(dqcert\-required\(dq: true, \(dqauthentication\(dq: { \(dqtype\(dq: \(dqbasic\(dq, \(dqrealm\(dq: \(dqkea\-dhcpv4\-server\(dq, \(dqclients\(dq: [ { \(dquser\(dq: \(dqadmin\(dq, \(dqpassword\(dq: \(dq1234\(dq } ] } }, { \(dqsocket\-type\(dq: \(dqhttp\(dq, \(dqsocket\-address\(dq: \(dq2010:30:40::50\(dq, \(dqsocket\-port\(dq: 8004 } ], \(dqsubnet4\(dq: [ { ... }, ... ], ... } .EE .UNINDENT .UNINDENT .SS زمینه‌های کاربر در IPv4 (User Contexts in IPv4) .sp ‏Kea امکان بارگذاری کتابخانه‌های قلاب (hook libraries) را فراهم می‌کند که گاهی می‌توانند از پارامترهای اضافی بهره‌مند شوند. اگر چنین پارامتری مختص به کل کتابخانه باشد، معمولاً به عنوان پارامتری برای کتابخانه قلاب تعریف می‌شود. با این حال، گاهی اوقات لازم است پارامترهایی مشخص شوند که برای هر استخر (pool) متفاوت باشند. .sp برای پیش‌زمینه تکمیلی در مورد ایده user\-context، بخش Comments and User Context \%<#\:user-context> را ببینید. برای بررسی از دیدگاه قلاب‌ها، بخش User Contexts in Hooks \%<#\:user-context-hooks> را مشاهده کنید. .sp زمینه‌های کاربر (User contexts) را می‌توان در محدوده سراسری (global scope)؛ در سطح shared\-network، subnet، pool، client\-class، option\-data یا تعاریف (definition)؛ و از طریق رزرو میزبان (host reservation) مشخص کرد. یکی دیگر از ویژگی‌های مفید، قابلیت ذخیره نظرات یا توضیحات است. .sp بیایید حالت فرضی دستگاه‌هایی را در نظر بگیریم که چراغ‌های LED رنگی دارند. بسته به مکان قرارگیری، آن‌ها باید با نور قرمز، آبی یا سبز روشن شوند. نوشتن یک کتابخانه قلاب که مقادیر مشخصی را، احتمالاً به عنوان یک گزینه فروشنده (vendor option)، ارسال کند کار آسانی خواهد بود. با این حال، سرور باید راهی برای تعیین آن مقدار برای هر pool داشته باشد. این نیاز توسط زمینه‌های کاربر (user contexts) برطرف می‌شود. در اصل، هر داده کاربری می‌تواند در زمینه کاربر مشخص شود تا زمانی که یک نگاشت معتبر JSON باشد. برای مثال، مورد دستگاه‌های LED یادشده می‌تواند به روش زیر پیکربندی شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq, # This is pool specific user context \(dquser\-context\(dq: { \(dqcolor\(dq: \(dqred\(dq } } ], # This is a subnet\-specific user context. Any type # of information can be entered here as long as it is valid JSON. \(dquser\-context\(dq: { \(dqcomment\(dq: \(dqnetwork on the second floor\(dq, \(dqlast\-modified\(dq: \(dq2017\-09\-04 13:32\(dq, \(dqdescription\(dq: \(dqyou can put anything you like here\(dq, \(dqphones\(dq: [ \(dqx1234\(dq, \(dqx2345\(dq ], \(dqdevices\-registered\(dq: 42, \(dqbilling\(dq: false } } ] } .EE .UNINDENT .UNINDENT .sp ‏Kea اطلاعات user\-context را تفسیر یا استفاده نمی‌کند؛ صرفاً آن را ذخیره می‌کند و در دسترس کتابخانه‌های قلاب قرار می‌دهد. استخراج این اطلاعات و استفاده از آن به عهده هر کتابخانه قلاب است. تجزیه‌کننده یک مدخل \fBcomment\fP را به یک زمینه کاربر همراه با آن مدخل ترجمه می‌کند که امکان ضمیمه کردن یک نظر را در داخل خود پیکربندی فراهم می‌سازد..SS استانداردهای پشتیبانی‌شده DHCP (Supported DHCP Standards) .sp استانداردهای زیر در حال حاضر در Kea پشتیبانی می‌شوند: .INDENT 0.0 .IP \(bu 2 \fIBOOTP Vendor Information Extensions\fP، RFC 1497 \%: این مورد نیازمند بارگذاری قلاب (hook) متن‌باز BOOTP است. برای جزئیات libdhcp_bootp.so: Support for BOOTP Clients \%<#\:hooks-bootp> را ببینید. .IP \(bu 2 \fIDynamic Host Configuration Protocol\fP، RFC 1531 \%: این RFC منسوخ شده و با RFC 1541 جایگزین شده است که آن هم به نوبه خود با RFC 2131 جایگزین شد. Kea از هر سه RFC پشتیبانی می‌کند. .IP \(bu 2 \fIClarifications and Extensions for the Bootstrap Protocol\fP، RFC 1532 \%: این RFC خطای نگارشی دارد و به‌سرعت توسط RFC 1542 جایگزین شد. Kea از هر دوی آن‌ها پشتیبانی می‌کند. .IP \(bu 2 \fIDHCP Options and BOOTP Vendor Extensions\fP، RFC 1533 \%: این RFC منسوخ شده و با RFC 2132 جایگزین شد. با این وجود، Kea از گزینه‌های تعریف‌شده در آن پشتیبانی می‌کند. .IP \(bu 2 \fIDynamic Host Configuration Protocol\fP، RFC 1541 \%: این RFC منسوخ شده و با RFC 2131 جایگزین شد. Kea از هر دو پشتیبانی می‌کند. .IP \(bu 2 \fIClarifications and Extensions for the Bootstrap Protocol\fP، RFC 1542 \%: این RFC پشتیبانی می‌شود. .IP \(bu 2 \fIDynamic Host Configuration Protocol\fP، RFC 2131 \%: پیام‌های پشتیبانی‌شده عبارتند از DHCPDISCOVER (1)، DHCPOFFER (2)، DHCPREQUEST (3)، DHCPRELEASE (7)، DHCPINFORM (8)، DHCPACK (5) و DHCPNAK (6). .IP \(bu 2 \fIDHCP Options and BOOTP Vendor Extensions\fP، RFC 2132 \%: گزینه‌های پشتیبانی‌شده عبارتند از PAD (0)، END (255)، Message Type (53)، DHCP Server Identifier (54)، Domain Name (15)، DNS Servers (6)، IP Address Lease Time (51)، Subnet Mask (1) و Routers (3). .IP \(bu 2 \fIDHCP Options for Novell Directory Services\fP، RFC 2241 \%: هر سه گزینه پشتیبانی می‌شوند. .IP \(bu 2 \fIManagement of IP numbers by peg\-dhcp\fP، RFC 2322 \%: این RFC پشتیبانی می‌شود، اگرچه برای استقرار کامل به سخت‌افزار اضافی نیاز است. .IP \(bu 2 \fIDHCP Option for The Open Group\(aqs User Authentication Protocol\fP، RFC 2485 \%: این گزینه پشتیبانی می‌شود. .IP \(bu 2 \fIDHCP Option to Disable Stateless Auto\-Configuration in IPv4 Clients\fP، RFC 2563 \%: این گزینه پشتیبانی می‌شود. .IP \(bu 2 \fIDHCP Options for Service Location Protocol\fP، RFC 2610 \%: هر دو گزینه پشتیبانی می‌شوند. .IP \(bu 2 \fIThe Name Service Search Option for DHCP\fP، RFC 2937 \%: این گزینه پشتیبانی می‌شود. .IP \(bu 2 \fIThe User Class Option for DHCP\fP، RFC 3004 \%: کلاس کاربر پشتیبانی می‌شود و می‌تواند در هر عبارتی استفاده شود. ساختار گزینه تجزیه نمی‌شود و باید با استفاده از hex به آن ارجاع داده شود. .IP \(bu 2 \fIThe IPv4 Subnet Selection Option for DHCP\fP، RFC 3011 \%: گزینه subnet\-selection پشتیبانی می‌شود؛ در صورت دریافت در یک بسته، در فرایند انتخاب زیرشبکه استفاده می‌گردد. .IP \(bu 2 \fIDHCP Relay Agent Information Option\fP، RFC 3046 \%: گزینه‌های Relay Agent Information، Circuit ID و Remote ID پشتیبانی می‌شوند. .IP \(bu 2 \fIThe DOCSIS (Data\-Over\-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub\-option\fP، RFC 3256 \%: زیرگزینه DOCSIS پشتیبانی می‌شود و می‌تواند در هر عبارتی استفاده شود. .IP \(bu 2 \fIEncoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)\fP، RFC 3396 \%: کارساز Kea می‌تواند هم گزینه‌های طولانی را دریافت و هم ارسال کند. گزینه‌های طولانی قابل پیکربندی هستند و اگر طول بار داده (payload) بیشتر از ۲۵۵ بایت باشد، Kea آن‌ها را به صورت نمونه‌های جداگانه ارسال می‌کند. .IP \(bu 2 \fIDynamic Host Configuration Protocol (DHCP) Domain Search Option\fP، RFC 3397 \%: این گزینه پشتیبانی می‌شود. .IP \(bu 2 \fIThe Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4\fP، RFC 3442 \%: این گزینه پشتیبانی می‌شود. .IP \(bu 2 \fIDynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration\fP، RFC 3495 \%: این گزینه و زیرگزینه‌های ۱، ۲، ۴، ۵، ۶، ۷ و ۸ آن پشتیبانی می‌شوند. برای جزئیات به بخش CableLabs Client Conf Suboptions مراجعه کنید. .IP \(bu 2 \fILink Selection sub\-option for the Relay Agent Option\fP، RFC 3527 \%: زیرگزینه link selection پشتیبانی می‌شود. .IP \(bu 2 \fIPacketCable Security Ticket Control Sub\-Option for the DHCP CableLabs Client Configuration (CCC) Option\fP، RFC 3594 \%: زیرگزینه Security Ticket Control پشتیبانی می‌شود. .IP \(bu 2 \fIKey Distribution Center (KDC) Server Address Sub\-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option\fP، RFC 3634 \%: زیرگزینه نشانی IP مربوط به Key Distribution Center پشتیبانی می‌شود. .IP \(bu 2 \fIUnused Dynamic Host Configuration Protocol (DHCP) Option Codes\fP، RFC 3679 \%: Kea از هیچ‌یک از گزینه‌های قدیمی که توسط این RFC منسوخ شده‌اند پشتیبانی نمی‌کند. .IP \(bu 2 \fIVendor\-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4\fP، RFC 3925 \%: گزینه‌های Vendor\-Identifying Vendor Class و Vendor\-Identifying Vendor\-Specific Information پشتیبانی می‌شوند. .IP \(bu 2 \fIReclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options\fP، RFC 3942 \%: Kea از گزینه‌هایی با کدهای بزرگتر از ۱۲۷ پشتیبانی می‌کند. .IP \(bu 2 \fISubscriber\-ID Suboption for the DHCP Relay Agent Option\fP، RFC 3993 \%: گزینه Subscriber\-ID پشتیبانی می‌شود. .IP \(bu 2 \fIDynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers\fP، RFC 4280 \%: گزینه‌های DHCPv4 پشتیبانی می‌شوند. .IP \(bu 2 \fINode\-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)\fP، RFC 4361 \%: شناسه DUID در DHCPv4 پشتیبانی می‌شود. .IP \(bu 2 \fIDynamic Host Configuration Protocol (DHCP) Leasequery\fP، RFC 4388 \%: قابلیت‌های کارساز پشتیبانی می‌شود. این مورد نیازمند قلاب leasequery است. برای جزئیات libdhcp_lease_query.so: Leasequery Support \%<#\:hooks-lease-query> را ببینید. .IP \(bu 2 \fIDynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)\fP، RFC 4578 \%: هر سه گزینه تعریف‌شده پشتیبانی می‌شوند. .IP \(bu 2 \fIA DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)\fP، RFC 4701 \%: کارساز DHCPv4 از رکوردهای DHCID پشتیبانی می‌کند. کارساز DHCP\-DDNS باید در حال اجرا باشد تا رکوردهای DHCID را اضافه، به‌روزرسانی و/یا حذف کند. .IP \(bu 2 \fIThe Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option\fP، RFC 4702 \%: کارساز Kea قادر به مدیریت گزینه Client FQDN است. همچنین می‌تواند از مؤلفه \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> برای آغاز عملیات مناسب به‌روزرسانی DNS استفاده کند. .IP \(bu 2 \fIResolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients\fP، RFC 4703 \%: کارساز DHCPv6 از یک کارساز DHCP\-DDNS برای حل تعارض‌ها استفاده می‌کند. .IP \(bu 2 \fITimezone Options for DHCP\fP: RFC 4833 \%: هر دو گزینه DHCPv4 پشتیبانی می‌شوند. .IP \(bu 2 \fIThe Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption\fP: RFC 5010 \%: زیرگزینه Relay Agent Flags برای Kea مفهوم است و می‌تواند در عبارات استفاده شود. .IP \(bu 2 \fIServer Identifier Override sub\-option for the Relay Agent Option\fP، RFC 5107 \%: زیرگزینه server identifier override پشتیبانی می‌شود. پیاده‌سازی طبق RFC کامل نیست، زیرا کارساز RAI را ذخیره نمی‌کند، اما این کارکرد موارد کاربرد مورد انتظار را پوشش می‌دهد. .IP \(bu 2 \fIDHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents\fP: RFC 5192 \%: گزینه PANA پشتیبانی می‌شود. .IP \(bu 2 \fIDiscovering Location\-to\-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)\fP: RFC 5223 \%: گزینه LOST پشتیبانی می‌شود. .IP \(bu 2 \fIControl And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option\fP: RFC 5417 \%: گزینه CAPWAP برای IPv4 پشتیبانی می‌شود. .IP \(bu 2 \fIDHCPv4 Lease Query by Relay Agent Remote ID\fP، RFC 6148 \%: درخواست leasequery بر اساس remote\-id پشتیبانی می‌شود. این مورد نیازمند قلاب leasequery است. برای جزئیات libdhcp_lease_query.so: Leasequery Support \%<#\:hooks-lease-query> را ببینید. .IP \(bu 2 \fIClient Identifier Option in DHCP Server Replies\fP، RFC 6842 \%: کارساز به صورت پیش‌فرض گزینه \fBclient\-id\fP را بازمی‌گرداند. این قابلیت می‌تواند غیرفعال شود. برای جزئیات Echoing Client\-ID (RFC 6842) را ببینید. .IP \(bu 2 \fIThe DHCPv4 Relay Agent Identifier Sub\-Option\fP، RFC 6925 \%: گزینه relay\-id پشتیبانی می‌شود و می‌تواند در تمام ویژگی‌هایی که از عبارات استفاده می‌کنند (دسته‌بندی کلاینت، رزروهای flex\-id و غیره) به کار رود. .IP \(bu 2 \fIDHCPv4 Bulk Leasequery\fP، RFC 6926 \%: کارکرد کارساز (اتصال‌های TCP، انواع پرس‌وجو جدید، پاسخ‌های چندگانه و غیره) پشتیبانی می‌شود. این مورد نیازمند قلاب leasequery است. برای جزئیات libdhcp_lease_query.so: Leasequery Support \%<#\:hooks-lease-query> را ببینید. .IP \(bu 2 \fIGeneralized UDP Source Port for the DHCP Relay Agent Option\fP، RFC 8357 \%: کارساز Kea زیرگزینه Relay Agent Information Source Port را در پیام دریافت‌شده پردازش می‌کند، درگاه UDP را به خاطر می‌سپارد، و پاسخی را با استفاده از این درگاه UDP برای همان عامل رله بازمی‌فرستد. .IP \(bu 2 \fICaptive\-Portal Identification in DHCP and Router Advertisements (RAs)\fP، RFC 8910 \%: کارساز Kea می‌تواند هر دو نسخه v4 و v6 گزینه‌های پرتال محدودکننده (captive portal) را پیکربندی کند. .IP \(bu 2 \fIIPv6\-Only Preferred Option for DHCPv4\fP، RFC 8925 \%: کارساز Kea قادر است استخرها و زیرشبکه‌های خود را به عنوان IPv6\-Only Preferred تعیین کرده و گزینه \fBv6\-only\-preferred\fP را برای کلاینت‌هایی که آن را درخواست کرده‌اند بازپس فرستد. .IP \(bu 2 \fIDHCP and Router Advertisement Options for the Discovery of Network\-designated Resolvers (DNR)\fP، RFC 9463 \%\&. کارساز Kea از گزینه DNR پشتیبانی می‌کند. .UNINDENT.SS تخطی‌های شناخته‌شده از RFC .sp در اصل، Kea در پی آن است که یک پیاده‌سازی مرجع باشد و هدف آن پیاده‌سازی ۱۰۰٪ استانداردهای RFC است. با این حال، در برخی موارد جنبه‌های عملی وجود دارند که مانع از پایبندی کامل Kea به متن تمام اسناد RFC می‌شوند. .INDENT 0.0 .IP \(bu 2 سند RFC 2131 \%، صفحهٔ ۳۰، بیان می‌کند که اگر بستهٔ ورودی DHCPREQUEST فاقد گزینهٔ \(dqrequested IP address\(dq باشد و \fBciaddr\fP نیز تنظیم نشده باشد، کارساز باید با NAK پاسخ دهد. با این حال، کلاینت‌های معیوبی وجود دارند که همواره یک DHCPREQUEST را بدون مشخص کردن این گزینه‌ها ارسال می‌کنند. در این حالت، Kea بستهٔ DHCPREQUEST را می‌پذیرد، نشانی‌ای را اختصاص می‌دهد، و با یک ACK پاسخ می‌دهد. .IP \(bu 2 سند RFC 2131 \%، جدول ۵، بیان می‌کند که پیام‌های از نوع DHCPDECLINE یا DHCPRELEASE باید گزینهٔ شناسهٔ کارساز (server identifier) را تنظیم کرده باشند و در صورت نبود این گزینه باید رها (drop) شوند. با این حال، ISC DHCP این موضوع را اعمال نمی‌کند، که احتمالاً تلاشی در جهت سازگاری با کلاینت‌های معیوب است، و تیم Kea نیز تصمیم گرفت همین رویه را دنبال کند. .UNINDENT .SS محدودیت‌های کارساز DHCPv4 .sp این موارد محدودیت‌های شناخته‌شدهٔ کنونی نرم‌افزار کارساز Kea DHCPv4 هستند. بیشتر آن‌ها بازتابی از مرحلهٔ فعلی توسعه هستند و باید به جای محدودیت‌های واقعی، به عنوان «هنوز پیاده‌سازی‌نشده» تلقی شوند. با این وجود، برخی از آن‌ها از پیامدهای تصمیمات اتخاذشده در طراحی هستند. این موارد به‌روشنی به همین صورت مشخص شده‌اند. .INDENT 0.0 .IP \(bu 2 در خانوادهٔ سیستم‌های Linux و BSD، پیام‌های DHCP از طریق سوکت‌های خام (با استفاده از LPF و BPF) ارسال و دریافت می‌شوند و تمام سرآیندهای بسته (از جمله سرآیندهای لایهٔ پیوند داده، IP و UDP) به جای هستهٔ سیستم، توسط Kea ایجاد و تجزیه می‌شوند. در حال حاضر، Kea فقط می‌تواند سرآیندهای لایهٔ پیوند داده با قالبی مطابق با استاندارد IEEE 802.3 را تجزیه کند، و این قالب سرآیند لایهٔ پیوند داده را برای تمامی رابط‌ها فرض می‌گیرد. بنابراین، Kea روی رابط‌هایی که از قالب‌های سرآیند لایهٔ پیوند دادهٔ متفاوتی استفاده می‌کنند (مانند Infiniband) کار نمی‌کند. .UNINDENT .SS مثال‌های کارساز DHCPv4 در Kea .sp مجموعه‌ای از مثال‌های ساده و کاربردی برای مؤلفهٔ DHCPv4 در Kea همراه با فایل‌های منبع، در دایرکتوری \fBdoc/examples/kea4\fP در دسترس است. .SS پسانهٔ پیکربندی در DHCPv4 .sp در بخش پسانهٔ پیکربندی Kea \%<#\:config-backend>، قابلیت پسانهٔ پیکربندی (CB)، کاربردپذیری و محدودیت‌های آن را شرح داده‌ایم. این بخش بر استفاده از CB به همراه کارساز Kea DHCPv4 متمرکز است. این قسمت پارامترهای پشتیبانی‌شده را فهرست می‌کند، محدودیت‌ها را توضیح می‌دهد و مثال‌هایی از پیکربندی کارساز DHCPv4 برای بهره‌برداری از CB ارائه می‌دهد. لطفاً برای استفادهٔ مخصوص DHCPv6 از CB، به بخش متناظر پسانهٔ پیکربندی در DHCPv6 \%<#\:dhcp6-cb> نیز مراجعه کنید. .SS پارامترهای پشتیبانی‌شده .sp هدف نهایی CB این است که به عنوان یک مخزن مرکزی پیکربندی برای یک یا چند کارساز Kea متصل به یک پایگاه‌داده عمل کند. در نسخه‌های کنونیِ پشتیبانی‌شدهٔ Kea، تنها زیرمجموعه‌ای از پارامترهای کارساز DHCPv4 را می‌توان در پایگاه‌داده پیکربندی کرد. سایر پارامترها در صورت نیاز باید در فایل پیکربندی JSON مشخص شوند. .sp تمامی پارامترهای پشتیبانی‌شده را می‌توان از طریق \fBlibdhcp_cb_cmds.so\fP \%<#\:std-ischooklib-libdhcp_cb_cmds\:.so>\& پیکربندی کرد. قاعدهٔ کلی بر این است که پارامترهای سراسری نردبانی با استفاده از \fBremote\-global\-parameter4\-set\fP \%<#\:std-isccmd-remote-global-parameter4-set> تنظیم می‌شوند؛ پارامترهای مختص شبکهٔ مشترک با استفاده از \fBremote\-network4\-set\fP \%<#\:std-isccmd-remote-network4-set> تعیین می‌گردند؛ و پارامترهای سطح زیرشبکه و سطح استخر با استفاده از \fBremote\-subnet4\-set\fP \%<#\:std-isccmd-remote-subnet4-set>\& تنظیم می‌شوند. هرگاه استثنایی بر این قاعدهٔ کلی وجود داشته باشد، در جدول برجسته شده است. پارامترهای سراسری غیرنردبانی دارای دستورات اختصاصی هستند؛ برای مثال، گزینه‌های سراسری DHCPv4 (\fBoption\-data\fP) با استفاده از \fBremote\-option4\-global\-set\fP \%<#\:std-isccmd-remote-option4-global-set>\& تغییر می‌یابند. کلاس‌های کلاینت به همراه تعاریف گزینه‌ها و گزینه‌های DHCPv4 مختص به آن کلاس، با استفاده از دستور \fBremote\-class4\-set\fP \%<#\:std-isccmd-remote-class4-set> پیکربندی می‌شوند. .sp بخش اشتراک‌گذاری پیکربندی و برچسب‌های کارساز \%<#\:cb-sharing> مفهوم عناصر پیکربندی قابل‌اشتراک و غیرقابل‌اشتراک و محدودیت‌های به‌اشتراک‌گذاری آن‌ها میان چند کارساز را توضیح می‌دهد. در پیکربندی DHCP (چه DHCPv4 و چه DHCPv6)، عناصر پیکربندی قابل‌اشتراک شامل زیرشبکه‌ها و شبکه‌های مشترک هستند. بنابراین، می‌توان آن‌ها را به‌طور صریح با چند برچسب کارساز مرتبط کرد. پارامترهای سراسری، تعاریف گزینه‌ها و گزینه‌های سراسری غیرقابل‌اشتراک هستند و تنها می‌توانند با یک برچسب کارساز مرتبط باشند. این قاعده شامل عناصر پیکربندیِ مرتبط با کارسازهای \fBall\fP نمی‌شود. هر عنصر پیکربندی مرتبط با کارسازهای \fBall\fP (با استفاده از کلمهٔ کلیدی \fBall\fP به عنوان برچسب کارساز) توسط تمام کارسازهایی که به پایگاه‌دادهٔ پیکربندی متصل می‌شوند، استفاده می‌شود. .sp جدول زیر پارامترهای مختص DHCPv4 پشتیبانی‌شده توسط پسانهٔ پیکربندی را به همراه سطح سلسله‌مراتبی که در حال حاضر در آن پشتیبانی می‌شود، فهرست می‌کند. .SS فهرست پارامترهای DHCPv4 پشتیبانی‌شده توسط پسانهٔ پیکربندی .TS box center; l|l|l|l|l|l. T{ پارامتر T} T{ سراسری T} T{ کلاس کلاینت T} T{ شبکهٔ مشترک T} T{ زیرشبکه T} T{ استخر T} _ T{ 4o6\-interface T} T{ n/a T} T{ n/a T} T{ n/a T} T{ بله T} T{ n/a T} _ T{ 4o6\-interface\-id T} T{ n/a T} T{ n/a T} T{ n/a T} T{ بله T} T{ n/a T} _ T{ 4o6\-subnet T} T{ n/a T} T{ n/a T} T{ n/a T} T{ بله T} T{ n/a T} _ T{ allocator T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ boot\-file\-name T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ n/a T} _ T{ cache\-max\-age T} T{ بله T} T{ n/a T} T{ خیر T} T{ خیر T} T{ n/a T} _ T{ cache\-threshold T} T{ بله T} T{ n/a T} T{ خیر T} T{ خیر T} T{ n/a T} _ T{ calculate\-tee\-times T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ client\-class T} T{ n/a T} T{ n/a T} T{ بله T} T{ بله T} T{ بله T} _ T{ ddns\-send\-update T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ ddns\-override\-no\-update T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ ddns\-override\-client\-update T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ ddns\-replace\-client\-name T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ ddns\-generated\-prefix T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ ddns\-qualifying\-suffix T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ decline\-probation\-period T} T{ بله T} T{ n/a T} T{ n/a T} T{ n/a T} T{ n/a T} _ T{ dhcp4o6\-port T} T{ بله T} T{ n/a T} T{ n/a T} T{ n/a T} T{ n/a T} _ T{ echo\-client\-id T} T{ بله T} T{ n/a T} T{ n/a T} T{ n/a T} T{ n/a T} _ T{ hostname\-char\-set T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ hostname\-char\-replacement T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ interface T} T{ n/a T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ match\-client\-id T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ min\-valid\-lifetime T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ n/a T} _ T{ max\-valid\-lifetime T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ n/a T} _ T{ next\-server T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ n/a T} _ T{ option\-data T} T{ بله (از طریق remote\-option4\-global\-set) T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} _ T{ option\-def T} T{ بله (از طریق remote\-option\-def4\-set) T} T{ بله T} T{ n/a T} T{ n/a T} T{ n/a T} _ T{ rebind\-timer T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ renew\-timer T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ server\-hostname T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ n/a T} _ T{ valid\-lifetime T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ n/a T} _ T{ relay T} T{ n/a T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ require\-client\-classes T} T{ خیر T} T{ n/a T} T{ بله T} T{ بله T} T{ بله T} _ T{ evaluate\-additional\-classes T} T{ خیر T} T{ n/a T} T{ بله T} T{ بله T} T{ بله T} _ T{ reservations\-global T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ reservations\-in\-subnet T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ reservations\-out\-of\-pool T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ t1\-percent T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} _ T{ t2\-percent T} T{ بله T} T{ n/a T} T{ بله T} T{ بله T} T{ n/a T} .TE .INDENT 0.0.IP \(bu 2 \fByes\fP \- نشان می‌دهد که این پارامتر در سطح مشخص‌شده از سلسله‌مراتب پشتیبانی می‌شود و از طریق بک‌اند پیکربندی قابل تنظیم است. .IP \(bu 2 \fBno\fP \- نشان می‌دهد که یک پارامتر در سطح مشخص‌شده از سلسله‌مراتب پشتیبانی می‌شود، اما از طریق بک‌اند پیکربندی قابل تنظیم نیست. .IP \(bu 2 \fBn/a\fP \- نشان می‌دهد که پارامتر مربوطه در سطح مشخص‌شده از سلسله‌مراتب قابل اعمال نیست یا سرور از آن پارامتر در آن سطح پشتیبانی نمی‌کند. .UNINDENT .sp برخی از پارامترهای اسکالر موجود در نگاشت‌های سراسری سطح بالا توسط بک‌اند پیکربندی پشتیبانی می‌شوند. .SS فهرست پارامترهای نگاشت DHCPv4 پشتیبانی‌شده توسط بک‌اند پیکربندی .TS box center; l|l|l. T{ نام پارامتر (قالب نام‌گذاری مسطح) T} T{ نگاشت سراسری T} T{ نام پارامتر T} _ T{ compatibility.ignore\-dhcp\-server\-identifier T} T{ compatibility T} T{ ignore\-dhcp\-server\-identifier T} _ T{ compatibility.ignore\-rai\-link\-selection T} T{ compatibility T} T{ ignore\-rai\-link\-selection T} _ T{ compatibility.lenient\-option\-parsing T} T{ compatibility T} T{ lenient\-option\-parsing T} _ T{ compatibility.exclude\-first\-last\-24 T} T{ compatibility T} T{ exclude\-first\-last\-24 T} _ T{ dhcp\-ddns.enable\-updates T} T{ dhcp\-ddns T} T{ enable\-updates T} _ T{ dhcp\-ddns.max\-queue\-size T} T{ dhcp\-ddns T} T{ max\-queue\-size T} _ T{ dhcp\-ddns.ncr\-format T} T{ dhcp\-ddns T} T{ ncr\-format T} _ T{ dhcp\-ddns.ncr\-protocol T} T{ dhcp\-ddns T} T{ ncr\-protocol T} _ T{ dhcp\-ddns.sender\-ip T} T{ dhcp\-ddns T} T{ sender\-ip T} _ T{ dhcp\-ddns.sender\-port T} T{ dhcp\-ddns T} T{ sender\-port T} _ T{ dhcp\-ddns.server\-ip T} T{ dhcp\-ddns T} T{ server\-ip T} _ T{ dhcp\-ddns.server\-port T} T{ dhcp\-ddns T} T{ server\-port T} _ T{ expired\-leases\-processing.flush\-reclaimed\-timer\-wait\-time T} T{ expired\-leases\-processing T} T{ flush\-reclaimed\-timer\-wait\-time T} _ T{ expired\-leases\-processing.hold\-reclaimed\-time T} T{ expired\-leases\-processing T} T{ hold\-reclaimed\-time T} _ T{ expired\-leases\-processing.max\-reclaim\-leases T} T{ expired\-leases\-processing T} T{ max\-reclaim\-leases T} _ T{ expired\-leases\-processing.max\-reclaim\-time T} T{ expired\-leases\-processing T} T{ max\-reclaim\-time T} _ T{ expired\-leases\-processing.reclaim\-timer\-wait\-time T} T{ expired\-leases\-processing T} T{ reclaim\-timer\-wait\-time T} _ T{ expired\-leases\-processing.unwarned\-reclaim\-cycles T} T{ expired\-leases\-processing T} T{ unwarned\-reclaim\-cycles T} _ T{ multi\-threading.enable\-multi\-threading T} T{ multi\-threading T} T{ enable\-multi\-threading T} _ T{ multi\-threading.thread\-pool\-size T} T{ multi\-threading T} T{ thread\-pool\-size T} _ T{ multi\-threading.packet\-queue\-size T} T{ multi\-threading T} T{ packet\-queue\-size T} _ T{ sanity\-checks.lease\-checks T} T{ sanity\-checks T} T{ lease\-checks T} _ T{ sanity\-checks.extended\-info\-checks T} T{ sanity\-checks T} T{ extended\-info\-checks T} _ T{ dhcp\-queue\-control.enable\-queue T} T{ dhcp\-queue\-control T} T{ enable\-queue T} _ T{ dhcp\-queue\-control.queue\-type T} T{ dhcp\-queue\-control T} T{ queue\-type T} _ T{ dhcp\-queue\-control.capacity T} T{ dhcp\-queue\-control T} T{ capacity T} .TE .sp برخی از پارامترهای فهرست سراسری که تنها حاوی انواع اسکالر هستند، توسط بک‌اند پیکربندی پشتیبانی می‌شوند..SS فهرست پارامترهای فهرستی DHCPv4 پشتیبانی‌شده توسط بک‌اند پیکربندی .TS box center; l. T{ نام پارامتر | نوع پارامتر نگه‌دارندهٔ فهرست T} _ T{ host\-reservation\-identifiers | string T} .TE .SS فعال‌سازی بک‌اند پیکربندی .sp قطعه‌پیکربندی زیر را در نظر بگیرید که از یک پایگاه‌دادهٔ پیکربندی MySQL استفاده می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqserver\-tag\(dq: \(dqmy DHCPv4 server\(dq, \(dqconfig\-control\(dq: { \(dqconfig\-databases\(dq: [ { \(dqtype\(dq: \(dqmysql\(dq, \(dqname\(dq: \(dqkea\(dq, \(dquser\(dq: \(dqkea\(dq, \(dqpassword\(dq: \(dq1234\(dq, \(dqhost\(dq: \(dq192.0.2.1\(dq, \(dqport\(dq: 3302 } ], \(dqconfig\-fetch\-wait\-time\(dq: 20 }, \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_mysql.so\(dq }, { \(dqlibrary\(dq: \(dqlibdhcp_cb_cmds.so\(dq } ] } } .EE .UNINDENT .UNINDENT .sp قطعه‌کد زیر استفاده از یک پایگاه‌دادهٔ PostgreSQL را نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqserver\-tag\(dq: \(dqmy DHCPv4 server\(dq, \(dqconfig\-control\(dq: { \(dqconfig\-databases\(dq: [ { \(dqtype\(dq: \(dqpostgresql\(dq, \(dqname\(dq: \(dqkea\(dq, \(dquser\(dq: \(dqkea\(dq, \(dqpassword\(dq: \(dq1234\(dq, \(dqhost\(dq: \(dq192.0.2.1\(dq, \(dqport\(dq: 3302 } ], \(dqconfig\-fetch\-wait\-time\(dq: 20 }, \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_pgsql.so\(dq }, { \(dqlibrary\(dq: \(dqlibdhcp_cb_cmds.so\(dq } ] } } .EE .UNINDENT .UNINDENT .sp نگاشت \fBconfig\-control\fP شامل دو پارامتر است. \fBconfig\-databases\fP فهرستی حاوی یک عنصر است که نوع پایگاه‌داده، مکان آن و اطلاعات هویتی مورد استفاده برای اتصال به این پایگاه‌داده را شامل می‌شود. (توجه داشته باشید پارامترهایی که در اینجا مشخص شده‌اند، با مشخصات پایگاه‌داده برای بک‌اند پایگاه‌دادهٔ اجاره (lease) و بک‌اند پایگاه‌دادهٔ میزبان‌ها مطابقت دارند.) در حال حاضر تنها یک اتصال پایگاه‌داده را می‌توان در فهرست \fBconfig\-databases\fP مشخص کرد. سرور در طول راه‌اندازی یا پیکربندی مجدد به این پایگاه‌داده متصل می‌شود و پیکربندی موجود برای این سرور را از پایگاه‌داده واکشی می‌کند. این پیکربندی در پیکربندی خوانده‌شده از فایل پیکربندی ادغام می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هر زمان که تعارضی بین پارامترهای مشخص‌شده در فایل پیکربندی و پایگاه‌داده وجود داشته باشد، پارامترهای پایگاه‌داده اولویت دارند. ما اکیداً توصیه می‌کنیم از تکرار پارامترها در فایل و پایگاه‌داده خودداری کنید، اما این توصیه توسط سرورهای Kea اجبار نمی‌شود. به‌ویژه، اگر پیکربندی زیرشبکه‌ها از پایگاه‌داده تأمین می‌شود، توصیه می‌کنیم تمام زیرشبکه‌ها در پایگاه‌داده مشخص شوند و هیچ زیرشبکه‌ای در فایل پیکربندی مشخص نشود. امکان تعیین زیرشبکه‌ها در هر دو مکان وجود دارد، اما زیرشبکه‌های موجود در فایل پیکربندی که دارای شناسه‌ها (IDs) و/یا پیشوندهای هم‌پوشان با زیرشبکه‌های پایگاه‌داده باشند، توسط موارد موجود در پایگاه‌داده جایگزین خواهند شد. .UNINDENT .UNINDENT .sp پس از پیکربندی سرور Kea، این سرور به‌صورت دوره‌ای پایگاه‌داده را برای بررسی تغییرات پیکربندی وارسی (poll) می‌کند. بسامد وارسی توسط پارامتر \fBconfig\-fetch\-wait\-time\fP بر حسب ثانیه کنترل می‌شود؛ این مقدار فاصلهٔ زمانی بین لحظه‌ای است که سرور آخرین وارسی خود (و احتمالاً به‌روزرسانی پیکربندی محلی) را به پایان رسانده و زمانی است که وارسی مجدد را آغاز خواهد کرد. در مثال بالا، این دوره روی ۲۰ ثانیه تنظیم شده است. این بدان معناست که پس از افزودن یک پیکربندی جدید به پایگاه‌داده (مثلاً افزودن یک زیرشبکهٔ جدید)، تا ۲۰ ثانیه (به‌علاوهٔ زمان مورد نیاز برای واکشی و اعمال پیکربندی جدید) طول می‌کشد تا سرور شروع به استفاده از این زیرشبکه کند. هرچه مقدار \fBconfig\-fetch\-wait\-time\fP کمتر باشد، زمان واکنش سرور به به‌روزرسانی‌های افزایشی پیکربندی در پایگاه‌داده کوتاه‌تر خواهد بود. از سوی دیگر، وارسی بیش از حد پایگاه‌داده ممکن است بر عملکرد سرور DHCP تأثیر بگذارد، زیرا سرور باید حداقل یک پرس‌وجو به پایگاه‌داده ارسال کند تا هرگونه به‌روزرسانی معلق پیکربندی را کشف کند. مقدار پیش‌فرض \fBconfig\-fetch\-wait\-time\fP برابر با ۳۰ ثانیه است. .sp دستور \fBconfig\-backend\-pull\fP \%<#\:std-isccmd-config-backend-pull> می‌تواند برای وادار کردن سرور به وارسی فوری هرگونه تغییر پیکربندی از پایگاه‌داده و جلوگیری از انتظار برای چرخهٔ واکشی بعدی استفاده شود. .sp در مثال‌های پیکربندی بالا، دو کتابخانهٔ قلاب (hook library) بارگذاری شده‌اند. نخستین مورد کتابخانه‌ای است که بک‌اند پیکربندی را برای یک نوع پایگاه‌دادهٔ خاص پیاده‌سازی می‌کند: \fBlibdhcp_mysql.so\fP \%<#\:std-ischooklib-libdhcp_mysql\:.so> پشتیبانی از MySQL را ارائه می‌دهد و \fBlibdhcp_pgsql.so\fP \%<#\:std-ischooklib-libdhcp_pgsql\:.so> پشتیبانی از PostgreSQL را فراهم می‌کند. کتابخانهٔ بارگذاری‌شده باید با \fBtype\fP پایگاه‌داده که در پارامتر \fBconfig\-control\fP مشخص شده مطابقت داشته باشد؛ در غیر این صورت هنگامی که سرور تلاش می‌کند پیکربندی خود را بارگذاری کند، یک خطا ثبت شده و بارگذاری با شکست مواجه می‌شود. .sp کتابخانهٔ قلاب دوم، \fBlibdhcp_cb_cmds.so\fP \%<#\:std-ischooklib-libdhcp_cb_cmds\:.so>، اختیاری است. این کتابخانه زمانی باید بارگذاری شود که قرار است از نمونهٔ سرور Kea برای مدیریت پیکربندی در پایگاه‌داده استفاده شود. برای جزئیات بیشتر به بخش libdhcp_cb_cmds.so: Configuration Backend Commands \%<#\:hooks-cb-cmds> مراجعه کنید..SS پارامترهای پیکربندی سازگاری Kea DHCPv4 .sp هدف ISC این است که Kea اسناد RFC را برای ارتقای سازگاری بهتر با استانداردها رعایت کند. با این حال، پیاده‌سازی‌های معیوب بسیاری از DHCP از قبل وجود دارند که نمی‌توان آن‌ها را به‌راحتی برطرف یا ارتقا داد. بنابراین، Kea یک حالت سازگاری با کاربرد آسان را برای کلاینت‌های خراب یا ناسازگار فراهم می‌کند. برای این منظور، گزینه سازگاری باید فعال شود تا رفتارهای غیرمعمول مجاز شمرده شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqcompatibility\(dq: { } } } .EE .UNINDENT .UNINDENT .SS تجزیه آسان‌گیرانه گزینه‌ها (Lenient Option Parsing) .sp به‌طور پیش‌فرض، فیلدهای چندتایی (tuple) تعریف‌شده در گزینه‌های سفارشی به‌عنوان مجموعه‌ای از جفت‌های طول\-مقدار (length\-value) تجزیه می‌شوند. .sp با \fB\(dqlenient\-option\-parsing\(dq: true\fP، اگر یک طول از باقی‌مانده بافر گزینه فراتر می‌رفت، نسخه‌های قبلی Kea پیام لاگ \fBunable to parse the opaque data tuple, the buffer length is x, but the tuple length is y\fP با شرط \fBx < y\fP را بازمی‌گرداندند؛ این اتفاق دیگر رخ نمی‌دهد. در عوض، مقدار برابر با باقی‌مانده بافر در نظر گرفته می‌شود، یا بر اساس پیام لاگ بالا، طول چندتایی \fBy\fP برابر با \fBx\fP می‌شود\&. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqcompatibility\(dq: { \(dqlenient\-option\-parsing\(dq: true } } } .EE .UNINDENT .UNINDENT .sp از نسخه 2.5.8 در Kea، این تجزیه گسترش یافته است تا گزینه‌های FQDN (81) دارای برخی نام‌های دامنه نامعتبر را بی‌صدا نادیده بگیرد، و از نسخه 3.1.9 در Kea برای تصحیح پرچم‌های نامعتبر توسعه یافته است، یعنی زمانی که هر دو پرچم \(aqS\(aq و \(aqN\(aq روی 1 تنظیم شده باشند، پرچم \(aqN\(aq جهت سازگاری با رفتار ISC DHCP به 0 بازنشانی می‌شود. .SS نادیده گرفتن شناسه کارگزار DHCP (DHCP Server Identifier) .sp با \fB\(dqignore\-dhcp\-server\-identifier\(dq: true\fP، کارگزار نشانی موجود در گزینه DHCP Server Identifier را بررسی نمی‌کند، یعنی اینکه آیا پرس‌وجو به این کارگزار ارسال شده است یا کارگزاری دیگر (و در حالت دوم رها کردن پرس‌وجو). .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqcompatibility\(dq: { \(dqignore\-dhcp\-server\-identifier\(dq: true } } } .EE .UNINDENT .UNINDENT .SS نادیده گرفتن Link Selection در RAI .sp با \fB\(dqignore\-rai\-link\-selection\(dq: true\fP، داده‌های زیرگزینه Relay Agent Information Link Selection برای انتخاب زیرشبکه (subnet) استفاده نمی‌شود. در این حالت، منطق عادی، انتخاب زیرشبکه را هدایت می‌کند، به جای تلاش برای استفاده از زیرشبکه مشخص‌شده توسط این زیرگزینه. این گزینه منطبق بر RFC نیست و به‌طور پیش‌فرض روی \fBfalse\fP تنظیم شده است. تنظیم این گزینه روی \fBtrue\fP می‌تواند به انتخاب زیرشبکه در سناریوهای خاصی کمک کند؛ برای مثال، هنگامی که رله‌های DHCP به مدیر سیستم اجازه نمی‌دهند مشخص کند کدام زیرگزینه‌ها در گزینه Relay Agent Information گنجانده شوند، و اطلاعات Link Selection نادرست را وارد می‌کنند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqcompatibility\(dq: { \(dqignore\-rai\-link\-selection\(dq: true } } } .EE .UNINDENT .UNINDENT .SS مستثنی کردن اولین و آخرین نشانی‌ها در زیرشبکه‌های 24/ یا بزرگ‌تر .sp پرچم سازگاری \fBexclude\-first\-last\-24\fP در بخش پیکربندی مخازن نشانی‌های IPv4 توضیح داده شده است (در صورت تنظیم روی true، نشانی‌های 0. و 255. از زیرشبکه‌هایی با طول پیشوند کوچکتر یا مساوی 24 مستثنی می‌شوند). .SS راهبردهای تخصیص نشانی در DHCPv4 .sp یک کارگزار DHCP الگوریتم پیچیده‌ای را برای انتخاب یک نشانی IPv4 برای یک کلاینت دنبال می‌کند. این کارگزار ترجیح می‌دهد نشانی‌های خاص درخواست‌شده توسط کلاینت و نشانی‌هایی را که کلاینت برای آن‌ها رزرو دارد، تخصیص دهد. .sp اگر کلاینت نشانی خاصی را درخواست نکند و هیچ رزروی نداشته باشد، یا کلاینت‌های دیگر از قبل در حال استفاده از هر یک از نشانی‌های درخواستی باشند، کارگزار باید نشانی دردسترس دیگری را در مخازن پیکربندی‌شده بیابد. تابعی از کارگزار با عنوان \(dqallocator\(dq (تخصیص‌دهنده) در Kea مسئول یافتن یک نشانی در دسترس در چنین مواردی است. .sp کارگزار Kea DHCPv4 پارامترهای پیکربندی را برای انتخاب تخصیص‌دهنده‌های مختلف در سطوح سراسری (global)، شبکه مشترک (shared\-network) و زیرشبکه (subnet) ارائه می‌دهد. مثال زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqallocator\(dq: \(dqrandom\(dq, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq, \(dqallocator\(dq: \(dqiterative\(dq }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq } ] } } .EE .UNINDENT .UNINDENT .sp این تخصیص‌دهنده، راهبرد تخصیص پیش‌فرض iterative (تکرارشونده) را در سطح سراسری لغو کرده و در عوض تخصیص random (تصادفی) را انتخاب می‌کند. تخصیص تصادفی برای زیرشبکه با شناسه 2 استفاده خواهد شد، در حالی که تخصیص تکرارشونده برای زیرشبکه با شناسه 1 به کار خواهد رفت. .sp بخش‌های زیر تخصیص‌دهنده‌های پشتیبانی‌شده و کاربردهای توصیه‌شده آن‌ها را شرح می‌دهند..SS مقایسه تخصیص‌دهنده‌ها (Allocators Comparison) .sp در جدول زیر، تخصیص‌دهنده‌های پشتیبانی‌شده را که همگی در بخش‌های بعدی به تفصیل شرح داده شده‌اند، به‌طور خلاصه مقایسه می‌کنیم. .SS مقایسه تخصیص‌دهنده‌های اجاره پشتیبانی‌شده توسط Kea DHCPv4 .TS box center; l|l|l|l|l|l. T{ تخصیص‌دهنده T} T{ عملکرد در بهره‌برداری پایین T} T{ عملکرد در بهره‌برداری بالا T} T{ تصادفی‌سازی اجاره T} T{ راه‌اندازی/پیکربندی T} T{ مصرف حافظه T} _ T{ Iterative T} T{ بسیار بالا T} T{ پایین T} T{ خیر T} T{ بسیار سریع T} T{ پایین T} _ T{ Random T} T{ بالا T} T{ پایین T} T{ بله T} T{ بسیار سریع T} T{ بالا (متغیر) T} _ T{ Free Lease Queue T} T{ بالا T} T{ بالا T} T{ بله T} T{ کند (بسته به اندازه poolها) T} T{ بالا (متغیر) T} _ T{ Shared FLQ T} T{ بالا T} T{ بالا T} T{ جزئی، poolهای درون زیرشبکه‌ها تصادفی هستند T} T{ هنگام افزودن، کند؛ پس از افزودن، سریع T} T{ پایین T} .TE .SS تخصیص‌دهنده ترتیبی (Iterative Allocator) .sp این تخصیص‌دهنده پیش‌فرض مورد استفاده توسط کارساز Kea DHCPv4 است. این تخصیص‌دهنده آخرین آدرس پیشنهادشده را به خاطر می‌سپارد و آن آدرس را به اضافه یک، به کلاینت بعدی پیشنهاد می‌دهد. برای مثال، ممکن است آدرس‌ها را به این ترتیب پیشنهاد دهد: \fB192.0.2.10\fP، \fB192.0.2.11\fP، \fB192.0.2.12\fP و غیره. زمان لازم برای یافتن و پیشنهاد آدرس بعدی بسیار کوتاه است؛ بنابراین، زمانی که میزان بهره‌برداری از pool پایین بوده و احتمال در دسترس بودن آدرس بعدی بالا باشد، این تخصیص‌دهنده بیشترین کارایی را دارد. .sp تخصیص ترتیبی زمانی که چند کارساز DHCP یک پایگاه داده اجاره را به اشتراک می‌گذارند یا به یک کلاستر متصل هستند، عملکرد ضعیفی دارد. کارسازها تمایل دارند بلوک‌های مشابهی از آدرس‌ها را به طور مستقل به کلاینت‌های مختلف پیشنهاد داده و تخصیص دهند، که این امر موجب تداخل‌های تخصیص فراوان میان کارسازها و ارسال مجدد درخواست‌ها توسط کلاینت‌ها می‌شود. تخصیص تصادفی با پراکنده‌سازی ترتیب تخصیص، این مشکل را برطرف می‌کند. .SS تخصیص‌دهنده تصادفی (Random Allocator) .sp تخصیص‌دهنده تصادفی از یک تابع تصادفی‌سازی یکنواخت برای انتخاب آدرس‌های پیشنهادی از poolهای زیرشبکه استفاده می‌کند. این روش در استقرارهایی که چند کارساز به یک پایگاه داده مشترک یا یک کلاستر پایگاه داده متصل هستند، بسیار مناسب است. با پراکنده کردن آدرس‌های پیشنهادی، کارسازها خطر تخصیص هم‌زمان یا تقریباً هم‌زمان یک آدرس یکسان به دو کلاینت مختلف را به حداقل می‌رسانند. علاوه بر این، تاب‌آوری کارساز را در برابر حملات مبتنی بر پیش‌بینی‌پذیری تخصیص بهبود می‌بخشد. .sp با این حال، تخصیص‌دهنده تصادفی کمی کندتر از تخصیص‌دهنده ترتیبی است. افزون بر این، مصرف حافظه کارساز را افزایش می‌دهد زیرا باید آدرس‌های تصادفی‌شده را به خاطر بسپارد تا از پیشنهاد مکرر آن‌ها جلوگیری کند. مصرف حافظه با افزایش تعداد آدرس‌های پیشنهادی رشد می‌کند؛ به عبارت دیگر، poolهای بزرگ‌تر و کلاینت‌های بیشتر، مصرف حافظه را در تخصیص تصادفی بالا می‌برند. .sp قطعه‌پیکربندی زیر نحوه انتخاب تخصیص‌دهنده تصادفی را برای یک زیرشبکه نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqallocator\(dq: \(dqrandom\(dq, \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq, \(dqallocator\(dq: \(dqrandom\(dq } ] } } .EE .UNINDENT .UNINDENT.SS "تخصیص‌دهنده صف اجاره آزاد (Free Lease Queue Allocator)" .sp این یک تخصیص‌دهنده (allocator) پیشرفته است که استفاده از آن باید در زیرشبکه‌هایی با استخرهای آدرس با بهره‌برداری بالا مورد توجه قرار گیرد. در چنین مواردی، ممکن است زمان قابل‌توجهی طول بکشد تا تخصیص‌دهنده تکرارشونده (iterative) یا تصادفی (random) یک آدرس در دسترس پیدا کند، زیرا آن‌ها باید مکرراً بررسی کنند که آیا برای آدرسی که قصد ارائه آن را دارند، اجاره معتبری وجود دارد یا خیر. هنگامی که استخرهای زیرشبکه به اتمام می‌رسند، تعداد این بررسی‌ها می‌تواند به اندازه تعداد کل آدرس‌های موجود در زیرشبکه باشد که این امر می‌تواند تأثیر منفی مستقیمی بر زمان پاسخ‌دهی DHCP به هر درخواست بگذارد. .sp تخصیص‌دهنده Free Lease Queue (FLQ) تخصیص‌ها و آزادسازی‌های اجاره را دنبال کرده و فهرستی جاری از آدرس‌های در دسترس را برای هر استخر آدرس نگهداری می‌کند. این تخصیص‌دهنده اجازه می‌دهد که یک اجاره در دسترس در زمانی ثابت، صرف‌نظر از میزان بهره‌برداری استخرهای زیرشبکه، انتخاب شود. تخصیص‌دهنده به‌طور پیوسته فهرست اجاره‌های آزاد را با حذف هر اجاره تخصیص‌یافته و افزودن موارد رهاشده (released) یا بازیابی‌شده (reclaimed) به‌روزرسانی می‌کند. .sp قطعه‌پیکربندی زیر نحوه انتخاب تخصیص‌دهنده FLQ را برای یک زیرشبکه نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqallocator\(dq: \(dqflq\(dq } ] } } .EE .UNINDENT .UNINDENT .sp چندین ملاحظه وجود دارد که مدیر سیستم باید پیش از استفاده از این تخصیص‌دهنده مد نظر قرار دهد. تخصیص‌دهنده FLQ می‌تواند تأثیر شدیدی بر زمان راه‌اندازی (startup) و بازپیکربندی (reconfiguration) سرور بگذارد، زیرا تخصیص‌دهنده باید فهرست اجاره‌های آزاد را برای هر زیرشبکه‌ای که در آن استفاده می‌شود، پر کند. این تأخیرها هم در زمان بارگذاری مجدد پیکربندی و هم هنگامی که زیرشبکه‌ها با استفاده از \fBlibdhcp_subnet_cmds.so\fP \%<#\:std-ischooklib-libdhcp_subnet_cmds\:.so>\& ایجاد می‌شوند، قابل مشاهده است. این تخصیص‌دهنده مصرف حافظه را متناسب با اندازه کل استخرهای آدرسی که تخصیص‌دهنده FLQ برای آن‌ها به کار رفته است، برای نگهداری فهرست اجاره‌های آزاد افزایش می‌دهد. در نهایت، بازیابی اجاره (lease reclamation) باید با مقدار پایینی برای پارامتر \fBreclaim\-timer\-wait\-time\fP فعال باشد تا اطمینان حاصل شود که سرور به‌طور مکرر اجاره‌های منقضی‌شده را جمع‌آوری کرده و آن‌ها را از طریق صف اجاره آزاد برای تخصیص در دسترس قرار می‌دهد؛ اجاره‌های منقضی‌شده تا زمانی که توسط سرور بازیابی نشوند، از نظر تخصیص‌دهنده آزاد تلقی نمی‌شوند. برای جزئیات بیشتر درباره فرایند بازیابی اجاره، به Lease Reclamation \%<#\:lease-reclamation> مراجعه کنید. .sp ما توصیه می‌کنیم که تخصیص‌دهنده FLQ تنها پس از بررسی دقیق انتخاب شود. برای نمونه، استفاده از آن برای یک زیرشبکه با استخر \fB/8\fP ممکن است راه‌اندازی سرور را ۱۵ ثانیه یا بیشتر به تأخیر بیندازد. از سوی دیگر، تأخیر راه‌اندازی و افزایش مصرف حافظه برای زیرشبکه‌هایی با استخر \fB/16\fP یا کوچک‌تر باید قابل قبول باشد. ما همچنین توصیه می‌کنیم نوع تخصیص‌دهنده دیگری را در تنظیمات پیکربندی سراسری (global) مشخص کرده و این انتخاب را در سطح زیرشبکه یا شبکه اشتراکی (shared\-network) بازنویسی (override) کنید تا تخصیص‌دهنده FLQ فقط برای زیرشبکه‌های منتخب استفاده شود. بدین ترتیب، هنگامی که یک زیرشبکه جدید بدون تعیین تخصیص‌دهنده اضافه می‌شود، از تنظیم سراسری استفاده شده و در نتیجه از اثرات نامطلوب و غیرضروری بر زمان راه‌اندازی سرور جلوگیری می‌شود. .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 تخصیص‌دهنده FLQ برای استفاده با پایگاه‌داده اجاره مشترک مناسب نیست (یعنی هنگامی که چندین سرور Kea اجاره‌ها را در یک پایگاه‌داده یکسان ذخیره می‌کنند). سرورها از اجاره‌های منقضی‌شده‌ای که توسط سرورهای همتا بازیابی شده‌اند بی‌خبر می‌مانند و هرگز آن‌ها را به صف‌های محلی اجاره آزاد خود بازنمی‌گردانند. در نتیجه، سرورها قادر نخواهند بود برخی از اجاره‌های موجود را به کلاینت‌ها پیشنهاد دهند. تنها سروری که یک اجاره خاص را بازیابی می‌کند، قادر به ارائه آن خواهد بود. .UNINDENT .UNINDENT .sp در Kea 3.1.1 یک پارامتر جدید با نام \fBadaptive\-lease\-time\-threshold\fP اضافه شد. این پارامتر می‌تواند در سطوح سراسری (global)، شبکه اشتراکی (shared network) و زیرشبکه مشخص شود و مقداری ممیز شناور بین \fB0.0\fP (غیرشامل) و \fB1.0\fP می‌پذیرد\&. این پارامتر به‌طور پیش‌فرض یا هنگامی که روی \fB1.0\fP تنظیم شده باشد، غیرفعال است\&. این پارامتر فقط توسط تخصیص‌دهنده FLQ پشتیبانی می‌شود. هنگامی که نرخ اشغال استخرها در یک زیرشبکه بالاتر از مقدار مشخص‌شده باشد، سرور طول‌عمر معتبر اجاره را برای کلاینت‌های جدید به میزان مربوطه در \fBmin\-valid\-lifetime\fP کاهش می‌دهد. کلاینت‌هایی که یک اجاره از پیش موجود را تمدید می‌کنند، حداقل طول‌عمر باقی‌مانده از اجاره فعلی را دریافت می‌کنند. از آنجا که اجاره‌ها سریع‌تر منقضی می‌شوند، سرور ممکن است سریع‌تر بازیابی شود یا به‌کلی از اتمام ظرفیت استخر جلوگیری کند. .sp نرخ اشغال به‌صورت تعداد آدرس‌های تخصیص‌یافته کنونی (شامل آدرسی که در حال تخصیص است) تقسیم بر تعداد کل آدرس‌ها در استخرهایی که امکان تخصیص آدرس از آن‌ها وجود دارد، تعریف می‌شود (یعنی اگر پرس‌وجو عضوی از گارد \fBclient\-classes\fP یک استخر نباشد، آن استخر به حساب نمی‌آید). .SS "تخصیص‌دهنده صف اجاره آزاد مشترک (Shared Free Lease Queue Allocator)" .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 تخصیص‌دهنده Shared Free Lease Queue Allocator که در Kea 3.1.9 اضافه شد، آزمایشی (experimental) تلقی شده و برای استفاده در محیط عملیاتی (production) پشتیبانی نمی‌شود. .UNINDENT .UNINDENT .sp تخصیص‌دهنده Shared Free Lease Queue (SFLQ) برای سایت‌هایی با بک‌اندهای اجاره مشترک (MySQL یا PostgreSQL) و زیرشبکه‌هایی با استخرهای آدرس با بهره‌برداری بالا در نظر گرفته شده است. در چنین مواردی، ممکن است زمان قابل‌توجهی طول بکشد تا تخصیص‌دهنده تکرارشونده یا تصادفی یک آدرس در دسترس پیدا کند، زیرا آن‌ها باید مکرراً بررسی کنند که آیا برای آدرسی که قصد ارائه آن را دارند، اجاره معتبری وجود دارد یا خیر. هنگامی که استخرهای زیرشبکه به اتمام می‌رسند، تعداد این بررسی‌ها می‌تواند به اندازه تعداد کل آدرس‌های زیرشبکه باشد. از آنجا که هر بررسی نیازمند یک پرس‌وجو در پایگاه‌داده است، این موضوع می‌تواند تأثیر منفی مستقیمی بر زمان پاسخ‌دهی DHCP به هر درخواست بگذارد. .sp مشابه تخصیص‌دهنده Free Lease Queue، تخصیص‌دهنده SFLQ نیز تخصیص‌ها و آزادسازی‌های اجاره را دنبال کرده و فهرستی جاری از آدرس‌های در دسترس را برای هر استخر آدرس نگه می‌دارد. به این فهرست‌ها داده‌های SFLQ گفته می‌شود. این امر اجازه می‌دهد که صرف‌نظر از میزان بهره‌برداری استخرهای زیرشبکه، یک اجاره در دسترس در زمانی ثابت انتخاب شود. داده‌های SFLQ از طریق به‌روزرسانی‌های اختصاصی اجاره که توسط سرور Kea برای اجاره‌های متعلق به زیرشبکه‌های استفاده‌کننده از تخصیص SFLQ به کار گرفته می‌شوند، نگهداری می‌شوند. .sp تفاوت اساسی میان تخصیص‌دهنده‌های FLQ و SFLQ در این است که تخصیص SFLQ داده‌های SFLQ را به‌جای حافظه محلی سرور Kea، به‌صورت متمرکز در بک‌اند اجاره ذخیره می‌کند. این کار اجازه می‌دهد که این داده‌ها میان سرورها به اشتراک گذاشته شوند، به‌طوری که همگی درک یکسانی از وضعیت فعلی اجاره‌ها داشته باشند. این امر همچنین بدان معناست که داده‌های SFLQ پس از ایجاد، پایدار و ماندگار (persistent) هستند و بنابراین نیازی به ایجاد مجدد آن‌ها هنگام راه‌اندازی یا بازپیکربندی سرور Kea نیست. قطعه‌پیکربندی زیر نحوه انتخاب تخصیص‌دهنده SFLQ را برای یک زیرشبکه نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqallocator\(dq: \(dqshared\-flq\(dq } ] } } .EE .UNINDENT .UNINDENT .sp ملاحظاتی وجود دارد که مدیر سیستم باید پیش از استفاده از این تخصیص‌دهنده در نظر بگیرد. همانند FLQ، تخصیص‌دهنده SFLQ می‌تواند تأثیر شدیدی بر زمان راه‌اندازی و بازپیکربندی سرور بگذارد، زیرا تخصیص‌دهنده باید داده‌های SFLQ را برای هر استخر در هر زیرشبکه‌ای که در آن استفاده می‌شود ایجاد و پر کند. این تأخیرها هم در هنگام بارگذاری مجدد پیکربندی و هم زمانی که زیرشبکه‌ها با استفاده از \fBlibdhcp_subnet_cmds.so\fP \%<#\:std-ischooklib-libdhcp_subnet_cmds\:.so>\& ایجاد می‌شوند، قابل مشاهده است. بر خلاف FLQ، این هزینه‌ها تنها در نخستین باری رخ می‌دهند که یک زیرشبکه برای استفاده از SFLQ پیکربندی می‌شود یا تغییراتی در محدوده‌های آدرس استخرهای آن اعمال می‌گردد. به بیانی دیگر، پس از راه‌اندازی مجدد یا بازپیکربندی، داده‌های SFLQ تنها باید برای استخرهایی ایجاد شوند که پیش‌تر داده‌ای برای آن‌ها ایجاد نشده است. بنابراین تأثیر آن بر راه‌اندازی‌های مجدد یا بازپیکربندی‌های بعدی زیرشبکه‌هایی که هم‌اکنون از SFLQ استفاده می‌کنند، حداقلی و ناچیز است. .sp از آنجا که داده‌های SFLQ در بک‌اند اجاره نگهداری می‌شوند، هزینه ذخیره‌سازی آن‌ها در فضای دیسک سرور پایگاه‌داده است نه در حافظه محلی سرور Kea. مصرف دیسک برای داده‌های SFLQ کسری از اطلاعاتی است که در حال حاضر به ازای هر اجاره ذخیره می‌شود و با افزایش بهره‌برداری از استخر، حجم داده‌های SFLQ کاهش می‌یابد. .sp ما توصیه می‌کنیم که تخصیص‌دهنده SFLQ تنها پس از بررسی دقیق انتخاب شود. همان‌طور که در بالا بحث شد، تأثیر بر راه‌اندازی هنگام شروع استفاده از SFLQ می‌تواند قابل‌توجه باشد. ایجاد داده‌های اولیه SFLQ برای استخرهای بزرگ (مانند \(ga\(ga/8\(ga\(ga) ممکن است راه‌اندازی سرور را برای هر استخر چندین ثانیه یا بیشتر به تأخیر بیندازد. این کار برای استخرهای کوچک‌تر (مانند \(ga\(ga/16\(ga\(ga یا کمتر) سریع‌تر است، اما در صورت وجود تعداد زیادی از این استخرها، مجموع زمان صرف‌شده برای هر استخر می‌تواند قابل‌توجه شود. برای کاهش این هزینه راه‌اندازی، توصیه می‌کنیم نوع دیگری از تخصیص‌دهنده را در سطح سراسری مشخص کرده و تخصیص‌دهنده SFLQ را در سطح زیرشبکه یا شبکه اشتراکی فقط برای زیرشبکه‌های منتخب تعیین کنید. .sp جنبه مهم دیگری از تخصیص‌دهنده SFLQ وجود دارد که بررسی آن ضروری است. همان‌طور که در بالا اشاره شد، هنگامی که سروری از تخصیص SFLQ برای استخری مشخص استفاده می‌کند، از به‌روزرسانی‌های اختصاصی بک‌اند که داده‌های SFLQ را نگهداری می‌کنند، بهره می‌برد. بنابراین حیاتی است که تمام سرورهایی که یک بک‌اند اجاره را به اشتراک می‌گذارند، در مورد اینکه کدام زیرشبکه‌ها از تخصیص SFLQ استفاده می‌کنند توافق داشته باشند. در صورت عدم توافق، داده‌های SFLQ به‌سرعت نادقیق و نادرست خواهند شد. ممکن است آدرس‌ها آزاد به نظر برسند در حالی که آزاد نیستند و بالعکس. در حالت اول، موتور تخصیص یک اجاره موجود را شناسایی کرده و آدرس دیگری را امتحان می‌کند. در حالت دوم، اجاره به کلاینت پیشنهاد نخواهد شد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اکیداً توصیه می‌شود که پیکربندی زیرشبکه‌ها برای استفاده یا توقف استفاده از تخصیص SFLQ در بازه‌های تعمیر و نگهداری (maintenance windows) انجام شود، تا در زمان اعمال تغییرات، سرورها به‌طور فعال به کلاینت‌های آن زیرشبکه‌ها سرویس ندهند. این کار از ایجاد ناهماهنگی در داده‌های SFLQ جلوگیری می‌کند. .sp داده‌های SFLQ بر حسب استخرها ردیابی می‌شوند؛ جایی که هر استخر دارای یک آدرس شروع و یک آدرس پایان است. تغییرات پیکربندی که محدوده آدرس یک استخر را تغییر می‌دهند یا آن را به چندین استخر جدید تقسیم می‌کنند، هنگام اعمال پیکربندی جدید باعث ایجاد داده‌های SFLQ برای استخرهای جدید خواهند شد. .UNINDENT .UNINDENT .sp همان‌طور که پیش‌تر ذکر شد، هنگامی که یک سرور راه‌اندازی مجدد یا بازپیکربندی می‌شود، روی زیرشبکه‌های خود پیمایش کرده و تخصیص‌دهنده پیکربندی‌شده را برای استخرهای آن زیرشبکه راه‌اندازی اولیه (initialize) می‌کند. برای تخصیص‌دهنده SFLQ، این امر باعث می‌شود سرور از بک‌اند اجاره درخواست کند تا داده‌های SFLQ را برای هر استخر در زیرشبکه ایجاد کند. اگر داده‌های SFLQ از قبل برای یک استخر موجود باشد، درخواست بلافاصله بازمی‌گردد. در غیر این صورت، پس از ایجاد داده‌های SFLQ برای آن استخر بازخواهد گشت. ایجاد داده‌های SFLQ برای یک استخر خاص یک عملیات انحصاری (exclusive) است. پس از شروع این عملیات توسط یک سرور، هرگونه درخواست از سوی سرورهای دیگر برای ایجاد داده‌های SFLQ برای همان استخر مسدود (block) شده و تا زمانی که درخواست اول ایجاد داده‌های SFLQ استخر را کامل نکند، بازنخواهد گشت. بدین ترتیب تنها یک سرور داده‌های SFLQ استخر را ایجاد می‌کند و سایر سرورها تا زمانی که داده‌های SFLQ آن استخر وجود نداشته باشد، از استفاده از آن منع می‌شوند. این رفتار برای حفظ نظم در طول راه‌اندازی‌های مجدد و بازپیکربندی‌های هم‌زمان سرورها طراحی شده است. .sp موضوع استخرهای هم‌پوشان (overlapping pools) نیز مطرح است. Kea امکان پیکربندی استخرهایی را می‌دهد که محدوده آدرس آن‌ها با استخرهای دیگر هم‌پوشانی دارد. تخصیص‌دهنده SFLQ تا زمانی که تمام این استخرها برای استفاده از تخصیص‌دهنده SFLQ پیکربندی شده باشند، به‌طور یکپارچه از این مورد پشتیبانی می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 بازیابی اجاره باید با مقدار پایینی برای پارامتر \fBreclaim\-timer\-wait\-time\fP فعال باشد تا اطمینان حاصل شود که سرور به‌طور مکرر اجاره‌های منقضی‌شده را جمع‌آوری کرده و آن‌ها را از طریق داده‌های SFLQ برای تخصیص در دسترس قرار می‌دهد. اجاره‌های منقضی‌شده تا زمانی که توسط سرور بازیابی نشوند، از نظر تخصیص‌دهنده آزاد تلقی نمی‌شوند. برای جزئیات بیشتر درباره فرایند بازیابی اجاره، به Lease Reclamation \%<#\:lease-reclamation> مراجعه کنید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تخصیص‌دهنده SFLQ به استفاده در استخرهایی محدود شده است که بزرگ‌تر از /8 نباشند (به عنوان مثال ۱۶۷۷۷۲۱۶ آدرس). استخرهایی با ظرفیت بزرگ‌تر موجب خطای پیکربندی خواهند شد. .UNINDENT .UNINDENT .sp تخصیص‌دهنده SFLQ از \fBadaptive\-lease\-time\-threshold\fP پشتیبانی نمی‌کند\&..SH "سرور DHCPV6 (THE DHCPV6 SERVER)" .SS "راه‌اندازی و توقف سرور DHCPv6 (Starting and Stopping the DHCPv6 Server)" .sp توصیه می‌شود که سرور Kea DHCPv6 با استفاده از \fBkeactrl\fP \%<#\:std-iscman-keactrl> (توضیح داده شده در مدیریت Kea با keactrl \%<#\:keactrl>) راه‌اندازی و متوقف شود؛ با این حال، اجرای مستقیم سرور از طریق دستور \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> نیز امکان‌پذیر است، که گزینه‌های خط فرمان زیر را می‌پذیرد: .INDENT 0.0 .IP \(bu 2 \fB\-c file\fP \- فایل پیکربندی را مشخص می‌کند. این تنها گزینه اجباری است. .IP \(bu 2 \fB\-d\fP \- مشخص می‌کند که آیا ثبت وقایع سرور باید به حالت اشکال‌زدایی/پرگویی (debug/verbose) تغییر کند یا خیر. در حالت پرگویی، سطح شدت گزارش‌گیری و debuglevel مشخص‌شده در فایل پیکربندی نادیده گرفته می‌شوند؛ سطح شدت \(dqdebug\(dq و حداکثر debuglevel (مقدار 99) فرض می‌شوند. این پرچم برای تغییر وضعیت موقت سرور به حداکثر پرگویی، به عنوان مثال هنگام اشکال‌زدایی، بسیار مناسب است. .IP \(bu 2 \fB\-p server\-port\fP \- پورت محلی UDP را که سرور روی آن گوش می‌دهد مشخص می‌کند. این گزینه فقط هنگام آزمایش مفید است، زیرا یک سرور DHCPv6 که روی پورت‌هایی غیر از پورت‌های استاندارد گوش می‌دهد، قادر به رسیدگی به پرس‌وجوهای عادی DHCPv6 نیست. .IP \(bu 2 \fB\-P client\-port\fP \- پورت دوردست UDP را که سرور تمام پاسخ‌ها را به آن ارسال می‌کند مشخص می‌کند. این گزینه فقط هنگام آزمایش مفید است، زیرا یک سرور DHCPv6 که پاسخ‌ها را به پورت‌هایی غیر از پورت‌های استاندارد ارسال می‌کند، قادر به رسیدگی به پرس‌وجوهای عادی DHCPv6 نیست. .IP \(bu 2 \fB\-t file\fP \- یک فایل پیکربندی را جهت آزمایش مشخص می‌کند. \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> آن را بارگذاری کرده، بررسی می‌کند و خارج می‌شود. در طول آزمایش، پیام‌های گزارش در خروجی استاندارد و پیام‌های خطا در خطای استاندارد چاپ می‌شوند. نتیجه آزمایش از طریق کد خروج گزارش می‌شود (۰ = پیکربندی درست به نظر می‌رسد، ۱ = خطا رخ داده است). این بررسی جامع نیست؛ برخی از بررسی‌ها فقط هنگام اجرای واقعی سرور امکان‌پذیر هستند. .IP \(bu 2 \fB\-T file\fP \- یک فایل پیکربندی را جهت آزمایش مشخص می‌کند. \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> آن را بارگذاری کرده، بررسی می‌کند و خارج می‌شود. این گزینه بررسی‌های اضافی فراتر از آنچه \fB\-t\fP ارائه می‌دهد انجام می‌دهد، مانند برقراری اتصالات پایگاه داده (برای lease backend، host reservations backend، configuration backend و forensic logging backend)، بارگذاری کتابخانه‌های hook، تجزیه پیکربندی‌های hook\-library و غیره. این گزینه سوکت‌های UNIX یا TCP/UDP، فایل‌های قفل و همچنین باز کردن یا چرخش (rotate) فایل‌ها را انجام نمی‌دهد، زیرا هر یک از این اقدامات می‌تواند با فرایند در حال اجرا روی همان ماشین تداخل داشته باشد. .IP \(bu 2 \fB\-v\fP \- نسخه Kea را نمایش داده و خارج می‌شود. .IP \(bu 2 \fB\-V\fP \- نسخه گسترش‌یافته Kea را همراه با پارامترهای اضافی نمایش داده و خارج می‌شود. این فهرست شامل نسخه کتابخانه‌هایی است که به صورت پویا به Kea پیوند (link) داده شده‌اند. .IP \(bu 2 \fB\-W\fP \- گزارش پیکربندی Kea را نمایش داده و خارج می‌شود. این گزارش رونوشتی از فایل \fBconfig.report\fP تولید شده توسط \fBmeson setup\fP است؛ این گزارش درون فایل اجرایی باینری گنجانده شده است. .sp محتویات فایل \fBconfig.report\fP همچنین می‌تواند با بررسی برخی از کتابخانه‌ها در درخت نصب یا در درخت کد منبع در دسترس قرار گیرد. .INDENT 2.0 .INDENT 3.5 .sp .EX # from installation using libkea\-process.so $ strings ${prefix}/lib/libkea\-process.so | sed \-n \(aqs/;;;; //p\(aq # from sources using libkea\-process.so $ strings src/lib/process/.libs/libkea\-process.so | sed \-n \(aqs/;;;; //p\(aq # from sources using libkea\-process.a $ strings src/lib/process/.libs/libkea\-process.a | sed \-n \(aqs/;;;; //p\(aq # from sources using libcfgrpt.a $ strings src/lib/process/cfgrpt/.libs/libcfgrpt.a | sed \-n \(aqs/;;;; //p\(aq .EE .UNINDENT .UNINDENT .IP \(bu 2 \fB\-X\fP \- از نسخه Kea 3.0، محدودیت‌های امنیتی را غیرفعال می‌کند. سرور همچنان موارد نقض را بررسی می‌کند اما به جای توقف با خطا، هنگام مواجهه با آن‌ها گزارش‌های هشدار صادر می‌کند. لطفاً برای جزئیات به Kea Runtime Security Policy Checking \%<#\:sec-kea-runtime-security-policy-checking> مراجعه کنید. .UNINDENT .sp هنگام راه‌اندازی، سرور رابط‌های شبکه موجود را شناسایی کرده و تلاش می‌کند سوکت‌های UDP را روی تمام رابط‌های فهرست‌شده در فایل پیکربندی باز کند. از آنجا که سرور DHCPv6 پورت‌های ممتاز (privileged) را باز می‌کند، به دسترسی root نیاز دارد؛ این دیمن باید به عنوان کاربر root اجرا شود. .sp در طول راه‌اندازی، سرور تلاش می‌کند یک فایل PID به فرم زیر ایجاد کند: \fB[pidfile_dir]/[conf name].kea\-dhcp6.pid\fP، که در آن: .INDENT 0.0 .IP \(bu 2 \fBpidfile_dir\fP \- برابر است با \fB[prefix]/[localstatedir]/run/kea\fP که در آن \fBprefix\fP و \fBlocalstatedir\fP مقادیری هستند که به meson setup با استفاده از \fB\-\-prefix\fP و \fB\-\-localstatedir\fP منتقل شده‌اند و به طور پیش‌فرض به ترتیب \fB/usr/local\fP و \fBvar\fP می‌باشند. بنابراین کل مسیر \fBpidfile_dir\fP به طور پیش‌فرض \fB/usr/local/var\fP\& است. توجه داشته باشید که این مقدار ممکن است در زمان اجرا با تنظیم متغیر محیطی \fBKEA_PIDFILE_DIR\fP که عمدتاً برای اهداف آزمایشی در نظر گرفته شده است، بازنویسی شود. .IP \(bu 2 \fBconf name\fP: نام فایل پیکربندی مورد استفاده برای راه‌اندازی سرور، منهای تمام مسیرهای پیشین و پسوند فایل است. به عنوان مثال، در صورت داشتن مسیر \fB/usr/local/etc/kea/myconf.txt\fP، بخش استفاده‌شده \fBmyconf\fP\& خواهد بود. .UNINDENT .sp اگر فایل از قبل موجود باشد و شامل PID یک فرایند فعال باشد، سرور پیام گزارش \fBDHCP6_ALREADY_RUNNING\fP را صادر کرده و خارج می‌شود. این احتمال وجود دارد، اگرچه بعید است، که فایل بازمانده‌ای از یک فروپاشی سیستم (crash) باشد و فرایندی که PID متعلق به آن است ربطی به Kea نداشته باشد. در چنین حالتی، لازم است فایل PID را به صورت دستی حذف کنید. .sp سرور را می‌توان با استفاده از دستور \fBkill\fP متوقف کرد. هنگام اجرا در کنسول، سرور را می‌توان با فشردن Ctrl\-c نیز متوقف نمود. Kea این ترکیب کلید را تشخیص داده و به آرامی و به درستی خاموش می‌شود. .sp پیکربندی مجدد هر سرور Kea با دریافت سیگنال SIGHUP آغاز می‌شود. هنگامی که یک سرور سیگنال SIGHUP را دریافت می‌کند، فایل پیکربندی خود را دوباره می‌خواند و در صورتی که پیکربندی جدید معتبر باشد، از آن استفاده می‌کند. اگر معلوم شود که پیکربندی جدید نامعتبر است، سرور پیکربندی فعلی خود را حفظ می‌کند؛ با این حال، در برخی موارد یک پیام خطای مهلک (fatal) ثبت می‌شود که نشان می‌دهد سرور دیگر هیچ سرویسی ارائه نمی‌دهد: در این شرایط باید در اسرع وقت یک پیکربندی سالم بارگذاری شود..SS پیکربندی کارگزار DHCPv6 .SS مقدمه .sp این بخش نحوه پیکربندی کارگزار DHCPv6 مربوط به Kea را با استفاده از یک فایل پیکربندی توضیح می‌دهد. .sp پیش از آغاز به کار DHCPv6، فایل پیکربندی آن باید ایجاد شود. پیکربندی پایه‌ای به شرح زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { # DHCPv6 configuration starts on the next line \(dqDhcp6\(dq: { # First we set up global values \(dqvalid\-lifetime\(dq: 4000, \(dqrenew\-timer\(dq: 1000, \(dqrebind\-timer\(dq: 2000, \(dqpreferred\-lifetime\(dq: 3000, # Next we set up the interfaces to be used by the server. \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth0\(dq ] }, # And we specify the type of lease database \(dqlease\-database\(dq: { \(dqtype\(dq: \(dqmemfile\(dq, \(dqpersist\(dq: true, \(dqname\(dq: \(dq/var/lib/kea/dhcp6.leases\(dq }, # Finally, we list the subnets from which we will be leasing addresses. \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::1\-2001:db8:1::ffff\(dq } ] } ] # DHCPv6 configuration ends with the next line } } .EE .UNINDENT .UNINDENT .sp بندهای زیر نمای کلی مختصری از پارامترهای موجود در مثال بالا و همچنین قالب آن‌ها را ارائه می‌دهند. بخش‌های بعدی این فصل، این پارامترها و موارد دیگر را با جزئیات بسیار بیشتری بررسی می‌کنند. .sp خطوطی که با علامت هش (#) آغاز می‌شوند، توضیح (comment) هستند و توسط کارگزار نادیده گرفته می‌شوند؛ این خطوط به هیچ وجه بر عملکرد آن تأثیری ندارند. .sp پیکربندی در خط نخست با براکت مجعد بازشونده (یا آکولاد باز) اولیه آغاز می‌شود. هر پیکربندی باید حاوی شیئی باشد که پیکربندی ماژول Kea مصرف‌کننده آن را مشخص می‌کند. در مثال بالا، این شیء \fBDhcp6\fP نام دارد. .sp پیکربندی \fBDhcp6\fP با خط \fB\(dqDhcp6\(dq: {\fP آغاز شده و با آکولاد بسته متناظر (در مثال بالا، آکولاد پس از آخرین توضیح) پایان می‌یابد. هر آنچه میان این خطوط تعریف می‌شود، به عنوان پیکربندی \fBDhcp6\fP در نظر گرفته می‌شود. .sp به طور کلی، ترتیبی که این پارامترها ظاهر می‌شوند اهمیتی ندارد، اما دو نکته حائز اهمیت وجود دارد. نخست آنکه فایل پیکربندی باید یک JSON با ساختار صحیح (well\-formed) باشد؛ بدین معنا که پارامترها برای هر حوزه (scope) مشخص باید با یک کاما از هم جدا شوند، و نباید بعد از آخرین پارامتر کاما قرار گیرد. هنگام بازچینی فایل پیکربندی، جابه‌جا کردن یک پارامتر به موقعیت آخر یا از موقعیت آخر در یک حوزه، ممکن است نیازمند جابه‌جایی کاما نیز باشد. نکته دوم این است که تکرار چندباره یک پارامتر امری نامتداول است — هرچند از نظر قواعد JSON مجاز می‌باشد. اگر چنین اتفاقی بیفتد، آخرین رخداد یک پارامتر در یک حوزه معین استفاده می‌شود، در حالی که تمامی موارد پیشین نادیده گرفته می‌شوند. بعید است این موضوع سردرگمی ایجاد کند، چرا که در عمل دلیلی برای نگه‌داشتن چندین نسخه از یک پارامتر یکسان در فایل پیکربندی وجود ندارد. .sp چند مؤلفه نخست در پیکربندی DHCPv6 پارامترهایی سراسری (global) را تعریف می‌کنند. \fBvalid\-lifetime\fP مشخص می‌کند نشانی‌هایی (اجاره‌هایی یا leases) که توسط کارگزار واگذار می‌شوند تا چه مدت معتبر هستند؛ مقدار پیش‌فرض این است که کارخواه مجاز به استفاده از نشانی مشخص‌شده برای مدت ۴۰۰۰ ثانیه باشد. (توجه داشته باشید که اعداد صحیح به همان صورت و بدون هیچ‌گونه علامت نقل‌قول در اطرافشان مشخص می‌شوند.) این نشانی در ۳۰۰۰ ثانیه منسوخ (deprecated) خواهد شد؛ بدین معنا که کارخواه‌ها مجاز به حفظ اتصالات قدیمی هستند، اما نمی‌توانند از این نشانی برای ایجاد اتصالات جدید استفاده کنند. \fBrenew\-timer\fP و \fBrebind\-timer\fP مقادیری (همچنین به ثانیه) هستند که زمان‌سنج‌های T1 و T2 را تعریف می‌کنند؛ این زمان‌سنج‌ها تعیین می‌کنند چه زمانی کارخواه رویه‌های تجدید (renewal) و اتصال مجدد (rebind) را آغاز کند. .sp نگاشت \fBinterfaces\-config\fP رابط‌های شبکه‌ای را مشخص می‌کند که کارگزار باید روی آن‌ها به پیام‌های DHCP گوش فرا دهد. پارامتر \fBinterfaces\fP فهرستی از رابط‌های شبکه را تعیین می‌کند که کارگزار باید به آن‌ها گوش دهد. فهرست‌ها با براکت‌های مربعی باز و بسته می‌شوند و عناصر آن‌ها با کاما از یکدیگر جدا می‌گردند. برای گوش فرا دادن روی دو رابط، مؤلفه \fBinterfaces\-config\fP باید شبیه به این باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth0\(dq, \(dqeth1\(dq ] }, \&... } .EE .UNINDENT .UNINDENT .sp خطوط بعدی پایگاه‌داده اجاره (lease database) را تعریف می‌کنند؛ مکانی که کارگزار اطلاعات اجاره خود را در آن ذخیره می‌نماید. این مثال خاص به کارگزار می‌گوید از memfile استفاده کند که ساده‌ترین و سریع‌ترین زیرساخت (backend) پایگاه‌داده است. این زیرساخت از یک پایگاه‌داده درون‌حافظه‌ای بهره می‌برد و اجاره‌ها را روی دیسک در یک فایل CSV (مقادیر جداشده با کاما) ذخیره می‌کند. این یک مثال پیکربندی بسیار ساده است؛ معمولاً پیکربندی پایگاه‌داده اجاره مفصل‌تر بوده و شامل پارامترهای تکمیلی است. توجه داشته باشید که \fBlease\-database\fP یک شیء است و با استفاده از یک آکولاد باز، حوزه جدیدی باز می‌کند. پارامترهای آن (در این مثال تنها یک مورد: \fBtype\fP) در ادامه می‌آیند. اگر بیش از یک پارامتر وجود داشت، با کاما جدا می‌شدند. این حوزه با یک آکولاد بسته، پایان می‌یابد. از آنجا که پارامترهای بیشتری برای تعریف \fBDhcp6\fP در ادامه می‌آیند، یک کاما در انتهای آن قرار گرفته است. .sp در نهایت، باید فهرستی از زیرشبکه‌های (subnets) مربوط به IPv6 را تعریف کنیم. این مهم‌ترین ساختار پیکربندی DHCPv6 است، چرا که کارگزار از این اطلاعات برای پردازش درخواست‌های کارخواه‌ها استفاده می‌کند. این بخش تمامی زیرشبکه‌هایی را مشخص می‌کند که انتظار می‌رود کارگزار درخواست‌های DHCP را از آن‌ها دریافت کند. زیرشبکه‌ها با پارامتر \fBsubnet6\fP مشخص می‌شوند. این پارامتر یک فهرست است، بنابراین با براکت‌های مربعی آغاز شده و پایان می‌یابد. هر تعریف زیرشبکه در این فهرست دارای چندین صفت وابسته به خود است؛ بنابراین یک ساختار به شمار می‌رود و با آکولاد باز و بسته می‌شود. در کمترین حالت، تعریف یک زیرشبکه باید حداقل شامل دو پارامتر باشد: \fBsubnet\fP که کل زیرشبکه را تعریف می‌کند؛ و \fBpools\fP که فهرستی از استخرهای تخصیص‌یافته به صورت پویا است که توسط کارگزار DHCP اداره می‌شوند. .sp این مثال شامل یک زیرشبکه تکی است. در صورتی که بیش از یک مورد تعریف می‌شد، عناصر بیشتری در پارامتر \fBsubnet6\fP مشخص شده و با کاما از هم جدا می‌شدند. برای نمونه، جهت تعریف دو زیرشبکه، نحو (syntax) زیر به کار می‌رفت: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::/112\(dq } ], \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq }, { \(dqid\(dq: 2, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:2::1\-2001:db8:2::ffff\(dq } ], \(dqsubnet\(dq: \(dq2001:db8:2::/64\(dq } ], \&... } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که تورفتگی (indentation) اختیاری است و صرفاً به دلایل زیبایی‌شناختی استفاده می‌شود. در برخی موارد ممکن است ترجیح داده شود از قالب نشانه‌گذاری فشرده‌تری استفاده شود. .sp پس از آنکه تمام پارامترها مشخص شدند، دو زمینه (context) باز وجود دارد: \fBglobal\fP و \fBDhcp6\fP؛ از این رو، برای بستن آن‌ها باید از دو براکت مجعد بسته (آکولاد بسته) استفاده شود..SS ذخیره‌سازی اجاره‌ها (Lease Storage) .sp تمام اجاره‌های (leases) صادر شده توسط کارساز در پایگاه‌دادهٔ اجاره ذخیره می‌شوند. سه بک‌اند پایگاه‌داده در دسترس است: memfile (پیش‌فرض)، MySQL و PostgreSQL. .SS Memfile \- ذخیره‌سازی پایه‌ای برای اجاره‌ها (Memfile \- Basic Storage for Leases) .sp کارساز قادر است داده‌های اجاره را در مخازن مختلفی ذخیره کند. استقرارهای بزرگ‌تر ممکن است ذخیرهٔ اجاره‌ها در یک پایگاه‌داده را انتخاب کنند؛ بخش «پیکربندی پایگاه‌دادهٔ اجاره» (Lease Database Configuration) این گزینه را شرح می‌دهد. با این حال، در استقرارهای معمولی و کوچک‌تر، کارساز اطلاعات اجاره را به جای پایگاه‌داده در یک فایل CSV ذخیره می‌کند. علاوه بر نیاز به مدیریت کمتر، مزیت استفاده از فایل برای ذخیره‌سازی این است که وابستگی به نرم‌افزارهای پایگاه‌دادهٔ شخص ثالث را برطرف می‌سازد. .sp پیکربندی بک‌اند memfile از طریق پارامترهای \fBDhcp6\fP/\fBlease\-database\fP کنترل می‌شود. پارامتر \fBtype\fP اجباری است و از طریق مقدار \fB\(dqmemfile\(dq\fP مشخص می‌کند که کارساز باید از کدام محل ذخیره‌سازی برای اجاره‌ها استفاده کند. فهرست زیر پارامترهای اختیاری بیشتری را ارائه می‌دهد که می‌توان از آن‌ها برای پیکربندی بک‌اند memfile استفاده کرد. .INDENT 0.0 .IP \(bu 2 \fBpersist\fP: کنترل می‌کند که آیا اجاره‌های جدید و به‌روزرسانی‌های اجاره‌های موجود روی فایل نوشته شوند یا خیر. اکیداً توصیه می‌شود که در تمام طول کارکرد عادی کارساز، مقدار این پارامتر روی \fBtrue\fP تنظیم شده باشد. ننوشتن اجاره‌ها روی دیسک بدین معناست که اگر کارساز راه‌اندازی مجدد شود (مثلاً پس از قطع برق)، نخواهد دانست چه آدرس‌هایی واگذار شده‌اند. در نتیجه، ممکن است به کلاینت‌های جدید، آدرس‌هایی را تخصیص دهد که هم‌اکنون در حال استفاده هستند. مقدار \fBfalse\fP بیشتر برای اهداف آزمایش کارایی مفید است. مقدار پیش‌فرض پارامتر \fBpersist\fP برابر با \fBtrue\fP است که نوشتن به‌روزرسانی‌های اجاره در فایل اجاره را فعال می‌کند. .IP \(bu 2 \fBname\fP: فایل اجاره‌ای را که اجاره‌های جدید و به‌روزرسانی‌های اجاره در آن ثبت می‌شوند مشخص می‌کند. مقدار پیش‌فرض این پارامتر \fB\(dq[kea\-install\-dir]/var/lib/kea/kea\-leases6.csv\(dq\fP\& است. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 2.7.9 به بعد، فایل‌های اجاره تنها می‌توانند از دایرکتوری داده‌ای که در زمان کامپایل تعیین شده است بارگیری شوند: \fB\(dq[kea\-install\-dir]/var/lib/kea\(dq\fP\&. این مسیر را می‌توان در هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_DHCP_DATA_DIR\fP روی مسیر مورد نظر بازنویسی (override) کرد. اگر در \fBname\fP مسیری غیر از این مقدار استفاده شود، Kea خطایی صادر کرده و از شروع به کار خودداری می‌کند، یا اگر از قبل در حال اجرا باشد، یک خطای جبران‌ناپذیر را ثبت می‌کند. برای سهولت در مشخص کردن نام فایل سفارشی، کافی است بخش مسیر را از \fBname\fP حذف کنید. .UNINDENT .UNINDENT .INDENT 0.0 .IP \(bu 2 \fBlfc\-interval\fP: بازهٔ زمانی (به ثانیه) را تعیین می‌کند که کارساز در آن یک پاک‌سازی فایل اجاره (LFC) انجام می‌دهد. این فرآیند اطلاعات مازاد (تاریخچه‌ای) را از فایل اجاره حذف کرده و به‌طور مؤثری حجم فایل اجاره را کاهش می‌دهد. فرآیند پاک‌سازی در ادامهٔ همین بخش با جزئیات بیشتری شرح داده شده است. مقدار پیش‌فرض \fBlfc\-interval\fP برابر با \fB3600\fP است. مقدار \fB0\fP فرآیند LFC را غیرفعال می‌کند. .IP \(bu 2 \fBmax\-row\-errors\fP: تعداد خطاهای ردیف را پیش از این‌که کارساز تلاش برای بارگیری فایل اجاره را متوقف کند مشخص می‌کند. هنگامی که کارساز یک فایل اجاره را بارگیری می‌کند، آن را ردیف به ردیف پردازش می‌کند، که هر ردیف شامل یک اجارهٔ تکی است. اگر یک ردیف معیوب باشد و نتواند به درستی پردازش شود، کارساز آن را ثبت کرده، آن ردیف را نادیده می‌گیرد و به ردیف بعدی می‌رود. این پارامتر می‌تواند برای تعیین حد مجاز برای تعداد دفعات نادیده‌گرفته‌شدن ردیف‌ها استفاده شود، که پس از رسیدن به آن، کارساز تلاش را متوقف کرده و خارج می‌شود. مقدار پیش‌فرض \fB0\fP این محدودیت را غیرفعال کرده و به کارساز اجازه می‌دهد صرف‌نظر از این‌که چه تعداد ردیف نادیده گرفته می‌شوند، کل فایل را پردازش کند. .UNINDENT .sp یک نمونه پیکربندی از بک‌اند memfile در زیر آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqtype\(dq: \(dqmemfile\(dq, \(dqpersist\(dq: true, \(dqname\(dq: \(dqkea\-leases6.csv\(dq, \(dqlfc\-interval\(dq: 1800, \(dqmax\-row\-errors\(dq: 100 } } .EE .UNINDENT .UNINDENT .sp این پیکربندی \fBkea\-leases6.csv\fP را به عنوان فایل ذخیره‌سازی اطلاعات اجاره انتخاب کرده و پایایی (نوشتن به‌روزرسانی‌های اجاره روی این فایل) را فعال می‌کند. همچنین بک‌اند را طوری پیکربندی می‌کند که هر ۱۸۰۰ ثانیه (۳۰ دقیقه) یک‌بار پاک‌سازی دوره‌ای فایل اجاره را انجام دهد و حداکثر تعداد خطاهای ردیف را روی ۱۰۰ تنظیم می‌کند. .SS چرا پاک‌سازی فایل اجاره ضروری است؟ (Why Is Lease File Cleanup Necessary?) .sp برای درک این‌که چرا پاک‌سازی دوره‌ای فایل اجاره لازم است، دانستن نحوهٔ سازمان‌دهی محتویات فایل اجاره اهمیت دارد. هر بار که کارساز اجاره‌ای را به‌روزرسانی می‌کند یا اجارهٔ جدیدی برای یک کلاینت ایجاد می‌کند، اطلاعات اجارهٔ جدید باید در فایل اجاره ثبت شود. به دلایل کارایی، کارساز اجارهٔ فعلی کلاینت را در فایل به‌روزرسانی نمی‌کند، زیرا این کار می‌تواند مستلزم بازنویسی کل فایل باشد. در عوض، صرفاً اطلاعات اجارهٔ جدید را به انتهای فایل پیوست (append) می‌کند؛ مدخل‌های قبلی اجاره برای آن کلاینت حذف نمی‌شوند. هنگامی که کارساز اجاره‌ها را از فایل اجاره بارگیری می‌کند، مثلاً در هنگام راه‌اندازی کارساز، فرض می‌کند که آخرین مدخل اجاره برای کلاینت، مدخل معتبر است. مدخل‌های قبلی نادیده گرفته می‌شوند، بدین معنا که کارساز می‌تواند اطلاعات دقیقی را دربارهٔ اجاره‌ها بازسازی کند، حتی اگر مدخل‌های اجارهٔ متعددی برای هر کلاینت وجود داشته باشد. با این وجود، ذخیرهٔ مدخل‌های زیاد برای هر کلاینت منجر به حجیم شدن فایل اجاره شده و کارایی راه‌اندازی و پیکربندی مجدد کارساز را دچار اختلال می‌کند، زیرا ناچار است تعداد بیشتری از مدخل‌های اجاره را پردازش کند. .sp پاک‌سازی فایل اجاره (LFC) تمام مدخل‌های پیشین مربوط به هر کلاینت را حذف کرده و تنها آخرین مدخل‌ها را نگه می‌دارد. بازهٔ زمانی اجرای پاک‌سازی قابل پیکربندی است و باید متناسب با بسامد تمدیدهای اجاره که از سوی کلاینت‌ها آغاز می‌شود انتخاب گردد. هرچه تمدیدها مکررتر باشند، مقدار \fBlfc\-interval\fP باید کوچک‌تر باشد. با این حال، توجه داشته باشید که LFC زمان‌بر است و بنابراین این احتمال (هرچند بعید) وجود دارد که اگر \fBlfc\-interval\fP بیش از حد کوتاه باشد، یک پاک‌سازی جدید در حالی آغاز شود که پاک‌سازی قبلی هنوز در حال اجراست. کارساز در صورت تشخیص این‌که پاک‌سازی پیشین هنوز در جریان است، با صرف‌نظر کردن از پاک‌سازی جدید این موضوع را مدیریت می‌کند، اما این بدان معناست که پاک‌سازی‌های واقعی با فواصلی طولانی‌تر از بازهٔ تنظیم‌شده اجرا خواهند شد. علاوه بر این، راه‌اندازی یک فرآیند پاک‌سازی جدید سرباری به کارساز اضافه می‌کند که باعث می‌شود در بازهٔ زمانی کوتاهی که فرآیند پاک‌سازی جدید ایجاد (spawn) می‌شود، قادر به پاسخگویی به درخواست‌های جدید نباشد. بنابراین، توصیه می‌شود که مقدار \fBlfc\-interval\fP به گونه‌ای انتخاب شود که به LFC اجازه دهد پیش از شروع یک پاک‌سازی جدید، کار خود را به پایان برساند. .sp پاک‌سازی فایل اجاره توسط یک فرآیند مجزا (در پس‌زمینه) انجام می‌شود تا از تأثیر منفی بر کارایی فرآیند کارساز جلوگیری گردد. برای جلوگیری از تداخل میان دو فرآیند که از فایل‌های اجارهٔ یکسانی استفاده می‌کنند، فرآیند LFC با باز کردن یک فایل اجارهٔ جدید توسط Kea آغاز می‌شود؛ فرآیند واقعی LFC روی فایل اجاره‌ای کار می‌کند که دیگر توسط کارساز استفاده نمی‌شود. همچنین فایل‌های دیگری نیز به عنوان اثر جانبی پاک‌سازی فایل اجاره ایجاد می‌شوند. شرح تفصیلی فرآیند LFC در ادامهٔ این کتابچهٔ راهنمای مدیران Kea آورده شده است: فرآیند LFC \%<#\:kea-lfc>\&..SS پیکربندی پایگاه دادهٔ اجاره (Lease Database Configuration) .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اطلاعات دسترسی به پایگاه دادهٔ اجاره باید برای کارگزار DHCPv6 پیکربندی شود، حتی اگر پیش‌تر برای کارگزار DHCPv4 پیکربندی شده باشد. این کارگزارها اطلاعات خود را به طور مستقل ذخیره می‌کنند، بنابراین هر کارگزار می‌تواند از یک پایگاه دادهٔ جداگانه استفاده کند یا هر دو کارگزار می‌توانند از همان پایگاه دادهٔ یکسان استفاده نمایند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برنامهٔ Kea نیازمند آن است که منطقهٔ زمانی پایگاه داده با منطقهٔ زمانی سیستم همخوانی داشته باشد. برای جزئیات بیشتر، بخش «First\-Time Creation of the MySQL Database» \%<#\:mysql-database-create> و «First\-Time Creation of the PostgreSQL Database» \%<#\:pgsql-database-create>\& را ببینید. .UNINDENT .UNINDENT .sp پیکربندی پایگاه دادهٔ اجاره از طریق پارامترهای \fBDhcp6\fP/\fBlease\-database\fP کنترل می‌شود. نوع پایگاه داده باید روی \fBmemfile\fP، \fBmysql\fP یا \fBpostgresql\fP تنظیم شود؛ برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqtype\(dq: \(dqmysql\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp سپس، نام پایگاه داده‌ای که برای نگهداری اجاره‌ها استفاده می‌شود باید تعیین گردد؛ این همان نامی است که هنگام ایجاد پایگاه داده استفاده شده است (بخش «First\-Time Creation of the MySQL Database» \%<#\:mysql-database-create> یا «First\-Time Creation of the PostgreSQL Database» \%<#\:pgsql-database-create> را ببینید). .sp برای MySQL یا PostgreSQL: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqname\(dq: \(dqdatabase\-name\(dq , ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر پایگاه داده روی سیستمی متفاوت از کارگزار DHCPv6 قرار دارد، نام میزبان پایگاه داده نیز باید مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqhost\(dq: \(dqremote\-host\-name\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp به‌طور معمول، پایگاه داده روی همان ماشینی است که کارگزار DHCPv6 قرار دارد. در این حالت، مقدار را روی یک رشتهٔ خالی تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqhost\(dq : \(dq\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp در صورتی که پایگاه داده از درگاهی غیر از درگاه پیش‌فرض استفاده کند، آن نیز می‌تواند مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqport\(dq : 12345, ... }, ... } .EE .UNINDENT .UNINDENT .sp در صورتی که پایگاه داده روی سیستم دیگری قرار داشته باشد، ممکن است مدیر سیستم نیاز به تعیین بازهٔ طولانی‌تری برای مهلت زمانی اتصال (timeout) داشته باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqconnect\-timeout\(dq : timeout\-in\-seconds, ... }, ... } .EE .UNINDENT .UNINDENT .sp مقدار پیش‌فرضِ پنج ثانیه باید برای اتصالات محلی بیش از حد کافی باشد. هرچند اگر یک مهلت زمانی تعیین شود، باید یک عدد صحیح بزرگ‌تر از صفر باشد. .sp حداکثر دفعاتی که کارگزار پس از قطع اتصال به طور خودکار برای اتصال مجدد به پایگاه دادهٔ اجاره تلاش می‌کند، می‌تواند مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqmax\-reconnect\-tries\(dq : number\-of\-tries, ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر کارگزار پس از انجام حداکثر دفعات تلاش نتواند دوباره به پایگاه داده متصل شود، خارج خواهد شد. مقدار 0 (پیش‌فرض) بازیابی خودکار را غیرفعال می‌کند و کارگزار بلافاصله پس از تشخیص قطع اتصال، خارج می‌شود (تنها در MySQL و PostgreSQL). .sp تعداد میلی‌ثانیه‌هایی که کارگزار پس از قطع اتصال، بین تلاش‌ها برای اتصال مجدد به پایگاه دادهٔ اجاره منتظر می‌ماند نیز می‌تواند مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqreconnect\-wait\-time\(dq : number\-of\-milliseconds, ... }, ... } .EE .UNINDENT .UNINDENT .sp مقدار پیش‌فرض برای MySQL و PostgreSQL برابر با 0 است که بازیابی خودکار را غیرفعال کرده و باعث می‌شود کارگزار بلافاصله پس از تشخیص قطع اتصال خارج شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqon\-fail\(dq : \(dqstop\-retry\-exit\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp مقادیر ممکن عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBstop\-retry\-exit\fP \- سرویس DHCP را هنگام تلاش برای بازیابی خودکار اتصالات قطع‌شده غیرفعال می‌کند، و پس از اتمام \fBmax\-reconnect\-tries\fP در صورت عدم موفقیت، کارگزار را خاموش می‌کند. این مقدار پیش‌فرض برای بک‌اند اجاره، بک‌اند میزبان و بک‌اند پیکربندی است. .IP \(bu 2 \fBserve\-retry\-exit\fP \- هنگام تلاش برای بازیابی خودکار اتصالات قطع‌شده، به سرویس‌دهی DHCP ادامه می‌دهد و پس از اتمام \fBmax\-reconnect\-tries\fP در صورت عدم موفقیت، کارگزار را خاموش می‌کند. .IP \(bu 2 \fBserve\-retry\-continue\fP \- به سرویس‌دهی DHCP ادامه می‌دهد و حتی اگر بازیابی با شکست مواجه شود، کارگزار را خاموش نمی‌کند. این مقدار پیش‌فرض برای ثبت وقایع قانونی (forensic logging) است. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اتصال مجدد خودکار به بک‌اندهای پایگاه داده به طور جداگانه برای هر بک‌اند پیکربندی می‌شود؛ این قابلیت به کاربران اجازه می‌دهد تا پارامترهای بازیابی را متناسب با هر بک‌اندی که استفاده می‌کنند تنظیم کنند. ما پیشنهاد می‌کنیم که کاربران آن را یا برای همهٔ بک‌اندها فعال کنند یا برای هیچ‌کدام، تا رفتار سیستم سازگار و یکدست باشد. .sp قطع اتصال با بک‌اندی که اتصال مجدد برای آن غیرفعال است (در صورت پیکربندی)، منجر به خاموش شدن خودکار کارگزار می‌شود. این شامل مواردی نیز می‌شود که بک‌اند پایگاه دادهٔ اجاره و بک‌اند پایگاه دادهٔ میزبان‌ها به یک نمونهٔ پایگاه دادهٔ یکسان متصل باشند. .sp اکیداً توصیه می‌شود که تنظیم پیش‌فرض \fBstop\-retry\-exit\fP را برای مدیریت اجاره (lease manager) تغییر ندهید، چرا که فعال بودن اتصال در زمان پردازش ترافیک DHCP امری حیاتی است. این مورد را تنها در صورتی تغییر دهید که از کارگزار منحصراً به عنوان یک ابزار پیکربندی استفاده شود. .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqretry\-on\-startup\(dq : true, ... }, ... } .EE .UNINDENT .UNINDENT .sp هنگام راه‌اندازی کارگزار، ناتوانی در اتصال به هر یک از بک‌اندهای پیکربندی‌شده تنها در صورتی مهلک (fatal) تلقی می‌شود که \fBretry\-on\-startup\fP روی \fBfalse\fP (پیش‌فرض) تنظیم شده باشد. یک خطای مهلک در گزارش ثبت می‌شود و کارگزار خارج می‌شود، بر این مبنا که پیکربندی باید در زمان راه‌اندازی معتبر باشد. خروج به سیستم‌عامل این امکان را به اسکریپت‌های نظارتی (nanny scripts) می‌دهد تا مشکل را تشخیص دهند. اگر \fBretry\-on\-startup\fP روی \fBtrue\fP تنظیم شود، کارگزار تلاش‌ها برای برقراری مجدد اتصال را حتی در زمان راه‌اندازی اولیه یا هنگام رویدادهای بازپیکربندی آغاز می‌کند و به عملیات مشخص‌شده در پارامتر \fBon\-fail\fP عمل می‌نماید. .sp پارامتر host توسط بک‌اندهای MySQL و PostgreSQL استفاده می‌شود. .sp در نهایت، اطلاعات احراز هویت حسابی که کارگزار تحت آن به پایگاه داده دسترسی خواهد داشت باید تنظیم شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dquser\(dq: \(dquser\-name\(dq, \(dqpassword\(dq: \(dq1234\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر گذرواژه‌ای برای حساب وجود ندارد، گذرواژه را روی یک رشتهٔ خالی \fB\(dq\(dq\fP تنظیم کنید. (این مقدار پیش‌فرض است.).SS تنظیم مهلت‌های زمانی پایگاه داده (Tuning Database Timeouts) .sp در موارد نادری، خواندن از پایگاه داده یا نوشتن در آن ممکن است متوقف شود (hang کند). این وضعیت می‌تواند به دلیل یک مشکل موقت شبکه یا پیکربندی نادرست سرور پراکسی باشد که اتصال را بین نمونه‌های مختلف پایگاه داده جابه‌جا می‌کند. این شرایط نادر هستند، اما کاربران گزارش کرده‌اند که Kea گاهی اوقات هنگام انجام عملیات I/O پایگاه داده معلق می‌شود. تنظیم مقادیر مهلت زمانی (timeout) مناسب می‌تواند چنین مشکلاتی را کاهش دهد. .sp پایگاه‌داده MySQL دو گزینه اتصال متمایز را برای پیکربندی مهلت‌های زمانی خواندن و نوشتن ارائه می‌دهد. پارامترهای پیکربندی متناظر Kea یعنی \fBread\-timeout\fP و \fBwrite\-timeout\fP این مهلت‌های زمانی را بر حسب ثانیه مشخص می‌کنند. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqread\-timeout\(dq : 10, \(dqwrite\-timeout\(dq: 20, ... }, ... } .EE .UNINDENT .UNINDENT .sp تنظیم این پارامترها روی 0 معادل مشخص نکردن آن‌ها است و باعث می‌شود سرور Kea با مقادیر پیش‌فرض MySQL اتصالی به پایگاه داده برقرار کند. در این حالت، Kea به مدت نامحدود منتظر تکمیل عملیات خواندن و نوشتن می‌ماند. .sp نسخه‌های MySQL قدیمی‌تر از 5.6 از تنظیم مهلت زمانی برای عملیات خواندن و نوشتن پشتیبانی نمی‌کنند. علاوه بر این، پارامترهای \fBread\-timeout\fP و \fBwrite\-timeout\fP تنها برای بک‌اند MySQL قابل تعریف هستند؛ تنظیم آن‌ها برای هر نوع پایگاه داده بک‌اند دیگری موجب خطای پیکربندی می‌شود. .sp برای تنظیم مهلت زمانی بر حسب ثانیه برای PostgreSQL، از پارامتر \fBtcp\-user\-timeout\fP استفاده کنید. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqlease\-database\(dq: { \(dqtcp\-user\-timeout\(dq : 10, ... }, ... } .EE .UNINDENT .UNINDENT .sp مشخص کردن این پارامتر برای سایر انواع بک‌اند باعث خطای پیکربندی می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مهلت‌های زمانی شرح داده شده در اینجا فقط برای اتصالات TCP مؤثر هستند. لطفاً توجه داشته باشید که کتابخانه کلاینت MySQL مورد استفاده توسط سرورهای Kea معمولاً هنگامی که پارامتر \fBhost\fP مقدار \fBlocalhost\fP باشد از طریق سوکت دامنه یونیکس (UNIX domain socket) به پایگاه داده متصل می‌شود، اما برای \fB127.0.0.1\fP یک اتصال TCP برقرار می‌کند\&. .UNINDENT .UNINDENT .sp از نسخه 2.7.4 نرم‌افزار Kea به بعد، کتابخانه قلاب (hook library) به نام libdhcp_mysql.so باید بارگذاری شود تا اجاره‌ها در بک‌اند پایگاه داده اجاره MySQL ذخیره شوند. مکان کتابخانه قلاب بک‌اند اجاره را مشخص کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { // the MySQL lease backend hook library required for lease storage. \(dqlibrary\(dq: \(dqlibdhcp_mysql.so\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp از نسخه 2.7.4 نرم‌افزار Kea به بعد، کتابخانه قلاب libdhcp_pgsql.so باید بارگذاری شود تا اجاره‌ها در بک‌اند پایگاه داده اجاره PostgreSQL ذخیره شوند. مکان کتابخانه قلاب بک‌اند اجاره را مشخص کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { // the PostgreSQL lease backend hook library required for lease storage. \(dqlibrary\(dq: \(dqlibdhcp_pgsql.so\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .SS ذخیره‌سازی میزبان‌ها (Hosts Storage) .sp همچنین Kea قادر است اطلاعات مربوط به رزروهای میزبان (host reservations) را در پایگاه داده ذخیره کند. پیکربندی پایگاه داده میزبان‌ها از همان ساختار نحوی پایگاه داده اجاره‌ها استفاده می‌کند. در حقیقت، سرور Kea برای هر منظور، خواه اطلاعات اجاره باشد یا اطلاعات میزبان‌ها، اتصالات مستقلی باز می‌کند که این امر بالاترین انعطاف‌پذیری را فراهم می‌سازد. Kea می‌تواند اجاره‌ها و رزروهای میزبان را به طور جداگانه نگهداری کند، اما می‌تواند به همان پایگاه داده مشترک نیز اشاره نماید. در حال حاضر انواع پایگاه‌های داده پشتیبانی‌شده برای میزبان‌ها MySQL و PostgreSQL هستند. .sp پیکربندی زیر می‌تواند برای تنظیم اتصال به MySQL استفاده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqtype\(dq: \(dqmysql\(dq, \(dqname\(dq: \(dqkea\(dq, \(dquser\(dq: \(dqkea\(dq, \(dqpassword\(dq: \(dq1234\(dq, \(dqhost\(dq: \(dqlocalhost\(dq, \(dqport\(dq: 3306 } } .EE .UNINDENT .UNINDENT .sp بسته به پیکربندی پایگاه داده، بسیاری از این پارامترها ممکن است اختیاری باشند. .sp لطفاً توجه داشته باشید که استفاده از ذخیره‌سازی میزبان‌ها اختیاری است. کاربر می‌تواند تمام رزروهای میزبان را درون فایل پیکربندی تعریف کند، و در صورتی که تعداد رزروها کم باشد این روش پیشنهادی است. با این حال، هنگامی که تعداد رزروها افزایش می‌یابد، استفاده از ذخیره‌سازی پایگاه داده میزبان‌ها راحت‌تر خواهد بود. لطفاً توجه داشته باشید که هر دو روش ذخیره‌سازی (فایل پیکربندی و یکی از پایگاه‌های داده پشتیبانی‌شده) می‌توانند به صورت همزمان استفاده شوند. اگر میزبان‌ها در هر دو مکان تعریف شده باشند، ابتدا تعاریف فایل پیکربندی بررسی می‌شوند و در صورت نیاز، فضای ذخیره‌سازی خارجی بعداً بررسی خواهد شد. .sp اطلاعات میزبان می‌تواند در چندین مخزن ذخیره‌سازی قرار گیرد. عملیات‌ها روی مخازن بر اساس همان ترتیبی که در فایل پیکربندی تعریف شده‌اند انجام می‌پذیرد، هرچند این موضوع در صورت افزودن یک رزرو میزبان به محدودیتی در اولویت‌بندی منجر می‌شود؛ مخازن فقط‌خواندنی (read\-only) باید حتماً بعد از یک مخزن خواندنی\-نوشتنی (read\-write) پیکربندی شوند، در غیر این صورت عملیات افزودن با خطا مواجه خواهد شد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نرم‌افزار Kea مستلزم آن است که منطقه زمانی (timezone) پایگاه داده با منطقه زمانی سیستم یکسان باشد. برای جزئیات بیشتر، به بخش‌های First\-Time Creation of the MySQL Database \%<#\:mysql-database-create> و First\-Time Creation of the PostgreSQL Database \%<#\:pgsql-database-create>\& مراجعه کنید. .UNINDENT .UNINDENT.SS پیکربندی پایگاه‌داده میزبان‌های DHCPv6 .sp پیکربندی پایگاه‌داده میزبان‌ها از طریق پارامترهای \fBDhcp6\fP/\fBhosts\-database\fP کنترل می‌شود. در صورت فعال بودن، نوع پایگاه‌داده باید بر روی \fBmysql\fP یا \fBpostgresql\fP تنظیم شود\&. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqtype\(dq: \(dqmysql\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp سپس، نام پایگاه‌داده‌ای که رزروها را نگه‌داری می‌کند باید تنظیم شود؛ این همان نامی است که هنگام ایجاد پایگاه‌داده اجاره‌ها استفاده شده است (برای دستورالعمل‌های نحوه راه‌اندازی نوع پایگاه‌داده مورد نظر، به بخش پشتیبان‌های پشتیبانی‌شده \%<#\:supported-databases> مراجعه کنید): .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqname\(dq: \(dqdatabase\-name\(dq , ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر پایگاه‌داده بر روی سامانه‌ای غیر از کارگزار DHCPv6 قرار دارد، نام میزبان پایگاه‌داده نیز باید مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqhost\(dq: remote\-host\-name, ... }, ... } .EE .UNINDENT .UNINDENT .sp به طور معمول، پایگاه‌داده روی همان ماشین کارگزار DHCPv6 قرار دارد. در این حالت، مقدار را روی یک رشته خالی تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqhost\(dq : \(dq\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp در صورتی که پایگاه‌داده از درگاهی به غیر از درگاه پیش‌فرض استفاده می‌کند، می‌توان آن را نیز مشخص کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqport\(dq : 12345, ... }, ... } .EE .UNINDENT .UNINDENT .sp حداکثر دفعاتی که کارگزار پس از قطع اتصال به طور خودکار برای اتصال مجدد به پایگاه‌داده میزبان تلاش می‌کند را می‌توان مشخص کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqmax\-reconnect\-tries\(dq : number\-of\-tries, ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر کارگزار پس از انجام حداکثر دفعات تلاش قادر به اتصال مجدد به پایگاه‌داده نباشد، کارگزار خارج خواهد شد. مقدار 0 (پیش‌فرض) بازیابی خودکار را غیرفعال می‌کند و کارگزار بلافاصله پس از تشخیص قطع اتصال خارج می‌شود (تنها در MySQL و PostgreSQL). .sp مدت‌زمانی که کارگزار بین تلاش‌ها برای اتصال مجدد به پایگاه‌داده میزبان پس از قطع اتصال منتظر می‌ماند را نیز می‌توان بر حسب میلی‌ثانیه مشخص کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqreconnect\-wait\-time\(dq : number\-of\-milliseconds, ... }, ... } .EE .UNINDENT .UNINDENT .sp مقدار پیش‌فرض برای MySQL و PostgreSQL برابر با 0 است که بازیابی خودکار را غیرفعال کرده و باعث می‌شود کارگزار بلافاصله پس از تشخیص قطع اتصال خارج شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqon\-fail\(dq : \(dqstop\-retry\-exit\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp مقادیر مجاز عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBstop\-retry\-exit\fP \- سرویس DHCP را در هنگام تلاش برای بازیابی خودکار اتصالات قطع‌شده غیرفعال می‌کند. در صورت عدم موفقیت پس از اتمام \fBmax\-reconnect\-tries\fP، کارگزار را خاموش می‌کند. این مقدار پیش‌فرض برای MySQL و PostgreSQL است. .IP \(bu 2 \fBserve\-retry\-exit\fP \- سرویس‌دهی DHCP را در حین تلاش برای بازیابی خودکار اتصالات قطع‌شده ادامه می‌دهد. در صورت عدم موفقیت پس از اتمام \fBmax\-reconnect\-tries\fP، کارگزار را خاموش می‌کند. .IP \(bu 2 \fBserve\-retry\-continue\fP \- سرویس‌دهی DHCP را ادامه می‌دهد و حتی در صورت شکست بازیابی نیز کارگزار را خاموش نمی‌کند. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اتصال مجدد خودکار به پشتیبان‌های پایگاه‌داده به طور جداگانه برای هر پشتیبان پیکربندی می‌شود. این امر به کاربران امکان می‌دهد پارامترهای بازیابی را متناسب با هر پشتیبانی که استفاده می‌کنند تنظیم کنند. پیشنهاد می‌کنیم کاربران آن را برای همه پشتیبان‌ها فعال کرده یا برای هیچ‌کدام فعال نکنند تا رفتار سامانه یکدست باشد. .sp از دست رفتن اتصال به پشتیبانی که اتصال مجدد برای آن غیرفعال است (در صورت پیکربندی) منجر به خاموش شدن خودکار کارگزار می‌شود. این شامل مواردی نیز می‌شود که پشتیبان پایگاه‌داده اجاره‌ها و پشتیبان پایگاه‌داده میزبان‌ها به یک نمونه پایگاه‌داده یکسان متصل باشند. .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqretry\-on\-startup\(dq : true, ... }, ... } .EE .UNINDENT .UNINDENT .sp در زمان راه‌اندازی کارگزار، ناتوانی در اتصال به هر یک از پشتیبان‌های پیکربندی‌شده تنها در صورتی یک خطای مهلک در نظر گرفته می‌شود که \fBretry\-on\-startup\fP بر روی \fBfalse\fP (پیش‌فرض) تنظیم شده باشد. یک خطای مهلک در گزارش‌ها ثبت شده و کارگزار خارج می‌شود، بر پایه این رویکرد که پیکربندی در زمان راه‌اندازی باید معتبر باشد. خروج به سیستم‌عامل به اسکریپت‌های ناظر اجازه می‌دهد تا مشکل را تشخیص دهند. اگر \fBretry\-on\-startup\fP بر روی \fBtrue\fP تنظیم شود، کارگزار حتی هنگام راه‌اندازی یا در زمان رخدادهای بازپیکربندی نیز تلاش‌های اتصال مجدد را آغاز کرده و رفتار مشخص‌شده در پارامتر \fBon\-fail\fP را به کار می‌بندد. .sp در نهایت، اعتبارنامه‌های حسابی که کارگزار با استفاده از آن به پایگاه‌داده دسترسی خواهد داشت باید مشخص شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dquser\(dq: \(dquser\-name\(dq, \(dqpassword\(dq: \(dq1234\(dq, ... }, ... } .EE .UNINDENT .UNINDENT .sp اگر حساب کاربری گذرواژه‌ای ندارد، گذرواژه را روی رشته خالی \fB\(dq\(dq\fP تنظیم کنید\&. (این مقدار پیش‌فرض است.) .sp افزونه چندذخیره‌سازی از ساختار مشابهی استفاده می‌کند؛ با این تفاوت که پیکربندی به جای یک مدخل \fBhosts\-database\fP، درون یک فهرست \fBhosts\-databases\fP قرار می‌گیرد، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-databases\(dq: [ { \(dqtype\(dq: \(dqmysql\(dq, ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp اگر میزبانی به صورت هم‌زمان هم درون فایل و هم درون پایگاه‌داده پیکربندی شده باشد، Kea هیچ هشداری صادر نمی‌کند؛ برخلاف وضعیتی که هر دو در یک منبع داده یکسان تعریف شده باشند. در عوض، میزبانی که درون فایل پیکربندی شده است، نسبت به میزبان پیکربندی‌شده در پایگاه‌داده اولویت دارد..SS استفاده از پایگاه‌های داده فقط\-خواندنی برای رزروهای میزبان با DHCPv6 .sp در برخی استقرارها، کاربری که نام آن در پیکربندی backend پایگاه داده مشخص شده است، ممکن است دسترسی نوشتن به پایگاه داده را نداشته باشد. این موضوع اغلب بر اساس سیاست‌های درون یک شبکه برای محافظت از داده‌ها در برابر تغییرات ناخواسته الزامی است. در بسیاری از موارد مدیران سیستم پایگاه‌های داده موجودی (inventory) را مستقر کرده‌اند که حاوی اطلاعات بسیار بیشتری درباره میزبان‌ها نسبت به صرفاً رزروهای ایستا اختصاص‌یافته به آن‌ها است. از پایگاه داده موجودی می‌توان برای ایجاد یک نما (view) از پایگاه داده میزبان‌های Kea استفاده کرد و چنین نمایی اغلب به‌صورت فقط\-خواندنی است. .sp بخش‌های backend پایگاه داده میزبان Kea با یک پیکربندی ضمنی برای خواندن و نوشتن در پایگاه داده عمل می‌کنند. اگر کاربر دسترسی نوشتن به پایگاه داده میزبان را نداشته باشد، backend در راه‌اندازی شکست می‌خورد و سرور از شروع به‌کار (یا بازپیکربندی) خودداری می‌کند. با این حال، اگر دسترسی به یک پایگاه داده میزبانِ فقط\-خواندنی جهت بازیابی رزروها برای کلاینت‌ها و/یا تخصیص آدرس‌ها و گزینه‌های خاص نیاز باشد، می‌توان Kea را صراحتاً برای شروع در حالت \(dqread\-only\(dq پیکربندی کرد. این عمل توسط پارامتر بولی \fBreadonly\fP به صورت زیر کنترل می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhosts\-database\(dq: { \(dqreadonly\(dq: true, ... }, ... } .EE .UNINDENT .UNINDENT .sp تنظیم این پارامتر روی \fBfalse\fP، پایگاه داده backend را برای کار در حالت \(dqread\-write\(dq پیکربندی می‌کند، که در صورت تعیین نشدن پارامتر، پیکربندی پیش‌فرض نیز همین است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پارامتر \fBreadonly\fP تنها برای پایگاه‌های داده MySQL و PostgreSQL پشتیبانی می‌شود. .UNINDENT .UNINDENT .sp از نسخه Kea.2.7.4، کتابخانه قلاب libdhcp_mysql.so باید بارگیری شود تا رزروهای میزبان در backend پایگاه داده میزبان MySQL ذخیره شوند. مکان کتابخانه قلاب backend اجاره (lease) را مشخص کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { // the MySQL host backend hook library required for host storage. \(dqlibrary\(dq: \(dqlibdhcp_mysql.so\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp از نسخه Kea.2.7.4، کتابخانه قلاب libdhcp_pgsql.so باید بارگیری شود تا رزروهای میزبان در backend پایگاه داده میزبان PostgreSQL ذخیره شوند. مکان کتابخانه قلاب backend اجاره را مشخص کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { // the PostgreSQL host backend hook library required for host storage. \(dqlibrary\(dq: \(dqlibdhcp_pgsql.so\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .SS تنظیم مهلت‌های زمانی پایگاه داده برای ذخیره‌سازی میزبان‌ها .sp بخش Tuning Database Timeouts\& را ببینید. .SS پیکربندی رابط‌ها .sp سرور DHCPv6 باید برای شنود روی رابط‌های شبکه مشخصی پیکربندی شود. ساده‌ترین پیکربندی رابط شبکه به سرور می‌گوید روی تمام رابط‌های در دسترس شنود کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dq*\(dq ] }, ... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 ‏Kea به‌طور پیش‌فرض روی آدرس‌های عمومی IPv6 شنود نمی‌کند. برای فعال‌سازی ترافیک تک‌پخشی (unicast) بخش Unicast Traffic Support\& را ببینید. .UNINDENT .UNINDENT .sp نویسه ستاره نقش نویسه عمومی (wildcard) را بازی می‌کند و به معنای \(dqشنود روی تمام رابط‌ها\(dq است. با این حال، معمولاً بهتر است نام‌های رابط‌ها صراحتاً مشخص شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq ] }, ... } .EE .UNINDENT .UNINDENT .sp امکان استفاده از نویسه عمومی رابط (*) به‌طور هم‌زمان با نام‌های صریح رابط‌ها وجود دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq, \(dq*\(dq ] }, ... } .EE .UNINDENT .UNINDENT .sp این قالب تنها زمانی باید استفاده شود که نیاز باشد موقتاً فهرست نام رابط‌ها نادیده گرفته شده و روی تمام رابط‌ها شنود انجام شود. .sp همانند سرور DHCPv4، اتصال به آدرس‌های خاص و غیرفعال‌سازی تشخیص مجدد رابط‌ها پشتیبانی می‌شود. اما \fBdhcp\-socket\-type\fP پشتیبانی نمی‌شود، زیرا DHCPv6 تنها از سوکت‌های UDP/IPv6 استفاده می‌کند. .sp رابط‌ها در هر بار پیکربندی مجدد دوباره شناسایی می‌شوند. این رفتار را می‌توان با تنظیم مقدار \fBre\-detect\fP روی \fBfalse\fP غیرفعال کرد، برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq ], \(dqre\-detect\(dq: false }, ... } .EE .UNINDENT .UNINDENT .sp سازوکار شناسایی مجدد معمولاً رابط‌های شناسایی‌شده قبلی را حذف کرده و سپس تمام رابط‌های شناسایی‌شده فعلی را اضافه می‌کند. توجه داشته باشید که هنگام اجرای دستورهای \fBconfig\-test\fP \%<#\:std-isccmd-config-test> یا \fBconfig\-set\fP \%<#\:std-isccmd-config-set> رابط‌ها دوباره شناسایی نمی‌شوند. با این حال، رابط‌های جدید شناسایی می‌شوند و برای استفاده توسط پیکربندی جدیدِ ارسال‌شده به دستورهای \fBconfig\-test\fP \%<#\:std-isccmd-config-test> و \fBconfig\-set\fP \%<#\:std-isccmd-config-set> در دسترس خواهند بود. .sp رابط‌های لوپ‌بک (مانند رابط \fBlo\fP یا \fBlo0\fP) به‌طور پیش‌فرض پیکربندی نمی‌شوند، مگر اینکه صراحتاً در پیکربندی ذکر شوند. توجه داشته باشید که Kea به یک آدرس پیوند\-محلی (link\-local) (که در همه سیستم‌ها وجود ندارد) یا یک آدرس مشخص تک‌پخشی (unicast) نیاز دارد، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqenp0s2/2001:db8::1234:abcd\(dq ] }, ... } .EE .UNINDENT .UNINDENT .sp ‏Kea در هنگام راه‌اندازی، سوکت‌های سرویس را برای هر رابط مقیدسازی (bind) می‌کند. اگر فرایند دیگری قبلاً از یک درگاه (port) استفاده کرده باشد، Kea پیام را در لاگ ثبت کرده و از بروز خطا جلوگیری می‌کند. سرویس DHCP اجرا می‌شود، اما روی برخی رابط‌ها در دسترس نخواهد بود. .sp گزینه \(dqservice\-sockets\-require\-all\(dq باعث می‌شود Kea نیاز داشته باشد که تمام سوکت‌ها با موفقیت مقید شوند. اگر باز کردن هر سوکتی با شکست مواجه شود، Kea فرایند مقداردهی اولیه را قطع کرده و با یک وضعیت غیرصفر خارج می‌شود. (پیش‌فرض false است). .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq ], \(dqservice\-sockets\-require\-all\(dq: true }, ... } .EE .UNINDENT .UNINDENT .sp گاهی اوقات، قطع فوری فرایند انتخاب مناسبی نیست. درگاه ممکن است تنها موقتاً در دسترس نباشد. در این حالت، تلاش مجدد برای باز کردن ممکن است مشکل را حل کند. Kea دو گزینه را برای تعیین تلاش مجدد فراهم می‌کند: \fBservice\-sockets\-max\-retries\fP و \fBservice\-sockets\-retry\-wait\-time\fP\&. .sp گزینه نخست حداکثر تعداد تلاش‌های مجددی را تعیین می‌کند که Kea برای باز کردن یک سوکت انجام می‌دهد. مقدار صفر (پیش‌فرض) بدین معناست که Kea فرایند را دوباره تلاش نمی‌کند. .sp گزینه دوم زمان انتظار (به میلی‌ثانیه) بین تلاش‌ها را تعیین می‌کند. مقدار پیش‌فرض 5000 (۵ ثانیه) است. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq, \(dqeth3\(dq ], \(dqservice\-sockets\-max\-retries\(dq: 5, \(dqservice\-sockets\-retry\-wait\-time\(dq: 5000 }, ... } .EE .UNINDENT .UNINDENT .sp اگر \(dqservice\-sockets\-max\-retries\(dq غیرصفر باشد و \(dqservice\-sockets\-require\-all\(dq برابر با false باشد، آن‌گاه Kea باز کردن را (در صورت نیاز) دوباره تلاش می‌کند اما در صورتی که هر سوکتی همچنان باز نشده باشد با شکست مواجه نمی‌شود..SS شناسه زیرشبکه IPv6 (IPv6 Subnet Identifier) .sp شناسه زیرشبکه (subnet ID) عددی یکتا است که به یک زیرشبکه خاص اختصاص می‌یابد. در اصل، این شناسه برای مرتبط ساختن اجاره‌های (leases) کارخواه‌ها با زیرشبکه‌های مربوطه‌شان به کار می‌رود. پیکربندی کارساز باید شامل شناسه‌های یکتا و پایداری برای تمام زیرشبکه‌ها باشد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 شناسه‌های زیرشبکه باید بزرگ‌تر از صفر و کوچک‌تر از 4294967295 باشند. .UNINDENT .UNINDENT .sp پیکربندی زیر شناسه زیرشبکه مشخص‌شده را به یک زیرشبکه تازه پیکربندی‌شده تخصیص می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqid\(dq: 1024, ... } ] } .EE .UNINDENT .UNINDENT .SS پیشوند زیرشبکه IPv6 (IPv6 Subnet Prefix) .sp پیشوند زیرشبکه (subnet prefix) روش دوم برای شناسایی یک زیرشبکه است. Kea می‌تواند نشانی‌های غیرمتعارف (non\-canonical) زیرشبکه را نیز بپذیرد؛ برای نمونه، این پیکربندی پذیرفته می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::1/64\(dq, ... } ] } .EE .UNINDENT .UNINDENT .sp این حالت حتی در صورتی که زیرشبکه دیگری با پیشوند \(dq2001:db8:1::/64\(dq وجود داشته باشد کار می‌کند؛ جهت جلوگیری از موارد تکراری، تنها شکل متنی زیرشبکه‌ها مقایسه می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 استفاده نادرست از این قابلیت می‌تواند به انتخاب نادرست زیرشبکه منجر شود (به «انتخاب زیرشبکه IPv6» مراجعه کنید). .UNINDENT .UNINDENT .SS پشتیبانی از ترافیک تک‌پخشی (Unicast Traffic Support) .sp هنگامی که کارساز DHCPv6 راه‌اندازی می‌شود، به‌طور پیش‌فرض به ترافیک DHCP ارسال‌شده به نشانی چندپخشی (multicast) ff02::1:2 بر روی هر رابطی که برای شنود پیکربندی شده باشد گوش می‌دهد (به «پیکربندی رابط» مراجعه کنید). در برخی موارد مفید است که کارساز را طوری پیکربندی کرد که ترافیک ورودی ارسال‌شده به نشانی‌های تک‌پخشی سراسری (global unicast) را نیز مدیریت کند؛ رایج‌ترین دلیل برای این کار، ارسال مستقیم ترافیک توسط بازپخش‌کننده‌ها (relays) به کارساز است. برای پیکربندی کارساز جهت شنود روی یک نشانی تک‌پخشی مشخص، یک اسلش (/) پس از نام رابط اضافه کنید و سپس نشانی تک‌پخشی سراسری را که کارساز باید روی آن گوش دهد بیاورید. کارساز علاوه‌بر مقیدسازی (binding) عادی محلی پیوند (link\-local) و شنود روی نشانی ff02::1:2، روی این نشانی نیز گوش خواهد داد. نمونه پیکربندی زیر نشان می‌دهد چگونه می‌توان روی نشانی 2001:db8::1 (یک نشانی سراسری) پیکربندی‌شده روی رابط \fBeth1\fP شنود کرد. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1/2001:db8::1\(dq ] }, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqunicast\(dq, \(dqdata\(dq: \(dq2001:db8::1\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp این پیکربندی باعث می‌شود که کارساز روی رابط \fBeth1\fP بر روی نشانی link\-local، گروه چندپخشی (ff02::1:2)، و 2001:db8::1 گوش دهد. .sp معمولاً پشتیبانی از تک‌پخشی با گزینه تک‌پخشی کارساز (server unicast option) همراه است که به کارخواه‌ها اجازه می‌دهد پیام‌های تک‌پخشی را به کارساز ارسال کنند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 گزینه تک‌پخشی توسط RFC 9915 \% منسوخ شده است؛ تلاش برای افزودن آن به پاسخ‌ها هشداری را ایجاد می‌کند و کارساز دیگر پرس‌وجوهای مستقیم تک‌پخشی را (در مقایسه با پرس‌وجوهای بازپخش‌شده تک‌پخشی) نمی‌پذیرد. .UNINDENT .UNINDENT .sp نمونه بالا شامل تعریف گزینه تک‌پخشی کارساز است که باعث می‌شود کارخواه پیام‌ها را به نشانی تک‌پخشی مشخص‌شده ارسال کند. .sp امکان ترکیب نام‌های رابط، نویسه‌های عام (wildcards)، و جفت‌های «نام رابط/نشانی» در فهرست رابط‌ها وجود دارد. با این حال، مشخص کردن بیش از یک نشانی تک‌پخشی روی یک رابط معین امکان‌پذیر نیست. .sp باید در مشخص کردن نشانی‌های تک‌پخشی مناسب دقت شود، زیرا کارساز بدون هیچ‌گونه بررسی اضافی، برای مقیدسازی (bind) به نشانی‌های مشخص‌شده تلاش خواهد کرد. این رویکرد عمداً انتخاب شده است تا نرم‌افزار در صورت تمایل بتواند از طریق نشانی‌های نامتعارف نیز ارتباط برقرار کند..SS پیکربندی استخرهای نشانی IPv6 .sp نقش اصلی یک کارگزار DHCPv6، تخصیص نشانی است. بدین منظور، کارگزار باید دست‌کم با یک زیرشبکه و یک استخر از نشانی‌های پویا برای مدیریت پیکربندی شود. برای نمونه، فرض کنید کارگزار به یک بخش از شبکه متصل است که از پیشوند 2001:db8:1::/64 استفاده می‌کند. مدیر آن شبکه تصمیم می‌گیرد که نشانی‌های بازهٔ 2001:db8:1::1 تا 2001:db8:1::ffff توسط کارگزار DHCPv6 مدیریت شوند. چنین پیکربندی‌ای را می‌توان به روش زیر انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::1\-2001:db8:1::ffff\(dq } ], ... } ] } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که \fBsubnet\fP به صورت یک رشتهٔ ساده تعریف می‌شود، اما پارامتر \fBpools\fP در واقع فهرستی از استخرها است؛ به همین دلیل، تعریف استخر درون قلاب‌ها (کروشه‌ها) قرار می‌گیرد، حتی اگر فقط یک بازه از نشانی‌ها مشخص شده باشد. .sp هر \fBpool\fP ساختاری است که پارامترهای توصیف‌کنندهٔ یک استخر مجزا را در بر دارد. در حال حاضر فقط یک پارامتر وجود دارد، \fBpool\fP، که بازهٔ نشانی‌های موجود در استخر را تعیین می‌کند. .sp امکان تعریف بیش از یک استخر در یک زیرشبکه وجود دارد؛ در ادامهٔ مثال پیشین، همچنین فرض کنید 2001:db8:1:0:5::/80 نیز باید توسط کارگزار مدیریت شود. این را می‌توان به صورت 2001:db8:1:0:5:: تا 2001:db8:1::5:ffff:ffff:ffff نوشت، اما تایپ این همه نویسهٔ \fBf\fP دشوار و طاقت‌فرسا است. این استخر می‌تواند ساده‌تر به صورت 2001:db8:1:0:5::/80 بیان شود. هر دو قالب توسط \fBDhcp6\fP پشتیبانی می‌شوند و می‌توان آن‌ها را در فهرست استخرها با یکدیگر ترکیب کرد. برای نمونه، استخرهای زیر را می‌توان تعریف کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::1\-2001:db8:1::ffff\(dq }, { \(dqpool\(dq: \(dq2001:db8:1:05::/80\(dq } ], ... } ] } .EE .UNINDENT .UNINDENT .sp فاصله‌های خالی در تعاریف استخر نادیده گرفته می‌شوند، بنابراین فاصله‌های قبل و بعد از خط پیوند اختیاری هستند. می‌توان از آن‌ها برای بهبود خوانایی استفاده کرد. .sp تعداد استخرها محدودیتی ندارد، اما به دلایل کارایی توصیه می‌شود تا جای ممکن از تعداد کمتری استفاده شود. .sp کارگزار ممکن است طوری پیکربندی شود که به بیش از یک زیرشبکه سرویس‌دهی کند. برای افزودن زیرشبکهٔ دوم، از دستوری مشابه زیر استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::1\-2001:db8:1::ffff\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq2001:db8:2::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:2::/64\(dq } ] }, ... ] } .EE .UNINDENT .UNINDENT .sp در این مثال، ما به کارگزار اجازه می‌دهیم تمام نشانی‌های موجود در کل زیرشبکه را به صورت پویا تخصیص دهد. گرچه تا حدی اسراف‌آمیز است، اما اختصاص دادن کل زیرشبکهٔ /64 برای این منظور مسلماً یک پیکربندی معتبر است. توجه داشته باشید که کارگزار Kea اجاره‌ها را از پیش تخصیص نمی‌دهد، بنابراین خطری در استفاده از استخرهای نشانی غول‌پیکر وجود ندارد. .sp هنگام پیکربندی یک کارگزار DHCPv6 با استفاده از نمادگذاری پیشوند/طول (prefix/length)، لطفاً به مقادیر مرزی دقت کنید. وقتی مشخص می‌کنید که کارگزار می‌تواند از یک استخر داده‌شده استفاده کند، این کارگزار قادر است اولین نشانی (که معمولاً یک نشانی شبکه است) را نیز از آن استخر تخصیص دهد. برای نمونه، برای استخر 2001:db8:2::/64، ممکن است نشانی 2001:db8:2:: نیز اختصاص یابد. برای جلوگیری از این امر، از نمادگذاری \fBmin\-max\fP استفاده کنید. .SS استخرهای زیرشبکه و تفویض پیشوند (Prefix Delegation) .sp زیرشبکه‌ها همچنین می‌توانند برای تفویض پیشوندها پیکربندی شوند، همان‌گونه که در بخش 6.3 از RFC 9915 \% تعریف شده است. یک زیرشبکه می‌تواند یک یا چند استخر تفویض پیشوند داشته باشد. هر استخر دارای یک نشانی پیشوندی است که به عنوان یک پیشوند (\fBprefix\fP) و یک طول پیشوند (\fBprefix\-len\fP)، به همراه طول پیشوند تفویض‌شده (\fBdelegated\-len\fP) مشخص می‌شود. طول تفویض‌شده نباید کوتاه‌تر از طول پیشوند باشد (یعنی باید از نظر عددی بزرگ‌تر یا مساوی با آن باشد). اگر هر دو طول تفویض‌شده و پیشوند برابر باشند، کارگزار تنها قادر به تفویض یک پیشوند خواهد بود. پیشوند تفویض‌شده الزامی ندارد که با پیشوند زیرشبکه یکسان باشد. .sp در زیر یک نمونه پیکربندی زیرشبکه آمده است که تفویض پیشوند را برای آن فعال می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:d8b:1::/64\(dq, \(dqpd\-pools\(dq: [ { \(dqprefix\(dq: \(dq3000:1::\(dq, \(dqprefix\-len\(dq: 64, \(dqdelegated\-len\(dq: 96 } ] } ], ... } .EE .UNINDENT .UNINDENT.SS گزینه استثنای پیشوند (Prefix Exclude Option) .sp برای هر پیشوند واگذارشده (delegated prefix)، روتر واگذارکننده می‌تواند طبق مشخصات RFC 6603 \%\& تصمیم بگیرد که یک پیشوند منفرد را از پیشوند واگذارشده استثنا کند. روتر درخواست‌کننده نباید پیشوند مستثناشده را به هیچ‌یک از رابط‌های دست‌پایین (downstream interfaces) خود اختصاص دهد. پیشوند مستثناشده با این هدف در نظر گرفته شده است که روی پیوندی استفاده شود که روتر واگذارکننده از طریق آن پیام‌های DHCPv6 را با روتر درخواست‌کننده تبادل می‌کند. نمونه پیکربندی زیر نحوه مشخص کردن یک پیشوند مستثناشده در تعاریف استخر پیشوند (prefix pool) را نشان می‌دهد. پیشوند مستثناشدهٔ \fB2001:db8:1:8000:cafe:80::/72\fP به روتر درخواست‌کننده‌ای ارسال خواهد شد که گزینه Prefix Exclude را در گزینه درخواست گزینه (ORO یا Option Request option) قرار داده باشد و پیشوندی از این استخر به آن واگذار شده باشد. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/48\(dq, \(dqpd\-pools\(dq: [ { \(dqprefix\(dq: \(dq2001:db8:1:8000::\(dq, \(dqprefix\-len\(dq: 56, \(dqdelegated\-len\(dq: 64, \(dqexcluded\-prefix\(dq: \(dq2001:db8:1:8000:cafe:80::\(dq, \(dqexcluded\-prefix\-len\(dq: 72 } ] } ] } .EE .UNINDENT .UNINDENT .SS استخرهای هم‌پوشان (Overlapping Pools) .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در اینجا برخی آزادی‌عمل‌ها و محدودیت‌ها برای مقادیری که زیرشبکه‌ها و استخرها می‌توانند در پیکربندی‌های Kea فراتر از حالت معمول داشته باشند آورده شده است: .TS box center; l|l|l. T{ مورد پیکربندی Kea T} T{ مجاز T} T{ توضیح T} _ T{ زیرشبکه‌های هم‌پوشان T} T{ بله T} T{ مدیر سیستم باید به چگونگی تطبیق کلاینت‌ها با این زیرشبکه‌ها توجه داشته باشد. T} _ T{ استخرهای آدرس هم‌پوشان در یک زیرشبکه T} T{ خیر T} T{ خطای راه‌اندازی: DHCP6_PARSER_FAIL T} _ T{ استخرهای آدرس هم‌پوشان در زیرشبکه‌های مختلف T} T{ بله T} T{ مشخص کردن یک استخر آدرس یکسان در زیرشبکه‌های مختلف می‌تواند به عنوان معادل استخر آدرس سراسری (global address pool) استفاده شود. در این حالت، سرور می‌تواند فارغ از زیرشبکه کلاینت، آدرس‌ها را از همان محدوده تخصیص دهد. اگر آدرسی از چنین استخری به کلاینتی در یک زیرشبکه اختصاص یابد، در صورت انتقال کلاینت به زیرشبکه‌ای دیگر، همان آدرس برای این کلاینت تمدید خواهد شد. به کلاینت دیگری در یک زیرشبکه متفاوت، آدرسی که پیش‌تر به این کلاینت در هر یک از زیرشبکه‌ها اختصاص یافته است، داده نخواهد شد. T} _ T{ استخرهای آدرسی که خارج از زیرشبکه تعریف‌شده خود هستند T} T{ خیر T} T{ خطای راه‌اندازی: DHCP6_PARSER_FAIL T} _ T{ استخرهای واگذاری پیشوند هم‌پوشان در یک زیرشبکه T} T{ خیر T} T{ خطای راه‌اندازی: DHCP6_PARSER_FAIL T} _ T{ استخرهای واگذاری پیشوند هم‌پوشان در زیرشبکه‌های مختلف T} T{ بله T} T{ مشخص کردن یک استخر واگذاری پیشوند یکسان در زیرشبکه‌های مختلف می‌تواند به عنوان معادل استخر سراسری به کار رود. در این حالت، سرور می‌تواند صرف‌نظر از زیرشبکه کلاینت، همان پیشوندها را واگذار کند. اگر پیشوندی از چنین استخری به کلاینتی در یک زیرشبکه واگذار شود، در صورت جابجایی کلاینت به زیرشبکه‌ای دیگر، همان پیشوند برای این کلاینت تمدید خواهد شد. به کلاینت دیگری در یک زیرشبکه متفاوت، پیشوندی که پیش‌تر به این کلاینت در هر یک از زیرشبکه‌ها واگذار شده است، داده نخواهد شد. T} _ T{ استخرهای واگذاری پیشوندی که با پیشوند زیرشبکه مطابقت ندارند T} T{ بله T} T{ در بسیاری از پیاده‌سازی‌ها پیکربندی استخرهای واگذاری پیشوند به‌صورتی که با پیشوند زیرشبکه مطابقت نداشته باشند رایج است؛ مانند یک استخر پیشوند 3000::/96 درون زیرشبکه 2001:db8:1::/64. چنین مواردی توسط سرور Kea DHCPv6 پشتیبانی می‌شوند. T} .TE .UNINDENT .UNINDENT.SS گزینه‌های استاندارد DHCPv6 (Standard DHCPv6 Options) .sp یکی از ویژگی‌های اصلی کارساز DHCPv6، توانایی ارائه گزینه‌های پیکربندی به کلاینت‌ها است. با اینکه گزینه‌های متعددی وجود دارند که نیازمند رفتار خاصی هستند، اکثر گزینه‌ها تنها در صورتی توسط کارساز ارسال می‌شوند که کلاینت صراحتاً آن‌ها را درخواست کرده باشد. مثال زیر نحوه پیکربندی نشانی‌های کارسازهای DNS را نشان می‌دهد که یکی از پرکاربردترین گزینه‌ها است. گزینه‌هایی که به این صورت مشخص می‌شوند سراسری (global) تلقی شده و برای تمام زیرشبکه‌های پیکربندی‌شده اعمال می‌گردند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqcode\(dq: 23, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq2001:db8::cafe, 2001:db8::babe\(dq }, ... ] } .EE .UNINDENT .UNINDENT .sp خط \fBoption\-data\fP یک مدخل جدید در جدول option\-data ایجاد می‌کند. این جدول حاوی اطلاعات مربوط به تمام گزینه‌های سراسری است که کارساز باید در تمام زیرشبکه‌ها پیکربندی کند. خط \fBname\fP نام گزینه را مشخص می‌کند. (برای مشاهده فهرست کامل نام‌های پشتیبانی‌شده کنونی، بخش «List of standard DHCPv6 options configurable by an administrator»\& را ببینید.) خط بعدی کد گزینه را مشخص می‌کند که باید با یکی از مقادیر آن فهرست مطابقت داشته باشد. خطی که با \fBspace\fP شروع می‌شود فضای گزینه را تعیین می‌کند که همواره باید روی \fBdhcp6\fP تنظیم شود، چرا که این‌ها گزینه‌های استاندارد DHCPv6 هستند. برای سایر فضاهای نام، از جمله فضاهای گزینه سفارشی، بخش «Nested DHCPv6 Options (Custom Option Spaces)»\& را ببینید. خط بعدی قالبی را که داده‌ها در آن وارد می‌شوند مشخص می‌کند؛ استفاده از CSV (مقادیر جداشده با کاما) توصیه می‌شود. در نهایت، خط \fBdata\fP مقدار واقعی ارسال‌شونده به کلاینت‌ها را مشخص می‌سازد. پارامتر data به صورت متن معمولی مشخص می‌شود و در صورتی که بیش از یک مقدار مجاز باشد، مقادیر با کاما از هم جدا می‌شوند. .sp گزینه‌ها را می‌توان به صورت مقادیر هگزادسیمال نیز پیکربندی کرد. اگر \fBcsv\-format\fP روی \fBfalse\fP تنظیم شده باشد، داده‌های گزینه باید به عنوان یک رشته هگزادسیمال مشخص شوند. دستورات زیر گزینه \fBdns\-servers\fP را برای تمام زیرشبکه‌ها با نشانی‌های 2001:db8:1::cafe و 2001:db8:1::babe پیکربندی می‌کنند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqcode\(dq: 23, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcsv\-format\(dq: false, \(dqdata\(dq: \(dq20 01 0D B8 00 01 00 00 00 00 00 00 00 00 CA FE \e 20 01 0D B8 00 01 00 00 00 00 00 00 00 00 BA BE\(dq }, ... ] } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مقدار تنظیم‌شده برای عنصر \fBdata\fP در این مثال برای وضوح بیشتر در دو خط شکسته شده است؛ هنگام وارد کردن دستور، کل رشته باید در یک خط وارد شود. .UNINDENT .UNINDENT .sp Kea هنگام مشخص کردن داده‌های هگزادسیمال از قالب‌های زیر پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBاکتت‌های جداشده (Delimited octets)\fP \- یک یا چند اکتت که با دو‌نقطه یا فاصله (\(dq:\(dq یا \(dq \(dq) از یکدیگر جدا شده‌اند. اگرچه هر اکتت می‌تواند شامل یک یا دو رقم باشد، اکیداً توصیه می‌کنیم همواره از دو رقم استفاده کنید. مثال‌های معتبر عبارتند از \(dqab:cd:ef\(dq و \(dqab cd ef\(dq. .IP \(bu 2 \fBرشته‌ای از ارقام (String of digits)\fP \- یک رشته پیوسته از ارقام هگزادسیمال همراه با پیشوند \(dq0x\(dq یا بدون آن. مثال‌های معتبر عبارتند از \(dq0xabcdef\(dq و \(dqabcdef\(dq. .UNINDENT .sp هنگام استفاده از قالب هگزادسیمال باید دقت شود که کدگذاری مناسب به کار رود؛ توانایی Kea در اعتبارسنجی صحت داده‌ها در قالب هگزادسیمال محدود است. .sp همچنین می‌توان داده‌های گزینه‌های باینری را به صورت یک رشته متنی محصور در نقل‌قول تکی (single-quoted) درون نقل‌قول جفت (double quotes) مشخص کرد، همان‌طور که نشان داده شده است (توجه داشته باشید که \fBcsv\-format\fP باید روی \fBfalse\fP تنظیم شود): .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqsubscriber\-id\(dq, \(dqcode\(dq: 38, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcsv\-format\(dq: false, \(dqdata\(dq: \(dq\(aqconvert this text to binary\(aq\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp بسیاری از پارامترها در ساختار \fBoption\-data\fP اختیاری هستند و در برخی شرایط می‌توان آن‌ها را حذف کرد، همان‌طور که در «Unspecified Parameters for DHCPv6 Option Configuration»\& بحث شده است. تنها یکی از دو مورد \fBname\fP یا \fBcode\fP الزامی است؛ نیازی به مشخص کردن هر دوی آن‌ها نیست. مقدار پیش‌فرض Space برابر با \fBdhcp6\fP است، بنابراین اگر یک گزینه معمولی (غیر کپسوله‌شده) DHCPv6 تعریف شود، می‌توان از این مورد نیز صرف‌نظر کرد. در نهایت، مقدار پیش‌فرض \fBcsv\-format\fP برابر با \fBtrue\fP است، بنابراین از آن هم می‌توان صرف‌نظر کرد مگر اینکه مقدار گزینه به صورت رشته هگزادسیمال (hexstring) مشخص شده باشد. در نتیجه، مثال بالا را می‌توان به این صورت ساده‌سازی کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8::cafe, 2001:db8::babe\(dq }, ... ] } .EE .UNINDENT .UNINDENT .sp گزینه‌های تعریف‌شده در صورتی که کلاینت آن‌ها را درخواست کند، به همراه تمام گزینه‌های الزامی در پروتکل، به پاسخ اضافه می‌شوند. مدیر سیستم همچنین می‌تواند مشخص کند که یک گزینه همواره ارسال شود، حتی اگر کلاینت به طور مشخص آن را درخواست نکرده باشد. برای اجبار به افزودن یک گزینه خاص، پرچم \fBalways\-send\fP را روی \fBtrue\fP تنظیم کنید، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8::cafe, 2001:db8::babe\(dq, \(dqalways\-send\(dq: true }, ... ] } .EE .UNINDENT .UNINDENT .sp اثر این کار همانند آن است که کلاینت کد گزینه را در Option Request Option (یا معادل آن برای گزینه‌های vendor) اضافه کرده باشد، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8::cafe, 2001:db8::babe\(dq, \(dqalways\-send\(dq: true }, ... ], \(dqsubnet6\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8:1::cafe, 2001:db8:1::babe\(dq }, ... ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp در مثال بالا، گزینه \fBdns\-servers\fP از پرچم سراسری \fBalways\-send\fP تبعیت کرده و همواره به پاسخ‌ها اضافه می‌شود، اما برای زیرشبکه \fB2001:db8:1::/64\fP، مقدار آن از مشخصات داده‌های گزینه در سطح زیرشبکه دریافت می‌شود. .sp برخلاف \fBalways\-send\fP، اگر پرچم \fBnever\-send\fP برای یک گزینه خاص روی \fBtrue\fP تنظیم شود، کارساز آن را به پاسخ اضافه نمی‌کند. اثر این کار مانند آن است که کلاینت کد گزینه را از Option Request Option (یا معادل آن برای گزینه‌های vendor) حذف کرده باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8::cafe, 2001:db8::babe\(dq }, ... ], \(dqsubnet6\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqnever\-send\(dq: true }, ... ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp در مثال بالا، گزینه \fBdns\-server\fP هرگز به پاسخ‌ها در زیرشبکه \fB2001:db8:1::/64\fP اضافه نمی‌شود. \fBnever\-send\fP بر \fBalways\-send\fP اولویت دارد، بنابراین اگر هر دو روی \fBtrue\fP تنظیم شده باشند، گزینه اضافه نخواهد شد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پرچم‌های \fBalways\-send\fP و \fBnever\-send\fP چسبنده (sticky) هستند، بدین معنا که از قواعد معمول توارث پیکربندی پیروی نمی‌کنند. در عوض، اگر حداقل یک بار در طول زنجیره توارث پیکربندی فعال شوند، اعمال می‌گردند \- حتی اگر در بخش‌های دیگری که معمولاً اولویت بالاتری دریافت می‌کنند غیرفعال شده باشند. برای نمونه، اگر یکی از این پرچم‌ها در دامنه سراسری فعال شده باشد اما در سطح زیرشبکه غیرفعال شود، صرف‌نظر از تنظیمات سطح زیرشبکه فعال در نظر گرفته می‌شود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پرچم \fBnever\-send\fP نسبت به \fBlibdhcp_flex_option.so\fP \%<#\:std-ischooklib-libdhcp_flex_option\:.so> قدرت کمتری دارد؛ به عنوان مثال، بر گزینه‌هایی که توسط خود کارساز مدیریت می‌شوند هیچ تاثیری ندارد. هر دو پرچم \fBalways\-send\fP و \fBnever\-send\fP بر گزینه‌هایی که قابل درخواست نیستند، مانند گزینه‌های یک فضای سفارشی، بی‌تاثیر هستند. .UNINDENT .UNINDENT .sp امکان بازنویسی گزینه‌ها بر پایه هر زیرشبکه وجود دارد. اگر انتظار می‌رود کلاینت‌های متصل به اغلب زیرشبکه‌ها مقادیر یکسانی از یک گزینه معین را دریافت کنند، مدیران سیستم باید از گزینه‌های سراسری استفاده کنند؛ همچنین این امکان وجود دارد که مقادیر خاصی برای تعداد اندکی از زیرشبکه‌ها بازنویسی شوند. از سوی دیگر، اگر در هر زیرشبکه از مقادیر متفاوتی استفاده می‌شود، مشخص کردن مقادیر گزینه‌های سراسری توجیهی ندارد؛ بلکه تنها باید گزینه‌های مختص زیرشبکه تنظیم شوند. .sp دستورات زیر گزینه سراسری \fBdns\-servers\fP را برای یک زیرشبکه خاص بازنویسی کرده و یک کارساز DNS منفرد با نشانی 2001:db8:1::3 تنظیم می‌کنند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqcode\(dq: 23, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq2001:db8:1::3\(dq }, ... ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp در برخی شرایط، اختصاص دادن برخی گزینه‌ها به یک استخر (pool) نشانی یا پیشوند که کلاینت اجاره (lease) خود را از آن دریافت می‌کند سودمند است. مقادیر گزینه‌های مختص استخر، مقادیر گزینه‌های مختص زیرشبکه و سراسری را بازنویسی می‌کنند. اگر کلاینت چندین اجاره از استخرهای مختلف دریافت کند، کارساز گزینه‌ها را از تمامی استخرهایی که اجاره‌ها از آن‌ها به دست آمده‌اند اختصاص می‌دهد. با این وجود، چنانچه گزینه خاصی در چندین استخر که کلاینت از آن‌ها اجاره می‌گیرد مشخص شده باشد، تنها یک نمونه از این گزینه به کلاینت تحویل داده می‌شود. مدیر کارساز نباید تلاش کند با تغییر ترتیب تعریف استخرها در پیکربندی کارساز، اقدام به اولویت‌بندی در تخصیص گزینه‌های مختص استخر نماید. .sp قطعه پیکربندی زیر نشان می‌دهد چگونه می‌توان گزینه \fBdns\-servers\fP را مشخص کرد تا تنها در صورتی که کلاینت نشانی خود را از استخر داده‌شده به دست آورد، به آن اختصاص یابد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::100\-2001:db8:1::300\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8:1::10\(dq } ] } ] }, ... ], ... } .EE .UNINDENT .UNINDENT .sp گزینه‌ها را می‌توان در دامنه کلاس یا رزرو میزبان (host\-reservation) نیز مشخص کرد. ترتیب اولویت گزینه‌ها در Kea در حال حاضر (از بیشترین اولویت به کمترین) به شرح زیر است: رزرو میزبان، استخر (pool)، زیرشبکه (subnet)، شبکه مشترک (shared network)، کلاس (class)، سراسری (global). .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 2.7.4 نرم‌افزار Kea به بعد، گنجاندن گزینه‌ها را می‌توان از طریق برچسب‌گذاری کلاس گزینه (option class\-tagging) نیز کنترل کرد؛ بخش «Option Class\-Tagging» \%<#\:option-class-tagging> را ببینید. .UNINDENT .UNINDENT .sp زمانی که یک فیلد داده به صورت رشته باشد و آن رشته حاوی نویسه کاما (\fB,\fP؛ U+002C) باشد، کاما باید با دو بک‌اسلش گریز داده شود (\fB\e\e,\fP؛ U+005C). این گریز دوگانه از این رو الزامی است که هم روال جداسازی داده‌های CSV به فیلدها و هم ساختار JSON از نویسه گریز یکسانی استفاده می‌کنند؛ یک تک‌گریز (\fB\e,\fP) ساختار JSON را نامعتبر خواهد کرد. برای مثال، رشته \(dqEST5EDT4,M3.2.0/02:00,M11.1.0/02:00\(dq باید به صورت زیر نمایش داده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqpools\(dq: [ { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqnew\-posix\-timezone\(dq, \(dqdata\(dq: \(dqEST5EDT4\e\e,M3.2.0/02:00\e\e,M11.1.0/02:00\(dq } ] }, ... ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp برخی گزینه‌ها به عنوان آرایه تعیین شده‌اند، به این معنی که بیش از یک مقدار برای آن‌ها مجاز است. به عنوان مثال، گزینه \fBdns\-servers\fP امکان تعیین بیش از یک نشانی IPv6 را فراهم می‌سازد که به کلاینت‌ها اجازه می‌دهد نشانی‌های چندین کارساز DNS را به دست آورند. .sp بخش «Custom DHCPv6 Options» نحو (syntax) پیکربندی را جهت ایجاد تعاریف (قالب‌های) گزینه‌های سفارشی شرح می‌دهد. ایجاد تعاریف سفارشی برای گزینه‌های استاندارد عموماً مجاز نیست، حتی اگر تعریف در حال ایجاد دقیقاً با قالب گزینه تعریف‌شده در RFCها مطابقت داشته باشد. با این حال، یک استثنا برای این قاعده در مورد گزینه‌های استانداردی وجود دارد که Kea در حال حاضر تعریفی برای آن‌ها ارائه نمی‌دهد. برای استفاده از چنین گزینه‌هایی، مدیر کارساز باید همان‌طور که در «Custom DHCPv6 Options» شرح داده شده است، تعریفی در فضای گزینه \fBdhcp6\fP ایجاد کند. این تعریف باید با قالب گزینه شرح داده شده در RFC مربوطه مطابقت داشته باشد، اما سازوکار پیکربندی هر قالب گزینه‌ای را مجاز می‌داند زیرا در حال حاضر روشی برای اعتبارسنجی آن وجود ندارد. .sp گزینه‌های استاندارد DHCPv6 که در حال حاضر پشتیبانی می‌شوند در جدول زیر فهرست شده‌اند. مقادیر \(dqName\(dq و \(dqCode\(dq مقادیری هستند که باید به عنوان name/code در ساختارهای option\-data استفاده شوند. \(dqType\(dq قالب داده‌ها را مشخص می‌سازد؛ معانی انواع مختلف در «List of standard DHCP option types» \%<#\:dhcp-types>\& ارائه شده است..SS فهرست گزینه‌های استاندارد DHCPv6 قابل پیکربندی توسط مدیر سیستم .TS box center; l|l|l|l. T{ نام T} T{ کد T} T{ نوع T} T{ آرایه؟ T} _ T{ preference T} T{ 7 T} T{ uint8 T} T{ false T} _ T{ unicast T} T{ 12 T} T{ ipv6\-address T} T{ false T} _ T{ sip\-server\-dns T} T{ 21 T} T{ fqdn T} T{ true T} _ T{ sip\-server\-addr T} T{ 22 T} T{ ipv6\-address T} T{ true T} _ T{ dns\-servers T} T{ 23 T} T{ ipv6\-address T} T{ true T} _ T{ domain\-search T} T{ 24 T} T{ fqdn T} T{ true T} _ T{ nis\-servers T} T{ 27 T} T{ ipv6\-address T} T{ true T} _ T{ nisp\-servers T} T{ 28 T} T{ ipv6\-address T} T{ true T} _ T{ nis\-domain\-name T} T{ 29 T} T{ fqdn T} T{ true T} _ T{ nisp\-domain\-name T} T{ 30 T} T{ fqdn T} T{ true T} _ T{ sntp\-servers T} T{ 31 T} T{ ipv6\-address T} T{ true T} _ T{ information\-refresh\-time T} T{ 32 T} T{ uint32 T} T{ false T} _ T{ bcmcs\-server\-dns T} T{ 33 T} T{ fqdn T} T{ true T} _ T{ bcmcs\-server\-addr T} T{ 34 T} T{ ipv6\-address T} T{ true T} _ T{ geoconf\-civic T} T{ 36 T} T{ record (uint8, uint16, binary) T} T{ false T} _ T{ remote\-id T} T{ 37 T} T{ record (uint32, binary) T} T{ false T} _ T{ subscriber\-id T} T{ 38 T} T{ binary T} T{ false T} _ T{ client\-fqdn T} T{ 39 T} T{ record (uint8, fqdn) T} T{ false T} _ T{ pana\-agent T} T{ 40 T} T{ ipv6\-address T} T{ true T} _ T{ new\-posix\-timezone T} T{ 41 T} T{ string T} T{ false T} _ T{ new\-tzdb\-timezone T} T{ 42 T} T{ string T} T{ false T} _ T{ ero T} T{ 43 T} T{ uint16 T} T{ true T} _ T{ lq\-query (1) T} T{ 44 T} T{ record (uint8, ipv6\-address) T} T{ false T} _ T{ client\-data (1) T} T{ 45 T} T{ empty T} T{ false T} _ T{ clt\-time (1) T} T{ 46 T} T{ uint32 T} T{ false T} _ T{ lq\-relay\-data (1) T} T{ 47 T} T{ record (ipv6\-address, binary) T} T{ false T} _ T{ lq\-client\-link (1) T} T{ 48 T} T{ ipv6\-address T} T{ true T} _ T{ v6\-lost T} T{ 51 T} T{ fqdn T} T{ false T} _ T{ capwap\-ac\-v6 T} T{ 52 T} T{ ipv6\-address T} T{ true T} _ T{ relay\-id T} T{ 53 T} T{ binary T} T{ false T} _ T{ ntp\-server T} T{ 56 T} T{ empty T} T{ false T} _ T{ v6\-access\-domain T} T{ 57 T} T{ fqdn T} T{ false T} _ T{ sip\-ua\-cs\-list T} T{ 58 T} T{ fqdn T} T{ true T} _ T{ bootfile\-url T} T{ 59 T} T{ string T} T{ false T} _ T{ bootfile\-param T} T{ 60 T} T{ tuple T} T{ true T} _ T{ client\-arch\-type T} T{ 61 T} T{ uint16 T} T{ true T} _ T{ nii T} T{ 62 T} T{ record (uint8, uint8, uint8) T} T{ false T} _ T{ aftr\-name T} T{ 64 T} T{ fqdn T} T{ false T} _ T{ erp\-local\-domain\-name T} T{ 65 T} T{ fqdn T} T{ false T} _ T{ rsoo T} T{ 66 T} T{ empty T} T{ false T} _ T{ pd\-exclude T} T{ 67 T} T{ binary T} T{ false T} _ T{ rdnss\-selection T} T{ 74 T} T{ record (ipv6\-address, uint8, fqdn) T} T{ true T} _ T{ client\-linklayer\-addr T} T{ 79 T} T{ binary T} T{ false T} _ T{ link\-address T} T{ 80 T} T{ ipv6\-address T} T{ false T} _ T{ solmax\-rt T} T{ 82 T} T{ uint32 T} T{ false T} _ T{ inf\-max\-rt T} T{ 83 T} T{ uint32 T} T{ false T} _ T{ dhcp4o6\-server\-addr T} T{ 88 T} T{ ipv6\-address T} T{ true T} _ T{ s46\-rule T} T{ 89 T} T{ record (uint8, uint8, uint8, ipv4\-address, ipv6\-prefix) T} T{ false T} _ T{ s46\-br T} T{ 90 T} T{ ipv6\-address T} T{ false T} _ T{ s46\-dmr T} T{ 91 T} T{ ipv6\-prefix T} T{ false T} _ T{ s46\-v4v6bind T} T{ 92 T} T{ record (ipv4\-address, ipv6\-prefix) T} T{ false T} _ T{ s46\-portparams T} T{ 93 T} T{ record(uint8, psid) T} T{ false T} _ T{ s46\-cont\-mape T} T{ 94 T} T{ empty T} T{ false T} _ T{ s46\-cont\-mapt T} T{ 95 T} T{ empty T} T{ false T} _ T{ s46\-cont\-lw T} T{ 96 T} T{ empty T} T{ false T} _ T{ v6\-captive\-portal T} T{ 103 T} T{ string T} T{ false T} _ T{ v6\-sztp\-redirect T} T{ 136 T} T{ tuple T} T{ true T} _ T{ ipv6\-address\-andsf T} T{ 143 T} T{ ipv6\-address T} T{ true T} _ T{ v6\-dnr T} T{ 144 T} T{ record (uint16, uint16, fqdn, binary) T} T{ false T} _ T{ addr\-reg\-enable T} T{ 148 T} T{ empty T} T{ false T} .TE .sp می‌توانید نمونه‌ای از چگونگی پیکربندی این گزینه‌ها را در kea6/all\-options.json \%<#\:config-example-kea6-all-options-json>\& مشاهده کنید. .sp گزینهٔ unicast توسط RFC 9915 \% منسوخ شده است؛ این گزینه همچنان پشتیبانی می‌شود اما نباید استفاده شود و در نگارش‌های بعدی Kea حذف خواهد شد. .sp گزینه‌های مشخص‌شده با (1) دارای تعاریف گزینه هستند، اما منطق پردازشیِ پشت آن‌ها پیاده‌سازی نشده است. این بدان معناست که از نظر فنی، Kea می‌داند چگونه آن‌ها را در پیام‌های دریافتی تجزیه کند یا در صورت پیکربندی، چگونه ارسالشان نماید، اما نمی‌داند باید با آن‌ها چه کار کند. از آنجا که RFCهای مربوطه نیازمند پردازش‌های ویژه‌ای هستند، پشتیبانی از این گزینه‌ها غیرعملیاتی (non\-functional) است. با این حال، ممکن است در برخی آزمون‌های محدود آزمایشگاهی مفید باشد؛ از این رو ساختار تعاریف آن‌ها در اینجا فهرست شده است. .sp پیکربندی برخی گزینه‌ها نسبت به گزینه‌های دیگر پیچیده‌تر است. به‌ویژه، خانوادهٔ گزینه‌های Softwire46 و Discovery of Network\-designated Resolvers (DNR) در بخش‌های جداگانه‌ای در ادامه بررسی شده‌اند. .sp Kea از گزینه‌های بیشتری نسبت به موارد فهرست‌شده در بالا پشتیبانی می‌کند. فهرست زیر بیشتر برای خوانندگانی مفید است که می‌خواهند بدانند آیا Kea قادر به پشتیبانی از گزینه‌های خاصی هست یا خیر. گزینه‌های زیر توسط خود موتور Kea بازگردانده می‌شوند و به‌طور کلی نباید به‌صورت دستی پیکربندی شوند..SS فهرست گزینه‌های استاندارد DHCPv6 که به‌طور خودکار توسط Kea مدیریت شده و مستقیماً توسط مدیر سیستم قابل پیکربندی نیستند .TS box center; l|l|l. T{ نام T} T{ کد T} T{ توضیحات T} _ T{ client\-id T} T{ 1 T} T{ توسط کلاینت ارسال می‌شود؛ Kea از آن برای تمایز میان کلاینت‌ها استفاده می‌کند. T} _ T{ server\-id T} T{ 2 T} T{ توسط کلاینت‌ها برای درخواست عملیات از یک سرور مشخص، و توسط سرور برای معرفی و شناسایی خود ارسال می‌شود. برای جزئیات به Server Identifier in DHCPv6 مراجعه کنید. T} _ T{ ia\-na T} T{ 3 T} T{ یک گزینه دربرگیرنده (container) که آدرس‌های IPv6 (گزینه‌های \fBiaddr\fP) را منتقل می‌کند. Kea این گزینه‌ها را با استفاده از موتور تخصیص خود دریافت و ارسال می‌کند. T} _ T{ ia\-ta T} T{ 4 T} T{ آدرس‌های موقت را منتقل می‌کند. قابلیتی منسوخ‌شده است و پشتیبانی نمی‌شود. T} _ T{ iaaddr T} T{ 5 T} T{ آدرس‌ها را به همراه طول عمر در گزینه‌های \fBia\-na\fP و \fBia\-ta\fP منتقل می‌کند. T} _ T{ oro T} T{ 6 T} T{ گزینه ORO (یا Option Request Option) توسط کلاینت‌ها برای درخواست فهرستی از گزینه‌های مورد نظر استفاده می‌شود. Kea از آن پشتیبانی می‌کند و در صورت پیکربندی با گزینه‌های لازم، گزینه‌های درخواستی را بازمی‌گرداند. T} _ T{ elapsed\-time T} T{ 8 T} T{ توسط کلاینت‌ها ارسال می‌شود تا مشخص کند چه مدت در تلاش برای دریافت پیکربندی بوده‌اند. Kea مقادیر بالای ارسال‌شده توسط کلاینت را به عنوان نشانه‌ای از وجود مشکل تلقی می‌کند؛ این یکی از جنبه‌های مورد استفاده در HA برای تعیین وضعیت سلامت شریک (partner) است. T} _ T{ relay\-msg T} T{ 9 T} T{ توسط رله‌ها برای کپسوله‌سازی پیام اصلی کلاینت استفاده می‌شود. Kea هنگام بازگرداندن پاسخ‌های بازپخش‌شده به عامل رله (relay agent) از آن استفاده می‌کند. T} _ T{ auth T} T{ 11 T} T{ برای انتقال اطلاعات احراز هویت بین کلاینت‌ها و سرور استفاده می‌شود. پشتیبانی از این گزینه بسیار محدود است. T} _ T{ status\-code T} T{ 13 T} T{ گزینه‌ای که سرور می‌تواند در صورت بروز شکست‌های مختلف، مانند تمام شدن آدرس‌ها یا پیکربندی نشدن برای تخصیص پیشوندها، آن را ضمیمه کند. T} _ T{ rapid\-commit T} T{ 14 T} T{ برای نشان دادن تمایل کلاینت به پشتیبانی از \fBrapid\-commit\fP و پذیرش این پیکربندی توسط سرور استفاده می‌شود. برای جزئیات به Rapid Commit مراجعه کنید. T} _ T{ user\-class T} T{ 15 T} T{ توسط کلاینت برای شناسایی نوع دستگاه خود ارسال می‌شود. Kea می‌تواند از این مورد برای رده‌بندی کلاینت (client classification) استفاده کند. T} _ T{ vendor\-class T} T{ 16 T} T{ مشابه \fBuser\-class\fP، اما وابسته به سازنده (vendor\-specific). T} _ T{ vendor\-opts T} T{ 17 T} T{ یک دربرگیرنده اختصاصی سازنده که توسط کلاینت و سرور برای تبادل گزینه‌های ویژه سازنده استفاده می‌شود. منطق پشت این گزینه‌ها بین سازندگان مختلف متفاوت است. گزینه‌های سازنده در DHCPv6 Vendor\-Specific Options توضیح داده شده‌اند\&. T} _ T{ interface\-id T} T{ 18 T} T{ ممکن است توسط عامل رله برای مشخص کردن رابطی که پیام اصلی کلاینت روی آن دریافت شده درج شود. می‌توان به Kea دستور داد تا از این اطلاعات برای انتخاب زیرشبکه‌های خاص استفاده کند. همچنین در صورت تعیین، Kea این گزینه را بازتاب (echo) می‌دهد تا رله بداند از کدام رابط برای دسترسی به کلاینت استفاده کند. T} _ T{ ia\-pd T} T{ 25 T} T{ یک دربرگیرنده برای انتقال واگذاری پیشوند (Prefix Delegations یا PDs) که به کلاینت‌ها واگذار می‌شود. برای جزئیات به Subnet and Prefix Delegation Pools مراجعه کنید. T} _ T{ iaprefix T} T{ 26 T} T{ پیشوند IPv6 را در گزینه \fBia\-pd\fP منتقل می‌کند. برای جزئیات به Subnet and Prefix Delegation Pools مراجعه کنید. T} .TE.SS گزینه‌های مشترک Softwire46 .sp گزینه‌های Softwire46 در تدارک و راه‌اندازی IPv4\-over\-IPv6 از طریق تونل‌زنی یا ترجمه، همان‌طور که در RFC 7598 \%\& مشخص شده است، به کار می‌روند. بخش‌های زیر مثال‌هایی از پیکربندی این گزینه‌ها را ارائه می‌دهند. .SS گزینه‌های کانتینر Softwire46 .sp گزینه‌های کانتینر Softwire46 (S46) قواعد و پارامترهای اختیاری درگاه (port) را برای یک دامنه مشخص گروه‌بندی می‌کنند. سه گزینه کانتینر در فضای گزینه \(dqdhcp6\(dq (سطح بالا) مشخص شده‌اند: گزینه کانتینر MAP\-E، گزینه کانتینر MAP\-T، و گزینه کانتینر S46 Lightweight 4over6. این گزینه‌ها تنها شامل گزینه‌های کپسوله‌شده مشخص‌شده در زیر هستند؛ آن‌ها شامل هیچ فیلد داده‌ای نمی‌باشند. .sp برای پیکربندی سرور جهت ارسال یک گزینه کانتینر خاص به همراه تمام گزینه‌های کپسوله‌شده، گزینه کانتینر باید مطابق شکل زیر در پیکربندی سرور گنجانده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqs46\-cont\-mape\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp این پیکربندی باعث می‌شود سرور گزینه کانتینر MAP\-E را برای کلاینت ارسال کند. به ترتیب از \fBs46\-cont\-mapt\fP یا \fBs46\-cont\-lw\fP برای گزینه‌های کانتینر MAP\-T و کانتینر S46 Lightweight 4over6 استفاده کنید. .sp تمام گزینه‌های باقی‌مانده Softwire46 که در ادامه شرح داده شده‌اند، در یکی از گزینه‌های کانتینر گنجانده می‌شوند. بنابراین، آن‌ها باید با انتخاب نام \fBspace\fP که مشخص‌کننده گزینه‌ای است که باید در آن قرار گیرند، در فضاهای گزینه مناسب گنجانده شوند. .SS گزینه S46 Rule .sp گزینه S46 Rule برای انتقال قاعده نگاشت پایه (BMR) و قاعده نگاشت بازارسال (FMR) استفاده می‌شود. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqspace\(dq: \(dqs46\-cont\-mape\-options\(dq, \(dqname\(dq: \(dqs46\-rule\(dq, \(dqdata\(dq: \(dq128, 0, 24, 192.0.2.0, 2001:db8:1::/64\(dq } .EE .UNINDENT .UNINDENT .sp مقدار ممکن دیگر برای \fBspace\fP، مقدار \fBs46\-cont\-mapt\-options\fP است. .sp گزینه S46 Rule چندین پارامتر را منتقل می‌کند: .INDENT 0.0 .IP \(bu 2 \fBflags\fP \- یک عدد صحیح بی‌علامت ۸ بیتی، که در حال حاضر تنها باارزش‌ترین بیت آن مشخص شده است. این مقدار مشخص می‌کند که آیا قاعده می‌تواند برای بازارسال (forwarding) استفاده شود (128) یا خیر (0). .IP \(bu 2 \fBea\-len\fP \- طول آدرس تعبیه‌شده (Embedded Address) با طول ۸ بیت. مقادیر مجاز در بازه 0 تا 48 قرار دارند. .IP \(bu 2 \fBIPv4 prefix length\fP \- بیانی ۸ بیتی از طول پیشوند برای پیشوند IPv4 قاعده که در فیلد \fBipv4\-prefix\fP مشخص شده است. مقادیر مجاز در بازه 0 تا 32 قرار دارند. .IP \(bu 2 \fBIPv4 prefix\fP \- یک فیلد ۳۲ بیتی با طول ثابت که پیشوند IPv4 را برای قاعده S46 مشخص می‌کند. بیت‌های موجود در پیشوند پس از تعداد مشخصی بیت (تعریف‌شده در \fBprefix4\-len\fP) رزرو شده‌اند و فرستنده باید حتماً آن‌ها را با صفر مقداردهی اولیه کرده و گیرنده باید آن‌ها را نادیده بگیرد. .IP \(bu 2 \fBIPv6 prefix\fP \- فیلدی با نمادگذاری پیشوند/طول که پیشوند دامنه IPv6 را برای قاعده S46 مشخص می‌کند. هنگامی که \fBprefix6\-len\fP بخش‌پذیر بر 8 نباشد، این فیلد از سمت راست با بیت‌های صفر تا نزدیک‌ترین مرز بایت (اکتت) پر (pad) می‌شود. .UNINDENT .SS گزینه S46 BR .sp گزینه S46 BR برای انتقال آدرس IPv6 رله مرزی (Border Relay) استفاده می‌شود. این گزینه در گزینه کانتینر MAP\-E اجباری است و در گزینه‌های کانتینر MAP\-T و S46 Lightweight 4over6 مجاز نیست. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqspace\(dq: \(dqs46\-cont\-mape\-options\(dq, \(dqname\(dq: \(dqs46\-br\(dq, \(dqdata\(dq: \(dq2001:db8:cafe::1\(dq } .EE .UNINDENT .UNINDENT .sp مقدار ممکن دیگر برای \fBspace\fP، مقدار \fBs46\-cont\-lw\-options\fP است. .SS گزینه S46 DMR .sp گزینه S46 DMR برای انتقال مقادیر قاعده نگاشت پیش‌فرض (DMR) استفاده می‌شود. این گزینه در گزینه کانتینر MAP\-T اجباری است و در گزینه‌های کانتینر MAP\-E و S46 Lightweight 4over6 مجاز نیست. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqspace\(dq: \(dqs46\-cont\-mapt\-options\(dq, \(dqname\(dq: \(dqs46\-dmr\(dq, \(dqdata\(dq: \(dq2001:db8:cafe::/64\(dq } .EE .UNINDENT .UNINDENT .sp این گزینه نباید در کانتینرهای دیگر گنجانده شود..SS گزینه پیوند نشانی S46 IPv4/IPv6 (S46 IPv4/IPv6 Address Binding Option) .sp گزینه S46 IPv4/IPv6 Address Binding می‌تواند برای مشخص کردن نشانی کامل یا اشتراکی IPv4 سمت مشتری (Customer Edge یا CE) استفاده شود. فیلد پیشوند IPv6 توسط CE برای شناسایی پیشوند صحیح جهت استفاده به عنوان مبدأ تونل به کار می‌رود. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqspace\(dq: \(dqs46\-cont\-lw\(dq, \(dqname\(dq: \(dqs46\-v4v6bind\(dq, \(dqdata\(dq: \(dq192.0.2.3, 2001:db8:1:cafe::/64\(dq } .EE .UNINDENT .UNINDENT .sp این گزینه نباید در کانتینرهای دیگر گنجانده شود. .SS پارامترهای پورت S46 (S46 Port Parameters) .sp گزینه S46 Port Parameters اطلاعات اختیاری مجموعه پورت‌ها (port\-set) را مشخص می‌کند که ممکن است در اختیار CEها قرار گیرد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqspace\(dq: \(dqs46\-rule\-options\(dq, \(dqname\(dq: \(dqs46\-portparams\(dq, \(dqdata\(dq: \(dq2, 3/4\(dq } .EE .UNINDENT .UNINDENT .sp یک مقدار ممکن دیگر برای \fBspace\fP مقدار \fBs46\-v4v6bind\fP است تا این گزینه در گزینه S46 IPv4/IPv6 Address Binding قرار گیرد. .sp توجه داشته باشید که مقدار دوم در مثال بالا فیلدهای PSID و طول PSID (PSID\-length) را در قالب PSID/PSID length مشخص می‌کند. این معادل مقادیر \fBPSID\-len=4\fP و \fBPSID=12288\fP منتقل‌شده در گزینه S46 Port Parameters است. .SS گزینه‌های DNR (Discovery of Network\-designated Resolvers) برای DHCPv6 .sp گزینه کشف تحلیل‌کننده‌های تعیین‌شده توسط شبکه، یا گزینه DNR، در RFC 9463 \% به عنوان روشی برای اعلام مکان تحلیل‌کننده‌های DNS در دسترس از طریقی غیر از DNS کلاسیک بر روی UDP و پورت ۵۳ معرفی شد. تا بهار ۲۰۲۴، فناوری‌های پشتیبانی‌شده عبارتند از DoT (DNS\-over\-TLS)، DoH (DNS\-over\-HTTPS) و DoQ (DNS\-over\-QUIC)، اما این گزینه به گونه‌ای طراحی شده است که توسعه‌پذیر بوده و در آینده پروتکل‌های دیگر را نیز در بر گیرد. .sp گزینه DNR را می‌توان با استفاده از نشانه‌گذاری مناسبی پیکربندی کرد: فیلدهای جداشده با کاما باید به ترتیب زیر ارائه شوند: .INDENT 0.0 .IP \(bu 2 اولویت سرویس (Service Priority) (اجباری)، .IP \(bu 2 نام دامنه کاملاً مشخص ADN (اجباری)، .IP \(bu 2 نشانی(های) IP (اختیاری؛ اگر بیش از یکی باشد، باید با فاصله جدا شوند) .IP \(bu 2 پارامترهای SvcParams به صورت مجموعه‌ای از جفت‌های کلید=مقدار (اختیاری؛ اگر بیش از یکی باشد، باید با فاصله جدا شوند. برای ارائه بیش از یک \fBalpn\-id\fP، آنها را با کاماهای گریز داده‌شده با دو بک‌اسلش مانند مثال زیر جدا کنید). .UNINDENT .sp فرض کنیم می‌خواهیم یک سرور DoT در حال کار در \fBdot1.example.org\fP (که به دو نشانی IPv6 تحلیل می‌شود: \fB2001:db8::1\fP و \fB2001:db8::2\fP) روی یک پورت غیر استاندارد ۸۵۳۰ را اعلام کنیم. یک گزینه نمونه که این اطلاعات را منتقل می‌کند به شکل زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqname\(dq: \(dqv6\-dnr\(dq, // نام گزینه // فیلدهای زیر باید مشخص شوند: // \- اولویت سرویس (عدد صحیح ۱۶ بیتی بدون علامت) // \- authentication\-domain\-name (نام FQDN مربوط به تحلیل‌کننده رمزگذاری‌شده) // \- فهرستی از یک یا چند نشانی IPv6 // \- فهرستی از پارامترها در قالب key=value که با فاصله جدا شده‌اند؛ هرگونه // نویسه کاما در این فیلد باید با دو بک‌اسلش گریز داده شود \(dqdata\(dq: \(dq100, dot1.example.org., 2001:db8::1 2001:db8::2, alpn=dot port=8530\(dq } .EE .UNINDENT .UNINDENT .sp گزینه بالا در رسانه انتقال (on\-wire) به صورت زیر کدگذاری خواهد شد: .INDENT 0.0 .INDENT 3.5 .sp .EX 00 64 \- اولویت سرویس (۱۰۰ در هگز به صورت عدد صحیح ۱۶ بیتی بدون علامت) 00 12 \- طول FQDN نام دامنه احراز هویت (نام تحلیل‌کننده) (۱۸ در هگز به صورت عدد صحیح ۱۶ بیتی بدون علامت) 04 64 6f 74 31 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 \- ۱۸ اوکتت از ADN FQDN 00 20 \- ۳۲ اوکتت، طول دو نشانی IPv6 پس از آن است 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 \- 2001:db8::1 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 02 \- 2001:db8::2 00 01 \- شروع SvcParams \- این alpn SvcParamKey است 00 04 \- طول فیلد alpn SvcParamValue (۴ اوکتت) 03 \- طول alpn\-id بعدی کدگذاری‌شده در یک اوکتت 64 6f 74 \- \(dqdot\(dq \- مقدار alpn 00 03 \- این port SvcParamKey است 00 02 \- طول فیلد SvcParamValue برابر ۲ اوکتت است 21 52 \- مقدار واقعی 0x2152 یا ۸۵۳۰ در مبنای ده‌دهی است .EE .UNINDENT .UNINDENT .sp مثال زیر نحوه پیکربندی بیش از یک پروتکل \fBALPN\fP را در پارامترهای سرویس (Service Parameters) نشان می‌دهد. این مثال تحلیل‌کننده‌ای شناخته‌شده به نام \fBresolver.example\fP را مشخص می‌کند که از موارد زیر پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 پروتکل DoT روی پورت پیش‌فرض ۸۵۳ .IP \(bu 2 پروتکل DoQ روی پورت پیش‌فرض ۸۵۳ .IP \(bu 2 پروتکل DoH در \fBhttps://resolver.example/q{?dns}\fP .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqname\(dq: \(dqv6\-dnr\(dq, // نام گزینه // به کاماهای گریز داده‌شده با دو بک‌اسلش در فهرست alpn\-id توجه کنید. \(dqdata\(dq: \(dq150, resolver.example., 2001:db8::1 2001:db8::2, alpn=dot\e\e,doq\e\e,h2\e\e,h3 dohpath=/q{?dns}\(dq } .EE .UNINDENT .UNINDENT .sp گزینه بالا در رسانه انتقال (on\-wire) به صورت زیر کدگذاری خواهد شد: .INDENT 0.0 .INDENT 3.5 .sp .EX 00 96 \- اولویت سرویس (۱۵۰ در هگز به صورت عدد صحیح ۱۶ بیتی بدون علامت) 00 12 \- طول FQDN نام دامنه احراز هویت (نام تحلیل‌کننده) (۱۸ در هگز به صورت عدد صحیح ۱۶ بیتی بدون علامت) 08 72 65 73 6f 6c 76 65 72 07 65 78 61 6d 70 6c 65 00 \- ۱۸ اوکتت از ADN FQDN 00 20 \- ۳۲ اوکتت، طول دو نشانی IPv6 پس از آن است 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 \- 2001:db8::1 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 02 \- 2001:db8::2 00 01 \- شروع SvcParams \- این alpn SvcParamKey است 00 0e \- طول فیلد alpn SvcParamValue (۱۴ اوکتت) 03 \- طول alpn\-id بعدی کدگذاری‌شده در یک اوکتت 64 6f 74 \- \(dqdot\(dq \- مقدار alpn 03 \- طول alpn\-id بعدی کدگذاری‌شده در یک اوکتت 64 6f 71 \- \(dqdoq\(dq \- مقدار alpn 02 \- طول alpn\-id بعدی کدگذاری‌شده در یک اوکتت 68 32 \- \(dqh2\(dq \- مقدار alpn \(dqHTTP/2 over TLS\(dq 02 \- طول alpn\-id بعدی کدگذاری‌شده در یک اوکتت 68 33 \- \(dqh3\(dq \- مقدار alpn \(dqHTTP/3\(dq 00 07 \- این dohpath SvcParamKey است 00 08 \- طول فیلد SvcParamValue برابر ۸ اوکتت است 2f 71 7b 3f 64 6e 73 7d \- \(dq/q{?dns}\(dq dohpath .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگر نویسه‌های «کاما» (\(dqcomma\(dq) یا «پایپ» (\(dqpipe\(dq) به جای جداکننده فیلد به عنوان متن استفاده شوند، باید با دو بک‌اسلش گریز داده شوند (\fB\e\e,\fP یا \fB\e\e|\fP). هنگام پیکربندی بیش از یک پروتکل \fBALPN\fP، باید از کاماهای گریزخورده برای جداسازی آنها استفاده شود. نویسه «پایپ» (\fB0x7C\fP) می‌تواند در پارامتر سرویس \fBdohpath\fP استفاده شود، زیرا در یک URI مجاز است. .UNINDENT .UNINDENT .sp بخش ۴.۱ از سند RFC 9463 \% استفاده از SvcParam مربوط به \fBALPN\fP (Application\-Layer Protocol Negotiation) را تشویق می‌کند، زیرا در اکثر موارد مورد نیاز است. این پارامتر پروتکل دسترسی به تحلیل‌کننده رمزگذاری‌شده را تعریف می‌کند. رایج‌ترین مقادیر عبارتند از \fBdot\fP، \fBdoq\fP و \fBh2\fP (به معنای HTTP/2.0 بر روی TLS، که در DoH استفاده می‌شود). .sp طبق بخش ۵ از RFC 9461 \%: اگر SvcParam مربوط به \fBalpn\fP نشان‌دهنده پشتیبانی از HTTP باشد، \fBdohpath\fP حتماً باید وجود داشته باشد. الگوی URI باید حاوی یک متغیر \(dqdns\(dq باشد. به عنوان مثال، هنگام معرفی یک تحلیل‌کننده DoH در دسترس در \fBhttps://doh1.example.org/query{?dns}\fP، مقدار \fBdohpath\fP باید روی URI نسبی \fB/query{?dns}\fP\& تنظیم شود. .sp به کاربرانی که علاقه‌مند به پیکربندی این گزینه هستند توصیه می‌شود مطالب زیر را مطالعه کنند: .INDENT 0.0 .IP \(bu 2 مجموعه بسیار خوبی از مثال‌ها در بخش ۷ از RFC 9461 \%\& در دسترس است. .IP \(bu 2 فهرستی از تمام پارامترهای سرویس تعریف‌شده کنونی در ثبت IANA \%\& نگهداری می‌شود. این سند رکوردهایی را که می‌توان در فیلد svcParams گزینه DNR ذخیره کرد، مشخص می‌کند. .IP \(bu 2 فهرستی از پروتکل‌های مجاز کنونی در پارامتر ALPN در یکی دیگر از ثبت‌های IANA \%\& نگهداری می‌شود. .IP \(bu 2 سند RFC 9463 \% تعاریف گزینه‌ها را ارائه می‌دهد. از نظر SvcParams، بیان می‌کند که \fBalpn\fP و \fBport\fP باید پشتیبانی شوند، و پشتیبانی از \fBdohpath\fP (استفاده‌شده برای DoH) توصیه می‌شود. .IP \(bu 2 بخش ۲.۲ از RFC 9460 \% قالب on\-wire را برای SvcParams تعریف می‌کند. .IP \(bu 2 بخش‌های ۷.۱ و ۷.۲ از RFC 9460 \% قالب on\-wire را برای alpn و port تعریف می‌کنند. .IP \(bu 2 بخش ۵ از RFC 9461 \% قالب on\-wire را برای \fBdohpath\fP\& تعریف می‌کند. .UNINDENT .sp در حال حاضر Kea از پارامترهای سرویس زیر پشتیبانی می‌کند: .INDENT 0.0 .INDENT 3.5 .TS box center; l|l|l. T{ نام T} T{ کد T} T{ توضیحات T} _ T{ alpn T} T{ 1 T} T{ انواع پروتکل‌های جداشده با کاما را مشخص می‌کند (DoT، DoH و غیره) T} _ T{ port T} T{ 3 T} T{ عدد صحیح ۱۶ بیتی بدون علامت. نشان‌دهنده یک پورت غیر استاندارد TCP یا UDP است. T} _ T{ dohpath T} T{ 7 T} T{ برای DoH اجباری است. شامل مسیر URL برای تحلیل‌کننده DoT است. T} .TE .UNINDENT .UNINDENT .sp سایر پارامترهای سرویس تعریف‌شده کنونی شامل mandatory (0)، no\-default\-alpn (2)، ipv4hint (4)، ech (5)، ipv6hint (6) و ohttp (8) در گزینه DNR قابل استفاده نیستند. .sp مثال‌های بیشتر را می‌توان در kea6/all\-options.json \%<#\:config-example-kea6-all-options-json>\& یافت. گزینه DHCPv4 تقریباً یکسان است و در DNR (Discovery of Network\-designated Resolvers) Options for DHCPv4 \%<#\:dnr4-options>\& شرح داده شده است..SS زیرگزینه‌های سرور NTP (NTP Server Suboptions) .sp گزینهٔ سرور NTP حاوی مجموعه‌ای از زیرگزینه‌ها است: ntp\-server\-address (۱)، ntp\-server\-multicast (۲) که حامل یک آدرس IPv6 است، و ntp\-server\-fqdn (۳) که حامل یک FQDN در قالب سیمی (wire format) تعریف‌شده در فضای گزینهٔ \(dqv6\-ntp\-server\-suboptions\(dq است. طبق الزامات RFC 5908 \%\&، هر نمونه از گزینه تنها و فقط یک زیرگزینه را حمل می‌کند. .sp بنابراین با فرض اینکه گزینهٔ دربرگیرندهٔ ntp\-server از پیش در یک بند option\-data تنظیم شده باشد، برای ارسال آن همراه با زیرگزینهٔ ntp\-server\-address برای سرور عمومی 2.pool.ntp.org، پیکربندی باید شامل موارد زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqspace\(dq: \(dqv6\-ntp\-server\-suboptions\(dq, \(dqname\(dq: \(dqntp\-server\-address\(dq, \(dqdata\(dq: \(dq2a02:8424:6fc4:3601:c13b:9426:51db:aa1\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp برای FQDN که امکان انتخاب یکی از ۴ آدرس آن را فراهم می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqspace\(dq: \(dqv6\-ntp\-server\-suboptions\(dq, \(dqname\(dq: \(dqntp\-server\-fqdn\(dq, \(dqdata\(dq: \(dq2.pool.ntp.org\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp یا برای یک سایت بسته با سرور NTP اختصاصی که از چندپخشی (multicast) استفاده می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqspace\(dq: \(dqv6\-ntp\-server\-suboptions\(dq, \(dqname\(dq: \(dqntp\-server\-multicast\(dq, \(dqdata\(dq: \(dqff05::101\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که استاندارد ایجاب می‌کند تنها یک زیرگزینه در گزینهٔ ntp\-server گنجانده شود. .SS گزینه‌های سفارشی DHCPv6 (Custom DHCPv6 Options) .sp نرم‌افزار Kea از گزینه‌های سفارشی (غیراستاندارد) DHCPv6 پشتیبانی می‌کند. فرض کنید می‌خواهیم یک گزینهٔ DHCPv6 جدید به نام \fBfoo\fP تعریف کنیم که کد ۱۰۰ خواهد داشت و یک مقدار عدد صحیح ۳۲ بیتی بدون علامت منفرد را منتقل می‌کند. چنین گزینه‌ای را می‌توان با قرار دادن ورودی زیر در فایل پیکربندی تعریف کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqcode\(dq: 100, \(dqtype\(dq: \(dquint32\(dq, \(dqarray\(dq: false, \(dqrecord\-types\(dq: \(dq\(dq, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqencapsulate\(dq: \(dq\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp مقدار \fBfalse\fP در پارامتر \fBarray\fP مشخص می‌کند که گزینه شامل آرایه‌ای از مقادیر \fBuint32\fP نیست، بلکه در عوض یک مقدار منفرد است. دو پارامتر دیگر خالی گذاشته شده‌اند: \fBrecord\-types\fP و \fBencapsulate\fP\&. اولی در صورتی که گزینه شامل رکوردی از فیلدهای داده باشد، فهرستی از فیلدهای دادهٔ گزینه را که با کاما جدا شده‌اند مشخص می‌کند. در صورتی که \fBtype\fP روی \fBrecord\fP تنظیم شده باشد، مقدار \fBrecord\-types\fP باید غیرخالی باشد؛ در غیر این صورت باید خالی گذاشته شود. پارامتر دومی نام فضای گزینه‌ای را مشخص می‌کند که توسط این گزینهٔ خاص کپسوله‌سازی می‌شود. اگر این گزینهٔ خاص هیچ فضای گزینه‌ای را کپسوله‌سازی نکند، پارامتر باید خالی گذاشته شود. توجه داشته باشید که عبارت پیکربندی \fBoption\-def\fP تنها قالب یک گزینه را تعریف می‌کند و مقدار (یا مقادیر) آن را تعیین نمی‌نماید. .sp پارامترهای \fBname\fP، \fBcode\fP و \fBtype\fP الزامی هستند؛ سایر پارامترها اختیاری‌اند. مقدار پیش‌فرض پارامتر \fBarray\fP برابر با \fBfalse\fP است. مقادیر پیش‌فرض پارامترهای \fBrecord\-types\fP و \fBencapsulate\fP خالی (\fB\(dq\(dq\fP) هستند. مقدار پیش‌فرض \fBspace\fP نیز \fBdhcp6\fP است. .sp پس از تعریف قالب گزینهٔ جدید، مقدار آن به همان روش گزینه‌های استاندارد تنظیم می‌شود. به عنوان مثال، دستورات زیر یک مقدار سراسری تنظیم می‌کنند که بر تمام زیرشبکه‌ها اعمال می‌شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqcode\(dq: 100, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq12345\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp گزینه‌های جدید می‌توانند اشکال پیچیده‌تری نسبت به استفادهٔ ساده از انواع اولیه (uint8، string، ipv6\-address و غیره) به خود بگیرند؛ امکان تعریف گزینه‌ای متشکل از چندین نوع اولیهٔ موجود وجود دارد. .sp برای مثال، فرض کنید می‌خواهیم گزینهٔ جدیدی تعریف کنیم که از یک آدرس IPv6، به دنبال آن یک عدد صحیح ۱۶ بیتی بدون علامت، به دنبال آن یک مقدار بولی (boolean)، و سپس یک رشتهٔ متنی تشکیل شده باشد. چنین گزینه‌ای را می‌توان به شیوهٔ زیر تعریف کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqbar\(dq, \(dqcode\(dq: 101, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqtype\(dq: \(dqrecord\(dq, \(dqarray\(dq: false, \(dqrecord\-types\(dq: \(dqipv6\-address, uint16, boolean, string\(dq, \(dqencapsulate\(dq: \(dq\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp پارامتر \fBtype\fP روی \fB\(dqrecord\(dq\fP تنظیم می‌شود تا نشان دهد گزینه شامل مقادیر متعددی از انواع مختلف است. این نوع‌ها به صورت فهرستی جداشده با کاما در فیلد \fBrecord\-types\fP مشخص می‌شوند و باید از میان موارد ذکرشده در فهرست انواع گزینه‌های استاندارد DHCP \%<#\:dhcp-types>\& باشند. .sp مقادیر گزینه‌ها در یک عبارت \fBoption\-data\fP به صورت زیر تنظیم می‌شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqbar\(dq, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcode\(dq: 101, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq2001:db8:1::10, 123, false, Hello World\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp پارامتر \fBcsv\-format\fP روی \fBtrue\fP تنظیم شده است تا نشان دهد فیلد \fBdata\fP شامل فهرستی از مقادیر جداشده با کاما است. مقادیر موجود در \fBdata\fP باید با انواع تنظیم‌شده در فیلد \fBrecord\-types\fP در تعریف گزینه مطابقت داشته باشند. .sp هنگامی که \fBarray\fP روی \fBtrue\fP و \fBtype\fP روی \fB\(dqrecord\(dq\fP تنظیم شود، آخرین فیلد یک آرایه خواهد بود، یعنی می‌تواند بیش از یک مقدار داشته باشد، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqbar\(dq, \(dqcode\(dq: 101, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqtype\(dq: \(dqrecord\(dq, \(dqarray\(dq: true, \(dqrecord\-types\(dq: \(dqipv6\-address, uint16\(dq, \(dqencapsulate\(dq: \(dq\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp محتوای گزینهٔ جدید یک آدرس IPv6 است که در ادامهٔ آن یک یا چند عدد صحیح ۱۶ بیتی بدون علامت قرار دارد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 به‌طور کلی، مقادیر بولی بدون نقل‌قول و به صورت \fBtrue\fP یا \fBfalse\fP مشخص می‌شوند. برخی پارامترهای بولی خاص ممکن است مقادیر \fB\(dqtrue\(dq\fP، \fB\(dqfalse\(dq\fP، \fB0\fP، \fB1\fP، \fB\(dq0\(dq\fP و \fB\(dq1\(dq\fP را نیز بپذیرند. .UNINDENT .UNINDENT.SS گزینه‌های مختص سازنده در DHCPv6 (DHCPv6 Vendor\-Specific Options) .sp گزینه‌های سازنده در DHCPv6 از طریق گزینهٔ اطلاعات مختص سازنده (Vendor\-Specific Information option با کد ۱۷) منتقل می‌شوند. ایدهٔ پشت گزینهٔ ۱۷ این است که هر سازنده مجموعهٔ یکتای خود از گزینه‌ها را با قالب‌های سفارشی ویژهٔ خود دارد. سازنده با یک عدد صحیح بدون علامت ۳۲ بیتی با نام \fBenterprise\-number\fP یا \fBvendor\-id\fP مشخص می‌شود\&. .sp فضاهای استانداردی که در Kea تعریف شده‌اند و گزینه‌های آن‌ها عبارت‌اند از: .INDENT 0.0 .IP \(bu 2 \fBvendor\-2495\fP: مربوط به Internet Systems Consortium, Inc. برای گزینه‌های 4o6: .UNINDENT .TS box center; l|l|l. T{ کد گزینه T} T{ نام گزینه T} T{ شرح گزینه T} _ T{ 60000 T} T{ 4o6\-interface T} T{ نام رابط سرور 4o6 که رو به سمت کلاینت است T} _ T{ 60001 T} T{ 4o6\-source\-address T} T{ آدرسی که سرور 4o6 برای ارسال بسته‌ها به کلاینت استفاده می‌کند T} _ T{ 60002 T} T{ 4o6\-source\-port T} T{ پورتی که سرور 4o6 برای ارسال بسته‌ها به کلاینت باز می‌کند T} .TE .INDENT 0.0 .IP \(bu 2 \fBvendor\-4491\fP: مربوط به Cable Television Laboratories, Inc. برای گزینه‌های DOCSIS3: .UNINDENT .TS box center; l|l|l. T{ کد گزینه T} T{ نام گزینه T} T{ شرح گزینه T} _ T{ 1 T} T{ oro T} T{ گزینهٔ ORO (یا Option Request Option) توسط کلاینت‌ها برای درخواست فهرستی از گزینه‌های مورد نظر آن‌ها استفاده می‌شود. T} _ T{ 2 T} T{ tftp\-servers T} T{ فهرستی از آدرس‌های IPv4 سرورهای TFTP که توسط مودم کابلی استفاده می‌شوند T} .TE .sp مثال‌های زیر نشان می‌دهند چگونه گزینهٔ \fB\(dqfoo\(dq\fP با کد ۱ تعریف شود که شامل یک آدرس IPv6، یک عدد صحیح ۱۶ بیتی بدون علامت، و یک رشته است. گزینهٔ \fB\(dqfoo\(dq\fP در یک گزینهٔ اطلاعات مختص سازنده (Vendor\-Specific Information) منتقل می‌شود که شامل یک مقدار uint32 واحد است که روی \fB12345\fP تنظیم شده است\&. زیرگزینهٔ \fB\(dqfoo\(dq\fP پس از فیلد داده‌ای که این مقدار را در خود نگه می‌دارد قرار می‌گیرد. .sp گام نخست، تعریف قالب گزینه است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqcode\(dq: 1, \(dqspace\(dq: \(dqvendor\-12345\(dq, \(dqtype\(dq: \(dqrecord\(dq, \(dqarray\(dq: false, \(dqrecord\-types\(dq: \(dqipv6\-address, uint16, string\(dq, \(dqencapsulate\(dq: \(dq\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که فضای گزینه روی \fB\(dqvendor\-12345\(dq\fP تنظیم شده است\&. پس از تعریف قالب گزینه، گام بعدی تعیین مقادیر واقعی برای آن گزینه است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqspace\(dq: \(dqvendor\-12345\(dq, \(dqdata\(dq: \(dq2001:db8:1::10, 123, Hello World\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp همچنین باید مقداری (\fB\(dqenterprise\-number\(dq\fP) برای گزینهٔ اطلاعات مختص سازنده تعریف کنیم تا گزینهٔ \fBfoo\fP را منتقل کند\&. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqvendor\-opts\(dq, \(dqdata\(dq: \(dq12345\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp از طرف دیگر، می‌توان گزینه را با استفاده از کد آن مشخص کرد. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqcode\(dq: 17, \(dqdata\(dq: \(dq12345\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp یک پیکربندی رایج این است که پرچم \fBalways\-send\fP روی \fBtrue\fP تنظیم شود، تا گزینهٔ سازنده حتی در صورتی که کلاینت آن را در پرس‌وجوی خود مشخص نکرده باشد نیز ارسال گردد. .sp همچنین به همین ترتیب می‌توان \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> را برای ارسال چندین گزینهٔ سازنده از سازندگان مختلف، به همراه شماره سازمانی اختصاصی هر یک از آن‌ها، پیکربندی نمود. برای ارسال این گزینه‌ها صرف‌نظر از اینکه کلاینت یک شماره سازمانی مشخص کرده باشد یا خیر، سرور باید با \fB\(dqalways\-send\(dq: true\fP پیکربندی شود، از جمله گزینهٔ اطلاعات مختص سازنده (کد ۱۷). .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqalways\-send\(dq: true, \(dqdata\(dq: \(dqtagged\(dq, \(dqname\(dq: \(dqtag\(dq, \(dqspace\(dq: \(dqvendor\-2234\(dq }, { \(dqalways\-send\(dq: true, \(dqdata\(dq: \(dqhttps://example.com:1234/path\(dq, \(dqname\(dq: \(dqurl\(dq, \(dqspace\(dq: \(dqvendor\-3561\(dq } ], \(dqoption\-def\(dq: [ { \(dqcode\(dq: 22, \(dqname\(dq: \(dqtag\(dq, \(dqspace\(dq: \(dqvendor\-2234\(dq, \(dqtype\(dq: \(dqstring\(dq }, { \(dqcode\(dq: 11, \(dqname\(dq: \(dqurl\(dq, \(dqspace\(dq: \(dqvendor\-3561\(dq, \(dqtype\(dq: \(dqstring\(dq } ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 سرور \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> قادر است چندین گزینهٔ Vendor Class (کد ۱۶) با شماره‌های سازمانی مختلف را در درخواست‌های کلاینت شناسایی کند و چندین گزینهٔ اطلاعات مختص سازنده (کد ۱۷) را در پاسخ‌ها، به ازای هر سازنده یکی، ارسال نماید. .UNINDENT .UNINDENT.SS گزینه‌های تودرتوی DHCPv6 (فضاهای گزینهٔ سفارشی) .sp گاهی اوقات تعریف یک فضای گزینهٔ (option space) کاملاً جدید سودمند است: برای نمونه، کاربر ممکن است گزینهٔ جدیدی برای انتقال زیرگزینه‌هایی ایجاد کند که از یک طرح شماره‌گذاری جداگانه استفاده می‌کنند، مانند زیرگزینه‌هایی با کدهای ۱ و ۲. این کدهای گزینه با گزینه‌های استاندارد DHCPv6 تداخل دارند، بنابراین باید یک فضای گزینهٔ جداگانه تعریف شود. .sp توجه داشته باشید که هنگام تعریف زیرگزینه‌ها برای یک گزینهٔ استاندارد، ایجاد یک فضای گزینهٔ جدید لازم نیست؛ زیرا اگر قرار باشد یک گزینهٔ استاندارد زیرگزینه‌هایی را منتقل کند، به‌طور پیش‌فرض یکی ایجاد می‌شود (به بخش DHCPv6 Vendor\-Specific Options مراجعه کنید). .sp اگر بخواهیم یک گزینهٔ DHCPv6 به نام \fBcontainer\fP با کد 102 داشته باشیم که دو زیرگزینه با کدهای 1 و 2 را منتقل می‌کند، ابتدا باید زیرگزینه‌های جدید را تعریف کنیم: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqsubopt1\(dq, \(dqcode\(dq: 1, \(dqspace\(dq: \(dqisc\(dq, \(dqtype\(dq: \(dqipv6\-address\(dq, \(dqrecord\-types\(dq: \(dq\(dq, \(dqarray\(dq: false, \(dqencapsulate\(dq: \(dq\(dq }, { \(dqname\(dq: \(dqsubopt2\(dq, \(dqcode\(dq: 2, \(dqspace\(dq: \(dqisc\(dq, \(dqtype\(dq: \(dqstring\(dq, \(dqrecord\-types\(dq: \(dq\(dq, \(dqarray\(dq: false, \(dqencapsulate\(dq: \(dq\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که ما گزینه‌ها را طوری تعریف کرده‌ایم که به یک فضای گزینهٔ جدید (در این حالت، \fB\(dqisc\(dq\fP) تعلق داشته باشند. .sp گام بعدی تعریف یک گزینهٔ معمولی DHCPv6 با کد مورد نظر و مشخص کردن این است که باید گزینه‌های متعلق به فضای گزینهٔ جدید را شامل شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqcontainer\(dq, \(dqcode\(dq: 102, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqtype\(dq: \(dqempty\(dq, \(dqarray\(dq: false, \(dqrecord\-types\(dq: \(dq\(dq, \(dqencapsulate\(dq: \(dqisc\(dq }, ... ], ... } .EE .UNINDENT .UNINDENT .sp نام فضای گزینه‌ای که زیرگزینه‌ها در آن تعریف شده‌اند در فیلد \fBencapsulate\fP تنظیم می‌شود. فیلد \fBtype\fP روی \fB\(dqempty\(dq\fP تنظیم شده است تا نشان دهد این گزینه داده‌ای غیر از زیرگزینه‌ها حمل نمی‌کند. .sp در نهایت، می‌توانیم مقادیر گزینه‌های جدید را مقداردهی کنیم: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqsubopt1\(dq, \(dqcode\(dq: 1, \(dqspace\(dq: \(dqisc\(dq, \(dqdata\(dq: \(dq2001:db8::abcd\(dq }, { \(dqname\(dq: \(dqsubopt2\(dq, \(dqcode\(dq: 2, \(dqspace\(dq: \(dqisc\(dq, \(dqdata\(dq: \(dqHello world\(dq }, { \(dqname\(dq: \(dqcontainer\(dq, \(dqcode\(dq: 102, \(dqspace\(dq: \(dqdhcp6\(dq } ] } } .EE .UNINDENT .UNINDENT .sp ایجاد گزینه‌ای که علاوه بر زیرگزینه‌های تعریف‌شده در فضای گزینهٔ کپسوله‌شده داده‌هایی را نیز حمل کند ممکن است. برای نمونه، اگر گزینهٔ \fBcontainer\fP از مثال قبلی ملزم به حمل یک مقدار uint16 در کنار زیرگزینه‌ها باشد، مقدار \fBtype\fP در تعریف گزینه باید روی \fB\(dquint16\(dq\fP تنظیم شود. (چنین گزینه‌ای در این صورت دارای این ساختار داده خواهد بود: هدر DHCP، مقدار uint16، زیرگزینه‌ها.) سپس مقداری که با پارامتر \fBdata\fP مشخص شده است — که باید یک عدد صحیح معتبر درون گیومه باشد، مانند \fB\(dq123\(dq\fP — به فیلد \fBuint16\fP در گزینهٔ \fBcontainer\fP اختصاص می‌یابد..SS پارامترهای مشخص‌نشده برای پیکربندی گزینه‌های DHCPv6 .sp در بسیاری از موارد نیازی به مشخص کردن تمام پارامترها برای پیکربندی یک گزینه نیست و می‌توان از مقادیر پیش‌فرض استفاده کرد. با این حال، درک پیامدهای مشخص نکردن برخی از آن‌ها مهم است، زیرا ممکن است منجر به خطاهای پیکربندی شود. فهرست زیر رفتار کارگزار را هنگام مشخص نشدن صریح یک پارامتر خاص توضیح می‌دهد: .INDENT 0.0 .IP \(bu 2 \fBname\fP \- کارگزار برای شناسایی یک گزینه، یا به نام گزینه و یا به کد گزینه نیاز دارد. اگر این پارامتر مشخص نشده باشد، کد گزینه باید مشخص شود. .IP \(bu 2 \fBcode\fP \- کارگزار برای شناسایی یک گزینه، یا به نام گزینه و یا به کد گزینه نیاز دارد؛ اگر پارامتر \fBname\fP مشخص شده باشد، این پارامتر می‌تواند مشخص‌نشده رها شود. با این حال، این امر همچنین مستلزم آن است که گزینه مورد نظر دارای تعریف باشد (خواه به عنوان یک گزینه استاندارد یا تعریفی ایجادشده توسط مدیر با استفاده از ساختار \fBoption\-def\fP)، چرا که تعریف گزینه، آن را با نامی خاص مرتبط می‌سازد. پیکربندی گزینه‌ای که تعریفی برای آن وجود ندارد (قالب گزینه نامشخص) امکان‌پذیر است. پیکربندی چنین گزینه‌هایی مستلزم استفاده از کد گزینه است. .IP \(bu 2 \fBspace\fP \- اگر فضای گزینه مشخص نشده باشد، به طور پیش‌فرض \fBdhcp6\fP خواهد بود که فضای گزینه‌ای شامل گزینه‌های استاندارد DHCPv6 است. .IP \(bu 2 \fBdata\fP \- اگر داده‌های گزینه مشخص نشده باشد، به طور پیش‌فرض یک مقدار خالی خواهد بود. مقدار خالی بیشتر برای گزینه‌هایی استفاده می‌شود که بار داده (payload) ندارند (گزینه‌های بولی)، اما مشخص کردن مقادیر خالی برای برخی گزینه‌ها که حامل داده‌های با طول متغیر هستند و مشخصات پروتکل طول 0 را برای آن‌ها مجاز می‌داند نیز معتبر است. برای چنین گزینه‌هایی، می‌توان از پارامتر data در پیکربندی صرف‌نظر کرد. .IP \(bu 2 \fBcsv\-format\fP \- اگر این مقدار مشخص نشده باشد، کارگزار فرض می‌کند که داده‌های گزینه به صورت فهرستی از مقادیر جداشده با کاما مشخص شده‌اند تا به فیلدهای جداگانه گزینه DHCP اختصاص یابند. .UNINDENT .SS کنترل مقادیر ارسالی برای زمان‌های T1 و T2 .sp مطابق با RFC 9915، بخش 21.4، مقادیر توصیه‌شده T1 و T2 به ترتیب ۵۰٪ و ۸۰٪ زمان اجاره ترجیحی (preferred lease time) هستند. Kea را می‌توان به گونه‌ای پیکربندی کرد که مقادیر مشخص‌شده به صورت صریح، یا مقادیر محاسبه‌شده به عنوان درصدی از زمان اجاره ترجیحی را ارسال کند. رفتار کارگزار با ترکیبی از پارامترهای پیکربندی تعیین می‌شود که T1 و T2 تنها دو مورد از آن‌ها هستند. .sp طول‌عمرهای ترجیحی و معتبر اجاره به صورت سه‌تایی‌هایی با مقادیر حداقل، پیش‌فرض و حداکثر با استفاده از ورودی‌های پیکربندی بیان می‌شوند: .INDENT 0.0 .IP \(bu 2 \fBmin\-preferred\-lifetime\fP \- حداقل طول‌عمر ترجیحی را مشخص می‌کند (اختیاری). .IP \(bu 2 \fBpreferred\-lifetime\fP \- طول‌عمر ترجیحی پیش‌فرض را مشخص می‌کند. .IP \(bu 2 \fBmax\-preferred\-lifetime\fP \- حداکثر طول‌عمر ترجیحی را مشخص می‌کند (اختیاری). .IP \(bu 2 \fBmin\-valid\-lifetime\fP \- حداقل طول‌عمر معتبر را مشخص می‌کند (اختیاری). .IP \(bu 2 \fBvalid\-lifetime\fP \- طول‌عمر معتبر پیش‌فرض را مشخص می‌کند. .IP \(bu 2 \fBmax\-valid\-lifetime\fP \- حداکثر طول‌عمر معتبر را مشخص می‌کند (اختیاری). .UNINDENT .sp این مقادیر را می‌توان در کلاس‌های کلاینت (client classes) مشخص کرد. .sp هنگامی که کلاینت طول‌عمرها را مشخص نمی‌کند، از مقدار پیش‌فرض استفاده می‌شود. طول‌عمر مشخص‌شده \- با استفاده از زیرگزینه IAADDR یا IAPREFIX با مقادیر غیرصفر \- در صورتی از این مقادیر استفاده می‌کند که بین کران‌های حداقل و حداکثر پیکربندی‌شده قرار داشته باشند. مقادیر خارج از این کران‌ها بر حسب نیاز به سمت بالا یا پایین گرد می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگر \fBpreferred\-lifetime\fP به صورت صریح مشخص نشده باشد، یا اگر مقدار مشخص‌شده بزرگ‌تر از مقدار \fBvalid\-lifetime\fP باشد، کارگزار از مقدار \fBvalid\-lifetime\fP ضرب در 0.625 استفاده می‌کند. .UNINDENT .UNINDENT .sp برای ارسال مقادیر ثابت مشخص، از دو پارامتر زیر استفاده کنید: .INDENT 0.0 .IP \(bu 2 \fBrenew\-timer\fP \- مقدار T1 را به ثانیه مشخص می‌کند. .IP \(bu 2 \fBrebind\-timer\fP \- مقدار T2 را به ثانیه مشخص می‌کند. .UNINDENT .sp هر مقداری بزرگ‌تر یا مساوی صفر را می‌توان برای T2 مشخص کرد. T1، در صورت مشخص شدن، باید کمتر از T2 باشد. این انعطاف‌پذیری سناریویی را ممکن می‌سازد که مدیران بخواهند تمدیدها (renewals) و اتصال‌های مجدد (rebinds) کلاینت را با به تعویق انداختن آن‌ها فراتر از طول‌عمر اجاره، سرکوب کنند. این امر باعث منقضی شدن اجاره می‌شود، به جای آنکه توسط کلاینت‌ها تمدید گردد. اگر T1 بزرگ‌تر از T2 مشخص شود، T1 در IA خروجی بدون هشدار روی صفر تنظیم می‌شود. .sp در اکثریت قریب به اتفاق موارد، مقادیر باید از این قاعده پیروی کنند: T1 < T2 < طول‌عمر ترجیحی < طول‌عمر معتبر. از طرف دیگر، هر دو مقدار T1 و T2 را می‌توان روی 0 پیکربندی کرد، که علامتی به کلاینت‌های DHCPv6 است مبنی بر اینکه می‌توانند بر اساس صلاحدید خود اقدام به تمدید کنند. با این حال، پیاده‌سازی‌های معیوب شناخته‌شده‌ای از کلاینت‌ها در حال استفاده هستند که بلافاصله تمدید را آغاز می‌کنند. مدیرانی که قصد استفاده از مقادیر T1=T2=0 را دارند باید ابتدا آزمایش کرده و مطمئن شوند که کلاینت‌هایشان رفتار معقولی دارند. .sp در برخی موارد نادر ممکن است نیاز به غیرفعال کردن توانایی کلاینت در تمدید نشانی‌ها وجود داشته باشد. این امر از دیدگاه پروتکل نامطلوب است و در صورت امکان باید از آن اجتناب شود. با این حال، در صورت لزوم، مدیران می‌توانند مقادیر T1 و T2 را برابر یا بزرگ‌تر از طول‌عمر معتبر پیکربندی کنند. توجه داشته باشید که این کار باعث می‌شود کلاینت‌ها گهگاه نشانی‌های خود را از دست بدهند، که عموماً به عنوان سرویس‌دهی ضعیف تلقی می‌شود. با این حال، ممکن است موارد تجاری نادری وجود داشته باشد که این رفتار مطلوب باشد (مانند زمانی که قطع عمدی اتصالات طولانی‌مدت مد نظر است). .sp محاسبه مقادیر توسط سه پارامتر زیر کنترل می‌شود: .INDENT 0.0 .IP \(bu 2 \fBcalculate\-tee\-times\fP \- هنگامی که \fBtrue\fP باشد، T1 و T2 به صورت درصدهایی از زمان اجاره معتبر محاسبه می‌شوند. مقدار پیش‌فرض آن \fBtrue\fP است. .IP \(bu 2 \fBt1\-percent\fP \- درصدی از زمان اجاره معتبر که برای T1 استفاده می‌شود. این مقدار به صورت یک عدد حقیقی بین 0.0 و 1.0 بیان می‌شود و باید کمتر از \fBt2\-percent\fP باشد. مقدار پیش‌فرض طبق RFC 9915 برابر با 0.5 است. .IP \(bu 2 \fBt2\-percent\fP \- درصدی از زمان اجاره معتبر که برای T2 استفاده می‌شود. این مقدار به صورت یک عدد حقیقی بین 0.0 و 1.0 بیان می‌شود و باید بزرگ‌تر از \fBt1\-percent\fP باشد. مقدار پیش‌فرض طبق RFC 9915 برابر با 0.8 است. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برخلاف DHCPv4، زمان‌های تی (T1، T2) همیشه در گزینه‌های نشانی و پیشوند DHCPv6 وجود دارند. بنابراین مقدار پیش‌فرض \fBcalculate\-tee\-times\fP برای \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> برابر با \fBtrue\fP است. این امر تضمین می‌کند که رفتار پیش‌فرض کارگزار منجر به ارسال زمان‌های تی غیرصفر به کلاینت‌ها شود. این کار به منظور جلوگیری از اشباع شدن کارگزار توسط کلاینت‌های بدرفتاری است که این زمان‌ها را برای خود محاسبه نمی‌کنند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگر هم مقادیر صریح مشخص شده باشند و هم \fBcalculate\-tee\-times\fP برابر با \fBtrue\fP باشد، کارگزار از مقادیر صریح استفاده خواهد کرد. مدیرانی با پیکربندی‌ای که در آن برخی زیرشبکه‌ها یا shared\-networkها از مقادیر صریح و برخی از مقادیر محاسباتی استفاده می‌کنند، نباید مقادیر صریح را در سطحی بالاتر از جایی که به کار می‌روند تعریف کنند. به ارث بردن آن‌ها از حوزه‌ای بسیار بالا، مانند دامنه سراسری (global)، باعث می‌شود که آن‌ها در تمام سطوح زیرین (هم shared\-networkها و هم زیرشبکه‌ها) دارای مقدار باشند و عملاً مقادیر محاسباتی را غیرفعال کنند. .UNINDENT .UNINDENT.SS انتخاب زیرشبکه IPv6 (IPv6 Subnet Selection) .sp کارساز DHCPv6 ممکن است درخواست‌هایی را از کلاینت‌های محلی (متصل به همان زیرشبکه کارساز) و دوردست (متصل از طریق رله‌ها یا relays) دریافت کند. از آنجا که ممکن است پیکربندی‌های متعددی برای زیرشبکه‌ها در کارساز تعریف شده باشد، باید زیرشبکه مناسب را برای درخواست داده‌شده انتخاب کند. .sp در IPv4، کارساز می‌تواند تشخیص دهد که کدام‌یک از زیرشبکه‌های پیکربندی‌شده محلی هستند، زیرا این انتظار منطقی وجود دارد که کارساز دارای یک نشانی IPv4 (سراسری یا global) پیکربندی‌شده روی رابط شبکه (interface) باشد. این فرض در IPv6 صادق نیست؛ کارساز DHCPv6 باید بتواند حتی در صورت استفاده صرف از نشانی‌های link\-local نیز کار کند. بنابراین، پارامتر اختیاری \fBinterface\fP درون تعریف زیرشبکه در دسترس است تا مشخص کند زیرشبکه مورد نظر محلی است، یعنی مستقیماً از طریق رابط مشخص‌شده در دسترس قرار دارد. برای نمونه، کارسازی که قرار است به یک زیرشبکه محلی روی eth0 سرویس دهد، می‌تواند به صورت زیر پیکربندی شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:beef::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:beef::/48\(dq } ], \(dqinterface\(dq: \(dqeth0\(dq } ], ... } .EE .UNINDENT .UNINDENT .SS اختصاص سریع (Rapid Commit) .sp گزینه Rapid Commit، که در RFC 9915 \% شرح داده شده است، توسط کارساز Kea DHCPv6 پشتیبانی می‌شود. با این حال، این پشتیبانی به‌طور پیش‌فرض غیرفعال است. می‌توان آن را به ازای هر زیرشبکه با استفاده از پارامتر \fBrapid\-commit\fP فعال کرد، همان‌طور که در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:beef::/48\(dq, \(dqrapid\-commit\(dq: true, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:beef::1\-2001:db8:beef::10\(dq } ] } ] } } .EE .UNINDENT .UNINDENT .sp این تنظیم تنها بر زیرشبکه‌ای تأثیر می‌گذارد که مقدار \fBrapid\-commit\fP برای آن روی \fBtrue\fP تنظیم شده باشد\&. برای کلاینت‌های متصل به زیرشبکه‌های دیگر، کارساز گزینه Rapid Commit ارسال‌شده توسط کلاینت را نادیده می‌گیرد و فرایند مبادله ۴\-مرحله‌ای (4\-way exchange) را دنبال می‌کند؛ یعنی در پاسخ به یک پیام Solicit که حاوی گزینه Rapid Commit است، پیام Advertise ارسال می‌کند. .SS رله‌های DHCPv6 (DHCPv6 Relays) .sp یک کارساز DHCPv6 با چندین زیرشبکه تعریف‌شده، باید هنگام دریافت درخواست از سوی کلاینت، زیرشبکه مناسب را انتخاب کند. برای کلاینت‌هایی که از طریق رله‌ها متصل هستند، از دو سازوکار استفاده می‌شود: .sp سازوکار نخست از فیلد \fBlinkaddr\fP در پیام \fBRELAY_FORW\fP استفاده می‌کند. نام این فیلد تا حدی گمراه‌کننده است، چرا که حاوی یک نشانی لایه پیوند (link\-layer) نیست؛ بلکه نشانی‌ای (معمولاً یک نشانی سراسری یا global) را نگهداری می‌کند که برای شناسایی یک پیوند به‌کار می‌رود. کارساز DHCPv6 بررسی می‌کند که آیا این نشانی به یک زیرشبکه تعریف‌شده تعلق دارد یا خیر، و در صورت تعلق داشتن، آن زیرشبکه برای درخواست کلاینت انتخاب می‌شود. .sp سازوکار دوم مبتنی بر گزینه‌های \fBinterface\-id\fP است. رله‌ها هنگام بازفرستادن (forwarding) پیام کلاینت، ممکن است گزینه \fBinterface\-id\fP را در پیام درج کنند که رابطی از رله را که پیام را دریافت کرده است مشخص می‌کند. (برخی رله‌ها امکان پیکربندی این پارامتر را فراهم می‌کنند، اما این مقدار گاهی به‌صورت ثابت کدنویسی شده است (hard\-coded) و ممکن است از بسیار ساده [مانند \(dqvlan100\(dq] تا بسیار مبهم و پیچیده متغیر باشد؛ یک نمونه واقعی دیده شده روی سخت‌افزار \(dqISAM144|299|ipv6|nt:vp:1:110\(dq بود.) کارساز می‌تواند از این اطلاعات برای انتخاب زیرشبکه مناسب استفاده کند. این اطلاعات همچنین به رله بازگردانده می‌شود، تا رله بداند از کدام رابط برای ارسال پاسخ به کلاینت استفاده کند. برای اینکه این فرایند با موفقیت کار کند، شناسه‌های رابط رله باید درون شبکه یکتا باشند و پیکربندی کارساز نیز با آن مقادیر مطابقت داشته باشد. .sp هنگام پیکربندی کارساز DHCPv6، دو پارامتر با نام‌های مشابه را می‌توان برای یک زیرشبکه پیکربندی کرد: .INDENT 0.0 .IP \(bu 2 \fBinterface\fP \- تعیین می‌کند که کدام رابط شبکه محلی می‌تواند برای دسترسی به یک زیرشبکه داده‌شده استفاده شود. .IP \(bu 2 \fBinterface\-id\fP \- محتوای گزینه \fBinterface\-id\fP را تعیین می‌کند که توسط رله‌ها برای شناسایی رابطی روی رله که بسته پاسخ به آن ارسال می‌شود، استفاده می‌گردد. .UNINDENT .sp این دو گزینه مانعة‌الجمع هستند؛ یک زیرشبکه نمی‌تواند هم به‌صورت محلی (ترافیک مستقیم) و هم از طریق رله‌ها (ترافیک راه‌دور) در دسترس باشد. تعیین هم‌زمان هر دو یک خطای پیکربندی محسوب می‌شود و کارساز DHCPv6 چنین پیکربندی‌ای را نخواهد پذیرفت. .sp پیکربندی نمونه زیر نشان می‌دهد که چگونه می‌توان یک \fBinterface\-id\fP با مقدار \(dqvlan123\(dq تعیین کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:beef::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:beef::/48\(dq } ], \(dqinterface\-id\(dq: \(dqvlan123\(dq } ], ... } .EE .UNINDENT .UNINDENT.SS گزینه‌های ارائه‌شده توسط بازپخش (Relay\-Supplied Options) .sp سند RFC 6422 \% سازوکاری به نام Relay\-Supplied DHCP Options را تعریف می‌کند. در موارد خاصی، کارگزاران بازپخش (relay agents) تنها موجودیت‌هایی هستند که ممکن است اطلاعات مشخصی را در اختیار داشته باشند، و می‌توانند هنگام بازپخش پیام‌ها از کلاینت به کارساز، گزینه‌ها را درج کنند. سپس کارساز بررسی‌های خاصی را انجام داده و آن گزینه‌ها را در پاسخی که برای کلاینت فرستاده می‌شود رونوشت می‌کند. .sp برای گنجانده شدن گزینه، شرایط خاصی وجود دارد که باید برآورده شوند. نخست، کارساز نباید خودش آن گزینه را ارائه دهد؛ به بیان دیگر، اگر هم بازپخش و هم کارساز گزینه‌ای را ارائه دهند، کارساز همواره اولویت دارد. دوم، گزینه باید دارای قابلیت RSOO باشد. (مخفف \(dqRelay Supplied Options option\(dq). نهاد IANA فهرستی از گزینه‌های فعال‌شده برای RSOO را در اینجا نگهداری می‌کند: \%\&. با این حال، ممکن است مواردی وجود داشته باشد که مدیران سیستم بخواهند گزینه‌های دیگری را بازتاب (echo) دهند. می‌توان Kea را طوری تنظیم کرد که با گزینه‌های دیگر نیز به‌صورت RSOO\-enabled رفتار کند؛ برای مثال، برای علامت‌گذاری گزینه‌های 110، 120 و 130 به‌عنوان RSOO\-enabled، باید از ساختار زیر استفاده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqrelay\-supplied\-options\(dq: [ \(dq110\(dq, \(dq120\(dq, \(dq130\(dq ], ... } .EE .UNINDENT .UNINDENT .sp در حال حاضر، تنها گزینه 65 توسط IANA به‌صورت RSOO\-enabled درآمده است. این گزینه همیشه به‌صورت RSOO\-enabled در نظر گرفته می‌شود، بنابراین نیازی به علامت‌گذاری صریح آن نیست. هنگام فعال‌سازی گزینه‌های استاندارد، می‌توان به جای کد گزینه از نام آن‌ها نیز استفاده کرد؛ برای نمونه، استفاده از \fBdns\-servers\fP به جای \fB23\fP\&. برای مشاهده نام‌ها به ref:\fIdhcp6\-std\-options\-list\fP مراجعه کنید. در مواردی خاص، این کار ممکن است برای گزینه‌های سفارشی (custom options) نیز کار کند، اما به دلیل ماهیت کد تجزیه‌کننده (parser) ممکن است غیرقابل‌اتکا باشد و باید از آن اجتناب کرد. .SS طبقه‌بندی کلاینت در DHCPv6 (Client Classification in DHCPv6) .sp کارساز DHCPv6 شامل پشتیبانی از طبقه‌بندی کلاینت (client classification) است. برای بررسی عمیق‌تر فرآیند طبقه‌بندی، Client Classification \%<#\:classify>\& را ببینید. .sp در مواردی خاص، پیکربندی کارساز برای تمایز قائل شدن بین انواع کلاینت‌های DHCP و رفتار متناسب با آن‌ها مفید است. طبقه‌بندی کلاینت را می‌توان برای تغییر رفتار تقریباً هر بخشی از پردازش پیام‌های DHCP به کار برد. Kea در حال حاضر سه سازوکار ارائه می‌دهد که در DHCPv6 از طبقه‌بندی کلاینت بهره می‌برند: انتخاب زیرشبکه (subnet selection)، انتخاب استخر آدرس (address pool selection)، و تخصیص گزینه‌های DHCP (DHCP options assignment). .sp می‌توان به Kea دستور داد تا دسترسی به زیرشبکه‌های مشخص‌شده را بر اساس اطلاعات کلاس محدود کند. این امر به‌ویژه برای مواردی مفید است که در آن دو نوع دستگاه پیوند یکسانی را به اشتراک می‌گذارند و انتظار می‌رود که از دو زیرشبکه مختلف به آن‌ها سرویس‌دهی شود. مورد کاربرد اصلی چنین سناریویی شبکه‌های کابلی است، که در آن دو کلاس از دستگاه‌ها وجود دارد: خود مودم کابلی، که باید اجاره‌ای (lease) از زیرشبکه A به آن تحویل داده شود؛ و تمامی دستگاه‌های دیگر پشت مودم، که باید اجاره‌هایی از زیرشبکه B دریافت کنند. این جداسازی برای جلوگیری از دستکاری مودم‌های کابلی توسط کاربران نهایی بیش از حد کنجکاو ضروری است. برای جزئیات در مورد نحوه راه‌اندازی محدودیت‌های کلاس روی زیرشبکه‌ها، Configuring Subnets With Class Information \%<#\:classification-subnets>\& را ببینید. .sp هنگامی که زیرشبکه‌ها به یک شبکه مشترک (shared network) تعلق دارند، طبقه‌بندی روی انتخاب زیرشبکه اعمال می‌شود اما روی استخرها اعمال نمی‌شود؛ یعنی یک استخر در زیرشبکه‌ای که به کلاس خاصی محدود شده است، در صورتی که استخر مورد انتظار کلاینت‌ها تمام شده باشد، همچنان می‌تواند توسط کلاینت‌هایی که به آن کلاس تعلق ندارند استفاده شود. محدودیت دسترسی بر اساس اطلاعات کلاس در سطح استخر آدرس/پیشوند درون یک زیرشبکه نیز در دسترس است: به Configuring Pools With Class Information \%<#\:classification-pools>\& مراجعه کنید. این قابلیت زمانی مفید است که کلاینت‌های متعلق به یک زیرشبکه را به محدوده‌های آدرس متفاوتی تفکیک می‌کنید. .sp به همین شیوه، با استفاده از کلاس‌های توکار \fBKNOWN\fP یا \fBUNKNOWN\fP، می‌توان یک استخر را محدود کرد تا تنها به کلاینت‌های شناخته‌شده، یعنی کلاینت‌هایی که دارای رزرو (reservation) هستند، سرویس دهد. می‌توان به کلاینت‌های ثبت‌شده آدرس اختصاص داد بدون اینکه برای هر رزرو یک آدرس متفاوت داده شود: برای نمونه، زمانی که آدرس‌های دردسترس کافی وجود ندارد. تعیین اینکه آیا رزروی برای یک کلاینت خاص وجود دارد یا خیر، پس از انتخاب زیرشبکه انجام می‌شود، بنابراین امکان استفاده از کلاس‌های \fBKNOWN\fP/\fBUNKNOWN\fP برای انتخاب یک شبکه مشترک یا یک زیرشبکه وجود ندارد. .sp فرآیند طبقه‌بندی در پنج مرحله انجام می‌شود. نخستین گام، ارزیابی بسته ورودی و انتساب آن به صفر یا چند کلاس است. دومین گام، انتخاب یک زیرشبکه است، که احتمالاً بر اساس اطلاعات کلاس صورت می‌گیرد. هنگامی که بسته ورودی در کلاس ویژه \fBDROP\fP قرار گیرد، دور انداخته می‌شود و یک پیام اشکال‌زدایی (debug) ثبت می‌گردد. گام بعدی، ارزیابی عبارت‌های کلاسیِ وابسته به کلاس‌های توکار \fBKNOWN\fP/\fBUNKNOWN\fP پس از جستجوی رزرو میزبان (host reservation lookup)، استفاده از آن‌ها برای انتخاب pool/pd\-pool و انتساب کلاس‌ها از روی رزروهای میزبان است. سپس فهرست کلاس‌های مورد نیاز ساخته می‌شود و عبارت هر کلاس از این فهرست ارزیابی می‌گردد؛ زمانی که خروجی آن \fBtrue\fP باشد، بسته به‌عنوان عضوی از آن کلاس اضافه می‌شود. گام پایانی تخصیص گزینه‌ها است که باز هم احتمالاً بر اساس اطلاعات کلاس انجام می‌شود. اطلاعات کامل‌تر و دقیق‌تر در Client Classification \%<#\:classify>\& در دسترس است. .sp دو روش اصلی برای طبقه‌بندی وجود دارد. روش اول خودکار است و بر بررسی مقادیر موجود در گزینه‌های vendor class یا وجود رزرو میزبان تکیه دارد. اطلاعات از این گزینه‌ها استخراج شده، و نام کلاسی از آن ساخته می‌شود و به فهرست کلاس‌های بسته افزوده می‌گردد. روش دوم، عبارتی را مشخص می‌کند که برای هر بسته ارزیابی می‌شود. اگر نتیجه \fBtrue\fP باشد، بسته عضوی از آن کلاس خواهد بود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پرچم پارامتر سراسری جدید \fBearly\-global\-reservations\-lookup\fP امکان جستجو برای رزروهای سراسری را قبل از مرحله انتخاب زیرشبکه فعال می‌کند. این جستجو شبیه به جستجوی عمومی شرح داده‌شده در بالا با دو تفاوت است: .INDENT 0.0 .IP \(bu 2 جستجو به رزروهای میزبان سراسری (global host reservations) محدود است .IP \(bu 2 کلاس \fBUNKNOWN\fP هرگز تنظیم نمی‌شود .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در استفاده از طبقه‌بندی کلاینت باید دقت شود، زیرا کلاینت‌هایی که معیارهای کلاس را برآورده نمی‌کنند به‌سادگی ممکن است از دریافت هرگونه سرویسی محروم شوند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نگارش 3.1.7 از Kea کلاس ویژه دیگری به نام \fBREJECT\fP اضافه کرد که به شیوه‌ای مشابه با کلاس \fBDROP\fP کار می‌کند، اما به‌جای نادیده گرفتن و دور انداختن کامل پرس‌وجوی ورودی، از بخش تخصیص اجاره صرف‌نظر می‌کند تا IAها در پاسخ، کدهای وضعیت NoAddrsAvail یا NoPrefixAvail را دریافت کنند. .UNINDENT .UNINDENT.SS تعریف و استفاده از کلاس‌های سفارشی .sp مثال زیر نحوه پیکربندی یک کلاس با استفاده از یک عبارت (expression) و یک زیرشبکه با استفاده از آن کلاس را نشان می‌دهد. این پیکربندی کلاسی به نام \fBClient_enterprise\fP\& را تعریف می‌کند. این کلاس شامل تمام کلاینت‌هایی است که شناسه کلاینت آن‌ها با رشته هگزادسیمال مشخص‌شده شروع می‌شود (که نشان‌دهنده یک DUID بر اساس شناسه سازمانی 0xAABBCCDD است). به اعضای این کلاس آدرسی از 2001:db8:1::0 تا 2001:db8:1::FFFF اختصاص می‌یابد و آدرس‌های کارسازهای DNS آن‌ها روی 2001:db8:0::1 و 2001:db8:2::1 تنظیم می‌شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient_enterprise\(dq, \(dqtest\(dq: \(dqsubstring(option[1].hex,0,6) == 0x0002AABBCCDD\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqcode\(dq: 23, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq2001:db8:0::1, 2001:db8:2::1\(dq } ] }, ... ], \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::\-2001:db8:1::ffff\(dq } ], \(dqclient\-classes\(dq: [ \(dqClient_enterprise\(dq ] } ], ... } .EE .UNINDENT .UNINDENT .sp این مثال پیکربندی‌ای را با استفاده از کلاس تولیدشده خودکار \fBVENDOR_CLASS_\fP نشان می‌دهد. مدیر شبکه تصمیم گرفته است که آدرس‌ها در محدوده 2001:db8:1::1 تا 2001:db8:1::ffff توسط کارساز DHCPv6 مدیریت شوند و فقط کلاینت‌های متعلق به کلاس کلاینت eRouter1.0 مجاز به استفاده از آن استخر (pool) باشند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::\-2001:db8:1::ffff\(dq } ], \(dqclient\-classes\(dq: [ \(dqVENDOR_CLASS_eRouter1.0\(dq ] } ], ... } .EE .UNINDENT .UNINDENT .SS کلاس‌بندی تکمیلی .sp در برخی موارد، محدود کردن دامنه (scope) یک کلاس به یک pool، subnet یا shared network مفید است. دو پارامتر وجود دارند که با دستور دادن به کارساز برای ارزیابی عبارت‌های آزمون در زمان نیاز، برای محدود کردن دامنه کلاس استفاده می‌شوند. .sp پارامتر نخست \fBevaluate\-additional\-classes\fP است که فهرستی از نام‌های کلاس را می‌گیرد و در دامنه pool، subnet و shared network معتبر است. کلاس‌های موجود در این فهرست‌ها به عنوان تکمیلی نشانه‌گذاری می‌شوند و پس از انتخاب آن pool/subnet/shared network خاص و پیش از پردازش گزینه‌های خروجی ارزیابی می‌گردند. .sp پارامتر دوم، پرچم خاص هر کلاس به نام \fBonly\-in\-additional\-list\fP است که به صورت پیش‌فرض \fBfalse\fP می‌باشد. هنگامی که روی \fBtrue\fP تنظیم شود، عبارت آزمون کلاس هنگام دریافت بسته ورودی ارزیابی نمی‌شود، بلکه بعداً و تنها در صورتی که کلاس در یک فهرست \fBevaluate\-additional\-classes\fP موجود باشد ارزیابی خواهد شد. .sp در این مثال، زمانی که زیرشبکه (subnet) مشخص‌شده استفاده شود، یک کلاس به بسته ورودی اختصاص داده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient_foo\(dq, \(dqtest\(dq: \(dqmember(\(aqALL\(aq)\(dq, \(dqonly\-in\-additional\-list\(dq: true }, ... ], \(dqsubnet6\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::\-2001:db8:1::ffff\(dq } ], \(dqevaluate\-additional\-classes\(dq: [ \(dqClient_foo\(dq ], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp ارزیابی تکمیلی می‌تواند برای بیان وابستگی‌های پیچیده مانند عضویت در زیرشبکه استفاده شود. همچنین می‌توان از آن برای معکوس کردن تقدم (precedence) استفاده کرد؛ اگر \fBoption\-data\fP در یک subnet تنظیم شده باشد، بر \fBoption\-data\fP در یک کلاس اولویت دارد. اگر \fBoption\-data\fP به یک کلاس الزامی منتقل شود و در subnet فراخوانی شود، کلاسی که زودتر ارزیابی شده است ممکن است تقدم پیدا کند. .sp ارزیابی تکمیلی در سطوح shared network و pool/pd\-pool نیز در دسترس است. ترتیبی که در آن کلاس‌های تکمیلی بررسی می‌شوند عبارت است از: (pd\-)pool، سپس subnet، و در نهایت shared network؛ یعنی به همان ترتیبی که \fBoption\-data\fP پردازش می‌شود. .sp از نسخه 2.7.4 نرم‌افزار Kea، کلاس‌های تکمیلی که بدون عبارت آزمون پیکربندی شده‌اند بدون قید و شرط اضافه می‌شوند؛ یعنی همواره با مقدار \fBtrue\fP ارزیابی می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از آنجا که ارزیابی تکمیلی پس از تخصیص اجاره (lease) رخ می‌دهد، پارامترهایی که در غیر این صورت بر طول عمر اجاره تأثیر می‌گذاشتند (مانند \fBvalid\-lifetime\fP و \fBpreferred\-lifetime\fP)، چنانچه در کلاسی تعیین شوند که پرچم \fBonly\-in\-additional\-list\fP آن روی true تنظیم شده است، هیچ تأثیری نخواهند داشت. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 2.7.4 نرم‌افزار Kea، شناسه‌های \fBonly\-if\-required\fP و \fBrequire\-client\-classes\fP به ترتیب به \fBonly\-in\-additional\-list\fP و \fBevaluate\-additional\-classes\fP تغییر نام یافته‌اند. نام‌های قبلی همچنان به عنوان ورودی معتبر پذیرفته می‌شوند تا کاربران فرصت مهاجرت به ساختار جدید را داشته باشند، اما در نهایت منسوخ و رد خواهند شد. .UNINDENT .UNINDENT.SS DDNS برای DHCPv6 .sp همان‌طور که پیش‌تر اشاره شد، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> می‌تواند به‌گونه‌ای پیکربندی شود که برای به‌روزرسانی مدخل‌های DNS، درخواست‌هایی را برای کارساز DHCP\-DDNS یعنی \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> (که در اینجا به آن \(dqD2\(dq گفته می‌شود) تولید کند. این درخواست‌ها با نام NameChangeRequests یا NCR شناخته می‌شوند. هر NCR شامل اطلاعات زیر است: .INDENT 0.0 .IP 1. 3 اینکه آیا درخواستی برای افزودن (به‌روزرسانی) است یا حذف مدخل‌های DNS. .IP 2. 3 اینکه آیا تغییر درخواستی برای به‌روزرسانی مستقیم DNS (رکورد‌های AAAA)، به‌روزرسانی معکوس DNS (رکورد‌های PTR)، یا هر دو است. .IP 3. 3 نام دامنه کاملاً واجد شرایط (FQDN)، نشانی اجاره (lease address)، و DHCID (اطلاعات شناسایی کلاینت مرتبط با FQDN). .UNINDENT .sp پارامترهای مرتبط با DDNS به دو گروه تقسیم می‌شوند: .INDENT 0.0 .IP 1. 3 پارامترهای اتصال (Connectivity Parameters) .INDENT 3.0 .INDENT 3.5 این‌ها پارامترهایی هستند که مشخص می‌کنند \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> کجا و چگونه به D2 متصل شده و با آن ارتباط برقرار می‌کند. این پارامترها فقط می‌توانند درون بخش سطح بالای \fBdhcp\-ddns\fP در پیکربندی \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> مشخص شوند. پارامترهای اتصال در زیر فهرست شده‌اند: .INDENT 0.0 .IP \(bu 2 \fBenable\-updates\fP .IP \(bu 2 \fBserver\-ip\fP .IP \(bu 2 \fBserver\-port\fP .IP \(bu 2 \fBsender\-ip\fP .IP \(bu 2 \fBsender\-port\fP .IP \(bu 2 \fBmax\-queue\-size\fP .IP \(bu 2 \fBncr\-protocol\fP .IP \(bu 2 \fBncr\-format\fP .UNINDENT .UNINDENT .UNINDENT .IP 2. 3 پارامترهای رفتاری (Behavioral Parameters) .INDENT 3.0 .INDENT 3.5 این پارامترها بر رفتارهایی مانند نحوه مدیریت نام میزبان کلاینت و گزینه‌های FQDN تأثیر می‌گذارند. آن‌ها از بخش \fBdhcp\-ddns\fP خارج شده‌اند تا بتوان آن‌ها را در سطوح سراسری (global)، شبکه مشترک (shared\-network)، زیرشبکه (subnet) و/یا استخر (pool) مشخص کرد. علاوه بر این، آن‌ها از سطوح بالاتر به پایین به ارث می‌رسند: از سراسری به شبکه مشترک، به زیرشبکه و به استخر. به عبارت دیگر، اگر پارامتری در یک سطح خاص تعیین نشده باشد، مقدار آن سطح از سطح بالاتر دریافت می‌شود. پارامترهای رفتاری به شرح زیر هستند: .INDENT 0.0 .IP \(bu 2 \fBddns\-send\-updates\fP .IP \(bu 2 \fBddns\-override\-no\-update\fP .IP \(bu 2 \fBddns\-override\-client\-update\fP .IP \(bu 2 \fBddns\-replace\-client\-name\fP .IP \(bu 2 \fBddns\-generated\-prefix\fP .IP \(bu 2 \fBddns\-qualifying\-suffix\fP .IP \(bu 2 \fBddns\-update\-on\-renew\fP .IP \(bu 2 \fBddns\-conflict\-resolution\-mode\fP .IP \(bu 2 \fBddns\-ttl\fP .IP \(bu 2 \fBddns\-ttl\-percent\fP .IP \(bu 2 \fBddns\-ttl\-min\fP .IP \(bu 2 \fBddns\-ttl\-max\fP .IP \(bu 2 \fBhostname\-char\-set\fP .IP \(bu 2 \fBhostname\-char\-replacement\fP .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در Kea 2.7.6 پشتیبانی از این پارامترها در سطح استخر (نشانی) افزوده شد. این پارامترها در pd\-pools پشتیبانی نمی‌شوند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پارامترهای رفتاری که بر FQDN تأثیر می‌گذارند، حتی اگر هر دو گزینهٔ \fBenable\-updates\fP و \fBddns\-send\-updates\fP برابر با \fBfalse\fP باشند نیز اعمال می‌شوند؛ این امر برای پشتیبانی از محیط‌هایی است که در آن‌ها کلاینت‌ها مسئول به‌روزرسانی DNS خود هستند. این موضوع برای \fBddns\-replace\-client\-name\fP، \fBddns\-generated\-prefix\fP، \fBddns\-qualifying\-suffix\fP، \fBhostname\-char\-set\fP، و \fBhostname\-char\-replacement\fP\& صدق می‌کند. .UNINDENT .UNINDENT .sp پیکربندی پیش‌فرض و مقادیر آن به صورت زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqdhcp\-ddns\(dq: { // Connectivity parameters \(dqenable\-updates\(dq: false, \(dqserver\-ip\(dq: \(dq127.0.0.1\(dq, \(dqserver\-port\(dq:53001, \(dqsender\-ip\(dq:\(dq\(dq, \(dqsender\-port\(dq:0, \(dqmax\-queue\-size\(dq:1024, \(dqncr\-protocol\(dq:\(dqUDP\(dq, \(dqncr\-format\(dq:\(dqJSON\(dq }, // Behavioral parameters (global) \(dqddns\-send\-updates\(dq: true, \(dqddns\-override\-no\-update\(dq: false, \(dqddns\-override\-client\-update\(dq: false, \(dqddns\-replace\-client\-name\(dq: \(dqnever\(dq, \(dqddns\-generated\-prefix\(dq: \(dqmyhost\(dq, \(dqddns\-qualifying\-suffix\(dq: \(dq\(dq, \(dqddns\-update\-on\-renew\(dq: false, \(dqddns\-conflict\-resolution\-mode\(dq: \(dqcheck\-with\-dhcid\(dq, \(dqhostname\-char\-set\(dq: \(dq[^A\-Za\-z0\-9.\-]\(dq, \(dqhostname\-char\-replacement\(dq: \(dqx\(dq, ... } .EE .UNINDENT .UNINDENT .sp دو پارامتر وجود دارند که تعیین می‌کنند آیا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> می‌تواند درخواست‌های DDNS را برای D2 تولید کند یا خیر: پارامتر موجود \fBdhcp\-ddns:enable\-updates\fP که اکنون فقط کنترل می‌کند آیا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> به D2 متصل شود یا خیر؛ و پارامتر رفتاری جدید \fBddns\-send\-updates\fP که مشخص می‌کند آیا به‌روزرسانی‌های DDNS در یک سطح مشخص (مانند سراسری، شبکه مشترک یا زیرشبکه) فعال هستند یا خیر. جدول زیر نحوه عملکرد هم‌زمان این دو پارامتر را نشان می‌دهد:.SS فعال و غیرفعال کردن به‌روزرسانی‌های DDNS .TS box center; l|l|l. T{ dhcp\-ddns: enable\-updates T} T{ سراسری ddns\-send\-updates T} T{ نتیجه T} _ T{ false (پیش‌فرض) T} T{ false T} T{ بدون به‌روزرسانی در هیچ حوزه‌ای T} _ T{ false T} T{ true (پیش‌فرض) T} T{ بدون به‌روزرسانی در هیچ حوزه‌ای T} _ T{ true T} T{ false T} T{ به‌روزرسانی تنها در حوزه‌هایی با مقدار محلی \fBtrue\fP برای \fBddns\-enable\-updates\fP T} _ T{ true T} T{ true T} T{ به‌روزرسانی در تمام حوزه‌ها به‌جز آن‌هایی که مقدار محلی \fBfalse\fP برای \fBddns\-enable\-updates\fP دارند T} .TE .sp در Kea 1.9.1 دو پارامتر جدید اضافه شد؛ اولین پارامتر \fBddns\-update\-on\-renew\fP است\&. به‌طور معمول، هنگام تمدید اجاره‌ها (leases)، کارساز فقط در صورتی DNS را به‌روزرسانی می‌کند که اطلاعات DNS مربوط به اجاره (مانند FQDN، پرچم‌های جهت به‌روزرسانی DNS) تغییر کرده باشد. تنظیم \fBddns\-update\-on\-renew\fP روی \fBtrue\fP به کارساز دستور می‌دهد که هنگام تمدید اجاره همواره اطلاعات DNS را به‌روزرسانی کند، حتی اگر اطلاعات DNS آن تغییری نکرده باشد. این ویژگی به Kea امکان می‌دهد در صورتی که پیش‌تر قادر به افزودن ورودی‌های DNS نبوده یا آن‌ها به هر دلیلی توسط کارساز DNS از دست رفته باشند، «خودترمیم» (\(dqself\-heal\(dq) انجام دهد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تنظیم \fBddns\-update\-on\-renew\fP روی \fBtrue\fP ممکن است بر کارایی تأثیر بگذارد، به‌ویژه برای کارسازهایی با کارخواه‌های متعدد که مکرراً تمدید می‌شوند. .UNINDENT .UNINDENT .sp دومین پارامتر اضافه‌شده در Kea 1.9.1 پارامتر \fBddns\-use\-conflict\-resolution\fP است\&. این پارامتر بولی (boolean) به D2 منتقل می‌شد و حل تعارض را بر اساس شرح ارائه‌شده در RFC 4703 \% فعال یا غیرفعال می‌کرد\&. از نسخه Kea 2.5.0 به بعد، این پارامتر منسوخ شده و با \fBddns\-conflict\-resolution\-mode\fP جایگزین شده است که چهار حالت رفتار مربوط به حل تعارض را ارائه می‌دهد: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBcheck\-with\-dhcid\fP \- این حالت، که پیش‌فرض است، به D2 دستور می‌دهد تا حل تعارض منطبق بر RFC 4703 را انجام دهد. ورودی‌های موجود DNS فقط در صورتی بازنویسی می‌شوند که دارای یک رکورد DHCID باشند و این رکورد با DHCID کارخواه مطابقت داشته باشد. این حالت معادل \fBddns\-use\-conflict\-resolution\fP: \fBtrue\fP است؛ .IP \(bu 2 \fBno\-check\-with\-dhcid\fP \- ورودی‌های موجود DNS ممکن است توسط هر کارخواهی بازنویسی شوند، صرف‌نظر از اینکه آن ورودی‌ها شامل رکورد DHCID باشند یا خیر. ورودی‌های جدید شامل یک رکورد DHCID برای کارخواهی خواهند بود که به آن تعلق دارند. این حالت معادل \fBddns\-use\-conflict\-resolution\fP: \fBfalse\fP است؛ .IP \(bu 2 \fBcheck\-exists\-with\-dhcid\fP \- ورودی‌های موجود DNS تنها در صورتی بازنویسی می‌شوند که دارای رکورد DHCID باشند. نیازی نیست رکورد DHCID با DHCID کارخواه مطابقت داشته باشد. این حالت روشی برای محافظت از ورودی‌های ایستا DNS (آن‌هایی که رکورد DHCID ندارند) در حین اجازه دادن به بازنویسی ورودی‌های پویا (آن‌هایی که رکورد DHCID دارند) توسط هر کارخواهی فراهم می‌کند. این رفتار پیش از Kea 2.4.0 پشتیبانی نمی‌شد. .IP \(bu 2 \fBno\-check\-without\-dhcid\fP \- ورودی‌های موجود DNS ممکن است توسط هر کارخواهی بازنویسی شوند؛ ورودی‌های جدید شامل رکوردهای DHCID نخواهند بود. این رفتار پیش از Kea 2.4.0 پشتیبانی نمی‌شد. .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 جهت سازگاری با نسخه‌های پیشین، \fBddns\-use\-conflict\-resolution\fP همچنان در پیکربندی JSON پذیرفته می‌شود. کارساز این مقدار را در داخل به‌صورت خودکار با \fBddns\-conflict\-resolution\-mode\fP و مقدار مناسب جایگزین می‌کند: \(ga \fBcheck\-with\-dhcid\fP برای \fBtrue\fP و \fBno\-check\-with\-dhcid\fP برای \fBfalse\fP\&. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تنظیم \fBddns\-conflict\-resolution\-mode\fP روی هر مقداری به‌جز \fBcheck\-with\-dhcid\fP، تمهیدات حفاظتی بازنویسی را که قواعد حل تعارض (از RFC 4703 \%) قصد پیشگیری از آن را دارند غیرفعال می‌کند. این بدان معناست که ورودی‌های موجود برای یک FQDN یا یک نشانی IP که برای Client\-A ایجاد شده‌اند می‌توانند توسط ورودی‌های Client\-B حذف یا جایگزین شوند. علاوه بر این، دو سناریو وجود دارد که از طریق آن‌ها ورودی‌های چند کارخواه برای یک کلید یکسان (مانند FQDN یا IP) ایجاد شود. .sp 1. کارخواه Client\-B از همان FQDN مربوط به Client\-A اما با یک نشانی IP متفاوت استفاده می‌کند. در این حالت، ورودی‌های مستقیم DNS (رکوردهای AAAA و DHCID) مربوط به Client\-A حذف خواهند شد چرا که با FQDN مطابقت دارند، و ورودی‌های جدید برای Client\-B اضافه خواهند شد. با این حال، ورودی‌های معکوس DNS (رکوردهای PTR و DHCID) برای Client\-A حذف نخواهند شد زیرا متعلق به نشانی IP متفاوتی هستند، در حالی که ورودی‌های جدید برای Client\-B همچنان افزوده می‌شوند. .sp 2. کارخواه Client\-B از همان نشانی IP مربوط به Client\-A اما با یک FQDN متفاوت استفاده می‌کند. در این حالت، ورودی‌های معکوس DNS (رکوردهای PTR و DHCID) مربوط به Client\-A حذف خواهند شد چرا که با نشانی IP مطابقت دارند، و ورودی‌های جدید برای Client\-B افزوده خواهند شد. با این حال، ورودی‌های مستقیم DNS (رکوردهای AAAA و DHCID) برای Client\-A حذف نخواهند شد، زیرا به یک FQDN متفاوت تعلق دارند، در حالی که ورودی‌های جدید برای Client\-B همچنان افزوده خواهند شد. .sp غیرفعال‌سازی حل تعارض تنها باید پس از بررسی دقیق موارد کاربرد خاص انجام شود. بهترین راه برای جلوگیری از ایجاد ورودی‌های ناخواسته DNS این است که همیشه اطمینان حاصل شود پیش از تخصیص مجدد FQDNها یا نشانی‌های IP، تغییرات اجاره از طریق Kea پردازش شوند—خواه آزاد شوند، منقضی شوند یا از طریق دستور \fBlease6\-del\fP \%<#\:std-isccmd-lease6-del> حذف شوند. انجام این کار باعث می‌شود \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> درخواست‌های حذف DNS را به D2 ارسال کند. .UNINDENT .UNINDENT .sp ورودی‌های DNS که توسط Kea ایجاد می‌شوند شامل مقداری برای TTL (طول عمر / time to live) هستند. به‌طور پیش‌فرض، کارساز \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> این مقدار را بر اساس RFC 4702، بخش ۵ \% محاسبه می‌کند، که پیشنهاد می‌کند مقدار TTL برابر با ۱/۳ طول عمر اجاره باشد، با حداقل مقدار ۱۰ دقیقه. چهار پارامتر اختیاری وجود دارند که می‌توان از آن‌ها برای تأثیرگذاری بر محاسبه TTL استفاده کرد: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBddns\-ttl\fP \- در صورت تعیین شدن و بزرگ‌تر بودن از ۰، بدون قید و شرط به عنوان مقدار TTL استفاده می‌شود. این پارامتر بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض تعیین‌نشده است. .IP \(bu 2 \fBddns\-ttl\-percent\fP \- در صورت تعیین شدن و بزرگ‌تر بودن از صفر، به عنوان درصد طول عمر اجاره استفاده می‌شود، در غیر این صورت از ۱/۳ (بر اساس RFC 4702) طول عمر اجاره استفاده خواهد شد. این مقدار به‌صورت یک درصد اعشاری (مانند 0.75، 0.50) مشخص می‌شود و به‌طور پیش‌فرض تعیین‌نشده است. .IP \(bu 2 \fBddns\-ttl\-min\fP \- در صورت تعیین شدن و بزرگ‌تر بودن از ۰، به عنوان حداقل مقدار استفاده می‌شود، در غیر این صورت حداقل ۶۰۰ ثانیه (بر اساس RFC 4702) در نظر گرفته خواهد شد. اگر TTL محاسبه‌شده کمتر از مقدار حداقل باشد، مقدار حداقل بازگردانده می‌شود. این پارامتر بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض تعیین‌نشده است. .IP \(bu 2 \fBddns\-ttl\-max\fP \- در صورت تعیین شدن و بزرگ‌تر بودن از صفر، TTL محاسبه‌شده را به این مقدار محدود می‌کند. این پارامتر بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض تعیین‌نشده است. .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مقدار صفر برای هر یک از پارامترهای TTL می‌تواند برای ابطال (یعنی \(dqunspecify\(dq یا لغو تعیین) مقدار به ارث رسیده آن پارامتر از یک حوزه بالاتر استفاده شود. .UNINDENT .UNINDENT.SS اتصالات کارگزار DHCP\-DDNS .sp برای اینکه NCRها به کارگزار D2 برسند، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> باید بتواند با آن ارتباط برقرار کند. \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> از پارامترهای پیکربندی زیر برای کنترل این ارتباط استفاده می‌کند: .INDENT 0.0 .IP \(bu 2 \fBenable\-updates\fP \- این گزینه ارتباط با \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> را فعال می‌کند تا به‌روزرسانی‌های DDNS ایجاد و ارسال شوند. برای اینکه NCRها تولید و به D2 فرستاده شوند، مقدار آن باید \fBtrue\fP باشد. مقدار پیش‌فرض آن \fBfalse\fP است\&. .IP \(bu 2 \fBserver\-ip\fP \- نشانی IPای است که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض، رابط محلی loopback روی نشانی 127.0.0.1 است. می‌توان هر یک از نشانی‌های IPv4 یا IPv6 را مشخص کرد. .IP \(bu 2 \fBserver\-port\fP \- درگاهی است که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض \fB53001\fP است\&. .IP \(bu 2 \fBsender\-ip\fP \- نشانی IPای است که \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> برای ارسال درخواست‌ها به D2 از آن استفاده می‌کند. مقدار پیش‌فرض خالی است که به \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> دستور می‌دهد یک نشانی مناسب را انتخاب کند. .IP \(bu 2 \fBsender\-port\fP \- درگاهی است که \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> برای ارسال درخواست‌ها به D2 استفاده می‌کند. مقدار پیش‌فرض \fB0\fP به \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> اعلام می‌کند یک درگاه مناسب انتخاب کند. .IP \(bu 2 \fBmax\-queue\-size\fP \- حداکثر تعداد درخواست‌هایی است که مجازند در حین انتظار برای ارسال به D2 در صف قرار گیرند. این مقدار از تجمع مهارنشدنی درخواست‌ها در صورتی که سریع‌تر از تحویلشان تولید شوند، جلوگیری می‌کند. اگر تعداد درخواست‌های در صف برای انتقال به این مقدار برسد، به‌روزرسانی DDNS تا زمانی که انباشت صف به اندازه کافی کاهش یابد، متوقف می‌شود. هدف این است که به کارگزار \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> اجازه داده شود بدون مواجه شدن با خطر رشد بی‌رویه مصرف حافظه، به عملیات‌های اجاره (lease) خود ادامه دهد. مقدار پیش‌فرض \fB1024\fP است\&. .IP \(bu 2 \fBncr\-protocol\fP \- پروتکل سوکت مورد استفاده هنگام ارسال درخواست‌ها به D2 را مشخص می‌کند. در حال حاضر فقط از UDP پشتیبانی می‌شود. .IP \(bu 2 \fBncr\-format\fP \- قالب بسته مورد استفاده هنگام ارسال درخواست‌ها به D2 را مشخص می‌کند. در حال حاضر تنها قالب JSON پشتیبانی می‌شود. .UNINDENT .sp به‌طور پیش‌فرض، فرض می‌شود که \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> روی همان دستگاهی اجرا می‌شود که \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> در حال اجرا است، و تمام مقادیر پیش‌فرض ذکرشده در بالا باید کافی باشند. با این حال، اگر D2 برای گوش دادن روی نشانی یا درگاه دیگری پیکربندی شده باشد، این مقادیر باید متناسب با آن تغییر کنند. برای نمونه، اگر D2 برای گوش دادن روی 2001:db8::5 درگاه 900 پیکربندی شده باشد، پیکربندی زیر لازم است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqdhcp\-ddns\(dq: { \(dqserver\-ip\(dq: \(dq2001:db8::5\(dq, \(dqserver\-port\(dq: 900, ... }, ... } .EE .UNINDENT .UNINDENT .SS چه زمانی کارگزار \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> یک درخواست DDNS ایجاد می‌کند؟ .sp کارگزار \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> از رفتار تعیین‌شده برای کارگزارهای DHCP در RFC 4704 \%\& پیروی می‌کند. باید در نظر داشت که \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> تصمیم اولیه درباره زمان و موارد به‌روزرسانی را اتخاذ کرده و این اطلاعات را در قالب NCRها به D2 هدایت می‌کند. انجام به‌روزرسانی‌های واقعی DNS و مدیریت مواردی چون حل تعارض، در حیطه وظایف خود D2 است (نگاه کنید به کارگزار DHCP\-DDNS \%<#\:dhcp-ddns-server>). این بخش شرح می‌دهد که چه زمانی \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> اقدام به تولید NCRها می‌کند و کدام پارامترهای پیکربندی می‌توانند بر این تصمیم اثر بگذارند. فرض بر این است که هم پارامتر ارتباطی \fBenable\-updates\fP و هم پارامتر رفتاری \fBddns\-send\-updates\fP برابر با \fBtrue\fP باشند\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر رابط میان \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> و D2 تنها از درخواست‌هایی پشتیبانی می‌کند که مدخل‌های DNS را برای یک نشانی IP منفرد به‌روزرسانی می‌کنند. اگر یک اجاره بیش از یک نشانی اعطا کند، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> درخواست به‌روزرسانی DDNS را فقط برای نخستین نشانی از این نشانی‌ها تولید می‌کند. .UNINDENT .UNINDENT .sp به‌طور کلی، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> درخواست‌های به‌روزرسانی DDNS را در شرایط زیر ایجاد می‌کند: .INDENT 0.0 .IP 1. 3 یک اجاره جدید در پاسخ به یک DHCPREQUEST اعطا شود؛ .IP 2. 3 یک اجاره موجود تمدید شود اما FQDN مرتبط با آن تغییر کرده باشد؛ یا .IP 3. 3 یک اجاره موجود در پاسخ به یک DHCPRELEASE آزاد شود. .UNINDENT .sp در حالت دوم، یعنی تمدید اجاره، دو درخواست DDNS صادر می‌شود: یک درخواست برای حذف مدخل‌ها برای FQDN قبلی، و درخواست دوم برای افزودن مدخل‌ها برای FQDN جدید. در حالت سوم، آزادسازی اجاره \- یک درخواست DDNS تکی \- برای حذف مدخل‌های آن ارسال خواهد شد. .sp اما در مورد حالت اول، تصمیم‌گیری‌های مربوط به اعطای اجاره جدید پیچیده‌تر است. هنگامی که اجاره جدیدی اعطا می‌شود، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> تنها در صورتی درخواست به‌روزرسانی DDNS ایجاد می‌کند که DHCPREQUEST حاوی گزینه FQDN (کد 39) باشد. به‌طور پیش‌فرض، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> به پرچم‌های N و S مربوط به FQDN که توسط سرویس‌گیرنده مشخص شده‌اند همان‌گونه که در جدول زیر نشان داده شده، احترام می‌گذارد: .SS رفتار پیش‌فرض پرچم‌های FQDN .TS box center; l|l|l|l. T{ پرچم‌های سرویس‌گیرنده: N\-S T} T{ هدف سرویس‌گیرنده T} T{ پاسخ کارگزار T} T{ پرچم‌های کارگزار: N\-S\-O T} _ T{ 0\-0 T} T{ سرویس‌گیرنده مایل به انجام به‌روزرسانی‌های مستقیم است، کارگزار باید به‌روزرسانی‌های معکوس را انجام دهد T} T{ کارگزار درخواستی فقط برای معکوس تولید می‌کند T} T{ 1\-0\-0 T} _ T{ 0\-1 T} T{ کارگزار باید هم به‌روزرسانی‌های مستقیم و هم معکوس را انجام دهد T} T{ کارگزار درخواستی برای به‌روزرسانی هر دو جهت تولید می‌کند T} T{ 0\-1\-0 T} _ T{ 1\-0 T} T{ سرویس‌گیرنده مایل به انجام هیچ به‌روزرسانی‌ای نیست T} T{ کارگزار درخواستی تولید نمی‌کند T} T{ 1\-0\-0 T} .TE .sp سطر نخست در جدول بالا نمایانگر \(dqواگذاری سرویس‌گیرنده\(dq (client delegation) است. در اینجا سرویس‌گیرنده DHCP اعلام می‌کند که قصد دارد به‌روزرسانی‌های مستقیم DNS را خود انجام دهد و کارگزار باید به‌روزرسانی‌های معکوس را انجام دهد. به‌طور پیش‌فرض، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> به خواسته سرویس‌گیرنده احترام گذاشته و یک درخواست DDNS به کارگزار D2 برای به‌روزرسانی داده‌های معکوس DNS تولید می‌کند. می‌توان از پارامتر \fBddns\-override\-client\-update\fP برای دستور به کارگزار جهت نادیده‌گرفتن درخواست‌های واگذاری سرویس‌گیرنده استفاده کرد. هنگامی که این پارامتر \fBtrue\fP باشد، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> درخواست‌های واگذاری سرویس‌گیرنده را نادیده گرفته و یک درخواست DDNS برای به‌روزرسانی داده‌های مستقیم و معکوس DNS تولید می‌کند. در این حالت، پرچم‌های N\-S\-O در پاسخ کارگزار به سرویس‌گیرنده به ترتیب 0\-1\-1 خواهد بود. .sp (توجه داشته باشید که بر اساس RFC 4702 \%\&، ترکیب پرچم‌های N=1 و S=1 ممنوع است. در صورت دریافت چنین ترکیبی از سرویس‌گیرنده، بسته توسط \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> دور انداخته خواهد شد\&.) .sp برای نادیده‌گرفتن واگذاری سرویس‌گیرنده، مقادیر زیر را در فایل پیکربندی تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqddns\-override\-client\-update\(dq: true, ... } .EE .UNINDENT .UNINDENT .sp سطر سوم جدول بالا حالتی را شرح می‌دهد که در آن سرویس‌گیرنده درخواست می‌کند هیچ به‌روزرسانی DNS انجام نشود. می‌توان از پارامتر \fBddns\-override\-no\-update\fP برای دستور به کارگزار جهت نادیده گرفتن خواسته سرویس‌گیرنده استفاده کرد. هنگامی که این پارامتر \fBtrue\fP باشد، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> حتی اگر سرویس‌گیرنده درخواست کرده باشد که هیچ به‌روزرسانی‌ای صورت نگیرد، درخواست‌های به‌روزرسانی DDNS را به \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> ارسال می‌کند. پرچم‌های N\-S\-O در پاسخ کارگزار به سرویس‌گیرنده 0\-1\-1 خواهد بود. .sp برای نادیده‌گرفتن واگذاری سرویس‌گیرنده، پیکربندی زیر را اعمال کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqddns\-override\-no\-update\(dq: true, ... } .EE .UNINDENT .UNINDENT .sp کارگزار \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> در صورتی که درخواست سرویس‌گیرنده فقط شامل گزینه Host Name باشد، همیشه درخواست‌های به‌روزرسانی DDNS را تولید می‌کند. علاوه بر این، یک گزینه FQDN را با پرچم‌های FQDN N\-S\-O که به ترتیب روی 0\-1\-0 تنظیم شده‌اند، در پاسخ به سرویس‌گیرنده قرار می‌دهد. بخش نام دامنه از گزینه FQDN، همان نامی است که در درخواست به‌روزرسانی DDNS به D2 ارسال می‌شود..SS \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> تولید نام برای درخواست‌های به‌روزرسانی DDNS .sp هر NameChangeRequest مسلماً باید شامل نام دامنه کاملاً واجد شرایط (FQDN) باشد که مدخل‌های DNS آن قرار است تحت تأثیر قرار گیرند. \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> می‌تواند به‌گونه‌ای پیکربندی شود که بخشی از آن نام یا تمامی آن را بر اساس آنچه از کارخواه در DHCPREQUEST دریافت می‌کند، تأمین نماید. .sp قوانین پیش‌فرض برای ساخت FQDN که برای مدخل‌های DNS استفاده خواهد شد عبارتند از: .INDENT 0.0 .IP 1. 3 اگر DHCPREQUEST شامل گزینه FQDN کارخواه باشد، نام کاندید از آن گرفته می‌شود. .IP 2. 3 اگر نام کاندید یک نام جزئی (یعنی نامشخص یا فاقد صلاحیت) باشد، یک پسوند قابل‌پیکربندی به نام افزوده شده و از نتیجه به‌عنوان FQDN استفاده می‌شود. .IP 3. 3 اگر نام کاندید ارائه‌شده خالی باشد، با استفاده از یک پیشوند و پسوند قابل‌پیکربندی، یک FQDN تولید می‌شود. .IP 4. 3 اگر کارخواه هیچ‌یک از گزینه‌ها را ارائه نکند، هیچ اقدامی روی DNS صورت نمی‌گیرد. .UNINDENT .sp این قوانین را می‌توان با تنظیم پارامتر \fBddns\-replace\-client\-name\fP اصلاح کرد، که حالت‌های رفتاری زیر را فراهم می‌کند: .INDENT 0.0 .IP \(bu 2 \fBnever\fP \- استفاده از نام ارسالی کارخواه. اگر کارخواه نامی ارسال نکرده باشد، نامی تولید نمی‌شود. این حالت پیش‌فرض است. .IP \(bu 2 \fBalways\fP \- جایگزینی نام ارسالی کارخواه. اگر کارخواه نامی ارسال نکرده باشد، یک نام برای کارخواه تولید می‌شود. .IP \(bu 2 \fBwhen\-present\fP \- جایگزینی نام ارسالی کارخواه. اگر کارخواه نامی ارسال نکرده باشد، نامی تولید نمی‌شود. .IP \(bu 2 \fBwhen\-not\-present\fP \- استفاده از نام ارسالی کارخواه. اگر کارخواه نامی ارسال نکرده باشد، یک نام برای کارخواه تولید می‌شود. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در نسخه‌های اولیه Kea، این پارامتر بولی بود و فقط مقادیر \fBtrue\fP و \fBfalse\fP\& را مجاز می‌دانست. مقادیر بولی منسوخ شده‌اند و دیگر پذیرفته نمی‌شوند؛ مدیرانی که در حال حاضر از مقادیر بولی استفاده می‌کنند باید آن‌ها را با نام حالت مورد نظر جایگزین کنند. مقدار \fBtrue\fP به \fBwhen\-present\fP و مقدار \fBfalse\fP به \fBnever\fP\& نگاشت می‌شود. .UNINDENT .UNINDENT .sp برای نمونه، جهت دستور دادن به \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> برای تولید همیشگی FQDN برای یک کارخواه، پارامتر \fBddns\-replace\-client\-name\fP را مانند زیر روی \fBalways\fP تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqddns\-replace\-client\-name\(dq: \(dqalways\(dq, ... } .EE .UNINDENT .UNINDENT .sp پیشوند مورداستفاده در تولید FQDN توسط پارامتر \fBddns\-generated\-prefix\fP مشخص می‌شود. مقدار پیش‌فرض \(dqmyhost\(dq است. برای تغییر مقدار آن، کافی است آن را روی رشته دلخواه تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqddns\-generated\-prefix\(dq: \(dqanother.host\(dq, ... } .EE .UNINDENT .UNINDENT .sp پسوند مورداستفاده هنگام تولید یک FQDN، یا هنگام کامل‌سازی یک نام جزئی، توسط پارامتر \fBddns\-qualifying\-suffix\fP مشخص می‌شود. اکیداً توصیه می‌شود که در صورت فعال بودن به‌روزرسانی‌های DDNS، کاربر مقداری را برای پسوند صلاحیت‌بخش تعیین کند. به دلایل آشکار، ما نمی‌توانیم یک مقدار پیش‌فرض معنادار ارائه دهیم. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqddns\-qualifying\-suffix\(dq: \(dqfoo.example.org\(dq, ... } .EE .UNINDENT .UNINDENT .sp هنگام کامل‌سازی یک نام جزئی، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> نام را در قالب زیر می‌سازد: .sp \fB[candidate\-name].[ddns\-qualifying\-suffix].\fP .sp که در آن \fBcandidate\-name\fP همان نام جزئی ارائه‌شده در DHCPREQUEST است. برای نمونه، اگر مقدار نام دامنه FQDN برابر با \(dqsome\-computer\(dq و مقدار \fBddns\-qualifying\-suffix\fP برابر با \(dqexample.com\(dq باشد، FQDN تولیدشده عبارت خواهد بود از: .sp \fBsome\-computer.example.com.\fP .sp هنگام تولید نام کامل، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> نام را در قالب زیر می‌سازد: .sp \fB[ddns\-generated\-prefix]\-[address\-text].[ddns\-qualifying\-suffix].\fP .sp که در آن \fBaddress\-text\fP صرفاً همان آدرس IP اجاره (lease) است که به رشته‌ای جداشده با خط تیره تبدیل شده است. برای نمونه، اگر آدرس اجاره 3001:1::70E باشد، پسوند صلاحیت‌بخش \(dqexample.com\(dq باشد و از مقدار پیش‌فرض برای \fBddns\-generated\-prefix\fP استفاده شود، FQDN تولیدشده عبارت است از: .sp \fBmyhost\-3001\-1\-\-70E.example.com.\fP .sp از نسخه 2.7.8 برنامه Kea به بعد، پیشوندهای تولیدشده‌ای که به خط تیره ختم می‌شدند، یک صفر به انتهای آن‌ها اضافه خواهد شد. برای مثال، پیشوند تولیدشده برای آدرس \(dq2001:db8:1::\(dq به صورت \(dqmyhost\-2001\-db8\-1\-\-0\(dq خواهد بود..SS پالایش نام‌های FQDN کلاینت .sp برخی از کلاینت‌های DHCP ممکن است مقادیری را در مؤلفهٔ نام از گزینهٔ FQDN (کد گزینهٔ ۳۹) ارائه دهند که حاوی نویسه‌های نامطلوب باشد. می‌توان \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> را برای پالایش این مقادیر پیکربندی کرد. معمول‌ترین مورد کاربرد، اطمینان از این است که تنها نویسه‌های مجاز طبق RFC 1035 شامل شوند: A\-Z،‏ a\-z،‏ 0\-9 و \(dq\-\(dq. این کار می‌تواند با دو پارامتر زیر انجام شود: .INDENT 0.0 .IP \(bu 2 \fBhostname\-char\-set\fP \- یک عبارت باقاعده که مجموعه نویسه‌های نامعتبر را توصیف می‌کند. این مقدار می‌تواند هر عبارت باقاعدهٔ معتبری با استفاده از نحو عبارات گسترش‌یافتهٔ POSIX باشد. نویسه‌های تهی نشانده‌شده (0x00) همواره به عنوان یک نویسهٔ نامعتبر در نظر گرفته می‌شوند تا جایگزین (یا حذف) شوند. پیش‌فرض \fB\(dq[^A\-Za\-z0\-9.\-]\(dq\fP\& است. این عبارت با هر نویسه‌ای که حرف، رقم، نقطه یا خط پیوند نباشد مطابقت دارد. اکیداً توصیه می‌شود که این مقدار بر روی یک رشتهٔ خالی (\fB\(dq\(dq\fP) تنظیم نشود، زیرا این کار اجازه می‌دهد نویسه‌های غیرقابل‌چاپ در مؤلفهٔ hostname استفاده شوند. .IP \(bu 2 \fBhostname\-char\-replacement\fP \- رشته‌ای از صفر یا چند نویسه که هر نویسهٔ نامعتبر در نام میزبان با آن جایگزین می‌شود. یک رشتهٔ خالی باعث می‌شود نویسه‌های نامعتبر به‌جای جایگزین شدن، حذف (OMITTED) شوند. پیش‌فرض \fB\(dq\(dq\fP\& است. .UNINDENT .sp پیکربندی زیر هر چیزی غیر از یک حرف، رقم، نقطه یا خط پیوند را با حرف \(dqx\(dq جایگزین می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhostname\-char\-set\(dq: \(dq[^A\-Za\-z0\-9.\-]\(dq, \(dqhostname\-char\-replacement\(dq: \(dqx\(dq, ... } .EE .UNINDENT .UNINDENT .sp بدین ترتیب، مقدار ارائه‌شده توسط کلاینت مانند \(dqmyhost\-$[123.org\(dq به \(dqmyhost\-xx123.org\(dq تبدیل خواهد شد. پالایش تنها روی بخشی از نام که توسط کلاینت ارائه شده انجام می‌گیرد، و قبل از اعمال پسوند صلاحیت‌بخش (در صورت تعریف و نیاز) اعمال می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هدف از پالایش نام، پوشش دادن حالت‌های متداول‌تر نویسه‌های نامعتبر از طریق یک طرح نسبتاً سادهٔ جایگزینی نویسه است. ابداع طرحی که در همهٔ موارد به‌خوبی کار کند دشوار است. مدیرانی که کلاینت‌هایی با موارد خاص و نامتعارف از ترکیب نویسه‌ها دارند که به‌سادگی با این سازوکار قابل مدیریت نیست، باید نوشتن یک قلاب (hook) را مد نظر قرار دهند که بتواند منطق به‌اندازهٔ کافی پیچیده‌ای را برای برآورده کردن نیازهایشان اجرا کند. .sp اطمینان حاصل کنید که نقطه، یعنی \(dq.\(dq، توسط عبارت \fBhostname\-char\-set\fP به عنوان یک نویسهٔ معتبر در نظر گرفته شود، مانند این: \fB\(dq[^A\-Za\-z0\-9.\-]\(dq\fP\&. هنگام پالایش FQDNها، نقطه‌ها به عنوان جداکننده تلقی شده و برای تفکیک مقدار گزینه به برچسب‌های دامنهٔ جداگانه که پالایش شده و سپس مجدداً سرهم می‌شوند، به کار می‌روند. .sp اگر کلاینت‌ها مقادیری را ارسال می‌کنند که تفاوت آن‌ها فقط در نویسه‌هایی است که توسط \fBhostname\-char\-set\fP نامعتبر شمرده شده‌اند، آگاه باشید که پالایش آن‌ها به مقادیر یکسان منجر خواهد شد. در چنین مواردی، قواعد تداخل DDNS تنها به یکی از آن‌ها اجازهٔ ثبت نام را می‌دهد. .sp در نهایت، با توجه به اختیاری که کلاینت‌ها در ارسال مقادیر دارند، عملاً غیرممکن است تضمین شود که ترکیبی از این دو پارامتر همیشه نامی معتبر برای استفاده در DNS به دست دهد. برای نمونه، استفاده از یک مقدار خالی برای \fBhostname\-char\-replacement\fP در صورتی که برچسب دامنه تنها از نویسه‌های نامعتبر تشکیل شده باشد، می‌تواند منجر به یک برچسب خالی درون یک نام شود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 امکان تعیین \fBhostname\-char\-set\fP و/یا \fBhostname\-char\-replacement\fP در حوزهٔ سراسری (global scope) وجود دارد. .sp کتابخانهٔ قلاب کئا با نام \fBlibdhcp_ddns_tuning.so\fP \%<#\:std-ischooklib-libdhcp_ddns_tuning\:.so> این قابلیت را برای هر دوی \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> فراهم می‌کند تا نام‌های میزبان را به‌طور رویه‌ای بر پایه یک عبارت ایجاد کنند، از به‌روزرسانی‌های DDNS به‌ازای هر کلاینت صرف‌نظر نمایند، یا جنبه‌های مختلف به‌روزرسانی DNS را به‌دقت تنظیم کنند. لطفاً برای گزینه‌های پیکربندی به مستندات libdhcp_ddns_tuning.so: DDNS Tuning \%<#\:hooks-ddns-tuning> مراجعه نمایید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 3.1.3 به بعد، هنگامی که پالایش منجر به یک رشتهٔ خالی شود، گزینهٔ FQDN به‌گونه‌ای نادیده گرفته خواهد شد که گویی کلاینت اصلاً آن را ارسال نکرده است. این موضوع می‌تواند در صورتی رخ دهد که مقدار ارسال‌شده توسط کلاینت تنها شامل نویسه‌هایی باشد که توسط عبارت در \(aqhostname\-char\-set\(aq نامعتبر شمرده شده و \(aqhostname\-char\-replacement\(aq نیز خالی، یعنی \(dq\(dq باشد. .UNINDENT .UNINDENT .SS DHCPv4\-over\-DHCPv6: سمت DHCPv6 .sp پشتیبانی از انتقال DHCPv4\-over\-DHCPv6 در RFC 7341 \% شرح داده شده است و با استفاده از همکاری سرورهای DHCPv4 و DHCPv6 پیاده‌سازی می‌شود. این بخش دربارهٔ پیکربندی سمت DHCPv6 است (سمت DHCPv4 در DHCPv4\-over\-DHCPv6: DHCPv4 Side \%<#\:dhcp4-dhcp4o6-config> شرح داده شده است). .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 جزئیات ارتباط بین‌فرآیندی در DHCPv4\-over\-DHCPv6 ممکن است تغییر کند؛ برای نمونه، پشتیبانی از رله پورت (RFC 8357) یک تغییر ناسازگار معرفی کرد. هر دو سمت DHCPv4 و DHCPv6 باید نسخهٔ یکسانی از Kea را اجرا کنند. .UNINDENT .UNINDENT .sp تنها یک پارامتر ویژه برای سمت DHCPv6 وجود دارد: \fBdhcp4o6\-port\fP، که نخستین پورت از دو پورت متوالی سوکت‌های UDP مورد استفاده برای ارتباط میان سرورهای DHCPv6 و DHCPv4 را مشخص می‌کند. سرور DHCPv6 به ::1 روی \fBport\fP مقید (bind) شده و به ::1 روی \fBport\fP + 1 متصل می‌شود. .sp دو مدخل پیکربندی دیگر نیز معمولاً الزامی هستند: پشتیبانی از ترافیک Unicast (بخش Unicast Traffic Support را ببینید) و گزینهٔ آدرس سرور DHCP 4o6 (نام \(dqdhcp4o6\-server\-addr\(dq، کد 88). .sp شرکت ISC پیکربندی زیر را آزمایش کرده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { # DHCPv6 conf \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeno33554984/2001:db8:1:1::1\(dq ] }, \(dqlease\-database\(dq: { \(dqtype\(dq: \(dqmemfile\(dq, \(dqname\(dq: \(dqleases6\(dq }, \(dqpreferred\-lifetime\(dq: 3000, \(dqvalid\-lifetime\(dq: 4000, \(dqrenew\-timer\(dq: 1000, \(dqrebind\-timer\(dq: 2000, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1:1::/64\(dq, \(dqinterface\(dq: \(dqeno33554984\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1:1::1:0/112\(dq } ] } ], \(dqdhcp4o6\-port\(dq: 786, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdhcp4o6\-server\-addr\(dq, \(dqcode\(dq: 88, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq2001:db8:1:1::1\(dq } ], \(dqloggers\(dq: [ { \(dqname\(dq: \(dqkea\-dhcp6\(dq, \(dqoutput\-options\(dq: [ { \(dqoutput\(dq: \(dqkea\-dhcp6.log\(dq } ], \(dqseverity\(dq: \(dqDEBUG\(dq, \(dqdebuglevel\(dq: 0 } ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پیام‌های بازپخش‌شدهٔ (Relayed) DHCPv6 از نوع DHCPv4\-QUERY پشتیبانی نمی‌شوند. .UNINDENT .UNINDENT.SS بررسی‌های صحت در DHCPv6 .sp یک جنبه مهم از یک سامانه DHCP با عملکرد مناسب، اطمینان از سازگار ماندن داده‌ها است؛ با این حال، در برخی موارد ممکن است تحمل برخی داده‌های ناسازگار مناسب باشد. برای مثال، یک مدیر شبکه که به طور موقت یک زیرشبکه را از پیکربندی حذف می‌کند، مایل نیست تمام اجاره‌های مرتبط با آن از پایگاه‌داده اجاره‌ها ناپدید شوند. Kea سازوکاری برای پیاده‌سازی بررسی‌های صحت برای شرایطی از این دست دارد. .sp Kea از یک حوزه پیکربندی به نام \fBsanity\-checks\fP پشتیبانی می‌کند. پارامتری به نام \fBlease\-checks\fP، اعتبارسنجی انجام‌شده هنگام بارگذاری یک اجاره جدید از یک فایل اجاره را کنترل می‌کند. این سازوکار به Kea اجازه می‌دهد تا برای اصلاح داده‌های ناسازگار تلاش کند. .sp هر زیرشبکه دارای یک مقدار \fBsubnet\-id\fP است؛ Kea به این صورت در داخل زیرشبکه‌ها را شناسایی می‌کند. هر اجاره نیز دارای پارامتر \fBsubnet\-id\fP است که زیرشبکه متعلق به آن را مشخص می‌کند. با این حال، اگر پیکربندی تغییر کرده باشد، ممکن است اجاره‌ای با یک \fBsubnet\-id\fP وجود داشته باشد بدون اینکه هیچ زیرشبکه منطبقی با آن یافت شود. همچنین، این احتمال وجود دارد که پیکربندی زیرشبکه تغییر کرده باشد و \fBsubnet\-id\fP اکنون متعلق به زیرشبکه‌ای باشد که با اجاره مطابقت ندارد. .sp الگوریتم اصلاحی Kea ابتدا بررسی می‌کند که آیا زیرشبکه‌ای با \fBsubnet\-id\fP مشخص‌شده توسط اجاره وجود دارد یا خیر. اگر وجود داشته باشد، بررسی می‌کند که آیا اجاره متعلق به آن زیرشبکه است یا خیر. در غیر این صورت، بسته به تنظیمات \fBlease\-checks\fP، اجاره دور انداخته می‌شود، یک هشدار نمایش داده می‌شود، یا زیرشبکه جدیدی برای اجاره انتخاب می‌شود که از نظر مکان‌شناسی (topologically) با آن همخوانی دارد. .sp از آنجا که پیشوندهای تفویض‌شده (delegated prefixes) لزوماً نباید متعلق به زیرشبکه‌ای باشند که در آن ارائه می‌شوند، راهی برای پیاده‌سازی چنین سازوکاری برای پیشوندهای IPv6 وجود ندارد. به همین دلیل، این سازوکار تنها برای آدرس‌های IPv6 کار می‌کند. .sp پنج سطح پشتیبانی می‌شود: .INDENT 0.0 .IP \(bu 2 \fBnone\fP \- هیچ بررسی خاصی انجام نده؛ اجاره را همان‌گونه که هست بپذیر. .IP \(bu 2 \fBwarn\fP \- در صورت شناسایی مشکلات، یک هشدار نمایش بده، اما به هر حال داده‌های اجاره را بپذیر. این مقدار پیش‌فرض است. .IP \(bu 2 \fBfix\fP \- در صورت کشف ناسازگاری در داده‌ها، سعی در اصلاح آن کن. اگر اصلاح موفقیت‌آمیز نبود، به هر حال داده‌های نادرست را درج کن. .IP \(bu 2 \fBfix\-del\fP \- در صورت کشف ناسازگاری در داده‌ها، سعی در اصلاح آن کن. اگر اصلاح موفقیت‌آمیز نبود، اجاره را رد کن. این تنظیم صحت داده‌ها را تضمین می‌کند، اما ممکن است برخی از داده‌های نادرست از دست بروند. با احتیاط استفاده شود. .IP \(bu 2 \fBdel\fP \- در صورت شناسایی هرگونه ناسازگاری، اجاره را رد کن. این سخت‌گیرانه‌ترین حالت است؛ با احتیاط استفاده شود. .UNINDENT .sp این ویژگی در حال حاضر برای backend memfile پیاده‌سازی شده است. بررسی صحت روی پایگاه‌داده اجاره در حافظه اعمال می‌شود، نه روی فایل اجاره؛ یعنی اجاره‌های ناسازگار در فایل اجاره باقی خواهند ماند. .sp یک نمونه پیکربندی که این پارامتر را تنظیم می‌کند به شرح زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsanity\-checks\(dq: { \(dqlease\-checks\(dq: \(dqfix\-del\(dq }, ... } .EE .UNINDENT .UNINDENT .SS ذخیره‌سازی اطلاعات توسعه‌یافته اجاره .sp برای پشتیبانی از ویژگی‌هایی مانند DHCPv6 Reconfigure (RFC 3315 \%) و Leasequery (RFC 5007 \%)، اطلاعات تکمیلی باید همراه با هر اجاره ذخیره شود. از آنجا که حجم اطلاعات ذخیره‌شده برای هر اجاره پیامدهایی از نظر عملکرد و مصرف منابع سیستم دارد، ذخیره‌سازی این اطلاعات تکمیلی از طریق پارامتر \fBstore\-extended\-info\fP قابل پیکربندی است. مقدار پیش‌فرض آن \fBfalse\fP است و ممکن است در سطوح سراسری (global)، shared\-network، و زیرشبکه تنظیم شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqstore\-extended\-info\(dq: true, ... } .EE .UNINDENT .UNINDENT .sp هنگامی که روی \fBtrue\fP تنظیم شود، اطلاعات مربوط به پرس‌وجوی DHCPv6 (مانند REQUEST، RENEW، یا REBIND) که اجاره را درخواست می‌کند، به عنوان یک عنصر نگاشت با برچسب \(dqISC\(dq به \fBuser\-context\fP اجاره اضافه می‌شود. در حال حاضر، اطلاعات موجود در این نگاشت فهرستی از رله‌ها است؛ یکی برای هر لایه پیام رله که پرس‌وجوی کلاینت را در بر می‌گیرد. \fBuser\-context\fP اجاره برای یک پرس‌وجوی با دو جهش (two\-hop) ممکن است چیزی شبیه به این باشد (برای وضوح بیشتر به صورت ساختاریافته نمایش داده شده است): .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqISC\(dq: { \(dqrelay\-info\(dq: [ { \(dqhop\(dq: 3, \(dqlink\(dq: \(dq2001:db8::1\(dq, \(dqpeer\(dq: \(dq2001:db8::2\(dq }, { \(dqhop\(dq: 2, \(dqlink\(dq: \(dq2001:db8::3\(dq, \(dqoptions\(dq: \(dq0x00C800080102030405060708\(dq, \(dqpeer\(dq: \(dq2001:db8::4\(dq }, { \(dqhop\(dq: 1, \(dqlink\(dq: \(dq2001:db8::5\(dq, \(dqoptions\(dq: \(dq0x00250006010203040506003500086464646464646464\(dq, \(dqremote\-id\(dq: \(dq010203040506\(dq, \(dqrelay\-id\(dq: \(dq6464646464646464\(dq } ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پیش از نسخه 2.3.2 برنامه Kea، این ورودی \fBrelays\fP نامیده می‌شد؛ گزینه‌های شناسه‌گر راه دور (remote) و رله رمزگشایی نمی‌شدند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این احتمال وجود دارد که سایر کتابخانه‌های قلاب (hook libraries) قبلاً از \fBuser\-context\fP استفاده کرده باشند. فعال کردن \fBstore\-extended\-info\fP نباید با محتوای دیگر \fBuser\-context\fP تداخلی ایجاد کند، تا زمانی که آن‌ها نیز از عنصری با برچسب \(dqISC\(dq استفاده نکنند. به عبارت دیگر، \fBuser\-context\fP به عنوان یک ظرف انعطاف‌پذیر برای برآورده کردن اهداف متعدد در نظر گرفته شده است. تا زمانی که هدف دیگری نیز یک عنصر \(dqISC\(dq در \fBuser\-context\fP ننویسد، نباید هیچ تداخلی وجود داشته باشد. .UNINDENT .UNINDENT .sp اطلاعات توسعه‌یافته اجاره نیز مشمول بررسی صحت قابل پیکربندی است. پارامتر موجود در حوزه \fBsanity\-checks\fP به نام \fBextended\-info\-checks\fP است و از این سطوح پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBnone\fP \- هیچ بررسی یا ارتقایی انجام نده. این سطح فقط باید زمانی استفاده شود که از اطلاعات توسعه‌یافته اصلاً استفاده نمی‌شود یا انتظار هیچ اطلاعات توسعه‌یافته با قالب‌بندی نادرست، از جمله استفاده از قالب قدیمی، وجود ندارد. .IP \(bu 2 \fBfix\fP \- برخی از ناسازگاری‌های رایج را برطرف کن و اطلاعات توسعه‌یافته با قالب قدیمی را به قالب جدید ارتقا بده. این سطح پیش‌فرض است و زمانی مناسب است که کتابخانه قلاب Leasequery بارگذاری نشده باشد. .IP \(bu 2 \fBstrict\fP \- تمام ناسازگاری‌هایی را که بر کتابخانه قلاب (Bulk) Leasequery تأثیر دارند، برطرف کن. .IP \(bu 2 \fBpedantic\fP \- انطباق کامل با قالبی که توسط کد Kea تولید می‌شود را اعمال کن؛ برای مثال، به استثنای \fBcomment\fP هیچ ورودی اضافه دیگری مجاز نیست. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این ویژگی در حال حاضر تنها برای backend memfile پیاده‌سازی شده است. بررسی صحت روی پایگاه‌داده اجاره در حافظه اعمال می‌شود، نه روی فایل اجاره؛ یعنی اجاره‌های ناسازگار در فایل اجاره باقی می‌مانند. .UNINDENT .UNINDENT.SS تنظیمات چندریسمانی (Multi\-Threading Settings) .sp سرور Kea را می‌توان برای پردازش موازی بسته‌ها با استفاده از چند ریسمان (thread) پیکربندی کرد. این تنظیمات در ساختار \fBmulti\-threading\fP یافت می‌شوند و با پارامترهای زیر مشخص می‌گردند: .INDENT 0.0 .IP \(bu 2 \fBenable\-multi\-threading\fP \- استفاده از چندین ریسمان برای پردازش موازی بسته‌ها. مقدار پیش‌فرض \fBtrue\fP است\&. .IP \(bu 2 \fBthread\-pool\-size\fP \- تعیین تعداد ریسمان‌ها برای پردازش موازی بسته‌ها. می‌تواند روی \fB0\fP (تشخیص خودکار) یا هر عدد مثبتی که تعداد ریسمان‌ها را به‌طور صریح مشخص کند تنظیم شود. مقدار پیش‌فرض \fB0\fP است\&. .IP \(bu 2 \fBpacket\-queue\-size\fP \- تعیین اندازهٔ صف مورد استفاده توسط استخر ریسمان (thread pool) برای پردازش بسته‌ها. می‌تواند روی \fB0\fP (نامحدود) یا هر عدد مثبتی که اندازهٔ صف را به‌طور صریح مشخص کند تنظیم شود. مقدار پیش‌فرض \fB64\fP است\&. .UNINDENT .sp یک نمونه پیکربندی که این پارامترها را تنظیم می‌کند به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqmulti\-threading\(dq: { \(dqenable\-multi\-threading\(dq: true, \(dqthread\-pool\-size\(dq: 4, \(dqpacket\-queue\-size\(dq: 16 }, ... } .EE .UNINDENT .UNINDENT .SS تنظیمات چندریسمانی با پس‌اندهای پایگاه‌داده مختلف (Multi\-Threading Settings With Different Database Backends) .sp سرور Kea DHCPv6 توسط ISC بنچمارک شده است تا مشخص شود چه تنظیماتی بهترین کارایی را ارائه می‌دهند. اگرچه این بخش نتایج ما را شرح می‌دهد، اما آنها صرفاً پیشنهاد هستند و به سخت‌افزار خاص مورد استفاده برای محک‌زنی بستگی زیادی دارند. قویاً توصیه می‌کنیم که مدیران سیستم بنچمارک‌های کارایی مختص به خود را اجرا کنند. .sp گزارش کاملی از نتایج کارایی برای آخرین نسخهٔ پایدار Kea را می‌توان در اینجا یافت: \%\&. این گزارش شامل توضیحات سخت‌افزار و سناریوی بنچمارک، و همچنین نتایج فعلی است. .sp پس از فعال‌سازی چندریسمانی، تعداد ریسمان‌ها با پارامتر \fBthread\-pool\-size\fP تعیین می‌شود. نتایج حاصل از آزمایش‌های ما نشان می‌دهد که بهترین تنظیمات برای \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBthread\-pool\-size\fP: برابر با 4 هنگام استفاده از \fBmemfile\fP برای ذخیرهٔ اجاره‌ها (leases). .IP \(bu 2 \fBthread\-pool\-size\fP: برابر با 12 یا بیشتر هنگام استفاده از \fBmysql\fP برای ذخیرهٔ اجاره‌ها. .IP \(bu 2 \fBthread\-pool\-size\fP: برابر با 6 هنگام استفاده از \fBpostgresql\fP\&. .UNINDENT .sp پارامتر بسیار مهم دیگر \fBpacket\-queue\-size\fP است؛ در بنچمارک‌هایمان ما آن را به عنوان ضریبی از \fBthread\-pool\-size\fP استفاده کردیم. مقدار واقعی به‌شدت به \fBthread\-pool\-size\fP وابسته است. .sp ما در بنچمارک‌های خود با تنظیمات زیر به بهترین نتایج دست یافتیم: .INDENT 0.0 .IP \(bu 2 \fBpacket\-queue\-size\fP: برابر با 150 * \fBthread\-pool\-size\fP هنگام استفاده از \fBmemfile\fP برای ذخیرهٔ اجاره‌ها؛ در مورد ما، این مقدار 150 * 4 = 600 بود. این بدان معناست که در هر لحظه، حداکثر تا ۶۰۰ بسته می‌توانند در صف قرار گیرند. .IP \(bu 2 \fBpacket\-queue\-size\fP: برابر با 200 * \fBthread\-pool\-size\fP هنگام استفاده از \fBmysql\fP برای ذخیرهٔ اجاره‌ها؛ در مورد ما، این مقدار 200 * 12 = 2400 بود. این بدان معناست که حداکثر تا ۲۴۰۰ بسته می‌توانند در صف قرار گیرند. .IP \(bu 2 \fBpacket\-queue\-size\fP: برابر با 11 * \fBthread\-pool\-size\fP هنگام استفاده از \fBpostgresql\fP برای ذخیرهٔ اجاره‌ها؛ در مورد ما، این مقدار 11 * 6 = 66 بود. .UNINDENT .SS حافظه‌نهان اجاره (Lease Caching) .sp کلاینت‌هایی که در بازهٔ زمانی کوتاهی چندین بار تلاش برای تمدید اجاره می‌کنند، می‌توانند باعث شوند سرور به‌طور مکرر پایگاه‌داده را به‌روزرسانی کرده و در آن بنویسد، که نتیجهٔ آن افت کارایی سرور خواهد بود. پارامترهای حافظه‌نهان (cache) به سرور DHCP دستور می‌دهند که از به‌روزرسانی بیش‌ازحد مکرر اجاره‌ها خودداری کند و بدین ترتیب از این رفتار جلوگیری شود. در عوض، سرور همان اجاره را بدون هیچ تغییری تخصیص می‌دهد (یعنی از آن دوباره استفاده می‌کند)، به‌جز CLTT (Client Last Transmission Time)، که نیازی به عملیات دیسک ندارد. .sp این دو پارامتر عبارتند از عدد اعشاری \fBcache\-threshold\fP و عدد صحیح \fBcache\-max\-age\fP\&. این پارامترها را می‌توان در سطوح سراسری (global)، شبکهٔ مشترک (shared\-network) و زیرشبکه (subnet) پیکربندی کرد. سطح زیرشبکه نسبت به سطح شبکهٔ مشترک اولویت دارد، در حالی که سطح سراسری به عنوان آخرین چاره استفاده می‌شود. به عنوان مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet6\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1:1::1:0/112\(dq } ], \(dqcache\-threshold\(dq: .25, \(dqcache\-max\-age\(dq: 600, \(dqvalid\-lifetime\(dq: 2000, ... } ], \&... } .EE .UNINDENT .UNINDENT .sp هنگامی که یک اجارهٔ از پیش تخصیص‌یافته بتواند به پرس‌وجوی کلاینت پاسخ دهد: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 هرگونه تغییر مهم، به عنوان مثال در پارامتر DDNS، نام میزبان (hostname)، یا کاهش طول عمر ترجیحی یا معتبر، مانع از استفادهٔ مجدد از اجاره می‌شود. .IP \(bu 2 عمر اجاره (lease age)، یعنی تفاوت میان زمان ایجاد یا آخرین تغییر با زمان فعلی، محاسبه می‌شود (مدت‌زمان سپری‌شده). .IP \(bu 2 اگر \fBcache\-max\-age\fP به‌طور صریح پیکربندی شده باشد، با عمر اجاره مقایسه می‌شود؛ اجاره‌هایی که بیش از حد قدیمی باشند قابل استفادهٔ مجدد نیستند. این بدان معناست که مقدار 0 برای \fBcache\-max\-age\fP، قابلیت حافظه‌نهان اجاره را غیرفعال می‌کند. .IP \(bu 2 اگر \fBcache\-threshold\fP به‌طور صریح پیکربندی شده باشد و بین 0.0 و 1.0 باشد، بیانگر درصدی از طول عمر معتبر (valid lifetime) اجاره است که برای عمر اجاره مجاز است. مقادیر کمتر و مساوی 0.0 و مقادیر بیشتر از 1.0، قابلیت حافظه‌نهان اجاره را غیرفعال می‌کنند. .UNINDENT .UNINDENT .UNINDENT .sp در مثال ما، اجاره‌ای با طول عمر معتبر ۲۰۰۰ ثانیه در صورتی می‌تواند مجدداً استفاده شود که کمتر از ۵۰۰ ثانیه پیش ثبت شده باشد. با طول عمر ۳۰۰۰ ثانیه، حداکثر عمر ۶۰۰ ثانیه اعمال می‌شود. .sp در پاسخ‌های خروجی به کلاینت (مانند پیام‌های DHCPV6_REPLY)، طول عمرهای ترجیحی و معتبر استفاده‌شده همان مقادیر قابل استفادهٔ مجدد هستند، یعنی تاریخ‌های انقضا تغییر نمی‌کنند..SS رزروهای میزبان در DHCPv6 .sp موارد متعددی وجود دارد که در آن‌ها ارائهٔ پیکربندی بر مبنای هر میزبان (per\-host) مفید است. بارزترین مورد، رزرو یک نشانی IPv6 یا/و پیشوند مشخص و ایستا برای استفادهٔ انحصاری یک کلاینت (میزبان) خاص است؛ کلاینتِ بازگشتی، هر بار همان نشانی یا/و پیشوند را دریافت می‌کند و سایر کلاینت‌ها هرگز آن نشانی را دریافت نخواهند کرد. همچنین رزروهای میزبان در مواقعی که یک میزبان نیازمندی‌های خاصی دارد، سودمند هستند؛ به عنوان مثال چاپگری که به گزینه‌های DHCP اضافی نیاز دارد یا یک مودم کابلی که به پارامترهای مشخصی نیازمند است. یکی دیگر از موارد کاربرد ممکن، تعریف نام‌های یکتا برای میزبان‌ها است. .sp ممکن است مواردی پیش بیاید که یک رزرو جدید برای کلاینتی انجام شده باشد، در حالی که آن نشانی یا پیشوند در حال حاضر توسط کلاینت دیگری استفاده می‌شود. ما این وضعیت را یک \(dqتداخل\(dq می‌نامیم. این تداخل‌ها، همان‌طور که در بخش‌های بعدی توضیح داده شده است، به مرور زمان به صورت خودکار برطرف می‌شوند. به محض برطرف شدن تداخل، کلاینت صحیح در زمان تمدید، پیکربندی رزروشده را دریافت خواهد کرد. .sp رزروهای میزبان به عنوان پارامترهایی برای هر زیرشبکه تعریف می‌شوند. هر میزبان باید یا با DUID یا با نشانی سخت‌افزاری/MAC خود شناسایی شود؛ برای جزئیات به MAC/Hardware Addresses in DHCPv6 مراجعه کنید. یک آرایهٔ اختیاری \fBreservations\fP در ساختار \fBsubnet6\fP وجود دارد؛ هر عنصر در آن آرایه ساختاری است که اطلاعات مربوط به رزروها را برای یک میزبان منفرد نگه می‌دارد. به طور خاص، این ساختار دارای یک شناسه است که یک میزبان را به طور یکتا مشخص می‌کند. در زمینهٔ DHCPv6، این شناسه معمولاً یک DUID است، اما می‌تواند یک نشانی سخت‌افزاری یا MAC نیز باشد. همچنین ممکن است یک یا چند نشانی یا پیشوند مشخص شود، و امکان تعیین hostname و گزینه‌های DHCPv6 برای یک میزبان معین وجود دارد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نشانی رزروشده باید در محدودهٔ زیرشبکه باشد. این موضوع در مورد پیشوندهای رزروشده صدق نمی‌کند. .UNINDENT .UNINDENT .sp مثال زیر نحوهٔ رزرو نشانی‌ها و پیشوندها را برای میزبان‌های مشخص نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::/80\(dq } ], \(dqpd\-pools\(dq: [ { \(dqprefix\(dq: \(dq2001:db8:1:8000::\(dq, \(dqprefix\-len\(dq: 56, \(dqdelegated\-len\(dq: 64 } ], \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq01:02:03:04:05:0A:0B:0C:0D:0E\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1::100\(dq ] }, { \(dqhw\-address\(dq: \(dq00:01:02:03:04:05\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1::101\(dq, \(dq2001:db8:1::102\(dq ] }, { \(dqduid\(dq: \(dq01:02:03:04:05:06:07:08:09:0A\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1::103\(dq ], \(dqprefixes\(dq: [ \(dq2001:db8:2:abcd::/64\(dq ], \(dqhostname\(dq: \(dqfoo.example.com\(dq } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp این مثال شامل رزروهایی برای سه کلاینت مختلف است. رزرو نخست برای نشانی 2001:db8:1::100 و برای کلاینتی است که از DUID با مقدار 01:02:03:04:05:0A:0B:0C:0D:0E استفاده می‌کند. رزرو دوم برای دو نشانی 2001:db8:1::101 و 2001:db8:1::102 برای کلاینتی است که از نشانی MAC با مقدار 00:01:02:03:04:05 استفاده می‌کند. در نهایت، نشانی 2001:db8:1::103 و پیشوند 2001:db8:2:abcd::/64 برای کلاینتی با DUID مقدار 01:02:03:04:05:06:07:08:09:0A رزرو شده‌اند. آخرین رزرو همچنین یک hostname به این کلاینت اختصاص می‌دهد. .sp پروتکل DHCPv6 به یک کلاینت اجازه می‌دهد به طور هم‌زمان چندین نشانی و چندین پیشوند را اجاره کند. بنابراین \fBip\-addresses\fP و \fBprefixes\fP به صورت جمع هستند و در واقع آرایه می‌باشند. هنگامی که کلاینت چندین گزینهٔ IA (از نوع IA_NA یا IA_PD) ارسال می‌کند، هر نشانی یا پیشوند رزروشده به یک IA جداگانه از نوع مناسب اختصاص می‌یابد. اگر تعداد IAهای یک نوع خاص کمتر از تعداد رزروهای آن نوع باشد، تعداد نشانی‌ها یا پیشوندهای رزروشدهٔ اختصاص‌یافته به کلاینت برابر با تعداد IA_NAها یا IA_PDهای ارسال‌شده توسط کلاینت خواهد بود؛ بدین معنی که برخی از نشانی‌ها یا پیشوندهای رزروشده اختصاص نمی‌یابند. با این حال، آن‌ها همچنان برای این کلاینت رزرو باقی می‌مانند و سرور آن‌ها را به هیچ کلاینت دیگری اختصاص نخواهد داد. اگر تعداد IAهای یک نوع خاص که توسط کلاینت ارسال شده است بیشتر از تعداد نشانی‌ها یا پیشوندهای رزروشده باشد، سرور تلاش می‌کند تا تمام نشانی‌ها یا پیشوندهای رزروشده را به تک‌تک IAها اختصاص دهد و نشانی‌ها یا پیشوندها را به صورت پویا به IAهای باقی‌مانده تخصیص دهد. چنانچه سرور نتواند یک نشانی یا پیشوند رزروشده را به دلیل در حال استفاده بودن اختصاص دهد، نشانی یا پیشوند رزروشدهٔ بعدی را انتخاب کرده و تلاش می‌کند آن را به کلاینت اختصاص دهد. اگر سرور متعاقباً دریابد که دیگر هیچ رزروی وجود ندارد که بتوان در آن لحظه به کلاینت اختصاص داد، تلاش خواهد کرد اجاره‌ها را به صورت پویا اختصاص دهد. .sp ایجاد رزرو برای یک میزبان متحرک که ممکن است در چندین زیرشبکه رفت‌وآمد داشته باشد، نیازمند تعریف میزبان جداگانه در هر زیرشبکه‌ای است که انتظار می‌رود میزبان در آن حضور یابد. امکان تعریف چندین تعریف میزبان با یک نشانی سخت‌افزاری یکسان در یک زیرشبکهٔ منفرد وجود ندارد. چند تعریف میزبان با یک نشانی سخت‌افزاری یکسان در صورتی معتبر هستند که هر کدام در زیرشبکهٔ متفاوتی باشند. رزرو برای یک میزبان معین باید تنها شامل یک شناسه باشد، یا DUID یا نشانی سخت‌افزاری؛ تعریف هر دو برای یک میزبان، خطای پیکربندی در نظر گرفته می‌شود. .sp افزودن رزروهای میزبان باعث افت کارایی می‌شود. در اصل، هنگامی که سروری بدون پشتیبانی از رزرو میزبان به یک پرس‌وجو پاسخ می‌دهد، تنها باید بررسی کند که آیا برای نشانی مورد نظر جهت تخصیص یا تمدید، اجاره‌ای وجود دارد یا خیر. اما سروری که از رزرو میزبان پشتیبانی می‌کند باید بررسی‌های بیشتری انجام دهد: نه تنها این که آیا نشانی در حال حاضر استفاده می‌شود (یعنی آیا اجاره‌ای برای آن وجود دارد یا خیر)، بلکه آیا نشانی می‌تواند توسط شخص دیگری استفاده شود (یعنی آیا رزروی برای آن وجود دارد یا خیر). این بررسی اضافی بار پردازشی بیشتری تحمیل می‌کند..SS انواع رزرو آدرس/پیشوند .sp در یک سناریوی معمول Kea، یک زیرشبکه IPv6 تعریف شده است که بخش معینی از آن به تخصیص پویای آدرس توسط کارساز DHCPv6 اختصاص دارد. ممکن است فضای آدرس بیشتری نیز برای واگذاری پیشوند (prefix delegation) تعریف شده باشد. این بخش‌های پویا با عنوان استخرهای پویا، استخرهای آدرس و پیشوند، یا به طور ساده استخرها (pools) شناخته می‌شوند. در اصل، یک رزرو میزبان می‌تواند هر آدرس یا پیشوندی را که متعلق به زیرشبکه است، رزرو کند. به رزروهایی که آدرس‌های متعلق به استخرهای پیکربندی‌شده را مشخص می‌کنند، \(dqرزروهای درون‌استخری\(dq گفته می‌شود. در مقابل، به رزروهایی که متعلق به استخرهای پویا نیستند، \(dqرزروهای بیرون‌استخری\(dq می‌گویند. هیچ تفاوت رسمی‌ای در ساختار نحوی رزرو وجود ندارد و با هر دو نوع رزرو به‌صورت یکسان رفتار می‌شود. .sp نرم‌افزار Kea از رزروهای سراسری میزبان پشتیبانی می‌کند. این‌ها رزروهایی هستند که در سطح سراسری در پیکربندی مشخص می‌شوند و متعلق به هیچ زیرشبکهٔ خاصی نیستند. Kea همچنان بسته‌های ورودی کلاینت را مطابق گذشته به یک زیرشبکه تطبیق می‌دهد، اما هنگامی که حالت رزرو زیرشبکه روی \(dqglobal\(dq تنظیم شده باشد، Kea رزروهای میزبان را تنها در میان رزروهای سراسریِ تعریف‌شده جستجو می‌کند. معمولاً چنین رزروهایی برای رزرو نام میزبان کلاینت‌هایی به کار می‌روند که ممکن است از یک زیرشبکه به زیرشبکهٔ دیگر جابجا شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 رزروهای سراسری، اگرچه در شرایط خاصی سودمند هستند، اما جنبه‌هایی دارند که هنگام استفاده از آن‌ها باید به‌دقت مد نظر قرار گیرند. لطفاً برای جزئیات بیشتر به بخش «تداخل‌ها در رزروهای DHCPv6» مراجعه کنید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه Kea 1.9.1، حالت رزرو با سه پرچم بولی \fBreservations\-global\fP، \fBreservations\-in\-subnet\fP و \fBreservations\-out\-of\-pool\fP جایگزین شده است که امکان پیکربندی رزروهای میزبان را هم به‌صورت سراسری و هم در یک زیرشبکه فراهم می‌سازند. در چنین مواردی، در صورتی که هر دو رزرو برای یک کلاینت یکسان وجود داشته باشند، رزرو میزبان زیرشبکه بر رزرو سراسری ارجحیت دارد. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 با شروع از Kea 2.7.3، ساختار نحوی رزرو میزبان از مدخل جدیدی با نام \fBexcluded\-prefixes\fP پشتیبانی می‌کند. از این مدخل می‌توان برای مشخص کردن پیشوندهایی که کلاینت باید از پیشوندهای واگذار شده استثنا کند استفاده کرد. در صورت وجود، این مدخل باید دقیقاً تعداد عناصری برابر با مدخل \fBprefixes\fP داشته باشد. هر دو مدخل حاوی رشته‌هایی هستند که پیشوندهای IPv6 را نشان می‌دهند. هر عنصر \fBexcluded\-prefixes\fP باید یک رشتهٔ خالی باشد یا با پیشوند موجود در همان جایگاه در \fBprefixes\fP مطابقت داشته باشد. یک فهرست \fBexcluded\-prefixes\fP خالی یا فهرستی که فقط حاوی رشته‌های خالی باشد را می‌توان حذف کرد. نمونه‌ای که \fB2001:db8:0:1::/64\fP را از \fB2001:db8::/48\fP مستثنی می‌کند در زیر نشان داده شده است: .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq01:02:03:04:05:06:07:08:09:0A\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1::103\(dq ], \(dqprefixes\(dq: [ \(dq2001:db8::/48\(dq ], \(dqexcluded\-prefixes\(dq: [ \(dq2001:db8:0:1::/64\(dq ], \(dqhostname\(dq: \(dqfoo.example.com\(dq } ], \&... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از آنجا که رزروهای میزبان نسبت به استخرهای پیشوند اولویت دارند، یک پیشوند رزروشدهٔ فاقد پیشوند استثنا شده، گزینهٔ pd\-exclude را به گزینهٔ پیشوند اضافه نخواهد کرد؛ حتی اگر پیشوند واگذار شده درون یک استخر پیشوند پیکربندی‌شده قرار داشته باشد که یک پیشوند استثنا شده را مشخص کرده است (برخلاف رفتار قبلی). .UNINDENT .UNINDENT .SS تداخل‌ها در رزروهای DHCPv6 .sp از آنجا که اطلاعات رزرو و اطلاعات اجاره به‌صورت جداگانه ذخیره می‌شوند، ممکن است تداخل رخ دهد. توالی رویدادهای زیر را در نظر بگیرید: کارساز یک استخر پویای آدرس را در بازهٔ 2001:db8::10 تا 2001:db8::20 پیکربندی کرده است. میزبان A درخواست آدرس می‌دهد و 2001:db8::10 را دریافت می‌کند. اکنون مدیر سیستم تصمیم می‌گیرد آدرس 2001:db8::10 را برای میزبان B رزرو کند. به‌طور کلی، رزرو آدرسی که در حال حاضر به شخص دیگری اختصاص داده شده است پیشنهاد نمی‌شود، اما سناریوهای معتبری وجود دارند که انجام چنین عملیاتی در آن‌ها موجه است. .sp اکنون کارساز تداخلی دارد که باید برطرف شود. اگر میزبان B راه‌اندازی شود و درخواست آدرس کند، کارساز نمی‌تواند بلافاصله آدرس رزروشدهٔ 2001:db8::10 را به آن تخصیص دهد. یک رویکرد ساده‌لوحانه این خواهد بود که فوراً اجارهٔ میزبان A حذف شده و یک اجارهٔ جدید برای میزبان B ایجاد شود. با این حال، این کار مشکل را حل نمی‌کند، زیرا به محض اینکه میزبان B آدرس را دریافت کند، متوجه می‌شود که این آدرس از قبل (توسط میزبان A) در حال استفاده است و یک پیام DHCPDECLINE ارسال می‌کند. بنابراین، در این وضعیت، کارساز باید موقتاً آدرس متفاوتی از استخر پویا (که با آنچه رزرو شده مطابقت ندارد) را به میزبان B تخصیص دهد. .sp هنگامی که میزبان A آدرس خود را تمدید می‌کند، کارساز متوجه می‌شود که آدرس در حال تمدید، اکنون برای فرد دیگری \- میزبان B \- رزرو شده است. کارساز اجارهٔ 2001:db8::10 را حذف کرده، آدرس جدیدی را انتخاب می‌کند و یک اجارهٔ جدید برای آن ایجاد می‌نماید. کارساز در پاسخ خود دو آدرس ارسال می‌کند: آدرس قدیمی با طول عمر (lifetime) تنظیم‌شده روی 0 تا صراحتاً نشان دهد که دیگر معتبر نیست؛ و آدرس جدید با یک طول عمر غیرصفر. هنگامی که میزبان B تلاش می‌کند آدرسِ موقتاً تخصیص‌یافتهٔ خود را تمدید کند، کارساز متوجه می‌شود که اجارهٔ موجود با رزرو مطابقت ندارد، بنابراین آدرس فعلیِ میزبان B را آزاد کرده و یک اجارهٔ جدید منطبق با رزرو می‌سازد. همانند قبل، کارساز دو آدرس ارسال می‌کند: آدرس موقتاً تخصیص‌یافته با طول عمر صفر، و آدرس جدیدِ مطابق با رزرو همراه با طول عمر مناسب. .sp این روند بازیابی حتی در صورتی که سایر میزبان‌ها برای دریافت آدرس رزروشده تلاش کنند نیز موفقیت‌آمیز خواهد بود. اگر میزبان C پس از ایجاد رزرو، آدرس 2001:db8::10 را درخواست کند، کارساز آدرس متفاوتی را پیشنهاد خواهد داد. .sp این سازوکار بازیابی به کارساز امکان می‌دهد تا از شرایطی که رزروها با اجاره‌های موجود تداخل دارند، به‌طور کامل بازیابی شود؛ هرچند اجرای این فرایند تقریباً به اندازه مقدار تنظیم‌شده برای \fBrenew\-timer\fP زمان می‌برد. بهترین روش برای جلوگیری از چنین روندی، تعریف نکردن رزروهای جدیدی است که با اجاره‌های موجود تداخل داشته باشند. توصیهٔ دیگر، استفاده از رزروهای بیرون‌استخری است؛ اگر آدرس رزروشده متعلق به یک استخر نباشد، کلاینت‌های دیگر به هیچ وجه نمی‌توانند آن را دریافت کنند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 سازوکار حل تداخل برای رزروهای سراسری کار نمی‌کند. اگرچه قابلیت رزرو سراسری آدرس ممکن است در شرایط خاصی کاربردی باشد، اما به‌طور کلی توصیه می‌شود از رزروهای سراسری برای آدرس‌ها استفاده نکنید. مدیرانی که تصمیم به استفاده از رزروهای سراسری می‌گیرند باید به‌صورت دستی اطمینان حاصل کنند که آدرس‌های رزروشده درون استخرهای پویا قرار ندارند. .UNINDENT .UNINDENT.SS "رزرو نام میزبان (Reserving a Hostname)" .sp هنگامی که رزرو برای یک کلاینت شامل \fBhostname\fP باشد، سرور این نام میزبان را به کلاینت تخصیص داده و در صورتی که کلاینت گزینهٔ Client FQDN را در پیام ارسالی خود به سرور گنجانده باشد، آن را در گزینهٔ Client FQDN بازمی‌گرداند. نام میزبان رزروشده همواره نسبت به نام میزبان ارائه‌شده توسط کلاینت (از طریق گزینهٔ FQDN) یا نام میزبان تولیدشده به‌صورت خودکار (از روی نشانی IPv6) اولویت دارد. .sp سرور نام میزبان رزروشده را با مقدار پارامتر \fBddns\-qualifying\-suffix\fP تکمیل می‌کند. برای نمونه، پیکربندی زیرشبکهٔ زیر: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::/80\(dq } ], \(dqddns\-qualifying\-suffix\(dq: \(dqexample.isc.org.\(dq, \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq01:02:03:04:05:0A:0B:0C:0D:0E\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1::100\(dq ], \(dqhostname\(dq: \(dqalice\-laptop\(dq } ] } ], \(dqdhcp\-ddns\(dq: { \(dqenable\-updates\(dq: true }, \&... } .EE .UNINDENT .UNINDENT .sp باعث می‌شود نام میزبان \(dqalice\-laptop.example.isc.org.\(dq به کلاینت دارای DUID با مقدار \(dq01:02:03:04:05:0A:0B:0C:0D:0E\(dq تخصیص یابد. اگر \fBddns\-qualifying\-suffix\fP مشخص نشده باشد، مقدار پیش‌فرض (خالی) استفاده خواهد شد و در این حالت مقدار مشخص‌شده برای \fBhostname\fP به عنوان یک نام کامل دامنه (fully qualified name) در نظر گرفته می‌شود. بنابراین، با خالی گذاشتن \fBddns\-qualifying\-suffix\fP می‌توان نام‌های میزبان را برای کلاینت‌های مختلف با نام‌های دامنهٔ متفاوت تکمیل کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::/80\(dq } ], \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq01:02:03:04:05:0A:0B:0C:0D:0E\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1::100\(dq ], \(dqhostname\(dq: \(dqmark\-desktop.example.org.\(dq } ] } ], \(dqdhcp\-ddns\(dq: { \(dqenable\-updates\(dq: true } } .EE .UNINDENT .UNINDENT .sp مثال بالا منجر به تخصیص نام میزبان \(dqmark\-desktop.example.org.\(dq به کلاینت دارای DUID با مقدار \(dq01:02:03:04:05:0A:0B:0C:0D:0E\(dq می‌شود. .SS "گنجاندن گزینه‌های خاص DHCPv6 در رزروها (Including Specific DHCPv6 Options in Reservations)" .sp نرم‌افزار Kea امکان تعیین گزینه‌ها را بر پایهٔ هر میزبان فراهم می‌کند. این گزینه‌ها از همان قواعد سایر گزینه‌ها پیروی می‌کنند. این موارد می‌توانند گزینه‌های استاندارد (بخش Standard DHCPv6 Options را ببینید)، گزینه‌های سفارشی (بخش Custom DHCPv6 Options را ببینید)، یا گزینه‌های ویژهٔ سازنده (بخش DHCPv6 Vendor\-Specific Options را ببینید) باشند. مثال زیر نحوهٔ تعریف گزینه‌های استاندارد را نشان می‌دهد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq01:02:03:05:06:07:08\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1::2\(dq ], \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq3000:1::234\(dq }, { \(dqname\(dq: \(dqnis\-servers\(dq, \(dqdata\(dq: \(dq3000:1::234\(dq }, ... ], ... }, \&... ], \&... } .EE .UNINDENT .UNINDENT .sp گزینه‌های ویژهٔ سازنده را می‌توان به شیوه‌ای مشابه رزرو کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqreservations\(dq: [ { \(dqduid\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8::1\(dq ], \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqvendor\-opts\(dq, \(dqdata\(dq: 4491 }, { \(dqname\(dq: \(dqtftp\-servers\(dq, \(dqspace\(dq: \(dqvendor\-4491\(dq, \(dqdata\(dq: \(dq3000:1::234\(dq }, ... ], ... }, \&... ], \&... } .EE .UNINDENT .UNINDENT .sp گزینه‌های تعریف‌شده در سطح میزبان بالاترین اولویت را دارند. به بیان دیگر، اگر گزینه‌هایی با نوع یکسان در سطوح سراسری (global)، زیرشبکه (subnet)، کلاس (class) و میزبان (host) تعریف شده باشند، مقادیر اختصاصی میزبان استفاده می‌شوند..SS رزرو کلاس‌های کلاینت در DHCPv6 .sp بخش «استفاده از عبارت‌ها در دسته‌بندی» \%<#\:classification-using-expressions> توضیح می‌دهد که چگونه سرور را پیکربندی کنید تا بر اساس محتوای گزینه‌هایی که کلاینت به سرور ارسال می‌کند، کلاس‌هایی را به آن اختصاص دهد. سازوکارهای رزرو میزبان (Host reservation) نیز امکان تخصیص ایستای کلاس‌ها به کلاینت‌ها را فراهم می‌کنند. تعاریف این کلاس‌ها در فایل پیکربندی Kea یا در یک پایگاه داده قرار می‌گیرند. قطعه‌پیکربندی زیر نشان می‌دهد چگونه مشخص کنید که یک کلاینت متعلق به کلاس‌های \fBreserved\-class1\fP و \fBreserved\-class2\fP است. این کلاس‌ها با گزینه‌های خاصی که به کلاینت‌های متعلق به آن‌ها ارسال می‌شوند، مرتبط هستند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqreserved\-class1\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8:1::50\(dq } ] }, { \(dqname\(dq: \(dqreserved\-class2\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqnis\-servers\(dq, \(dqdata\(dq: \(dq2001:db8:1::100\(dq } ] } ], \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::/64\(dq } ], \(dqsubnet\(dq: \(dq2001:db8:1::/48\(dq, \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq01:02:03:04:05:06:07:08\(dq, \(dqclient\-classes\(dq: [ \(dqreserved\-class1\(dq, \(dqreserved\-class2\(dq ] } ] } ] } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کلاس‌های فهرست‌شده در فهرست \fBclient\-classes\fP یک رزرو، بدون قید و شرط به کلاینتِ آن رزرو اختصاص داده می‌شوند، چه آن کلاس‌ها شامل یک عبارت آزمون (test expression) باشند و چه نباشند. برای جلوگیری از سردرگمی، پیشنهاد می‌شود در کلاس‌های کلاینتی که صرفاً از طریق رزروهای میزبان اختصاص می‌یابند، عبارت‌های آزمون حذف شوند. .UNINDENT .UNINDENT .sp در برخی موارد، رزروهای میزبان می‌توانند همراه با کلاس‌های کلاینتِ مشخص‌شده در پیکربندی Kea استفاده شوند. به‌ویژه، هنگامی که یک رزرو میزبان برای یک کلاینت در یک زیرشبکه معین وجود دارد، کلاس توکار \(dqKNOWN\(dq به کلاینت اختصاص می‌یابد. در مقابل، هنگامی که هیچ تخصیص ایستایی برای کلاینت وجود ندارد، کلاس \(dqUNKNOWN\(dq به کلاینت اختصاص داده می‌شود. عبارت‌های کلاس در فایل پیکربندی Kea می‌توانند با استفاده از عملگر \(dqmember\(dq به کلاس‌های \(dqKNOWN\(dq یا \(dqUNKNOWN\(dq ارجاع دهند. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqdependent\-class\(dq, \(dqtest\(dq: \(dqmember(\(aqKNOWN\(aq)\(dq, \(dqonly\-in\-additional\-list\(dq: true } ] } .EE .UNINDENT .UNINDENT .sp پارامتر \fBonly\-in\-additional\-list\fP در اینجا برای واداشتنِ ارزیابی کلاس پس از تخصیص اجاره (lease) و در نتیجه پس از تخصیص کلاس رزرو شده لازم است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کلاس‌های مشخص‌شده در رزروهای میزبان غیرسراسری (non\-global)، پس از اینکه تمام کلاس‌های دارای پارامتر \fBonly\-in\-additional\-list\fP با مقدار \fBfalse\fP ارزیابی شدند، به بستهٔ پردازش‌شده تخصیص می‌یابند. این بدان معناست که این کلاس‌ها نباید به کلاس‌های تخصیص‌یافتهٔ ایستا از رزروهای میزبان وابسته باشند. اگر چنین وابستگی‌ای لازم باشد، پارامتر \fBonly\-in\-additional\-list\fP برای کلاس‌های وابسته باید روی \fBtrue\fP تنظیم شود. چنین کلاس‌هایی پس از انتساب کلاس‌های ایستا به بسته ارزیابی می‌شوند. با این حال، این امر بار کاری اضافی در پیکربندی ایجاد می‌کند، زیرا تمام کلاس‌های علامت‌گذاری‌شده به عنوان \fBonly\-in\-additional\-list\fP باید در فهرست \fBevaluate\-additional\-classes\fP برای هر زیرشبکه‌ای که در آن استفاده می‌شوند قرار گیرند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کلاس‌های کلاینت مشخص‌شده در فایل پیکربندی Kea می‌توانند به کلاس‌های مشخص‌شده در رزروهای میزبان سراسری (global) وابسته باشند. در چنین حالتی به پارامتر \fBonly\-in\-additional\-list\fP نیازی نیست. برای سناریوهای کاربردی خاص، به بخش‌های «Pool Selection with Client Class Reservations» و «Subnet Selection with Client Class Reservations» مراجعه کنید. .UNINDENT .UNINDENT.SS ذخیره‌سازی رزروهای میزبان در MySQL یا PostgreSQL .sp کارساز Kea می‌تواند رزروهای میزبان را در MySQL یا PostgreSQL ذخیره کند. برای اطلاعات بیشتر در مورد نحوه پیکربندی Kea جهت استفاده از رزروهای ذخیره‌شده در MySQL یا PostgreSQL، بخش Hosts Storage را ببینید. کارساز Kea یک قلاب اختصاصی برای مدیریت رزروها در پایگاه‌داده ارائه می‌دهد؛ بخش libdhcp_host_cmds.so: Host Commands \%<#\:hooks-host-cmds> اطلاعات دقیقی را ارائه می‌کند. ویکی Kea \% چندین مثال از نحوه انجام عملیات رایج رزرو میزبان را ارائه می‌دهد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در Kea، حداکثر طول گزینه‌ای که به ازای هر میزبان مشخص می‌شود، به‌طور قراردادی روی 4096 بایت تنظیم شده است. .UNINDENT .UNINDENT .SS تنظیم دقیق رزرو میزبان DHCPv6 .sp قابلیت رزرو میزبان، محدودیت‌های اضافی را برای موتور تخصیص (بخشی از Kea که آدرسی را برای کلاینت انتخاب می‌کند) در طول فرایند انتخاب و تمدید اجاره اعمال می‌کند. به طور خاص، سه بررسی عمده ضروری است. نخست، هنگام انتخاب یک اجاره جدید، تنها آزاد بودن اجاره و عدم استفاده از آن توسط کلاینت DHCP دیگر کافی نیست؛ بلکه نباید برای کلاینت دیگری نیز رزرو شده باشد. به طور مشابه، هنگام تمدید یک اجاره، باید بررسی دیگری انجام شود تا مشخص گردد آیا آدرسی که در حال تمدید است برای کلاینت دیگری رزرو شده است یا خیر. در نهایت، هنگامی که یک میزبان آدرس یا پیشوندی را تمدید می‌کند، کارساز باید بررسی کند که آیا رزروی برای این میزبان وجود دارد یا خیر، که در این صورت به این معنی است که آدرس موجود (تخصیص‌یافته به صورت پویا) باید باطل شده و به جای آن آدرس رزروشده استفاده شود. .sp برخی از این بررسی‌ها ممکن است در برخی استقرارها غیرضروری باشند، و انجام ندادن آن‌ها می‌تواند کارایی را بهبود بخشد. کارساز Kea پارامترهای پیکربندی \fBreservations\-global\fP، \fBreservations\-in\-subnet\fP و \fBreservations\-out\-of\-pool\fP را برای انتخاب انواع رزروهای مجاز برای یک زیرشبکه خاص ارائه می‌دهد. هر نوع رزرو، محدودیت‌های متفاوتی برای بررسی‌هایی دارد که کارساز هنگام تخصیص یا تمدید اجاره برای کلاینت باید انجام دهد. .sp پرچم‌های پیکربندی عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBreservations\-in\-subnet\fP \- هنگامی که روی \fBtrue\fP تنظیم شود، انواع رزرو میزبان درون استخر (in\-pool) را فعال می‌کند. این تنظیم مقدار پیش‌فرض بوده و امن‌ترین و انعطاف‌پذیرترین حالت است. با این حال، از آنجا که تمام بررسی‌ها انجام می‌شوند، کندترین حالت نیز هست. این گزینه رزروهای سراسری را بررسی نمی‌کند. مقدار پیش‌فرض این پرچم \fBtrue\fP است. .IP \(bu 2 \fBreservations\-out\-of\-pool\fP \- هنگامی که روی \fBtrue\fP تنظیم شود، فقط به رزروهای میزبان خارج از استخر (out\-of\-pool) اجازه می‌دهد. در این حالت کارساز فرض می‌کند که تمام رزروهای میزبان برای آدرس‌هایی هستند که متعلق به استخر پویا نیستند. بنابراین، هنگام برخورد با آدرس‌های درون استخر می‌تواند از بررسی‌های رزرو صرف‌نظر کند، و در نتیجه کارایی را بهبود بخشد. اگر هر یک از رزروها از آدرس‌های درون استخر استفاده می‌کنند، از این حالت استفاده نکنید. هنگام استفاده از این تنظیم احتیاط توصیه می‌شود؛ Kea رزروها را در برابر \fBreservations\-out\-of\-pool\fP اعتبارسنجی منطقی نمی‌کند و پیکربندی نادرست ممکن است باعث بروز مشکلاتی شود. مقدار پیش‌فرض این پرچم \fBfalse\fP است. .IP \(bu 2 \fBreservations\-global\fP \- رزروهای میزبان سراسری را مجاز می‌کند. با اعمال این تنظیم، کارساز رزروهای مربوط به یک کلاینت را در میان رزروهای سراسری تعریف‌شده جستجو می‌کند. اگر آدرسی مشخص شده باشد، کارساز از بررسی‌های رزرو که در سایر حالت‌ها انجام می‌شوند صرف‌نظر کرده، و در نتیجه کارایی را بهبود می‌بخشد. هنگام استفاده از این تنظیم احتیاط توصیه می‌شود؛ زمانی که \fBreservations\-global\fP روی \fBtrue\fP تنظیم شده باشد، Kea رزروها را اعتبارسنجی منطقی نمی‌کند و پیکربندی نادرست ممکن است باعث بروز مشکلاتی شود. مقدار پیش‌فرض این پرچم \fBfalse\fP است. .UNINDENT .INDENT 0.0 .TP .B نکته: تنظیم تمام پرچم‌ها روی \fBfalse\fP پشتیبانی از رزرو میزبان را غیرفعال می‌کند. از آنجا که هیچ رزروی وجود ندارد، کارساز از تمام بررسی‌ها صرف‌نظر می‌کند. هر رزرو تعریف‌شده کاملاً نادیده گرفته می‌شود. از آنجا که بررسی‌ها نادیده گرفته می‌شوند، کارساز ممکن است در این حالت سریع‌تر عمل کند. .UNINDENT .sp از نسخه 1.9.1 Kea، پرچم‌های \fBreservations\-global\fP، \fBreservations\-in\-subnet\fP و \fBreservations\-out\-of\-pool\fP پشتیبانی می‌شوند. .sp پارامترهای \fBreservations\-global\fP، \fBreservations\-in\-subnet\fP و \fBreservations\-out\-of\-pool\fP را می‌توان در سطوح زیر مشخص کرد: .INDENT 0.0 .IP \(bu 2 سطح سراسری: \fB\&.Dhcp6[\(dqreservations\-global\(dq]\fP (کمترین اولویت: توسط تمام سطوح دیگر بازنویسی می‌شود) .IP \(bu 2 سطح زیرشبکه: \fB\&.Dhcp6.subnet6[][\(dqreservations\-in\-subnet\(dq]\fP (اولویت پایین) .IP \(bu 2 سطح شبکه مشترک: \fB\&.Dhcp6[\(dqshared\-networks\(dq][][\(dqreservations\-out\-of\-pool\(dq]\fP (اولویت بالا) .IP \(bu 2 سطح زیرشبکه در شبکه مشترک: \fB\&.Dhcp6[\(dqshared\-networks\(dq][].subnet6[][\(dqreservations\-out\-of\-pool\(dq]\fP (بالاترین اولویت: بر تمام سطوح دیگر تقدم دارد) .UNINDENT .sp برای تصمیم‌گیری در مورد اینکه کدام پرچم‌ها استفاده شوند، نمودار تصمیم‌گیری زیر ممکن است مفید باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX O | v +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | Is per\-host configuration needed, such as | | reserving specific addresses, | | assigning specific options or | | assigning packets to specific classes on per\-device basis? | +\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | no| yes| | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | | For all given hosts, | +\-\-> \(dqdisabled\(dq +\-\->+ can the reserved resources | | be used in all configured subnets? | +\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-+ | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ |no |yes | Is | | | | at least one reservation +<\-\-+ \(dqglobal\(dq <\-\-+ | used to reserve addresses | | or prefixes? | +\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-+ | | no| yes| +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | | Is high leases\-per\-second | +\-\-> \(dqout\-of\-pool\(dq +\-\->+ performance or efficient | ^ | resource usage | | | (CPU ticks, RAM usage, | | | database roundtrips) | | | important to your setup? | | +\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+ | | | | yes| no| | | | | +\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | | | | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | | | Can it be guaranteed | | | +\-\->+ that the reserved | | | | addresses/prefixes | | | | aren\(aqt part of the | | | | pools configured | | | | in the respective | | | | subnet? | | | +\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-+ | | | | | | yes| no| | | | | V +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +\-\-> \(dqin\-subnet\(dq .EE .UNINDENT .UNINDENT .sp یک نمونه پیکربندی که رزروها را غیرفعال می‌کند به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::\-2001:db8:1::100\(dq } ], \(dqreservations\-global\(dq: false, \(dqreservations\-in\-subnet\(dq: false, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq } ] } } .EE .UNINDENT .UNINDENT .sp یک پیکربندی نمونه با استفاده از رزروهای سراسری در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqreservations\-global\(dq: true, \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq00:03:00:01:11:22:33:44:55:66\(dq, \(dqhostname\(dq: \(dqhost\-one\(dq }, { \(dqduid\(dq: \(dq00:03:00:01:99:88:77:66:55:44\(dq, \(dqhostname\(dq: \(dqhost\-two\(dq } ], \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::\-2001:db8:1::100\(dq } ], \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq } ] } } .EE .UNINDENT .UNINDENT .sp معنی پرچم‌های رزرو عبارتند از: .INDENT 0.0.IP \(bu 2 \fBreservations\-global\fP: واکشی رزروهای سراسری. .IP \(bu 2 \fBreservations\-in\-subnet\fP: واکشی رزروهای زیرشبکه. برای یک shared network این شامل تمام زیرشبکه‌های عضو آن shared network می‌شود. .IP \(bu 2 \fBreservations\-out\-of\-pool\fP: این مورد تنها زمانی معنادار است که پرچم \fBreservations\-in\-subnet\fP برابر با \fBtrue\fP باشد. هنگامی که \fBreservations\-out\-of\-pool\fP برابر با \fBtrue\fP باشد، کارگزار فرض می‌کند که تمام رزروهای میزبان برای نشانی‌هایی هستند که متعلق به استخر پویا (dynamic pool) نیستند. بنابراین، می‌تواند هنگام مواجهه با نشانی‌های درون استخر از بررسی‌های رزرو صرف‌نظر کرده و کارایی را بهبود بخشد. کارگزار نشانی‌های رزروشده‌ای را که درون استخرهای پویا قرار دارند به کلاینت‌های مربوطه اختصاص نخواهد داد. این همچنین بدان معناست که نشانی‌های مطابق با رزروهای مربوطه از درون استخرهای پویا (در صورت وجود) می‌توانند به‌صورت پویا به هر کلاینتی اختصاص داده شوند. .UNINDENT .sp پیکربندی \fBdisabled\fP معادل است با: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqreservations\-global\(dq: false, \(dqreservations\-in\-subnet\(dq: false } } .EE .UNINDENT .UNINDENT .sp پیکربندی \fBglobal\fP با استفاده از \fBreservations\-global\fP معادل است با: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqreservations\-global\(dq: true, \(dqreservations\-in\-subnet\(dq: false } } .EE .UNINDENT .UNINDENT .sp پیکربندی \fBout\-of\-pool\fP با استفاده از \fBreservations\-out\-of\-pool\fP معادل است با: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqreservations\-global\(dq: false, \(dqreservations\-in\-subnet\(dq: true, \(dqreservations\-out\-of\-pool\(dq: true } } .EE .UNINDENT .UNINDENT .sp و پیکربندی \fBin\-subnet\fP با استفاده از \fBreservations\-in\-subnet\fP معادل است با: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqreservations\-global\(dq: false, \(dqreservations\-in\-subnet\(dq: true, \(dqreservations\-out\-of\-pool\(dq: false } } .EE .UNINDENT .UNINDENT .sp برای فعال‌سازی هم‌زمان \fBglobal\fP و \fBin\-subnet\fP، ترکیب زیر می‌تواند استفاده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqreservations\-global\(dq: true, \(dqreservations\-in\-subnet\(dq: true, \(dqreservations\-out\-of\-pool\(dq: false } } .EE .UNINDENT .UNINDENT .sp برای فعال‌سازی هم‌زمان \fBglobal\fP و \fBout\-of\-pool\fP، ترکیب زیر می‌تواند استفاده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqreservations\-global\(dq: true, \(dqreservations\-in\-subnet\(dq: true, \(dqreservations\-out\-of\-pool\(dq: true } } .EE .UNINDENT .UNINDENT .sp فعال‌سازی \fBout\-of\-pool\fP و غیرفعال‌سازی هم‌زمان \fBin\-subnet\fP توصیه نمی‌شود زیرا \fBout\-of\-pool\fP برای رزروهای میزبان در یک زیرشبکه اعمال می‌شود که فقط در صورت \fBtrue\fP بودن پرچم \fBin\-subnet\fP واکشی می‌شوند. .sp این پارامتر می‌تواند در سطوح global، subnet و shared\-network تعیین شود. .sp یک پیکربندی نمونه که رزروها را غیرفعال می‌کند به‌صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqreservations\-global\(dq: false, \(dqreservations\-in\-subnet\(dq: false, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqid\(dq: 1 } ] } } .EE .UNINDENT .UNINDENT .sp یک پیکربندی نمونه با استفاده از رزروهای سراسری در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq00:03:00:01:11:22:33:44:55:66\(dq, \(dqhostname\(dq: \(dqhost\-one\(dq }, { \(dqduid\(dq: \(dq00:03:00:01:99:88:77:66:55:44\(dq, \(dqhostname\(dq: \(dqhost\-two\(dq } ], \(dqreservations\-global\(dq: true, \(dqreservations\-in\-subnet\(dq: false, \(dqsubnet6\(dq: [ { \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::\-2001:db8:1::100\(dq } ], \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqid\(dq: 1 } ] } } .EE .UNINDENT .UNINDENT .sp برای جزئیات بیشتر در رابطه با رزروهای سراسری، به بخش Global Reservations in DHCPv6 مراجعه کنید. .sp جنبهٔ دیگر رزروهای میزبان، انواع مختلف شناسه‌ها است. Kea در حال حاضر از دو نوع شناسه در DHCPv6 پشتیبانی می‌کند: نشانی سخت‌افزاری و DUID. این قابلیت از دیدگاه کاربری مفید است؛ با این حال، یک عیب دارد. برای هر بستهٔ ورودی، Kea باید هر نوع شناسه را استخراج کرده و سپس پایگاه‌داده را پرس‌وجو کند تا بررسی کند آیا رزروی با این شناسهٔ خاص وجود دارد یا خیر. اگر چیزی یافت نشد، شناسهٔ بعدی استخراج شده و پرس‌وجوی بعدی ارسال می‌شود. این فرایند تا زمانی که یک رزرو پیدا شود یا تمام انواع شناسه‌ها بررسی شوند ادامه می‌یابد. به مرور زمان، با افزایش تعداد انواع شناسه‌های پشتیبانی‌شده، Kea کندتر و کندتر خواهد شد. .sp برای حل این مشکل، پارامتری به نام \fBhost\-reservation\-identifiers\fP در دسترس است. این پارامتر فهرستی از انواع شناسه را دریافت می‌کند. Kea تنها آن دسته از انواع شناسه‌ها را که در \fBhost\-reservation\-identifiers\fP ذکر شده‌اند بررسی می‌کند. از نظر کارایی، تعداد انواع شناسه‌ها باید در حداقل ممکن، در حالت ایده‌آل یک مورد، نگه داشته شود. اگر در استقرار از چندین نوع رزرو استفاده می‌شود، لطفاً آن‌ها را از پرکاربردترین به کم‌کاربردترین مرتب کنید، زیرا این کار شانس یافتن رزرو توسط Kea را با کمترین تعداد پرس‌وجو افزایش می‌دهد. یک نمونه از پیکربندی \fBhost\-reservation\-identifiers\fP به‌صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhost\-reservation\-identifiers\(dq: [ \(dqduid\(dq, \(dqhw\-address\(dq ], \(dqsubnet6\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, ... } ], \&... } .EE .UNINDENT .UNINDENT .sp در صورت عدم تعیین، مقدار پیش‌فرض برابر است با: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqhost\-reservation\-identifiers\(dq: [ \(dqhw\-address\(dq, \(dqduid\(dq ] .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 به‌محض یافتن یک رزرو میزبان، جستجو متوقف می‌شود؛ هنگامی که یک کلاینت دارای دو رزرو میزبان با استفاده از انواع شناسه‌های فعالِ متفاوت باشد، همیشه نخستین مورد بازگردانده شده و دومی نادیده گرفته می‌شود. این حالت معمولاً یک خطای پیکربندی است. در موارد نادری که داشتن دو رزرو برای یک میزبان منطقی است، موردی که باید استفاده شود را می‌توان با مرتب‌سازی فهرست انواع شناسه در \fBhost\-reservation\-identifiers\fP تعیین کرد. .UNINDENT .UNINDENT.SS "رزروهای سراسری در DHCPv6 (Global Reservations in DHCPv6)" .sp در برخی پیاده‌سازی‌ها، مانند شبکه‌های تلفن همراه، کلاینت‌ها می‌توانند در سراسر شبکه جابه‌جا شوند (roam کنند) و پارامترهای خاصی فارغ از مکان فعلی کلاینت باید مشخص گردند. برای برآورده ساختن چنین نیازی، Kea سازوکار رزرو سراسری (global reservation) را ارائه می‌دهد. ایدهٔ نهفته در پس آن این است که رزروهای میزبان معمولی، با استفاده از یک شناسهٔ زیرشبکه (subnet ID) مشخص، به زیرشبکه‌های خاصی وابسته هستند. Kea می‌تواند یک رزرو سراسری را مشخص کند که در تمامی زیرشبکه‌هایی که رزروهای سراسری در آن‌ها فعال است، قابل استفاده باشد. .sp این ویژگی می‌تواند برای تخصیص پارامترهای مشخصی مانند hostname یا سایر گزینه‌های اختصاصی و ویژهٔ میزبان (host\-specific) به کار رود. همچنین می‌توان از آن برای تخصیص نشانی‌ها یا پیشوندها استفاده کرد. .sp نشانی اختصاص‌یافته از طریق رزرو سراسری میزبان باید برای زیرشبکه‌ای که سرور برای کلاینت انتخاب می‌کند، امکان‌پذیر و معتبر باشد. به عبارت دیگر، نشانی باید در محدودهٔ زیرشبکه قرار داشته باشد؛ در غیر این صورت نادیده گرفته شده و سرور تلاش خواهد کرد نشانی را به‌صورت پویا تخصیص دهد. اگر زیرشبکهٔ انتخاب‌شده متعلق به یک شبکهٔ مشترک (shared network) باشد، سرور امکان‌پذیری را با زیرشبکه‌های همتای آن بررسی کرده و نخستین زیرشبکه‌ای را که نشانی در محدودهٔ آن قرار دارد انتخاب می‌نماید. اگر چنین زیرشبکه‌ای وجود نداشته باشد، سرور به تخصیص پویای نشانی بازمی‌گردد. این موضوع در مورد پیشوندهای رزروشدهٔ سراسری صدق نمی‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پیش از نسخهٔ 2.3.5، سرور بررسی‌های امکان‌پذیری را بر روی نشانی‌های رزروشدهٔ سراسری انجام نمی‌داد، که این موضوع به سرور اجازه می‌داد تا به‌گونه‌ای پیکربندی شود که اجاره‌های (leases) نامعقولی را برای مقادیر دلخواه نشانی صادر کند. نسخه‌های بعدی Kea این بررسی‌ها را انجام می‌دهند. .UNINDENT .UNINDENT .sp برای استفاده از رزروهای سراسری میزبان، می‌توان از پیکربندی مشابه زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { # This specifies global reservations. # They will apply to all subnets that # have global reservations enabled. \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:ff\(dq, \(dqhostname\(dq: \(dqhw\-host\-dynamic\(dq }, { \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqhostname\(dq: \(dqhw\-host\-fixed\(dq, # Use of IP addresses in global reservations is risky. # If used outside of matching subnet, such as 3001::/64, # it will result in a broken configuration being handed # to the client. \(dqip\-address\(dq: \(dq2001:db8:ff::77\(dq }, { \(dqduid\(dq: \(dq01:02:03:04:05\(dq, \(dqhostname\(dq: \(dqduid\-host\(dq } ], \(dqvalid\-lifetime\(dq: 600, \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, # Specify if the server should look up global reservations. \(dqreservations\-global\(dq: true, # Specify if the server should look up in\-subnet reservations. \(dqreservations\-in\-subnet\(dq: false, # Specify if the server can assume that all reserved addresses # are out\-of\-pool. It can be ignored because \(dqreservations\-in\-subnet\(dq # is false. # \(dqreservations\-out\-of\-pool\(dq: false, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::\-2001:db8:1::100\(dq } ] } ] } .EE .UNINDENT .UNINDENT .sp هنگام استفاده از backendهای پایگاه داده، رزروهای سراسری میزبان با استفاده از مقدار 0 برای \fBsubnet\-id\fP از رزروهای معمولی متمایز می‌شوند. .SS "انتخاب استخر با رزروهای کلاس کلاینت (Pool Selection with Client Class Reservations)" .sp کلاس‌های کلاینت می‌توانند هم در فایل پیکربندی Kea و هم از طریق رزروهای میزبان تعیین شوند. کلاس‌های مشخص‌شده در فایل پیکربندی Kea بلافاصله پس از دریافت بستهٔ DHCP ارزیابی می‌شوند و بنابراین می‌توان از آن‌ها برای تأثیرگذاری بر انتخاب زیرشبکه با استفاده از پارامتر \fBclient\-classes\fP مشخص‌شده در حوزهٔ زیرشبکه (subnet scope) استفاده کرد. کلاس‌های مشخص‌شده درون رزروهای میزبان، پس از آن‌که سرور از قبل زیرشبکه‌ای را برای کلاینت انتخاب کرد، واکشی شده و به بسته اختصاص داده می‌شوند. این بدان معناست که کلاس کلاینت مشخص‌شده درون یک رزرو میزبان نمی‌تواند بر تخصیص زیرشبکه برای این کلاینت تأثیر بگذارد، مگر اینکه زیرشبکه به یک شبکهٔ مشترک (shared network) تعلق داشته باشد. اگر زیرشبکه متعلق به یک شبکهٔ مشترک باشد، سرور ممکن است هنگام تلاش برای تخصیص اجاره (lease)، تخصیص زیرشبکه را به‌طور پویا تغییر دهد. اگر زیرشبکه متعلق به یک شبکهٔ مشترک نباشد، زیرشبکه پس از یک‌بار انتخاب شدن دیگر تغییر نخواهد کرد. .sp اگر زیرشبکه متعلق به یک شبکهٔ مشترک نباشد، می‌توان از دسته‌بندی کلاینت مبتنی بر رزرو میزبان برای انتخاب یک استخر (pool) در درون زیرشبکه به صورت زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqreserved_class\(dq }, { \(dqname\(dq: \(dqunreserved_class\(dq, \(dqtest\(dq: \(dqnot member(\(aqreserved_class\(aq)\(dq } ], \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:fe\(dq, \(dqclient\-classes\(dq: [ \(dqreserved_class\(dq ] } ], \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::10 \- 2001:db8:1::20\(dq, \(dqclient\-classes\(dq: [ \(dqunreserved_class\(dq ] }, { \(dqpool\(dq: \(dq2001:db8:1::30 \- 2001:db8:1::40\(dq, \(dqclient\-classes\(dq: [ \(dqreserved_class\(dq ] }, { \(dqpool\(dq: \(dq2001:db8:1::50 \- 2001:db8:1::60\(dq } ] } ] } } .EE .UNINDENT .UNINDENT .sp کلاس \fBreserved_class\fP بدون پارامتر \fBtest\fP اعلان شده است زیرا تنها می‌تواند از طریق سازوکار رزرو میزبان به یک کلاینت اختصاص یابد. کلاس دوم، یعنی \fBunreserved_class\fP، به کلاینت‌هایی اختصاص می‌یابد که به \fBreserved_class\fP\& تعلق ندارند. .sp استخر نخست در زیرشبکه برای کلاینت‌هایی استفاده می‌شود که چنین رزروی ندارند. استخر دوم تنها برای کلاینت‌هایی استفاده می‌شود که رزروی برای \fBreserved_class\fP\& دارند. استخر سوم یک استخر بدون محدودیت برای تمامی کلاینت‌ها است که هم شامل کلاینت‌های \fBreserved_class\fP و هم شامل \fBunreserved_class\fP\& می‌شود. .sp این قطعه‌پیکربندی شامل یک رزرو میزبان است که باعث می‌شود کلاینتی با نشانی MAC به مقدار \fBaa:bb:cc:dd:ee:fe\fP به \fBreserved_class\fP\& اختصاص یابد. بنابراین، به این کلاینت نشانی IP از دومین استخر نشانی داده خواهد شد. .sp رزروهای تعریف‌شده در زیرشبکه‌ای که متعلق به یک شبکهٔ مشترک است برای کلاینتی که در غیر این صورت تطابق دارد قابل مشاهده نیست، بنابراین نمی‌توان از آن‌ها برای انتخاب استخرها، و به همین ترتیب زیرشبکه‌ها، استفاده کرد..SS انتخاب زیرشبکه با رزروهای کلاس کلاینت (Subnet Selection with Client Class Reservations) .sp یک حالت کاربردی خاص وجود دارد که در آن انتخاب زیرشبکه می‌تواند تحت تأثیر کلاس‌های کلاینت مشخص‌شده درون رزروهای میزبان قرار گیرد: زمانی که کلاینت به یک شبکهٔ مشترک (shared network) تعلق دارد. در چنین حالتی، می‌توان از کلاس‌بندی برای انتخاب یک زیرشبکه درون این شبکهٔ مشترک استفاده کرد. مثال زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqreserved_class\(dq }, { \(dqname\(dq: \(dqunreserved_class\(dq, \(dqtest\(dq: \(dqnot member(\(aqreserved_class\(aq)\(dq } ], \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dqaa:bb:cc:dd:ee:fe\(dq, \(dqclient\-classes\(dq: [ \(dqreserved_class\(dq ] } ], \(dqreservations\-global\(dq: true, \(dqreservations\-in\-subnet\(dq: false, \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqnet\(dq, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::10 \- 2001:db8:1::20\(dq, \(dqclient\-classes\(dq: [ \(dqunreserved_class\(dq ] }, { \(dqpool\(dq: \(dq2001:db8:1::30 \- 2001:db8:1::40\(dq, \(dqclient\-classes\(dq: [ \(dqunreserved_class\(dq ] } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq2001:db8:2::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:2::10 \- 2001:db8:2::20\(dq, \(dqclient\-classes\(dq: [ \(dqreserved_class\(dq ] }, { \(dqpool\(dq: \(dq2001:db8:2::30 \- 2001:db8:2::40\(dq, \(dqclient\-classes\(dq: [ \(dqreserved_class\(dq ] } ] }, { \(dqid\(dq: 3, \(dqsubnet\(dq: \(dq2001:db8:3::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:3::10 \- 2001:db8:3::20\(dq }, { \(dqpool\(dq: \(dq2001:db8:3::30 \- 2001:db8:3::40\(dq } ] } ] } ] } } .EE .UNINDENT .UNINDENT .sp این مشابه مثالی است که در «Pool Selection with Client Class Reservations» شرح داده شد. با این حال، این بار سه زیرشبکه وجود دارد که استخر هر یک از دو تای اول با یک کلاس متفاوت مرتبط شده است. .sp به کلاینت‌هایی که رزروی برای \fBreserved_class\fP ندارند، نشانی‌ای از زیرشبکهٔ اول اختصاص می‌یابد و پس از پر شدن آن، از زیرشبکهٔ سوم. به کلاینت‌هایی با رزرو برای \fBreserved_class\fP، نشانی‌ای از زیرشبکهٔ دوم اختصاص می‌یابد و پس از پر شدن آن، از زیرشبکهٔ سوم. .sp زیرشبکه‌ها باید متعلق به همان شبکهٔ مشترک باشند. .sp برای اینکه یک زیرشبکه به کلاسی خاص محدود شود یا نادیده گرفته شود، تمامی استخرهای درون آن زیرشبکه باید به ترتیب توسط \fBreserved_class\fP یا \fBunreserved_class\fP محافظت شوند. .sp علاوه بر این، رزرو برای کلاس کلاینت باید در حوزهٔ سراسری (رزرو سراسری) تعیین شده باشد و \fBreservations\-global\fP نیز روی \fBtrue\fP تنظیم شده باشد\&. .sp در مثال بالا، پارامتر پیکربندی \fBclient\-classes\fP می‌توانست به جای سطح استخر، در سطح زیرشبکه نیز مشخص شود و همان نتیجه را در بر داشته باشد. .sp اگر زیرشبکه‌ها بیرون از شبکه‌های مشترک تعریف شده بودند و \fBclient\-classes\fP در سطح زیرشبکه مشخص شده بود، آن‌گاه \fBearly\-global\-reservations\-lookup\fP نیز باید فعال می‌شد تا انتخاب زیرشبکه به درستی کار کند. .SS چند رزرو برای یک IP یکسان (Multiple Reservations for the Same IP) .sp رزروهای میزبان طوری طراحی شده بودند تا از ایجاد چندین رزرو برای یک نشانی IP یا پیشوند واگذارشده (delegated prefix) یکسان در یک زیرشبکهٔ خاص جلوگیری کنند، تا از رقابت دو کلاینت مختلف بر سر یک اجاره (lease) یکسان پرهیز شود. هنگام استفاده از تنظیمات پیش‌فرض، سرور هنگامی که دو یا چند رزرو را برای یک اجارهٔ یکسان درون یک زیرشبکه در فایل پیکربندی Kea بیابد، یک خطای پیکربندی برمی‌گرداند. \fBlibdhcp_host_cmds.so\fP \%<#\:std-ischooklib-libdhcp_host_cmds\:.so> در پاسخ به دستور \fBreservation\-add\fP \%<#\:std-isccmd-reservation-add> هنگامی که تشخیص دهد رزروی در پایگاه داده برای اجاره‌ای که رزرو جدید برای آن افزوده می‌شود وجود دارد، یک خطا برمی‌گرداند. .sp مشابه با DHCPv4 (ببینید Multiple Reservations for the Same IP \%<#\:multiple-reservations-same-ip4>)، سرور DHCPv6 نیز می‌تواند پیکربندی شود تا امکان ایجاد چندین رزرو برای یک نشانی IPv6 و/یا پیشوند واگذارشدهٔ یکسان در یک زیرشبکهٔ معین را فراهم کند. این قابلیت از انتشار 1.9.1 برنامهٔ Kea به عنوان یک حالت عملیاتی اختیاری پشتیبانی می‌شود که با پارامتر سراسری \fBip\-reservations\-unique\fP فعال می‌گردد. .sp پارامتر \fBip\-reservations\-unique\fP یک پارامتر بولی (boolean) است که مقدار پیش‌فرض آن \fBtrue\fP است و تعیین بیش از یک رزرو را برای همان اجاره در یک زیرشبکهٔ معین ممنوع می‌کند. تنظیم این پارامتر روی \fBfalse\fP اجازه می‌دهد چنین رزروهایی هم در فایل پیکربندی Kea و هم در بک‌اند پایگاه دادهٔ میزبان، از طریق \fBlibdhcp_host_cmds.so\fP \%<#\:std-ischooklib-libdhcp_host_cmds\:.so> ایجاد شوند\&. .sp تنظیم \fBip\-reservations\-unique\fP روی \fBfalse\fP هنگام استفاده از memfile، MySQL یا PostgreSQL پشتیبانی می‌شود. این تنظیم هنگام استفاده از Host Cache (ببینید libdhcp_host_cache.so: Host Cache Reservations for Improved Performance \%<#\:hooks-host-cache>) یا بک‌اند RADIUS (ببینید libdhcp_radius.so: RADIUS Server Support \%<#\:hooks-radius>) پشتیبانی نمی‌شود. این بک‌اندهای رزرو از چندین رزرو برای یک IP یکسان پشتیبانی نمی‌کنند؛ اگر هر یک از این هوک‌ها بارگیری شده باشد و \fBip\-reservations\-unique\fP روی \fBfalse\fP تنظیم شود، خطای پیکربندی صادر شده و راه‌اندازی سرور ناموفق خواهد بود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگامی که \fBip\-reservations\-unique\fP روی \fBtrue\fP (مقدار پیش‌فرض) تنظیم است، سرور اطمینان حاصل می‌کند که رزروهای IP برای یک زیرشبکه درون یک بک‌اند میزبان واحد و/یا فایل پیکربندی Kea یکتا هستند. این امر یکتا بودن رزروها را در میان چندین بک‌اند تضمین نمی‌کند. در زمان راه‌اندازی سرور، تنها یکتا بودن رزروهای IP تعریف‌شده در فایل پیکربندی Kea بررسی می‌شود. .UNINDENT .UNINDENT .sp در ادامه یک پیکربندی نمونه با دو رزرو برای نشانی IPv6 یکسان اما با نشانی‌های MAC متفاوت آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqip\-reservations\-unique\(dq: false, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dq1a:1b:1c:1d:1e:1f\(dq, \(dqip\-address\(dq: \(dq2001:db8:1::11\(dq }, { \(dqhw\-address\(dq: \(dq2a:2b:2c:2d:2e:2f\(dq, \(dqip\-address\(dq: \(dq2001:db8:1::11\(dq } ] } ] } .EE .UNINDENT .UNINDENT .sp کنترل پارامتر \fBip\-reservations\-unique\fP از طریق Configuration Backend در DHCPv6 امکان‌پذیر است\&. اگر تنظیم جدید این پارامتر با بک‌اندهای مورد استفادهٔ فعلی تداخل داشته باشد (یعنی بک‌اندها از تنظیم جدید پشتیبانی نکنند)، تنظیم جدید نادیده گرفته شده و یک پیام ثبت وقایع هشداری تولید می‌شود. بک‌اندها با این انتظار که رزروهای IP در هر زیرشبکه یکتا هستند، به استفاده از تنظیم پیش‌فرض ادامه می‌دهند. برای فراهم کردن امکان ایجاد رزروهای IP غیریکتا، مدیر سیستم باید بک‌اندهایی را که از آن‌ها پشتیبانی نمی‌کنند از فایل پیکربندی حذف کند. .sp مدیران سیستم باید هنگام استفاده از چندین رزرو برای یک نشانی IP و/یا پیشوند واگذارشدهٔ یکسان، در صورتی که بعداً تصمیم به بازگشت به حالت پیش‌فرض (که در آن این کار دیگر مجاز نیست) بگیرند، مراقب باشند. آن‌ها باید پیش از بازگشت به حالت پیش‌فرض، اطمینان حاصل کنند که حداکثر یک رزرو برای یک نشانی IP یا پیشوند واگذارشدهٔ مشخص در یک زیرشبکه وجود دارد. اگر چنین موارد تکراری در فایل پیکربندی باقی بمانند، سرور خطای پیکربندی گزارش می‌دهد. باقی گذاشتن چنین رزروهایی در پایگاه‌های دادهٔ میزبان باعث خطای پیکربندی نمی‌شود، اما ممکن است در حین کارکرد سرور، هنگامی که به طور غیرمنتظره چندین رزرو برای همان نشانی IP یا پیشوند واگذارشده پیدا می‌کند، منجر به خطاهای تخصیص اجاره (lease) شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر، سرور Kea بررسی نمی‌کند که آیا هنگام به‌روزرسانی \fBip\-reservations\-unique\fP از \fBfalse\fP به \fBtrue\fP، چندین رزرو برای یک نشانی IP و/یا پیشوند واگذارشدهٔ یکسان در پایگاه‌های دادهٔ میزبان (MySQL و/یا PostgreSQL) وجود دارد یا خیر\&. این موضوع ممکن است باعث بروز مشکلاتی در تخصیص اجاره‌ها شود. مدیر سیستم باید پیش از به‌روزرسانی پیکربندی اطمینان حاصل کند که حداکثر یک رزرو برای هر نشانی IP و/یا پیشوند واگذارشده در هر زیرشبکه وجود دارد. .UNINDENT .UNINDENT .sp پارامتر \fBreservations\-lookup\-first\fP یک پارامتر بولی است که کنترل می‌کند آیا جستجوی رزروهای میزبان باید پیش از جستجوی اجاره انجام شود یا خیر. این پارامتر تنها زمانی مؤثر است که چندریسمانی (multi\-threading) غیرفعال باشد. هنگامی که چندریسمانی فعال باشد، جستجوی رزروهای میزبان همواره ابتدا انجام می‌شود تا از قفل شدن منابع جستجوی اجاره جلوگیری گردد. پارامتر \fBreservations\-lookup\-first\fP در صورت غیرفعال بودن چندریسمانی، به طور پیش‌فرض روی \fBfalse\fP تنظیم است..SS رزرو میزبان به‌عنوان کنترل دسترسی پایه .sp تعریف یک رزرو میزبان (host reservation) که تنها شامل یک شناسه‌گر است، بدون هیچ نشانی، گزینه یا مقداری، امکان‌پذیر است. در برخی از پیاده‌سازی‌ها این کار مفید است، زیرا میزبان‌هایی که دارای رزرو هستند به کلاس KNOWN تعلق می‌گیرند در حالی که سایرین تعلق ندارند. این قابلیت می‌تواند به‌عنوان یک سازوکار ابتدایی برای کنترل دسترسی استفاده شود. .sp مثال زیر این مفهوم را نشان می‌دهد. این مثال یک زیرشبکه IPv6 منفرد را مشخص می‌کند که تمام کلاینت‌ها نشانی خود را از آن دریافت می‌کنند. با این حال، تنها کلاینت‌های شناخته‌شده (آن‌هایی که رزرو دارند) سرور DNS پیش‌فرض خود را پیکربندی‌شده دریافت خواهند کرد. رزروهای خالی، یعنی رزروهایی که فقط معیار شناسایی دارند، می‌توانند روشی مفید برای شناخته‌شده کردن کلاینت‌ها باشند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqKNOWN\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8::1\(dq } ] } ], \(dqreservations\(dq: [ // Clients on this list will be added to the KNOWN class. { \(dqduid\(dq: \(dq01:02:03:04:05:0A:0B:0C:0D:0E\(dq }, { \(dqduid\(dq: \(dq02:03:04:05:0A:0B:0C:0D:0E:0F\(dq } ], \(dqreservations\-global\(dq: true, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1:1::/64\(dq } ] } ] } .EE .UNINDENT .UNINDENT .sp این مفهوم می‌تواند با استفاده از رزروها همراه با برچسب‌گذاری کلاس گزینه‌ها (بخش Option Class\-Tagging \%<#\:option-class-tagging> را ببینید) بیشتر گسترش یابد. یک سناریوی واقعی مناسب می‌تواند وضعیتی باشد که در آن برخی از مشترکان یک ISP صورت‌حساب‌های خود را پرداخت نکرده‌اند. به این مشتریان باید یک سرور DNS جایگزین تخصیص داده شود که به جای ارائه دسترسی به اینترنت، آن‌ها را به یک پورتال اسارتی (captive portal) هدایت کرده و از آن‌ها بخواهد حساب‌های خود را تسویه کنند. می‌توان از رزروها برای تخصیص یک کلاینت به کلاس \(dqblocked\(dq استفاده کرد که متعاقباً برای تعیین مقدار گزینه سرور DNS همان‌طور که در زیر نشان داده شده، به کار می‌رود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqblocked\(dq } ], \(dqreservations\(dq: [ // Clients on this list will be added to the KNOWN class. Some // will also be added to the blocked class. { \(dqduid\(dq: \(dq01:02:03:04:05:0A:0B:0C:0D:0E\(dq, \(dqclient\-classes\(dq: [ \(dqblocked\(dq ] }, { \(dqduid\(dq: \(dq02:03:04:05:0A:0B:0C:0D:0E:0F\(dq } ], \(dqreservations\-global\(dq: true, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1:1::/64\(dq } ], \(dqoption\-data\(dq: [ { // DNS server for blocked customers. \(dqclient\-classes\(dq: [ \(dqblocked\(dq ], \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8::2\(dq }, { // DNS server for customers in good standing. \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8::1\(dq } ] } ] } .EE .UNINDENT .UNINDENT .SS شبکه‌های اشتراکی در DHCPv6 .sp سرورهای DHCP از اطلاعات زیرشبکه به دو روش استفاده می‌کنند. این اطلاعات هم برای تعیین نقطه اتصال (یعنی جایی که کلاینت به شبکه متصل است) و هم برای گروه‌بندی اطلاعات مربوط به یک مکان خاص در شبکه به کار می‌رود. گاهی اوقات استقرار بیش از یک زیرشبکه منطقی IP روی یک پیوند فیزیکی (physical link) یکسان مفید است. درک این موضوع که دو یا چند زیرشبکه روی یک پیوند یکسان استفاده می‌شوند، نیازمند منطق اضافی در سرور DHCP است. این قابلیت در Kea با نام \(dqshared networks\(dq (شبکه‌های اشتراکی) و گاهی نیز \(dqshared subnets\(dq نامیده می‌شود؛ در نام‌گذاری مایکروسافت، به آن \(dqmultinet\(dq گفته می‌شود. .sp موارد زیادی وجود دارد که ویژگی شبکه‌های اشتراکی در آن‌ها مفید است؛ در اینجا تنها به چند مورد از رایج‌ترین آن‌ها اشاره می‌کنیم. نخستین و تا حد زیادی متداول‌ترین مورد استفاده، یک شبکه IPv4 موجود است که گسترش یافته و فضای نشانی دردسترس آن رو به اتمام است. این موضوع در IPv6 کمتر رایج است، اما شبکه‌های اشتراکی همچنان مفید هستند: برای مثال، هنگام اتمام پیشوندهای واگذارشده (delegated prefixes) در IPv6 در یک زیرشبکه، یا تمایل به آزمایش یک طرح آدرس‌دهی جدید. با ظهور استقرار IPv6 و فضای نشانی گسترده، بسیاری از سازمان‌ها فضای نشانی را به زیرشبکه‌ها تقسیم کرده، آن را مستقر می‌کنند و سپس پس از مدتی متوجه می‌شوند که می‌خواهند آن را به شکل متفاوتی تقسیم‌بندی کنند. در دوره گذار، آن‌ها می‌خواهند هر دو آدرس‌دهی قدیمی و جدید در دسترس باشند؛ بنابراین به بیش از یک زیرشبکه روی یک پیوند فیزیکی یکسان نیاز خواهد بود. .sp در نهایت، مورد شبکه‌های کابلی مستقیماً در IPv6 کاربرد دارد. در شبکه‌های کابلی دو نوع دستگاه وجود دارد: مودم‌های کابلی و دستگاه‌های کاربر نهایی پشت آن‌ها. این یک روش معمول است که برای مودم‌های کابلی از زیرشبکه‌های متفاوتی استفاده شود تا از دستکاری آن‌ها توسط کاربران جلوگیری گردد. در این حالت، تمایز به جای اتمام فضای نشانی، بر اساس نوع دستگاه است. .sp به کلاینتی که به یک شبکه اشتراکی متصل است، ممکن است یک اجاره (نشانی یا پیشوند) از هر یک از استخرهای تعریف‌شده در زیرشبکه‌های متعلق به آن شبکه اشتراکی تخصیص داده شود. در داخل، سرور یکی از زیرشبکه‌های متعلق به یک شبکه اشتراکی را انتخاب کرده و تلاش می‌کند یک اجاره را از این زیرشبکه تخصیص دهد. اگر سرور نتواند اجاره‌ای را از زیرشبکه انتخابی تخصیص دهد (به‌عنوان مثال، به دلیل اتمام استخر)، از زیرشبکه دیگری در همان شبکه اشتراکی استفاده کرده و تلاش می‌کند اجاره را از آن تخصیص دهد. سرور معمولاً تمام اجاره‌های موجود در یک زیرشبکه مشخص را پیش از شروع تخصیص اجاره‌ها از سایر زیرشبکه‌های متعلق به همان شبکه اشتراکی واگذار می‌کند. با این حال، در شرایط خاصی ممکن است پیش از اتمام استخرهای زیرشبکه نخست، به کلاینت اجاره‌ای از زیرشبکه دیگری تخصیص یابد؛ این اتفاق گاهی زمانی رخ می‌دهد که کلاینت یک راهنمایی (hint) متعلق به زیرشبکه‌ای دیگر ارائه دهد، یا اینکه کلاینت دارای رزروهایی در زیرشبکه‌ای غیر از زیرشبکه پیش‌فرض باشد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در پیاده‌سازی‌ها نباید این فرض در نظر گرفته شود که Kea پیش از تخصیص نشانی‌ها از سایر زیرشبکه‌ها، حتماً منتظر می‌ماند تا تمام نشانی‌های زیرشبکه نخست در یک شبکه اشتراکی را تخصیص دهد. .UNINDENT .UNINDENT .sp برای تعریف یک شبکه اشتراکی، یک دامنه پیکربندی اضافی معرفی شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqshared\-networks\(dq: [ { # Name of the shared network. It may be an arbitrary string # and it must be unique among all shared networks. \(dqname\(dq: \(dqipv6\-lab\-1\(dq, # The subnet selector can be specified on the shared network # level. Subnets from this shared network will be selected # for clients communicating via relay agent having # the specified IP address. \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq2001:db8:2:34::1\(dq ] }, # This starts a list of subnets in this shared network. # There are two subnets in this example. \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8::1 \- 2001:db8::ffff\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq3ffe:ffe::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq3ffe:ffe::/64\(dq } ] } ] } ], # end of shared\-networks # It is likely that in the network there will be a mix of regular, # \(dqplain\(dq subnets and shared networks. It is perfectly valid # to mix them in the same configuration file. # # This is a regular subnet. It is not part of any shared\-network. \(dqsubnet6\(dq: [ { \(dqid\(dq: 3, \(dqsubnet\(dq: \(dq2001:db9::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db9::/64\(dq } ], \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq2001:db8:1:2::1\(dq ] } } ] } } .EE .UNINDENT .UNINDENT .sp همان‌طور که در مثال نشان داده شد، امکان ترکیب زیرشبکه‌های اشتراکی و زیرشبکه‌های عادی (\(dqplain\(dq) وجود دارد. هر شبکه اشتراکی باید یک نام یکتا داشته باشد. این شبیه به شناسه (ID) برای زیرشبکه‌ها است، اما به مدیران سیستم انعطاف‌پذیری بیشتری می‌دهد. این نام برای ثبت وقایع و همچنین به طور داخلی برای شناسایی شبکه‌های اشتراکی استفاده می‌شود. .sp در اصل منطقی است که تنها شبکه‌های اشتراکی‌ای تعریف شوند که از دو یا چند زیرشبکه تشکیل شده باشند. با این حال، برای اهداف آزمایشی، یک زیرشبکه خالی یا شبکه‌ای با تنها یک زیرشبکه مجاز است. این یک روش توصیه‌شده در شبکه‌های عملیاتی نیست، زیرا منطق شبکه اشتراکی نیازمند پردازش اضافی است و در نتیجه کارایی سرور را کاهش می‌دهد. برای جلوگیری از افت غیرضروری کارایی، زیرشبکه‌های اشتراکی تنها باید در صورتی تعریف شوند که شرایط پیاده‌سازی آن را ایجاب کند. .sp شبکه‌های اشتراکی این امکان را فراهم می‌کنند که پارامترهای متعددی در دامنه شبکه اشتراکی مشخص شوند که بر تمام زیرشبکه‌های درون آن اعمال گردند. در صورت لزوم، می‌توان پارامتری را در دامنه shared\-network مشخص کرد و سپس مقدار آن را در دامنه زیرشبکه بازنویسی (override) نمود. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqlab\-network3\(dq, \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq2001:db8:2:34::1\(dq ] }, # This applies to all subnets in this shared network, unless # values are overridden on subnet scope. \(dqvalid\-lifetime\(dq: 600, # This option is made available to all subnets in this shared # network. \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8::8888\(dq } ], \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::1 \- 2001:db8:1::ffff\(dq } ], # This particular subnet uses different values. \(dqvalid\-lifetime\(dq: 1200, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8::1:2\(dq }, { \(dqname\(dq: \(dqunicast\(dq, \(dqdata\(dq: \(dq2001:abcd::1\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq2001:db8:2::/48\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:2::1 \- 2001:db8:2::ffff\(dq } ], # This subnet does not specify its own valid\-lifetime value, # so it is inherited from shared network scope. \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8:cafe::1\(dq } ] } ] } ], ... } .EE .UNINDENT .UNINDENT .sp در این مثال، گزینه \fBdns\-servers\fP به‌گونه‌ای تعریف شده که برای کلاینت‌ها در هر دو زیرشبکه این شبکه اشتراکی در دسترس است. همچنین، طول عمر معتبر (valid lifetime) روی ۱۰ دقیقه (۶۰۰ ثانیه) تنظیم شده است. با این حال، زیرشبکه نخست برخی از مقادیر را بازنویسی می‌کند (طول عمر معتبر ۲۰ دقیقه است، نشانی IP متفاوتی برای \fBdns\-servers\fP وجود دارد)، و همچنین گزینه اختصاصی خود را اضافه می‌کند (نشانی تک‌پخشی یا unicast). با فرض اینکه به کلاینتی که درخواست گزینه‌های server unicast و \fBdns\-servers\fP را دارد، اجاره‌ای از این زیرشبکه تخصیص یابد، اجاره‌ای به مدت ۲۰ دقیقه و گزینه \fBdns\-servers\fP را دریافت خواهد کرد و مجاز به استفاده از تک‌پخشی سرور در نشانی 2001:abcd::1 خواهد بود. اگر همان کلاینت به زیرشبکه دوم تخصیص داده شود، یک اجاره ۱۰ دقیقه‌ای، مقدار 2001:db8:cafe::1 برای \fBdns\-servers\fP دریافت خواهد کرد و هیچ نشانی تک‌پخشی سروری نخواهد داشت. .sp برخی پارامترها باید در تمام زیرشبکه‌های واقع در یک شبکه اشتراکی یکسان باشند. این محدودیت برای تنظیمات \fBinterface\fP و \fBrapid\-commit\fP اعمال می‌شود. راحت‌ترین روش، تعریف آن‌ها در دامنه shared\-network است، اما می‌توان آن‌ها را برای هر زیرشبکه نیز مشخص کرد. با این حال، هر زیرشبکه باید دارای مقدار یکسانی باشد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگام استفاده از کلاینت‌هایی که چندین گزینه IA را در یک درخواست منفرد ارسال می‌کنند، و شبکه‌های اشتراکی که زیرشبکه‌های آن‌ها مقادیر متفاوتی برای گزینه‌ها و پارامترهای پیکربندی دارند، یک ابهام ذاتی وجود دارد. سرور گزینه‌های IA را به ترتیب وقوع آن‌ها در پرس‌وجوی کلاینت به صورت متوالی پردازش می‌کند؛ اگر اجاره‌های درخواست‌شده در گزینه‌های IA در نهایت از زیرشبکه‌های متفاوتی برآورده شوند، کدام پارامترها و گزینه‌ها باید اعمال شوند؟ در حال حاضر، کد سرور از مقادیر آخرین زیرشبکه مربوط به آخرین گزینه IA برآورده‌شده استفاده می‌کند. .sp ما این مسئله را تا حد زیادی به‌عنوان یک مشکل در پیکربندی سایت در نظر می‌گیریم. یک شبکه اشتراکی معمولاً به معنای همان پیوند فیزیکی است، بنابراین سرویس‌های پیکربندی‌شده توسط گزینه‌های زیرشبکه A باید به همان آسانی از زیرشبکه B قابل دسترسی باشند و برعکس. راه‌های متعددی برای اجتناب از این وضعیت وجود دارد: .INDENT 0.0.IP \(bu 2 از مقادیر یکسان برای گزینه‌ها و پارامترها در زیرشبکه‌های درون شبکهٔ اشتراکی استفاده کنید. .IP \(bu 2 از انتخاب‌گرهای زیرشبکه یا محافظ‌های کلاس کلاینت (client class guards) استفاده کنید که تضمین می‌کنند برای پرس‌وجوی یک کلاینت، برای تمام گزینه‌های IA در آن پرس‌وجو از همان زیرشبکه استفاده شود. .IP \(bu 2 از به‌کارگیری شبکه‌های اشتراکی برای کلاینت‌هایی که در هر پرس‌وجو چندین گزینهٔ IA ارسال می‌کنند خودداری کنید. .UNINDENT .UNINDENT .UNINDENT .SS ترافیک محلی و رله‌شده در شبکه‌های اشتراکی (Local and Relayed Traffic in Shared Networks) .sp تعیین نام رابط (interface) در سطح shared\-network امکان‌پذیر است تا به سرور اعلام شود این شبکهٔ اشتراکی خاص، به‌طور مستقیم (نه از طریق رله‌ها) و با استفاده از رابط شبکهٔ محلی در دسترس است. از آنجا که انتظار می‌رود تمام زیرشبکه‌ها در یک شبکهٔ اشتراکی روی پیوند فیزیکی یکسانی استفاده شوند، تلاش برای تعریف یک شبکهٔ اشتراکی با زیرشبکه‌هایی که از طریق رابط‌های متفاوتی در دسترس هستند یک خطای پیکربندی است. به عبارت دیگر، تمام زیرشبکه‌های درون شبکهٔ اشتراکی باید مقدار یکسانی برای پارامتر \fBinterface\fP داشته باشند. پیکربندی زیر نمونه‌ای از کارهایی است که \fBنباید\fP انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqoffice\-floor\-2\(dq, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8::1 \- 2001:db8::ffff\(dq } ], \(dqinterface\(dq: \(dqeth0\(dq }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq3ffe:abcd::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq3ffe:abcd::1 \- 3ffe:abcd::ffff\(dq } ], ... # Specifying a different interface name is a configuration # error. This value should rather be \(dqeth0\(dq or the interface # name in the other subnet should be \(dqeth1\(dq. # \(dqinterface\(dq: \(dqeth1\(dq } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp برای به حداقل رساندن احتمال خطاهای پیکربندی، اغلب راحت‌تر است که نام رابط به سادگی یک بار در سطح shared\-network تعیین شود، همان‌طور که در مثال زیر نشان داده شده است. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqoffice\-floor\-2\(dq, # This tells Kea that the whole shared network is reachable over a # local interface. This applies to all subnets in this network. \(dqinterface\(dq: \(dqeth0\(dq, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8::1 \- 2001:db8::ffff\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq3ffe:abcd::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq3ffe:abcd::1 \- 3ffe:abcd::ffff\(dq } ] } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp در ترافیک رله‌شده، زیرشبکه‌ها معمولاً با استفاده از نشانی‌های عامل‌های رله (relay agents) انتخاب می‌شوند. اگر زیرشبکه‌ها به‌طور مستقل (بدون گروه‌بندی در یک شبکهٔ اشتراکی) استفاده شوند، می‌توان برای هر یک از این زیرشبکه‌ها نشانی رلهٔ متفاوتی تعیین کرد. هنگامی که چندین زیرشبکه به یک شبکهٔ اشتراکی تعلق دارند، باید از طریق نشانی رلهٔ یکسانی انتخاب شوند و مانند مورد ترافیک محلی شرح داده شده در بالا، تعیین نشانی‌های رلهٔ متفاوت برای زیرشبکه‌های مربوطه در شبکهٔ اشتراکی یک خطای پیکربندی است. پیکربندی زیر نمونهٔ دیگری از کارهایی است که \fBنباید\fP انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqkakapo\(dq, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8::/64\(dq, \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq2001:db8::1234\(dq ] }, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8::1 \- 2001:db8::ffff\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq3ffe:abcd::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq3ffe:abcd::1 \- 3ffe:abcd::ffff\(dq } ], \(dqrelay\(dq: { # Specifying a different relay address for this # subnet is a configuration error. In this case # it should be 2001:db8::1234 or the relay address # in the previous subnet should be 3ffe:abcd::cafe. \(dqip\-addresses\(dq: [ \(dq3ffe:abcd::cafe\(dq ] } } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp مجدداً، بهتر است نشانی رله در سطح shared\-network تعیین شود؛ این مقدار توسط تمام زیرشبکه‌های متعلق به شبکهٔ اشتراکی به ارث برده خواهد شد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqkakapo\(dq, \(dqrelay\(dq: { # This relay address is inherited by both subnets. \(dqip\-addresses\(dq: [ \(dq2001:db8::1234\(dq ] }, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8::1 \- 2001:db8::ffff\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq3ffe:abcd::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq3ffe:abcd::1 \- 3ffe:abcd::ffff\(dq } ] } ] } ], \&... } .EE .UNINDENT .UNINDENT .sp اگرچه از نظر فنی امکان پیکربندی دو (یا چند) زیرشبکه در شبکهٔ اشتراکی برای استفاده از نشانی‌های رلهٔ متفاوت وجود دارد، اما این کار تقریباً همیشه به رفتاری متفاوت از انتظار کاربر منجر خواهد شد. در این حالت، سرور Kea در ابتدا یکی از زیرشبکه‌ها را با تطبیق نشانی رله در بستهٔ کلاینت با پیکربندی زیرشبکه انتخاب می‌کند. با این حال، اگر کلاینت از قبل اجاره‌ای (lease) در زیرشبکهٔ دیگر داشته باشد یا یک رزرو میزبان (host reservation) در آن زیرشبکه داشته باشد، یا صرفاً اگر زیرشبکهٔ انتخاب‌شده در ابتدا نشانی در دسترس دیگری نداشته باشد، سرور ممکن است در نهایت از زیرشبکهٔ دیگر استفاده کند (حتی اگر با نشانی رله مطابقت نداشته باشد). بنابراین، اکیداً توصیه می‌شود در صورتی که زیرشبکه‌ها متعلق به یک شبکهٔ اشتراکی هستند، همیشه انتخاب‌گرهای زیرشبکه (interface یا نشانی relay) در سطح shared\-network تعیین شوند، چرا که تعیین آن‌ها در سطح subnet به‌ندرت مفید است و می‌تواند منجر به خطاهای پیکربندی شرح داده شده در بالا شود..SS "طبقه‌بندی کلاینت‌ها در شبکه‌های مشترک (Client Classification in Shared Networks)" .sp گاهی مطلوب است که کلاینت‌ها بر اساس ویژگی‌های معینی در زیرشبکه‌های خاصی تفکیک شوند. این سازوکار طبقه‌بندی کلاینت (client classification) نامیده می‌شود و در Client Classification \%<#\:classify>\& شرح داده شده است. طبقه‌بندی کلاینت را می‌توان به همان شیوه‌ای که برای زیرشبکه‌های تعریف‌شده در خارج از شبکه‌های مشترک استفاده می‌شود، برای زیرشبکه‌های متعلق به شبکه‌های مشترک (shared networks) نیز اعمال کرد. درک نحوهٔ انتخاب زیرشبکه‌ها برای کلاینت‌ها توسط سرور هنگام استفاده از طبقه‌بندی کلاینت اهمیت دارد، تا اطمینان حاصل شود که زیرشبکهٔ مناسب برای یک نوع کلاینت مشخص انتخاب می‌شود. .sp اگر یک زیرشبکه با یک کلاس مرتبط شده باشد، تنها کلاینت‌های متعلق به این کلاس می‌توانند از این زیرشبکه استفاده کنند. چنانچه هیچ کلاسی برای یک زیرشبکه تعیین نشده باشد، هر کلاینت متصل به یک شبکهٔ مشترک معین می‌تواند از این زیرشبکه استفاده نماید. یک اشتباه رایج این است که فرض شود زیرشبکهٔ شامل کلاس کلاینت، بر زیرشبکه‌های بدون کلاس کلاینت ارجحیت دارد. .sp پارامتر \fBclient\-classes\fP ممکن است در دامنه‌های shared network، subnet و/یا pool تعیین شود. اگر برای یک shared network تعیین شود، کلاینت‌ها باید حداقل عضو یکی از کلاس‌های مشخص‌شده برای آن شبکه باشند تا برای زیرشبکه‌های درون آن شبکه در نظر گرفته شوند. اگر برای یک subnet مشخص گردد، کلاینت‌ها باید دست‌کم متعلق به یکی از کلاس‌های مشخص‌شده برای آن زیرشبکه باشند تا برای هر یک از استخرها (pools) یا رزروهای میزبان (host reservations) آن زیرشبکه مد نظر قرار گیرند. اگر برای یک pool مشخص شود، کلاینت‌ها باید حداقل عضو یکی از کلاس‌های مشخص‌شده برای آن استخر باشند تا یک اجاره (lease) از آن pool دریافت کنند. .sp مثال زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqb\-devices\(dq, \(dqtest\(dq: \(dqoption[1234].hex == 0x0002\(dq } ], \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqgalah\(dq, \(dqrelay\(dq: { \(dqip\-address\(dq: [ \(dq2001:db8:2:34::1\(dq ] }, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::20 \- 2001:db8:1::ff\(dq } ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq2001:db8:3::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:3::20 \- 2001:db8:3::ff\(dq } ], \(dqclient\-classes\(dq: \(dqb\-devices\(dq } ] } ] } .EE .UNINDENT .UNINDENT .sp اگر کلاینت متعلق به کلاس \(dqb\-devices\(dq باشد (به این دلیل که شامل option 1234 با مقدار 0x0002 است)، این تضمین نمی‌کند که زیرشبکهٔ 2001:db8:3::/64 برای این کلاینت استفاده (یا ترجیح داده) شود. سرور می‌تواند از هر یک از این دو زیرشبکه استفاده کند، چرا که زیرشبکهٔ 2001:db8:1::/64 نیز برای این کلاینت مجاز است. طبقه‌بندی کلاینت به‌کاررفته در این مورد باید به عنوان راهی برای محدود کردن دسترسی به زیرشبکه‌های خاص تلقی شود، نه روشی برای اولویت‌بندی زیرشبکه‌ها. برای مثال، اگر کلاینت متعلق به کلاس \(dqb\-devices\(dq نباشد، فقط می‌تواند از زیرشبکهٔ 2001:db8:1::/64 استفاده کند و هرگز از زیرشبکهٔ 2001:db8:3::/64 استفاده نخواهد کرد. .sp یک کاربرد معمول برای طبقه‌بندی کلاینت در شبکه‌های کابلی (cable network) است؛ جایی که مودم‌های کابلی باید از یک زیرشبکه و سایر دستگاه‌ها باید از زیرشبکهٔ دیگری درون همان شبکهٔ مشترک استفاده کنند. در این حالت، اعمال طبقه‌بندی بر روی تمام زیرشبکه‌ها ضروری است. مثال زیر دو کلاس از دستگاه‌ها را تعریف می‌کند و انتخاب زیرشبکه بر اساس مقادیر option 1234 انجام می‌گیرد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqa\-devices\(dq, \(dqtest\(dq: \(dqoption[1234].hex == 0x0001\(dq }, { \(dqname\(dq: \(dqb\-devices\(dq, \(dqtest\(dq: \(dqoption[1234].hex == 0x0002\(dq } ], \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqgalah\(dq, \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq2001:db8:2:34::1\(dq ] }, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::20 \- 2001:db8:1::ff\(dq } ], \(dqclient\-classes\(dq: [ \(dqa\-devices\(dq ] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq2001:db8:3::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:3::20 \- 2001:db8:3::ff\(dq } ], \(dqclient\-classes\(dq: [ \(dqb\-devices\(dq ] } ] } ] } .EE .UNINDENT .UNINDENT .sp در این مثال هر کلاس محدودیت خاص خود را دارد. تنها کلاینت‌هایی که متعلق به کلاس \(dqa\-devices\(dq هستند می‌توانند از زیرشبکهٔ 2001:db8:1::/64 استفاده کنند و تنها کلاینت‌های متعلق به \(dqb\-devices\(dq قادر به استفاده از زیرشبکهٔ 2001:db8:3::/64 خواهند بود. باید دقت شود که قواعد طبقه‌بندی بیش از حد محدودکننده تعریف نشوند، زیرا از ارائهٔ سرویس به کلاینت‌هایی که قادر به استفاده از هیچ زیرشبکه‌ای نیستند امتناع خواهد شد. با این حال، چنانچه هدف ارائهٔ سرویس صرفاً به کلاینت‌هایی با ویژگی‌های مشخص باشد (مثلاً فقط تلفن‌های VoIP مجاز به اتصال به یک پیوند خاص باشند)، این می‌تواند یک نتیجهٔ مطلوب باشد. .sp می‌توان بدون استفاده از shared networks نیز به نتیجه‌ای مشابه با آنچه در این بخش مطرح شد دست یافت. اگر زیرشبکه‌ها به جای قرار گرفتن در shared network، در دامنهٔ سراسری زیرشبکه‌ها (global subnets scope) قرار گیرند، سرور همچنان از قواعد طبقه‌بندی برای انتخاب زیرشبکهٔ مناسب برای یک کلاس خاص از دستگاه‌ها استفاده خواهد کرد. مزیت اصلی قرار دادن زیرشبکه‌ها در یک shared network این است که پارامترهای مشترک برای زیرشبکه‌هایی که از نظر منطقی گروه‌بندی شده‌اند را می‌توان یک‌بار در دامنهٔ shared network مشخص کرد؛ مانند پارامترهای \fBinterface\fP یا \fBrelay\fP. تمام زیرشبکه‌های متعلق به این شبکه مشترک، آن پارامترها را به ارث خواهند برد..SS رزروهای میزبان در شبکه‌های اشتراکی (Shared Networks) .sp زیرشبکه‌هایی که بخشی از یک شبکه اشتراکی هستند، همانند زیرشبکه‌های معمولی اجازه رزرو میزبان را می‌دهند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqfrog\(dq, \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq2001:db8:2:34::1\(dq ] }, \(dqsubnet6\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqid\(dq: 100, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::1 \- 2001:db8:1::64\(dq } ], \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq00:03:00:01:11:22:33:44:55:66\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1::28\(dq ] } ] }, { \(dqsubnet\(dq: \(dq2001:db8:3::/64\(dq, \(dqid\(dq: 101, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:3::1 \- 2001:db8:3::64\(dq } ], \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq00:03:00:01:aa:bb:cc:dd:ee:ff\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:2::28\(dq ] } ] } ] } ] } .EE .UNINDENT .UNINDENT .sp شایان ذکر است که در صورت تعریف شبکه‌های اشتراکی، Kea هنگام پردازش بسته، بررسی‌های بیشتری انجام می‌دهد. نخست، Kea به جای اینکه صرفاً بررسی کند آیا برای کلاینت مورد نظر در زیرشبکه اولیه انتخاب‌شده رزروی وجود دارد یا خیر، تمام زیرشبکه‌های موجود در یک شبکه اشتراکی را برای یافتن رزرو جستجو می‌کند. این یکی از دلایلی است که چرا تعریف یک شبکه اشتراکی ممکن است بر کارایی تأثیر بگذارد. اگر در هر یک از زیرشبکه‌ها رزروی برای کلاینت وجود داشته باشد، همان زیرشبکه خاص برای کلاینت انتخاب می‌شود. اگرچه از نظر فنی خطا محسوب نمی‌شود، اما تعریف رزرو برای یک میزبان یکسان در چندین زیرشبکه متعلق به یک شبکه اشتراکی، روشی نادرست تلقی می‌شود. .sp اگرچه استفاده از مقادیر صریح \(dqid\(dq برای زیرشبکه‌ها کاملاً اجباری نیست، اما در صورتی که قرار باشد از ذخیره‌سازی پایگاه‌داده برای رزروهای میزبان استفاده شود، به‌شدت توصیه می‌شود. اگر یک شناسه مشخص نشود، مقادیر آن به‌طور خودکار تولید می‌شوند؛ بدین معنا که Kea مقادیر صحیح افزایشی را از ۱ تخصیص می‌دهد. بنابراین، شناسه‌های تولیدشده به‌طور خودکار در طول تغییرات پیکربندی پایدار نخواهند بود. .SS شناسه سرور در DHCPv6 .sp پروتکل DHCPv6 از یک \(dqشناسه سرور\(dq (که با نام DUID نیز شناخته می‌شود) استفاده می‌کند تا به کلاینت‌ها امکان دهد بین چندین سرور موجود در یک پیوند (link) یکسان تمایز قائل شوند. استاندارد RFC 9915 \% در حال حاضر چهار نوع DUID را تعریف می‌کند: DUID\-LLT، DUID\-EN، DUID\-LL و DUID\-UUID. .sp سرور DHCPv6 در Kea یک‌بار در هنگام نخستین راه‌اندازی، یک شناسه سرور تولید کرده و آن را در یک فایل ذخیره می‌کند. این شناسه در طول راه‌اندازی‌های مجدد سرور تغییر نمی‌کند و از این رو شناسه‌ای پایدار است. .sp نرم‌افزار Kea از توصیه مطرح‌شده در RFC 9915 \% مبنی بر استفاده از DUID\-LLT به عنوان شناسه سرور پیش‌فرض پیروی می‌کند. با این حال، ISC گزارش‌هایی دریافت کرده است مبنی بر اینکه برخی استقرارها به انواع متفاوتی از DUID نیاز دارند، و لازم است نوع DUID و/یا محتوای آن به صورت مدیریتی تعیین شود. .sp شناسه سرور را می‌توان با استفاده از پارامترهای موجود در عنصر نگاشت \fBserver\-id\fP در حوزه سراسری فایل پیکربندی Kea پیکربندی کرد. مثال زیر نحوه انتخاب DUID\-EN را به عنوان شناسه سرور نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqserver\-id\(dq: { \(dqtype\(dq: \(dqEN\(dq }, ... } .EE .UNINDENT .UNINDENT .sp مقادیر پشتیبانی‌شده کنونی برای پارامتر \fBtype\fP به ترتیب عبارتند از: \(dqLLT\(dq، \(dqEN\(dq و \(dqLL\(dq، به ترتیب برای DUID\-LLT، DUID\-EN و DUID\-LL. .sp هنگامی که یک نوع DUID جدید انتخاب می‌شود، سرور مقدار آن را تولید کرده و جایگزین هر DUID موجود در فایل می‌کند. سپس سرور از شناسه سرور جدید در تمامی تعاملات بعدی با کلاینت‌ها استفاده خواهد کرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگر شناسه سرور جدید پس از دریافت اجاره‌ها (leases) توسط برخی کلاینت‌ها ایجاد شود، کلاینت‌هایی که از شناسه قدیمی استفاده می‌کنند قادر به تمدید اجاره‌های خود نخواهند بود؛ سرور پیام‌های حاوی شناسه سرور قدیمی را نادیده خواهد گرفت. کلاینت‌ها به ارسال پیام‌های RENEW ادامه می‌دهند تا زمانی که به وضعیت rebinding منتقل شوند. در این وضعیت، آنها شروع به ارسال پیام‌های REBIND به آدرس چندپخشی (multicast) بدون شناسه سرور می‌کنند. سرور با شناسه سرور جدید به پیام‌های REBIND پاسخ می‌دهد و کلاینت‌ها شناسه سرور جدید را با اجاره‌های خود مرتبط می‌سازند. اگرچه کلاینت‌ها قادر به حفظ اجاره‌های خود خواهند بود و در نهایت شناسه سرور جدید را یاد می‌گیرند، اما این امر به بهای افزایش تعداد درخواست‌های تمدید و ترافیک چندپخشی ناشی از نیاز به rebind تمام خواهد شد. بنابراین، توصیه می‌شود در صورتی که سرور از قبل اجاره‌هایی تخصیص داده و این اجاره‌ها همچنان معتبر هستند، از تغییر نوع و مقدار شناسه سرور خودداری شود. .UNINDENT .UNINDENT .sp مواردی وجود دارد که مدیر سیستم به جای اجازه دادن به سرور برای تولید مقدار DUID، نیاز به تعیین صریح آن دارد. مثال زیر نحوه تنظیم صریح تمامی مؤلفه‌های یک DUID\-LLT را نشان می‌دهد. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqserver\-id\(dq: { \(dqtype\(dq: \(dqLLT\(dq, \(dqhtype\(dq: 8, \(dqidentifier\(dq: \(dqA65DC7410F05\(dq, \(dqtime\(dq: 2518920166 }, ... } .EE .UNINDENT .UNINDENT .sp که در آن: .INDENT 0.0 .IP \(bu 2 \fBhtype\fP یک مقدار ۱۶ بیتی بدون علامت است که نوع سخت‌افزار را مشخص می‌کند، .IP \(bu 2 \fBidentifier\fP یک آدرس لایه پیوند (link\-layer) است که به صورت رشته‌ای از ارقام هگزادسیمال مشخص می‌شود، و .IP \(bu 2 \fBtime\fP یک مقدار زمان ۳۲ بیتی بدون علامت است. .UNINDENT .sp نمایش هگزادسیمال DUID تولیدشده در نتیجه پیکربندی مشخص‌شده در بالا به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX 00:01:00:08:96:23:AB:E6:A6:5D:C7:41:0F:05 |type |htype| time | identifier | .EE .UNINDENT .UNINDENT .sp مقدار ویژه \(dq0\(dq برای \fBhtype\fP و \fBtime\fP مجاز است، که نشان می‌دهد سرور باید از هر مقداری برای این مؤلفه‌ها استفاده کند. اگر سرور از قبل از یک DUID\-LLT استفاده کند، از مقادیر موجود در همین DUID استفاده خواهد کرد؛ اگر سرور از DUID با نوع متفاوتی استفاده کند یا هنوز از هیچ DUID استفاده نکرده باشد، این مقادیر را تولید خواهد کرد. به همین ترتیب، اگر به \fBidentifier\fP یک رشته خالی اختصاص داده شود، مقدار \fBidentifier\fP تولید خواهد شد. حذف هر یک از این پارامترها معادل تنظیم آنها بر روی این مقادیر ویژه است. .sp برای نمونه، پیکربندی زیر: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqserver\-id\(dq: { \(dqtype\(dq: \(dqLLT\(dq, \(dqhtype\(dq: 0, \(dqidentifier\(dq: \(dq\(dq, \(dqtime\(dq: 2518920166 }, ... } .EE .UNINDENT .UNINDENT .sp نشان می‌دهد که سرور باید از هر آدرس لایه پیوند و نوع سخت‌افزاری استفاده کند. اگر سرور از قبل از DUID\-LLT استفاده کند، از آدرس لایه پیوند و نوع سخت‌افزار موجود در DUID فعلی استفاده خواهد کرد. اگر سرور هنوز از هیچ DUID استفاده نمی‌کند، از آدرس لایه پیوند و نوع سخت‌افزار یکی از رابط‌های شبکه موجود استفاده خواهد کرد. سرور از مقدار زمانی صریح استفاده خواهد کرد؛ اگر این مقدار با مقدار زمان موجود در DUID کنونی متفاوت باشد، آن مقدار جایگزین خواهد شد که عملاً شناسه سرور فعلی را تغییر می‌دهد. .sp مثال زیر یک پیکربندی صریح از یک DUID\-EN را نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqserver\-id\(dq: { \(dqtype\(dq: \(dqEN\(dq, \(dqenterprise\-id\(dq: 2495, \(dqidentifier\(dq: \(dq87ABEF7A5BB545\(dq }, ... } .EE .UNINDENT .UNINDENT .sp که در آن: .INDENT 0.0.IP \(bu 2 \fBenterprise\-id\fP یک مقدار ۳۲\-بیتی بدون علامت است که شماره سازمانی (enterprise number) را نگه می‌دارد، و .IP \(bu 2 \fBidentifier\fP یک شناسه با طول متغیر در DUID\-EN است. .UNINDENT .sp نمایش هگزادسیمال DUID\-EN ایجادشده طبق پیکربندی بالا به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX 00:02:00:00:09:BF:87:AB:EF:7A:5B:B5:45 |type | ent\-id | identifier | .EE .UNINDENT .UNINDENT .sp همانند حالت DUID\-LLT، می‌توان از مقادیر ویژه‌ای برای پیکربندی DUID\-EN استفاده کرد. اگر \fBenterprise\-id\fP برابر \(dq0\(dq باشد، سرور از مقدار موجود در DUID\-EN فعلی استفاده خواهد کرد. اگر سرور از هیچ DUID استفاده نکند یا DUID موجود از نوع متفاوتی باشد، شناسه سازمانی ISC استفاده خواهد شد. هنگامی که یک رشته خالی برای \fBidentifier\fP وارد شود، از شناسه موجود در DUID\-EN فعلی استفاده می‌شود. اگر سرور از هیچ DUID\-EN استفاده نکند، یک \fBidentifier\fP جدید با طول ۶ بایت ایجاد خواهد شد. .sp پیکربندی DUID\-LL به همان روش DUID\-LLT انجام می‌شود، با این تفاوت که پارامتر \fBtime\fP هیچ تأثیری بر DUID\-LL ندارد، زیرا این نوع DUID تنها شامل یک نوع سخت‌افزار و نشانی لایه پیوند است. مثال زیر نحوه پیکربندی DUID\-LL را نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqserver\-id\(dq: { \(dqtype\(dq: \(dqLL\(dq, \(dqhtype\(dq: 8, \(dqidentifier\(dq: \(dqA65DC7410F05\(dq }, ... } .EE .UNINDENT .UNINDENT .sp که به شناسه سرور زیر منجر خواهد شد: .INDENT 0.0 .INDENT 3.5 .sp .EX 00:03:00:08:A6:5D:C7:41:0F:05 |type |htype| identifier | .EE .UNINDENT .UNINDENT .sp سرور شناسه سرور ایجادشده را در مکان زیر ذخیره می‌کند: \fB\(dq[kea\-install\-dir]/var/lib/kea/kea\-dhcp6\-serverid\(dq\fP\&. .sp از Kea نسخه 2.7.9 به بعد، این مسیر می‌تواند هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_DHCP_DATA_DIR\fP به مسیر دلخواه بازنویسی شود. .sp در برخی استقرارهای نامتداول که هیچ فضای ذخیره‌سازی پایداری در دسترس نیست، سرور باید طوری پیکربندی شود که برای ذخیره شناسه سرور تلاش نکند. این انتخاب با مقدار پارامتر بولی \fBpersist\fP کنترل می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqserver\-id\(dq: { \(dqtype\(dq: \(dqEN\(dq, \(dqenterprise\-id\(dq: 2495, \(dqidentifier\(dq: \(dq87ABEF7A5BB545\(dq, \(dqpersist\(dq: false }, ... } .EE .UNINDENT .UNINDENT .sp مقدار پیش‌فرض پارامتر \fBpersist\fP برابر با \fBtrue\fP است، که سرور را طوری پیکربندی می‌کند که شناسه سرور را روی یک دیسک ذخیره کند. .sp در مثال بالا، سرور طوری پیکربندی شده است که شناسه سرور تولیدشده را روی دیسک ذخیره نکند. اما اگر شناسه سرور در پیکربندی تغییر داده نشود، پس از راه‌اندازی مجدد سرور از همان مقدار استفاده می‌شود، چرا که کل شناسه سرور به صورت صریح در پیکربندی مشخص شده است. .SS "دایرکتوری داده‌های DHCPv6 (DHCPv6 Data Directory)" .sp سرور Kea DHCPv6 فایل شناسه سرور و فایل پیش‌فرض اجاره‌های حافظه را در دایرکتوری داده‌های خود قرار می‌دهد. به طور پیش‌فرض این دایرکتوری \fB\(dq[kea\-install\-dir]/var/lib/kea\(dq\fP است، اما این مکان را می‌توان با استفاده از پارامتر سراسری \fBdata\-directory\fP تغییر داد، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqdata\-directory\(dq: \(dq/var/lib/kea/kea\-server6\(dq, ... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از Kea نسخه 2.7.9، پارامتر \fBdata\-directory\fP منسوخ شده است. فایل‌های duid و اجاره (lease) ممکن است فقط از دایرکتوری تعیین‌شده در زمان کامپایل بارگیری شوند: \fB\(dq[kea\-install\-dir]/var/lib/kea\(dq\fP\&. این مسیر می‌تواند هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_DHCP_DATA_DIR\fP به مسیر مورد نظر بازنویسی شود. اگر مسیری غیر از این مقدار در \fBdata\-directory\fP استفاده شود، Kea خطایی صادر کرده و از شروع به کار خودداری می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت می‌کند. .UNINDENT .UNINDENT.SS DHCPv6 بدون‌حالت (پیام INFORMATION\-REQUEST) .sp به‌طور معمول DHCPv6 برای تخصیص هر دو مورد نشانی‌ها و گزینه‌ها به کار می‌رود. این تخصیص‌ها (اجاره‌ها) دارای وضعیتی هستند که در طول زمان تغییر می‌کند، از این رو به عنوان \(dqبا‌حالت\(dq توصیف می‌شوند. پروتکل DHCPv6 همچنین از یک حالت \(dqبدون‌حالت\(dq پشتیبانی می‌کند که در آن کلاینت‌ها تنها گزینه‌های پیکربندی را درخواست می‌کنند. این حالت از دیدگاه سرور سبک به شمار می‌آید، زیرا به هیچ‌گونه رهگیری وضعیت نیاز ندارد. .sp سرور Kea از حالت بدون‌حالت پشتیبانی می‌کند. هنگامی که کلاینت‌ها پیام‌های INFORMATION\-REQUEST ارسال می‌کنند، سرور در صورت موجود بودن گزینه‌ها در پیکربندی سرور، پاسخ‌ها را به همراه گزینه‌های درخواستی بازمی‌گرداند. سرور ابتدا تلاش می‌کند از گزینه‌های مختص به هر زیرشبکه استفاده کند؛ اگر این کار ناموفق باشد، سپس سعی می‌کند گزینه‌های تعریف‌شده در حوزه سراسری را ارائه دهد. .sp حالت‌های بدون‌حالت و با‌حالت می‌توانند در کنار یکدیگر استفاده شوند. برای مدیریت این موضوع به هیچ دستورالعمل پیکربندی خاصی نیاز نیست؛ کافی است از پیکربندی مربوط به کلاینت‌های با‌حالت استفاده شود و کلاینت‌های بدون‌حالت تنها گزینه‌هایی را که درخواست کرده‌اند دریافت خواهند کرد. .sp امکان اجرای سروری که تنها گزینه‌ها را ارائه دهد و هیچ نشانی یا پیشوندی تخصیص ندهد وجود دارد. اگر گزینه‌ها در هر زیرشبکه مقدار یکسانی داشته باشند، می‌توان گزینه‌های مورد نیاز را در حوزه سراسری تعریف کرد و تعاریف زیرشبکه را به‌کلی نادیده گرفت. در اینجا نمونه ساده‌ای از چنین پیکربندی آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqethX\(dq ] }, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8::1, 2001:db8::2\(dq } ], \(dqlease\-database\(dq: { \(dqtype\(dq: \(dqmemfile\(dq } } .EE .UNINDENT .UNINDENT .sp این پیکربندی بسیار ساده، اطلاعات سرور DNS را بدون در نظر گرفتن موقعیت مکانی کلاینت‌ها در اختیار تمام کلاینت‌های شبکه قرار می‌دهد. پایگاه داده اجاره memfile باید مشخص شود، زیرا Kea نیازمند مشخص شدن یک پایگاه داده اجاره است حتی اگر از آن استفاده نشود. .SS پشتیبانی از RFC 7550 (اکنون بخشی از RFC 9915) .sp مستند RFC 7550 \% تغییراتی را در مشخصات قبلی DHCPv6، یعنی RFC 3315 \% و RFC 3633 \% ایجاد کرد تا مشکلات ناشی از همزیستی چند گزینه با‌حالت در پیام‌های مبادله‌شده میان کلاینت‌ها و سرورها برطرف شود. این تغییرات بعداً در جدیدترین مشخصات پروتکل DHCPv6، یعنی RFC 9915 \% گنجانده شدند که جایگزین RFC 7550 \%\& گردید. پروتکل Kea از RFC 9915 \% به همراه این تغییرات پروتکل پشتیبانی می‌کند که در ادامه به طور خلاصه شرح داده شده‌اند. .sp هنگامی که یک کلاینت، مانند یک مسیریاب درخواست‌کننده، در طول تبادل ۴ مرحله‌ای (SARR) با سرور درخواست تخصیص هم‌زمان نشانی‌ها و پیشوندها را ارسال کند و سرور برای تخصیص هیچ پیشوندی پیکربندی نشده باشد اما بتواند تعدادی نشانی تخصیص دهد، با IA_NA(ها) حاوی نشانی‌های تخصیص‌یافته و IA_PD(ها) حاوی کد وضعیت NoPrefixAvail پاسخ خواهد داد. مطابق با مشخصات به‌روزرسانی‌شده، اگر کلاینت بتواند بدون پیشوندها به کار خود ادامه دهد، باید نشانی‌های تخصیص‌یافته را بپذیرد و به وضعیت \(dqbound\(dq منتقل شود. هنگامی که کلاینت متعاقباً پیام‌های RENEW/REBIND را به منظور تمدید طول عمر نشانی‌های تخصیص‌یافته، بر اساس زمان‌های T1 و T2 به سرور ارسال می‌کند، در صورتی که کلاینت همچنان مایل به دریافت پیشوندها از سرور باشد، می‌تواند یک IA_PD را نیز در RENEW/REBIND برای درخواست تخصیص پیشوندها بگنجاند. اگر سرور همچنان قادر به تخصیص پیشوندها نباشد، با IA_PD(ها) حاوی کد وضعیت NoPrefixAvail پاسخ خواهد داد. با این حال، اگر سرور بتواند پیشوندها را تخصیص دهد، آن‌ها را تخصیص داده و در IA_PD(ها) به کلاینت ارسال می‌کند. وضعیت مشابهی زمانی رخ می‌دهد که سرور قادر به تخصیص نشانی برای کلاینت نباشد اما امکان تفویض پیشوندها را داشته باشد: کلاینت می‌تواند هنگام تمدید پیشوندهای تفویض‌شده، درخواست تخصیص نشانی‌ها را مطرح کند. تخصیص اجاره‌ها برای سایر انواع IA در حین تمدید اجاره‌های موجود، به‌طور پیش‌فرض توسط سرور Kea DHCPv6 پشتیبانی می‌شود و سرور هیچ سازوکار پیکربندی‌ای برای غیرفعال کردن این رفتار ارائه نمی‌دهد. .sp موارد زیر رفتارهای دیگری هستند که ابتدا در RFC 7550 \% (اکنون بخشی از RFC 9915 \%) معرفی شدند و توسط سرور Kea DHCPv6 پشتیبانی می‌شوند: .INDENT 0.0 .IP \(bu 2 تنظیم تایمرهای T1/T2 روی مقدار یکسان برای تمام گزینه‌های با‌حالت (IA_NA و IA_PD) به منظور تسهیل تمدید هم‌زمان همه اجاره‌های یک کلاینت (در یک تبادل پیام واحد). .IP \(bu 2 قرار دادن کدهای وضعیت NoAddrsAvail و NoPrefixAvail در گزینه‌های IA_NA و IA_PD در پیام ADVERTISE، به جای قرار دادن آن‌ها به عنوان گزینه‌های سطح بالا. .UNINDENT .SS استفاده از یک عامل رله مشخص برای یک زیرشبکه .sp سرور DHCPv6 برای انتخاب یک زیرشبکه جهت کلاینت، از اصول مشابهی با سرور DHCPv4 پیروی می‌کند؛ البته با تفاوت‌های قابل‌توجهی که عمدتاً مربوط به رله‌ها است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگامی که زیرشبکه انتخاب‌شده عضوی از یک شبکه مشترک باشد، کل شبکه مشترک انتخاب می‌شود. .UNINDENT .UNINDENT .sp یک رله باید رابطی متصل به پیوندی داشته باشد که کلاینت‌ها روی آن پیکربندی می‌شوند. به‌طور معمول رله یک نشانی IPv6 سراسری پیکربندی‌شده روی آن رابط دارد که متعلق به زیرشبکه‌ای است که سرور نشانی‌ها را از آن تخصیص می‌دهد. در شرایط عادی، سرور قادر است از نشانی IPv6 درج‌شده توسط رله (در فیلد \fBlink\-addr\fP در پیام RELAY\-FORW) برای انتخاب زیرشبکه مناسب استفاده کند. .sp با این حال، همیشه این‌طور نیست؛ نشانی رله ممکن است در برخی استقرارها با زیرشبکه مطابقت نداشته باشد. این موضوع معمولاً به این معنی است که بیش از یک زیرشبکه برای یک پیوند خاص تخصیص یافته است. دو نمونه رایج از این حالت، بازشماره‌گذاری طولانی‌مدت شبکه (جایی که هر دو فضای نشانی قدیم و جدید همچنان مورد استفاده قرار می‌گیرند) و شبکه کابلی هستند. در یک شبکه کابلی، هم مودم‌های کابلی و هم دستگاه‌های پشت آن‌ها به صورت فیزیکی به یک پیوند متصل هستند، اما از آدرس‌دهی متفاوتی استفاده می‌کنند. در چنین حالتی، سرور DHCPv6 به اطلاعات اضافی (مقدار گزینه \fBinterface\-id\fP یا نشانی IPv6 درج‌شده در فیلد \fBlink\-addr\fP در پیام RELAY\-FORW) نیاز دارد تا بتواند زیرشبکه مناسب را به‌درستی انتخاب کند. .sp مثال زیر فرض می‌کند که زیرشبکه 2001:db8:1::/64 وجود دارد که از طریق رله‌ای با نشانی IPv6 معادل 3000::1 در دسترس است. سرور قادر است این زیرشبکه را برای هر بسته ورودی که از سوی رله‌ای با نشانی موجود در زیرشبکه 2001:db8:1::/64 می‌آید، انتخاب کند. همچنین آن زیرشبکه را برای رله‌ای با نشانی 3000::1 انتخاب می‌نماید. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::1\-2001:db8:1::ffff\(dq } ], \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq3000::1\(dq ] } } ] } .EE .UNINDENT .UNINDENT .sp اگر \fBrelay\fP مشخص شده باشد، پارامتر \fBip\-addresses\fP در داخل آن الزامی است. پارامتر \fBip\-addresses\fP از مشخص کردن فهرستی از نشانی‌ها پشتیبانی می‌کند..SS "جداسازی کلاینت‌های IPv6 در یک شبکه کابلی (Segregating IPv6 Clients in a Cable Network)" .sp در برخی موارد، ترکیب اطلاعات آدرس رله (معرفی‌شده در «Using a Specific Relay Agent for a Subnet») با طبقه‌بندی کلاینت (توضیح‌داده‌شده در «Client Classification» \%<#\:classify>) مفید است. یک نمونه خاص، شبکه‌های کابلی است که در آن‌ها مودم‌ها معمولاً آدرس‌هایی از یک زیرشبکه متفاوت نسبت به تمام دستگاه‌های متصل در پشت خود دریافت می‌کنند. .sp فرض کنیم یک Cable Modem Termination System (CMTS) با یک CM MAC (یک پیوند فیزیکی که مودم‌ها به آن متصل هستند) وجود دارد. ما می‌خواهیم مودم‌ها آدرس‌هایی از زیرشبکه 3000::/64 دریافت کنند، در حالی که تمام دستگاه‌های متصل در پشت مودم‌ها باید آدرس‌هایی از زیرشبکه 2001:db8:1::/64 دریافت کنند. CMTS که به عنوان رله عمل می‌کند از آدرس 3000::1 استفاده می‌کند. پیکربندی زیر می‌تواند پاسخگوی این وضعیت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq3000::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq3000::2 \- 3000::ffff\(dq } ], \(dqclient\-classes\(dq: [ \(dqVENDOR_CLASS_docsis3.0\(dq ], \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq3000::1\(dq ] } }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::1\-2001:db8:1::ffff\(dq } ], \(dqrelay\(dq: { \(dqip\-addresses\(dq: [ \(dq3000::1\(dq ] } } ] } .EE .UNINDENT .UNINDENT .SS "آدرس‌های سخت‌افزاری/MAC در DHCPv6 (MAC/Hardware Addresses in DHCPv6)" .sp آدرس‌های سخت‌افزاری/MAC در پیام‌های DHCPv4 ارسالی از سوی کلاینت‌ها در دسترس هستند و مدیران سیستم معمولاً از این اطلاعات برای انجام وظایف خاصی مانند پیکربندی به ازای هر میزبان (per\-host configuration) و رزرو آدرس برای آدرس‌های MAC مشخص استفاده می‌کنند. متأسفانه، پروتکل DHCPv6 هیچ راهکار کاملاً قابل اعتمادی برای بازیابی این اطلاعات ارائه نمی‌دهد. برای کاهش این مشکل، سازوکارهای متعددی در Kea پیاده‌سازی شده است. هر یک از این سازوکارها در موارد خاصی کار می‌کنند، اما ممکن است در شرایط دیگر کارایی نداشته باشند. کارکردن این سازوکار در یک استقرار مشخص، تا حدودی به توپولوژی شبکه و فناوری‌های مورد استفاده بستگی دارد. .sp نرم‌افزار Kea امکان تعیین این موضوع را فراهم می‌کند که کدام‌یک از روش‌های پشتیبانی‌شده و با چه ترتیبی، از طریق پارامتر \fBmac\-sources\fP استفاده شوند. این پیکربندی را می‌توان نوعی تنظیم دقیق (fine tuning) برای استقرار DHCP به شمار آورد. .sp در اینجا یک مثال آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqmac\-sources\(dq: [ \(dqmethod1\(dq, \(dqmethod2\(dq, \(dqmethod3\(dq, ... ], \(dqsubnet6\(dq: [ { ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp در صورت عدم تعیین، مقدار \(dqany\(dq استفاده می‌شود که به سرور دستور می‌دهد تمام روش‌ها را به ترتیب امتحان کرده و از مقدار بازگردانده‌شده توسط اولین روشی که موفق می‌شود استفاده کند. در یک استقرار معمولی، مقدار پیش‌فرض \(dqany\(dq کافی است و نیازی به انتخاب روش‌های خاص نیست. تغییر مقدار این پارامتر بیشتر در مواردی مفید است که مدیر سیستم بخواهد روش‌های خاصی را غیرفعال کند؛ به عنوان مثال، اگر مدیر سیستم به زیرساخت شبکه بیشتر از اطلاعات ارائه‌شده توسط خود کلاینت‌ها اعتماد داشته باشد، ممکن است اطلاعات ارائه‌شده توسط رله‌ها را به اطلاعات ارائه‌شده توسط کلاینت‌ها ترجیح دهد. .sp در صورت مشخص شدن، \fBmac\-sources\fP باید حداقل دارای یک مقدار باشد. .sp روش‌های پشتیبانی‌شده عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBany\fP \- این یک روش واقعی نیست، بلکه صرفاً کلمه‌ای کلیدی است که به Kea دستور می‌دهد تمام روش‌های دیگر را امتحان کرده و از نخستین روشی که موفق می‌شود استفاده کند. اگر هیچ \fBmac\-sources\fP تعریف نشده باشد، این رفتار پیش‌فرض است. .IP \(bu 2 \fBraw\fP \- در اصل، یک سرور DHCPv6 می‌تواند از سوکت‌های خام (raw sockets) برای دریافت ترافیک ورودی و استخراج اطلاعات آدرس سخت‌افزاری/MAC استفاده کند. این قابلیت در حال حاضر برای DHCPv6 پیاده‌سازی نشده است و این مقدار هیچ اثری ندارد. .IP \(bu 2 \fBduid\fP \- پروتکل DHCPv6 به جای آدرس‌های MAC از شناساگرهای DUID استفاده می‌کند. در حال حاضر چهار نوع DUID تعریف شده است و دو مورد از آن‌ها (DUID\-LLT که پیش‌فرض است، و DUID\-LL) اطلاعات آدرس MAC را منتقل می‌کنند. گرچه RFC 9915 \% آن را منع کرده است، اما تجزیه این DUIDها و استخراج اطلاعات لازم از آن‌ها امکان‌پذیر است. این روش کاملاً قابل اعتماد نیست، زیرا کلاینت‌ها ممکن است از انواع دیگر DUID، یعنی DUID\-EN یا DUID\-UUID استفاده کنند. .IP \(bu 2 \fBipv6\-link\-local\fP \- روش ممکن دیگر برای کسب اطلاعات از آدرس IPv6 مبدأ به دست می‌آید. در استفاده معمول، کلاینت‌ها بسته‌های خود را از آدرس‌های محلی پیوند (link\-local) پروتکل IPv6 ارسال می‌کنند. احتمال زیادی وجود دارد که این آدرس‌ها بر پایه EUI\-64 باشند که شامل آدرس MAC است. این روش کاملاً قابل اعتماد نیست، چرا که ممکن است کلاینت‌ها از انواع دیگر آدرس‌های link\-local استفاده کنند. به‌ویژه، افزونه‌های حریم خصوصی (privacy extensions) تعریف‌شده در RFC 4941 \% از آدرس‌های MAC استفاده نمی‌کنند. همچنین توجه داشته باشید که استخراج موفقیت‌آمیز مستلزم آن است که بیت u آدرس روی \(dq1\(dq و بیت g آن روی \(dq0\(dq تنظیم شده باشد که نشان‌دهنده شناسه رابط (interface identifier) مطابق با بخش 2.5.1 از RFC 2373 \%\& است. .IP \(bu 2 \fBclient\-link\-addr\-option\fP \- یکی از افزونه‌های تعریف‌شده برای کاهش مشکلات نبود MAC، گزینه آدرس لایه پیوند کلاینت (client link\-layer address option) است که در RFC 6939 \%\& تعریف شده است. این گزینه‌ای است که توسط یک رله درج می‌شود و حاوی اطلاعاتی پیرامون آدرس MAC کلاینت است. این روش نیازمند یک عامل رله است که از این گزینه پشتیبانی کند و برای درج آن پیکربندی شده باشد. این روش برای کلاینت‌هایی که اتصال مستقیم دارند بی‌فایده است. مقدار \fBrfc6939\fP یک نام مستعار برای \fBclient\-link\-addr\-option\fP است\&. .IP \(bu 2 \fBremote\-id\fP \- سند RFC 4649 \% گزینه \fBremote\-id\fP را تعریف می‌کند که توسط یک عامل رله درج می‌شود. بسته به پیکربندی عامل رله، گزینه درج‌شده ممکن است حاوی اطلاعات آدرس MAC کلاینت باشد. مقدار \fBrfc4649\fP یک نام مستعار برای \fBremote\-id\fP است\&. .IP \(bu 2 \fBsubscriber\-id\fP \- تعریف‌شده در RFC 4580 \%، گزینه \fBsubscriber\-id\fP تا حدی مشابه \fBremote\-id\fP است؛ این گزینه نیز توسط یک عامل رله درج می‌شود. مقدار \fBrfc4580\fP یک نام مستعار برای \fBsubscriber\-id\fP است\&. این روش در حال حاضر پیاده‌سازی نشده است. .IP \(bu 2 \fBdocsis\-cmts\fP \- یکی دیگر از منابع احتمالی اطلاعات آدرس MAC، گزینه‌های DOCSIS درج‌شده توسط یک CMTS است که به عنوان عامل رله DHCPv6 در شبکه‌های کابلی عمل می‌کند. این روش تلاش می‌کند اطلاعات آدرس MAC را از زیرگزینه 1026 (cm mac) از گزینه خاص سازنده با \fBvendor\-id=4491\fP استخراج کند\&. این گزینه سازنده از پیام Relay\-forward استخراج می‌شود، نه از پیام اصلی کلاینت. .IP \(bu 2 \fBdocsis\-modem\fP \- آخرین منبع احتمالی اطلاعات آدرس MAC، گزینه‌های DOCSIS درج‌شده توسط خود مودم کابلی است. این روش تلاش می‌کند اطلاعات آدرس MAC را از زیرگزینه 36 (\fBdevice\-id\fP) از گزینه خاص سازنده با \fBvendor\-id=4491\fP استخراج کند\&. این گزینه سازنده از پیام اصلی کلاینت استخراج می‌شود، نه از گزینه‌های رله. .UNINDENT .sp یک پارامتر \fBmac\-sources\fP خالی مجاز نیست. مدیرانی که تمایلی به تعیین آن ندارند، باید یا تعریف \fBmac\-sources\fP را کاملاً حذف کنند یا آن را با مقدار \(dqany\(dq که حالت پیش‌فرض است مشخص نمایند..SS نشانی‌های تکراری (پشتیبانی از DHCPDECLINE) .sp کارساز DHCPv6 با استخر مشخصی از نشانی‌ها پیکربندی می‌شود که انتظار می‌رود آن‌ها را به کلاینت‌های DHCPv6 واگذار کند. فرض بر این است که کارساز معتبر (authoritative) بوده و اختیار تام بر روی آن نشانی‌ها دارد. با این حال، به دلایل مختلفی مانند پیکربندی نادرست یا پیاده‌سازی معیوب یک کلاینت که نشانی خود را فراتر از طول‌عمر معتبر (valid lifetime) حفظ می‌کند، ممکن است دستگاه‌های متصلی وجود داشته باشند که از آن نشانی‌ها بدون تایید یا آگاهی کارساز استفاده کنند. .sp چنین رویداد نامطلوبی می‌تواند توسط کلاینت‌های مجاز (با استفاده از Duplicate Address Detection) تشخیص داده شده و با استفاده از یک پیام DHCPDECLINE به کارساز DHCPv6 گزارش شود. کارساز یک بررسی صحت (sanity check) انجام می‌دهد (تا ببیند آیا کلاینتی که نشانی را رد می‌کند، واقعاً قرار بوده از آن استفاده کند یا خیر)، سپس یک عملیات پاک‌سازی انجام داده و با ارسال مجدد پیام REPLY، پیام DHCPDECLINE را تایید می‌کند. هرگونه مدخل DNS مربوط به آن نشانی حذف می‌شود، رویداد لاگ می‌شود و قلاب‌ها (hooks) فعال می‌گردند. پس از تکمیل این روند، نشانی به عنوان ردشده (declined) علامت‌گذاری می‌شود (که نشان می‌دهد توسط یک موجودیت ناشناس استفاده شده و در نتیجه برای تخصیص در دسترس نیست) و یک زمان تعلیق (probation time) روی آن تنظیم می‌شود. مگر اینکه به شکل دیگری پیکربندی شده باشد، دوره تعلیق ۲۴ ساعت طول می‌کشد؛ پس از آن زمان، کارساز اجاره (lease) را بازیابی می‌کند (یعنی آن را دوباره به وضعیت در دسترس بازمی‌گرداند) و نشانی دوباره برای تخصیص در دسترس خواهد بود. لازم به ذکر است که اگر مشکل اساسی دستگاه دارای پیکربندی نادرست برطرف نشود، سناریوی نشانی تکراری مجدداً تکرار خواهد شد. در صورت پیکربندی صحیح، این سازوکار فرصتی را برای بهبود و بازیابی خودکار از چنین رویدادی، بدون هیچ‌گونه دخالت مدیر سیستم، فراهم می‌کند. .sp برای پیکربندی دوره تعلیق رد نشانی با مقداری غیر از مقدار پیش‌فرض، می‌توان از نحو (syntax) زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqdecline\-probation\-period\(dq: 3600, \(dqsubnet6\(dq: [ { ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp این پارامتر بر حسب ثانیه بیان می‌شود، بنابراین مثال بالا به کارساز دستور می‌دهد تا اجاره‌های ردشده را پس از یک ساعت بازیافت کند. .sp چندین آمار و نقطه قلاب (hook point) مربوط به رویه رسیدگی به رد نشانی وجود دارد. نقطه قلاب \fBlease6_decline\fP پس از اینکه پیام ورودی DHCPDECLINE بررسی صحت شد و کارساز در شرف رد کردن اجاره است، فعال می‌شود. آمار \fBdeclined\-addresses\fP پس از بازگشت قلاب افزایش می‌یابد (هم نسخه سراسری و هم نسخه ویژه زیرشبکه). (برای جزئیات بیشتر درباره آمارهای DHCPv6 و نقاط قلاب Kea، بخش Statistics in the DHCPv6 Server and Hook Libraries \%<#\:hooks-libraries> را ببینید.) .sp به‌محض پایان زمان تعلیق، اجاره ردشده با استفاده از رویه استاندارد بازپس‌گیری اجاره‌های منقضی‌شده، همراه با چند مرحله اضافی بازیابی می‌شود. به‌ویژه، هر دو آمار \fBdeclined\-addresses\fP (سراسری و ویژه زیرشبکه) کاهش می‌یابند. در همان زمان، آمارهای \fBreclaimed\-declined\-addresses\fP (باز هم در دو گونه سراسری و ویژه زیرشبکه) افزایش می‌یابند. .sp نکته‌ای درباره آمارها: کارساز Kea هنگام دریافت و پردازش موفقیت‌آمیز پیام DHCPDECLINE، آمار \fBassigned\-nas\fP را کاهش نمی‌دهد. اگرچه از نظر فنی یک نشانی ردشده دیگر تخصیص‌یافته نیست، کاربرد اصلی آمار \fBassigned\-nas\fP پایش میزان بهره‌وری از استخر است. اکثر افراد فراموش می‌کنند که \fBdeclined\-addresses\fP را در محاسبه بگنجانند و صرفاً از \fBassigned\-nas\fP/\fBtotal\-nas\fP\& استفاده می‌کنند. این امر باعث ایجاد سوگیری در جهت کمتر نشان دادن استفاده از استخر می‌شود. از آنجا که این موضوع پتانسیل ایجاد سردرگمی جدی دارد، ISC تصمیم گرفت که بلافاصله پس از دریافت DHCPDECLINE مقدار \fBassigned\-nas\fP را کاهش ندهد، بلکه این کار را بعداً هنگامی که Kea نشانی را به استخر در دسترس بازمی‌گرداند انجام دهد. .SS ثبت نشانی (پشتیبانی از RFC 9686) .sp نسخه 2.7.7 کارساز Kea پشتیبانی از ثبت نشانی خودتولید (self\-generated) را همان‌طور که در RFC 9686 \% تعریف شده معرفی می‌کند؛ یعنی هنگامی که یک پیام معتبر ADDR\-REG\-INFORM (36) دریافت می‌شود، یک اجاره ثبت‌شده افزوده یا به‌روزرسانی شده و یک ADDR\-REG\-REPLY (37) به کلاینت بازگردانده می‌شود. .sp از نسخه 3.1.4 کارساز Kea، این ویژگی می‌تواند با تنظیم پارامتر \fBallow\-address\-registration\fP به ترتیب روی true یا false، به‌صورت سراسری فعال یا غیرفعال شود. این ویژگی به‌طور پیش‌فرض فعال است. .sp سند RFC 9686 \% از کارسازهایی که از ثبت نشانی پشتیبانی می‌کنند می‌خواهد که در صورت درخواست کلاینت‌ها از طریق گزینه ORO، گزینه 148 را به آن‌ها بازگردانند. مانند هر گزینه استاندارد دیگری، این گزینه نیز باید در پیکربندی کارساز مشخص شود تا به کلاینت‌ها ارسال گردد و این رفتار مستقل از \fBallow\-address\-registration\fP\& است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 حتی اگر آن‌ها پایگاه‌داده اجاره مشترکی با اجاره‌ها در وضعیت‌های دیگر داشته باشند، اجاره‌های ثبت‌شده مستقل هستند: هنگامی که یک اجاره در وضعیتی دیگر از قبل برای یک نشانی وجود دارد، این نشانی در حال استفاده تلقی شده و نمی‌تواند ثبت شود. به‌طور مشابه، یک اجاره ثبت‌شده نمی‌تواند به وضعیت دیگری تغییر یابد؛ برای مثال، بازپس‌گیری اجاره‌های ثبت‌شده منقضی، آن‌ها را حذف می‌کند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کارساز Kea گزینه Option Request را در پیام ADDR\-REG\-INFORM می‌پذیرد و پردازش می‌کند (سند RFC مشخص کرده است که کلاینت نباید چنین گزینه‌ای را در آن قرار دهد). .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کارساز Kea در حال حاضر فقط نشانی‌هایی را می‌پذیرد که \(dqمناسب پیوند\(dq (\(dqappropriate to the link\(dq) هستند، اما نشانی‌هایی را که \(dqدرون پیشوند واگذارشده به کلاینت\(dq (\(dqwithin a prefix delegated to the client\(dq) هستند هنوز نمی‌پذیرد، که این امر با شیوه توصیف توپولوژی در پیکربندی Kea سازگار نیست. .UNINDENT .UNINDENT.SS آمارها در کارساز DHCPv6 .sp کارساز DHCPv6 از آمارهای زیر پشتیبانی می‌کند: .SS آمارهای DHCPv6 .TS box center; l|l|l. T{ آماره T} T{ نوع داده T} T{ توضیحات T} _ T{ pkt6\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های DHCPv6 دریافت‌شده. این مقدار شامل همهٔ بسته‌ها می‌شود: معتبر، جعلی، خراب، رد شده و غیره. انتظار می‌رود این آماره به سرعت رشد کند. T} _ T{ pkt6\-service\-disabled T} T{ عدد صحیح T} T{ تعداد بسته‌های ورودی که هنگام غیرفعال بودن سرویس DHCP دور ریخته شده‌اند. T} _ T{ pkt6\-parse\-failed T} T{ عدد صحیح T} T{ تعداد بسته‌های ورودی که قابل تجزیه نبودند. مقدار غیرصفر برای این آماره نشان می‌دهد که کارساز یک بستهٔ بدشکل یا ناقص دریافت کرده است. این وضعیت ممکن است نشان‌دهندهٔ مشکلاتی در شبکه، کلاینت‌های معیوب، رله‌های معیوب، یا نقصی در کارساز باشد. T} _ T{ pkt6\-queue\-full T} T{ عدد صحیح T} T{ تعداد بسته‌های ورودی که به دلیل پر بودن صف نگه‌داری، دور ریخته شده‌اند. T} _ T{ pkt6\-duplicate T} T{ عدد صحیح T} T{ تعداد بسته‌های ورودی که پس از تشخیص به عنوان تکراری، دور ریخته شده‌اند. T} _ T{ pkt6\-rfc\-violation T} T{ عدد صحیح T} T{ تعداد بسته‌های ورودی که به دلیل عدم تطابق با مشخصات پروتکل دور ریخته شده‌اند. T} _ T{ pkt6\-admin\-filtered T} T{ عدد صحیح T} T{ تعداد بسته‌های ورودی که بر اساس پیکربندی کارساز دور ریخته شده‌اند، برای نمونه با دسته‌بندی پرس‌وجو در کلاس \fBDROP\fP\&. T} _ T{ pkt6\-not\-for\-us T} T{ عدد صحیح T} T{ تعداد بسته‌های ورودی که دور ریخته شدند زیرا باید توسط کارساز دیگری پردازش می‌شدند. T} _ T{ pkt6\-processing\-failed T} T{ عدد صحیح T} T{ تعداد بسته‌های ورودی که به دلیل رخ دادن خطایی غیرمنتظره در حین پردازش، دور ریخته شدند. T} _ T{ pkt6\-limit\-exceeded T} T{ عدد صحیح T} T{ تعداد بسته‌های ورودی که توسط کتابخانهٔ قلاب \fBlimits\fP دور ریخته شده‌اند. T} _ T{ pkt6\-receive\-drop T} T{ عدد صحیح T} T{ تعداد بسته‌های ورودی که دور ریخته شده‌اند. علت دقیق دور ریختن بسته‌ها ثبت می‌شود، اما شایع‌ترین دلایل ممکن است دریافت نوع بستهٔ غیرقابل‌قبول یا پشتیبانی‌نشده، ممنوع بودن پاسخ‌های مستقیم، عدم تطابق شناسهٔ کارساز ارسال‌شده توسط کلاینت با شناسهٔ کارساز، بدشکل بودن بسته، یا رخ دادن خطایی غیرمنتظره در حین پردازش باشد. T} _ T{ pkt6\-solicit\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های SOLICIT دریافت‌شده. انتظار می‌رود این آماره افزایش یابد؛ رشد آن یعنی کلاینت‌هایی که تازه راه‌اندازی شده‌اند فرآیند پیکربندی خود را آغاز کرده و بسته‌های اولیهٔ آن‌ها به کارساز Kea رسیده است. T} _ T{ pkt6\-advertise\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های ADVERTISE دریافت‌شده. بسته‌های ADVERTISE توسط کارساز ارسال می‌شوند و هرگز انتظار نمی‌رود کارساز آن‌ها را دریافت کند؛ مقدار غیرصفر برای این آماره نشان‌دهندهٔ خطایی در شبکه است. یک دلیل محتمل می‌تواند یک عامل رلهٔ نادرست باشد که پیام‌های ADVERTISE را به جای بازگرداندن به کلاینت‌ها، به اشتباه به سمت کارساز بازپخش می‌کند. T} _ T{ pkt6\-request\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های DHCPREQUEST دریافت‌شده. انتظار می‌رود این آماره رشد کند. افزایش آن بدین معنی است که کلاینت‌های تازه راه‌اندازی‌شده پاسخ کارساز (DHCPADVERTISE) را دریافت و قبول کرده‌اند، و اکنون در حال درخواست یک نشانی (DHCPREQUEST) هستند. T} _ T{ pkt6\-reply\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های REPLY دریافت‌شده. انتظار می‌رود این آماره همواره صفر بماند، زیرا بسته‌های REPLY توسط کارساز ارسال می‌شوند و هرگز نباید دریافت شوند. مقدار غیرصفر نشان‌دهندهٔ خطا است. یک علت محتمل می‌تواند یک عامل رلهٔ نادرست باشد که پیام‌های REPLY را به جای کلاینت‌ها، به اشتباه به سمت کارساز بازپخش می‌کند. T} _ T{ pkt6\-renew\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های RENEW دریافت‌شده. انتظار می‌رود این آماره افزایش یابد؛ رشد آن بدین معنا است که کلاینت‌ها نشانی‌ها و پیشوندهای خود را دریافت کرده و در تلاش برای تمدید آن‌ها هستند. T} _ T{ pkt6\-rebind\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های REBIND دریافت‌شده. مقدار غیرصفر نشان می‌دهد کلاینت‌ها پاسخی برای پیام‌های RENEW خود (از طریق سازوکار عادی تمدید اجاره) دریافت نکرده‌اند و در تلاشند هر کارسازی را که بتواند اجاره‌های آن‌ها را به عهده بگیرد، بیابند. این وضعیت ممکن است به این معنی باشد که پیام‌های REPLY برخی کارسازها هرگز به کلاینت‌ها نرسیده است. T} _ T{ pkt6\-release\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های RELEASE دریافت‌شده. انتظار می‌رود هنگام خاموش شدن یک دستگاه در شبکه، این آماره رشد کند؛ این آماره نشان می‌دهد که نشانی یا پیشوند واگذارشده دیگر مورد نیاز نیست. توجه داشته باشید که بسیاری از دستگاه‌ها، به‌ویژه دستگاه‌های بی‌سیم، چه به دلیل طراحی و چه به دلیل خارج شدن کلاینت از محدوده، بستهٔ RELEASE ارسال نمی‌کنند. T} _ T{ pkt6\-decline\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های DECLINE دریافت‌شده. انتظار می‌رود این آماره نزدیک به صفر بماند. افزایش آن نشان می‌دهد کلاینتی یک نشانی را اجاره کرده، اما متوجه شده که نشانی هم‌اکنون توسط دستگاهی ناشناخته در شبکه در حال استفاده است. اگر این آماره در حال رشد باشد، ممکن است نشان‌دهندهٔ کارساز با پیکربندی نادرست یا وجود دستگاه‌هایی با نشانی‌های ایستای متداخل باشد. T} _ T{ pkt6\-infrequest\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های INFORMATION\-REQUEST دریافت‌شده. انتظار می‌رود در صورت وجود دستگاه‌هایی که از DHCPv6 بدون‌حالت استفاده می‌کنند، این آماره افزایش یابد. پیام‌های INFORMATION\-REQUEST توسط کلاینت‌هایی استفاده می‌شود که پیکربندی بدون‌حالت، یعنی گزینه‌ها و پارامترهایی غیر از نشانی‌ها یا پیشوندها را درخواست می‌کنند. T} _ T{ pkt6\-lease\-query\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های LEASEQUERY دریافت‌شده توسط کتابخانهٔ قلاب leasequery. انتظار می‌رود این آماره افزایش یابد. T} _ T{ pkt6\-dhcpv4\-query\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های DHCPv4\-QUERY دریافت‌شده. انتظار می‌رود در صورت وجود دستگاه‌هایی که از DHCPv4\-over\-DHCPv6 استفاده می‌کنند، این آماره رشد کند. پیام‌های DHCPv4\-QUERY توسط کلاینت‌های DHCPv4 روی یک خط فقط\-IPv6 استفاده می‌شود که درخواست‌ها را روی DHCPv6 کپسوله‌سازی می‌کند. T} _ T{ pkt6\-dhcpv4\-response\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های DHCPv4\-RESPONSE دریافت‌شده. انتظار می‌رود این آماره همیشه صفر بماند، زیرا بسته‌های DHCPv4\-RESPONSE توسط کارساز ارسال می‌شوند و انتظار نمی‌رود کارساز هرگز آن‌ها را دریافت کند. مقدار غیرصفر نشان‌دهندهٔ خطا است. یک دلیل محتمل می‌تواند یک عامل رلهٔ نادرست باشد که پیام DHCPv4\-RESPONSE را به جای کلاینت‌ها، به اشتباه به سمت کارساز بازپخش می‌کند. T} _ T{ pkt6\-addr\-reg\-inform\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های ADDR\-REG\-INFORM دریافت‌شده. انتظار می‌رود در صورت وجود دستگاه‌هایی که از ثبت نشانی استفاده می‌کنند، این آماره رشد کند. T} _ T{ pkt6\-addr\-reg\-reply\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های ADDR\-REG\-REPLY دریافت‌شده. انتظار می‌رود این آماره همیشه صفر بماند، زیرا بسته‌های ADDR\-REG\-REPLY توسط کارساز ارسال می‌شوند و کارساز هرگز نباید آن‌ها را دریافت کند. مقدار غیرصفر نشان‌دهندهٔ خطا است. یک دلیل محتمل می‌تواند عامل رله‌ای باشد که به اشتباه پیام ADDR\-REG\-REPLY را به سمت کارساز بازپخش می‌کند. T} _ T{ pkt6\-unknown\-received T} T{ عدد صحیح T} T{ تعداد بسته‌های دریافت‌شده با نوع ناشناخته. مقدار غیرصفر برای این آماره نشان می‌دهد کارساز بسته‌ای را دریافت کرده که قادر به شناسایی آن نبوده است؛ یا نوع آن پشتیبانی‌نشده بوده یا احتمالاً مخدوش بوده است. T} _ T{ pkt6\-sent T} T{ عدد صحیح T} T{ تعداد بسته‌های DHCPv6 ارسال‌شده. انتظار می‌رود با هر بار ارسال بسته توسط کارساز، این آماره رشد کند. به طور کلی، این مقدار باید تقریباً با \fBpkt6\-received\fP همخوانی داشته باشد، زیرا بیشتر بسته‌های ورودی باعث پاسخ دادن کارساز می‌شوند. استثناهایی وجود دارد (مانند دریافت یک REQUEST با شناسهٔ کارساز متعلق به کارسازی دیگر)، بنابراین اگر از \fBpkt6\-received\fP کمتر بود جای نگرانی نیست. T} _ T{ pkt6\-advertise\-sent T} T{ عدد صحیح T} T{ تعداد بسته‌های ADVERTISE ارسال‌شده. انتظار می‌رود در بیشتر موارد پس از پردازش یک SOLICIT، این آماره افزایش یابد. موارد نامعمول اما معتبری وجود دارد که در آن‌ها بسته‌های SOLICIT ورودی دور ریخته می‌شوند، اما در کل انتظار می‌رود این آماره به \fBpkt6\-solicit\-received\fP نزدیک باشد. T} _ T{ pkt6\-reply\-sent T} T{ عدد صحیح T} T{ تعداد بسته‌های REPLY ارسال‌شده. انتظار می‌رود در بیشتر موارد پس از پردازش SOLICIT (با rapid\-commit)،‏ REQUEST،‏ RENEW،‏ REBIND،‏ RELEASE،‏ DECLINE، یا INFORMATION\-REQUEST این آماره رشد کند. در موارد خاصی پاسخی ارسال نمی‌شود. T} _ T{ pkt6\-lease\-query\-reply\-sent T} T{ عدد صحیح T} T{ تعداد بسته‌های LEASEQUERY\-REPLY ارسال‌شده توسط کتابخانهٔ قلاب leasequery. انتظار می‌رود این آماره افزایش یابد. T} _ T{ pkt6\-dhcpv4\-response\-sent T} T{ عدد صحیح T} T{ تعداد بسته‌های DHCPv4\-RESPONSE ارسال‌شده. انتظار می‌رود در بیشتر موارد پس از پردازش یک DHCPv4\-QUERY این آماره افزایش یابد. در موارد خاصی پاسخی ارسال نمی‌شود. T} _ T{ pkt6\-addr\-reg\-reply\-sent T} T{ عدد صحیح T} T{ تعداد بسته‌های ADDR\-REG\-REPLY ارسال‌شده. انتظار می‌رود در بیشتر موارد پس از پردازش یک ADDR\-REG\-INFORM این آماره رشد کند. در موارد خاصی پاسخی ارسال نمی‌شود. T} _ T{ subnet[id].total\-nas T} T{ عدد صحیح بزرگ T} T{ تعداد کل نشانی‌های NA موجود برای مدیریت DHCPv6 در یک زیرشبکهٔ مشخص؛ به عبارت دیگر، این مقدار شمارش همهٔ نشانی‌ها در تمامی استخرهای پیکربندی‌شده است. این آماره فقط در طول تغییرات پیکربندی تغییر می‌کند. این مقدار نشانی‌هایی را که ممکن است به دلیل رزرو میزبان رزرو شده باشند شامل نمی‌شود. شناسهٔ \fIid\fP شناسهٔ زیرشبکهٔ مربوطه است. این آماره برای هر زیرشبکه به طور جداگانه ارائه می‌شود، و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].pool[pid].total\-nas T} T{ عدد صحیح بزرگ T} T{ تعداد کل نشانی‌های NA موجود برای مدیریت DHCPv6 در یک استخر زیرشبکهٔ مشخص؛ به بیان دیگر، این تعداد همهٔ نشانی‌های موجود در استخر زیرشبکهٔ پیکربندی‌شده است. این آماره فقط در طول تغییرات پیکربندی تغییر می‌کند. نشانی‌هایی که به دلیل رزرو میزبان رزرو شده باشند به حساب نمی‌آیند. شناسهٔ \fIid\fP شناسهٔ زیرشبکه و \fIpid\fP شناسهٔ استخر مربوطه است. این آماره برای هر استخر زیرشبکه به طور جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌شود. T} _ T{ assigned\-nas T} T{ عدد صحیح T} T{ تعداد نشانی‌های NA که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد، و در حین رویداد پیکربندی مجدد بازنشانی می‌شود. T} _ T{ cumulative\-assigned\-nas T} T{ عدد صحیح T} T{ تعداد تجمعی نشانی‌های NA که از زمان راه‌اندازی کارساز واگذار شده‌اند. این آماره با هر بار واگذاری نشانی NA افزایش می‌یابد و هنگام پیکربندی مجدد کارساز بازنشانی نمی‌شود. T} _ T{ subnet[id].cumulative\-assigned\-nas T} T{ عدد صحیح T} T{ تعداد تجمعی نشانی‌های NA در یک زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و هرگز کاهش نمی‌یابد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه به طور جداگانه ارائه می‌شود، و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].pool[pid].cumulative\-assigned\-nas T} T{ عدد صحیح T} T{ تعداد تجمعی نشانی‌های NA در یک استخر زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و هرگز کاهش پیدا نمی‌کند. شناسهٔ \fIid\fP شناسهٔ زیرشبکه و \fIpid\fP شناسهٔ استخر مربوطه است. این آماره برای هر استخر زیرشبکه جداگانه ارائه می‌شود و در رویداد پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].assigned\-nas T} T{ عدد صحیح T} T{ تعداد نشانی‌های NA در یک زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود و در حین پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].pool[pid].assigned\-nas T} T{ عدد صحیح T} T{ تعداد نشانی‌های NA در یک استخر زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه و \fIpid\fP شناسهٔ استخر است. این آماره برای هر استخر زیرشبکه جداگانه ارائه شده و در حین پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].total\-pds T} T{ عدد صحیح بزرگ T} T{ تعداد کل پیشوندهای PD موجود برای مدیریت DHCPv6 در یک زیرشبکهٔ مشخص؛ به عبارت دیگر، این مقدار شمارش همهٔ پیشوندها در تمامی استخرهای پیکربندی‌شده است. این آماره فقط در طول تغییرات پیکربندی تغییر می‌کند. توجه داشته باشید که هیچ‌یک از پیشوندهایی که ممکن است به دلیل رزرو میزبان رزرو شده باشند به حساب نمی‌آیند. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].pd\-pool[pid].total\-pds T} T{ عدد صحیح بزرگ T} T{ تعداد کل پیشوندهای PD موجود برای مدیریت DHCPv6 در یک استخر زیرشبکهٔ مشخص؛ به عبارت دیگر، این تعداد کل پیشوندها در یک استخر PD زیرشبکهٔ پیکربندی‌شده است. این آماره فقط در حین تغییرات پیکربندی تغییر می‌کند. این مقدار پیشوندهای رزروشده به دلیل رزرو میزبان را شامل نمی‌شود. شناسهٔ \fIid\fP شناسهٔ زیرشبکه و \fIpid\fP شناسهٔ استخر مشخص است. این آماره برای هر استخر PD زیرشبکه جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌شود. T} _ T{ assigned\-pds T} T{ عدد صحیح T} T{ تعداد پیشوندهای PD که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد، و در حین رویداد پیکربندی مجدد بازنشانی می‌شود. T} _ T{ cumulative\-assigned\-pds T} T{ عدد صحیح T} T{ تعداد تجمعی پیشوندهای PD که از زمان راه‌اندازی کارساز واگذار شده‌اند. این مقدار با هر بار واگذاری پیشوند PD افزایش می‌یابد و هنگام پیکربندی مجدد کارساز بازنشانی نمی‌شود. T} _ T{ subnet[id].cumulative\-assigned\-pds T} T{ عدد صحیح T} T{ تعداد تجمعی پیشوندهای PD در یک زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و هرگز کاهش نمی‌یابد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود و در حین پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].pd\-pool[pid].cumulative\-assigned\-pds T} T{ عدد صحیح T} T{ تعداد تجمعی پیشوندهای PD در یک استخر PD زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش می‌یابد و هرگز کاهش نمی‌یابد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه و \fIpid\fP شناسهٔ استخر PD مربوطه است. این آماره برای هر استخر PD زیرشبکه جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].assigned\-pds T} T{ عدد صحیح T} T{ تعداد پیشوندهای PD در یک زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه شده و در حین پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].pd\-pool[pid].assigned\-pds T} T{ عدد صحیح T} T{ تعداد پیشوندهای PD در یک pd\-pool زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه و \fIpid\fP شناسهٔ استخر PD است. این آماره برای هر استخر PD زیرشبکه جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌شود. T} _ T{ reclaimed\-leases T} T{ عدد صحیح T} T{ تعداد اجاره‌های منقضی‌شده‌ای که از زمان راه‌اندازی کارساز بازپس‌گیری شده‌اند. این آماره با هر بار بازپس‌گیری یک اجارهٔ منقضی‌شده افزایش می‌یابد (هر دو بازپس‌گیری NA و PD را شامل می‌شود). این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان یک شاخص بلندمدت برای تعداد کل اجاره‌های واقعی بازپس‌گرفته‌شده استفاده کرد. این یک آمارهٔ سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].reclaimed\-leases T} T{ عدد صحیح T} T{ تعداد اجاره‌های منقضی‌شدهٔ وابسته به یک زیرشبکهٔ مشخص که از زمان راه‌اندازی کارساز بازپس‌گیری شده‌اند. این آماره با هر بار بازپس‌گیری یک اجارهٔ منقضی‌شده افزایش می‌یابد (شامل هر دو بازپس‌گیری NA و PD). شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود. T} _ T{ subnet[id].pool[pid].reclaimed\-leases T} T{ عدد صحیح T} T{ تعداد نشانی‌های NA منقضی‌شدهٔ وابسته به یک استخر زیرشبکهٔ مشخص که از زمان راه‌اندازی کارساز بازپس‌گیری شده‌اند. این آماره با هر بار بازپس‌گیری اجارهٔ منقضی‌شده افزایش می‌یابد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه و \fIpid\fP شناسهٔ استخر است. این آماره برای هر استخر زیرشبکه جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].pd\-pool[pid].reclaimed\-leases T} T{ عدد صحیح T} T{ تعداد پیشوندهای PD منقضی‌شدهٔ وابسته به یک استخر PD زیرشبکهٔ مشخص که از زمان راه‌اندازی کارساز بازپس‌گیری شده‌اند. این آماره با هر بار بازپس‌گیری اجارهٔ منقضی‌شده افزایش می‌یابد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه و \fIpid\fP شناسهٔ استخر PD است. این آماره برای هر استخر PD زیرشبکه جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ declined\-addresses T} T{ عدد صحیح T} T{ تعداد نشانی‌های IPv6 که هم‌اکنون رد شده‌اند (declined)؛ شمارشی از تعداد اجاره‌هایی که در حال حاضر در دسترس نیستند. به محض بازیابی یک اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این مقدار غیرصفر بوده یا رو به افزایش باشد، مدیر شبکه باید بررسی کند که آیا دستگاه ناهنجاری در شبکه وجود دارد یا خیر. این یک آمارهٔ سراسری است که تمامی زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].declined\-addresses T} T{ عدد صحیح T} T{ تعداد نشانی‌های IPv6 که در حال حاضر در یک زیرشبکهٔ مشخص رد شده‌اند؛ شمارشی از تعداد اجاره‌هایی که فعلاً در دسترس نیستند. به محض بازیابی اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این مقدار غیرصفر باشد یا افزایش یابد، مدیر شبکه باید بررسی کند که آیا دستگاه ناهنجاری در شبکه وجود دارد یا خیر. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود. T} _ T{ subnet[id].pool[pid].declined\-addresses T} T{ عدد صحیح T} T{ تعداد نشانی‌های IPv6 که هم‌اکنون در یک استخر زیرشبکهٔ مشخص رد شده‌اند؛ شمارشی از تعداد اجاره‌هایی که فعلاً در دسترس نیستند. به محض بازیابی اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این مقدار غیرصفر بوده یا در حال افزایش باشد، مدیر شبکه باید وجود دستگاه ناهنجار در شبکه را بررسی کند. شناسهٔ \fIid\fP شناسهٔ زیرشبکه و \fIpid\fP شناسهٔ استخر است. این آماره برای هر استخر زیرشبکه به طور جداگانه ارائه می‌شود. T} _ T{ reclaimed\-declined\-addresses T} T{ عدد صحیح T} T{ تعداد نشانی‌های IPv6 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف \fBdeclined\-addresses\fP، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان یک شاخص بلندمدت برای تعداد کل ردشدگی‌های معتبری که پردازش و بازیابی شده‌اند استفاده کرد. این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].reclaimed\-declined\-addresses T} T{ عدد صحیح T} T{ تعداد نشانی‌های IPv6 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف \fBdeclined\-addresses\fP، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان شاخصی بلندمدت برای تعداد کل ردشدگی‌های معتبری که پردازش و بازیابی شده‌اند استفاده کرد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود. T} _ T{ subnet[id].pool[pid].reclaimed\-declined\-addresses T} T{ عدد صحیح T} T{ تعداد نشانی‌های IPv6 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف \fBdeclined\-addresses\fP، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان شاخصی بلندمدت برای تعداد ردشدگی‌های معتبری که پردازش و بازیابی شده‌اند استفاده کرد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه و \fIpid\fP شناسهٔ استخر است. این آماره برای هر استخر زیرشبکه جداگانه ارائه می‌گردد. T} _ T{ v6\-allocation\-fail T} T{ عدد صحیح T} T{ تعداد کل شکست‌ها در تخصیص نشانی برای یک کلاینت خاص. این شامل تعداد تلاش‌هایی برای تخصیص اجاره است که کارساز پیش از انصراف انجام داده است، در صورتی که قادر به استفاده از هیچ‌یک از استخرهای نشانی نبوده باشد. این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].v6\-allocation\-fail T} T{ عدد صحیح T} T{ تعداد کل شکست‌ها در تخصیص نشانی برای یک کلاینت خاص. این شامل تعداد تلاش‌های تخصیص اجاره است که کارساز پیش از انصراف انجام داده است، در صورتی که نتوانسته باشد از هیچ‌یک از استخرهای نشانی استفاده کند. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود. T} _ T{ v6\-allocation\-fail\-shared\-network T} T{ عدد صحیح T} T{ تعداد شکست‌ها در تخصیص نشانی برای یک کلاینت خاص متصل به یک شبکهٔ اشتراکی (shared network). این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].v6\-allocation\-fail\-shared\-network T} T{ عدد صحیح T} T{ تعداد شکست‌ها در تخصیص نشانی برای یک کلاینت خاص متصل به یک شبکهٔ اشتراکی. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود. T} _ T{ v6\-allocation\-fail\-subnet T} T{ عدد صحیح T} T{ تعداد شکست‌های تخصیص نشانی برای یک کلاینت خاص متصل به زیرشبکه‌ای که به یک شبکهٔ اشتراکی تعلق ندارد. این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].v6\-allocation\-fail\-subnet T} T{ عدد صحیح T} T{ تعداد شکست‌های تخصیص نشانی برای یک کلاینت خاص متصل به زیرشبکه‌ای که به یک شبکهٔ اشتراکی تعلق ندارد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود. T} _ T{ v6\-allocation\-fail\-no\-pools T} T{ عدد صحیح T} T{ تعداد شکست‌های تخصیص نشانی به این دلیل که کارساز نتوانسته است از هیچ استخر پیکربندی‌شده‌ای برای یک کلاینت خاص استفاده کند. همچنین این احتمال وجود دارد که تمام زیرشبکه‌هایی که کارساز تلاش کرده از آن‌ها نشانی تخصیص دهد فاقد استخر نشانی باشند. در این وضعیت، چنانچه مدیر سیستم انتظار داشته باشد که به برخی کلاینت‌ها نشانی‌های پویا تخصیص یابد، این مورد باید یک پیکربندی نادرست تلقی شود. این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].v6\-allocation\-fail\-no\-pools T} T{ عدد صحیح T} T{ تعداد شکست‌های تخصیص نشانی به این دلیل که کارساز نتوانسته است از هیچ استخر پیکربندی‌شده‌ای برای یک کلاینت خاص استفاده کند. همچنین ممکن است همهٔ زیرشبکه‌هایی که کارساز سعی در تخصیص نشانی از آن‌ها داشته فاقد استخر نشانی باشند. در این صورت، اگر مدیر انتظار تخصیص نشانی پویا به کلاینت‌ها را داشته باشد، این یک پیکربندی نادرست است. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود. T} _ T{ v6\-allocation\-fail\-classes T} T{ عدد صحیح T} T{ تعداد شکست‌های تخصیص نشانی هنگامی که بستهٔ کلاینت به یک یا چند کلاس تعلق دارد. دلایل مختلفی برای عدم تخصیص اجاره وجود دارد: برای نمونه، اگر همهٔ استخرها نیازمند عضویت بسته‌ها در کلاس‌های خاصی باشند و بستهٔ ورودی به هیچ‌کدام تعلق نداشته باشد. حالت دیگر مفید بودن این اطلاعات، نشان دادن پایان یافتن نشانی‌های استخر رزروشده برای یک کلاس خاص است. این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد. T} _ T{ subnet[id].v6\-allocation\-fail\-classes T} T{ عدد صحیح T} T{ تعداد شکست‌های تخصیص نشانی هنگامی که بستهٔ کلاینت به یک یا چند کلاس تعلق دارد. دلایل مختلفی برای عدم تخصیص اجاره وجود دارد: برای نمونه، اگر همهٔ استخرها نیازمند عضویت بسته‌ها در کلاس‌های خاصی باشند و بستهٔ ورودی به هیچ‌کدام تعلق نداشته باشد. حالت دیگر مفید بودن این اطلاعات، نشان دادن اتمام نشانی‌های استخر رزروشده برای یک کلاس خاص است. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود. T} _ T{ v6\-ia\-na\-lease\-reuses T} T{ عدد صحیح T} T{ تعداد دفعاتی که به عنوان بخشی از قابلیت lease caching، مقدار CLTT یک اجارهٔ IA_NA در حافظه افزایش یافته و زمان انقضای آن در فضای ذخیره‌سازی پایدار دست‌نخورده باقی مانده است. به این فرآیند «استفادهٔ مجدد از اجاره» (lease reuse) گفته می‌شود. این یک آمارهٔ سراسری است. T} _ T{ subnet[id].v6\-ia\-na\-lease\-reuses T} T{ عدد صحیح T} T{ تعداد دفعاتی که به عنوان بخشی از قابلیت lease caching، مقدار CLTT یک اجارهٔ IA_NA در حافظه افزایش یافته و زمان انقضای آن در فضای ذخیره‌سازی پایدار دست‌نخورده باقی مانده است. به این فرآیند استفادهٔ مجدد از اجاره گفته می‌شود. این آماره به ازای هر زیرشبکه است. شناسهٔ \fIid\fP شناسهٔ زیرشبکهٔ مورد نظر است. T} _ T{ v6\-ia\-pd\-lease\-reuses T} T{ عدد صحیح T} T{ تعداد دفعاتی که به عنوان بخشی از قابلیت lease caching، مقدار CLTT یک اجارهٔ IA_PD در حافظه افزایش یافته و زمان انقضای آن در فضای ذخیره‌سازی پایدار بدون تغییر رها شده است. به این فرآیند استفادهٔ مجدد از اجاره گفته می‌شود. این یک آمارهٔ سراسری است. T} _ T{ subnet[id].v6\-ia\-pd\-lease\-reuses T} T{ عدد صحیح T} T{ تعداد دفعاتی که به عنوان بخشی از قابلیت lease caching، مقدار CLTT یک اجارهٔ IA_PD در حافظه افزایش یافته و زمان انقضای آن در فضای ذخیره‌سازی پایدار بدون تغییر رها شده است. به این فرآیند استفادهٔ مجدد از اجاره گفته می‌شود. این آماره به ازای هر زیرشبکه است. شناسهٔ \fIid\fP شناسهٔ زیرشبکهٔ مورد نظر است. T} _ T{ cumulative\-registered T} T{ عدد صحیح T} T{ تعداد تجمعی نشانی‌های NA که از زمان راه‌اندازی کارساز به ثبت رسیده‌اند. این آماره با هر بار ثبت یک نشانی NA افزایش یافته و هنگام پیکربندی مجدد کارساز بازنشانی نمی‌شود. T} _ T{ subnet[id].cumulative\-registered T} T{ عدد صحیح T} T{ تعداد تجمعی نشانی‌های NA در یک زیرشبکهٔ مشخص که به ثبت رسیده‌اند. این مقدار با هر بار ثبت یک نشانی جدید (در نتیجهٔ دریافت پیام ADDR\-REG\-INFORM) افزایش می‌یابد و هرگز کاهش پیدا نمی‌کند. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد. T} _ T{ subnet[id].registered T} T{ عدد صحیح T} T{ تعداد نشانی‌های NA در یک زیرشبکهٔ مشخص که به ثبت رسیده‌اند. این مقدار با هر بار ثبت یک نشانی جدید (در نتیجهٔ دریافت پیام ADDR\-REG\-INFORM) افزایش یافته و با هر بار انقضای یک ثبت کاهش می‌یابد. شناسهٔ \fIid\fP شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد. T} .TE .sp بسته‌های ورودی دور ریخته‌شده را می‌توان در \fBpkt6\-receive\-drop\fP و شمارندهٔ دومی که جزئیات دلیل دور انداختن را شرح می‌دهد، شمارش کرد: .INDENT 0.0.IP \(bu 2 \fBpkt6\-service\-disabled\fP \- سرویس DHCP غیرفعال است .IP \(bu 2 \fBpkt6\-parse\-failed\fP \- تجزیه بسته با یک خطای مهلک مواجه شد .IP \(bu 2 \fBpkt6\-queue\-full\fP \- بسته‌ای که قرار بود در صفی که پر بود نگهداری شود .IP \(bu 2 \fBpkt6\-duplicate\fP \- نسخه تکراری از بسته‌ای که در حال پردازش است .IP \(bu 2 \fBpkt6\-rfc\-violation\fP \- نقض RFC (یعنی مشخصات پروتکل دستور به دور انداختن آنها می‌دهد) .IP \(bu 2 \fBpkt6\-admin\-filtered\fP \- توسط مدیر سیستم فیلتر شده است .IP \(bu 2 \fBpkt6\-not\-for\-us\fP \- باید توسط سرور دیگری مدیریت شود .IP \(bu 2 \fBpkt6\-processing\-failed\fP \- هنگام پردازش با خطای غیرمنتظره‌ای مواجه شد .IP \(bu 2 \fBpkt6\-limit\-exceeded\fP \- توسط کتابخانه قلاب محدودیت‌ها (libdhcp_limits.so: Limits to Manage Lease Allocation and Packet Processing \%<#\:hooks-limits>) دور انداخته شد .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 شناسه استخر (pool ID) را می‌توان با تنظیم صریح پارامتر \fBpool\-id\fP در نگاشت پارامترهای استخر، روی هر استخر پیکربندی کرد. در صورت عدم پیکربندی، مقدار پیش‌فرض \fBpool\-id\fP برابر 0 خواهد بود. آمارهای مربوط به شناسه استخر 0 به تمام آمارهای همه استخرهایی اشاره دارد که \fBpool\-id\fP آنها پیکربندی نشده است\&. شناسه استخر نیازی نیست که در داخل یک زیرشبکه یا در میان زیرشبکه‌ها یکتا باشد. آمارهای مربوط به یک شناسه استخر مشخص در یک زیرشبکه با سایر آمارهای تمام استخرهای دیگری که همان شناسه استخر را در آن زیرشبکه دارند ادغام می‌شود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این بخش، آمارهای مختص DHCPv6 را شرح می‌دهد. برای بررسی اجمالی و نحوه استفاده از آمارها، Statistics \%<#\:stats>\& را ببینید. .UNINDENT .UNINDENT .sp سرور DHCPv6 دو پارامتر سراسری برای کنترل محدودیت‌های نمونه پیش‌فرض آمارها ارائه می‌دهد: .INDENT 0.0 .IP \(bu 2 \fBstatistic\-default\-sample\-count\fP \- حداکثر تعداد پیش‌فرض نمونه‌هایی را که باید نگهداری شوند تعیین می‌کند. مقدار ویژه 0 نشان می‌دهد که باید از یک حداکثر سن پیش‌فرض استفاده شود. .IP \(bu 2 \fBstatistic\-default\-sample\-age\fP \- حداکثر سن پیش‌فرض نمونه‌هایی را که باید نگهداری شوند، بر حسب ثانیه، تعیین می‌کند. .UNINDENT .sp برای نمونه، جهت کاهش بار اضافی نگهداری آمار، حداکثر تعداد پیش‌فرض نمونه‌ها را روی 1 تنظیم کنید تا تنها یک نمونه نگهداری شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqstatistic\-default\-sample\-count\(dq: 1, \(dqsubnet6\(dq: [ { ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp آمارها را می‌توان به‌صورت دوره‌ای بازیابی کرد تا بینش بیشتری درباره عملیات Kea به دست آورد. ابزاری که از این قابلیت بهره می‌برد ISC Stork است. برای جزئیات به Monitoring Kea With Stork \%<#\:stork> مراجعه کنید. .SS رابط مدیریت برای سرور DHCPv6 (Management API for the DHCPv6 Server) .sp رابط مدیریتی (Management API) امکان صدور دستورهای مدیریتی مشخص، نظیر بازیابی آمار، پیکربندی مجدد یا خاموش‌سازی را فراهم می‌کند. برای جزئیات بیشتر، Management API \%<#\:ctrl-channel>\& را ببینید. به‌طور پیش‌فرض هیچ سوکتی باز نیست؛ برای صدور دستور به Kea جهت باز کردن یک سوکت، می‌توان از مدخل زیر در فایل پیکربندی استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqcontrol\-sockets\(dq: [ { \(dqsocket\-type\(dq: \(dqunix\(dq, \(dqsocket\-name\(dq: \(dq/path/to/the/unix/socket\(dq } ], \(dqsubnet6\(dq: [ { ... }, ... ], ... } .EE .UNINDENT .UNINDENT .SS سوکت کنترل یونیکس (UNIX Control Socket) .sp تا سرور Kea نسخه 2.7.2، تنها نوع کانال ارتباطی پشتیبانی‌شده سوکت جریان UNIX با تنظیم \fBsocket\-type\fP روی \fBunix\fP و \fBsocket\-name\fP روی مسیر فایل سوکت UNIX/LOCAL بود. .sp طول مسیر مشخص‌شده توسط پارامتر \fBsocket\-name\fP به حداکثر طول مجاز برای نام سوکت UNIX در سیستم‌عامل مدیر سیستم، یعنی اندازه فیلد \fBsun_path\fP در ساختار \fBsockaddr_un\fP منهای 1، محدود است. این مقدار در سیستم‌عامل‌های گوناگون متغیر بوده و بین 91 تا 107 نویسه است. مقادیر معمول، 107 در Linux و 103 در FreeBSD هستند. .sp برنامه Kea تنها از یک سوکت کنترلی \fBunix\fP در فهرست \(dqcontrol\-sockets\(dq پشتیبانی می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه Kea 2.7.9 به بعد، سوکت‌های کنترل فقط می‌توانند در دایرکتوری تعیین‌شده در زمان کامپایل یعنی \fB\(dq[kea\-install\-dir]/var/run/kea\(dq\fP قرار گیرند، که این دایرکتوری نیز باید دارای مجوزهای دسترسی \fB0750\fP باشد. این مسیر ممکن است در زمان راه‌اندازی با تنظیم متغیر محیطی \fBKEA_CONTROL_SOCKET_DIR\fP به مسیر مورد نظر بازنویسی شود. اگر مسیری غیر از این مقدار در \fBsocket\-name\fP استفاده شود، Kea خطایی صادر کرده و از شروع به کار خودداری می‌کند یا در صورتی که از قبل در حال اجرا باشد، یک خطای غیرقابل‌بازیابی ثبت می‌کند. برای سهولت در استفاده، کافی است بخش مسیر را از \fBsocket\-name\fP حذف کنید\&. .UNINDENT .UNINDENT .sp ارتباط روی کانال کنترل با استفاده از ساختارهای JSON انجام می‌شود. برای جزئیات بیشتر، بخش Control Channel در Kea Developer\(aqs Guide \% را ببینید. .sp سرور DHCPv6 از دستورهای عملیاتی زیر پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBbuild\-report\fP \%<#\:std-isccmd-build-report> .IP \(bu 2 \fBconfig\-get\fP \%<#\:std-isccmd-config-get> .IP \(bu 2 \fBconfig\-hash\-get\fP \%<#\:std-isccmd-config-hash-get> .IP \(bu 2 \fBconfig\-reload\fP \%<#\:std-isccmd-config-reload> .IP \(bu 2 \fBconfig\-set\fP \%<#\:std-isccmd-config-set> .IP \(bu 2 \fBconfig\-test\fP \%<#\:std-isccmd-config-test> .IP \(bu 2 \fBconfig\-write\fP \%<#\:std-isccmd-config-write> .IP \(bu 2 \fBdhcp\-disable\fP \%<#\:std-isccmd-dhcp-disable> .IP \(bu 2 \fBdhcp\-enable\fP \%<#\:std-isccmd-dhcp-enable> .IP \(bu 2 \fBinterface\-add\fP \%<#\:std-isccmd-interface-add> .IP \(bu 2 \fBinterface\-list\fP \%<#\:std-isccmd-interface-list> .IP \(bu 2 \fBinterface\-redetect\fP \%<#\:std-isccmd-interface-redetect> .IP \(bu 2 \fBleases\-reclaim\fP \%<#\:std-isccmd-leases-reclaim> .IP \(bu 2 \fBlist\-commands\fP \%<#\:std-isccmd-list-commands> .IP \(bu 2 \fBshutdown\fP \%<#\:std-isccmd-shutdown> .IP \(bu 2 \fBstatus\-get\fP \%<#\:std-isccmd-status-get> .IP \(bu 2 \fBversion\-get\fP \%<#\:std-isccmd-version-get> .UNINDENT .sp همان‌طور که در Commands Supported by Both the DHCPv4 and DHCPv6 Servers \%<#\:commands-common>\& شرح داده شده است. علاوه بر این، از دستورهای مرتبط با آمار زیر پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBstatistic\-get\fP \%<#\:std-isccmd-statistic-get> .IP \(bu 2 \fBstatistic\-reset\fP \%<#\:std-isccmd-statistic-reset> .IP \(bu 2 \fBstatistic\-remove\fP \%<#\:std-isccmd-statistic-remove> .IP \(bu 2 \fBstatistic\-get\fP \%<#\:std-isccmd-statistic-get>\-all .IP \(bu 2 \fBstatistic\-reset\fP \%<#\:std-isccmd-statistic-reset>\-all .IP \(bu 2 \fBstatistic\-remove\fP \%<#\:std-isccmd-statistic-remove>\-all .IP \(bu 2 \fBstatistic\-sample\-age\-set\fP \%<#\:std-isccmd-statistic-sample-age-set> .IP \(bu 2 \fBstatistic\-sample\-age\-set\fP \%<#\:std-isccmd-statistic-sample-age-set>\-all .IP \(bu 2 \fBstatistic\-sample\-count\-set\fP \%<#\:std-isccmd-statistic-sample-count-set> .IP \(bu 2 \fBstatistic\-sample\-count\-set\fP \%<#\:std-isccmd-statistic-sample-count-set>\-all .UNINDENT .sp همان‌طور که در Commands for Manipulating Statistics \%<#\:command-stats>\& شرح داده شده است..SS سوکت کنترلی HTTP/HTTPS .sp مقدار \fBsocket\-type\fP باید \fBhttp\fP یا \fBhttps\fP باشد (زمانی که نوع \fBhttps\fP باشد، TLS الزامی است). پارامترهای \fBsocket\-address\fP (پیش‌فرض \fB::1\fP) و \fBsocket\-port\fP (پیش‌فرض 8000) آدرس IP و درگاهی را مشخص می‌کنند که سرویس HTTP به آن مقید (bind) خواهد شد. .sp از نسخه Kea 2.7.5، پارامتر \fBhttp\-headers\fP فهرستی از سرفصل‌های HTTP اضافی را برای افزودن به پاسخ‌های HTTP مشخص می‌کند. .sp پارامترهای \fBtrust\-anchor\fP، \fBcert\-file\fP، \fBkey\-file\fP و \fBcert\-required\fP پیکربندی TLS را برای HTTP، یعنی HTTPS، مشخص می‌کنند. اگر این پارامترها مشخص نشوند، HTTP استفاده می‌شود. پشتیبانی از TLS/HTTPS در Kea در بخش TLS/HTTPS Support \%<#\:tls>\& شرح داده شده است. .sp احراز هویت پایه HTTP (Basic authentication) از سرور در برابر استفاده‌های غیرمجاز توسط کاربران محلی محافظت می‌کند. برای محافظت در برابر مهاجمان از راه دور، HTTPS و پراکسی معکوس (reverse proxy) امنیت قوی‌تری فراهم می‌کنند. .sp احراز هویت در بلوک \fBauthentication\fP با پارامتر اجباری \fBtype\fP که نوع احراز هویت را انتخاب می‌کند، شرح داده می‌شود. در حال حاضر تنها احراز هویت پایه HTTP (نوع basic) پشتیبانی می‌شود. .sp پارامتر احراز هویت \fBrealm\fP (پیش‌فرض \fBkea\-dhcpv6\-server\fP) برای پیام‌های خطا در هنگامی استفاده می‌شود که احراز هویت پایه HTTP الزامی است اما کلاینت مجاز شناخته نشده است. .sp هنگامی که فهرست احراز هویت \fBclients\fP پیکربندی شده و خالی نباشد، احراز هویت پایه HTTP الزامی است. هر عنصر از فهرست، یک شناسه کاربری و یک گذرواژه را مشخص می‌کند. شناسه کاربری الزامی است، نباید خالی باشد و نباید شامل نویسه دونقطه (:) باشد. گذرواژه اختیاری است؛ در صورت عدم تعیین آن، از یک گذرواژه خالی استفاده می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 شناسه کاربری و گذرواژه در احراز هویت پایه HTTP با کدگذاری UTF\-8 ذخیره می‌شوند، اما نحو JSON فعلی Kea تنها از زیرمجموعه یونی‌کد Latin\-1 (یعنی 0x00..0xff) پشتیبانی می‌کند. .UNINDENT .UNINDENT .sp برای جلوگیری از افشای شناسه کاربری و/یا گذرواژه مرتبط با آن، می‌توان این مقادیر را از فایل‌ها خواند. نحو با موارد زیر گسترش یافته است: .INDENT 0.0 .IP \(bu 2 پارامتر احراز هویت \fBdirectory\fP، که بخش مشترک مسیر فایل‌ها را مدیریت می‌کند. مقدار پیش‌فرض، رشته خالی است. .IP \(bu 2 پارامتر کلاینت \fBpassword\-file\fP، که همراه با پارامتر \fBdirectory\fP، مسیر فایلی را مشخص می‌کند که می‌تواند حاوی گذرواژه باشد، یا اگر هیچ شناسه کاربری ارائه نشده باشد، کل راز احراز هویت پایه HTTP را در بر گیرد. .IP \(bu 2 پارامتر کلاینت \fBuser\-file\fP، که به همراه پارامتر \fBdirectory\fP، مسیر فایلی را مشخص می‌کند که شناسه کاربری را می‌توان از آن خواند. .UNINDENT .sp از نسخه Kea\-2.7.6، برنامه Kea از چندین اتصال HTTP/HTTPS پشتیبانی می‌کند. هم از آدرس‌های IPv4 و هم IPv6 می‌توان استفاده کرد. در صورت تغییر نوع سوکت از HTTP به HTTPS یا از HTTPS به HTTP با استفاده از همان آدرس و درگاه، سرور خطا صادر خواهد کرد. این عمل مجاز نیست، زیرا ممکن است به دلیل اشتباه سهوی کاربر، یک رخنه امنیتی ایجاد کند. هنگام استفاده از دستور \(dqconfig\-set\(dq برای جابه‌جایی از HTTP به HTTPS یا از HTTPS به HTTP، باید آدرس یا درگاه متفاوتی مشخص شود. همین امر هنگام تغییر فایل پیکربندی و سپس اجرای دستور \(dqconfig\-reload\(dq نیز صدق می‌کند. .sp هنگامی که از فایل‌ها استفاده می‌شود، آن‌ها در زمان بارگذاری پیکربندی خوانده می‌شوند تا خطاهای پیکربندی در سریع‌ترین زمان ممکن شناسایی شوند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqcontrol\-sockets\(dq: [ { \(dqsocket\-type\(dq: \(dqhttps\(dq, \(dqsocket\-address\(dq: \(dq2010:30:40::50\(dq, \(dqsocket\-port\(dq: 8005, \(dqhttp\-headers\(dq: [ { \(dqname\(dq: \(dqStrict\-Transport\-Security\(dq, \(dqvalue\(dq: \(dqmax\-age=31536000\(dq } ], \(dqtrust\-anchor\(dq: \(dq/path/to/the/ca\-cert.pem\(dq, \(dqcert\-file\(dq: \(dq/path/to/the/agent\-cert.pem\(dq, \(dqkey\-file\(dq: \(dq/path/to/the/agent\-key.pem\(dq, \(dqcert\-required\(dq: true, \(dqauthentication\(dq: { \(dqtype\(dq: \(dqbasic\(dq, \(dqrealm\(dq: \(dqkea\-dhcpv6\-server\(dq, \(dqclients\(dq: [ { \(dquser\(dq: \(dqadmin\(dq, \(dqpassword\(dq: \(dq1234\(dq } ] } }, { \(dqsocket\-type\(dq: \(dqhttp\(dq, \(dqsocket\-address\(dq: \(dq10.20.30.40\(dq, \(dqsocket\-port\(dq: 8005 } ], \(dqsubnet6\(dq: [ { ... }, ... ], ... } .EE .UNINDENT .UNINDENT .SS زمینه‌های کاربر در IPv6 .sp برنامه Kea امکان بارگذاری کتابخانه‌های قلاب (hook libraries) را فراهم می‌کند که گاهی می‌توانند از پارامترهای اضافی بهره‌مند شوند. اگر چنین پارامتری مختص کل کتابخانه باشد، معمولاً به عنوان پارامتری برای کتابخانه قلاب تعریف می‌شود. با این حال، گاهی اوقات نیاز است پارامترهایی مشخص شوند که برای هر استخر (pool) متفاوت باشند. .sp برای پیش‌زمینه بیشتر در رابطه با ایده user\-context، به بخش Comments and User Context \%<#\:user-context> مراجعه کنید. برای بررسی موضوع از دیدگاه قلاب‌ها، به User Contexts in Hooks \%<#\:user-context-hooks> مراجعه کنید. .sp زمینه‌های کاربر (user contexts) را می‌توان در دامنه سراسری (global scope)؛ در سطح shared\-network، subnet، pool، client\-class، option\-data یا definition؛ و از طریق رزرو میزبان (host reservation) مشخص کرد. یکی دیگر از ویژگی‌های کاربردی، امکان ذخیره یادداشت‌ها یا توضیحات است. .sp بیایید استقرار نمونه‌ای از lightweight 4over6 را در نظر بگیریم؛ فناوری گذار به IPv6 که امکان نگاشت پیشوندهای IPv6 به آدرس‌های IPv4 کامل یا جزئی را فراهم می‌کند. در زمینه DHCP، این‌ها پارامترهای خاصی هستند که قرار است در قالب گزینه‌های اضافی به کلاینت‌ها تحویل داده شوند. مقادیر این گزینه‌ها با پیشوندهای تفویض‌شده (delegated prefixes) همبستگی دارند، بنابراین منطقی است که این پارامترها به همراه استخر تفویض پیشوند (PD pool) نگهداری شوند. از سوی دیگر، lightweight 4over6 قابلیتی نیست که به طور متداول استفاده شود، بنابراین بخشی از کد پایه Kea محسوب نمی‌شود. راه‌حل این مسئله، تعیین یک زمینه کاربر است. برای هر استخر PD که انتظار می‌رود برای lightweight 4over6 استفاده شود، یک زمینه کاربر با پارامترهای اضافی تعریف می‌شود. آن پارامترهای اضافی توسط یک کتابخانه قلاب استفاده شده و تنها در صورتی بارگذاری می‌شوند که محاسبه پویای گزینه lightweight 4over6 واقعاً مورد نیاز باشد. نمونه‌ای از این پیکربندی به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqpd\-pools\(dq: [ { \(dqprefix\(dq: \(dq2001:db8::\(dq, \(dqprefix\-len\(dq: 56, \(dqdelegated\-len\(dq: 64, # This is a pool\-specific context. \(dquser\-context\(dq: { \(dqthreshold\-percent\(dq: 85, \(dqv4\-network\(dq: \(dq192.168.0.0/16\(dq, \(dqv4\-overflow\(dq: \(dq10.0.0.0/16\(dq, \(dqlw4over6\-sharing\-ratio\(dq: 64, \(dqlw4over6\-v4\-pool\(dq: \(dq192.0.2.0/24\(dq, \(dqlw4over6\-sysports\-exclude\(dq: true, \(dqlw4over6\-bind\-prefix\-len\(dq: 56 } } ], \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8::/32\(dq, # This is a subnet\-specific context. Any type of # information can be entered here as long as it is valid JSON. \(dquser\-context\(dq: { \(dqcomment\(dq: \(dqThose v4\-v6 migration technologies are tricky.\(dq, \(dqexperimental\(dq: true, \(dqbilling\-department\(dq: 42, \(dqcontacts\(dq: [ \(dqAlice\(dq, \(dqBob\(dq ] } } ] } .EE .UNINDENT .UNINDENT .sp برنامه Kea اطلاعات user\-context را تفسیر یا استفاده نمی‌کند؛ این برنامه صرفاً آن را ذخیره کرده و در دسترس کتابخانه‌های قلاب قرار می‌دهد. استخراج و استفاده از این اطلاعات به عهده هر کتابخانه قلاب است. تجزیه‌کننده (parser)، ورودی \fBcomment\fP را به یک زمینه کاربر به همراه آن ورودی تبدیل می‌کند، که این امر امکان پیوست کردن یادداشت درون خود پیکربندی را فراهم می‌سازد..SS "استانداردهای پشتیبانی‌شده DHCPv6" .sp استانداردهای زیر در حال حاضر در Kea پشتیبانی می‌شوند: .INDENT 0.0 .IP \(bu 2 \fIDynamic Host Configuration Protocol for IPv6\fP, RFC 3315 \%: پیام‌های پشتیبانی‌شده عبارتند از SOLICIT، ADVERTISE، REQUEST، RELEASE، RENEW، REBIND، INFORMATION\-REQUEST، CONFIRM، DECLINE و REPLY. تنها پیام پشتیبانی‌نشده RECONFIGURE است. تقریباً تمامی گزینه‌ها پشتیبانی می‌شوند، به جز AUTHENTICATION و RECONFIGURE\-ACCEPT. .IP \(bu 2 \fIDynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers\fP, RFC 3319 \%: تمامی گزینه‌های تعریف‌شده پشتیبانی می‌شوند. .IP \(bu 2 \fIIPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6\fP, RFC 3633 \%: گزینه‌های پشتیبانی‌شده IA_PD و IA_PREFIX هستند. همچنین کد وضعیت NoPrefixAvail نیز پشتیبانی می‌شود. .IP \(bu 2 \fIDNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)\fP, RFC 3646 \%: تمامی گزینه‌های تعریف‌شده پشتیبانی می‌شوند. .IP \(bu 2 \fIStateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6\fP, RFC 3736 \%: عملکرد سرور در حالت بدون حالت (stateless) پشتیبانی می‌شود. Kea در حال حاضر تنها در سمت سرور (server\-only) است، بنابراین سمت کلاینت پیاده‌سازی نشده است. .IP \(bu 2 \fISimple Network Time Protocol (SNTP) Configuration Option for DHCPv6\fP, RFC 4075 \%: گزینه SNTP پشتیبانی می‌شود. .IP \(bu 2 \fIRenumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)\fP, RFC 4076 \%: سرور از تمامی نیازمندی‌های شماره‌گذاری مجدد در حالت بدون حالت پشتیبانی می‌کند. .IP \(bu 2 \fIInformation Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)\fP, RFC 4242 \%: تنها گزینه تعریف‌شده (\fBinformation\-refresh\-time\fP) پشتیبانی می‌شود. .IP \(bu 2 \fIDynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers\fP, RFC 4280 \%: گزینه‌های DHCPv6 پشتیبانی می‌شوند. .IP \(bu 2 \fIDynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber\-ID Option\fP, RFC 4580 \%: گزینه subscribed\-id پشتیبانی می‌شود و می‌تواند در هر عبارتی استفاده شود. .IP \(bu 2 \fIThe Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote\-ID Option\fP, RFC 4649 \%: گزینه Remote\-ID پشتیبانی می‌شود. .IP \(bu 2 \fIA DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)\fP, RFC 4701 \%: سرور DHCPv6 از رکوردهای DHCID پشتیبانی می‌کند. سرور DHCP\-DDNS برای افزودن، به‌روزرسانی و/یا حذف رکوردهای DHCID باید در حال اجرا باشد. .IP \(bu 2 \fIResolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients\fP, RFC 4703 \%: سرور DHCPv6 برای حل تداخل‌ها از سرور DHCP\-DDNS استفاده می‌کند. .IP \(bu 2 \fIThe Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option\fP, RFC 4704 \%: گزینه پشتیبانی‌شده CLIENT_FQDN است. .IP \(bu 2 \fITimezone Options for DHCP\fP: RFC 4833 \%: هر دو گزینه DHCPv6 پشتیبانی می‌شوند. .IP \(bu 2 \fIDHCPv6 Leasequery\fP: RFC 5007 \%: قابلیت‌های سرور (انواع پیام‌ها، گزینه‌ها) پشتیبانی می‌شود. این ویژگی نیازمند قلاب leasequery است. برای جزئیات به libdhcp_lease_query.so: Leasequery Support \%<#\:hooks-lease-query> مراجعه کنید. .IP \(bu 2 \fIDHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents\fP: RFC 5192 \%: گزینه PANA پشتیبانی می‌شود. .IP \(bu 2 \fIDiscovering Location\-to\-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)\fP: RFC 5223 \%: گزینه LOST پشتیبانی می‌شود. .IP \(bu 2 \fIControl And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option\fP: RFC 5417 \%: گزینه CAPWAP for IPv6 پشتیبانی می‌شود. .IP \(bu 2 \fIDHCPv6 Bulk Leasequery\fP: RFC 5460 \%: قابلیت‌های سرور (اتصال TCP، انواع پیام‌ها و گزینه‌های جدید، انواع پرس‌وجوهای جدید) پشتیبانی می‌شود. این ویژگی نیازمند قلاب leasequery است. برای جزئیات به libdhcp_lease_query.so: Leasequery Support \%<#\:hooks-lease-query> مراجعه کنید. .IP \(bu 2 \fINetwork Time Protocol (NTP) Server Option for DHCPv6\fP: RFC 5908 \%: گزینه سرور NTP و زیرگزینه‌های آن پشتیبانی می‌شوند. برای جزئیات به NTP Server Suboptions مراجعه کنید. .IP \(bu 2 \fIDHCPv6 Options for Network Boot\fP: RFC 5970 \%: گزینه‌های بوت شبکه پشتیبانی می‌شوند. .IP \(bu 2 \fILightweight DHCPv6 Relay Agent\fP, RFC 6221 \%: برنامه Kea می‌تواند پیام‌های رله سبک‌وزن را مدیریت کند و از روش‌هایی به غیر از آدرس پیوند برای انتخاب زیرشبکه استفاده نماید. .IP \(bu 2 \fIDynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual\-Stack Lite\fP, RFC 6334 \%: گزینه DHCPv6 با عنوان AFTR\-Name پشتیبانی می‌شود. .IP \(bu 2 \fIRelay\-Supplied DHCP Options\fP, RFC 6422 \%: قابلیت کامل پشتیبانی می‌شود، از جمله OPTION_RSOO؛ توانایی سرور برای بازتاب دادن گزینه‌ها؛ بررسی فعال بودن RSOO برای یک گزینه؛ و امکان علامت‌گذاری گزینه‌های اضافی به عنوان فعال‌شده با RSOO. .IP \(bu 2 \fIThe EAP Re\-authentication Protocol (ERP) Local Domain Name DHCPv6 Option\fP, RFC 6440 \%: این گزینه پشتیبانی می‌شود. .IP \(bu 2 \fIPrefix Exclude Option for DHCPv6\-based Prefix Delegation\fP, RFC 6603 \%: گزینه Prefix Exclude پشتیبانی می‌شود. .IP \(bu 2 \fIClient Link\-Layer Address Option in DHCPv6\fP, RFC 6939 \%: گزینه پشتیبانی‌شده گزینه client link\-layer address است. .IP \(bu 2 \fIModification to Default values of SOL_MAX_RT and INF_MAX_RT\fP, RFC 7083 \%: گزینه‌های جدید پشتیبانی می‌شوند. .IP \(bu 2 \fIIssues and Recommendations with Multiple Stateful DHCPv6 Options\fP, RFC 7550 \%: تمامی توصیه‌های مربوط به عملکرد سرور DHCPv6 پشتیبانی می‌شوند. .IP \(bu 2 \fIDHCPv6 Options for Configuration of Softwire Address and Port\-Mapped Clients\fP, RFC 7598 \%: تمامی گزینه‌های مشخص‌شده در این سند، توسط سرور DHCPv6 پشتیبانی می‌شوند. .IP \(bu 2 \fIGeneralized UDP Source Port for DHCP Relay\fP, RFC 8357 \%: سرور Kea قادر است گزینه Relay Source Port را در پیام دریافتی Relay\-forward مدیریت کند، درگاه UDP را به خاطر بسپارد، و پاسخ Relay\-reply را همراه با رونوشتی از این گزینه و با استفاده از همین درگاه UDP به عامل رله بازپس بفرستد. .IP \(bu 2 \fIDynamic Host Configuration Protocol for IPv6 (DHCPv6)\fP, RFC 9915 \%: این مشخصه جدید پروتکل DHCPv6، استانداردهای RFC 3315، RFC 3633، RFC 3736، RFC 4242، RFC 7083، RFC 7283، RFC 7550 و RFC 8415 را منسوخ می‌کند. تمامی ویژگی‌ها، به استثنای سازوکار RECONFIGURE و سازوکار اکنون منسوخ‌شده آدرس‌های موقت (IA_TA)، پشتیبانی می‌شوند. .IP \(bu 2 \fICaptive\-Portal Identification in DHCP and Router Advertisements (RAs)\fP, RFC 8910 \%: سرور Kea می‌تواند هر دو نگارش v4 و v6 گزینه‌های captive portal را پیکربندی کند. .IP \(bu 2 \fIDHCP and Router Advertisement Options for the Discovery of Network\-designated Resolvers (DNR)\fP, RFC 9463 \%\&. سرور Kea از گزینه DNR پشتیبانی می‌کند. .IP \(bu 2 \fIRegistering Self\-Generated IPv6 Addresses Using DHCPv6\fP, RFC 9686 \%\&. سرور Kea از ثبت آدرس‌های خودساخته پشتیبانی می‌کند. برای جزئیات به Address Registration (RFC 9686 Support) مراجعه کنید. .UNINDENT.SS محدودیت‌های سرور DHCPv6 .sp این موارد محدودیت‌های شناخته‌شدهٔ کنونی نرم‌افزار سرور Kea DHCPv6 هستند. بیشتر آن‌ها بازتابی از مرحلهٔ کنونی توسعه هستند و به جای محدودیت‌های واقعی، باید به عنوان «هنوز پیاده‌سازی‌نشده» در نظر گرفته شوند. .INDENT 0.0 .IP \(bu 2 سرور برای هر گزینهٔ IA خاص (IA_NA یا IA_PD) ارسال‌شده توسط کلاینت، حداکثر یک اجاره (lease) را تخصیص داده، تمدید کرده یا بازنشانی (rebind) می‌کند. سند RFC 9915 \% اجازه می‌دهد چندین نشانی یا پیشوند برای یک IA واحد تخصیص یابد. .IP \(bu 2 نشانی‌های موقت پشتیبانی نمی‌شوند. هیچ برنامه‌ای برای پیاده‌سازی این ویژگی وجود ندارد، زیرا در RFC 9915 \%\& منسوخ شده است. .IP \(bu 2 پیکربندی مجدد کلاینت (RECONFIGURE) هنوز پشتیبانی نمی‌شود. .UNINDENT .SS مثال‌های سرور Kea DHCPv6 .sp مجموعه‌ای از مثال‌های ساده و کاربردی برای مؤلفهٔ DHCPv6 از Kea به همراه فایل‌های منبع، در دایرکتوری \fBdoc/examples/kea6\fP در دسترس است. .SS بک‌اند پیکربندی در DHCPv6 .sp در بخش Kea Configuration Backend \%<#\:config-backend> ویژگی بک‌اند پیکربندی (CB)، کاربرد آن و محدودیت‌هایش را توضیح داده‌ایم. این بخش بر استفاده از CB با سرور DHCPv6 تمرکز دارد. این قسمت پارامترهای پشتیبانی‌شده را فهرست می‌کند، محدودیت‌ها را توضیح می‌دهد و برای بهره‌گیری از CB، مثال‌هایی از پیکربندی سرور DHCPv6 ارائه می‌دهد. لطفاً برای استفادهٔ مخصوص DHCPv4 از CB، به بخش متناظر Configuration Backend in DHCPv4 \%<#\:dhcp4-cb> نیز مراجعه کنید. .SS پارامترهای پشتیبانی‌شده .sp هدف نهایی CB این است که به عنوان یک مخزن مرکزی پیکربندی برای یک یا چند سرور Kea متصل به یک پایگاه‌داده عمل کند. در نسخه‌های کنونی پشتیبانی‌شدهٔ Kea، تنها زیرمجموعه‌ای از پارامترهای سرور DHCPv6 را می‌توان در پایگاه‌داده پیکربندی کرد. سایر پارامترها در صورت نیاز باید در فایل پیکربندی JSON مشخص شوند. .sp تمام پارامترهای پشتیبانی‌شده را می‌توان از طریق \fBlibdhcp_cb_cmds.so\fP \%<#\:std-ischooklib-libdhcp_cb_cmds\:.so>\& پیکربندی کرد. قاعدهٔ کلی این است که پارامترهای سراسری اسکالر با استفاده از \fBremote\-global\-parameter6\-set\fP \%<#\:std-isccmd-remote-global-parameter6-set> تنظیم می‌شوند؛ پارامترهای ویژهٔ شبکهٔ مشترک با استفاده از \fBremote\-network6\-set\fP \%<#\:std-isccmd-remote-network6-set> تنظیم می‌شوند؛ و پارامترهای سطح زیرشبکه و استخر با استفاده از \fBremote\-subnet6\-set\fP \%<#\:std-isccmd-remote-subnet6-set>\& تنظیم می‌گردند. هرگاه استثنایی برای این قاعدهٔ کلی وجود داشته باشد، در جدول مشخص شده است. پارامترهای سراسری غیراسکالر دستورهای اختصاصی خود را دارند؛ برای مثال، گزینه‌های سراسری DHCPv6 (\fBoption\-data\fP) با استفاده از \fBremote\-option6\-global\-set\fP \%<#\:std-isccmd-remote-option6-global-set>\& تغییر داده می‌شوند. کلاس‌های کلاینت به همراه تعاریف گزینه‌ها و گزینه‌های DHCPv6 ویژهٔ کلاس، با استفاده از دستور \fBremote\-class6\-set\fP \%<#\:std-isccmd-remote-class6-set> پیکربندی می‌شوند. .sp بخش Configuration Sharing and Server Tags \%<#\:cb-sharing> مفهوم عناصر پیکربندی اشتراک‌پذیر و غیراشتراک‌پذیر و محدودیت‌های به‌اشتراک‌گذاری آن‌ها میان چندین سرور را توضیح می‌دهد. در پیکربندی DHCP (هم DHCPv4 و هم DHCPv6)، عناصر پیکربندی اشتراک‌پذیر زیرشبکه‌ها و شبکه‌های مشترک هستند. بنابراین، می‌توان آن‌ها را به‌طور صریح با چندین برچسب سرور مرتبط ساخت. پارامترهای سراسری، تعاریف گزینه‌ها و گزینه‌های سراسری غیراشتراک‌پذیر هستند و تنها می‌توانند با یک برچسب سرور مرتبط شوند. این قاعده برای عناصر پیکربندی مرتبط با سرورهای \fBall\fP صدق نمی‌کند. هر عنصر پیکربندی مرتبط با سرورهای \fBall\fP (با استفاده از کلمهٔ کلیدی \fBall\fP به عنوان برچسب سرور) توسط تمام سرورهای متصل به پایگاه‌دادهٔ پیکربندی مورد استفاده قرار می‌گیرد. .sp جدول زیر پارامترهای ویژهٔ DHCPv6 پشتیبانی‌شده توسط بک‌اند پیکربندی را به همراه سطحی از سلسله‌مراتب که در آن پشتیبانی می‌شود، فهرست می‌کند. .SS فهرست پارامترهای DHCPv6 پشتیبانی‌شده توسط بک‌اند پیکربندی .TS box center; l|l|l|l|l|l|l. T{ پارامتر T} T{ سراسری T} T{ کلاس کلاینت T} T{ شبکهٔ مشترک T} T{ زیرشبکه T} T{ استخر T} T{ استخر واگذاری پیشوند T} _ T{ allocator T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ cache\-max\-age T} T{ بله T} T{ نامربوط T} T{ خیر T} T{ خیر T} T{ نامربوط T} T{ نامربوط T} _ T{ cache\-threshold T} T{ بله T} T{ نامربوط T} T{ خیر T} T{ خیر T} T{ نامربوط T} T{ نامربوط T} _ T{ calculate\-tee\-times T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ client\-class T} T{ نامربوط T} T{ نامربوط T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} _ T{ ddns\-send\-update T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ ddns\-override\-no\-update T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ ddns\-override\-client\-update T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ ddns\-replace\-client\-name T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ ddns\-generated\-prefix T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ ddns\-qualifying\-suffix T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ decline\-probation\-period T} T{ بله T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} _ T{ delegated\-len T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ بله T} _ T{ dhcp4o6\-port T} T{ بله T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} _ T{ excluded\-prefix T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ بله T} _ T{ excluded\-prefix\-len T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ بله T} _ T{ hostname\-char\-set T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ hostname\-char\-replacement T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ interface T} T{ نامربوط T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ interface\-id T} T{ نامربوط T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ max\-preferred\-lifetime T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ max\-valid\-lifetime T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ min\-preferred\-lifetime T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ min\-valid\-lifetime T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ option\-data T} T{ بله (از طریق remote\-option6\-global\-set) T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} _ T{ option\-def T} T{ بله (از طریق remote\-option\-def6\-set) T} T{ بله T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} _ T{ pd\-allocator T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ preferred\-lifetime T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ prefix T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ بله T} _ T{ prefix\-len T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ نامربوط T} T{ بله T} _ T{ rapid\-commit T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ rebind\-timer T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ relay T} T{ نامربوط T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ renew\-timer T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ require\-client\-classes T} T{ خیر T} T{ نامربوط T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} _ T{ evaluate\-additional\-classes T} T{ خیر T} T{ نامربوط T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} _ T{ reservations\-global T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ reservations\-in\-subnet T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ reservations\-out\-of\-pool T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ t1\-percent T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ t2\-percent T} T{ بله T} T{ نامربوط T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} _ T{ valid\-lifetime T} T{ بله T} T{ بله T} T{ بله T} T{ بله T} T{ نامربوط T} T{ نامربوط T} .TE .INDENT 0.0.IP \(bu 2 \fByes\fP \- نشان می‌دهد که پارامتر در سطح مشخص‌شده از سلسله‌مراتب پشتیبانی می‌شود و از طریق backend پیکربندی قابل تنظیم است. .IP \(bu 2 \fBno\fP \- نشان می‌دهد که پارامتر در سطح مشخص‌شده از سلسله‌مراتب پشتیبانی می‌شود اما از طریق backend پیکربندی قابل تنظیم نیست. .IP \(bu 2 \fBn/a\fP \- نشان می‌دهد که پارامتر داده‌شده در سطح خاصی از سلسله‌مراتب کاربرد ندارد یا سرور از پارامتر در آن سطح پشتیبانی نمی‌کند. .UNINDENT .sp برخی از پارامترهای اسکالر موجود در نگاشت‌های سراسری سطح بالا توسط backend پیکربندی پشتیبانی می‌شوند. .SS فهرست پارامترهای نگاشت DHCPv6 پشتیبانی‌شده توسط backend پیکربندی (List of DHCPv6 map parameters supported by the configuration backend) .TS box center; l|l|l. T{ نام پارامتر (قالب نام‌گذاری مسطح) T} T{ نگاشت سراسری T} T{ نام پارامتر T} _ T{ compatibility.lenient\-option\-parsing T} T{ compatibility T} T{ lenient\-option\-parsing T} _ T{ dhcp\-ddns.enable\-updates T} T{ dhcp\-ddns T} T{ enable\-updates T} _ T{ dhcp\-ddns.max\-queue\-size T} T{ dhcp\-ddns T} T{ max\-queue\-size T} _ T{ dhcp\-ddns.ncr\-format T} T{ dhcp\-ddns T} T{ ncr\-format T} _ T{ dhcp\-ddns.ncr\-protocol T} T{ dhcp\-ddns T} T{ ncr\-protocol T} _ T{ dhcp\-ddns.sender\-ip T} T{ dhcp\-ddns T} T{ sender\-ip T} _ T{ dhcp\-ddns.sender\-port T} T{ dhcp\-ddns T} T{ sender\-port T} _ T{ dhcp\-ddns.server\-ip T} T{ dhcp\-ddns T} T{ server\-ip T} _ T{ dhcp\-ddns.server\-port T} T{ dhcp\-ddns T} T{ server\-port T} _ T{ expired\-leases\-processing.flush\-reclaimed\-timer\-wait\-time T} T{ expired\-leases\-processing T} T{ flush\-reclaimed\-timer\-wait\-time T} _ T{ expired\-leases\-processing.hold\-reclaimed\-time T} T{ expired\-leases\-processing T} T{ hold\-reclaimed\-time T} _ T{ expired\-leases\-processing.max\-reclaim\-leases T} T{ expired\-leases\-processing T} T{ max\-reclaim\-leases T} _ T{ expired\-leases\-processing.max\-reclaim\-time T} T{ expired\-leases\-processing T} T{ max\-reclaim\-time T} _ T{ expired\-leases\-processing.reclaim\-timer\-wait\-time T} T{ expired\-leases\-processing T} T{ reclaim\-timer\-wait\-time T} _ T{ expired\-leases\-processing.unwarned\-reclaim\-cycles T} T{ expired\-leases\-processing T} T{ unwarned\-reclaim\-cycles T} _ T{ multi\-threading.enable\-multi\-threading T} T{ multi\-threading T} T{ enable\-multi\-threading T} _ T{ multi\-threading.thread\-pool\-size T} T{ multi\-threading T} T{ thread\-pool\-size T} _ T{ multi\-threading.packet\-queue\-size T} T{ multi\-threading T} T{ packet\-queue\-size T} _ T{ sanity\-checks.lease\-checks T} T{ sanity\-checks T} T{ lease\-checks T} _ T{ sanity\-checks.extended\-info\-checks T} T{ sanity\-checks T} T{ extended\-info\-checks T} _ T{ server\-id.type T} T{ server\-id T} T{ type T} _ T{ server\-id.enterprise\-id T} T{ server\-id T} T{ enterprise\-id T} _ T{ server\-id.identifier T} T{ server\-id T} T{ identifier T} _ T{ server\-id.persist T} T{ server\-id T} T{ persist T} _ T{ dhcp\-queue\-control.enable\-queue T} T{ dhcp\-queue\-control T} T{ enable\-queue T} _ T{ dhcp\-queue\-control.queue\-type T} T{ dhcp\-queue\-control T} T{ queue\-type T} _ T{ dhcp\-queue\-control.capacity T} T{ dhcp\-queue\-control T} T{ capacity T} .TE .sp برخی از پارامترهای فهرست سراسری که تنها حاوی انواع اسکالر هستند، توسط backend پیکربندی پشتیبانی می‌شوند..SS فهرست پارامترهای فهرستی DHCPv6 پشتیبانی‌شده توسط پس‌بند پیکربندی .TS box center; l. T{ نام پارامتر | نوع پارامتر نگه‌دارنده فهرست T} _ T{ host\-reservation\-identifiers | string T} .TE .SS فعال‌سازی پس‌بند پیکربندی .sp قطعه‌پیکربندی زیر را در نظر بگیرید که از یک پایگاه‌داده پیکربندی MySQL استفاده می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqserver\-tag\(dq: \(dqmy DHCPv6 server\(dq, \(dqconfig\-control\(dq: { \(dqconfig\-databases\(dq: [ { \(dqtype\(dq: \(dqmysql\(dq, \(dqname\(dq: \(dqkea\(dq, \(dquser\(dq: \(dqkea\(dq, \(dqpassword\(dq: \(dq1234\(dq, \(dqhost\(dq: \(dq2001:db8:1::1\(dq, \(dqport\(dq: 3302 } ], \(dqconfig\-fetch\-wait\-time\(dq: 20 }, \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_mysql.so\(dq }, { \(dqlibrary\(dq: \(dqlibdhcp_cb_cmds.so\(dq } ] } } .EE .UNINDENT .UNINDENT .sp قطعه‌کد زیر استفاده از یک پایگاه‌داده PostgreSQL را نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqserver\-tag\(dq: \(dqmy DHCPv6 server\(dq, \(dqconfig\-control\(dq: { \(dqconfig\-databases\(dq: [ { \(dqtype\(dq: \(dqpostgresql\(dq, \(dqname\(dq: \(dqkea\(dq, \(dquser\(dq: \(dqkea\(dq, \(dqpassword\(dq: \(dq1234\(dq, \(dqhost\(dq: \(dq2001:db8:1::1\(dq, \(dqport\(dq: 3302 } ], \(dqconfig\-fetch\-wait\-time\(dq: 20 }, \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_pgsql.so\(dq }, { \(dqlibrary\(dq: \(dqlibdhcp_cb_cmds.so\(dq } ] } } .EE .UNINDENT .UNINDENT .sp ساختار پیکربندی تقریباً مشابه با کارساز DHCPv4 است (برای توضیحات دقیق، فعال‌سازی پس‌بند پیکربندی \%<#\:dhcp4-cb-json> را ببینید). .SS پارامترهای پیکربندی سازگاری Kea DHCPv6 .sp هدف ISC این است که Kea از اسناد RFC پیروی کند تا سازگاری بهتری با استانداردها ارتقا یابد. با این حال، پیاده‌سازی‌های معیوب بسیاری از DHCP وجود دارند که نمی‌توان به آسانی آن‌ها را اصلاح یا ارتقا داد. بنابراین، Kea یک حالت سازگاری با استفاده آسان برای کلاینت‌های معیوب یا ناسازگار فراهم می‌کند. به همین منظور، باید گزینه سازگاری فعال شود تا رفتارهای نامتعارف مجاز گردند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqcompatibility\(dq: { } } } .EE .UNINDENT .UNINDENT .SS تجزیه آسان‌گیرانه گزینه‌ها .sp به‌طور پیش‌فرض، فیلد \fBvendor\-class\-data\fP در گزینه ۱۶ DHCPv6 به‌صورت مجموعه‌ای از جفت‌های طول\-مقدار تجزیه می‌شود؛ همین امر برای فیلدهای چندتایی (tuple) تعریف‌شده در گزینه‌های سفارشی نیز صادق است. .sp با \fB\(dqlenient\-option\-parsing\(dq: true\fP، اگر یک طول از باقی‌مانده بافر گزینه فراتر رود، نسخه‌های پیشین Kea پیام گزارشی با مضمون \fBunable to parse the opaque data tuple, the buffer length is x, but the tuple length is y\fP با \fBx < y\fP بازمی‌گرداندند؛ این وضعیت دیگر رخ نمی‌دهد. در عوض، مقدار برابر با باقی‌مانده بافر در نظر گرفته می‌شود، یا به بیان پیام گزارش بالا، طول تاپل \fBy\fP به \fBx\fP تبدیل می‌شود\&. .sp انتظار می‌رود فعال کردن این پرچم، سازگاری با دستگاه‌هایی مانند RAD MiNID را بهبود بخشد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqcompatibility\(dq: { \(dqlenient\-option\-parsing\(dq: true } } } .EE .UNINDENT .UNINDENT .sp از نسخه 2.5.8 به بعد Kea، این شیوه تجزیه گسترش یافته است تا گزینه‌های client\-fqdn (39) با برخی نام‌های دامنه نامعتبر را بدون هشدار نادیده بگیرد؛ همچنین از نسخه 3.1.9 به بعد Kea، پرچم‌های نامعتبر را اصلاح می‌کند، بدین معنا که وقتی پرچم‌های \(aqS\(aq و \(aqN\(aq روی 1 تنظیم شده باشند، پرچم \(aqN\(aq جهت سازگاری با رفتار ISC DHCP به 0 بازنشانی می‌شود..SS راهبردهای تخصیص در DHCPv6 .sp یک سرور DHCP از الگوریتم پیچیده‌ای برای انتخاب اجارهٔ (lease) DHCPv6 برای کلاینت پیروی می‌کند. این سرور واگذاری آدرس‌های خاص یا پیشوندهای تفویض‌شدهٔ درخواست‌شده توسط کلاینت و مواردی را که کلاینت برای آن‌ها رزرو دارد، در اولویت قرار می‌دهد. .sp هنگامی که کلاینت یک پیشوند تفویض‌شدهٔ مشخص را درخواست می‌کند، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> مجموعه‌ای از مراحل را برای برآورده کردن درخواست، به این ترتیب دنبال می‌کند: .INDENT 0.0 .IP 1. 3 به‌دنبال اجاره‌ای می‌گردد که با پیشوند و طول پیشوند درخواست‌شده مطابقت داشته باشد. .IP 2. 3 به‌دنبال اجاره‌ای می‌گردد که با طول پیشوند مطابقت داشته باشد. .IP 3. 3 به‌دنبال اجاره‌ای با فضای آدرس بزرگ‌تر (طول پیشوند کوچک‌تر) می‌گردد. .IP 4. 3 به‌دنبال اجاره‌ای با فضای آدرس کوچک‌تر (طول پیشوند بزرگ‌تر) می‌گردد. .UNINDENT .sp اگر کلاینت هیچ اجارهٔ خاصی را درخواست نکند و هیچ رزروی نداشته باشد، یا کلاینت‌های دیگر در حال حاضر از اجاره‌های درخواستی استفاده کنند، سرور باید اجارهٔ دردسترس دیگری را در استخرهای (pools) پیکربندی‌شده پیدا کند. تابعی در سرور موسوم به \(dqallocator\(dq (تخصیص‌دهنده) در Kea مسئول یافتن اجارهٔ دردسترس در چنین شرایطی است. .sp سرور Kea DHCPv6 پارامترهای پیکربندی مختلفی را برای انتخاب تخصیص‌دهنده‌های گوناگون در سطوح سراسری (global)، شبکهٔ مشترک (shared\-network) و زیرشبکه (subnet) فراهم می‌کند. همچنین امکان انتخاب راهبردهای تخصیص متفاوت را برای واگذاری آدرس‌ها و تفویض پیشوند (prefix delegation) مهیا می‌سازد. .sp مثال زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqallocator\(dq: \(dqiterative\(dq, \(dqpd\-allocator\(dq: \(dqrandom\(dq, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqallocator\(dq: \(dqrandom\(dq }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq2001:db8:2::/64\(dq, \(dqpd\-allocator\(dq: \(dqiterative\(dq } ] } } .EE .UNINDENT .UNINDENT .sp تخصیص‌دهندهٔ iterative به‌صورت سراسری برای واگذاری آدرس‌ها انتخاب شده است، در حالی که تخصیص‌دهندهٔ random به‌صورت سراسری برای تفویض پیشوند تعیین شده است. این تنظیمات به‌صورت انتخابی در سطح زیرشبکه بازنویسی (override) می‌شوند. .sp بخش‌های زیر تخصیص‌دهنده‌های پشتیبانی‌شده و کاربردهای توصیه‌شدهٔ آن‌ها را شرح می‌دهند. .SS مقایسهٔ تخصیص‌دهنده‌ها .sp در جدول زیر، تخصیص‌دهنده‌های پشتیبانی‌شده را به‌طور خلاصه مقایسه می‌کنیم؛ تمامی آن‌ها در بخش‌های بعدی با جزئیات شرح داده شده‌اند. .SS مقایسهٔ تخصیص‌دهنده‌های اجارهٔ پشتیبانی‌شده توسط Kea DHCPv6 .TS box center; l|l|l|l|l|l. T{ تخصیص‌دهنده T} T{ کارایی در بهره‌برداری کم T} T{ کارایی در بهره‌برداری زیاد T} T{ تصادفی‌سازی اجاره T} T{ راه‌اندازی/پیکربندی T} T{ مصرف حافظه T} _ T{ Iterative T} T{ بسیار بالا T} T{ پایین T} T{ خیر T} T{ بسیار سریع T} T{ کم T} _ T{ Random T} T{ بالا T} T{ پایین T} T{ بله T} T{ بسیار سریع T} T{ زیاد (متغیر) T} _ T{ Free Lease Queue T} T{ بالا T} T{ بالا T} T{ بله T} T{ کند (بسته به اندازهٔ استخرها) T} T{ زیاد (متغیر) T} _ T{ Shared FLQ T} T{ بالا T} T{ بالا T} T{ جزئی، استخرهای درون زیرشبکه‌ها تصادفی هستند T} T{ کند هنگام افزودن استفاده؛ سریع پس از افزودن T} T{ کم T} .TE.SS تخصیص‌دهنده تکرارشونده (Iterative Allocator) .sp این تخصیص‌دهنده پیش‌فرضی است که توسط کارگزار Kea DHCPv6 استفاده می‌شود. این تخصیص‌دهنده آخرین اجارهٔ پیشنهادشده را به خاطر می‌سپارد و اجارهٔ ترتیبی بعدی را به کلاینت بعدی پیشنهاد می‌دهد. برای نمونه، ممکن است نشانی‌ها را به این ترتیب پیشنهاد دهد: \fB2001:db8:1::10\fP، \fB2001:db8:1::11\fP، \fB2001:db8:1::12\fP و غیره. به همین ترتیب، پیشوند واگذارشدهٔ ترتیبی بعدی را پس از مورد قبلی به کلاینت بعدی پیشنهاد می‌کند. زمان لازم برای یافتن و پیشنهاد دادن اجاره یا پیشوند واگذارشدهٔ بعدی بسیار کوتاه است؛ بنابراین، زمانی که بهره‌برداری از استخر پایین بوده و احتمال در دسترس بودن اجارهٔ انتخابی بعدی بالا باشد، این کارآمدترین تخصیص‌دهنده است. .sp تخصیص تکرارشونده زمانی که چندین کارگزار DHCP یک پایگاه‌دادهٔ اجاره را به اشتراک می‌گذارند یا به یک کلاستر متصل هستند، عملکرد ضعیفی ارائه می‌دهد. کارگزارها تمایل دارند همان بلوک‌های نشانی را به‌طور مستقل به کلاینت‌های مختلف پیشنهاد داده و تخصیص دهند، که باعث تداخل‌های تخصیص فراوان بین کارگزارها و ارسال‌های مجدد توسط کلاینت‌ها می‌شود. یک تخصیص تصادفی با پراکنده‌سازی ترتیب تخصیص، این مشکل را برطرف می‌کند. .SS تخصیص‌دهنده تصادفی (Random Allocator) .sp تخصیص‌دهنده تصادفی از یک تابع تصادفی‌سازی یکنواخت برای انتخاب نشانی‌ها و پیشوندهای واگذارشدهٔ پیشنهادی از استخرهای زیرشبکه استفاده می‌کند. این تخصیص‌دهنده در استقرارهایی مناسب است که چندین کارگزار به یک پایگاه‌دادهٔ مشترک یا یک کلاستر پایگاه‌داده متصل هستند. کارگزارها با پراکنده‌سازی اجاره‌های پیشنهادی، خطر تخصیص هم‌زمان یا تقریباً هم‌زمان یک اجارهٔ یکسان به دو کلاینت مختلف را به حداقل می‌رسانند. علاوه بر این، تاب‌آوری کارگزار را در برابر حملات مبتنی بر پیش‌بینی‌پذیری تخصیص بهبود می‌بخشد. .sp با این حال، تخصیص‌دهنده تصادفی اندکی از تخصیص‌دهنده تکرارشونده کندتر است. افزون بر این، مصرف حافظهٔ کارگزار را افزایش می‌دهد زیرا باید اجاره‌های تصادفی‌شده را به خاطر بسپارد تا از پیشنهاد دوبارهٔ آن‌ها جلوگیری کند. مصرف حافظه با تعداد اجاره‌های پیشنهادشده رشد می‌کند؛ به عبارت دیگر، استخرهای بزرگ‌تر و کلاینت‌های بیشتر، مصرف حافظه را در تخصیص تصادفی افزایش می‌دهند. .SS تخصیص‌دهنده صف اجاره‌های آزاد (فقط واگذاری پیشوند) .sp این یک تخصیص‌دهنده پیشرفته است که استفاده از آن باید در زیرشبکه‌هایی با استخرهای پیشوند واگذارشده با میزان مصرف بالا مد نظر قرار گیرد. در چنین مواردی، ممکن است یافتن یک پیشوند در دسترس برای تخصیص‌دهنده تکرارشونده یا تصادفی زمان قابل‌توجهی ببرد، زیرا آن‌ها باید مکرراً بررسی کنند که آیا برای پیشوندی که قصد پیشنهاد آن را دارند یک اجارهٔ معتبر وجود دارد یا خیر. زمانی که ظرفیت استخرهای زیرشبکه تکمیل شده باشد، تعداد بررسی‌ها می‌تواند به اندازهٔ تعداد کل پیشوندهای واگذارشده در زیرشبکه بالا برود که این امر می‌تواند تأثیر منفی مستقیمی بر زمان پاسخ DHCP برای هر درخواست بگذارد. .sp تخصیص‌دهنده Free Lease Queue (FLQ) تخصیص‌ها و لغو تخصیص‌های اجاره را ردیابی کرده و فهرستی پویا از پیشوندهای واگذارشدهٔ در دسترس را برای هر استخر نگهداری می‌کند. این تخصیص‌دهنده اجازه می‌دهد که بدون در نظر گرفتن میزان استفاده از استخرهای زیرشبکه، یک اجارهٔ در دسترس در یک زمان ثابت انتخاب شود. تخصیص‌دهنده با حذف اجاره‌های تخصیص‌یافته و افزودن اجاره‌های آزادشده یا بازپس‌گرفته‌شده، فهرست اجاره‌های آزاد را به‌طور مداوم به‌روزرسانی می‌کند. .sp قطعه پیکربندی زیر نحوه انتخاب تخصیص‌دهنده FLQ را برای واگذاری پیشوند در یک زیرشبکه نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpd\-allocator\(dq: \(dqflq\(dq } ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تخصیص‌دهنده Free Lease Queue تنها می‌تواند برای واگذاری پیشوند DHCPv6 استفاده شود. تلاش برای استفاده از این تخصیص‌دهنده جهت انتساب نشانی (با پارامتر \fBallocator\fP) منجر به خطای پیکربندی خواهد شد. استخرهای نشانی DHCPv6 معمولاً بسیار بزرگ هستند و میزان استفاده از آن‌ها پایین است؛ در این وضعیت، مزایای استفاده از تخصیص‌دهنده FLQ کم‌رنگ می‌شود. مدت‌زمان مورد نیاز تخصیص‌دهنده برای پر کردن صف اجاره‌های آزاد، باعث قفل شدن کارگزار در هنگام راه‌اندازی می‌شود. .UNINDENT .UNINDENT .sp چندین نکته وجود دارد که مدیر سیستم باید پیش از استفاده از این تخصیص‌دهنده برای واگذاری پیشوند مد نظر قرار دهد. تخصیص‌دهنده FLQ می‌تواند تأثیر شدیدی بر زمان راه‌اندازی و بازپیکربندی کارگزار بگذارد، زیرا تخصیص‌دهنده باید فهرست اجاره‌های آزاد را برای هر زیرشبکه‌ای که در آن استفاده می‌شود پر کند. این تأخیرها هم در طول بارگذاری مجدد پیکربندی و هم هنگامی که زیرشبکه‌ها با استفاده از \fBlibdhcp_subnet_cmds.so\fP \%<#\:std-ischooklib-libdhcp_subnet_cmds\:.so>\& ایجاد می‌شوند، قابل مشاهده است. این تخصیص‌دهنده برای نگهداری فهرست اجاره‌های آزاد، مصرف حافظه را متناسب با اندازهٔ کل استخرهایی که برای آن‌ها به کار رفته است افزایش می‌دهد. در نهایت، بازپس‌گیری اجاره باید با مقدار پایینی برای پارامتر \fBreclaim\-timer\-wait\-time\fP فعال شود، تا اطمینان حاصل گردد که کارگزار به‌طور مکرر اجاره‌های منقضی‌شده را جمع‌آوری کرده و آن‌ها را از طریق صف اجاره‌های آزاد برای تخصیص مجدد در دسترس قرار می‌دهد. اجاره‌های منقضی‌شده تا زمانی که توسط کارگزار بازپس‌گرفته نشوند، از نظر تخصیص‌دهنده آزاد به شمار نمی‌آیند. برای جزئیات بیشتر درباره فرایند بازپس‌گیری اجاره، بخش Lease Reclamation \%<#\:lease-reclamation> را ببینید. .sp پیشنهاد می‌کنیم تخصیص‌دهنده FLQ تنها پس از بررسی دقیق انتخاب شود. کارگزار هیچ محدودیتی بر اندازه استخرهای delegated\-prefix مورد استفاده با تخصیص‌دهنده FLQ اعمال نمی‌کند، بنابراین به کاربران توصیه می‌کنیم قبل از استقرار پیکربندی دارای تخصیص‌دهنده FLQ در محیط عملیاتی، زمان لازم برای بارگذاری استخرها توسط کارگزار را آزمایش کنند. همچنین توصیه می‌کنیم نوع تخصیص‌دهنده دیگری را در تنظیمات پیکربندی سراسری مشخص کرده و این انتخاب را در سطح subnet یا shared\-network بازنویسی کنید، تا از تخصیص‌دهنده FLQ فقط برای زیرشبکه‌های انتخابی استفاده شود. به این ترتیب، زمانی که یک زیرشبکه جدید بدون مشخص کردن تخصیص‌دهنده افزوده می‌شود، تنظیمات سراسری استفاده می‌شود و در نتیجه از تحمیل اثر غیرضروری بر زمان راه‌اندازی کارگزار جلوگیری می‌شود. .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 تخصیص‌دهنده FLQ برای استفاده با پایگاه‌دادهٔ اجاره مشترک مناسب نیست (یعنی زمانی که چندین کارگزار Kea اجاره‌ها را در یک پایگاه‌داده یکسان ذخیره می‌کنند). کارگزارها از اجاره‌های منقضی‌شده‌ای که توسط کارگزارهای همتا بازپس‌گرفته شده‌اند اطلاعی ندارند و هرگز آن‌ها را به صف‌های محلی اجاره‌های آزاد خود بازنمی‌گردانند. در نتیجه، کارگزارها قادر نخواهند بود برخی از اجاره‌های در دسترس را به کلاینت‌ها پیشنهاد دهند. تنها کارگزاری که یک اجارهٔ مشخص را بازپس می‌گیرد قادر به پیشنهاد دادن آن خواهد بود. .UNINDENT .UNINDENT .sp در Kea 3.1.1 یک پارامتر جدید با نام \fBadaptive\-lease\-time\-threshold\fP اضافه شد. این پارامتر می‌تواند در سطوح global، shared network و subnet مشخص شود و یک مقدار اعشاری بین \fB0.0\fP (به‌جز خود آن) و \fB1.0\fP می‌پذیرد. این پارامتر به‌طور پیش‌فرض یا در صورت تنظیم بر روی \fB1.0\fP غیرفعال است. این پارامتر تنها توسط تخصیص‌دهنده FLQ پشتیبانی می‌شود. هنگامی که نرخ اشغال استخرها در یک زیرشبکه بالاتر از مقدار مشخص‌شده باشد، کارگزار طول‌عمر معتبر اجاره را برای کلاینت‌های جدید به مقدار مربوط در \fBmin\-valid\-lifetime\fP کاهش می‌دهد. کلاینت‌هایی که یک اجارهٔ موجود را تمدید می‌کنند، حداقل طول‌عمر باقی‌مانده از اجارهٔ فعلی را دریافت خواهند کرد. از آنجا که اجاره‌ها سریع‌تر منقضی می‌شوند، کارگزار می‌تواند سریع‌تر بازیابی شود یا به‌طور کامل از اتمام ظرفیت استخر جلوگیری کند. .sp نرخ اشغال به‌صورت تعداد پیشوندهای واگذارشدهٔ پیش‌تر تخصیص‌یافته (شامل نشانی در حال تخصیص) تقسیم بر تعداد کل پیشوندها در استخرهایی که امکان تخصیص نشانی از آن‌ها وجود دارد، تعریف می‌شود (یعنی اگر پرس‌وجو عضو محافظ \fBclient\-classes\fP یک استخر نباشد، یا اگر طول پیشوند واگذارشده سازگار نباشد، آن استخر در نظر گرفته نمی‌شود)..SS تخصیص‌دهنده Shared Free Lease Queue .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 این ویژگی که در Kea 3.1.9 افزوده شده است، آزمایشی در نظر گرفته می‌شود و برای استفاده در محیط عملیاتی پشتیبانی نمی‌شود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تخصیص‌دهنده SFLQ می‌تواند برای استخرهای آدرس یا پیشوند (prefix) استفاده شود. برای شفافیت، این ویژگی در ادامه بر اساس استخرهای آدرس توضیح داده شده است، اما به‌طور یکسان در مورد استخرهای پیشوند نیز صدق می‌کند. .UNINDENT .UNINDENT .sp تخصیص‌دهنده Shared Free Lease Queue (SFLQ) برای سایت‌هایی در نظر گرفته شده است که دارای پشتیبان‌های اجاره اشتراکی (MySQL یا PostgreSQL) و زیرشبکه‌هایی با استخرهای آدرس دارای مصرف بالا هستند. در چنین مواردی، پیدا کردن یک آدرس آزاد برای تخصیص‌دهنده تکرارشونده (iterative) یا تصادفی (random) می‌تواند زمان قابل توجهی ببرد، زیرا آن‌ها باید مکرراً بررسی کنند که آیا برای آدرسی که پیشنهاد می‌دهند اجاره معتبری وجود دارد یا خیر. زمانی که استخرهای زیرشبکه رو به اتمام باشند، تعداد بررسی‌ها می‌تواند به اندازه تعداد آدرس‌های موجود در زیرشبکه بالا برود. از آنجا که هر بررسی نیازمند یک پرس‌وجو از پایگاه داده است، این مسئله می‌تواند تأثیر منفی مستقیمی بر زمان پاسخ DHCP برای هر درخواست بگذارد. .sp مشابه تخصیص‌دهنده Free Lease Queue، تخصیص‌دهنده SFLQ تخصیص‌ها و آزادسازی‌های اجاره را ردیابی کرده و فهرستی پویا از آدرس‌های در دسترس برای هر استخر آدرس نگهداری می‌کند. به این فهرست‌ها داده‌های SFLQ گفته می‌شود. این قابلیت امکان انتخاب یک اجاره در دسترس را در زمانی ثابت، صرف‌نظر از میزان مصرف استخرهای زیرشبکه، فراهم می‌کند. داده‌های SFLQ از طریق به‌روزرسانی‌های اختصاصی اجاره که توسط سرور Kea برای اجاره‌های متعلق به زیرشبکه‌های دارای تخصیص SFLQ به کار می‌رود، نگهداری می‌شوند. .sp تفاوت بنیادین میان تخصیص‌دهنده‌های FLQ و SFLQ در این است که تخصیص SFLQ داده‌های SFLQ را به‌جای حافظه محلی سرور Kea، به‌صورت متمرکز در پشتیبان اجاره ذخیره می‌کند. این امر اجازه می‌دهد داده‌ها بین سرورها به اشتراک گذاشته شوند تا همگی درک یکسانی از وضعیت فعلی اجاره‌ها داشته باشند. این ویژگی همچنین به این معناست که داده‌های SFLQ پس از ایجاد پایدار می‌مانند و بنابراین نیازی به ایجاد مجدد آن‌ها هنگام راه‌اندازی یا بازپیکربندی سرور Kea نیست. .sp از آنجا که استخرهای آدرس v6 می‌توانند بسیار بزرگ باشند و معمولاً نرخ مصرف پایینی دارند، تخصیص‌دهنده پیش‌فرض Iterative باید کارایی مناسبی ارائه دهد. تخصیص‌دهنده SFLQ می‌تواند برای استخرهای تفویض پیشوند (prefix delegation) که در آن‌ها تعداد پیشوندها در یک استخر مشخص محدودتر بوده و مصرف استخر می‌تواند بسیار بالا باشد، بسیار مفید واقع شود. .sp تخصیص‌دهنده‌ها برای v6 به‌طور مستقل برای آدرس‌ها و پیشوندهای تفویض‌شده تعیین می‌شوند. تخصیص‌دهنده SFLQ ممکن است برای هر دو نوع استخر استفاده شود. قطعه پیکربندی زیر نشان می‌دهد که چگونه تخصیص‌دهنده‌های SFLQ را برای تمام استخرهای هر دو نوع در یک زیرشبکه انتخاب کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqallocator\(dq: \(dqshared\-flq\(dq, \(dqpd\-allocator\(dq: \(dqshared\-flq\(dq } ] } } .EE .UNINDENT .UNINDENT .sp ملاحظاتی وجود دارد که مدیر سیستم باید پیش از استفاده از این تخصیص‌دهنده در نظر بگیرد. همانند FLQ، تخصیص‌دهنده SFLQ می‌تواند تأثیر شدیدی بر زمان راه‌اندازی و بازپیکربندی سرور بگذارد، زیرا تخصیص‌دهنده باید داده‌های SFLQ را برای هر استخر در هر زیرشبکه‌ای که در آن به کار رفته پر کند. این تأخیرها هم در طول بارگذاری مجدد پیکربندی و هم زمانی که زیرشبکه‌ها با استفاده از \fBlibdhcp_subnet_cmds.so\fP \%<#\:std-ischooklib-libdhcp_subnet_cmds\:.so>\& ایجاد می‌شوند، قابل مشاهده است. برخلاف FLQ، این هزینه‌ها تنها اولین باری رخ می‌دهند که یک زیرشبکه برای استفاده از SFLQ پیکربندی می‌شود یا تغییراتی در بازه‌های آدرس استخرهای آن اعمال می‌گردد. به عبارت دیگر، پس از راه‌اندازی مجدد یا بازپیکربندی، داده‌های SFLQ فقط باید برای استخرهایی ایجاد شوند که از قبل داده‌ای برای آن‌ها وجود ندارد. بنابراین تأثیر آن بر راه‌اندازی‌های مجدد یا بازپیکربندی‌های بعدی زیرشبکه‌هایی که از قبل از SFLQ استفاده می‌کنند، حداقلی است. .sp از آنجا که داده‌های SFLQ در پشتیبان اجاره نگهداری می‌شوند، هزینه ذخیره‌سازی آن بر دوش فضای دیسک سرور پایگاه داده است تا حافظه محلی سرور Kea. مصرف دیسک برای داده‌های SFLQ کسری از مقداری است که از پیش به ازای هر اجاره ذخیره شده است، و با افزایش مصرف استخر، حجم داده‌های SFLQ کاهش می‌یابد. .sp ما توصیه می‌کنیم تخصیص‌دهنده SFLQ تنها پس از بررسی دقیق انتخاب شود. همان‌طور که در بالا اشاره شد، هنگام آغاز استفاده از SFLQ تأثیر بر زمان راه‌اندازی می‌تواند قابل توجه باشد. ایجاد داده‌های اولیه SFLQ برای استخرهای بزرگ (مثلاً بیش از ۵۰۰ هزار آدرس یا پیشوند) ممکن است راه‌اندازی سرور را چند ثانیه یا بیشتر به ازای هر استخر به تأخیر بیندازد. این فرآیند برای استخرهای کوچک‌تر (مثلاً ۶۵ هزار آدرس یا پیشوند) سریع‌تر است، اما در صورت وجود استخرهای زیاد، مجموع زمان آن‌ها انباشته می‌شود. برای کاهش این هزینه راه‌اندازی، توصیه می‌کنیم نوع تخصیص‌دهنده دیگری را در سطح سراسری (global) مشخص کرده و تخصیص‌دهنده SFLQ را در سطح زیرشبکه یا shared\-network تنها برای زیرشبکه‌های گزینش‌شده تعیین نمایید. .sp جنبه مهم دیگری از تخصیص‌دهنده SFLQ وجود دارد که نیازمند توجه است. همان‌طور که پیش‌تر ذکر شد، هنگامی که یک سرور از تخصیص SFLQ برای استخری معین استفاده می‌کند، به‌روزرسانی‌های اختصاصی در پشتیبان را برای نگهداری داده‌های SFLQ به کار می‌گیرد. بنابراین حیاتی است که تمام سرورهایی که در یک پشتیبان اجاره سهیم هستند، در مورد اینکه کدام زیرشبکه‌ها از تخصیص SFLQ استفاده می‌کنند هماهنگ باشند. اگر آن‌ها هماهنگ نباشند، داده‌های SFLQ به‌سرعت نادقیق می‌شوند؛ آدرس‌ها ممکن است آزاد به نظر برسند در حالی که آزاد نیستند و برعکس. در حالت اول، موتور تخصیص یک اجاره موجود را شناسایی کرده و آدرس دیگری را امتحان می‌کند؛ در حالت دوم، اجاره پیشنهاد داده نخواهد شد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اکیداً توصیه می‌شود که پیکربندی زیرشبکه‌ها برای شروع یا توقف استفاده از تخصیص SFLQ در بازه‌های تعمیر و نگهداری (maintenance windows) انجام گیرد تا در حین اعمال تغییرات، سرورها به‌طور فعال به کلاینت‌های آن زیرشبکه‌ها سرویس ندهند. این کار از بروز ناسازگاری در داده‌های SFLQ جلوگیری می‌کند. .sp داده‌های SFLQ بر پایه استخرها ردیابی می‌شوند که در آن‌ها هر استخر دارای یک آدرس شروع و یک آدرس پایان است. تغییرات پیکربندی که بازه آدرس یک استخر را تغییر می‌دهند یا آن را به چندین استخر جدید تقسیم می‌کنند، هنگام اعمال پیکربندی جدید باعث ایجاد داده‌های SFLQ برای استخرهای جدید خواهند شد. .UNINDENT .UNINDENT .sp همان‌طور که قبلاً اشاره شد، زمانی که سرور راه‌اندازی مجدد یا بازپیکربندی می‌شود، روی زیرشبکه‌های خود پیمایش کرده و تخصیص‌دهنده پیکربندی‌شده را برای استخرهای آن زیرشبکه مقداردهی اولیه می‌کند. برای تخصیص‌دهنده SFLQ، این امر موجب می‌شود سرور از پشتیبان اجاره درخواست کند تا داده‌های SFLQ را برای هر استخر موجود در زیرشبکه بسازد. اگر داده‌های SFLQ از قبل برای یک استخر وجود داشته باشد، درخواست فوراً بازمی‌گردد. در غیر این صورت، پس از ایجاد داده‌های SFLQ برای آن استخر بازخواهد گشت. ایجاد داده‌های SFLQ برای یک استخر مشخص، یک عملیات انحصاری (exclusive) است. هنگامی که این عملیات توسط یک سرور آغاز شد، هر درخواستی از سوی دیگر سرورها برای ایجاد داده‌های SFLQ همان استخر مسدود (block) شده و تا زمانی که نخستین درخواست ساخت داده‌های SFLQ استخر را کامل نکند، بازنخواهد گشت. به این ترتیب، فقط یک سرور واقعاً داده‌های SFLQ استخر را ایجاد می‌کند و تمام سرورهای دیگر تا زمانی که داده‌های SFLQ استخر موجود نباشد، از استفاده از آن منع می‌شوند. این رفتار برای حفظ نظم در حین راه‌اندازی‌ها و بازپیکربندی‌های هم‌زمان سرورها در نظر گرفته شده است. .sp در نهایت، موضوع استخرهای هم‌پوشان مطرح است. Kea پیکربندی استخرهایی را که بازه‌های آدرس آن‌ها با استخرهای دیگر هم‌پوشانی دارند، مجاز می‌داند (به Overlapping Pools مراجعه کنید). تخصیص‌دهنده SFLQ به‌طور کلی از این سناریوها پشتیبانی می‌کند، تا زمانی که تمام چنین استخرهایی روی همه سرورها: .INDENT 0.0 .IP \(bu 2 برای استفاده از تخصیص‌دهنده SFLQ پیکربندی شده باشند .IP \(bu 2 از یک نوع اجاره یکسان باشند (همگی \fBTYPE_NA\fP یا همگی \fBTYPE_PD\fP) .IP \(bu 2 برای استخرهای تفویض پیشوند، مقدار delegated_len یکسانی داشته باشند .UNINDENT .sp استفاده از استخرهای تفویض پیشوند هم‌پوشان در هر شرایطی غیر از تعریف یک استخر یکسان در چندین زیرشبکه، توصیه نمی‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 بازیابی اجاره (Lease reclamation) باید با مقداری کم برای پارامتر \fBreclaim\-timer\-wait\-time\fP فعال باشد تا اطمینان حاصل شود که سرور به‌طور مرتب اجاره‌های منقضی‌شده را جمع‌آوری کرده و آن‌ها را از طریق داده‌های SFLQ برای تخصیص در دسترس قرار می‌دهد. اجاره‌های منقضی‌شده تا زمانی که توسط سرور بازیابی نشوند، از نظر تخصیص‌دهنده آزاد محسوب نمی‌شوند. برای جزئیات بیشتر درباره فرآیند بازیابی اجاره، به Lease Reclamation \%<#\:lease-reclamation> مراجعه کنید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تخصیص‌دهنده SFLQ محدود به استفاده در استخرهایی با ظرفیت حداکثر 16777216 آدرس یا پیشوند است. استخرهایی با ظرفیت بزرگ‌تر باعث ایجاد خطای پیکربندی خواهند شد. .UNINDENT .UNINDENT .sp تخصیص‌دهنده SFLQ از \fBadaptive\-lease\-time\-threshold\fP پشتیبانی نمی‌کند..SH "اتصال به پایگاه داده (DATABASE CONNECTIVITY)" .sp سرورهای Kea (\fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>) می‌توانند برای استفاده از بک‌اندهای مختلف پایگاه داده جهت اجاره‌ها (leases)، میزبان‌ها (hosts) و پیکربندی تنظیم شوند. آن‌ها می‌توانند از طریق پارامترهای \fBon\-fail\fP و \fBretry\-on\-startup\fP برای پشتیبانی از بازیابی خودکار در زمان قطع اتصال پیکربندی شوند. (پارامترهای \fBreconnect\-wait\-time\fP و \fBmax\-reconnect\-tries\fP در بخش «Lease Database Configuration» \%<#\:database-configuration4> و «Lease Database Configuration» \%<#\:database-configuration6>\& شرح داده شده‌اند.) .sp درک این موضوع که بازیابی خودکار چگونه و چه زمانی وارد عمل می‌شود بسیار حائز اهمیت است. بازیابی خودکار، در صورت پیکربندی، تنها پس از یک راه‌اندازی یا بازپیکربندی موفقیت‌آمیز که در طول آن اتصال به تمام بک‌اندها با موفقیت برقرار شده باشد، کار می‌کند. .sp در زمان راه‌اندازی سرور، ناتوانی در برقراری اتصال به هر یک از بک‌اندهای پیکربندی‌شده تنها در صورتی یک خطای مهلک در نظر گرفته می‌شود که \fBretry\-on\-startup\fP روی \fBfalse\fP (مقدار پیش‌فرض) تنظیم شده باشد. یک خطای مهلک در گزارش ثبت شده و بر این اساس که پیکربندی در زمان راه‌اندازی باید معتبر باشد، سرور خارج می‌شود. خروج به سیستم‌عامل این امکان را به اسکریپت‌های ناظر (nanny scripts) می‌دهد تا مشکل را تشخیص دهند. اگر \fBretry\-on\-startup\fP روی \fBtrue\fP تنظیم شده باشد، سرور حتی در هنگام راه‌اندازی سرور یا رویدادهای بازپیکربندی نیز تلاش برای اتصال مجدد را آغاز کرده و از اقدام مشخص‌شده در پارامتر \fBon\-fail\fP پیروی خواهد کرد. .sp در طول بازپیکربندی پویا، اتصال تمام بک‌اندها قطع شده و سپس با استفاده از پیکربندی جدید مجدداً برقرار می‌شود. اگر اتصال به هر یک از بک‌اندها برقرار نشود، سرور یک خطای مهلک ثبت می‌کند اما فعال باقی می‌ماند. سرور قادر به پردازش دستورها خواهد بود، اما به کلاینت‌ها سرویس‌دهی نمی‌کند. این امر اجازه می‌دهد تا در صورت نیاز، پیکربندی از طریق دستورهای \fBconfig\-set\fP \%<#\:std-isccmd-config-set> یا \fBremote\-*\fP تصحیح شود. .sp در طول عملیات عادی، در صورتی که اتصال به هر یک از بک‌اندها قطع شود و بازیابی خودکار برای آن بک‌اند فعال باشد، سرور اتصال خود را از بک‌اند مربوطه قطع کرده و سپس تلاش می‌کند مجدداً متصل شود. در طول فرآیند بازیابی، سرور طبق گزینهٔ پیکربندی‌شدهٔ \fBon\-fail\fP سرویس‌دهی به کلاینت‌ها را متوقف می‌کند، اما همچنان به دستورها پاسخ می‌دهد. .sp پارامتر \fBon\-fail\fP اقداماتی را که سرور باید هنگام قطع اتصال انجام دهد، تعیین می‌کند. این پارامتر می‌تواند یکی از مقادیر زیر را داشته باشد: .INDENT 0.0 .IP \(bu 2 \fBstop\-retry\-exit\fP \- نشان می‌دهد که سرور باید هنگام تلاش برای بازیابی اتصال، سرویس‌دهی را متوقف کرده و در صورتی که بازیابی پس از \fBmax\-reconnect\-tries\fP موفقیت‌آمیز نبود، خارج شود. .IP \(bu 2 \fBserve\-retry\-exit\fP \- نشان می‌دهد که سرور نباید هنگام تلاش برای بازیابی اتصال سرویس‌دهی را متوقف کند، اما در صورتی که بازیابی پس از \fBmax\-reconnect\-tries\fP موفقیت‌آمیز نبود، باید خارج شود. .IP \(bu 2 \fBserve\-retry\-continue\fP \- نشان می‌دهد که سرور نباید هنگام تلاش برای بازیابی اتصال سرویس‌دهی را متوقف کند، و در صورتی که بازیابی پس از \fBmax\-reconnect\-tries\fP موفقیت‌آمیز نبود نیز نباید خارج شود. .UNINDENT .sp اگر اتصال به تمام بک‌اندها بازیابی شود، سرور به عملیات عادی بازمی‌گردد. اگر اتصال نتواند بازیابی شود و سرور برای خروج پیکربندی شده باشد، قبل از خاموش شدن یک خطای مهلک صادر می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 3.1.5، بک‌اند اجارهٔ memfile از پارامتر \fBon\-fail\fP پشتیبانی می‌کند. اگر هنگام نوشتن در فایل اجاره، خطایی مانند \(dqno space on device\(dq رخ دهد و \fBon\-fail\fP برابر با \fBstop\-retry\-exit\fP (پیش‌فرض) یا \fBserve\-retry\-exit\fP باشد، سرور بلافاصله خارج خواهد شد. اگر \fBon\-fail\fP برابر با \fBserve\-retry\-continue\fP باشد، سرور فعال باقی می‌ماند، هرچند خطاهای نوشتن تا زمان انجام اقدام اصلاحی ادامه خواهند داشت. مقادیری غیر از صفر برای \fBmax\-reconnect\-tries\fP و \fBreconnect\-wait\-time\fP توسط memfile پشتیبانی نمی‌شوند. .UNINDENT .UNINDENT .sp برای اینکه سرورهای Kea DHCP بتوانند با بک‌اندهای پایگاه داده کار کنند، طرح‌وارهٔ (schema) پایگاه داده باید ایجاد شده و با نسخهٔ سرور Kea مطابقت داشته باشد. اگر بررسی نسخه با شکست مواجه شود و بک‌اند پایگاه داده به‌صورت فقط‌خواندنی (read\-only) پیکربندی نشده باشد، Kea تلاش می‌کند تا طرح‌واره را مقداردهی اولیه کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 سرور Kea به‌طور خودکار اقدام به ارتقای یک طرح‌وارهٔ موجود نمی‌کند؛ چرا که انجام این کار ممکن است کاربران را از فرصت اتخاذ اقدامات احتیاطی، مانند پشتیبان‌گیری از پایگاه داده یا خاموش کردن موقت سرورهای در حال اجرای Kea که در حال حاضر روی پایگاه داده کار می‌کنند، محروم سازد. .UNINDENT .UNINDENT .sp اتصال به سرور پایگاه داده می‌تواند به‌صورت اختیاری توسط TLS محافظت شود. پارامترهای پیکربندی متناظر پایگاه داده برای سرورهای Kea عبارتند از: .INDENT 0.0 .IP \(bu 2 پارامتر \fBtrust\-anchor\fP نام فایل یا مسیر دایرکتوری مرجع صدور گواهی (CA) را مشخص می‌کند. .IP \(bu 2 پارامتر \fBcert\-file\fP نام فایل گواهی کلاینت را مشخص می‌کند. .IP \(bu 2 پارامتر \fBkey\-file\fP نام فایل کلید خصوصی را مشخص می‌کند. .IP \(bu 2 پارامتر \fBssl\-mode\fP حالت SSL را مشخص می‌کند: \fBdisable\fP، \fBprefer\fP، \fBrequire\fP، \fBverify\-ca\fP یا \fBverify\-full\fP\&. .IP \(bu 2 پارامتر \fBcipher\-list\fP فهرست سایفرهای TLS را مشخص می‌کند (نحوهٔ نگارش محتوای این پارامتر در راهنمای سایفرهای OpenSSL شرح داده شده است). .UNINDENT .sp در حال حاضر، میزان پشتیبانی برای هر پایگاه داده به شرح زیر است: .INDENT 0.0 .IP \(bu 2 پایگاه دادهٔ MySQL از تمام این مجموعه، به جز \fBssl\-mode\fP پشتیبانی می‌کند؛ پیکربندی‌های بیشتر باید در تنظیمات محلی MySQL انجام شوند، مانند فهرست ابطال گواهی (CRL)، انتخاب نسخهٔ خاصی از TLS، احراز هویت دوطرفه و غیره. هنگامی که یک اتصال TLS الزامی باشد اما اتصال واقعی به‌صورت متن آشکار (clear text) برقرار شود، یک گزارش خطا ثبت می‌گردد. .IP \(bu 2 پایگاه دادهٔ PostgreSQL از تمام این مجموعه، به جز \fBcipher\-list\fP پشتیبانی می‌کند؛ پیکربندی‌های اضافی باید در کتابخانهٔ کلاینت (libpq) انجام شود. سایر موارد باید در پیکربندی محلی PostgreSQL صورت گیرد. .UNINDENT .sp برای جزئیات بیشتر دربارهٔ ایمن‌سازی اتصال پایگاه داده، به بخش «Securing Database Connections» \%<#\:sec-database-connection>\& مراجعه کنید..SH "انقضای اجاره (LEASE EXPIRATION)" .sp نقش اصلی کارگزار DHCP تخصیص نشانی‌ها و/یا واگذاری پیشوندها به کلاینت‌های DHCP است. این نشانی‌ها و پیشوندها اغلب به عنوان «اجاره‌ها» (\(dqleases\(dq) نامیده می‌شوند. اجاره‌ها معمولاً برای مدت زمان محدودی که به عنوان «طول عمر معتبر» (\(dqvalid lifetime\(dq) شناخته می‌شود به کلاینت‌ها تخصیص می‌یابند. کلاینت‌های DHCP که مایلند به استفاده از اجاره‌های تخصیص‌یافته خود ادامه دهند، آن‌ها را به صورت دوره‌ای با ارسال پیام مناسب به کارگزار DHCP تمدید می‌کنند. کارگزار DHCP زمان تمدید این اجاره‌ها را ثبت کرده و زمان انقضای جدیدی برای آن‌ها محاسبه می‌کند. .sp اگر کلاینت اجاره‌ای را پیش از به پایان رسیدن طول عمر معتبر آن تمدید نکند، اجاره منقضی‌شده تلقی می‌شود. شرایط متعددی وجود دارد که ممکن است کلاینت تمدید اجاره را متوقف کند؛ سناریوهای رایج شامل مواردی است که دستگاه اجراکننده کلاینت برای مدت طولانی خاموش می‌شود یا دستگاه همراه از محدوده شبکه خارج می‌گردد. .sp فرآیندی که کارگزار DHCP طی آن اجاره‌های منقضی‌شده را برای تخصیص مجدد در دسترس قرار می‌دهد، «بازپس‌گیری اجاره» (\(dqlease reclamation\(dq) نامیده می‌شود، و اجاره‌های منقضی‌شده‌ای که از طریق این فرآیند مجدداً در دسترس قرار می‌گیرند «بازپس‌گرفته‌شده» (\(dqreclaimed\(dq) نام دارند. کارگزار DHCP به محض تشخیص انقضای یک اجاره، برای بازپس‌گیری آن تلاش می‌کند. کارگزار چندین راه ممکن برای تشخیص انقضا دارد: ممکن است تلاش کند اجاره‌ای را به یک کلاینت اختصاص دهد اما متوجه شود این اجاره در پایگاه‌داده وجود دارد و منقضی شده است؛ یا می‌تواند به‌طور دوره‌ای پایگاه‌داده اجاره را برای یافتن اجاره‌های منقضی‌شده پرس‌وجو کند. صرف‌نظر از چگونگی تشخیص اجاره منقضی‌شده، این اجاره باید پیش از تخصیص مجدد به یک کلاینت بازپس‌گیری شود. .sp این فصل نحوه پیکربندی کارگزار را برای پرس‌وجوی دوره‌ای اجاره‌های منقضی‌شده و چگونگی به حداقل رساندن تأثیر فرآیند دوره‌ای بازپس‌گیری اجاره بر پاسخگویی کارگزار شرح می‌دهد. در نهایت، «وابستگی اجاره» (\(dqlease affinity\(dq) را توضیح می‌دهد که سازوکاری برای تخصیص همان اجاره به یک کلاینت بازگشتی پس از انقضای اجاره‌اش فراهم می‌آورد. .sp اگرچه تمام مثال‌های پیکربندی در این بخش برای کارگزار DHCPv4 ارائه شده‌اند، اما همین پارامترها را می‌توان برای پیکربندی کارگزار DHCPv6 نیز به کار برد. .SS "بازپس‌گیری اجاره (Lease Reclamation)" .sp بازپس‌گیری اجاره فرآیندی است که طی آن یک اجاره منقضی‌شده برای تخصیص به همان کلاینت یا کلاینتی دیگر در دسترس قرار می‌گیرد. این فرآیند شامل مراحل زیر برای هر اجاره بازپس‌گرفته‌شده است: .INDENT 0.0 .IP \(bu 2 فراخوانی calloutها برای نقاط قلاب \fBlease4_expire\fP یا \fBlease6_expire\fP، در صورتی که کتابخانه‌های قلاب پشتیبانی‌کننده از آن calloutها بارگذاری شده باشند. .IP \(bu 2 به‌روزرسانی DNS؛ یعنی حذف هرگونه مدخل DNS مرتبط با اجاره منقضی‌شده. .IP \(bu 2 به‌روزرسانی اطلاعات اجاره در پایگاه‌داده اجاره‌ها به منظور نشان دادن اینکه اجاره اکنون برای تخصیص مجدد در دسترس است. .IP \(bu 2 به‌روزرسانی شمارنده‌ها در کارگزار؛ فرآیندی که شامل افزایش تعداد اجاره‌های بازپس‌گرفته‌شده و کاهش تعداد نشانی‌های تخصیص‌یافته یا پیشوندهای واگذارشده است. .UNINDENT .sp لطفاً برای مشاهده نحوه پیکربندی به‌روزرسانی‌های DNS در Kea به The DHCP\-DDNS Server \%<#\:dhcp-ddns-server> و برای اطلاعات درباره استفاده از کتابخانه‌های قلاب به Hook Libraries \%<#\:hooks-libraries> مراجعه کنید. .SS "پارامترهای پیکربندی بازپس‌گیری اجاره (Lease Reclamation Configuration Parameters)" .sp فهرست زیر تمام پارامترهای پیکربندی مربوط به پردازش اجاره‌های منقضی‌شده را به همراه مقادیر پیش‌فرض آن‌ها ارائه می‌دهد: .INDENT 0.0 .IP \(bu 2 \fBreclaim\-timer\-wait\-time\fP \- این پارامتر فاصله‌های زمانی بین اتمام چرخه بازپس‌گیری قبلی و شروع چرخه بعدی را تنظیم می‌کند. بر حسب ثانیه مشخص می‌شود؛ مقدار پیش‌فرض 10 است. .IP \(bu 2 \fBflush\-reclaimed\-timer\-wait\-time\fP \- این پارامتر مشخص می‌کند کارگزار با چه تواتری روند بازپس‌گیری اجاره را آغاز می‌کند. بر حسب ثانیه بیان می‌شود؛ مقدار پیش‌فرض 25 است. اگر هر دو پارامتر \fBflush\-reclaimed\-timer\-wait\-time\fP و \fBhold\-reclaimed\-time\fP غیر صفر باشند، هنگامی که کلاینت پیام release ارسال می‌کند، اجاره به جای حذف شدن از فضای ذخیره‌سازی اجاره‌ها، منقضی می‌شود. .IP \(bu 2 \fBhold\-reclaimed\-time\fP \- این پارامتر تعیین می‌کند که اجاره پس از بازپس‌گیری تا چه مدت باید نگهداری شود. مقدار غیر صفر این پارامتر، قابلیت وابستگی اجاره را فعال می‌کند. بر حسب ثانیه بیان می‌شود؛ مقدار پیش‌فرض 3600 است. اگر هر دو پارامتر \fBflush\-reclaimed\-timer\-wait\-time\fP و \fBhold\-reclaimed\-time\fP غیر صفر باشند، هنگامی که کلاینت پیام release ارسال می‌کند، اجاره به جای حذف شدن از فضای ذخیره‌سازی اجاره‌ها، منقضی می‌شود. .IP \(bu 2 \fBmax\-reclaim\-leases\fP \- این پارامتر حداکثر تعداد اجاره‌های بازپس‌گرفته‌شده‌ای را که می‌توان در یک نوبت پردازش کرد مشخص می‌کند. مقدار صفر به معنی نامحدود است (یعنی پردازش تمام اجاره‌های بازپس‌گرفته‌شده). مقدار پیش‌فرض 100 است. .IP \(bu 2 \fBmax\-reclaim\-time\fP \- این پارامتر حد بالایی برای مدت زمانی که یک فرآیند بازپس‌گیری اجاره می‌تواند طول بکشد تعیین می‌کند. مقدار صفر به معنای نبود محدودیت زمانی است. بر حسب میلی‌ثانیه بیان می‌شود؛ مقدار پیش‌فرض 250 است. .IP \(bu 2 \fBunwarned\-reclaim\-cycles\fP \- در صورت تعیین محدودیت‌های بازپس‌گیری اجاره (\fBmax\-reclaim\-leases\fP و/یا \fBmax\-reclaim\-time\fP)، تحت شرایط خاصی ممکن است کارگزار نتواند اجاره‌های آماده بازپس‌گیری را با سرعت کافی پردازش کند. این پارامتر مشخص می‌کند چند چرخه پاک‌سازی متوالی باید با باقی ماندن اجاره‌های در صف پردازش خاتمه یابند پیش از آنکه هشداری چاپ شود. مقدار پیش‌فرض 5 چرخه است. .UNINDENT .sp این پارامترها با جزئیات بیشتر در ادامه این فصل توضیح داده شده‌اند. .sp در صورتی که پارامتری صراحتاً در پیکربندی مشخص نشده باشد، مقدار پیش‌فرض آن به کار می‌رود. اگر نگاشت \fBexpired\-leases\-processing\fP به‌طور کامل در پیکربندی حذف شده باشد، مقادیر پیش‌فرض برای تمام پارامترهای فهرست‌شده در بالا استفاده می‌شوند. .SS "پیکربندی بازپس‌گیری اجاره (Configuring Lease Reclamation)" .sp برنامه Kea را می‌توان به گونه‌ای پیکربندی کرد که اجاره‌های منقضی‌شده را به‌طور دوره‌ای شناسایی و بازپس‌گیری کند. در طول این فرآیند، مدخل‌های اجاره در پایگاه‌داده اصلاح یا حذف می‌شوند. در حین وقوع این امر، کارگزار پیام‌های ورودی DHCP را پردازش نمی‌کند تا از بروز تداخل دسترسی هم‌روند به اطلاعات پایگاه‌داده جلوگیری شود. در نتیجه، کارگزار در هنگام انجام بازپس‌گیری اجاره پاسخگو نخواهد بود و پرس‌وجوهای DHCP انباشته می‌شوند؛ پاسخ‌ها پس از اتمام چرخه بازپس‌گیری اجاره ارسال خواهند شد. .sp در پیاده‌سازی‌هایی که زمان پاسخ‌دهی در آن‌ها حیاتی است، مدیران سیستم ممکن است تمایل داشته باشند وقفه‌های سرویس‌دهی ناشی از بازپس‌گیری اجاره را به حداقل برسانند. به این منظور، Kea پارامترهای پیکربندی متعددی برای کنترل بسامد چرخه‌های بازپس‌گیری اجاره، حداکثر تعداد اجاره‌های پردازش‌شده در یک چرخه و حداکثر مدت زمانی که یک چرخه بازپس‌گیری اجازه دارد پیش از قطع شدن اجرا شود ارائه می‌دهد. مثال‌های زیر نحوه استفاده از این پارامترها را نشان می‌دهند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqexpired\-leases\-processing\(dq: { \(dqreclaim\-timer\-wait\-time\(dq: 5, \(dqmax\-reclaim\-leases\(dq: 0, \(dqmax\-reclaim\-time\(dq: 0 } } } .EE .UNINDENT .UNINDENT .sp پارامتر اول بر حسب ثانیه بیان می‌شود و فاصله زمانی بین دو چرخه متوالی بازپس‌گیری اجاره را مشخص می‌کند. این موضوع با نمودار زیر توضیح داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX | c1 | | c2 | |c3| | c4 | |<\-\-\-\->|<\-\-\-\-\-\-\-\-\-\->|<\-\->|<\-\-\-\-\-\-\-\-\-\->|<>|<\-\-\-\-\-\-\-\-\-\->|<\-\->|<\-\- \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-> | | 5s | | 5s | | 5s | | time .EE .UNINDENT .UNINDENT .sp این نمودار چهار چرخه بازپس‌گیری اجاره (c1 تا c4) با مدت زمان متغیر را نشان می‌دهد. مدت زمان چرخه بازپس‌گیری به تعداد اجاره‌های منقضی‌شده شناسایی و پردازش‌شده در آن چرخه خاص بستگی دارد. این مدت زمان معمولاً به میزان قابل توجهی کوتاه‌تر از فاصله بین چرخه‌ها است. .sp با توجه به \fBreclaim\-timer\-wait\-time\fP، کارگزار فاصله‌های زمانی ثابت پنج ثانیه‌ای بین پایان یک چرخه و شروع چرخه بعدی حفظ می‌کند. این امر وجود دوره‌های ۵ ثانیه‌ای را تضمین می‌کند که طی آن کارگزار به پرس‌وجوهای DHCP پاسخگو باقی می‌ماند و بازپس‌گیری اجاره را انجام نمی‌دهد. مقادیر \fBmax\-reclaim\-leases\fP و \fBmax\-reclaim\-time\fP روی 0 تنظیم شده‌اند که هیچ محدودیتی بر حداکثر تعداد اجاره‌های بازپس‌گرفته‌شده در چرخه مشخص یا حداکثر مدت زمان هر چرخه اعمال نمی‌کند. .sp در پیاده‌سازی‌هایی با بهره‌برداری بالای مخزن اجاره (lease pool)، طول عمرهای معتبر نسبتاً کوتاه، و کلاینت‌هایی با قطع ارتباط مکرر که باعث انقضای اجاره‌ها می‌شوند، ممکن است تعداد اجاره‌های منقضی‌شده نیازمند بازپس‌گیری در هر زمان معین به طور چشمگیری افزایش یابد. در این حالت، اغلب مطلوب است که محدودیت‌هایی بر حداکثر مدت زمان یک چرخه بازپس‌گیری یا حداکثر تعداد اجاره‌های بازپس‌گرفته‌شده در یک چرخه اعمال شود. پیکربندی زیر نشان می‌دهد چگونه می‌توان این کار را انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqexpired\-leases\-processing\(dq: { \(dqreclaim\-timer\-wait\-time\(dq: 3, \(dqmax\-reclaim\-leases\(dq: 100, \(dqmax\-reclaim\-time\(dq: 50, \(dqunwarned\-reclaim\-cycles\(dq: 10 } } } .EE .UNINDENT .UNINDENT .sp در این مثال، پارامتر \fBmax\-reclaim\-leases\fP تعداد اجاره‌های بازپس‌گرفته‌شده در یک چرخه واحد را به 100 محدود می‌کند و \fBmax\-reclaim\-time\fP حداکثر مدت زمان هر چرخه را به 50 میلی‌ثانیه محدود می‌سازد. در صورت رسیدن به هر یک از این محدودیت‌ها، چرخه بازپس‌گیری اجاره متوقف خواهد شد. بازپس‌گیری هرگونه اجاره بازپس‌گرفته‌نشده در چرخه‌های بعدی انجام خواهد گرفت. .sp نمودار زیر رفتار سامانه را در حضور تعداد زیادی اجاره منقضی‌شده، زمانی که محدودیت‌ها بر چرخه‌های بازپس‌گیری اعمال شده‌اند، نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX | c1 | | c2 | | c3 | | c4 | |<\-\->|<\-\-\-\-\-\-\-\-\-\-\-\-\-\->|<\-\->|<\-\-\-\-\-\-\-\-\-\-\-\-\-\->|<\-\->|<\-\-\-\-\-\-\-\-\-\-\-\-\-\->|<\-\->|<\-\- \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-> |50ms| 3s |50ms| 3s |50ms| 3s |50ms| time .EE .UNINDENT .UNINDENT .sp در این حالت، اگر هر چرخه بازپس‌گیری بیش از 50 میلی‌ثانیه طول بکشد، بر اساس مقدار \fBmax\-reclaim\-time\fP متوقف می‌شود. این موضوع باعث برابری مدت زمان تمام چرخه‌های بازپس‌گیری در طول زمان می‌گردد. در این مثال، به محدودیت حداکثر 100 اجاره دسترسی پیدا نمی‌شود. این سناریو ممکن است زمانی رخ دهد که تراکنش‌های پایگاه‌داده یا calloutها در کتابخانه‌های قلاب متصل به کارگزار کند باشند. با این حال، مقادیر انتخاب‌شده برای حداکثر تعداد اجاره‌ها یا حداکثر زمان چرخه به شدت به نوع پیاده‌سازی، backend پایگاه‌داده اجاره مورد استفاده، کتابخانه‌های قلاب و غیره وابسته است. مدیران سیستم ممکن است برای تنظیم سامانه متناسب با شرایط استقرار خود، نیاز به آزمون و ارزیابی داشته باشند. .sp درک این نکته حائز اهمیت است که با اعمال این محدودیت‌ها، این خطر وجود دارد که اجاره‌های منقضی‌شده سریع‌تر از توانایی کارگزار در بازپس‌گیری آن‌ها انباشته شوند. اگر کارگزار با موج موقتی از انقضاها مواجه باشد مشکلی ایجاد نخواهد شد، چرا که می‌تواند به مرور زمان آن‌ها را پردازش کند. با این حال، اگر اجاره‌ها برای مدت طولانی با نرخ بالایی منقضی شوند، اجاره‌های بازپس‌گرفته‌نشده در پایگاه‌داده انباشته خواهند شد. به منظور مطلع ساختن مدیر سیستم از این موضوع که پیکربندی فعلی پاسخگوی نیازهای بازپس‌گیری اجاره‌های منقضی‌شده نیست، کارگزار در صورتی که نتواند تمام اجاره‌ها را طی چندین چرخه بازپس‌گیری کند، یک پیام هشدار در وقایع‌نگاری (log) صادر می‌کند. تعداد چرخه‌هایی که پس از آن‌ها چنین هشداری صادر می‌شود با پارامتر پیکربندی \fBunwarned\-reclaim\-cycles\fP تعیین می‌گردد. .sp تنظیم \fBreclaim\-timer\-wait\-time\fP روی 0، بازپس‌گیری دوره‌ای اجاره‌های منقضی‌شده را غیرفعال می‌کند..SS "پیکربندی تمایل اجاره (Configuring Lease Affinity)" .sp فرض کنید یک لپ‌تاپ پس از مدتی عدم فعالیت کاربر به حالت خواب (sleep mode) می‌رود. در حالی که لپ‌تاپ در حالت خواب است، کلاینت DHCP آن اجاره‌های دریافت‌شده از سرور را تمدید نمی‌کند و این اجاره‌ها در نهایت منقضی خواهند شد. هنگامی که لپ‌تاپ بیدار می‌شود، اغلب مطلوب است که همچنان به استفاده از آدرس‌های IP قبلیِ اختصاص‌یافته به خود ادامه دهد. برای تسهیل این امر، سرور باید کلاینت‌های بازگشتی را با اجاره‌های منقضی‌شدهٔ آن‌ها مرتبط سازد. هنگامی که کلاینت بازمی‌گردد، سرور ابتدا وجود آن اجاره‌ها را بررسی کرده و در صورتی که به کلاینت دیگری اختصاص نیافته باشند، آن‌ها را دوباره اختصاص می‌دهد. توانایی سرور در اختصاص مجدد همان اجاره به یک کلاینت بازگشتی، \(dqتمایل اجاره\(dq (lease affinity) نامیده می‌شود. .sp هنگامی که تمایل اجاره فعال باشد (یعنی زمانی که \fBhold\-reclaimed\-time\fP روی مقداری بزرگ‌تر از صفر پیکربندی شده باشد)، سرور همچنان اجاره‌ها را بر اساس پارامترهای شرح‌داده‌شده در بخش پیکربندی بازپس‌گیری اجاره (Configuring Lease Reclamation) بازپس می‌گیرد، اما اجاره‌های بازپس‌گرفته‌شده به جای حذف شدن، برای مدت‌زمان مشخصی در پایگاه داده نگهداری می‌شوند. اگر هر دو پارامتر \fBflush\-reclaimed\-timer\-wait\-time\fP و \fBhold\-reclaimed\-time\fP بزرگ‌تر از صفر باشند، زمانی که کلاینت یک پیام آزادسازی (release) ارسال می‌کند، اجاره به جای حذف شدن از فضای ذخیره‌سازی اجاره‌ها، بلافاصله منقضی می‌شود. هنگامی که کلاینت بازمی‌گردد، سرور ابتدا بررسی می‌کند که آیا اجارهٔ بازپس‌گرفته‌شده‌ای مرتبط با این کلاینت وجود دارد یا خیر و سپس در صورت امکان آن‌ها را دوباره اختصاص می‌دهد. با این حال، توجه به این نکته مهم است که هر اجارهٔ بازپس‌گرفته‌شده در صورتی که کلاینت دیگری مشخصاً آن را درخواست کند، ممکن است به آن کلاینت اختصاص یابد. بنابراین، تمایل اجاره تضمین نمی‌کند که اجارهٔ بازپس‌گرفته‌شده در دسترس کلاینتی که قبلاً از آن استفاده می‌کرده قرار گیرد؛ بلکه صرفاً احتمال اختصاص همان اجاره به کلاینت را افزایش می‌دهد. اگر استخر اجاره (lease pool) کوچک باشد \- به‌ویژه در DHCPv4 که فضای آدرس محدود است \- احتمال این‌که اجارهٔ منقضی‌شده به کلاینت دیگری اختصاص یابد افزایش می‌یابد. .sp پیکربندی زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqexpired\-leases\-processing\(dq: { \(dqreclaim\-timer\-wait\-time\(dq: 3, \(dqhold\-reclaimed\-time\(dq: 1800, \(dqflush\-reclaimed\-timer\-wait\-time\(dq: 5 }, ... } .EE .UNINDENT .UNINDENT .sp پارامتر \fBhold\-reclaimed\-time\fP مشخص می‌کند که یک اجارهٔ بازپس‌گرفته‌شده چند ثانیه پس از انقضا باید برای تخصیص مجدد به همان کلاینت در پایگاه داده نگهداری شود. در مثال فوق، اجاره‌های بازپس‌گرفته‌شده به مدت ۳۰ دقیقه (۱۸۰۰ ثانیه) پس از انقضایشان نگهداری می‌شوند. در طول این مدت، به احتمال زیاد سرور قادر خواهد بود همان اجاره را به کلاینت بازگشتی اختصاص دهد، مگر اینکه کلاینت دیگری صراحتاً این اجاره را درخواست کند و سرور آن را واگذار نماید. .sp سرور باید به‌صورت دوره‌ای اجاره‌های بازپس‌گرفته‌شده‌ای را که زمان مشخص‌شده توسط \fBhold\-reclaimed\-time\fP برای آن‌ها سپری شده است، حذف کند. پارامتر \fBflush\-reclaimed\-timer\-wait\-time\fP کنترل می‌کند که سرور هر چند وقت یک‌بار این‌گونه اجاره‌ها را حذف نماید. در مثال ارائه‌شده در بالا، سرور پنج ثانیه پس از تکمیل تلاش قبلی برای حذف، اقدام به حذف چنین اجاره‌هایی می‌کند. تنظیم این مقدار روی 0 تمایل اجاره را غیرفعال می‌کند، به این معنی که اجاره‌ها به محض بازپس‌گیری از پایگاه دادهٔ اجاره‌ها حذف می‌شوند. در صورت فعال بودن تمایل اجاره، توصیه می‌شود که \fBhold\-reclaimed\-time\fP روی مقداری به‌مراتب بالاتر از \fBreclaim\-timer\-wait\-time\fP تنظیم شود، زیرا حذف به‌موقع اجاره‌های منقضی/بازپس‌گرفته‌شده اهمیت کمتری نسبت به خودِ فرایند حذف دارد که می‌تواند بر پاسخ‌دهی سرور تأثیر بگذارد. .sp هیچ تضمینی وجود ندارد که تمایل اجاره همیشه کار کند؛ اگر سرور با کمبود آدرس مواجه شود، آدرس‌های منقضی‌شده را به کلاینت‌های جدید اختصاص خواهد داد. همچنین، کلاینت‌ها می‌توانند آدرس‌های خاصی را درخواست کنند و سرور در صورت امکان سعی می‌کند چنین درخواست‌هایی را برآورده سازد. مدیرانی که می‌خواهند مطمئن شوند یک کلاینت آدرس خود را حتی پس از دوره‌های عدم فعالیت حفظ می‌کند، باید استفاده از رزروهای میزبان (host reservations) یا اجاره‌هایی با طول عمر بسیار طولانی را در نظر بگیرند. .SS "بازپس‌گیری اجاره‌های منقضی‌شده از طریق فرمان (Reclaiming Expired Leases via Command)" .sp دستور \fBleases\-reclaim\fP \%<#\:std-isccmd-leases-reclaim> می‌تواند برای راه‌اندازی بازپس‌گیری اجاره در هر زمان استفاده شود. لطفاً برای جزئیات مربوط به نحوهٔ استفاده از این دستور، به بخش The leases\-reclaim Command \%<#\:command-leases-reclaim> مراجعه کنید. .SH "مدیریت ازدحام (CONGESTION HANDLING)" .SS "ازدحام چیست؟ (What is Congestion?)" .sp ازدحام زمانی رخ می‌دهد که پرس‌وجوهای کلاینت‌ها با سرعتی فراتر از توان پردازش آن‌ها به سرورها سرازیر شوند. در نتیجه، سرورها شروع به انباشت صف معوقه‌ای از پرس‌وجوهای معلق می‌کنند. هرچه نرخ بالای ترافیک بیشتر ادامه یابد، سرورها عقب‌تر می‌مانند. بسته به پیاده‌سازی‌های کلاینت، کلاینت‌هایی که موفق به دریافت اجاره نمی‌شوند یا منصرف می‌شوند یا به‌سادگی برای همیشه به تلاش مجدد ادامه می‌دهند. در حالت اول، سرور ممکن است در نهایت بازیابی شود، اما حالت دوم یک چرخه معیوب است که سرور قادر به رهایی از آن نیست. .sp ازدحام معمولاً زمانی رخ می‌دهد که یک رخداد شبکه‌ای سبب شود تعداد بیش از حد زیادی از کلاینت‌ها به‌طور هم‌زمان به اجاره نیاز پیدا کنند؛ مانند بازیابی پس از قطعی شبکه. در یک استقرار خوب برنامه‌ریزی‌شده، تعداد و ظرفیت سرورها با حداکثر بار مورد انتظار کلاینت‌ها تطابق داده می‌شود. اگر بار به‌طور معمول بیش از حد سنگین باشد، باید در استقرار بازنگری شود. .sp هدف از مدیریت ازدحام، کمک به سرورها در کاهش اثر پیک ترافیک با پاسخ‌گویی به بیشترین تعداد ممکن از مرتبط‌ترین درخواست‌ها است تا زمانی که ازدحام فروکش کند. .SS "پیکربندی مدیریت ازدحام (Configuring Congestion Handling)" .sp مدیریت ازدحام این امکان را فراهم می‌کند که سرور به‌گونه‌ای پیکربندی شود تا از یک رشته (thread) جداگانه برای خواندن بسته‌ها از بافرهای سوکت رابط استفاده کند. با خواندن بسته‌ها از بافرها توسط این رشته، آن‌ها به یک صف بستهٔ داخلی اضافه می‌شوند و رشتهٔ برنامهٔ اصلی سرور، بسته‌ها را به جای بافرهای سوکت از این صف پردازش می‌کند. با ساختاربندی به این روش، لایه‌ای قابل‌پیکربندی معرفی شده است که می‌تواند در مورد اینکه کدام بسته‌ها پردازش شوند، چگونه ذخیره گردند، و ترتیبی که توسط سرور پردازش می‌شوند تصمیم‌گیری کند. .sp پیاده‌سازی پیش‌فرض صف بسته برای هر دو \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> یک بافر حلقوی (ring buffer) ساده است. هنگامی که ظرفیت آن تکمیل شود، بسته‌های جدید با دور انداختن بسته‌ها از ابتدای صف، به انتهای صف اضافه می‌شوند. به جای دور انداختن همیشگی جدیدترین بسته‌ها، Kea اکنون همواره قدیمی‌ترین بسته‌ها را دور می‌اندازد. ظرفیت بافر، یعنی حداکثر تعداد بسته‌هایی که بافر می‌تواند در بر گیرد، قابل‌پیکربندی است. یک نقطهٔ شروع منطقی این است که ظرفیت را با تعداد اجاره‌ها بر ثانیه که یک نصب خاص از Kea می‌تواند مدیریت کند، تطبیق داد. این رقم بسته به مشخصات هر استقرار بسیار متغیر است. .sp از آنجا که هیچ الگوریتم یگانه‌ای وجود ندارد که بتواند پویایی همهٔ سایت‌ها را به بهترین شکل مدیریت کند، و با گذشت زمان رویکردهای جدیدی توسعه خواهند یافت، صف بسته به صورت یک پلاگین پیاده‌سازی شده است که می‌تواند با یک پیاده‌سازی صف سفارشی از طریق یک کتابخانهٔ قلاب (hook library) جایگزین شود. این امر باید آزمایش راه‌حل‌های اختصاصی را برای افراد علاقه‌مند ساده سازد. (توسعه‌دهندگان می‌توانند به \fBisc::dhcp::PacketQueue\fP و \fBisc::dhcp::PacketQueueMgr\fP که در راهنمای توسعه‌دهندهٔ Kea (Kea Developer\(aqs Guide) \%\& شرح داده شده‌اند مراجعه کنند.) .sp رفتار صف بسته در هر دو سرور \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> از طریق یک عنصر پیکربندی اختیاری در بالاترین سطح، یعنی \fBdhcp\-queue\-control\fP پیکربندی می‌شود. حذف این عنصر صف‌بندی بسته‌ها را غیرفعال می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqdhcp\-queue\-control\(dq: { \(dqenable\-queue\(dq: true, // true|false \(dqqueue\-type\(dq: \(dqqueue type\(dq, \(dqcapacity\(dq : 256 // n packets } .EE .UNINDENT .UNINDENT .sp که در آن: .INDENT 0.0 .IP \(bu 2 \fBenable\-queue\fP \- صف‌بندی بسته‌ها را فعال یا غیرفعال می‌کند. هنگامی که مقدار آن \fBtrue\fP باشد، سرور بسته‌ها را از صف بسته که توسط یک رشتهٔ جداگانه پر می‌شود پردازش می‌کند. هنگامی که \fBfalse\fP باشد، سرور بسته‌ها را مستقیماً از بافرهای سوکت در رشتهٔ اصلی پردازش می‌نماید. این گزینه به‌طور پیش‌فرض غیرفعال (\fBfalse\fP) است. .IP \(bu 2 \fBqueue\-type\fP \- نام پیاده‌سازی صف مورد استفاده. این مقدار به این منظور وجود دارد که بتوان پیاده‌سازی‌های سفارشی را (از طریق یک کتابخانهٔ قلاب) ثبت و سپس انتخاب کرد. یک پیاده‌سازی پیش‌فرض صف بسته وجود دارد که هنگام راه‌اندازی سرور از پیش ثبت شده است: \(dqkea\-ring4\(dq برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \(dqkea\-ring6\(dq برای \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>\&. .IP \(bu 2 \fBcapacity\fP \- این پارامتر حداکثر تعداد بسته‌هایی است که صف می‌تواند پیش از دور انداختن بسته‌ها در خود نگه دارد. مقدار بهینه برای این گزینه به‌شدت به ساختار سایت وابسته است. مقدار پیش‌فرض برای هر دو \(dqkea\-ring4\(dq و \(dqkea\-ring6\(dq برابر با 64 است. .UNINDENT .sp مثال زیر صف بستهٔ پیش‌فرض را برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> با ظرفیت صف 250 بسته فعال می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqdhcp\-queue\-control\(dq: { \(dqenable\-queue\(dq: true, \(dqqueue\-type\(dq: \(dqkea\-ring4\(dq, \(dqcapacity\(dq : 250 }, ... } .EE .UNINDENT .UNINDENT .sp مثال زیر صف بستهٔ پیش‌فرض را برای \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> با ظرفیت صف 300 بسته فعال می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqdhcp\-queue\-control\(dq: { \(dqenable\-queue\(dq: true, \(dqqueue\-type\(dq: \(dqkea\-ring6\(dq, \(dqcapacity\(dq : 300 }, ... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مدیریت ازدحام در حال حاضر با چندرشتگی (multi\-threading) ناسازگار است؛ هنگامی که هر دو فعال باشند، مدیریت ازدحام در سکوت غیرفعال می‌شود. .UNINDENT .UNINDENT.SH "کارساز DHCP-DDNS (THE DHCP-DDNS SERVER)" .SS "نمای کلی (Overview)" .sp کارساز DHCP\-DDNS (\fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>، که به‌طور غیررسمی با نام D2 شناخته می‌شود) سمت کلاینت پروتکل DNS پویا (DDNS، تعریف‌شده در RFC 2136 \%) را به نیابت از کارسازهای DHCPv4 و DHCPv6 (به‌ترتیب \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>) مدیریت می‌کند. کارسازهای DHCP بر اساس رویدادهای تغییر اجاره در DHCP، درخواست‌های به‌روزرسانی DDNS را که با عنوان درخواست‌های تغییر نام (NameChangeRequests یا NCRs) شناخته می‌شوند ایجاد کرده و سپس به D2 ارسال می‌کنند. D2 تلاش می‌کند هر درخواست را با کارساز(های) DNS مناسب تطبیق دهد و تبادل لازم را با آن کارسازها برای به‌روزرسانی داده‌های DNS به انجام برساند. .sp کتابخانهٔ قلاب (hook) در Kea به نام \fBlibdhcp_ddns_tuning.so\fP \%<#\:std-ischooklib-libdhcp_ddns_tuning\:.so> این امکان را برای هر دو کارساز \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> فراهم می‌کند تا نام‌های میزبان را به‌صورت رویه‌ای بر اساس یک عبارت تولید کنند، به‌روزرسانی‌های DDNS را به‌ازای هر کلاینت نادیده بگیرند، یا جنبه‌های مختلف به‌روزرسانی DNS را به‌دقت تنظیم نمایند. لطفاً برای گزینه‌های پیکربندی به مستندات libdhcp_ddns_tuning.so: DDNS Tuning \%<#\:hooks-ddns-tuning> مراجعه کنید. .SS "انتخاب کارساز DNS (DNS Server Selection)" .sp برای مطابقت دادن یک درخواست با کارسازهای DNS مناسب، D2 باید کاتالوگی از کارسازها داشته باشد تا از میان آن‌ها انتخاب کند. در واقع، D2 دو کاتالوگ از این دست دارد: یکی برای DNS مستقیم (forward) و دیگری برای DNS معکوس (reverse)؛ به این کاتالوگ‌ها «فهرست‌های دامنه‌های DDNS» (\(dqDDNS domain lists\(dq) گفته می‌شود. هر فهرست از یک یا چند دامنهٔ نام‌گذاری‌شدهٔ DDNS تشکیل شده است. علاوه بر این، هر دامنهٔ DDNS فهرستی از یک یا چند کارساز DNS دارد که داده‌های DNS آن دامنه را منتشر می‌کنند. .sp هنگام انجام تطبیق دامنهٔ مستقیم، D2 نام دامنهٔ کاملاً مشخص (FQDN) موجود در درخواست را با نام هر یک از دامنه‌های DDNS مستقیم در کاتالوگ خود مقایسه می‌کند. دامنه‌ای که نام آن با طولانی‌ترین بخش از FQDN مطابقت داشته باشد، بهترین تطابق در نظر گرفته می‌شود. به عنوان مثال، اگر FQDN برابر با \(dqmyhost.sample.example.com.\(dq باشد و دو دامنهٔ مستقیم در کاتالوگ به نام‌های \(dqsample.example.com.\(dq و \(dqexample.com.\(dq وجود داشته باشد، مورد اول بهترین تطابق محسوب می‌شود. در برخی موارد، ممکن است یافتن تطابق مناسب امکان‌پذیر نباشد. با فرض وجود همان دو دامنهٔ مستقیم، هیچ تطابقی برای FQDN با مقدار \(dqbogus.net\(dq وجود نخواهد داشت، بنابراین درخواست رد خواهد شد. در نهایت، اگر هیچ دامنهٔ DDNS مستقیمی تعریف نشده باشد، D2 به‌سادگی بخش به‌روزرسانی مستقیم درخواست‌ها را نادیده می‌گیرد. .sp هنگام انجام تطبیق دامنهٔ معکوس، D2 یک FQDN معکوس از آدرس اجاره در درخواست می‌سازد و آن را با نام هر دامنهٔ DDNS معکوس مقایسه می‌کند. مجدداً، دامنه‌ای که نام آن با طولانی‌ترین بخش از FQDN مطابقت داشته باشد، بهترین تطابق به شمار می‌آید. برای نمونه، اگر آدرس اجاره \(dq172.16.1.40\(dq باشد و دو دامنهٔ معکوس در کاتالوگ با نام‌های \(dq1.16.172.in\-addr.arpa.\(dq و \(dq16.172.in\-addr.arpa\(dq وجود داشته باشند، مورد اول بهترین تطابق است. همانند تطبیق مستقیم، ممکن است D2 تطابق مناسبی پیدا نکند. با فرض وجود همان دو دامنه، هیچ تطابقی برای آدرس اجارهٔ \(dq192.168.1.50\(dq وجود نخواهد داشت و درخواست رد خواهد شد. همانند تطبیق دامنهٔ مستقیم، اگر هیچ دامنهٔ DDNS معکوسی تعریف نشده باشد، D2 به‌سادگی بخش به‌روزرسانی معکوس درخواست‌ها را نادیده می‌گیرد. .SS "رفع تعارض (Conflict Resolution)" .sp D2 راهبرد رفع تعارض تجویز‌شده توسط RFC 4703 \%\& را پیاده‌سازی می‌کند. هدف از رفع تعارض، جلوگیری از نگاشت هم‌زمان کلاینت‌های مختلف به یک FQDN یکسان است. برای ممکن ساختن این امر، RFC الزامی می‌داند که مدخل‌های DNS مستقیم برای یک FQDN مشخص باید همراه با یک رکورد منبع (RR) از نوع DHCID باشند. این رکورد شامل یک شناسهٔ کلاینت است که کلاینت متعلق به آن نام را به‌صورت یکتا مشخص می‌کند. علاوه بر این، هر به‌روزرسان DNS که بخواهد مدخل‌های مستقیم موجود برای یک FQDN را به‌روزرسانی یا حذف کند، تنها در صورتی مجاز به انجام این کار است که کلاینت آن با رکورد DHCID RR همخوانی داشته باشد. .sp به عبارت دیگر، DHCID RR یک FQDN را به کلاینتی که به آن تعلق دارد نگاشت می‌کند و پس از آن، تغییرات در آن نگاشت تنها توسط آن کلاینت یا به درخواست آن امکان‌پذیر است. .sp رفع تعارض می‌تواند به‌طور غیرمستقیم از طریق پارامتر پیکربندی \fBddns\-use\-conflict\-resolution\fP که توسط هر دو کارساز \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>\& پشتیبانی می‌شود، فعال یا غیرفعال گردد. این کارسازها از این پارامتر برای تنظیم یک پرچم در هر NameChangeRequest ارسالی استفاده می‌کنند که به D2 اعلام می‌کند آیا باید رفع تعارض برای آن درخواست اعمال شود یا خیر. به‌طور پیش‌فرض، رفع تعارض فعال است. برای جزئیات بیشتر، لطفاً به مباحث مربوط به \fBddns\-use\-conflict\-resolution\fP در DDNS for DHCPv4 \%<#\:dhcp4-ddns-config> و DDNS for DHCPv6 \%<#\:dhcp6-ddns-config>\& مراجعه کنید. .sp هنگامی که رفع تعارض غیرفعال باشد، D2 همچنان رکوردهای DHCID RR را اضافه می‌کند اما از آن‌ها برای اعمال مالکیت کلاینت بر مدخل‌های DNS استفاده نمی‌کند. غیرفعال کردن آن تنها پس از بررسی دقیق باید انجام شود. .SS "محیط‌های دو پشته‌ای (Dual\-Stack Environments)" .sp بخش ۵.۲ از RFC 4703 \% مسائلی را توصیف می‌کند که ممکن است با کلاینت‌های دو پشته‌ای (dual\-stack) رخ دهد. این‌ها کلاینت‌هایی هستند که تمایل دارند هر دو نگاشت IPv4 و IPv6 را برای یک FQDN یکسان داشته باشند. برای عملکرد صحیح، کلاینت‌ها باید DUID مربوط به IPv6 خود را در گزینهٔ شناسهٔ کلاینت IPv4 بگنجانند، همان‌طور که در RFC 4361 \%\& تشریح شده است. بدین ترتیب، به‌روزرسانی‌های DNS هم برای IPv4 و هم برای IPv6 می‌توانند تحت یک رکورد DHCID RR یکسان مدیریت شوند. این ویژگی از نگارش 2.1.2 به بعد در Kea پشتیبانی می‌شود. .SS "راه‌اندازی و متوقف‌کردن کارساز DHCP\-DDNS (Starting and Stopping the DHCP\-DDNS Server)" .sp برنامهٔ \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> کارساز DHCP\-DDNS در Kea است و با توجه به ماهیت DDNS، در کنار مؤلفهٔ DHCPv4 یا DHCPv6 (یا هر دو) اجرا می‌شود. مانند سایر بخش‌های Kea، این برنامه یک باینری مجزا است که می‌تواند به صورت مستقل یا از طریق \fBkeactrl\fP \%<#\:std-iscman-keactrl> اجرا شود (ببینید Managing Kea with keactrl \%<#\:keactrl>). در حالت عادی، کنترل کردن \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> با \fBkeactrl\fP \%<#\:std-iscman-keactrl> توصیه می‌شود؛ با این حال، اجرای مستقیم کارساز DHCP\-DDNS نیز امکان‌پذیر است. این برنامه سوئیچ‌های خط فرمان زیر را می‌پذیرد: .INDENT 0.0 .IP \(bu 2 \fB\-c file\fP \- فایل پیکربندی را مشخص می‌کند. این تنها سوئیچ الزامی است. .IP \(bu 2 \fB\-d\fP \- مشخص می‌کند که آیا ثبت وقایع (لاگین) کارساز باید به حالت اشکال‌زدایی/پُرگویی (debug/verbose) تغییر کند یا خیر. در حالت پُرگو، سطح اهمیت ثبت وقایع و debuglevel مشخص‌شده در فایل پیکربندی نادیده گرفته می‌شوند و سطح اهمیت \(dqdebug\(dq و حداکثر debuglevel یعنی (99) در نظر گرفته می‌شود. این پرچم برای تغییر موقت کارساز به بیشترین حد پُرگویی، مثلاً هنگام اشکال‌زدایی، مناسب است. .IP \(bu 2 \fB\-t file\fP \- فایل پیکربندی را برای آزمایش مشخص می‌کند. \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> تلاش می‌کند آن را بارگذاری کرده و بررسی‌های سلامت را انجام دهد. برخی بررسی‌ها تنها هنگام اجرای کارساز واقعی امکان‌پذیر است. وضعیت واقعی با یک کد خروج گزارش می‌شود (0 = پیکربندی مناسب به نظر می‌رسد، 1 = خطا رخ داده است). هنگام آزمایش پیکربندی، Kea پیام‌های لاگ را در خروجی استاندارد و خطاها را در خطای استاندارد چاپ می‌کند. .IP \(bu 2 \fB\-v\fP \- نگارش Kea را نمایش داده و خارج می‌شود. .IP \(bu 2 \fB\-V\fP \- نگارش تفصیلی Kea را نمایش داده و خارج می‌شود. .IP \(bu 2 \fB\-W\fP \- گزارش پیکربندی Kea را نمایش داده و خارج می‌شود. این گزارش رونوشتی از فایل \fBconfig.report\fP تولیدشده توسط \fBmeson setup\fP است؛ این گزارش درون باینری اجرایی جاسازی شده است. .sp محتویات فایل \fBconfig.report\fP همچنین از طریق بررسی کتابخانه‌های خاصی در درخت نصب یا در درخت سورس قابل دسترسی است. .INDENT 2.0 .INDENT 3.5 .sp .EX # from installation using libkea\-process.so $ strings ${prefix}/lib/libkea\-process.so | sed \-n \(aqs/;;;; //p\(aq # from sources using libkea\-process.so $ strings src/lib/process/.libs/libkea\-process.so | sed \-n \(aqs/;;;; //p\(aq # from sources using libkea\-process.a $ strings src/lib/process/.libs/libkea\-process.a | sed \-n \(aqs/;;;; //p\(aq # from sources using libcfgrpt.a $ strings src/lib/process/cfgrpt/.libs/libcfgrpt.a | sed \-n \(aqs/;;;; //p\(aq .EE .UNINDENT .UNINDENT .IP \(bu 2 \fB\-X\fP \- از نسخهٔ Kea 3.0، محدودیت‌های امنیتی را غیرفعال می‌کند. کارساز همچنان نقض‌ها را بررسی می‌کند اما به جای شکست همراه با خطا، هنگام یافتن آن‌ها پیام‌های هشدار ثبت خواهد کرد. لطفاً برای جزئیات به Kea Runtime Security Policy Checking \%<#\:sec-kea-runtime-security-policy-checking> مراجعه کنید. .UNINDENT .sp پس از راه‌اندازی، ماژول پیکربندی خود را بارگذاری کرده و بر اساس آن پیکربندی، گوش‌دادن به NCRها را آغاز می‌کند. .sp در حین راه‌اندازی، کارساز تلاش می‌کند یک فایل PID به این شکل ایجاد کند: \fB[pidfile_dir]/[conf name].kea\-dhcp\-ddns.pid\fP که در آن: .INDENT 0.0 .IP \(bu 2 \fBpidfile_dir\fP \- برابر است با \fB[prefix]/[localstatedir]/run/kea\fP که در آن \fBprefix\fP و \fBlocalstatedir\fP مقادیری هستند که با استفاده از \fB\-\-prefix\fP و \fB\-\-localstatedir\fP به meson setup ارسال شده‌اند و به‌ترتیب به‌طور پیش‌فرض \fB/usr/local\fP و \fBvar\fP می‌باشند. بنابراین کل مسیر \fBpidfile_dir\fP به‌طور پیش‌فرض \fB/usr/local/var\fP است. توجه داشته باشید که این مقدار ممکن است در زمان اجرا با تنظیم متغیر محیطی \fBKEA_PIDFILE_DIR\fP که در درجهٔ اول برای اهداف آزمایشی در نظر گرفته شده است، بازنویسی شود. .IP \(bu 2 \fBconf name\fP \- نام فایل پیکربندی استفاده‌شده برای راه‌اندازی کارساز است، منهای تمام مسیرهای پیش از آن و پسوند فایل. برای مثال، با داشتن مسیر \fB/usr/local/etc/kea/myconf.txt\fP، بخش مورداستفاده \fBmyconf\fP خواهد بود. .UNINDENT .sp اگر فایل از قبل موجود باشد و حاوی PID یک فرایند زنده باشد، کارساز پیام ثبت وقایع \fBDHCP_DDNS_ALREADY_RUNNING\fP را صادر کرده و خارج می‌شود. این احتمال وجود دارد (هرچند بعید) که این فایل بازماندهٔ یک فروپاشی سیستم باشد و فرایندی که PID متعلق به آن است به Kea نامربوط باشد. در چنین حالتی، حذف دستی فایل PID ضروری است..SS پیکربندی کارگزار DHCP\-DDNS .sp پیش از راه‌اندازی ماژول \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> برای نخستین بار، باید یک فایل پیکربندی ایجاد شود. پیکربندی پیش‌فرض زیر قالبی است که می‌تواند بر اساس نیازهای اختصاصی سفارشی‌سازی شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqip\-address\(dq: \(dq127.0.0.1\(dq, \(dqport\(dq: 53001, \(dqdns\-server\-timeout\(dq: 500, \(dqncr\-protocol\(dq: \(dqUDP\(dq, \(dqncr\-format\(dq: \(dqJSON\(dq, \(dqtsig\-keys\(dq: [ ], \(dqforward\-ddns\(dq: { \(dqddns\-domains\(dq: [ ] }, \(dqreverse\-ddns\(dq: { \(dqddns\-domains\(dq: [ ] } } .EE .UNINDENT .UNINDENT .sp پیکربندی را می‌توان به بخش‌های زیر تقسیم کرد که هر یک در ادامه توضیح داده شده‌اند: .INDENT 0.0 .IP \(bu 2 \fIپارامترهای سراسری کارگزار (Global Server Parameters)\fP \- مقادیری را تعریف می‌کند که برقراری ارتباط و رفتار سراسری کارگزار را کنترل می‌کنند. .IP \(bu 2 \fIسوکت‌های کنترلی (Control Sockets)\fP \- فهرست سوکت‌های کنترلی را تعریف می‌کند. .IP \(bu 2 \fIاطلاعات کلید TSIG (TSIG Key Info)\fP \- کلیدهای TSIG مورد استفاده برای تبادل امن داده با کارگزارهای DNS را تعریف می‌کند. .IP \(bu 2 \fIDDNS مستقیم (Forward DDNS)\fP \- فهرست دامنه‌های DDNS مستقیم را تعریف می‌کند. .IP \(bu 2 \fIDDNS معکوس (Reverse DDNS)\fP \- فهرست دامنه‌های DDNS معکوس را تعریف می‌کند. .UNINDENT .SS پارامترهای سراسری کارگزار (Global Server Parameters) .INDENT 0.0 .IP \(bu 2 \fBip\-address\fP \- نشانی IP که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض، رابط محلی loopback روی نشانی 127.0.0.1 است. می‌توان یک نشانی IPv4 یا IPv6 تعیین کرد. .IP \(bu 2 \fBport\fP \- درگاهی (port) که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض 53001 است. .IP \(bu 2 \fBdns\-server\-timeout\fP \- حداکثر زمانی (بر حسب میلی‌ثانیه) که D2 برای دریافت پاسخ از کارگزار DNS برای یک پیام به‌روزرسانی منفرد DNS منتظر می‌ماند. مقدار پیش‌فرض 500 میلی‌ثانیه است. .IP \(bu 2 \fBncr\-protocol\fP \- پروتکل سوکت مورد استفاده هنگام ارسال درخواست‌ها به D2. در حال حاضر فقط UDP پشتیبانی می‌شود. .IP \(bu 2 \fBncr\-format\fP \- قالب بسته مورد استفاده هنگام ارسال درخواست‌ها به D2. در حال حاضر فقط قالب JSON پشتیبانی می‌شود. .UNINDENT .sp D2 باید روی یک نشانی و درگاه مشخص به درخواست‌های تغییر گوش دهد. به‌طور پیش‌فرض، روی 127.0.0.1 و درگاه 53001 گوش می‌دهد. مثال زیر نشان می‌دهد که چگونه می‌توان پارامترهای سراسری D2 را تغییر داد تا روی 192.168.1.10 و درگاه 900 گوش دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqip\-address\(dq: \(dq192.168.1.10\(dq, \(dqport\(dq: 900, ... } .EE .UNINDENT .UNINDENT .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 این امکان وجود دارد که یک مهاجم مخرب درخواست‌های جعلی NameChangeRequests را به کارگزار DHCP\-DDNS ارسال کند. نشانی‌هایی غیر از نشانی‌های loopback در IPv4 یا IPv6 (یعنی 127.0.0.1 یا ::1) باید صرفاً برای مقاصد آزمایشی استفاده شوند؛ توجه داشته باشید که کاربران محلی همچنان می‌توانند با کارگزار DHCP\-DDNS ارتباط برقرار کنند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگر \fBip\-address\fP و \fBport\fP تغییر کنند، مقادیر متناظر در بخش پیکربندی \fBdhcp\-ddns\fP در کارگزارهای DHCP نیز باید تغییر یابند. .UNINDENT .UNINDENT .SS رابط برنامه‌نویسی مدیریت (Management API) برای کارگزار D2 .sp رابط برنامه‌نویسی مدیریت امکان صدور دستورهای مدیریتی مشخص، مانند بازخوانی پیکربندی یا خاموش کردن را فراهم می‌کند. برای جزئیات بیشتر، Management API \%<#\:ctrl-channel>\& را ببینید. به‌طور پیش‌فرض هیچ سوکتی باز نیست؛ برای این‌که به Kea دستور دهید سوکتی را باز کند، می‌توان از مدخل زیر در فایل پیکربندی استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqcontrol\-sockets\(dq: [ { \(dqsocket\-type\(dq: \(dqunix\(dq, \(dqsocket\-name\(dq: \(dq/path/to/the/unix/socket\(dq } ], ... } .EE .UNINDENT .UNINDENT.SS سوکت کنترلی UNIX .sp تا قبل از سرور Kea نسخهٔ 2.7.2، تنها نوع کانال ارتباطی پشتیبانی‌شده سوکت جریان UNIX با مقداردهی \fBsocket\-type\fP به \fBunix\fP و \fBsocket\-name\fP به مسیر فایل سوکت UNIX/LOCAL بود. .sp طول مسیر مشخص‌شده توسط پارامتر \fBsocket\-name\fP به حداکثر طول مجاز برای نام سوکت UNIX در سیستم‌عامل، یعنی اندازهٔ فیلد \fBsun_path\fP در ساختار \fBsockaddr_un\fP منهای ۱، محدود است. این مقدار در سیستم‌عامل‌های مختلف بین ۹۱ تا ۱۰۷ نویسه متغیر است. مقادیر معمول ۱۰۷ در Linux و ۱۰۳ در FreeBSD هستند. .sp نرم‌افزار Kea تنها از یک سوکت کنترلی \fBunix\fP در فهرست \(dqcontrol\-sockets\(dq پشتیبانی می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ 2.7.9 در Kea، سوکت‌های کنترلی فقط می‌توانند در دایرکتوری تعیین‌شده در زمان کامپایل یعنی \fB\(dq[kea\-install\-dir]/var/run/kea\(dq\fP قرار گیرند که این مسیر نیز باید دارای مجوزهای دسترسی \fB0750\fP باشد. این مسیر را می‌توان هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_CONTROL_SOCKET_DIR\fP به مسیر دلخواه بازنویسی (override) کرد. اگر مسیری غیر از این مقدار در \fBsocket\-name\fP استفاده شود، Kea خطایی صادر کرده و از شروع به کار امتناع می‌کند، یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت می‌کند. برای سهولت در استفاده، کافی است بخش مسیر را از \fBsocket\-name\fP حذف کنید\&. .UNINDENT .UNINDENT .sp ارتباط از طریق کانال کنترلی با استفاده از ساختارهای JSON انجام می‌شود. برای جزئیات بیشتر به بخش Control Channel در Kea Developer\(aqs Guide \% مراجعه کنید. .sp سرور D2 از دستورهای عملیاتی زیر پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBbuild\-report\fP \%<#\:std-isccmd-build-report> .IP \(bu 2 \fBconfig\-get\fP \%<#\:std-isccmd-config-get> .IP \(bu 2 \fBconfig\-hash\-get\fP \%<#\:std-isccmd-config-hash-get> .IP \(bu 2 \fBconfig\-reload\fP \%<#\:std-isccmd-config-reload> .IP \(bu 2 \fBconfig\-set\fP \%<#\:std-isccmd-config-set> .IP \(bu 2 \fBconfig\-test\fP \%<#\:std-isccmd-config-test> .IP \(bu 2 \fBconfig\-write\fP \%<#\:std-isccmd-config-write> .IP \(bu 2 \fBlist\-commands\fP \%<#\:std-isccmd-list-commands> .IP \(bu 2 \fBshutdown\fP \%<#\:std-isccmd-shutdown> .IP \(bu 2 \fBstatus\-get\fP \%<#\:std-isccmd-status-get> .IP \(bu 2 \fBversion\-get\fP \%<#\:std-isccmd-version-get> .UNINDENT .sp از نسخهٔ 2.0.0 در Kea، سرور D2 از دستورهای عملیاتی زیر نیز برای آمار پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBstatistic\-get\fP \%<#\:std-isccmd-statistic-get> .IP \(bu 2 \fBstatistic\-get\fP \%<#\:std-isccmd-statistic-get>\-all .IP \(bu 2 \fBstatistic\-reset\fP \%<#\:std-isccmd-statistic-reset> .IP \(bu 2 \fBstatistic\-reset\fP \%<#\:std-isccmd-statistic-reset>\-all .UNINDENT .sp دستور \fBshutdown\fP \%<#\:std-isccmd-shutdown> از آرگومان اضافی \fBtype\fP پشتیبانی می‌کند که نحوهٔ پاک‌سازی سرور D2 هنگام خروج را کنترل می‌کند. انواع خاموش‌سازی پشتیبانی‌شده عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBnormal\fP \- مدیر صف را متوقف کرده و قبل از خروج، تمام تراکنش‌های جاری را به پایان می‌رساند. این مقدار پیش‌فرض است. .IP \(bu 2 \fBdrain_first\fP \- مدیر صف را متوقف می‌کند، اما به پردازش درخواست‌ها از صف تا خالی شدن آن ادامه می‌دهد. .IP \(bu 2 \fBnow\fP \- بلافاصله خارج می‌شود. .UNINDENT .sp یک دستور نمونه می‌تواند به این صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqshutdown\(dq, \(dqarguments\(dq: { \(dqexit\-value\(dq: 3, \(dqtype\(dq: \(dqdrain_first\(dq } } .EE .UNINDENT .UNINDENT .SS سوکت کنترلی HTTP/HTTPS .sp مقدار \fBsocket\-type\fP باید \fBhttp\fP یا \fBhttps\fP باشد (هنگامی که نوع آن \fBhttps\fP باشد، TLS الزامی است). پارامترهای \fBsocket\-address\fP (پیش‌فرض \fB127.0.0.1\fP) و \fBsocket\-port\fP (پیش‌فرض 8000) آدرس IP و درگاهی را مشخص می‌کنند که سرویس HTTP به آن متصل (bind) خواهد شد. .sp پارامترهای \fBtrust\-anchor\fP، \fBcert\-file\fP، \fBkey\-file\fP و \fBcert\-required\fP پیکربندی TLS را برای HTTP، یعنی HTTPS، مشخص می‌کنند. اگر این پارامترها مشخص نشوند، از HTTP استفاده می‌شود. پشتیبانی از TLS/HTTPS در Kea در بخش TLS/HTTPS Support \%<#\:tls>\& شرح داده شده است. .sp احراز هویت پایه HTTP (Basic HTTP authentication) از سرور در برابر استفاده‌های غیرمجاز توسط کاربران محلی محافظت می‌کند. برای محافظت در برابر مهاجمان از راه دور، HTTPS و پراکسی معکوس (reverse proxy) امنیت قوی‌تری فراهم می‌کنند. .sp احراز هویت در بلوک \fBauthentication\fP همراه با پارامتر اجباری \fBtype\fP شرح داده می‌شود که روش احراز هویت را تعیین می‌کند. در حال حاضر تنها احراز هویت پایه HTTP (نوع basic) پشتیبانی می‌شود. .sp پارامتر احراز هویت \fBrealm\fP (پیش‌فرض \fBkea\-dhcp\-ddns\-server\fP) برای پیام‌های خطا در شرایطی استفاده می‌شود که احراز هویت پایه HTTP الزامی است اما کلاینت مجاز شناخته نشده است. .sp هنگامی که فهرست احراز هویت \fBclients\fP پیکربندی شده و خالی نباشد، احراز هویت پایه HTTP الزامی است. هر عنصر از فهرست، یک شناسه کاربری و یک گذرواژه را مشخص می‌کند. شناسه کاربری الزامی است، نباید خالی باشد و نباید حاوی نویسهٔ دونقطه (:) باشد. گذرواژه اختیاری است؛ در صورت عدم تعیین، گذرواژهٔ خالی استفاده می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 شناسه کاربری و گذرواژه در احراز هویت پایه HTTP با استاندارد UTF\-8 کدگذاری می‌شوند، اما نحو JSON کنونی Kea تنها از زیرمجموعه یونیکد Latin\-1 (یعنی 0x00..0xff) پشتیبانی می‌کند. .UNINDENT .UNINDENT .sp برای جلوگیری از افشای شناسه کاربری و/یا گذرواژه مرتبط، می‌توان این مقادیر را از فایل‌ها خواند. نحو دستورها با موارد زیر گسترش یافته است: .INDENT 0.0 .IP \(bu 2 پارامتر احراز هویت \fBdirectory\fP، که بخش مشترک مسیرهای فایل را مدیریت می‌کند. مقدار پیش‌فرض آن یک رشتهٔ خالی است. .IP \(bu 2 پارامتر کلاینت \fBpassword\-file\fP، که همراه با پارامتر \fBdirectory\fP، مسیر فایلی را مشخص می‌کند که می‌تواند حاوی گذرواژه باشد، یا در صورتی که هیچ شناسه کاربری داده نشده باشد، کل راز احراز هویت پایه HTTP را در بر گیرد. .IP \(bu 2 پارامتر کلاینت \fBuser\-file\fP، که همراه با پارامتر \fBdirectory\fP، مسیر فایلی را مشخص می‌کند که شناسه کاربری از آن خوانده می‌شود. .UNINDENT .sp از نسخهٔ 2.7.6 در Kea، از چندین اتصال HTTP/HTTPS پشتیبانی می‌شود. هر دو نوع آدرس IPv4 و IPv6 قابل استفاده هستند. سرور در صورت تغییر نوع سوکت از HTTP به HTTPS یا از HTTPS به HTTP با استفاده از همان آدرس و درگاه، خطایی صادر خواهد کرد. این عمل مجاز نیست زیرا ممکن است موجب بروز یک مشکل امنیتی تصادفی ناشی از اشتباه کاربر شود. هنگام استفاده از دستور \(dqconfig\-set\(dq برای تغییر از HTTP به HTTPS یا از HTTPS به HTTP، باید آدرس یا درگاه متفاوتی مشخص شود. همین موضوع هنگام تغییر فایل پیکربندی و سپس اجرای دستور \(dqconfig\-reload\(dq نیز صدق می‌کند. .sp هنگامی که از فایل‌ها استفاده می‌شود، آن‌ها در زمان بارگذاری پیکربندی خوانده می‌شوند تا خطاهای پیکربندی در سریع‌ترین زمان ممکن شناسایی شوند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqcontrol\-sockets\(dq: [ { \(dqsocket\-type\(dq: \(dqhttps\(dq, \(dqsocket\-address\(dq: \(dq10.20.30.40\(dq, \(dqsocket\-port\(dq: 8005, \(dqtrust\-anchor\(dq: \(dq/path/to/the/ca\-cert.pem\(dq, \(dqcert\-file\(dq: \(dq/path/to/the/agent\-cert.pem\(dq, \(dqkey\-file\(dq: \(dq/path/to/the/agent\-key.pem\(dq, \(dqcert\-required\(dq: true, \(dqauthentication\(dq: { \(dqtype\(dq: \(dqbasic\(dq, \(dqrealm\(dq: \(dqkea\-dhcp\-ddns\-server\(dq, \(dqclients\(dq: [ { \(dquser\(dq: \(dqadmin\(dq, \(dqpassword\(dq: \(dq1234\(dq } ] } }, { \(dqsocket\-type\(dq: \(dqhttp\(dq, \(dqsocket\-address\(dq: \(dq2010:30:40::50\(dq, \(dqsocket\-port\(dq: 8004 } ], ... } .EE .UNINDENT .UNINDENT.SS فهرست کلیدهای TSIG (TSIG Key List) .sp یک تبادل در پروتکل DDNS می‌تواند با یا بدون امضای تراکنش یا TSIG (تعریف‌شده در RFC 2845 \%) انجام شود. این بخش از پیکربندی به مدیر سیستم امکان می‌دهد مجموعه‌ای از کلیدهای TSIG را که ممکن است در چنین تبادلاتی استفاده شوند، تعریف کند. .sp برای استفاده از TSIG هنگام به‌روزرسانی مدخل‌ها در یک دامنهٔ DNS، باید یک کلید در فهرست کلیدهای TSIG تعریف شده و با نام در مدخل پیکربندی آن دامنه به آن ارجاع داده شود. هنگامی که D2 یک درخواست تغییر را با یک دامنه مطابقت می‌دهد، بررسی می‌کند که آیا آن دامنه کلید TSIG مرتبطی دارد یا خیر. در صورت وجود، D2 از آن کلید برای امضای پیام‌های به‌روزرسانی DNS ارسالی به سرور(های) DNS دامنه و اعتبارسنجی پاسخ‌های دریافتی از آن‌ها استفاده می‌کند. به ازای هر کلید TSIG مورد نیاز سرورهای DNS که D2 با آن‌ها کار می‌کند، باید یک کلید TSIG متناظر در فهرست کلیدهای TSIG وجود داشته باشد. .sp همان‌طور که ممکن است از نام آن مشخص باشد، بخش \fBtsig\-key\fP در پیکربندی D2 کلیدهای TSIG را فهرست می‌کند. هر مدخل، یک کلید TSIG را توصیف می‌کند که توسط یک یا چند سرور DNS برای احراز هویت درخواست‌ها و امضای پاسخ‌ها استفاده می‌شود. هر مدخل در این فهرست سه پارامتر دارد: .INDENT 0.0 .IP \(bu 2 \fBname\fP \- یک برچسب متنی یکتا است که برای شناسایی این کلید در فهرست استفاده می‌شود. این مقدار مشخص می‌کند که هنگام به‌روزرسانی یک دامنهٔ خاص، باید از کدام کلید (در صورت وجود) استفاده شود. تا زمانی که این نام یکتا باشد محتوای آن اختیاری است، اگرچه برای وضوح و سهولت در نگهداری توصیه می‌شود که با نام استفاده‌شده در سرور(های) DNS مطابقت داشته باشد. این فیلد نمی‌تواند خالی باشد. .IP \(bu 2 \fBalgorithm\fP \- مشخص می‌کند که کدام الگوریتم درهم‌سازی (هش) باید با این کلید استفاده شود. این مقدار باید همان الگوریتمی را مشخص کند که برای کلید در سرور(های) DNS به کار رفته است. الگوریتم‌های پشتیبانی‌شده در زیر فهرست شده‌اند: .INDENT 2.0 .IP \(bu 2 HMAC\-MD5 .IP \(bu 2 HMAC\-SHA1 .IP \(bu 2 HMAC\-SHA224 .IP \(bu 2 HMAC\-SHA256 .IP \(bu 2 HMAC\-SHA384 .IP \(bu 2 HMAC\-SHA512 .UNINDENT .sp این مقدار به حروف بزرگ و کوچک حساس نیست. .IP \(bu 2 \fBdigest\-bits\fP \- برای تعیین حداقل طول خلاصه‌سازی‌شده بر حسب بیت استفاده می‌شود. مقدار پیش‌فرض 0 به این معنی است که کوتاه‌سازی ممنوع است؛ مقادیر غیرصفر باید یک عدد صحیح از هشت‌بیت‌ها (اکتت‌ها) بوده و هم از 80 و هم از نصف طول کامل بزرگ‌تر باشند. (توجه داشته باشید که در BIND 9 این پارامتر بعد از یک خط تیره به انتهای نام الگوریتم اضافه می‌شود.) .IP \(bu 2 \fBsecret\fP \- برای تعیین کد کلید مخفی مشترک (shared secret) برای این کلید استفاده می‌شود. این مقدار به حروف بزرگ و کوچک حساس است و باید دقیقاً با مقدار مشخص‌شده در سرور(های) DNS مطابقت داشته باشد. این مقدار یک متن کدگذاری‌شده با base64 است. .IP \(bu 2 \fBsecret\-file\fP \- از نسخهٔ Kea 2.5.8، این جایگزین امن‌تر پشتیبانی می‌شود. این مقدار نام فایلی را مشخص می‌کند که کلید مخفی در آن قرار دارد، به این معنی که کلید مخفیِ کدگذاری‌شده با base64 محتوای فایل است. .UNINDENT .sp به عنوان مثال، فرض کنید دامنه‌ای که D2 به‌روزرسانی خواهد کرد توسط یک سرور DNS از نوع BIND 9 نگهداری می‌شود که نیاز دارد به‌روزرسانی‌های پویا با TSIG امن شوند. همچنین فرض کنید مدخل مربوط به کلید TSIG در فایل named.conf سرور BIND 9 به این شکل است: .INDENT 0.0 .INDENT 3.5 .sp .EX : key \(dqkey.four.example.com.\(dq { algorithm hmac\-sha224; secret \(dqbZEG7Ow8OgAUPfLWV3aAUQ==\(dq; }; : .EE .UNINDENT .UNINDENT .sp به‌طور پیش‌فرض، فهرست کلیدهای TSIG خالی است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqtsig\-keys\(dq: [ ], ... } .EE .UNINDENT .UNINDENT .sp یک کلید جدید باید به فهرست اضافه شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqtsig\-keys\(dq: [ { \(dqname\(dq: \(dqkey.four.example.com.\(dq, \(dqalgorithm\(dq: \(dqHMAC\-SHA224\(dq, \(dqsecret\(dq: \(dqbZEG7Ow8OgAUPfLWV3aAUQ==\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp این مراحل باید برای هر کلید TSIG مورد نیاز تکرار شوند، هرچند یک کلید TSIG یکسان می‌تواند برای بیش از یک دامنه استفاده شود. .SS DDNS مستقیم (Forward DDNS) .sp بخش forward DDNS برای پیکربندی رفتار به‌روزرسانی مستقیم (forward\-update) در D2 استفاده می‌شود. در حال حاضر این بخش شامل یک پارامتر واحد است: کاتالوگ دامنه‌های forward DDNS، که فهرستی از ساختارها است. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqforward\-ddns\(dq: { \(dqddns\-domains\(dq: [ ] }, ... } .EE .UNINDENT .UNINDENT .sp به‌طور پیش‌فرض، این فهرست خالی است که موجب می‌شود سرور بخش‌های مربوط به به‌روزرسانی مستقیم در درخواست‌ها را نادیده بگیرد..SS افزودن دامنه‌های DDNS مستقیم .sp یک دامنهٔ DDNS مستقیم، یک ناحیهٔ (zone) مستقیم DNS را به مجموعه‌ای از سرورهای DNS نگاشت می‌کند که داده‌های مستقیم DNS (یعنی نگاشت نام به آدرس) را برای آن ناحیه نگهداری می‌کنند. هر ناحیهٔ ارائه‌شده به یک دامنهٔ DDNS مستقیم نیاز دارد. ممکن است برخی یا همهٔ ناحیه‌ها توسط سرورهای یکسانی نگهداری شوند، اما همچنان برای هر ناحیه به یک دامنهٔ DDNS نیاز است. به یاد داشته باشید که تطبیق یک درخواست با سرور(های) مناسب بر اساس ناحیه انجام می‌شود و یک دامنهٔ DDNS تنها یک ناحیه را تعریف می‌کند. .sp این بخش نحوهٔ افزودن دامنه‌های DDNS مستقیم را شرح می‌دهد؛ این مراحل را برای هر دامنهٔ DDNS مستقیمِ موردنظر تکرار کنید. هر دامنهٔ DDNS مستقیم دارای پارامترهای زیر است: .INDENT 0.0 .IP \(bu 2 \fBname\fP \- این نام دامنهٔ کاملاً مشخص (یا ناحیه) است که این دامنهٔ DDNS می‌تواند آن را به‌روزرسانی کند. این مقدار هنگام تطبیق مستقیم با FQDN درخواست مقایسه می‌شود. این مقدار باید در کاتالوگ (catalog) یکتا باشد. .IP \(bu 2 \fBkey\-name\fP \- اگر از TSIG همراه با سرورهای این دامنه استفاده می‌شود، این مقدار باید نام کلید از فهرست کلیدهای TSIG باشد. اگر مقدار خالی باشد (پیش‌فرض)، از TSIG در تبادلات DDNS با سرورهای این دامنه استفاده نخواهد شد. .IP \(bu 2 \fBdns\-servers\fP \- فهرستی از یک یا چند سرور DNS است که می‌توانند سمتِ سرورِ پروتکل DDNS را برای این دامنه اداره کنند. سرورها به ترتیب اولویت از نخستین تا آخرین استفاده می‌شوند؛ به عبارت دیگر، هنگامی که D2 پردازش یک درخواست را برای این دامنه آغاز می‌کند، نخستین سرور در این فهرست را انتخاب کرده و تلاش می‌کند با آن ارتباط برقرار کند. اگر آن تلاش ناموفق باشد، D2 به سراغ سرور بعدی در فهرست می‌رود و به همین ترتیب، تا زمانی که یا عملیات موفقیت‌آمیز باشد یا فهرست به پایان برسد. .UNINDENT .sp برای ایجاد یک دامنهٔ DDNS مستقیم جدید، یک عنصر دامنهٔ جدید اضافه کرده و پارامترهای آن را تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqforward\-ddns\(dq: { \(dqddns\-domains\(dq: [ { \(dqname\(dq: \(dqother.example.com.\(dq, \(dqkey\-name\(dq: \(dq\(dq, \(dqdns\-servers\(dq: [ ] } ] } } .EE .UNINDENT .UNINDENT .sp امکان افزودن یک دامنه بدون هیچ سروری وجود دارد؛ با این حال، اگر آن دامنه با درخواستی تطبیق یابد، درخواست با شکست مواجه می‌شود. برای اینکه دامنه کاربردی باشد، باید دست‌کم یک سرور DNS به آن اضافه شود. .SS افزودن سرورهای مستقیم DNS .sp این بخش نحوهٔ افزودن سرورهای DNS به یک دامنهٔ DDNS مستقیم را شرح می‌دهد. این دستورالعمل‌ها را برحسب نیاز برای تمام سرورهای هر دامنه تکرار کنید. .sp مدخل‌های سرور مستقیم DNS نمایانگر سرورهای واقعی DNS هستند که از سمت سرور پروتکل DDNS پشتیبانی می‌کنند. هر سرور مستقیم DNS دارای پارامترهای زیر است: .INDENT 0.0 .IP \(bu 2 \fBhostname\fP \- نام میزبان قابل‌حلِ (resolvable) سرور DNS؛ این پارامتر هنوز پیاده‌سازی نشده است. .IP \(bu 2 \fBip\-address\fP \- آدرس IP که سرور روی آن به درخواست‌های DDNS گوش می‌دهد. این آدرس می‌تواند یک آدرس IPv4 یا IPv6 باشد. .IP \(bu 2 \fBport\fP \- پورتی که سرور روی آن به درخواست‌های DDNS گوش می‌دهد. مقدار پیش‌فرض آن پورت استاندارد سرویس DNS یعنی 53 است. .UNINDENT .sp برای ایجاد یک سرور مستقیم DNS جدید، باید یک عنصر سرور جدید به دامنه اضافه شده و پارامترهای آن تکمیل شود. به عنوان مثال، اگر سرویس روی \(dq172.88.99.10\(dq در حال اجرا باشد، سرور مستقیم DNS را به صورت زیر تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqforward\-ddns\(dq: { \(dqddns\-domains\(dq: [ { \(dqname\(dq: \(dqother.example.com.\(dq, \(dqkey\-name\(dq: \(dq\(dq, \(dqdns\-servers\(dq: [ { \(dqip\-address\(dq: \(dq172.88.99.10\(dq, \(dqport\(dq: 53 } ] } ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از آنجا که \fBhostname\fP هنوز پشتیبانی نمی‌شود، پارامتر \fBip\-address\fP باید روی آدرس سرور DNS تنظیم شود. .UNINDENT .UNINDENT .SS DDNS معکوس .sp بخش DDNS معکوس برای پیکربندی رفتار به‌روزرسانی معکوس D2 به کار می‌رود و مفاهیم آن مشابه بخش DDNS مستقیم است. در حال حاضر این بخش شامل یک پارامتر منفرد، یعنی کاتالوگ (catalog) دامنه‌های DDNS معکوس است که فهرستی از ساختارها می‌باشد. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqreverse\-ddns\(dq: { \(dqddns\-domains\(dq: [ ] }, ... } .EE .UNINDENT .UNINDENT .sp به‌طور پیش‌فرض، این فهرست خالی است که باعث می‌شود سرور بخش‌های به‌روزرسانی معکوس در درخواست‌ها را نادیده بگیرد..SS افزودن دامنه‌های DDNS معکوس .sp یک دامنهٔ DDNS معکوس، یک زون معکوس DNS را به مجموعه‌ای از کارگزارهای DNS که داده‌های معکوس DNS (نگاشت نشانی به نام) را برای آن زون نگهداری می‌کنند، نگاشت می‌نماید. هر زون سرویس‌دهی‌شده به یک دامنهٔ DDNS معکوس نیاز دارد. ممکن است برخی یا همهٔ زون‌ها توسط کارگزارهای یکسانی نگهداری شوند، اما برای هر زون به یک مدخل دامنهٔ DDNS نیاز است. به یاد داشته باشید که تطبیق یک درخواست با کارگزار(های) مناسب بر پایهٔ زون انجام می‌شود و هر دامنهٔ DDNS تنها یک زون منفرد را تعریف می‌کند. .sp این بخش نحوهٔ افزودن دامنه‌های DDNS معکوس را شرح می‌دهد؛ این مراحل را برای هر دامنهٔ DDNS معکوس دلخواه تکرار کنید. هر دامنهٔ DDNS معکوس دارای پارامترهای زیر است: .INDENT 0.0 .IP \(bu 2 \fBname\fP \- این زون معکوس کاملاً واجد شرایط (FQDN) است که این دامنهٔ DDNS می‌تواند آن را به‌روزرسانی کند. این همان مقداری است که در طول تطبیق معکوس استفاده می‌شود و با نسخهٔ معکوس‌شدهٔ نشانی واگذاری (lease address) درخواست مقایسه می‌گردد. نام زون باید از استانداردهای مربوطه پیروی کند؛ برای مثال، جهت پشتیبانی از زیرشبکهٔ IPv4 به‌صورت 172.16.1، نام باید \(dq1.16.172.in\-addr.arpa.\(dq باشد. به همین ترتیب، برای پشتیبانی از یک زیرشبکهٔ IPv6 مانند 2001:db8:1، نام باید \(dq1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.\(dq باشد. این نام باید در سرتاسر کاتالوگ یکتا باشد. .IP \(bu 2 \fBkey\-name\fP \- اگر در ارتباط با کارگزارهای این دامنه از TSIG استفاده می‌شود، این مقدار باید نام کلید از فهرست کلیدهای TSIG باشد. اگر مقدار خالی باشد (پیش‌فرض)، در تبادلات DDNS با کارگزارهای این دامنه از TSIG استفاده نخواهد شد. .IP \(bu 2 \fBdns\-servers\fP \- فهرستی از یک یا چند کارگزار DNS است که می‌توانند سمت سرور پروتکل DDNS را برای این دامنه اجرا کنند. در حال حاضر، کارگزارها با اولویت نخستین به آخرین استفاده می‌شوند؛ به عبارت دیگر، هنگامی که D2 پردازش درخواستی را برای این دامنه آغاز می‌کند، نخستین کارگزار این فهرست را برمی‌گزیند و برای برقراری ارتباط با آن تلاش می‌کند. اگر آن تلاش ناموفق باشد، D2 به سراغ کارگزار بعدی در فهرست می‌رود و به همین ترتیب، تا زمانی که عملیات با موفقیت انجام شود یا فهرست به پایان برسد. .UNINDENT .sp برای ایجاد یک دامنهٔ DDNS معکوس جدید، باید یک عنصر دامنهٔ جدید اضافه شده و پارامترهای آن مقداردهی گردند. برای نمونه، برای پشتیبانی از زیرشبکهٔ 2001:db8:1::، می‌توان از پیکربندی زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqreverse\-ddns\(dq: { \(dqddns\-domains\(dq: [ { \(dqname\(dq: \(dq1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.\(dq, \(dqkey\-name\(dq: \(dq\(dq, \(dqdns\-servers\(dq: [ ] } ] } } .EE .UNINDENT .UNINDENT .sp افزودن یک دامنه بدون هیچ‌گونه کارگزاری امکان‌پذیر است؛ با این حال، اگر آن دامنه با درخواستی تطبیق یابد، درخواست با شکست مواجه خواهد شد. برای کاربردی ساختن دامنه، دست‌کم یک کارگزار DNS باید به آن افزوده شود. .SS افزودن کارگزارهای DNS معکوس .sp این بخش نحوهٔ افزودن کارگزارهای DNS به یک دامنهٔ DDNS معکوس را شرح می‌دهد. این دستورالعمل‌ها را در صورت نیاز برای تمام کارگزارها در هر دامنه تکرار کنید. .sp مدخل‌های کارگزار DNS معکوس نمایانگر کارگزارهای واقعی DNS هستند که از سمت سرور پروتکل DDNS پشتیبانی می‌کنند. هر کارگزار DNS معکوس دارای پارامترهای زیر است: .INDENT 0.0 .IP \(bu 2 \fBhostname\fP \- نام میزبان قابل‌حلِ کارگزار DNS؛ این مقدار در حال حاضر نادیده گرفته می‌شود. .IP \(bu 2 \fBip\-address\fP \- نشانی IP که کارگزار روی آن به درخواست‌های DDNS گوش فرا می‌دهد. .IP \(bu 2 \fBport\fP \- پورتی که کارگزار روی آن به درخواست‌های DDNS گوش فرا می‌دهد. مقدار پیش‌فرض آن پورت استاندارد سرویس DNS یعنی 53 است. .UNINDENT .sp جهت ایجاد یک کارگزار DNS معکوس جدید، باید یک عنصر کارگزار جدید به دامنه افزوده شده و پارامترهای آن تعیین شوند. اگر به عنوان مثال، سرویس روی \(dq172.88.99.10\(dq در حال اجراست، آن را به شکل زیر تنظیم کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqreverse\-ddns\(dq: { \(dqddns\-domains\(dq: [ { \(dqname\(dq: \(dq1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.\(dq, \(dqkey\-name\(dq: \(dq\(dq, \(dqdns\-servers\(dq: [ { \(dqip\-address\(dq: \(dq172.88.99.10\(dq, \(dqport\(dq: 53 } ] } ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از آنجا که \fBhostname\fP هنوز پشتیبانی نمی‌شود، پارامتر \fBip\-address\fP باید روی نشانی کارگزار DNS تنظیم شود. .UNINDENT .UNINDENT .SS کلیدهای TSIG به ازای هر کارگزار DNS .sp از نسخهٔ 2.0.0 در Kea، می‌توان یک کلید TSIG را در پیکربندی کارگزار DNS مشخص کرد. قاعدهٔ اولویت بدین شرح است: .INDENT 0.0 .IP \(bu 2 اگر یک نام کلید غیرخالی در مدخل کارگزار DNS مشخص شده باشد، این کلید TSIG از به‌روزرسانی‌های DNS ارسال‌شده به این کارگزار محافظت می‌کند. .IP \(bu 2 اگر مدخل کارگزار DNS خالی باشد، اما یک نام کلید غیرخالی در مدخل دامنهٔ والد مشخص شده باشد، کلید TSIG دامنهٔ والد از به‌روزرسانی‌های DNS ارسال‌شده به این کارگزار محافظت می‌کند. .IP \(bu 2 اگر مدخل کارگزار DNS خالی باشد و هیچ نام کلیدی در مدخل دامنهٔ والد آن مشخص نشده باشد، هیچ TSIGای از به‌روزرسانی‌های DNS ارسال‌شده به این کارگزار محافظت نمی‌کند. .UNINDENT .sp برای نمونه، در این پیکربندی: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqforward\-ddns\(dq: { \(dqddns\-domains\(dq: [ { \(dqname\(dq: \(dqother.example.com.\(dq, \(dqkey\-name\(dq: \(dqfoo\(dq, \(dqdns\-servers\(dq: [ { \(dqip\-address\(dq: \(dq172.88.99.10\(dq, \(dqport\(dq: 53 }, { \(dqip\-address\(dq: \(dq172.88.99.11\(dq, \(dqport\(dq: 53, \(dqkey\-name\(dq: \(dqbar\(dq } ] } ] }, \(dqreverse\-ddns\(dq: { \(dqddns\-domains\(dq: [ { \(dqname\(dq: \(dq1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.\(dq, \(dqdns\-servers\(dq: [ { \(dqip\-address\(dq: \(dq172.88.99.12\(dq, \(dqport\(dq: 53 }, { \(dqip\-address\(dq: \(dq172.88.99.13\(dq, \(dqport\(dq: 53, \(dqkey\-name\(dq: \(dqbar\(dq } ] } ] }, \(dqtsig\-keys\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqalgorithm\(dq: \(dqHMAC\-MD5\(dq, \(dqsecret\(dq: \(dqLSWXnfkKZjdPJI5QxlpnfQ==\(dq }, { \(dqname\(dq: \(dqbar\(dq, \(dqalgorithm\(dq: \(dqHMAC\-SHA224\(dq, \(dqsecret\(dq: \(dqbZEG7Ow8OgAUPfLWV3aAUQ==\(dq } ] } .EE .UNINDENT .UNINDENT .sp کارگزار 172.88.99.10 از کلید TSIG با نام \(dqfoo\(dq استفاده خواهد کرد، کارگزارهای 172.88.99.11 و 172.88.99.13 از کلید \(dqbar\(dq استفاده خواهند کرد و 172.88.99.12 از TSIG استفاده نخواهد کرد..SS زمینه‌های کاربری در DDNS .sp برای پیش‌زمینه بیشتر درباره ایده زمینه کاربر (user context)، بخش نظرات و زمینه کاربر \%<#\:user-context> را ببینید. .sp زمینه‌های کاربر را می‌توان در حوزه سراسری (global scope)، یک دامنه DDNS، یک کارساز DNS، یک کلید TSIG و ثبت‌کننده‌ها (loggers) مشخص کرد. یکی دیگر از کاربردهای مفید، قابلیت ذخیره نظرات یا توضیحات است؛ تجزیه‌گر یک مدخل \(dqcomment\(dq را به یک زمینه کاربر به همراه آن مدخل ترجمه می‌کند، که اجازه می‌دهد نظر در داخل خود پیکربندی ضمیمه شود. .SS نمونه پیکربندی کارساز DHCP\-DDNS .sp این بخش یک نمونه پیکربندی کارساز DHCP\-DDNS را بر اساس یک شبکه نمونه کوچک ارائه می‌دهد. فرض کنیم شبکه نمونه ما دارای سه دامنه است که هر کدام زیرشبکه خود را دارند. .SS شبکه نمونه ما .TS box center; l|l|l|l. T{ دامنه T} T{ زیرشبکه T} T{ کارسازهای DNS مستقیم T} T{ کارسازهای DNS معکوس T} _ T{ four.example.com T} T{ 192.0.2.0/24 T} T{ 172.16.1.5, 172.16.2.5 T} T{ 172.16.1.5, 172.16.2.5 T} _ T{ six.example.com T} T{ 2001:db8:1::/64 T} T{ 3001:1::50 T} T{ 3001:1::51 T} _ T{ example.com T} T{ 192.0.0.0/16 T} T{ 172.16.2.5 T} T{ 172.16.2.5 T} .TE .sp ما باید سه دامنه DDNS مستقیم بسازیم: .SS دامنه‌های DDNS مستقیم مورد نیاز .TS box center; l|l|l. T{ # T} T{ نام دامنه DDNS T} T{ کارسازهای DNS T} _ T{ .INDENT 0.0 .IP 1. 3 .UNINDENT T} T{ four.example.com. T} T{ 172.16.1.5, 172.16.2.5 T} _ T{ .INDENT 0.0 .IP 2. 3 .UNINDENT T} T{ six.example.com. T} T{ 3001:1::50 T} _ T{ .INDENT 0.0 .IP 3. 3 .UNINDENT T} T{ example.com. T} T{ 172.16.2.5 T} .TE .sp همان‌طور که پیش‌تر توضیح داده شد، تطبیق FQDN به دامنه بر اساس طولانی‌ترین تطابق (longest match) است. عبارت FQDN \(dqmyhost.four.example.com.\(dq با دامنه اول (\(dqfour.example.com\(dq) تطابق دارد، در حالی که \(dqadmin.example.com.\(dq با دامنه سوم (\(dqexample.com\(dq) مطابقت پیدا می‌کند. عبارت FQDN \(dqother.example.net.\(dq با هیچ دامنه‌ای تطبیق ندارد و رد می‌شود. .sp پیکربندی نمونه زیر دامنه‌های DDNS مستقیم را مشخص می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqcomment\(dq: \(dqexample configuration: forward part\(dq, \(dqforward\-ddns\(dq: { \(dqddns\-domains\(dq: [ { \(dqname\(dq: \(dqfour.example.com.\(dq, \(dqkey\-name\(dq: \(dq\(dq, \(dqdns\-servers\(dq: [ { \(dqip\-address\(dq: \(dq172.16.1.5\(dq }, { \(dqip\-address\(dq: \(dq172.16.2.5\(dq } ] }, { \(dqname\(dq: \(dqsix.example.com.\(dq, \(dqkey\-name\(dq: \(dq\(dq, \(dqdns\-servers\(dq: [ { \(dqip\-address\(dq: \(dq2001:db8::1\(dq } ] }, { \(dqname\(dq: \(dqexample.com.\(dq, \(dqkey\-name\(dq: \(dq\(dq, \(dqdns\-servers\(dq: [ { \(dqip\-address\(dq: \(dq172.16.2.5\(dq } ], \(dquser\-context\(dq: { \(dqbackup\(dq: false } }, ... ] } } .EE .UNINDENT .UNINDENT .sp به طور مشابه، ما باید سه دامنه DDNS معکوس را بسازیم:.SS دامنه‌های معکوس DDNS مورد نیاز .TS box center; l|l|l. T{ # T} T{ نام دامنه DDNS T} T{ کارسازهای DNS T} _ T{ .INDENT 0.0 .IP 1. 3 .UNINDENT T} T{ 2.0.192.in\-addr.arpa. T} T{ 172.16.1.5, 172.16.2.5 T} _ T{ .INDENT 0.0 .IP 2. 3 .UNINDENT T} T{ 1.0.0.0.8.d.b.0.1.0.0.2.ip6.arpa. T} T{ 3001:1::50 T} _ T{ .INDENT 0.0 .IP 3. 3 .UNINDENT T} T{ 0.182.in\-addr.arpa. T} T{ 172.16.2.5 T} .TE .sp آدرس \(dq192.0.2.150\(dq با دامنه نخست، \(dq2001:db8:1::10\(dq با دامنه دوم، و \(dq192.0.50.77\(dq با دامنه سوم مطابقت دارد. .sp این دامنه‌های معکوس DDNS به صورت زیر مشخص می‌شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcpDdns\(dq: { \(dqcomment\(dq: \(dqexample configuration: reverse part\(dq, \(dqreverse\-ddns\(dq: { \(dqddns\-domains\(dq: [ { \(dqname\(dq: \(dq2.0.192.in\-addr.arpa.\(dq, \(dqkey\-name\(dq: \(dq\(dq, \(dqdns\-servers\(dq: [ { \(dqip\-address\(dq: \(dq172.16.1.5\(dq }, { \(dqip\-address\(dq: \(dq172.16.2.5\(dq } ] }, { \(dqname\(dq: \(dq1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.\(dq, \(dqkey\-name\(dq: \(dq\(dq, \(dqdns\-servers\(dq: [ { \(dqip\-address\(dq: \(dq2001:db8::1\(dq } ] }, { \(dqname\(dq: \(dq0.192.in\-addr.arpa.\(dq, \(dqkey\-name\(dq: \(dq\(dq, \(dqdns\-servers\(dq: [ { \(dqip\-address\(dq: \(dq172.16.2.5\(dq } ] }, ... ] } } .EE .UNINDENT .UNINDENT .SS آمارهای کارساز DHCP\-DDNS .sp نسخه 2.0.0 از Kea، پشتیبانی از آمارها را برای DHCP\-DDNS ارائه کرد. .sp آمارها به سه گروه تقسیم می‌شوند: NameChangeRequests، به‌روزرسانی‌های DNS، و به‌روزرسانی‌های DNS بر پایه هر کلید TSIG (per\-TSIG\-key). در حالی که آمارهای دو گروه نخست تجمعی هستند، یعنی با تغییر پیکربندی یا بارگذاری مجدد تحت تأثیر قرار نمی‌گیرند، آمارهای بر پایه هر کلید با ایجاد (یا ایجاد مجدد) شیء مربوطه، به ۰ بازنشانی می‌شوند. .sp در حال حاضر مدیریت آمارهای Kea دارای محدودیت‌های زیر است: .INDENT 0.0 .IP \(bu 2 تنها نمونه‌های عدد صحیح (یعنی یک شمارنده و یک برچسب زمانی) استفاده می‌شوند؛ .IP \(bu 2 بیشینه تعداد نمونه ۱ است؛ .IP \(bu 2 هیچ رابط برنامه‌نویسی‌ای (API) برای حذف یک یا تمام آمارها وجود ندارد؛ .IP \(bu 2 هیچ APIای برای تنظیم بیشینه تعداد نمونه یا طول عمر آن وجود ندارد. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کتابخانه‌های قلاب (Hook libraries)، مانند کتابخانه GSS\-TSIG، آمارهای جدیدی را در Kea در دسترس قرار می‌دهند. .UNINDENT .UNINDENT .sp اطلاعات بیشتر درباره آمارهای Kea را می‌توان در بخش Statistics \%<#\:stats>\& یافت. .SS آمارهای NCR .sp آمارهای مربوط به NameChangeRequest عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBncr\-received\fP \- تعداد NCRهای معتبر دریافتی .IP \(bu 2 \fBncr\-invalid\fP \- تعداد NCRهای نامعتبر دریافتی .IP \(bu 2 \fBncr\-error\fP \- تعداد خطاها در دریافت NCR به‌جز لغو ورودی/خروجی (I/O cancel) هنگام خاموش‌سازی .IP \(bu 2 \fBqueue\-mgr\-queue\-full\fP \- تعداد دفعاتی که صف دریافت NCR به حداکثر ظرفیت خود رسیده است .UNINDENT.SS "آمارهای به‌روزرسانی DNS (DNS Update Statistics)" .sp آمارهای سراسری به‌روزرسانی DNS عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBupdate\-sent\fP \- تعداد به‌روزرسانی‌های DNS ارسال‌شده .IP \(bu 2 \fBupdate\-signed\fP \- تعداد به‌روزرسانی‌های DNS ارسال‌شده و محافظت‌شده با TSIG .IP \(bu 2 \fBupdate\-unsigned\fP \- تعداد به‌روزرسانی‌های DNS ارسال‌شده و محافظت‌نشده با TSIG .IP \(bu 2 \fBupdate\-success\fP \- تعداد به‌روزرسانی‌های DNS که با موفقیت تکمیل شده‌اند .IP \(bu 2 \fBupdate\-timeout\fP \- تعداد به‌روزرسانی‌های DNS که با اتمام مهلت زمانی (timeout) پایان یافته‌اند .IP \(bu 2 \fBupdate\-error\fP \- تعداد به‌روزرسانی‌های DNS که با خطایی غیر از اتمام مهلت زمانی پایان یافته‌اند .UNINDENT .SS "آمارهای به‌روزرسانی DNS بر پایه کلید TSIG (Per\-TSIG\-Key DNS Update Statistics)" .sp آمارهای به‌روزرسانی DNS برای هر کلید TSIG عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBupdate\-sent\fP \- تعداد به‌روزرسانی‌های DNS ارسال‌شده .IP \(bu 2 \fBupdate\-success\fP \- تعداد به‌روزرسانی‌های DNS که با موفقیت تکمیل شده‌اند .IP \(bu 2 \fBupdate\-timeout\fP \- تعداد به‌روزرسانی‌های DNS که با اتمام مهلت زمانی (timeout) پایان یافته‌اند .IP \(bu 2 \fBupdate\-error\fP \- تعداد به‌روزرسانی‌های DNS که با خطایی غیر از اتمام مهلت زمانی پایان یافته‌اند .UNINDENT .sp قالب نام برای آمارهای بر پایه کلید، به صورت \fBkey[].\fP است؛ برای نمونه، نام آمار \fBupdate\-sent\fP برای کلید TSIG با عنوان \fBkey.example.com.\fP برابر با \fBkey[key.example.com.].update\-sent\fP\& است. .SS "محدودیت‌های کارگزار DHCP\-DDNS (DHCP\-DDNS Server Limitations)" .sp موارد زیر محدودیت‌های کنونی کارگزار DHCP\-DDNS هستند. .INDENT 0.0 .IP \(bu 2 درخواست‌های دریافتی از کارگزارهای DHCP تا زمان پردازش در صف قرار می‌گیرند. در حال حاضر، در صورت خاموش شدن کارگزار، تمام درخواست‌های موجود در صف از دست می‌روند. .UNINDENT .SS "استانداردهای پشتیبانی‌شده (Supported Standards)" .sp RFCهای زیر توسط کارگزار DHCP\-DDNS پشتیبانی می‌شوند: .INDENT 0.0 .IP \(bu 2 \fISecret Key Transaction Authentication for DNS (TSIG)\fP، RFC 2845 \%: تمام بسته‌های به‌روزرسانی DNS ارسال‌شده و دریافت‌شده توسط کارگزار DHCP\-DDNS می‌توانند با امضاهای TSIG محافظت شوند. .IP \(bu 2 \fIDynamic Updates in the Domain Name System (DNS UPDATE)\fP، RFC 2136 \%: سازوکار کامل به‌روزرسانی DNS پشتیبانی می‌شود. .IP \(bu 2 \fIResolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients\fP، RFC 4703 \%: DHCP\-DDNS وظیفه حل تعارض را برای هر دو کارگزار DHCPv4 و DHCPv6 انجام می‌دهد. .IP \(bu 2 \fIA DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)\fP، RFC 4701 \%: کارگزار DHCP\-DDNS از رکوردهای DHCID استفاده می‌کند. .UNINDENT .SH "فرآیند LFC (THE LFC PROCESS)" .SS "نمای کلی (Overview)" .sp \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> یک فرآیند سرویس است که اطلاعات زائد را از فایل‌های مورد استفاده برای ذخیره‌سازی پایدار در بک‌اند پایگاه‌داده memfile پاک‌سازی می‌کند. این سرویس برای اجرا به عنوان یک فرآیند مستقل نوشته شده است. .sp اگرچه \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> را می‌توان به صورت خارجی آغاز کرد، معمولاً نیازی به انجام این کار نیست. \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> به صورت دوره‌ای توسط کارگزارهای Kea DHCP اجرا می‌شود و از نسخه Kea 3.1.2 می‌تواند با استفاده از دستور \fBkea\-lfc\-start\fP راه‌اندازی شود. .sp این فرآیند روی مجموعه‌ای از فایل‌ها کار می‌کند و از آن‌ها برای دریافت ورودی و ثبت خروجی ورودی‌های اجاره (lease entries) و نشان دادن مرحله‌ای که فرآیند در صورت بروز وقفه در آن قرار دارد، استفاده می‌کند. در حال حاضر فراخواننده باید نام همه این فایل‌ها را مشخص کند. .SS "گزینه‌های خط فرمان (Command\-Line Options)" .sp \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> به صورت زیر اجرا می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX kea\-lfc [\-4 | \-6] \-c config\-file \-p pid\-file \-x previous\-file \-i copy\-file \-o output\-file \-f finish\-file .EE .UNINDENT .UNINDENT .sp آرگومان \fB\-4\fP یا \fB\-6\fP نسخه پروتکل فایل‌های اجاره را انتخاب می‌کند. .sp آرگومان \fB\-c\fP فایل پیکربندی را مشخص می‌کند. این آرگومان الزامی است، اما در حال حاضر توسط فرآیند استفاده نمی‌شود. .sp آرگومان \fB\-p\fP فایل PID را مشخص می‌کند. هنگامی که فرآیند \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> آغاز می‌شود، با بررسی فایل PID تلاش می‌کند تشخیص دهد که آیا نمونه دیگری از فرآیند از قبل در حال اجرا است یا خیر. اگر نمونه‌ای در حال اجرا باشد، فرآیند جدید خاتمه می‌یابد؛ اگر در حال اجرا نباشد، Kea شناسه فرآیند (PID) خود را در فایل PID می‌نویسد. .sp سایر نام‌های فایل مشخص می‌کنند که فرآیند \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> کجا باید به دنبال ورودی بگردد، خروجی خود را بنویسد و وظایف ثبت وضعیت (bookkeeping) خود را انجام دهد: .INDENT 0.0 .IP \(bu 2 \fBprevious\fP — هنگامی که \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> آغاز می‌شود، این فایل نتیجه اجرای قبلی \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc>\& است. هنگامی که \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> پایان می‌یابد، نتیجه این اجرا خواهد بود. اگر اجرای \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> پیش از تکمیل متوقف شود، ممکن است این فایل وجود نداشته باشد. .IP \(bu 2 \fBinput\fP — پیش از آنکه کارگزار DHCP فرآیند \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> را فراخوانی کند، فایل اجاره فعلی را به اینجا منتقل کرده و سپس \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> را با این فایل فراخوانی می‌کند. .IP \(bu 2 \fBoutput\fP — این فایل موقتی است که \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> اجاره‌ها را در آن می‌نویسد. پس از پایان نوشتن در فایل، به فایل \fBfinish\fP منتقل می‌شود (در ادامه ببینید). .IP \(bu 2 \fBfinish\fP — این یک فایل موقت دیگر است که \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> برای ثبت وضعیت استفاده می‌کند. هنگامی که \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> نوشتن در فایل \fBoutput\fP را تکمیل کرد، محتویات را به فایلی با این نام منتقل می‌کند. پس از اینکه \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> حذف فایل‌های دیگر (\fBprevious\fP و \fBinput\fP) را به پایان رساند، این فایل را به فایل اجاره \fBprevious\fP منتقل می‌کند. با انتقال فایل‌ها به این روش، فرآیندهای \fBkea\-lfc\fP \%<#\:std-iscman-kea-lfc> و کارگزار DHCP می‌توانند حتی در صورتی که یکی از فرآیندها پیش از پایان وظیفه خود دچار وقفه شود، فایل درست را برای استفاده تشخیص دهند. .UNINDENT .sp چندین آرگومان دیگر نیز وجود دارند که بیشتر برای اهداف اشکال‌زدایی به کار می‌روند. \fB\-d\fP سطح ثبت وقایع (logging) را روی حالت اشکال‌زدایی (debug) تنظیم می‌کند. \fB\-v\fP و \fB\-V\fP برچسب‌های نسخه را چاپ می‌کنند که \fB\-V\fP قالب طولانی‌تری ارائه می‌دهد. \fB\-h\fP متن راهنمای استفاده را نمایش می‌دهد..SH "دسته‌بندی کلاینت (CLIENT CLASSIFICATION)" .SS "نمای کلی دسته‌بندی کلاینت (Client Classification Overview)" .sp در موارد خاص، تفکیک بین انواع مختلف کلاینت‌ها و رفتار مناسب با هر یک مفید است. دلایل متداول عبارتند از: .INDENT 0.0 .IP \(bu 2 کلاینت‌ها بخش‌های متفاوتی از توپولوژی را نشان می‌دهند؛ به عنوان مثال، یک مودم کابلی (cable modem) با کلاینت‌های پشت آن مودم یکسان نیست. .IP \(bu 2 کلاینت‌ها رفتار متفاوتی دارند؛ به عنوان مثال، رفتار یک گوشی هوشمند با یک لپ‌تاپ تفاوت دارد. .IP \(bu 2 کلاینت‌ها برای برخی گزینه‌ها به مقادیر متفاوتی نیاز دارند؛ به عنوان مثال، یک مودم کابلی docsis3.0 به تنظیماتی متفاوت نسبت به یک مودم کابلی docsis2.0 نیاز دارد. .UNINDENT .sp برای ساده‌تر شدن مدیریت، کلاینت‌های مختلف می‌توانند در یک کلاس کلاینت (client class) گروه‌بندی شوند تا گزینه‌های مشترکی را دریافت کنند. .sp یک بسته ورودی می‌تواند به چندین روش به یک کلاس کلاینت منتسب شود: .INDENT 0.0 .IP \(bu 2 به‌طور ضمنی، با استفاده از یک گزینه vendor class یا شرط داخلی (built\-in) دیگر. .IP \(bu 2 با استفاده از عبارتی که مقدار آن به \fBtrue\fP ارزیابی شود. .IP \(bu 2 با استفاده از رزروهای میزبان ایستا (static host reservations)، یک shared network، یک subnet و غیره. .IP \(bu 2 با استفاده از یک hook. .UNINDENT .sp دسته‌بندی کلاینت می‌تواند برای تغییر رفتار تقریباً هر بخشی از پردازش پیام‌های DHCP استفاده شود. در حال حاضر ۹ سازوکار وجود دارند که از دسته‌بندی کلاینت بهره می‌برند: .INDENT 0.0 .IP \(bu 2 دور انداختن پرس‌وجوها (Dropping queries). .IP \(bu 2 انتخاب زیرشبکه (Subnet selection). .IP \(bu 2 انتخاب استخر (Pool selection). .IP \(bu 2 محدود کردن اجاره (Lease limiting). .IP \(bu 2 محدود کردن نرخ (Rate limiting). .IP \(bu 2 تنظیم DDNS. .IP \(bu 2 تعریف گزینه‌های اختصاصی DHCPv4 (کدهای ۲۲۴\-۲۵۴) و گزینه‌های کد ۴۳. .IP \(bu 2 اختصاص گزینه‌های متفاوت. .IP \(bu 2 تنظیم گزینه‌های خاص برای استفاده با آدرس سرور TFTP و فیلد فایل بوت (boot file) برای مودم‌های کابلی DHCPv4. .UNINDENT .SS "مراحل دسته‌بندی (Classification Steps)" .sp فرایند دسته‌بندی در چندین مرحله انجام می‌شود: .INDENT 0.0 .IP 1. 3 کلاس \fBALL\fP به بسته ورودی منتسب می‌شود. .IP 2. 3 گزینه‌های vendor class پردازش می‌شوند. .IP 3. 3 کلاس‌های دارای عبارات منطبق‌سازی که برای ارزیابی بعدی نشانه‌گذاری نشده‌اند (\(dqon request\(dq یا وابسته به کلاس‌های داخلی \fBKNOWN\fP/\fBUNKNOWN\fP)، به ترتیبی که در پیکربندی تعریف شده‌اند پردازش می‌شوند؛ عبارت بولی ارزیابی شده و در صورتی که مقدار \fBtrue\fP (تطابق) را برگرداند، بسته ورودی به آن کلاس منتسب می‌شود. .IP 4. 3 در صورت دریافت گزینه اختصاصی یا گزینه کد ۴۳ در DHCPv4، آن گزینه بر اساس تعریف client\-class یا سراسری (یا برای گزینه ۴۳، آخرین راهکار/last\-resort) رمزگشایی می‌شود. .IP 5. 3 هنگامی که بسته ورودی متعلق به کلاس ویژه \fBDROP\fP باشد، دور انداخته می‌شود و یک پیام اطلاع‌رسانی به همراه اطلاعات بسته ثبت می‌شود. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 فراخوان‌های \fBpkt4_receive\fP و \fBpkt6_receive\fP در اینجا اجرا می‌شوند. .UNINDENT .UNINDENT .INDENT 0.0 .IP 6. 3 هنگامی که پارامتر سراسری \fBearly\-global\-reservations\-lookup\fP بر روی \fBtrue\fP تنظیم شده باشد، این فرایند به جستجوی رزروهای سراسری پرداخته و مراحل ۸، ۹ و ۱۰ را به‌طور جزئی اجرا می‌کند. این جستجو محدود به رزروهای سراسری است؛ اگر موردی یافت شود، کلاس \fBKNOWN\fP تنظیم می‌شود، اما در صورت عدم یافتن، کلاس \fBUNKNOWN\fP تنظیم \fBنمی‌شود\fP. .IP 7. 3 یک زیرشبکه انتخاب می‌شود، احتمالاً بر اساس اطلاعات کلاس، زمانی که برخی از زیرشبکه‌ها رزرو شده باشند. دقیق‌تر: هنگام انتخاب یک زیرشبکه، سرور در میان تمام زیرشبکه‌هایی که با توجه به اطلاعات موجود در بسته (آدرس کلاینت، آدرس رله و غیره) امکان‌پذیر هستند، پیمایش می‌کند. سرور از اولین زیرشبکه‌ای استفاده می‌کند که یا هیچ کلاسی به آن منتسب نشده باشد، یا دارای کلاسی باشد که با یکی از کلاس‌های بسته مطابقت دارد. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 فراخوان‌های \fBsubnet4_select\fP و \fBsubnet6_select\fP در اینجا اجرا می‌شوند. .UNINDENT .UNINDENT .INDENT 0.0 .IP 8. 3 سرور به دنبال رزروهای میزبان (host reservations) می‌گردد. اگر شناسه‌ای از بسته ورودی با یک رزرو میزبان در زیرشبکه یا shared network مطابقت داشته باشد، بسته به کلاس \fBKNOWN\fP و تمام کلاس‌های آن رزرو میزبان منتسب می‌شود. اگر رزروی یافت نشود، بسته به کلاس \fBUNKNOWN\fP تخصیص می‌یابد. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگر یک رزرو منطبق از زیرشبکه انتخاب‌شده وجود داشته باشد و آن زیرشبکه متعلق به یک shared\-network باشد، انتساب هر کلاسی که در رزرو مشخص شده است تا پس از تخصیص اجاره به تعویق می‌افتد. این کار به دلیل در نظر گرفتن این احتمال انجام می‌شود که ممکن است انتخاب زیرشبکه در طول تخصیص اجاره تغییر کند و این امر تطابق رزرو اولیه را باطل کرده و احتمالاً جایگزین نماید. .UNINDENT .UNINDENT .INDENT 0.0 .IP 9. 3 کلاس‌های دارای عبارات تطابق \- چه به صورت مستقیم یا غیرمستقیم با استفاده از کلاس‌های داخلی \fBKNOWN\fP/\fBUNKNOWN\fP و بدون نشانه‌گذاری برای ارزیابی بعدی (\(dqon request\(dq) \- به ترتیبی که در پیکربندی تعریف شده‌اند پردازش می‌شوند؛ عبارت بولی ارزیابی می‌شود و در صورت بازگرداندن \fBtrue\fP (تطابق)، بسته ورودی به آن کلاس منتسب می‌گردد. پس از انتخاب یک زیرشبکه، سرور مشخص می‌کند که آیا رزروی برای کلاینت مشخص وجود دارد یا خیر. بنابراین، استفاده از کلاس \fBUNKNOWN\fP برای انتخاب یک shared network یا یک subnet امکان‌پذیر نیست. برای کلاس \fBKNOWN\fP، تنها از رزروهای سراسری استفاده می‌شود و پارامتر \fBearly\-global\-reservations\-lookup\fP باید روی \fBtrue\fP تنظیم شده باشد. .IP 10. 3 هنگامی که بسته ورودی متعلق به کلاس ویژه \fBDROP\fP باشد، دور انداخته می‌شود و یک پیام اطلاع‌رسانی به همراه اطلاعات بسته ثبت می‌شود. از نگارش ۱.۹.۸ برنامه Kea به بعد، وابسته کردن کلاس \fBDROP\fP به کلاس‌های \fBKNOWN\fP/\fBUNKNOWN\fP مجاز است. .IP 11. 3 در صورت نیاز، آدرس‌ها و پیشوندها از استخرها (pools) تخصیص می‌یابند، که در صورت رزرو بودن برخی استخرها برای اعضای کلاس، ممکن است بر اساس اطلاعات کلاس انجام پذیرد. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 فراخوان‌های \fBlease4_select\fP، \fBlease4_renew\fP، \fBlease6_select\fP، \fBlease6_renew\fP و \fBlease6_rebind\fP در اینجا اجرا می‌شوند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگر یک رزرو میزبان منطبق از زیرشبکه انتخاب‌شده وجود داشته باشد و آن زیرشبکه متعلق به یک shared\-network باشد، هر کلاسی که در رزرو مشخص شده است تخصیص داده می‌شود. .UNINDENT .UNINDENT .INDENT 0.0 .IP 12. 4 فهرست‌های \fBevaluate\-additional\-classes\fP (در صورت وجود) ابتدا برای pool، سپس subnet و در نهایت shared\-network که منابع تخصیص‌یافته به آن تعلق دارند، ارزیابی می‌شوند. کلاس‌ها به همان ترتیبی که در هر فهرست آمده‌اند ارزیابی می‌شوند. .IP 13. 4 گزینه‌ها مجدداً احتمالاً بر اساس اطلاعات کلاس و به ترتیبی که کلاس‌ها به بسته ورودی منتسب شده‌اند، اختصاص داده می‌شوند. اولین کلاسی که با بسته تطابق داشته و گزینه مشخص‌شده‌ای را معین کند، اولویت دارد. برای گزینه‌های اختصاصی و کد ۴۳ در DHCPv4، این شامل تعاریف گزینه مشخص‌شده درون کلاس‌ها نیز می‌شود. ترتیب اولویت گزینه‌ها به صورت زیر است: .INDENT 4.0 .IP 1. 3 گزینه‌های میزبان (Host options) .IP 2. 3 گزینه‌های استخر (Pool options) .IP 3. 3 گزینه‌های زیرشبکه (Subnet options) .IP 4. 3 گزینه‌های شبکه مشترک (Shared network options) .IP 5. 3 گزینه‌های کلاس‌های اختصاص‌یافته در طول دسته‌بندی عادی: .INDENT 4.0 .INDENT 3.5 .INDENT 0.0 .IP a. 3 کلاس \fBALL\fP.IP b. 3 کلاس‌های سازنده (Vendor classes) .IP c. 3 کلاس‌های میزبان (Host classes) .IP d. 3 کلاس‌های ارزیابی‌شده‌ای که به کلاس \fBKNOWN\fP وابسته نیستند .IP e. 3 کلاس‌های \fBKNOWN\fP و \fBUNKNOWN\fP .IP f. 3 کلاس‌های ارزیابی‌شده‌ای که به کلاس \fBKNOWN\fP وابسته‌اند .UNINDENT .UNINDENT .UNINDENT .IP 6. 3 گزینه‌های مربوط به کلاس‌ها در \fBevaluate\-additional\-classes\fP از: .INDENT 4.0 .INDENT 3.5 .INDENT 0.0 .IP a. 3 استخر (Pool) .IP b. 3 زیرشبکه (Subnet) .IP c. 3 شبکه مشترک (Shared network) .UNINDENT .UNINDENT .UNINDENT .IP 7. 3 گزینه‌های سراسری (Global options) .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در دسته‌بندی کلاینت‌ها باید دقت به خرج داد، زیرا برای کلاینت‌هایی که معیارهای هیچ کلاسی را برآورده نمی‌کنند، این احتمال به سادگی وجود دارد که به کلی از دریافت سرویس محروم شوند. .UNINDENT .UNINDENT .SS کلاس‌های توکار کلاینت (Built\-in Client Classes) .sp برخی کلاس‌ها توکار هستند، بنابراین نیازی به تعریف صریح آن‌ها نیست. در صورت نیاز به پیوند دادن طول عمر اجاره (lease lifetime)، داده‌های گزینه و غیره با آن‌ها، می‌توان آن‌ها را تعریف کرد. .sp اطلاعات کلاس سازنده (vendor class) نمونه اصلی این مورد است: سرور بررسی می‌کند که آیا بسته ورودی DHCPv4 شامل گزینه شناسه کلاس سازنده (60) هست یا بسته ورودی DHCPv6 شامل گزینه کلاس سازنده (16) می‌باشد. اگر چنین باشد، محتوای آن گزینه با پیشوند \fBVENDOR_CLASS_\fP همراه شده و نتیجه به عنوان کلاسی برای آن بسته تفسیر می‌شود. محتوایی که در نظر گرفته می‌شود کل شناسه کلاس برای DHCPv4، و اولین فیلد داده کلاس سازنده برای DHCPv6 است. شماره سازمانی (enterprise number) و فیلدهای داده کلاس سازنده پس از آن برای اهداف دسته‌بندی استفاده نمی‌شوند. برای مثال، مودم‌های کابلی امروزی چنین گزینه‌هایی را با مقدار \fBdocsis3.0\fP ارسال می‌کنند، بنابراین بسته متعلق به کلاس \fBVENDOR_CLASS_docsis3.0\fP خواهد بود\&. .sp پیشوند \fBHA_\fP توسط \fBlibdhcp_ha.so\fP \%<#\:std-ischooklib-libdhcp_ha\:.so> برای تعیین سرورهای خاصی جهت پردازش بسته‌های DHCP در نتیجه توازن بار (load balancing) استفاده می‌شود. نام کلاس با اضافه کردن پیشوند \fBHA_\fP به ابتدای نام سروری که باید بسته DHCP را پردازش کند ساخته می‌شود. این سرور بر اساس کلاس‌های کلاینت اختصاص‌یافته، از استخر یا زیرشبکه مناسبی برای تخصیص آدرس‌های IP (و/یا پیشوندها) استفاده می‌کند. جزئیات را می‌توان در libdhcp_ha.so: High Availability Outage Resilience for Kea Servers \%<#\:hooks-high-availability>\& یافت. .sp پیشوند \fBSPAWN_\fP توسط کلاس‌های الگو (template classes) برای تولید نام‌های کلاس مشتق‌شده (spawned) در زمان اجرا استفاده می‌شود. نام کلاس مشتق‌شده با الحاق پیشوند \fBSPAWN_\fP به ابتدای نام کلاس الگو و مقدار ارزیابی‌شده ساخته می‌شود: \fBSPAWN__\fP\&. جزئیات بیشتر را می‌توان در Configuring Classes یافت\&. .sp کلاس \fBBOOTP\fP توسط \fBlibdhcp_bootp.so\fP \%<#\:std-ischooklib-libdhcp_bootp\:.so> برای دسته‌بندی و پاسخ‌گویی به پرس‌وجوهای ورودی BOOTP استفاده می‌شود. .sp کلاس \fBSKIP_DDNS\fP توسط کتابخانه قلابِ تنظیم DDNS (DDNS\-tuning hook library) برای لغو به‌روزرسانی‌های DDNS بر اساس هر کلاینت استفاده می‌شود. .sp نمونه‌های دیگر شامل کلاس \fBALL\fP است که تمامی بسته‌های ورودی به آن تعلق دارند، و کلاس \fBKNOWN\fP که هنگام وجود رزرو میزبان (host reservation) برای یک کلاینت خاص اختصاص می‌یابد. طبق قرارداد، نام کلاس‌های توکار همگی با حروف بزرگ آغاز می‌شود. .sp نام‌های کلاس‌های توکار که در حال حاضر شناسایی می‌شوند عبارتند از \fBALL\fP، \fBKNOWN\fP و \fBUNKNOWN\fP، و پیشوندهای \fBVENDOR_CLASS_\fP، \fBHA_\fP، \fBAFTER_\fP، \fBEXTERNAL_\fP، \fBSKIP_DDNS\fP\&. اگرچه پیشوند \fBAFTER_\fP تمهیدی برای یک قلاب (hook) هنوز نوشته‌نشده است، پیشوند \fBEXTERNAL_\fP را می‌توان آزادانه استفاده کرد؛ کلاس‌های توکار به صورت ضمنی تعریف شده‌اند، بنابراین اگر در پیکربندی ظاهر نشوند، هرگز هشداری صادر نمی‌کنند. .SS استفاده از عبارت‌ها در دسته‌بندی (Using Expressions in Classification) .sp بخش عبارت (expression) از یک تعریف دسته‌بندی شامل عملگرها و مقادیر است. در حال حاضر تمامی مقادیر رشته هستند؛ عملگرها یک یا چند رشته را به عنوان ورودی گرفته و رشته دیگری برمی‌گردانند. هنگامی که تمام عملیات پایان یافت، نتیجه باید مقداری از نوع \fBtrue\fP یا \fBfalse\fP باشد\&. در صورتی که نتیجه \fBtrue\fP باشد، بسته متعلق به آن کلاس است (و نام کلاس به فهرست کلاس‌ها اضافه می‌شود)\&. عبارت‌ها در قالب استاندارد نوشته می‌شوند و می‌توانند تودرتو باشند. .sp عبارت‌ها هنگام تجزیه فایل پیکربندی پیش‌پردازش شده و به یک نمایش داخلی تبدیل می‌شوند. این امر امکان شناسایی و ثبت انواع خاصی از خطاها را در زمان تجزیه فراهم می‌کند. نمونه‌هایی از این خطاها شامل تعداد یا نوع نادرست آرگومان ورودی برای یک عملگر است. کد ارزیابی نیز این دسته از خطاها را بررسی کرده و معمولاً یک استثنا صادر می‌کند (throw exception)، اگرچه این حالت در یک سیستم با عملکرد عادی نباید رخ دهد. .sp سایر موارد، از جمله قرار گرفتن موقعیت شروع یک زیررشته در خارج از محدوده آن زیررشته یا عدم وجود یک گزینه در بسته، منجر به بازگرداندن یک رشته خالی توسط عملگر می‌شود. .sp وابستگی‌های بین کلاس‌ها نیز بررسی می‌شوند. برای نمونه، وابستگی‌های رو به جلو (forward dependencies) هنگام تجزیه پیکربندی رد می‌شوند؛ یک عبارت تنها می‌تواند به کلاس‌های از پیش تعریف‌شده (از جمله کلاس‌های توکار) وابسته باشد که در یک مرحله ارزیابی قبلی یا همان مرحله ارزیابی شده‌اند. این موضوع برای کلاس‌های \fBKNOWN\fP یا \fBUNKNOWN\fP اعمال نمی‌شود. .SS فهرست مقادیر دسته‌بندی (List of classification values) .TS box center; l|l|l. T{ نام T} T{ عبارت نمونه T} T{ مقدار نمونه T} _ T{ رشته لفظی T} T{ \(aqexample\(aq T} T{ \(aqexample\(aq T} _ T{ رشته هگزادسیمال لفظی T} T{ 0x5a7d T} T{ \(aqZ}\(aq T} _ T{ آدرس IP لفظی T} T{ 10.0.0.1 T} T{ 0x0a000001 T} _ T{ عدد صحیح لفظی T} T{ 123 T} T{ \(aq123\(aq T} _ T{ محتوای باینری گزینه T} T{ option[123].hex T} T{ \(aq(content of the option)\(aq T} _ T{ وجود گزینه T} T{ option[123].exists T} T{ \(aqtrue\(aq T} _ T{ محتوای باینری زیرگزینه T} T{ option[12].option[34].hex T} T{ \(aq(content of the sub\-option)\(aq T} _ T{ وجود زیرگزینه T} T{ option[12].option[34].exists T} T{ \(aqtrue\(aq T} _ T{ عضویت در کلاس کلاینت T} T{ member(\(aqfoobar\(aq) T} T{ \(aqtrue\(aq T} _ T{ کلاینت شناخته‌شده T} T{ known T} T{ member(\(aqKNOWN\(aq) T} _ T{ کلاینت ناشناخته T} T{ unknown T} T{ not member(\(aqKNOWN\(aq) T} _ T{ زیرگزینه عامل رله DHCPv4 T} T{ relay4[123].hex T} T{ \(aq(content of the RAI sub\-option)\(aq T} _ T{ گزینه‌های رله DHCPv6 T} T{ relay6[nest].option[code].hex T} T{ (value of the option) T} _ T{ آدرس همتای رله DHCPv6 T} T{ relay6[nest].peeraddr T} T{ 2001:DB8::1 T} _ T{ آدرس پیوند رله DHCPv6 T} T{ relay6[nest].linkaddr T} T{ 2001:DB8::1 T} _ T{ نام رابط بسته T} T{ pkt.iface T} T{ eth0 T} _ T{ آدرس مبدأ بسته T} T{ pkt.src T} T{ 10.1.2.3 T} _ T{ آدرس مقصد بسته T} T{ pkt.dst T} T{ 10.1.2.3 T} _ T{ طول بسته T} T{ pkt.len T} T{ 513 T} _ T{ آدرس سخت‌افزاری در بسته DHCPv4 T} T{ pkt4.mac T} T{ 0x010203040506 T} _ T{ طول سخت‌افزار در بسته DHCPv4 T} T{ pkt4.hlen T} T{ 6 T} _ T{ نوع سخت‌افزار در بسته DHCPv4 T} T{ pkt4.htype T} T{ 6 T} _ T{ فیلد ciaddr در بسته DHCPv4 T} T{ pkt4.ciaddr T} T{ 192.0.2.1 T} _ T{ فیلد giaddr در بسته DHCPv4 T} T{ pkt4.giaddr T} T{ 192.0.2.1 T} _ T{ فیلد yiaddr در بسته DHCPv4 T} T{ pkt4.yiaddr T} T{ 192.0.2.1 T} _ T{ فیلد siaddr در بسته DHCPv4 T} T{ pkt4.siaddr T} T{ 192.0.2.1 T} _ T{ نوع پیام در بسته DHCPv4 T} T{ pkt4.msgtype T} T{ 1 T} _ T{ شناسه تراکنش (xid) در بسته DHCPv4 T} T{ pkt4.transid T} T{ 12345 T} _ T{ نوع پیام در بسته DHCPv6 T} T{ pkt6.msgtype T} T{ 1 T} _ T{ شناسه تراکنش در بسته DHCPv6 T} T{ pkt6.transid T} T{ 12345 T} _ T{ وجود گزینه سازنده (هر سازنده‌ای) T} T{ vendor[*].exists T} T{ \(aqtrue\(aq T} _ T{ وجود گزینه سازنده (سازنده خاص) T} T{ vendor[4491].exists T} T{ \(aqtrue\(aq T} _ T{ شناسه سازمانی (enterprise\-id) از گزینه سازنده T} T{ vendor.enterprise T} T{ 4491 T} _ T{ وجود زیرگزینه سازنده T} T{ vendor[4491].option[1].exists T} T{ \(aqtrue\(aq T} _ T{ محتوای زیرگزینه سازنده T} T{ vendor[4491].option[1].hex T} T{ docsis3.0 T} _ T{ وجود گزینه کلاس سازنده (هر سازنده‌ای) T} T{ vendor\-class[*].exists T} T{ \(aqtrue\(aq T} _ T{ وجود گزینه کلاس سازنده (سازنده خاص) T} T{ vendor\-class[4491].exists T} T{ \(aqtrue\(aq T} _ T{ شناسه سازمانی (enterprise\-id) از گزینه کلاس سازنده T} T{ vendor\-class.enterprise T} T{ 4491 T} _ T{ نخستین بخش داده از گزینه کلاس سازنده T} T{ vendor\-class[4491].data T} T{ docsis3.0 T} _ T{ بخش داده خاص از گزینه کلاس سازنده T} T{ vendor\-class[4491].data[3] T} T{ docsis3.0 T} .TE .sp نکات: .INDENT 0.0.IP \(bu 2 رشته‌های هگزادسیمال همان‌گونه که انتظار می‌رود به یک رشته تبدیل می‌شوند. \fB0X\fP یا \fB0x\fP ابتدایی حذف می‌شود، و اگر تعداد نویسه‌های رشته فرد باشد، یک \(dq0\(dq به ابتدای آن افزوده می‌شود. .IP \(bu 2 آدرس‌های IP به رشته‌هایی به طول ۴ یا ۱۶ تبدیل می‌شوند. آدرس‌های IPv4،‏ IPv6 و IPv4 تعبیه‌شده در IPv6 (مانند IPv4\-mapped IPv6) پشتیبانی می‌شوند. .IP \(bu 2 اعداد صحیح در یک عبارت به اعداد صحیح ۳۲\-بیتی بدون علامت تبدیل می‌شوند و به‌صورت رشته‌های چهار بایتی نشان داده می‌شوند؛ برای نمونه، 123 به‌صورت \fB0x0000007b\fP\& نمایش داده می‌شود. تمام عبارت‌هایی که مقادیر عددی برمی‌گردانند، از اعداد صحیح ۳۲\-بیتی بدون علامت استفاده می‌کنند، حتی اگر فیلد مربوطه در بسته کوچک‌تر باشد. به‌طور کلی، استفاده از نماد ده‌دهی برای نمایش اعداد صحیح آسان‌تر است، اما استفاده از نماد هگزادسیمال نیز امکان‌پذیر است. هنگام نوشتن یک عدد صحیح در مبنای شانزده، باید دقت شود که مقدار حتماً به‌صورت ۳۲ بیت نشان داده شود، مثلاً به‌جای \fB0x1\fP یا \fB0x01\fP\& از \fB0x00000001\fP استفاده کنید. همچنین، مطمئن شوید که مقدار در ترتیب بایت شبکه (network order) مشخص شده باشد، برای نمونه 1 به‌صورت \fB0x00000001\fP\& نمایش می‌یابد. .IP \(bu 2 عبارت \fBoption[code].hex\fP مقدار گزینه‌ای با کد \fBcode\fP را از بستهٔ دریافتی استخراج می‌کند. اگر بسته فاقد این گزینه باشد، یک رشتهٔ خالی برمی‌گرداند. این رشته به‌صورت یک رشتهٔ بایتی از بار دادهٔ (payload) گزینه، بدون فیلدهای کد نوع یا طول ارائه می‌شود. .IP \(bu 2 عبارت \fBoption[code].exists\fP بررسی می‌کند که آیا گزینه‌ای با کد \fBcode\fP در بستهٔ دریافتی وجود دارد یا خیر. این عبارت را می‌توان با گزینه‌های خالی نیز به‌کار برد. .IP \(bu 2 عبارت \fBmember(\(aqfoobar\(aq)\fP بررسی می‌کند که آیا بسته متعلق به کلاس کلاینت \fBfoobar\fP\& است یا خیر. برای جلوگیری از حلقه‌های وابستگی، تجزیه‌گر فایل پیکربندی بررسی می‌کند که آیا کلاس‌های کلاینت از قبل تعریف شده‌اند یا توکار هستند، یعنی با \fBVENDOR_CLASS_\fP، \fBAFTER_\fP (برای قلابِ آیندهٔ \(dqafter\(dq) و \fBEXTERNAL_\fP آغاز می‌شوند یا برابر با \fBALL\fP، \fBKNOWN\fP، \fBUNKNOWN\fP و غیره هستند. .sp کلمات \fBknown\fP و \fBunknown\fP حالت‌های کوتاه‌شده برای \fBmember(\(aqKNOWN\(aq)\fP و \fBnot member(\(aqKNOWN\(aq)\fP\& هستند. توجه داشته باشید که ارزیابی هر عبارتی که از کلاس \fBKNOWN\fP (به‌صورت مستقیم یا غیرمستقیم) استفاده می‌کند، به پس از جستجوی رزرو میزبان موکول می‌شود (یعنی زمانی که افرازِ \fBKNOWN\fP یا \fBUNKNOWN\fP مشخص شده باشد). .IP \(bu 2 عبارت \fBrelay4[code].hex\fP تلاش می‌کند تا مقدار زیرگزینهٔ \fBcode\fP را از گزینه‌ای که به‌عنوان گزینهٔ اطلاعات عامل رلهٔ DHCPv4 یا DHCPv4 Relay Agent Information (82) درج شده است، استخراج کند. اگر بسته فاقد گزینهٔ RAI باشد، یا گزینهٔ RAI شامل زیرگزینهٔ درخواستی نباشد، عبارت یک رشتهٔ خالی برمی‌گرداند. این رشته به‌صورت یک رشتهٔ بایتی از بار دادهٔ گزینه بدون فیلدهای کد نوع یا طول ارائه می‌شود. استفاده از این عبارت تنها در DHCPv4 مجاز است. .IP \(bu 2 عبارت \fBrelay4\fP از همان انواع نمایش مشابه با \fBoption\fP استفاده می‌کند؛ برای نمونه، \fBrelay4[code].exists\fP پشتیبانی می‌شود. .IP \(bu 2 عبارت \fBrelay6[nest]\fP امکان دسترسی به کپسوله‌سازی‌های استفاده‌شده توسط هر رلهٔ DHCPv6 را که بسته را هدایت کرده است فراهم می‌کند. سطح \fBnest\fP رله‌ای را مشخص می‌کند که اطلاعات باید از آن استخراج شود، به‌طوری که مقدار 0 نشان‌دهندهٔ نزدیک‌ترین رله به کارساز DHCPv6 است. مقادیر منفی امکان شمارش رله‌ها را از سمت کلاینت DHCPv6 فراهم می‌کنند، به‌طوری که \-1 نشان‌دهندهٔ نزدیک‌ترین رله به کلاینت است. اگر کپسوله‌سازی درخواستی وجود نداشته باشد، رشتهٔ خالی \fB\(dq\(dq\fP برگردانده می‌شود. این عبارت تنها در DHCPv6 مجاز است. .IP \(bu 2 عبارت \fBrelay6[nest].option[code]\fP از همان انواع نمایش مشابه با \fBoption\fP استفاده می‌کند؛ برای نمونه، \fBrelay6[nest].option[code].exists\fP پشتیبانی می‌شود. .IP \(bu 2 عبارت‌هایی که با \fBpkt4\fP آغاز می‌شوند تنها در DHCPv4 قابل استفاده هستند. آن‌ها امکان دسترسی به فیلدهای پیام DHCPv4 را فراهم می‌کنند. .IP \(bu 2 عبارت \fBpkt6\fP به اطلاعات درخواست کلاینت اشاره دارد. برای دسترسی به اطلاعات رله‌های میانی، از \fBrelay6\fP\& استفاده کنید. \fBpkt6.msgtype\fP و \fBpkt6.transid\fP یک رشتهٔ باینری ۴ بایتی را برای نوع پیام یا شناسهٔ تراکنش خروجی می‌دهند. برای نمونه، نوع پیام \fBSOLICIT\fP برابر با \fB0x00000001\fP یا به‌سادگی 1 است، مانند \fBpkt6.msgtype == 1\fP\&. .IP \(bu 2 منظور از \(dqگزینهٔ سازنده\(dq (Vendor option)، گزینهٔ Vendor\-Identifying Vendor\-Specific Information در DHCPv4 (کد 125؛ بخش ۴ از RFC 3925 \% را ببینید) و گزینهٔ Vendor\-Specific Information Option در DHCPv6 (کد 17، تعریف‌شده در بخش ۲۱.۱۷ از RFC 9915 \%) است. منظور از \(dqگزینهٔ کلاس سازنده\(dq (Vendor class option)، گزینهٔ Vendor\-Identifying Vendor Class Option در DHCPv4 (کد 124؛ بخش ۳ از RFC 3925 \% را ببینید) در DHCPv4 و گزینهٔ Class Option در DHCPv6 (کد 16؛ بخش ۲۱.۱۶ از RFC 9915 \%) است. گزینه‌های سازنده ممکن است زیرگزینه‌هایی داشته باشند که با کد مربوطه‌شان ارجاع داده می‌شوند. گزینه‌های کلاس سازنده فاقد زیرگزینه هستند، بلکه تکه‌های داده (data chunks) دارند که با مقدار نمایه ارجاع داده می‌شوند. نمایهٔ 0 به معنای نخستین تکهٔ داده، نمایهٔ 1 برای دومین تکهٔ داده (در صورت وجود) و به همین ترتیب است. .IP \(bu 2 در ساختارهای vendor و vendor\-class می‌توان از یک ستاره (*) یا 0 برای مشخص کردن مقدار عام‌کارت (wildcard) برای \fBenterprise\-id\fP استفاده کرد، به این معنی که با هر مقدار \fBenterprise\-id\fP مطابقت خواهد داشت. .IP \(bu 2 شناسهٔ کلاس سازنده یا Vendor Class Identifier (گزینهٔ 60 در DHCPv4) با استفاده از عبارت option[60] قابل دسترسی است. .IP \(bu 2 استانداردهای RFC 3925 \% و RFC 9915 \% اجازه می‌دهند که چندین نمونه از گزینه‌های سازنده در یک پیام ظاهر شوند. کد طبقه‌بندی کلاینت در حال حاضر در صورتی که بیش از یک مورد ظاهر شود، نخستین نمونه را بررسی می‌کند. برای عبارت‌های \fBvendor.enterprise\fP و \fBvendor\-class.enterprise\fP، مقدار اولین نمونه برگردانده می‌شود. لطفاً برای درخواست پشتیبانی از چندین نمونه، یک درخواست قابلیت (feature request) در وب‌گاه گیت‌لب Kea به آدرس \% ثبت کنید. .UNINDENT .SS "فهرست عبارت‌های طبقه‌بندی (List of classification expressions)" .TS box center; l|l|l. T{ نام T} T{ مثال T} T{ توضیحات T} _ T{ Equal T} T{ \(aqfoo\(aq == \(aqbar\(aq T} T{ مقایسهٔ دو مقدار و برگرداندن \fBtrue\fP یا \fBfalse\fP T} _ T{ Match T} T{ match(\(aqfoo.*\(aq, \(aqfoobar\(aq) T} T{ تطبیق یک عبارت باقاعده با یک مقدار. T} _ T{ Not T} T{ not (\(aqfoo\(aq == \(aqbar\(aq) T} T{ نقیض منطقی T} _ T{ And T} T{ (\(aqfoo\(aq == \(aqbar\(aq) and (\(aqbar\(aq == \(aqfoo\(aq) T} T{ «و»ی منطقی T} _ T{ Or T} T{ (\(aqfoo\(aq == \(aqbar\(aq) or (\(aqbar\(aq == \(aqfoo\(aq) T} T{ «یا»ی منطقی T} _ T{ Substring T} T{ substring(\(aqfoobar\(aq,0,3) T} T{ برگرداندن زیررشتهٔ درخواست‌شده T} _ T{ Concat T} T{ concat(\(aqfoo\(aq,\(aqbar\(aq) T} T{ برگرداندن الحاق رشته‌ها T} _ T{ Concat (عملگر +) T} T{ \(aqfoo\(aq + \(aqbar\(aq T} T{ برگرداندن الحاق رشته‌ها T} _ T{ Ifelse T} T{ ifelse(\(aqfoo\(aq == \(aqbar\(aq,\(aqus\(aq,\(aqthem\(aq) T} T{ برگرداندن مقدار شاخه بر اساس شرط T} _ T{ Hexstring T} T{ hexstring(\(aqfoo\(aq, \(aq\-\(aq) T} T{ تبدیل مقدار به یک رشتهٔ هگزادسیمال، مانند 66\-6F\-6F T} _ T{ Lcase T} T{ lcase(\(aqLoWeR\(aq) T} T{ تبدیل مقدار یک عبارت رشته‌ای به حروف کوچک، مانند \(aqlower\(aq T} _ T{ Ucase T} T{ ucase(\(aquPpEr\(aq) T} T{ تبدیل مقدار یک عبارت رشته‌ای به حروف بزرگ، مانند \(aqUPPER\(aq T} _ T{ Split T} T{ split(\(aqfoo.bar\(aq, \(aq.\(aq, 2) T} T{ برگرداندن فیلد دوم، با تفکیک بر اساس نقطه. T} .TE.SS فهرست عبارت‌های تبدیل به متن (conversion\-to\-text) .TS box center; l|l|l. T{ نام T} T{ مثال T} T{ توضیحات T} _ T{ AddressToText T} T{ addrtotext (192.10.0.1) addrtotext (2003:db8::) T} T{ نمایش ۴ بایت از یک آدرس IPv4 یا ۱۶ بایت از یک آدرس IPv6 در قالب خوانا برای انسان T} _ T{ Int8ToText T} T{ int8totext (\-1) T} T{ نمایش عدد صحیح علامت‌دار ۸ بیتی در قالب متنی T} _ T{ Int16ToText T} T{ int16totext (\-1) T} T{ نمایش عدد صحیح علامت‌دار ۱۶ بیتی در قالب متنی T} _ T{ Int32ToText T} T{ int32totext (\-1) T} T{ نمایش عدد صحیح علامت‌دار ۳۲ بیتی در قالب متنی T} _ T{ UInt8ToText T} T{ uint8totext (255) T} T{ نمایش عدد صحیح بدون علامت ۸ بیتی در قالب متنی T} _ T{ UInt16ToText T} T{ uint16totext (65535) T} T{ نمایش عدد صحیح بدون علامت ۱۶ بیتی در قالب متنی T} _ T{ UInt32ToText T} T{ uint32totext (4294967295) T} T{ نمایش عدد صحیح بدون علامت ۳۲ بیتی در قالب متنی T} .TE .sp نکات: .sp عملگرهای تبدیل می‌توانند برای تبدیل داده‌ها از بازنمود باینری به متنی استفاده شوند. تنها شرط این است که طول نوع دادهٔ ورودی با مقدار مورد انتظار همخوانی داشته باشد. .sp نشانهٔ \fBAddressToText\fP برای آدرس‌های IPv4 انتظار ۴ بایت و برای آدرس‌های IPv6 انتظار ۱۶ بایت را دارد. نشانه‌های \fBInt8ToText\fP و \fBUInt8ToText\fP انتظار ۱ بایت، نشانه‌های \fBInt16ToText\fP و \fBUInt16ToText\fP انتظار ۲ بایت، و نشانه‌های \fBInt32ToText\fP و \fBUInt32ToText\fP انتظار ۴ بایت دارند. برای تمام نشانه‌های تبدیل، اگر طول داده ۰ باشد، رشتهٔ حاصل خالی خواهد بود. .SS گزاره‌ها (Predicates) .sp دو گزارهٔ موجود Equal و Match هستند. می‌توان از آن‌ها برای ساخت سایر گزاره‌های متداول استفاده کرد، به عنوان مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX not (substring(\(aqfoobar\(aq, 3, 3) == \(aqbar\(aq) match(\(aqfoo.*\(aq, lcase(\(aqFooBar\(aq)) match(\(aq.*foo.*\(aq, \(aqis it foo or bar\(aq) match(\(aq^.*foo.*$\(aq, \(aqis it foo or bar\(aq) .EE .UNINDENT .UNINDENT .sp بنابراین نابرابری، تطبیق الگوی مستقل از بزرگی و کوچکی حروف یا جستجوی الگو حاصل می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 عبارت‌های باقاعدهٔ نامعتبرِ شناسایی‌شده به عنوان خطای نحوی تلقی می‌شوند، و استثناهای زمان اجرا در حین تطبیق، به عنوان عدم تطبیق در نظر گرفته می‌شوند. .UNINDENT .UNINDENT .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 در استفاده از عملگر match مراقب باشید، زیرا می‌تواند منجر به کارایی بسیار ضعیف شده و به انکار سرویس ناشی از عبارت باقاعده (ReDoS) بیانجامد. .UNINDENT .UNINDENT.SS عملگرهای منطقی (Logical Operators) .sp عملگرهای منطقی Not، And و Or از عملگرهای رایج هستند. Not بالاترین اولویت و Or پایین‌ترین اولویت را دارد. And و Or شرکت‌پذیر (از چپ) هستند. پرانتزها در اطراف یک عبارت منطقی می‌توانند برای اعمال یک گروه‌بندی مشخص استفاده شوند؛ برای نمونه در \(dqA and (B or C)\(dq. بدون پرانتز، \(dqA and B or C\(dq به معنای \(dq(A and B) or C\(dq است. .SS زیررشته (Substring) .sp عملگر زیررشته \fBsubstring(value, start, length)\fP مقادیر مثبت و منفی را برای موقعیت آغازین و طول می‌پذیرد. برای \fBstart\fP، مقدار 0 بایت نخست در رشته است در حالی که \-1 آخرین بایت است. اگر نقطه آغاز بیرون از رشته اصلی باشد، یک رشته خالی بازگردانده می‌شود. \fBlength\fP تعداد بایت‌های مورد نظر برای استخراج است. یک مقدار منفی به معنای شمارش به سمت ابتدای رشته است اما بایتی را که توسط \fBstart\fP مشخص شده شامل نمی‌شود\&. مقدار ویژه \fBall\fP به معنای بازگرداندن تمامی بایت‌ها از نقطه آغاز تا انتهای رشته است. اگر طول بیشتر از بخش باقی‌مانده رشته باشد، کل بخش باقی‌مانده بازگردانده می‌شود. ذکر چند مثال می‌تواند مفید باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX substring(\(aqfoobar\(aq, 0, 6) == \(aqfoobar\(aq substring(\(aqfoobar\(aq, 3, 3) == \(aqbar\(aq substring(\(aqfoobar\(aq, 3, all) == \(aqbar\(aq substring(\(aqfoobar\(aq, 1, 4) == \(aqooba\(aq substring(\(aqfoobar\(aq, \-5, 4) == \(aqooba\(aq substring(\(aqfoobar\(aq, \-1, \-3) == \(aqoba\(aq substring(\(aqfoobar\(aq, 4, \-2) == \(aqob\(aq substring(\(aqfoobar\(aq, 10, 2) == \(aq\(aq .EE .UNINDENT .UNINDENT .SS الحاق (Concat) .sp تابع \fBconcat(string1, string2)\fP حاصل الحاق دو آرگومان خود را برمی‌گرداند. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX concat(\(aqfoo\(aq, \(aqbar\(aq) == \(aqfoobar\(aq .EE .UNINDENT .UNINDENT .sp برای راحتی کاربر، نگارش 1.9.8 از Kea یک نسخه عملگر شرکت‌پذیر از تابع concat اضافه کرده است. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX \(aqabc\(aq + \(aqdef\(aq + \(aqghi\(aq + \(aqjkl\(aq + \(aq...\(aq .EE .UNINDENT .UNINDENT .sp هم‌ارز است با: .INDENT 0.0 .INDENT 3.5 .sp .EX concat(concat(concat(concat(\(aqabc\(aq, \(aqdef\(aq), \(aqghi\(aq), \(aqjkl\(aq), \(aq...\(aq) .EE .UNINDENT .UNINDENT .sp یا: .INDENT 0.0 .INDENT 3.5 .sp .EX concat(\(aqabc\(aq, concat(\(aqdef\(aq, concat(\(aqghi\(aq, concat(\(aqjkl\(aq, \(aq...\(aq)))) .EE .UNINDENT .UNINDENT .sp یا: .INDENT 0.0 .INDENT 3.5 .sp .EX \(aqabcdefghijkl...\(aq .EE .UNINDENT .UNINDENT .SS تفکیک (Split) .sp عملگر تفکیک \fBsplit(value, delimiters, field\-number)\fP فهرستی از نویسه‌ها را به عنوان جداکننده (delimiters) و یک شماره فیلد مثبت از فیلد مورد نظر پس از تقسیم مقدار به فیلدهای جداشده توسط جداکننده‌ها می‌پذیرد. جداکننده‌های مجاور ادغام و فشرده نمی‌شوند، بلکه منجر به یک رشته خالی برای آن شماره فیلد خواهند شد. اگر value یک رشته خالی باشد، خروجی یک رشته خالی خواهد بود. اگر فهرست delimiters خالی باشد، خروجی همان مقدار اولیه خواهد بود. اگر field\-number کمتر از یک یا بیشتر از تعداد فیلدها باشد، خروجی رشته‌ای خالی خواهد بود. در ادامه چند مثال آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX split (\(aqone.two..four\(aq, \(aq.\(aq, 1) == \(aqone\(aq split (\(aqone.two..four\(aq, \(aq.\(aq, 2) == \(aqtwo\(aq split (\(aqone.two..four\(aq, \(aq.\(aq, 3) == \(aq\(aq split (\(aqone.two..four\(aq, \(aq.\(aq, 4) == \(aqfour\(aq split (\(aqone.two..four\(aq, \(aq.\(aq, 5) == \(aq\(aq .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برای استفاده از نویسه‌ای با گریز (escape) دشوار به عنوان جداکننده، از مقدار هگزادسیمال ASCII آن استفاده کنید. برای نمونه، جداسازی با \fBsingle quote\fP با استفاده از \fB0x27\fP: \fBsplit(option[39].text, 0x27, 1)\fP .UNINDENT .UNINDENT .SS شرط (Ifelse) .sp تابع \fBifelse(cond, iftrue, ifelse)\fP مقدار شاخه \fBiftrue\fP یا \fBifelse\fP را با توجه به شرط بولی \fBcond\fP برمی‌گرداند\&. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX ifelse(option[230].exists, option[230].hex, \(aqnone\(aq) .EE .UNINDENT .UNINDENT.SS Hexstring .sp تابع \fBhexstring(binary, separator)\fP مقدار دودویی (binary) را به صورت نمایه‌ی رشته هگزادسیمال آن بازمی‌گرداند: جفت‌هایی از ارقام هگزادسیمال که با جداکننده از هم جدا شده‌اند، مانند \fB\(aq:\(aq\fP، \fB\(aq\-\(aq\fP، \fB\(aq\(aq\fP (جداکننده خالی). .INDENT 0.0 .INDENT 3.5 .sp .EX hexstring(pkt4.mac, \(aq:\(aq) .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 عبارت مربوط به هر کلاس با دریافت هر بسته پردازش و اجرا می‌شود. در صورتی که عبارت‌ها بیش از اندازه پیچیده باشند، زمان لازم برای اجرای آن‌ها ممکن است عملکرد سرور را تحت تأثیر قرار دهد. مدیران سیستمی که به عبارت‌های پیچیده یا زمان‌بر نیاز دارند باید نوشتن یک قلاب \%<#\:hooks-libraries> را برای انجام کارهای لازم مد نظر قرار دهند. .UNINDENT .UNINDENT .SS پیکربندی کلاس‌ها (Configuring Classes) .INDENT 0.0 .TP .B تعریف یک کلاس کلاینت می‌تواند شامل مشخصه‌های زیر باشد: .INDENT 7.0 .IP \(bu 2 پارامتر \fBname\fP اجباری است و باید میان تمامی کلاس‌ها یکتا باشد. .IP \(bu 2 عبارت \fBtest\fP اجباری نیست و نشان‌دهنده رشته‌ای حاوی عبارت منطقی مورد استفاده برای تعیین عضویت در کلاس است. کل عبارت در علامت نقل‌قول جفتی (\fB\(dq\fP) قرار می‌گیرد. نتیجه باید به یک مقدار بولی (\fBtrue\fP یا \fBfalse\fP) ارزیابی شود. .IP \(bu 2 عبارت \fBtemplate\-test\fP اجباری نیست و نشان‌دهنده رشته‌ای حاوی عبارت منطقی مورد استفاده برای تولید یک کلاس انشعابی (spawning class) است. کل عبارت در علامت نقل‌قول جفتی (\fB\(dq\fP) قرار می‌گیرد. نتیجه باید به یک مقدار رشته‌ای ارزیابی شود که بخش متغیرِ نام کلاس انشعاب‌یافته (spawned class) را نشان می‌دهد. اگر رشته حاصل خالی باشد، هیچ کلاس انشعابی تولید نمی‌شود. کلاس انشعاب‌یافته حاصل دارای قالب نام تولیدشده به این صورت خواهد بود: \fBSPAWN__\fP\&. پس از ارزیابی کلاس‌ها و تولید کلاس انشعاب‌یافته، نام کلاس الگوی متناظر نیز با بسته پیوند می‌یابد. گزینه‌ای (Option) که در یک کلاس انشعاب‌یافته مشخص شده باشد بر همان گزینه در صورت تنظیم در کلاس الگوی آن، ارجحیت خواهد داشت. .IP \(bu 2 فهرست \fBoption\-data\fP اجباری نیست و شامل گزینه‌هایی است که باید به اعضای این کلاس اختصاص داده شوند. در مورد یک کلاس الگو، این گزینه‌ها به کلاس انشعاب‌یافتهٔ تولیدشده اختصاص می‌یابند. .IP \(bu 2 فهرست \fBoption\-def\fP اجباری نیست و برای تعریف گزینه‌های سفارشی به کار می‌رود. .IP \(bu 2 مشخصه \fBonly\-if\-required\fP با \fBonly\-in\-additional\-list\fP جایگزین شده و اکنون منسوخ است. این مقدار برای مدتی به عنوان ورودی پذیرفته می‌شود تا به کاربران اجازه مهاجرت داده شود، اما در نهایت پشتیبانی از آن متوقف خواهد شد. .IP \(bu 2 پرچم \fBonly\-in\-additional\-list\fP اجباری نیست؛ هنگامی که مقدار آن روی \fBfalse\fP (پیش‌فرض) تنظیم شود، عضویت در طول دسته‌بندی تعیین شده و برای نمونه جهت انتخاب زیرشبکه در دسترس است. هنگامی که مقدار روی \fBtrue\fP تنظیم شود، عضویت تنها در صورتی ارزیابی می‌شود که کلاس در فهرست \fBevaluate\-additional\-classes\fP وجود داشته باشد و تنها برای پیکربندی گزینه‌ها قابل استفاده خواهد بود. .IP \(bu 2 مشخصه \fBuser\-context\fP اجباری نیست و نشان‌دهنده یک نگاشت با داده‌های تعریف‌شده توسط کاربر و احتمالاً گزینه‌های پیکربندی برای کتابخانه‌های قلاب (hook libraries) است. .IP \(bu 2 پارامتر \fBnext\-server\fP اجباری نیست و فیلد \fBsiaddr\fP را در بسته‌های مرتبط با این کلاس پیکربندی می‌کند. این پارامتر تنها در DHCPv4 کاربرد دارد. .IP \(bu 2 مشخصه \fBserver\-hostname\fP اجباری نیست و فیلد \fBsname\fP را در بسته‌های مرتبط با این کلاس پیکربندی می‌کند. این مشخصه تنها در DHCPv4 کاربرد دارد. .IP \(bu 2 مشخصه \fBboot\-file\-name\fP اجباری نیست و فیلد \fBfile\fP را در بسته‌های مرتبط با این کلاس پیکربندی می‌کند. این مشخصه تنها در DHCPv4 کاربرد دارد. .IP \(bu 2 مشخصه‌های \fBvalid\-lifetime\fP، \fBmin\-valid\-lifetime\fP و \fBmax\-valid\-lifetime\fP اجباری نیستند و فیلدهای طول عمر معتبر را برای این کلاس کلاینت پیکربندی می‌کنند. .IP \(bu 2 مشخصه‌های \fBpreferred\-lifetime\fP، \fBmin\-preferred\-lifetime\fP و \fBmax\-preferred\-lifetime\fP اجباری نیستند و فیلدهای طول عمر ترجیحی را برای این کلاس کلاینت پیکربندی می‌کنند. این مشخصه‌ها تنها در DHCPv6 کاربرد دارند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBtest\fP و \fBtemplate\-test\fP در تعریف یک کلاس کلاینت مانعة‌الجمع هستند. از یکی از آن‌ها استفاده کنید، یا از هیچ‌کدام، اما نه هر دو. در صورت ارائه هر دو، پیکربندی رد می‌شود. .UNINDENT .UNINDENT .sp در مثال زیر، کلاسی به نام \fBClient_foo\fP تعریف شده است. این کلاس شامل تمام کلاینت‌هایی است که شناسه کلاینت (گزینه ۶۱) آن‌ها با رشته \fBfoo\fP آغاز می‌شود. به اعضای این کلاس، 192.0.2.1 و 192.0.2.2 به عنوان کارگزارهای نام دامنه اختصاص خواهد یافت. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient_foo\(dq, \(dqtest\(dq: \(dqsubstring(option[61].hex,0,3) == \(aqfoo\(aq\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqcode\(dq: 6, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq192.0.2.1, 192.0.2.2\(dq } ] }, ... ], ... } .EE .UNINDENT .UNINDENT .sp مثال بعدی تعریف یک کلاس کلاینت با نام \(dqClient_enterprise\(dq را برای استفاده توسط سرور DHCPv6 نشان می‌دهد. این کلاس شامل تمام کلاینت‌هایی است که شناسه کلاینت آن‌ها با رشته هگزادسیمال مشخص‌شده آغاز می‌شود، که نشان‌دهنده یک DUID بر اساس شناسه سازمانی \fB0x0002AABBCCDD\fP است. به اعضای این کلاس، 2001:db8:0::1 و 2001:db8:2::1 به عنوان کارگزارهای نام دامنه اختصاص داده خواهد شد. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient_enterprise\(dq, \(dqtest\(dq: \(dqsubstring(option[1].hex,0,6) == 0x0002AABBCCDD\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqcode\(dq: 23, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq2001:db8:0::1, 2001:db8:2::1\(dq } ] }, ... ], ... } .EE .UNINDENT .UNINDENT .sp همچنین این امکان وجود دارد که هر دو عملوند چپ و راست عبارت ارزیابی‌شده در زمان اجرا پردازش شوند. عبارت‌های مربوط به بسته‌ها می‌توانند به هر تعداد مورد نیاز در عبارت ظاهر شوند؛ هیچ محدودیتی وجود ندارد. با این حال، هر نشانه (token) تأثیر اندکی بر عملکرد دارد و عبارت‌های بیش از اندازه پیچیده ممکن است باعث ایجاد گلوگاه شوند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqInfrastructure\(dq, \(dqtest\(dq: \(dqoption[82].option[2].hex == pkt4.mac\(dq, ... }, ... ], ... } .EE .UNINDENT .UNINDENT.SS کلاس‌های الگو (Template Classes) .sp پارامتر \fBtemplate\-test\fP مشخص می‌کند که کلاس مربوطه یک کلاس الگو است. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient\-ID\(dq, \(dqtemplate\-test\(dq: \(dqsubstring(option[61].hex,0,3)\(dq, ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp اگر بسته DHCPv4 دریافت‌شده حاوی option 61 باشد، سه بایت اول نشان‌دهنده مقدار \fBfoo\fP در ASCII خواهد بود و کلاس ایجادشده (spawned) از نام \fBSPAWN_Client\-ID_foo\fP استفاده می‌کند. هر دو کلاس \fBSPAWN_Client\-ID_foo\fP و \fBClient\-ID\fP به بسته منتسب می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کلاس‌های الگو همچنین می‌توانند برای ایجاد کلاس‌هایی استفاده شوند که با کلاس‌های عادی (regular) مطابقت دارند و بدین‌ترتیب عملاً کلاس عادی را به بسته منتسب می‌کنند. برای دستیابی به این هدف، کلاس عادی نیز باید شامل بخش ثابتِ نام کلاس ایجادشده باشد: .sp \fBSPAWN__\fP .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqSPAWN_Client\-ID_foobar\(dq, \(dqtest\(dq: \(dqsubstring(option[1].hex,0,6) == 0x0002AABBCCDD\(dq, ... }, { \(dqname\(dq: \(dqClient\-ID\(dq, \(dqtemplate\-test\(dq: \(dqsubstring(option[1].hex,0,6)\(dq, ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp اگر بسته DHCPv6 دریافت‌شده حاوی option 1 (شناسه کلاینت) با مقدار هگزادسیمال \fB0x0002AABBCCDD\fP باشد، کلاس \fBSPAWN_Client\-ID_foobar\fP به بسته منتسب می‌شود. علاوه بر این، اگر شش بایت اول نمایانگر مقدار \fBfoobar\fP در ASCII باشد، کلاس ایجادشده از نام \fBSPAWN_Client\-ID_foobar\fP استفاده کرده و عملاً کلاس عادی را به بسته منتسب می‌نماید. در این حالت دوم، هر دو کلاس \fBSPAWN_Client\-ID_foobar\fP و \fBClient\-ID\fP به بسته منتسب می‌شوند. عبارت \fBtest\fP در کلاس عادی \fBSPAWN_Client\-ID_foobar\fP اجباری نیست و می‌تواند حذف شود، اما در اینجا با یک عبارت تطبیق متفاوت صرفاً با هدف مثال به کار رفته است. .sp معمولاً عبارت‌های \fBtest\fP و \fBtemplate\-test\fP پیش از انتخاب زیرشبکه (subnet) ارزیابی می‌شوند، اما در برخی موارد ارزیابی آن‌ها در مراحل بعد، زمانی که subnet، شبکه مشترک (shared network) یا poolها مشخص شده‌اند ولی پردازش گزینه‌های خروجی (output\-option processing) هنوز انجام نشده است، مفید خواهد بود. برای این منظور، پرچم \fBonly\-in\-additional\-list\fP که به‌طور پیش‌فرض \fBfalse\fP است، اجازه می‌دهد عبارت \fBtest\fP یا عبارت \fBtemplate\-test\fP تنها در صورتی ارزیابی شوند که به‌واسطه حضور کلاس در فهرست \fBevaluate\-additional\-classes\fP متعلق به pool، subnet یا shared network انتخاب‌شده درخواست شده باشند. .sp فهرست \fBevaluate\-additional\-classes\fP که برای دامنه‌های pool، subnet و shared\-network معتبر است، کلاس‌هایی را مشخص می‌کند که در دور دوم ارزیابی و پیش از پردازش گزینه‌های خروجی بررسی می‌شوند. این فهرست با همان اولویت داده‌های گزینه (option data) ساخته می‌شود؛ یعنی یک داده گزینه در subnet نسبت به مورد مشابه در shared network اولویت دارد. یک کلاس اضافی در subnet، پیش از کلاسی در shared network اضافه می‌شود. این سازوکار با پرچم \fBonly\-in\-additional\-list\fP مرتبط است، اما اجباری نیست که این پرچم حتماً روی \fBtrue\fP تنظیم شده باشد\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 عبارت \fBtemplate\-test\fP همچنین می‌تواند برای فیلتر کردن کلاس‌های ایجادشده به کار رود، به‌طوری که با استفاده از دستور \fBifelse\fP این کلاس‌ها فقط در صورت نیاز ساخته شوند. .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient\-ID\(dq, \(dqtemplate\-test\(dq: \(dqifelse(substring(option[61].hex,4,3) == \(aqfoo\(aq, substring(option[12].hex,0,12), \(aq\(aq)\(dq, ... }, ... ], ... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کلاس‌های الگو را می‌توان برای پیکربندی محدودیت‌ها (limits) به کار برد که دقیقاً مانند گزینه‌ها، به کلاس ایجادشده منتسب می‌شوند. این امر امکان پیکربندی محدودیت‌هایی را فراهم می‌سازد که بر تمام بسته‌های منتسب به کلاسی که در زمان اجرا (runtime) بر اساس عبارت \fBtemplate\-test\fP در کلاس الگوی والد ایجاد شده است، اعمال شوند. برای توضیحات دقیق‌تر درباره نحوه پیکربندی محدودیت‌ها با استفاده از کتابخانه قلاب limits، به Configuration \%<#\:hooks-limits-configuration>\& مراجعه کنید. برای مثال، با استفاده از پیکربندی زیر، بسته‌های DHCPv6 ورودی (ingress) که دارای مقادیر شناسه کلاینت (در قالبی که توسط ارزیاب Kea بیان می‌شود) \fBfoobar\fP و \fBfoofoo\fP باشند، هر دو مشمول همان سقف ۶۰ بسته در روز می‌شوند، در حالی که بسته‌های دیگر که سه هگزاست (hextet) اول آن‌ها مقداری غیر از \fBfoo\fP دارد، در سطل‌های مجزای محدودسازی نرخ (rate\-limiting buckets) قرار می‌گیرند. .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient\-ID\(dq, \(dqtemplate\-test\(dq: \(dqsubstring(option[1].hex,0,3)\(dq, \(dquser\-context\(dq : { \(dqlimits\(dq: { \(dqrate\-limit\(dq: \(dq60 packets per day\(dq } }, ... }, ... ], ... } .EE .UNINDENT .UNINDENT.SS استفاده از رزروهای ایستای میزبان در کلاس‌بندی .sp کلاس‌ها می‌توانند با استفاده از روش‌های شرح‌داده‌شده در «رزرو کلاس‌های کلاینت در DHCPv4» \%<#\:reservation4-client-classes> و «رزرو کلاس‌های کلاینت در DHCPv6» \%<#\:reservation6-client-classes>\& به صورت ایستا به کلاینت‌ها اختصاص یابند. .sp رزروهای میزبان در سطح زیرشبکه (subnet)، پس از انتخاب زیرشبکه جستجو می‌شوند. رزروهای سراسری میزبان (global) به طور پیش‌فرض در همان زمان جستجو می‌شوند، اما پارامتر \fBearly\-global\-reservations\-lookup\fP امکان تغییر این رفتار را برای جستجوی آن‌ها پیش از انتخاب زیرشبکه فراهم می‌کند. .sp انتخاب استخر (pool) پس از تمام جستجوهای رزرو میزبان انجام می‌شود. .SS پیکربندی زیرشبکه‌ها با اطلاعات کلاس .sp در موارد خاص، محدود کردن دسترسی به برخی زیرشبکه‌ها تنها به کلاینت‌هایی که متعلق به یک کلاس مشخص هستند، با استفاده از پارامتر \fBclient\-classes\fP هنگام تعریف زیرشبکه سودمند است. این پارامتر می‌تواند برای تعیین فهرستی از یک یا چند کلاس به کار رود که کلاینت‌ها به منظور استفاده از زیرشبکه باید متعلق به آن‌ها باشند. این سازوکار را می‌توان به عنوان «محافظ کلاس» (class guard) برای زیرشبکه در نظر گرفت، یا به عبارت دیگر، زیرشبکه توسط یک کلاس کلاینت محافظت می‌شود. .sp فرض کنید سرور به بخشی از شبکه متصل است که از پیشوند 192.0.2.0/24 استفاده می‌کند. مدیر آن شبکه تصمیم گرفته است که نشانی‌های بازه 192.0.2.10 تا 192.0.2.20 توسط سرور DHCPv4 مدیریت شوند. تنها کلاینت‌های متعلق به کلاس کلاینت \fBClient_foo\fP مجاز به استفاده از این زیرشبکه هستند. چنین پیکربندی‌ای را می‌توان به روش زیر انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient_foo\(dq, \(dqtest\(dq: \(dqsubstring(option[61].hex,0,3) == \(aqfoo\(aq\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqcode\(dq: 6, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq192.0.2.1, 192.0.2.2\(dq } ] }, ... ], \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq } ], \(dqclient\-classes\(dq: [ \(dqClient_foo\(dq ] }, ... ], ... } .EE .UNINDENT .UNINDENT .sp مثال زیر نحوه محدود کردن دسترسی به یک زیرشبکه DHCPv6 را نشان می‌دهد. این پیکربندی، استفاده از نشانی‌های بازه 2001:db8:1::1 تا 2001:db8:1::FFFF را به اعضای کلاس \(dqClient_enterprise\(dq محدود می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient_enterprise\(dq, \(dqtest\(dq: \(dqsubstring(option[1].hex,0,6) == 0x0002AABBCCDD\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqcode\(dq: 23, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq2001:db8:0::1, 2001:db8:2::1\(dq } ] }, ... ], \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::\-2001:db8:1::ffff\(dq } ], \(dqclient\-classes\(dq: \(dqClient_enterprise\(dq } ], ... } .EE .UNINDENT .UNINDENT .SS پیکربندی استخرها با اطلاعات کلاس .sp مشابه زیرشبکه‌ها، در موارد خاص دسترسی به برخی استخرهای نشانی یا پیشوند باید تنها به کلاینت‌هایی محدود شود که دست‌کم به یکی از کلاس‌های مشخص‌شده در فهرست تعلق دارند؛ این کار با استفاده از پارامتر \fBclient\-classes\fP هنگام تعریف استخر انجام می‌گیرد. این موضوع را می‌توان به عنوان «محافظ کلاس» (class guard) برای استخر در نظر گرفت، یا به عبارت دیگر، استخر توسط یک کلاس کلاینت محافظت می‌شود. .sp فرض کنید سرور به بخشی از شبکه متصل است که از پیشوند 192.0.2.0/24 استفاده می‌کند. مدیر آن شبکه تصمیم گرفته است که نشانی‌های بازه 192.0.2.10 تا 192.0.2.20 توسط سرور DHCPv4 مدیریت شوند. تنها کلاینت‌های متعلق به کلاس کلاینت \fBClient_foo\fP مجاز به استفاده از این استخر هستند. چنین پیکربندی‌ای را می‌توان به روش زیر انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient_foo\(dq, \(dqtest\(dq: \(dqsubstring(option[61].hex,0,3) == \(aqfoo\(aq\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqcode\(dq: 6, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq192.0.2.1, 192.0.2.2\(dq } ] }, ... ], \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq, \(dqclient\-classes\(dq: [ \(dqClient_foo\(dq ] } ] }, ... ], ... } .EE .UNINDENT .UNINDENT .sp مثال زیر نحوه محدود کردن دسترسی به یک استخر نشانی را نشان می‌دهد. این پیکربندی، استفاده از نشانی‌های بازه 2001:db8:1::1 تا 2001:db8:1::FFFF را به اعضای کلاس \(dqClient_enterprise\(dq محدود می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqClient_enterprise_\(dq, \(dqtest\(dq: \(dqsubstring(option[1].hex,0,6) == 0x0002AABBCCDD\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqcode\(dq: 23, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq2001:db8:0::1, 2001:db8:2::1\(dq } ] }, ... ], \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::\-2001:db8:1::ffff\(dq, \(dqclient\-classes\(dq: [ \(dqClient_foo\(dq ] } ] }, ... ], ... } .EE .UNINDENT .UNINDENT.SS "اولویت کلاس‌ها (Class Priority)" .sp کلاس‌های کلاینت در Kea از ترتیبی که در پیکربندی مشخص شده‌اند پیروی می‌کنند (در مقایسه با ترتیب الفبایی). کلاس‌های اضافی به ترتیبِ pool، سپس subnet و سپس shared\-network، و در هر محدوده (scope) بر اساس ترتیبی که در \fBevaluate\-additional\-classes\fP ظاهر می‌شوند، مرتب می‌گردند. .sp هنگام تعیین اینکه کدام اطلاعات client\-class (شامل گزینه‌ها، طول‌عمر اجاره‌ها، یا مقادیر فیلد DHCPv4) بخشی از تعاریف کلاس هستند که باید در پاسخ گنجانده شوند، کارساز اجتماعِ گزینه‌های تمام کلاس‌های انتساب‌یافته را بررسی می‌کند. اگر دو یا چند کلاس شامل اطلاعات کلاس یکسانی باشند، مقدار اولین کلاسِ انتساب‌یافته استفاده می‌شود. \fBALL\fP همیشه اولین کلاس است، یعنی کلاسی با بالاترین اولویت، و کلاس‌های منطبقِ الزامی (required) در انتها قرار دارند، بنابراین کمترین اولویت را دارند. .sp گزینه‌های تعریف‌شده در کلاس‌ها بر هر گزینه سراسری (global) اولویت داشته و جایگزین آن می‌شوند، و به نوبه خود توسط گزینه‌های تعریف‌شده برای یک subnet، shared network، pool یا reservation جداگانه لغو و بازنویسی (override) می‌شوند. .sp از سوی دیگر، طول‌عمر اجاره‌ها و مقادیر فیلدهای DHCPv4 تعریف‌شده در محدوده کلاس، بر هر مقدار تعریف‌شده به‌صورت سراسری، در محدوده subnet یا در محدوده shared\-network اولویت دارند و جایگزین آن‌ها می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از آنجا که ارزیابی اضافی پس از تخصیص اجاره رخ می‌دهد، پارامترهایی که در غیر این صورت بر طول‌عمر اجاره تأثیر می‌گذاشتند (مانند \fBvalid\-lifetime\fP و \fBoffer\-lifetime\fP) هنگامی که در کلاسی مشخص شوند که \fBonly\-in\-additional\-list\fP را نیز برابر با true قرار داده است، هیچ تأثیری نخواهند داشت. .UNINDENT .UNINDENT .sp به عنوان مثال، تصور کنید یک بسته ورودی با دو کلاس مطابقت دارد. کلاس \fBfoo\fP مقادیری برای یک سرور NTP (گزینه 42 در DHCPv4) و یک سرور SMTP (گزینه 69 در DHCPv4) تعریف می‌کند، در حالی که کلاس \fBbar\fP مقادیری برای یک سرور NTP و یک سرور POP3 (گزینه 70 در DHCPv4) تعریف می‌کند. کارساز سه گزینه \- یعنی NTP، SMTP و POP3 \- را بررسی کرده و هر کدام را که کلاینت درخواست کرده باشد بازمی‌گرداند. از آنجا که سرور NTP دو بار تعریف شده است، کارساز فقط یکی از مقادیر را برای پاسخ انتخاب می‌کند؛ کلاسی که مقدار از آن گرفته می‌شود طبق توضیحات بندهای قبلی تعیین می‌گردد. .SS "برچسب‌گذاری کلاسی گزینه‌ها (Option Class\-Tagging)" .sp برچسب‌گذاری کلاسی گزینه‌ها (Option class\-tagging) اجازه می‌دهد تا مقدار یک گزینه بر اساس عضویت کلاینت در کلاس، به‌صورت مشروط بر پاسخ اعمال شود. تأثیر آن مشابه استفاده از یک بلوک if در ISC DHCP برای گنجاندن شرطی گزینه‌ها در یک محدوده مشخص است. برچسب‌گذاری کلاسی با مشخص کردن فهرستی از یک یا چند نام کلاس در مدخل \fBclient\-classes\fP مربوط به گزینه انجام می‌شود. .sp حالتی را در نظر بگیرید که در آن اعضای یک کلاس معین به مقداری یکسان برای یک گزینه، اما مقداری مختص به زیرشبکه (subnet\-specific) برای گزینه‌ای دیگر نیاز دارند. مثال زیر نشان می‌دهد که چگونه از برچسب‌گذاری کلاسی استفاده شده تا به کلاینت‌های متعلق به \(dqGROUP1\(dq یک مقدار مختص زیرشبکه برای گزینه \(dqbar\(dq اختصاص داده شود، در حالی که به تمام اعضای \(dqGROUP1\(dq همان مقدار یکسان برای گزینه \(dqfoo\(dq داده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqGROUP1\(dq, \(dqtest\(dq:\(dqsubstring(option[123].hex,0,4) == \(aqONE\(aq\(dq, \(dqoption\-data\(dq: [{ \(dqname\(dq: \(dqfoo\(dq, \(dqdata\(dq: \(dqsomefile.txt\(dq }] }], \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq178.16.1.0/24\(dq, \(dqoption\-data\(dq: [{ \(dqclient\-classes\(dq: [\(dqGROUP1\(dq], \(dqname\(dq: \(dqbar\(dq, \(dqdata\(dq: 123 }] }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq178.16.2.0/24\(dq, \(dqoption\-data\(dq: [ { \(dqclient\-classes\(dq: [\(dqGROUP1\(dq], \(dqname\(dq: \(dqbar\(dq, \(dqdata\(dq: 789 }] }] } .EE .UNINDENT .UNINDENT .sp فهرست \fBclient\-classes\fP در مشخصات گزینه در هر محدوده‌ای (scope) مجاز است. برچسب‌گذاری کلاسی گزینه در زمان اضافه شدن گزینه‌ها به پاسخ اعمال می‌شود؛ یعنی پس از تخصیص اجاره و درست قبل از ارسال پاسخ به کلاینت. .sp هنگامی که \fBnever\-send\fP برای یک گزینه در هر محدوده‌ای برابر با true باشد، تمام مدخل‌های \fBclient\-classes\fP برای آن گزینه نادیده گرفته می‌شوند. این گزینه گنجانده نخواهد شد. .sp هنگامی که \fBalways\-send\fP در هر محدوده‌ای برابر با true باشد، گزینه گنجانده خواهد شد؛ مگر اینکه گزینه تعیین‌شده بر اساس محدوده، فهرست \fBclient\-classes\fP را به‌گونه‌ای مشخص کرده باشد که شامل هیچ‌یک از کلاس‌های کلاینت نباشد. .sp در غیر این صورت، گزینه درخواست‌شده توسط کلاینت در صورتی در پاسخ گنجانده می‌شود که یا آن گزینه \fBclient\-classes\fP را مشخص نکرده باشد، یا کلاینت حداقل به یکی از کلاس‌های موجود در \fBclient\-classes\fP تعلق داشته باشد\&. .sp هنگامی که برچسب کلاسی یک گزینه مطابقت ندارد، درست مانند این است که گزینه در آن محدوده مشخص نشده باشد. در مثال زیر، گزینه \(dqfoo\(dq هم برای subnet و هم برای pool مشخص شده است. مشخصات pool شامل یک برچسب کلاسی است که این گزینه را به اعضای کلاس \(dqmelon\(dq محدود می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqid\(dq: 100, \(dqsubnet\(dq: \(dq178.16.1.0/24\(dq, \(dqoption\-data\(dq: [{ \(dqname\(dq: \(dqfoo\(dq, \(dqdata\(dq: 456 }], \(dqpools\(dq: [{ \(dqpool\(dq: \(dq178.16.1.100 \- 178.16.1.200\(dq, \(dqoption\-data\(dq: [{ \(dqname\(dq: \(dqfoo\(dq, \(dqdata\(dq: 123, \(dqclient\-classes\(dq : [ \(dqmelon\(dq ] }] }] } .EE .UNINDENT .UNINDENT .sp کلاینت‌هایی که با کلاس \(dqmelon\(dq مطابقت دارند مقدار 123 را برای گزینه \(dqfoo\(dq خواهند داشت، در حالی که کلاینت‌هایی که با \(dqmelon\(dq مطابقت ندارند مقدار 456 را برای گزینه \(dqfoo\(dq دریافت خواهند کرد. .sp می‌توان با مشخص کردن بیش از یک باره یک گزینه با برچسب‌های کلاسی و مقادیر مختلف، به رفتاری مشابه if\-elseif\-else دست یافت. پیکربندی زیر را برای یک زیرشبکه در نظر بگیرید که سه مقدار ممکن را برای گزینه \(dqserver\-str\(dq فراهم می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.1.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.1.1 \- 192.0.1.255\(dq }], \(dqoption\-data\(dq: [{ \(dqclient\-classes\(dq: [ \(dqclass\-one\(dq ], \(dqname\(dq: \(dqserver\-str\(dq, \(dqdata\(dq: \(dqstring.one\(dq },{ \(dqclient\-classes\(dq: [ \(dqclass\-two\(dq ], \(dqname\(dq: \(dqserver\-str\(dq, \(dqdata\(dq: \(dqstring.two\(dq },{ \(dqname\(dq: \(dqserver\-str\(dq, \(dqdata\(dq: \(dqstring.other\(dq }] } .EE .UNINDENT .UNINDENT .sp کلاینت‌های متعلق به \(dqclass\-one\(dq مقدار \(dqstring.one\(dq، کلاینت‌های متعلق به \(dqclass\-two\(dq مقدار \(dqstring.two\(dq، و کلاینت‌هایی که نه به \(dqclass\-one\(dq و نه به \(dqclass\-two\(dq تعلق دارند، مقدار \(dqstring.other\(dq را دریافت خواهند کرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 ترتیب بررسی گزینه‌ها تضمین‌شده نیست، به جز اینکه گزینه‌ای با فهرست خالی \(dqclient\-classes\(dq در انتها بررسی می‌شود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگرچه مثال‌های بالا برای DHCPv4 هستند، نحو و رفتار برچسب‌گذاری کلاسی برای DHCPv6 نیز یکسان است. .UNINDENT .UNINDENT.SS "کلاس‌ها و قلاب‌ها (Classes and Hooks)" .sp می‌توان از قلاب‌ها (hooks) برای دسته‌بندی بسته‌ها استفاده کرد. این کار ممکن است زمانی مفید باشد که نوشتن عبارت پیچیده یا زمان‌بر باشد، و بتوان آن را بهتر یا ساده‌تر به‌صورت کد نوشت. هنگامی که قلاب نام کلاس مناسب را به بسته اضافه کرد، بقیهٔ سیستم دسته‌بندی طبق انتظار در انتخاب یک زیرشبکه و گزینه‌ها عمل خواهد کرد. برای توضیحات دربارهٔ قلاب‌ها، به Hook Libraries \%<#\:hooks-libraries> مراجعه کنید؛ برای اطلاعات دربارهٔ پیکربندی کلاس‌ها، به Configuring Classes and Configuring Subnets With Class Information\& مراجعه نمایید. .SS "اشکال‌زدایی عبارت‌ها (Debugging Expressions)" .sp هنگام ساخت عبارت‌های دسته‌بندی، مدیران سیستم ممکن است فعال‌سازی ثبت وقایع (logging) را مفید بیابند؛ برای توضیحات کامل‌تر دربارهٔ امکانات ثبت وقایع، به Logging \%<#\:logging> مراجعه کنید. .sp برای فعال‌سازی گزاره‌های اشکال‌زدایی در سیستم دسته‌بندی، سطح اهمیت باید روی \fBDEBUG\fP و سطح اشکال‌زدایی حداقل روی ۵۵ تنظیم شود. لاگرهای اختصاصی عبارتند از \fBkea\-dhcp4.eval\fP و \fBkea\-dhcp6.eval\fP\&. .sp برای درک گزاره‌های ثبت وقایع، ضروری است تا حدودی با نحوهٔ ارزیابی عبارت‌ها آشنا باشید؛ برای توضیحات کامل‌تر، به [سند طراحی](\%) مراجعه کنید. به‌طور خلاصه، در طول ارزیابی یک عبارت از دو ساختار استفاده می‌شود: فهرستی از نشانه‌ها (tokens) که نمایانگر عبارت‌ها هستند، و یک پشتهٔ مقادیر (value stack) که نمایانگر مقادیر در حال دستکاری است. .sp فهرست نشانه‌ها هنگام پردازش فایل پیکربندی ایجاد می‌شود و بیشتر عبارت‌ها و مقادیر به یک نشانه تبدیل می‌شوند. این فهرست بر اساس نمادگذاری معکوس لهستانی (RPN) سازماندهی شده است. در طول اجرا، فهرست به ترتیب پیمایش می‌شود؛ با اجرای هر نشانه، امکان برداشتن (pop) مقادیر از بالای پشته و در نهایت قرار دادن (push) نتیجه روی بالای پشته فراهم می‌شود. عبارت زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqtest\(dq: \(dqsubstring(option[61].hex,0,3) == \(aqfoo\(aq\(dq, .EE .UNINDENT .UNINDENT .sp این دستور به نشانه‌های زیر منجر خواهد شد: .INDENT 0.0 .INDENT 3.5 .sp .EX option, number (0), number (3), substring, text (\(aqfoo\(aq), equals .EE .UNINDENT .UNINDENT .sp در این مثال، سه نشانهٔ اول صرفاً مقادیر را روی پشته قرار می‌دهند. سپس نشانهٔ substring آن سه مقدار را برمی‌دارد و نتیجه‌ای را محاسبه می‌کند که روی پشته قرار می‌دهد. گزینهٔ text نیز مقداری را روی پشته می‌گذارد، و در نهایت نشانهٔ equals دو نشانهٔ روی پشته را برمی‌دارد و نتیجه‌اش را روی پشته می‌گذارد. .sp هنگامی که ثبت وقایع اشکال‌زدایی فعال باشد، با هر بار ارزیابی یک نشانه، پیام گزارشی صادر می‌شود که نشان‌دهندهٔ مقادیر هر شیء برداشته‌شده از پشتهٔ مقادیر و هر شیء قرار‌گرفته روی پشتهٔ مقادیر است. .sp مقادیر در صورتی که مشخص باشد دستور از مقادیر متنی استفاده می‌کند به‌صورت متن، یا اگر دستور از مقادیر باینری استفاده کند یا بتواند مقادیر متنی یا باینری را پردازش کند به‌صورت هگزادسیمال نمایش داده می‌شوند. برای عبارت‌هایی که چندین مقدار را از پشته برمی‌دارند، مقادیر به همان ترتیبی که برداشته شده‌اند نمایش می‌یابند. برای اکثر عبارت‌ها این موضوع اهمیتی نخواهد داشت، اما برای عبارت concat مقادیر به ترتیبی معکوس نسبت به ترتیب نوشته‌شدنشان در عبارت نمایش داده می‌شوند. .sp فرض کنیم آزمایش زیر در پیکربندی وارد شده است. این مثال از بخش عمدهٔ پیکربندی صرف‌نظر می‌کند تا روی آزمایش تمرکز کند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqtest\(dq: \(dqsubstring(option[61].hex,0,3) == \(aqfoo\(aq\(dq, .EE .UNINDENT .UNINDENT .sp ثبت وقایع ممکن است به این شکل باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX 2016\-05\-19 13:35:04.163 DEBUG [kea.eval/44478] EVAL_DEBUG_OPTION Pushing option 61 with value 0x666F6F626172 2016\-05\-19 13:35:04.164 DEBUG [kea.eval/44478] EVAL_DEBUG_STRING Pushing text string \(aq0\(aq 2016\-05\-19 13:35:04.165 DEBUG [kea.eval/44478] EVAL_DEBUG_STRING Pushing text string \(aq3\(aq 2016\-05\-19 13:35:04.166 DEBUG [kea.eval/44478] EVAL_DEBUG_SUBSTRING Popping length 3, start 0, string 0x666F6F626172 pushing result 0x666F6F 2016\-05\-19 13:35:04.167 DEBUG [kea.eval/44478] EVAL_DEBUG_STRING Pushing text string \(aqfoo\(aq 2016\-05\-19 13:35:04.168 DEBUG [kea.eval/44478] EVAL_DEBUG_EQUAL Popping 0x666F6F and 0x666F6F pushing result \(aqtrue\(aq .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در صورت وجود چندین عبارت برای ارزیابی، ثبت وقایع اشکال‌زدایی ممکن است بسیار پرحجم باشد؛ هدف از آن، کمک به ایجاد و اشکال‌زدایی عبارت‌ها است. مدیران سیستم باید پس از اطمینان از عملکرد صحیح عبارت‌ها، ثبت وقایع اشکال‌زدایی را غیرفعال کنند. همچنین کاربران ممکن است ترجیح دهند در زمان اشکال‌زدایی، تنها یک مجموعه از عبارت‌ها را در فایل پیکربندی قرار دهند تا گزاره‌های گزارش محدود شوند. به عنوان مثال، هنگام افزودن یک مجموعه عبارت جدید، ممکن است برای مدیر سیستم راحت‌تر باشد که فایلی از پیکربندی بسازد که تنها شامل عبارت‌های جدید باشد تا زمانی که به درستی کار کنند، و سپس مجموعهٔ جدید را به فایل پیکربندی اصلی اضافه کند. .UNINDENT .UNINDENT .SH "کتابخانه‌های قلاب (HOOK LIBRARIES)" .SS "مقدمه (Introduction)" .sp ‏Kea از طریق استفاده از «قلاب‌ها» (\(dqhooks\(dq)، هم انعطاف‌پذیر و هم قابل سفارشی‌سازی است. این ویژگی به Kea اجازه می‌دهد یک یا چند کتابخانه با پیوند پویا (که به نام «کتابخانه‌های قلاب» یا \(dqhook libraries\(dq شناخته می‌شوند) را بارگذاری کرده و توابع درون آن‌ها را در نقاط مختلفی از پردازش خود («نقاط قلاب» یا \(dqhook points\(dq) فراخوانی کند. این توابع هر پردازش سفارشی لازم را انجام می‌دهند. .sp مفهوم قلاب‌ها به کد اصلی Kea اجازه می‌دهد تا با انتقال قابلیت‌هایی که فقط برای برخی (نه همه) از کاربران مفید است به کتابخانه‌های خارجی، در حجمی مناسب باقی بماند. کاربرانی که به توابع خاصی نیاز ندارند می‌توانند به‌سادگی از بارگذاری آن کتابخانه‌ها صرف‌نظر کنند. .sp کتابخانه‌های قلاب توسط هر یک از فرآیندهای مجزای Kea بارگذاری می‌شوند، نه به صورت کلی توسط کل Kea. این یعنی در میان موارد دیگر، می‌توان یک مجموعه از کتابخانه‌ها را به کارگزار DHCPv4 و مجموعه‌ای دیگر را به کارگزار DHCPv6 اختصاص داد. .sp همچنین برای یک فرآیند این امکان وجود دارد که چندین کتابخانه را بارگذاری کند. هنگامی که پردازش به یک نقطهٔ قلاب می‌رسد، Kea توابع کتابخانهٔ قلاب متصل به آن را فراخوانی می‌کند. اگر چندین کتابخانه تابعی را به یک نقطهٔ قلاب مشخص پیوند زده باشند، Kea همهٔ آن‌ها را به ترتیبی که در فایل پیکربندی مشخص شده است فراخوانی می‌کند. این ترتیب ممکن است اهمیت داشته باشد؛ برای جزئیات به مستندات کتابخانه‌ها مراجعه کنید. .sp هنگامی که یک فرآیند Kea کتابخانه‌ای را تخلیه (unload) می‌کند، انتظار دارد تابع \fBdlclose\fP تمام نمادهای کتابخانه و همچنین کد آن را از فضای آدرس حذف کند. گرچه بیشتر سیستم‌عامل‌ها تابع \fBdlclose\fP را پیاده‌سازی کرده‌اند، اما این رفتار طبق استاندارد POSIX الزامی نیست و همهٔ سیستم‌ها از آن پشتیبانی نمی‌کنند؛ برای نمونه، کتابخانهٔ musl که به‌طور پیش‌فرض در Alpine Linux استفاده می‌شود، تابع \fBdlclose\fP را به‌صورت بی‌عملیات (no-op) پیاده‌سازی کرده است. در چنین سیستم‌هایی، کتابخانه در عمل در تمام طول عمر فرآیند بارگذاری‌شده باقی می‌ماند، به این معنی که برای به‌روزرسانی کتابخانه‌ها به نسخه‌های جدیدتر، فرآیند باید دوباره راه‌اندازی (restart) شود؛ صرفِ پیکربندی مجدد یا بارگذاری مجدد (reload) فرآیند Kea کافی نخواهد بود. .sp بخش‌های بعدی نحوهٔ نصب و پیکربندی کتابخانه‌های قلاب را شرح می‌دهند. کاربرانی که علاقه‌مند به نوشتن کتابخانهٔ قلاب خود هستند می‌توانند اطلاعات لازم را در بخش Hooks Developer\(aqs Guide از راهنمای Kea Developer\(aqs Guide \%\& بیابند. .sp توجه داشته باشید که برخی از کتابخانه‌ها تحت مجوزهای متفاوتی عرضه می‌شوند. .sp همچنین لطفاً توجه داشته باشید که برخی از کتابخانه‌ها ممکن است به وابستگی‌های اضافی و/یا فعال بودن کلیدهای کامپایل خاصی نیاز داشته باشند..SS "نصب بسته‌های قلاب (Hook Packages)" .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برای جزئیات بیشتر درباره نصب قلاب‌های مشترکین Kea، لطفاً این مقاله پایگاه دانش را بخوانید: \%\&. .UNINDENT .UNINDENT .sp بیشتر بسته‌های قلاب اکنون در سورس‌های اصلی Kea گنجانده شده‌اند. نیازی به انجام کار خاصی برای کامپایل یا نصب آن‌ها نیست، چرا که آن‌ها توسط روال‌های معمول ساخت و نصب پوشش داده می‌شوند. لطفاً برای یک نمای کلی از فرآیند نصب، به Installation \%<#\:installation> مراجعه کنید. .sp شرکت ISC چندین قلاب اضافی مخصوص مشترکین را در قالب بسته ارائه می‌دهد که روال نصب مشابهی دارند اما نیازمند چند مرحله بیشتر هستند. جهت راحتی کاربران، فرآیند نصب قلاب‌های مشترکین در این بخش شرح داده شده است. .sp 1. بسته را دانلود کنید؛ دستورالعمل‌های دقیق در مقاله پایگاه دانش بالا ارائه شده است. بسته فایلی با نامی مشابه \fBkea\-subscriber\-|release|.tar.xz\fP\& خواهد بود. .sp 2. مدیران سیستمی که از زمان نصب اولیه Kea، سورس‌های نسخه مربوط به بسته متن‌باز Kea را روی سیستم خود دارند، باید این مرحله را نادیده بگیرند. در غیر این صورت، سورس Kea را از tarball اصلی دانلود شده استخراج کنید. برای مثال، با دانلود Kea 3.2.0، باید یک tarball به نام \fBkea\-|release|.tar.xz\fP روی سیستم موجود باشد. این tarball را استخراج کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ tar \-Jxvf kea\-3.2.0\&.tar.xz .EE .UNINDENT .UNINDENT .sp این کار tarball را در زیردایرکتوری \fBkea\-|release|\fP از دایرکتوری کاری فعلی استخراج می‌کند. .sp 3. بسته tarball قلاب‌های مشترکین Kea را در همان دایرکتوری که سورس اصلی Kea در آن قرار دارد استخراج کنید. هنگامی که Kea 3.2.0 در زیردایرکتوری \fBkea\-|release|\fP استخراج شد و tarball مشترکین Kea در دایرکتوری فعلی قرار گرفت، مراحل زیر tarball مشترکین را در مکان مناسب استخراج خواهند کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ cd kea\-3.2.0 $ tar \-Jxvf ../kea\-subscriber\-3.2.0\&.tar.xz .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که استخراج بسته مشترکین Kea، فایل‌ها را در دایرکتوری با نام \fBpremium\fP\& قرار می‌دهد. صرف‌نظر از نام بسته، این دایرکتوری همیشه \fBpremium\fP\& نامیده می‌شود. .INDENT 0.0 .IP 4. 3 فرآیند ساخت (build) را آماده‌سازی کنید. مطمئن شوید که \fBmeson\fP و \fBninja\fP روی سیستم شما نصب شده‌اند. بخش اول خروجی باید چیزی شبیه به این باشد: .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ meson setup build .EE .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX Package: Name: kea Version: 3.2.0 Extended version: 3.2.0 (tarball) Version type: development OS Family: Linux Prefix: /opt/kea Hooks directory: /opt/kea/lib/kea/hooks Premium hooks: yes .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 6. 3 کامپایل Kea. .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ meson compile \-C build .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 7. 3 نصب سورس‌های Kea همراه با قلاب‌ها: .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ sudo make install .EE .UNINDENT .UNINDENT .sp مکان نصب کتابخانه‌های قلاب به این بستگی دارد که آیا پارامتر \fB\-\-prefix\fP در مرحله \fBmeson setup\fP مشخص شده بود یا خیر. در غیر این صورت، مکان پیش‌فرض \fB/usr/local/lib/kea/hooks\fP\& خواهد بود. نصب صحیح کتابخانه‌ها را می‌توان با این دستور بررسی کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ls \-l /usr/local/lib/kea/hooks/*.so /usr/local/lib/kea/hooks/libddns_gss_tsig.so /usr/local/lib/kea/hooks/libdhcp_bootp.so /usr/local/lib/kea/hooks/libdhcp_class_cmds.so /usr/local/lib/kea/hooks/libdhcp_ddns_tuning.so /usr/local/lib/kea/hooks/libdhcp_flex_id.so /usr/local/lib/kea/hooks/libdhcp_flex_option.so /usr/local/lib/kea/hooks/libdhcp_ha.so /usr/local/lib/kea/hooks/libdhcp_host_cache.so /usr/local/lib/kea/hooks/libdhcp_host_cmds.so /usr/local/lib/kea/hooks/libdhcp_lease_cmds.so /usr/local/lib/kea/hooks/libdhcp_lease_query.so /usr/local/lib/kea/hooks/libdhcp_legal_log.so /usr/local/lib/kea/hooks/libdhcp_limits.so /usr/local/lib/kea/hooks/libdhcp_mysql.so /usr/local/lib/kea/hooks/libdhcp_perfmon.so /usr/local/lib/kea/hooks/libdhcp_pgsql.so /usr/local/lib/kea/hooks/libdhcp_ping_check.so /usr/local/lib/kea/hooks/libdhcp_radius.so /usr/local/lib/kea/hooks/libdhcp_run_script.so /usr/local/lib/kea/hooks/libdhcp_stat_cmds.so /usr/local/lib/kea/hooks/libdhcp_subnet_cmds.so .EE .UNINDENT .UNINDENT .sp همراه با کتابخانه‌های مشترکین زیر: .INDENT 0.0 .INDENT 3.5 .sp .EX /usr/local/lib/kea/hooks/libdhcp_cb_cmds.so /usr/local/lib/kea/hooks/libdhcp_rbac.so .EE .UNINDENT .UNINDENT .sp فهرست دقیق بازگردانده شده به بسته‌های نصب‌شده بستگی دارد. اگر دایرکتوری از طریق \fB\-\-prefix\fP مشخص شده باشد، کتابخانه‌های قلاب در \fB{prefix directory}/lib/kea/hooks\fP\& قرار خواهند گرفت..SS پیکربندی کتابخانه‌های هوک (Configuring Hook Libraries) .sp کتابخانه‌های هوک (hook libraries) برای یک فرآیند مشخص با استفاده از کلمهٔ کلیدی \fBhooks\-libraries\fP در پیکربندی آن فرآیند پیکربندی می‌شوند. (توجه داشته باشید که واژهٔ \(dqhooks\(dq جمع است.) مقدار این کلمهٔ کلیدی آرایه‌ای از ساختارهای نگاشت (map structures) است، که هر ساختار متناظر با یک کتابخانهٔ هوک می‌باشد. برای نمونه، جهت راه‌اندازی دو کتابخانهٔ هوک برای سرور DHCPv4، پیکربندی به صورت زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqfirst_custom_hooks_example.so\(dq }, { \(dqlibrary\(dq: \(dqsecond_custom_hooks_example.so\(dq, \(dqparameters\(dq: { \(dqmail\(dq: \(dqspam@example.com\(dq, \(dqfloor\(dq: 13, \(dqdebug\(dq: false, \(dqusers\(dq: [ \(dqalice\(dq, \(dqbob\(dq, \(dqcharlie\(dq ], \(dqlanguages\(dq: { \(dqfrench\(dq: \(dqbonjour\(dq, \(dqklingon\(dq: \(dqyl\(aqel\(dq } } } ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کتابخانه‌ها حتی اگر فهرست آن‌ها تغییری نکرده باشد مجدداً بارگذاری می‌شوند، زیرا ممکن است پارامترهای تعیین‌شده برای کتابخانه (یا فایل‌هایی که آن پارامترها به آن‌ها اشاره دارند) تغییر کرده باشند. .UNINDENT .UNINDENT .sp از نسخهٔ Kea 2.7.9، کتابخانه‌های هوک تنها می‌توانند از دایرکتوری پیش‌فرض نصب که در زمان کامپایل تعیین شده و در گزارش پیکربندی به عنوان \(dqHooks directory\(dq نشان داده شده است، بارگذاری شوند. این مقدار ممکن است در زمان راه‌اندازی با تنظیم متغیر محیطی \fBKEA_HOOKS_PATH\fP بر روی مسیر دلخواه بازنویسی شود. اگر مسیری غیر از این مقدار در یک عنصر \fBlibrary\fP استفاده شود، Kea خطایی صادر کرده و از بارگذاری کتابخانه خودداری خواهد کرد. برای سهولت در استفاده، عناصر \fBlibrary\fP باید بخش‌های مسیر را حذف کنند و تنها نام فایل را همان‌طور که در زیر نشان داده شده مشخص نمایند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqfirst_custom_hooks_example.so\(dq }, { \(dqlibrary\(dq: \(dqsecond_custom_hooks_example.so\(dq } ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پشتیبانی از بخش‌های مسیر در عناصر \fBlibrary\fP از نسخهٔ 2.7.8 منسوخ شده است و در نهایت حذف خواهد شد. .UNINDENT .UNINDENT .sp کتابخانه‌ها ممکن است پارامترهای اضافی داشته باشند که اجباری نیستند، به این معنا که ممکن است کتابخانه‌هایی وجود داشته باشند که نیازی به آن‌ها نداشته باشند. با این حال، برای هر کتابخانهٔ مشخص اغلب الزامی برای تعیین مجموعه‌ای خاص از پارامترها وجود دارد. لطفاً برای جزئیات به مستندات هر کتابخانهٔ مجزا مراجعه کنید. در مثال بالا، کتابخانهٔ نخست (\fB/opt/first_custom_hooks_example.so\fP) هیچ پارامتری ندارد. کتابخانهٔ دوم (\fB/opt/local/second_custom_hooks_example.so\fP) دارای پنج پارامتر است: تعیین mail (پارامتر رشته‌ای)، floor (پارامتر عددی صحیح)، debug (پارامتر بولی)، لیست‌ها (فهرستی از رشته‌ها)، و نگاشت‌ها (شامل رشته‌ها). در صورت پشتیبانی کتابخانه، می‌توان از پارامترهای تو در تو استفاده کرد. این موضوع به تفصیل در بخش Hooks Developer\(aqs Guide از راهنمای توسعه‌دهندهٔ Kea توضیح داده شده است \%\&. .sp برخی هوک‌ها برای تنظیم پارامترها از بافتار کاربر (user context) استفاده می‌کنند. بخش User Contexts in Hooks را ببینید\&. .sp نکات: .INDENT 0.0 .IP \(bu 2 مسیر کامل هر کتابخانه باید مشخص شود. .IP \(bu 2 همان‌طور که در بالا اشاره شد، ترتیبی که هوک‌ها فراخوانی می‌شوند ممکن است حائز اهمیت باشد؛ برای جزئیات به مستندات مربوط به هر کتابخانه مراجعه کنید. .IP \(bu 2 یک فهرست خالی همان اثری را دارد که گویی عنصر پیکربندی \fBhooks\-libraries\fP به‌طور کلی حذف شده است. .sp \fBنکته:\fP .INDENT 2.0 .INDENT 3.5 یک حالت وجود دارد که این موضوع در آن صادق نیست: اگر Kea با پیکربندی‌ای در حال اجرا باشد که شامل یک مورد \fBhooks\-libraries\fP است، و آن مورد حذف شده و پیکربندی مجدداً بارگذاری شود، این حذف نادیده گرفته شده و کتابخانه‌ها بارگذاری‌شده باقی می‌مانند. به عنوان یک راهکار موقت، به جای حذف مورد \fBhooks\-libraries\fP، آن را به یک فهرست خالی تغییر دهید. .UNINDENT .UNINDENT .UNINDENT .sp در حال حاضر، تنها فرآیندهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> از کتابخانه‌های هوک پشتیبانی می‌کنند..SS ترتیب پیکربندی (Order of Configuration): .sp بسیار مهم است توجه داشته باشید که ترتیب پیکربندی کتابخانه‌های قلاب (hook libraries)، تعیین‌کنندهٔ ترتیب اجرای فراخوانی‌های آن‌ها (callouts) در مواردی است که بیش از یک کتابخانهٔ قلاب، یک فراخوانی یکسان را پیاده‌سازی کرده باشند. برای مثال، جهت استفاده از کتابخانهٔ قلاب Flexible Identifier (که Flex ID نیز نامیده می‌شود) برای فرمول‌بندی شناسه‌های کلاینت در کنار کتابخانهٔ قلاب High Availability (HA) جهت توازن بار HA، ضروری است که کتابخانهٔ Flex ID ابتدا در بخش \fBhooks\-libraries\fP سرور مشخص شود. این کار تضمین می‌کند که شناسهٔ کلاینت پیش از آن‌که کتابخانهٔ HA از آن برای توازن بار استفاده کند، توسط کتابخانهٔ Flex ID شکل گرفته باشد. به همین ترتیب، بهتر است کتابخانهٔ Forensic Logging در انتها مشخص شود تا اطمینان حاصل گردد پیش از بارگذاری آن، سایر قلاب‌های نصب‌شده سهم خود را در پردازش بسته اعمال کرده‌اند. .SS زمینه‌های کاربر در قلاب‌ها (User Contexts in Hooks) .sp کتابخانه‌های قلاب می‌توانند پارامترهای پیکربندی مختص به خود را داشته باشند، که در صورت اعمال پارامتر بر کل کتابخانه، بسیار مناسب و کاربردی است. با این حال، گاهی اوقات سودمند است که موجودیت‌های پیکربندی خاصی را با داده‌های پیکربندی اضافی گسترش داد. اینجاست که مفهوم زمینه‌های کاربر (user contexts) مطرح می‌شود. مدیر سیستم می‌تواند مجموعه‌ای اختیاری از داده‌ها را تعریف کرده و تا زمانی که داده‌ها به صورت یک نگاشت (map) در قالب JSON مشخص شده باشند، آن‌ها را به ساختارهای Kea متصل کند. به‌ویژه، تعریف فیلدهایی از نوع اعداد صحیح (integers)، رشته‌ها (strings)، مقادیر بولی (boolean)، فهرست‌ها (lists) یا نگاشت‌ها (maps) امکان‌پذیر است. همچنین می‌توان ساختارهای تو‌در‌تو با هر میزان پیچیدگی را تعریف نمود. Kea به‌خودی‌خود از این داده‌ها استفاده نمی‌کند؛ بلکه صرفاً آن‌ها را ذخیره کرده و در دسترس کتابخانه‌های قلاب قرار می‌دهد. .sp کاربرد دیگر برای user contexts می‌تواند ذخیره‌سازی یادداشت‌ها و سایر اطلاعاتی باشد که توسط Kea نگهداری خواهند شد. کامنت‌های معمولی هنگام بارگذاری پیکربندی نادیده گرفته و دور ریخته می‌شوند، اما زمینه‌های کاربر حفظ می‌گردند. این ویژگی برای مواردی مفید است که مدیران سیستم بخواهند یادداشت‌هایشان برای مثال در طول عملیات‌های \fBconfig\-set\fP \%<#\:std-isccmd-config-set> یا \fBconfig\-get\fP \%<#\:std-isccmd-config-get> پابرجا بمانند. .sp اگر زمینهٔ کاربر در یک بافت خاص پشتیبانی شود، تجزیه‌کننده (parser) مدخل‌های \(dqcomment\(dq را به زمینهٔ کاربر حاوی یک مدخل \(dqcomment\(dq تبدیل می‌کند. .sp زمینهٔ کاربر می‌تواند پیکربندی مربوط به چندین قلاب و یادداشت‌ها را به‌طور هم‌زمان در خود ذخیره کند. .sp برخی از قلاب‌ها از زمینهٔ کاربر برای پیکربندی‌هایی استفاده می‌کنند که می‌توان بدون نیاز به راه‌اندازی مجدد سرور، آن‌ها را به‌سادگی ویرایش کرد. .sp قلاب DDNS Tuning از user context برای پیکربندی رفتار به ازای هر زیرشبکه (per\-subnet) استفاده می‌کند. نمونه‌ای از این پیکربندی در ادامه آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqsubnet4\(dq: [{ \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq } ], \(dquser\-context\(dq: { \(dqddns\-tuning\(dq: { \(dqhostname\-expr\(dq: \(dq\(aqguest\-\(aq+int8totext(substring(pkt4.yiaddr, 0,1))+\(aq\-\(aq \e +int8totext(substring(pkt4.yiaddr, 1,2))+\(aq\-\(aq \e +int8totext(substring(pkt4.yiaddr, 2,3))+\(aq\-\(aq \e +int8totext(substring(pkt4.yiaddr, 3,4))\(dq }, \(dqlast\-modified\(dq: \(dq2017\-09\-04 13:32\(dq, \(dqphones\(dq: [ \(dqx1234\(dq, \(dqx2345\(dq ], \(dqdevices\-registered\(dq: 42, \(dqbilling\(dq: false } }] .EE .UNINDENT .UNINDENT .sp قلاب Limits از user\-context در کلاس‌ها و زیرشبکه‌ها برای تنظیم پارامترها استفاده می‌کند. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqgold\(dq, \(dquser\-context\(dq: { \(dqlimits\(dq: { \(dqaddress\-limit\(dq: 2, \(dqprefix\-limit\(dq: 1, \(dqrate\-limit\(dq: \(dq1000 packets per second\(dq } } } ], \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_limits.so\(dq } ], \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8::/64\(dq } ], \(dqsubnet\(dq: \(dq2001:db8::/64\(dq, \(dquser\-context\(dq: { \(dqlimits\(dq: { \(dqaddress\-limit\(dq: 4, \(dqprefix\-limit\(dq: 2, \(dqrate\-limit\(dq: \(dq10 packets per minute\(dq } } } ] } } .EE .UNINDENT .UNINDENT .SS محدودیت بسته‌های متوقف‌شده (Parked\-Packet Limit) .sp سرورهای Kea شامل سازوکاری هستند که به موجب آن، پاسخ به یک بستهٔ کلاینت می‌تواند تا زمان اتمام کار کتابخانهٔ قلاب معلق نگه داشته شود. ما از این فرایند با عنوان \(dqپارک کردن بسته\(dq یاد می‌کنیم. هنگامی که ادامهٔ کار آماده شد، سرور پاسخ را از حالت پارک خارج کرده و پردازش را ادامه می‌دهد. .sp یک پارامتر سراسری به نام \fBparked\-packet\-limit\fP وجود دارد که می‌توان از آن برای محدود کردن تعداد پاسخ‌هایی که در هر لحظه می‌توانند پارک شوند، استفاده کرد. این پارامتر به عنوان روشی برای مدیریت ازدحام عمل کرده و زمانی که حجم پرس‌وجوهای کلاینت‌ها از توان پاسخ‌گویی سرور پیشی می‌گیرد، از غرق شدن سرور زیر بار ترافیک جلوگیری می‌کند. هنگامی که این حد نصاب تکمیل شود، سرور یک لاگ ثبت کرده و هر پاسخ جدیدی را تا زمان خالی شدن ظرفیت پارک دور می‌اندازد (drop می‌کند). .sp به‌طور کلی، مقادیر کوچک‌تر برای محدودیت ظرفیت پارک احتمالاً باعث ریزش (drop) بیشتر اما با زمان پاسخ‌گویی کوتاه‌تر می‌شوند؛ مقادیر بزرگ‌تر احتمالاً به ریزش کمتر اما با زمان پاسخ‌گویی طولانی‌تر می‌انجامند. در حال حاضر، مقدار پیش‌فرض برای \fBparked\-packet\-limit\fP برابر با 256 است. .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 استفاده از یک مقدار بسیار کوچک ممکن است منجر به نرخ ریزش (drop rate) غیرضروری و بالایی شود، در حالی که استفاده از مقداری بیش از حد بزرگ می‌تواند زمان پاسخ‌گویی را تا حدی طولانی کند که عملاً دیگر کارآمد نباشد. مقدار 0 با اینکه مجاز است، این محدودیت را به‌کلی غیرفعال می‌کند، اما این کار اکیداً نهی می‌شود؛ چرا که ممکن است منجر به عدم پاسخ‌گویی سرورهای Kea به کلاینت‌ها شود. انتخاب بهترین مقدار بسیار وابسته به شرایط هر سامانه است؛ توصیه می‌کنیم کاربران در ابتدا آن را روی مقدار پیش‌فرض 256 بگذارند و نحوهٔ رفتار سیستم را در طول زمان تحت شرایط مختلف بار ترافیکی مشاهده کنند. .UNINDENT .UNINDENT .sp در ادامه مثالی از پارامتر سراسری آورده شده است که به همراه \fBlibdhcp_ha.so\fP استفاده شده است. این تنظیم، تعداد بسته‌های متوقف‌شدهٔ هم‌زمان را به 128 کاهش می‌دهد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqparked\-packet\-limit\(dq: 128 \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [ { \(dqmode\(dq: \(dqhot\-standby\(dq, \(dqpeers\(dq: [ { \(dqname\(dq: \(dqserver1\(dq, \(dqrole\(dq: \(dqprimary\(dq, \(dqurl\(dq: \(dqhttp://127.0.0.1:8080/\(dq }, { \(dqname\(dq: \(dqserver2\(dq, \(dqrole\(dq: \(dqstandby\(dq, \(dqurl\(dq: \(dqhttp://127.0.0.1:8088/\(dq } ], \(dqthis\-server\-name\(dq: \(dqserver1\(dq } ] } } ] } } .EE .UNINDENT .UNINDENT.SS کتابخانه‌های هوک دردسترس .sp همان‌طور که در بالا توضیح داده شد، سازوکار هوک روشی را برای سفارشی‌سازی یک کارساز Kea بدون تغییر در کد اصلی (core) فراهم می‌کند. ISC تصمیم گرفته است با بهره‌گیری از این ویژگی، قابلیت‌هایی را ارائه دهد که ممکن است تنها برای زیرمجموعه‌ای از کاربران Kea مفید باشند. بدین منظور، ISC چندین کتابخانهٔ هوک ایجاد کرده است که در بخش‌های بعدی به آن‌ها پرداخته می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 3.0.0، بیشتر این کتابخانه‌ها بدون هزینه همراه با کد پایهٔ متن‌باز در دسترس هستند؛ تعداد اندکی تنها برای سازمان‌هایی در دسترس هستند که از طریق قراردادهای پشتیبانی غیررایگان ISC در توسعهٔ Kea مشارکت دارند. پشتیبانی غیررایگان شامل کمک‌های مهندسی حرفه‌ای، اعلان‌های امنیتی زودهنگام، مشارکت در برنامه‌ریزی نقشهٔ راه ISC و مزایای بسیار دیگر است، و هم‌زمان به پایداری Kea در بلندمدت کمک می‌کند. ISC شرکت‌ها و سازمان‌ها را تشویق می‌کند تا خرید قرارداد پشتیبانی را مد نظر قرار دهند؛ اطلاعات بیشتر را می‌توان با تکمیل فرم در \%\& به دست آورد. .UNINDENT .UNINDENT .sp جدول زیر فهرستی از کتابخانه‌های هوک را که در حال حاضر از سوی ISC ارائه می‌شوند نشان می‌دهد. توجه به این که کدام کتابخانه‌ها می‌توانند توسط کدام فرایندهای Kea بارگذاری شوند دارای اهمیت است. اگر کتابخانه‌ای از سوی ISC مطابق انتظار کار نکرد، لطفاً مطمئن شوید که بر اساس جدول زیر توسط فرایند صحیح بارگذاری شده باشد. .SS فهرست کتابخانه‌های هوک دردسترس .TS box center; l|l|l. T{ نام T} T{ دسترسی T} T{ توضیحات T} _ T{ BOOTP T} T{ متن‌باز Kea T} T{ این کتابخانهٔ هوک، پشتیبانی از BOOTP را مطابق با تعریف RFC 1497 اضافه می‌کند. این کتابخانه درخواست‌های دریافت‌شدهٔ BOOTP را شناسایی می‌کند: این درخواست‌ها به بسته‌های DHCPREQUEST ترجمه می‌شوند، در کلاس کلاینت BOOTP قرار می‌گیرند و اجاره‌هایی با طول عمر نامحدود دریافت می‌کنند. T} _ T{ Class Commands T} T{ متن‌باز Kea T} T{ این کتابخانهٔ هوک امکان افزودن، به‌روزرسانی، حذف و واکشی کلاس‌های کلاینتِ پیکربندی‌شدهٔ DHCP را بدون نیاز به راه‌اندازی مجدد کارساز DHCP فراهم می‌کند. T} _ T{ Configuration Backend Commands T} T{ مشتریان پشتیبانی ISC T} T{ این کتابخانهٔ هوک مجموعه‌ای از دستورها را برای مدیریت اطلاعات پیکربندی Kea در یک پایگاه داده پیاده‌سازی می‌کند. این کتابخانه فقط در کنار یکی از پیاده‌سازی‌های پشتیبانی‌شدهٔ Configuration Backend قابل استفاده است. T} _ T{ DDNS Tuning T} T{ متن‌باز Kea T} T{ این کتابخانهٔ هوک رفتارهای سفارشی مربوط به به‌روزرسانی‌های Dynamic DNS را بر پایهٔ هر کلاینت اضافه می‌کند. ویژگی اصلی آن امکان محاسبهٔ نام میزبان مورداستفاده برای DNS با استفاده از یک عبارت است. T} _ T{ Flexible Identifier T} T{ متن‌باز Kea T} T{ نرم‌افزار Kea روشی را برای مدیریت رزروهای میزبان فراهم می‌کند که شامل آدرس‌ها، پیشوندها، گزینه‌ها، کلاس‌های کلاینت و سایر ویژگی‌ها است. رزرو می‌تواند بر اساس آدرس سخت‌افزاری، DUID، circuit\-id یا client\-id در DHCPv4 و بر اساس آدرس سخت‌افزاری یا DUID در DHCPv6 انجام شود. با این حال، گاهی سناریوهایی رخ می‌دهد که در آن‌ها رزرو پیچیده‌تر است، مانند استفاده از گزینه‌هایی غیر از موارد یادشده، استفاده از بخش‌هایی از گزینه‌هایی خاص، یا شاید استفاده از ترکیبی از چندین گزینه و فیلد برای شناسایی یکتای یک کلاینت. این سناریوها توسط برنامهٔ هوک Flexible Identifier پوشش داده می‌شوند. این برنامه امکان تعریف یک عبارت، مشابه عبارت مورد استفاده در کلاس‌بندی کلاینت، مانند \fBsubstring(relay6[0].option[37],0,6)\fP\& را می‌دهد. هر بستهٔ ورودی بر اساس آن عبارت ارزیابی شده و سپس مقدار آن در پایگاه دادهٔ رزروها جستجو می‌شود. T} _ T{ Flexible Option T} T{ متن‌باز Kea T} T{ این کتابخانه هوک‌هایی را ارائه می‌دهد که مقادیر گزینه را به‌جای مقادیر ایستای پیکربندی‌شده محاسبه می‌کنند. یک عبارت بر روی بستهٔ پرس‌وجو ارزیابی می‌شود. عملیات‌های تعریف‌شدهٔ add، supersede و remove با استفاده از نتیجهٔ ارزیابی، پیش از ارسال روی بستهٔ پاسخ اعمال می‌شوند. T} _ T{ Forensic Logging T} T{ متن‌باز Kea T} T{ این کتابخانه هوک‌هایی را فراهم می‌آورد که گزارشی تفصیلی از تخصیص‌ها و تمدیدهای اجاره را در مجموعه‌ای از فایل‌های لاگ ثبت می‌کنند. در بسیاری از حوزه‌های قضایی، شرکت‌ها \(en به‌ویژه ISPها \(en موظف‌اند اطلاعات مربوط به آدرس‌هایی را که به کلاینت‌های DHCP اجاره داده‌اند ثبت کنند. این کتابخانه برای کمک به این الزام طراحی شده است. اگر اطلاعاتی که ثبت می‌کند کافی باشد، می‌توان مستقیماً از آن استفاده کرد. اگر حوزه‌ای قضایی نیازمند ذخیرهٔ مجموعهٔ متفاوتی از اطلاعات باشد، می‌توان از آن به عنوان الگو یا مثالی برای ایجاد هوک‌های لاگ‌گیری سفارشی استفاده نمود. در Kea 1.9.8، پارامترهای بیشتری اضافه شد تا انعطاف‌پذیری بیشتری در رابطه با این که چه اطلاعاتی باید ثبت شوند به کاربران داده شود. T} _ T{ GSS\-TSIG T} T{ متن‌باز Kea T} T{ این کتابخانهٔ هوک پشتیبانی از استفاده از GSS\-TSIG برای امضای به‌روزرسانی‌های DNS را به کارساز Kea D2 (kea\-dhcp\-ddns) اضافه می‌کند. T} _ T{ High Availability T} T{ متن‌باز Kea T} T{ خطر از دسترس خارج شدن سرویس DHCP را می‌توان با برپایی یک جفت کارساز DHCP در یک شبکه به حداقل رساند. دو حالت عملیاتی پشتیبانی می‌شود. حالت اول موازنهٔ بار نام دارد و گاهی از آن با عنوان \(dqactive\-active\(dq یاد می‌شود. هر کارساز می‌تواند گروه‌های منتخبی از کلاینت‌ها را در این شبکه مدیریت کند، یا در صورتی که تشخیص دهد همتایش از دسترس خارج شده، تمام کلاینت‌ها را مدیریت نماید. همچنین می‌توان یک کارساز را برای پاسخگویی به همهٔ کلاینت‌های DHCP تعیین کرد و کارساز دیگر را در حالت آماده‌باش قرار داد. این حالت \(dqhot standby\(dq نامیده می‌شود و گاهی به آن \(dqactive\-passive\(dq می‌گویند. این کارساز تنها زمانی عملکرد DHCP خود را فعال می‌کند که تشخیص دهد همتایش در دسترس نیست. چنین همکاری‌ای میان کارسازهای DHCP مستلزم آن است که این کارسازها پیوسته با یکدیگر در ارتباط باشند تا به‌روزرسانی‌های مربوط به اجاره‌های اختصاص‌یافته را ارسال کنند و به صورت دوره‌ای عملیاتی بودن همتای خود را بیازمایند. این کتابخانهٔ هوک همچنین امکان ارسال به‌روزرسانی‌های اجاره را به کارسازهای پشتیبان خارجی فراهم می‌کند که داشتن یک جایگزین کاملاً به‌روز را بسیار ساده‌تر می‌سازد. T} _ T{ Host Cache T} T{ متن‌باز Kea T} T{ پاسخ‌دهی برخی از Backendهای پایگاه داده، مانند RADIUS، ممکن است زمان زیادی ببرد. از آنجا که Kea به‌طور کلی همگام است، کارایی Backend مستقیماً بر کارایی DHCP اثر می‌گذارد. برای به حداقل رساندن افت کارایی، این کتابخانه روشی را برای کَش کردن پاسخ‌های سایر میزبان‌ها فراهم می‌کند. این شامل کَش منفی نیز می‌شود، یعنی توانایی به‌خاطرسپاری اینکه هیچ اطلاعات کلاینتی در پایگاه داده وجود ندارد. T} _ T{ Host Commands T} T{ متن‌باز Kea T} T{ کارساز Kea روشی برای ذخیرهٔ رزروهای میزبان در یک پایگاه داده فراهم می‌کند. در بسیاری از استقرارهای بزرگ‌تر، مدیریت این اطلاعات در زمان اجرای کارساز سودمند است. این کتابخانه دستورهای مدیریتی را برای افزودن، پرس‌وجو و حذف رزروهای میزبان به شکلی امن و بدون راه‌اندازی دوبارهٔ کارساز ارائه می‌دهد. به‌ویژه، پارامترها را اعتبارسنجی می‌کند، بنابراین تلاشی برای درج داده‌های نادرست، مانند افزودن میزبانی با شناسهٔ متداخل در همان زیرشبکه، رد خواهد شد. این دستورها از طریق کانال فرمان (JSON از طریق سوکت‌های UNIX یا HTTP/HTTPS) ارائه می‌شوند، T} _ T{ Lease Commands T} T{ متن‌باز Kea T} T{ این کتابخانهٔ هوک مجموعه‌ای از دستورها را برای مدیریت اجاره‌ها ارائه می‌دهد. Kea می‌تواند اطلاعات اجاره را در Backendهای مختلفی ذخیره کند: memfile، MySQL و PostgreSQL. این کتابخانه رابطی یکپارچه برای دستکاری اجاره‌ها به روشی هماهنگ و امن فراهم می‌کند. به‌ویژه، دستکاری اجاره‌های memfile در زمان اجرای Kea، بررسی درستی تغییرات، بررسی وجود اجاره، و حذف تمام اجاره‌های متعلق به یک زیرشبکهٔ خاص را امکان‌پذیر می‌کند. همچنین می‌تواند خطاهای پنهان را شناسایی کند، مانند افزودن اجاره‌ای با subnet\-id که در پیکربندی وجود ندارد، یا پیکربندی یک اجاره برای استفاده از آدرسی خارج از زیرشبکه‌ای که باید به آن تعلق داشته باشد. این کتابخانه مدیریت آسان بسترهای کاربری (user contexts) مرتبط با اجاره‌ها را ممکن می‌سازد. T} _ T{ Leasequery T} T{ متن‌باز Kea T} T{ این کتابخانه پشتیبانی از DHCPv4 Leasequery (RFC 4388)، DHCPv4 Bulk Leasequery (RFC6926)، DHCPv6 Leasequery (RFC 5007) و DHCPv6 Bulk Leasequery (RFC5460) را اضافه می‌کند. T} _ T{ Limits T} T{ متن‌باز Kea T} T{ با این کتابخانهٔ هوک، کارسازهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> می‌توانند نرخی را که بسته‌ها بر اساس آن پاسخ دریافت می‌کنند محدود نمایند. این محدودیت می‌تواند بر پایهٔ هر کلاس کلاینت یا هر زیرشبکه اعمال شود. T} _ T{ MySQL Support Library T} T{ متن‌باز Kea T} T{ این کتابخانهٔ هوک، پشتیبانی از استفاده از پایگاه(های) دادهٔ MySQL را برای Backendهای Lease، Host و Configuration در Kea ارائه می‌دهد. T} _ T{ PerfMon T} T{ متن‌باز Kea T} T{ با این کتابخانهٔ هوک، کارسازهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> می‌توانند داده‌های مربوط به کارایی را رصد و گزارش کنند. T} _ T{ Ping Check T} T{ متن‌باز Kea T} T{ با این کتابخانهٔ هوک، کارساز \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> می‌تواند پیش از پیشنهاد آدرس‌های نامزد اجاره به کلاینت‌ها، بررسی پینگ را روی آن‌ها انجام دهد. T} _ T{ PostgreSQL Support Library T} T{ متن‌باز Kea T} T{ این کتابخانهٔ هوک، پشتیبانی از استفاده از پایگاه(های) دادهٔ PostgreSQL را برای Backendهای Lease، Host و Configuration در Kea ارائه می‌دهد. T} _ T{ RADIUS T} T{ متن‌باز Kea T} T{ کتابخانهٔ هوک RADIUS به Kea اجازه می‌دهد با استفاده از سازوکارهای access و accounting با کارسازهای RADIUS در ارتباط باشد. سازوکار access می‌تواند برای کنترل دسترسی، تخصیص آدرس‌های IPv4 یا IPv6 خاصِ رزروشده توسط RADIUS، تخصیص پویای آدرس‌ها از مخزن‌های (pools) تعیین‌شده توسط RADIUS، یا رد کامل پیام‌های کلاینت استفاده شود. سازوکار accounting به کارساز RADIUS اجازه می‌دهد فعالیت دستگاه را در گذر زمان رهگیری کند. T} _ T{ RBAC T} T{ مشتریان پشتیبانی ISC T} T{ این کتابخانهٔ هوک پشتیبانی از پالایش دستورها بر اساس کنترل دسترسی نقش‌محور (Role\-Based Access Control) را به کارسازهای Kea (شامل kea\-dhcp4، kea\-dhcp6 و kea\-dhcp\-ddns) اضافه می‌کند. T} _ T{ Run Script T} T{ متن‌باز Kea T} T{ این کتابخانهٔ هوک پشتیبانی از اجرای اسکریپت‌های خارجی را برای نقاط هوک خاص در پردازش بسته‌ها اضافه می‌کند. چندین متغیر محیطی صادرشده وجود دارند که در اختیار اسکریپت قرار می‌گیرند. T} _ T{ Statistics Commands T} T{ متن‌باز Kea T} T{ این کتابخانه دستورهای بیشتری را برای بازیابی آمارهای دقیق اجارهٔ DHCP، برای کارسازهای Kea DHCP که از یک پایگاه دادهٔ اجارهٔ مشترک بهره می‌برند، ارائه می‌دهد. این پیکربندی در استقرارهایی متداول است که به افزونگی سرویس DHCP نیاز دارند و از یک پایگاه دادهٔ اجارهٔ مشترک برای اجتناب از تکرار داده‌های اجاره بین کارسازهای DHCP استفاده می‌کنند. این کتابخانهٔ هوک آمارهای اجاره را برای هر زیرشبکه بازمی‌گرداند. T} _ T{ Subnet Commands T} T{ متن‌باز Kea T} T{ در استقرارهایی که پیکربندی زیرشبکه باید به طور مکرر به‌روزرسانی شود، این یک الزام حیاتی است که چنین به‌روزرسانی‌هایی بدون نیاز به پیکربندی مجددِ کامل یا راه‌اندازی دوبارهٔ کارساز DHCP انجام شوند. این کتابخانهٔ هوک امکان اعمال تغییرات تدریجی بر پیکربندی زیرشبکه، مانند افزودن یا حذف یک زیرشبکه را ممکن می‌سازد. همچنین امکان فهرست کردن تمام زیرشبکه‌های موجود و واکشی اطلاعات دقیق دربارهٔ یک زیرشبکهٔ انتخاب‌شده را فراهم می‌کند. دستورهای ارائه‌شده توسط این کتابخانه بر دیگر زیرشبکه‌ها یا پارامترهای پیکربندی که در حال حاضر توسط کارساز استفاده می‌شوند اثری نمی‌گذارند. T} _ T{ User Check T} T{ متن‌باز Kea T} T{ فهرست کاربران شناخته‌شده را از یک فایل می‌خواند. به کاربران ناشناخته، اجاره‌ای از آخرین زیرشبکهٔ تعریف‌شده در فایل پیکربندی اختصاص داده خواهد شد، برای مثال برای هدایت آن‌ها به یک پورتال محصور (captive portal). این عملکرد نشان می‌دهد که چگونه می‌توان از یک منبع خارجی اطلاعات برای اثرگذاری بر موتور تخصیص Kea استفاده کرد. این هوک بخشی از کد منبع Kea است و در دایرکتوری \fBsrc/hooks/dhcp/user_chk\fP در دسترس است. T} .TE .sp سازمان ISC امیدوار است با گذشت زمان، شاهد در دسترس قرار گرفتن کتابخانه‌های هوک بیشتری باشد که چه به صورت داخلی و چه خارجی توسعه یافته باشند. از آنجا که این فهرست ممکن است به صورت پویا تغییر کند، در یک صفحهٔ ویکی نگهداری می‌شود که در \%\& در دسترس است. از توسعه‌دهندگان یا دیگر افرادی که از کتابخانه‌های هوک ذکرنشده در آنجا آگاهی دارند، تقاضا می‌شود یادداشتی به فهرست‌های پستی kea\-users یا kea\-dev جهت به‌روزرسانی ارسال نمایند. (اطلاعات مربوط به تمام فهرست‌های پستی عمومی ISC را می‌توان در \%\& یافت.) .sp کتابخانه‌های توسعه‌یافته توسط ISC در بخش‌های بعدی با جزئیات شرح داده شده‌اند..SS \fBlibdhcp_bootp.so\fP: پشتیبانی از کلاینت‌های BOOTP .sp این کتابخانهٔ قلاب (hook library) پشتیبانی از BOOTP را به همراه افزونه‌های اطلاعات ارائه‌دهنده (vendor\-information extensions) (RFC 1497 \%) اضافه می‌کند. درخواست‌های دریافتی BOOTP تشخیص داده شده، با افزودن گزینهٔ \fBdhcp\-message\-type\fP به بسته‌های DHCPREQUEST تبدیل شده و در کلاس کلاینت \(dqBOOTP\(dq قرار می‌گیرند. اعضای این کلاس اجاره‌هایی با طول عمر نامحدود دریافت می‌کنند، اما از این کلاس می‌توان برای محافظت از یک استخر (pool) آدرس نیز استفاده کرد. .sp گزینه‌های ویژهٔ DHCP، مانند \fBdhcp\-message\-type\fP، از پاسخ‌های سرور حذف می‌شوند؛ پاسخ‌های کوتاه‌تر از حداقل اندازهٔ BOOTP یعنی ۳۰۰ بایت (octet)، تا این اندازه با داده‌های پرکننده تکمیل می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_bootp.so\fP بخشی از کد متن‌باز است و در دسترس تمامی کاربران Kea قرار دارد. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرایند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> بارگذاری شود، زیرا پروتکل BOOTP برای IPv6 وجود ندارد. .UNINDENT .UNINDENT .sp این کتابخانه مشابه سایر کتابخانه‌های قلاب بارگذاری می‌شود و هیچ پارامتری دریافت نمی‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_bootp.so\(dq }, ... ] } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 رزرو میزبان (host reservation) برای یک کلاینت BOOTP باید از آدرس سخت‌افزاری به عنوان شناسه استفاده کند (گزینهٔ \fBclient\-id\fP یک گزینهٔ ویژهٔ DHCP است). .UNINDENT .UNINDENT .sp بسته‌های ورودی BOOTP به کلاس BOOTP اضافه می‌شوند که به مدیران سیستم امکان می‌دهد کلاینت‌های BOOTP را در استخرهای جداگانه تفکیک کنند. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [ { // The DHCP class is the complement of the BOOTP class \(dqname\(dq: \(dqDHCP\(dq, \(dqtest\(dq: \(dqnot member(\(aqBOOTP\(aq)\(dq } ], \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { // BOOTP clients will be handled here \(dqpool\(dq: \(dq192.0.2.200 \- 192.0.2.254\(dq, \(dqclient\-classes\(dq: [ \(dqBOOTP\(dq ] }, { // Regular DHCP clients will be handled here \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.199\(dq, \(dqclient\-classes\(dq: [ \(dqDHCP\(dq ] }], ... }, ... ], ... } .EE .UNINDENT .UNINDENT .SS محدودیت‌های قلاب‌های BOOTP .sp در حال حاضر کتابخانهٔ BOOTP دارای محدودیت زیر است: .INDENT 0.0 .IP \(bu 2 پروتکل BOOTP پایه، مطابق با تعریف RFC 951 \%، پشتیبانی نمی‌شود. Kea تنها از BOOTP همراه با افزونه‌های اطلاعات ارائه‌دهنده پشتیبانی می‌کند. .UNINDENT .SS \fBlibdhcp_cb_cmds.so\fP: دستورهای بک‌اند پیکربندی .sp این کتابخانهٔ قلاب برای مدیریت پیکربندی‌های سرورهای Kea در یک پایگاه‌دادهٔ بک‌اند پیکربندی (configuration backend) به کار می‌رود. این کتابخانه باید همراه با کتابخانه‌های قلاب CB موجود که APIهای مشترک را برای ایجاد، خواندن، به‌روزرسانی و حذف (CRUD) اطلاعات پیکربندی در پایگاه‌های دادهٔ مربوطه پیاده‌سازی می‌کنند، استفاده شود. برای مثال: \fBlibdhcp_mysql.so\fP این API را برای MySQL پیاده‌سازی می‌کند در حالی که \fBlibdhcp_pgsql.so\fP این API را برای PostgreSQL پیاده‌سازی می‌نماید. برای مدیریت اطلاعات پیکربندی در یک پایگاه‌دادهٔ MySQL، هر دو کتابخانهٔ \fBlibdhcp_mysql.so\fP و \fBlibdhcp_cb_cmds.so\fP باید توسط سروری که برای مدیریت پیکربندی استفاده می‌شود بارگذاری شوند. برای مدیریت اطلاعات پیکربندی در یک پایگاه‌دادهٔ PostgreSQL، هر دو کتابخانهٔ \fBlibdhcp_pgsql.so\fP و \fBlibdhcp_cb_cmds.so\fP باید توسط سروری که برای مدیریت پیکربندی استفاده می‌شود بارگذاری شوند. .sp اطلاعات بیشتر دربارهٔ چگونگی پیکربندی کتابخانهٔ قلاب بک‌اند پیکربندی برای استفاده با یک پایگاه‌دادهٔ MySQL یا PostgreSQL را می‌توان در بخش‌های Configuration Backend in DHCPv4 \%<#\:dhcp4-cb> و Configuration Backend in DHCPv6 \%<#\:dhcp6-cb> مشاهده کرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_cb_cmds.so\fP تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس است. برای کسب اطلاعات بیشتر دربارهٔ گزینه‌های اشتراک، لطفاً فرم موجود در \%\& را تکمیل کنید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرایندهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 لطفاً پیش از به‌کارگیری دستورهای شرح داده شده در این بخش، بخش محدودیت‌ها و هشدارها (Limitations and Warnings) \%<#\:cb-limitations> را مطالعه کنید. .UNINDENT .UNINDENT.SS ساختار دستور (Command Structure) .sp این کتابخانه از ۵ نوع دستور پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBdel\fP \- حذف شیء انتخاب‌شده از پایگاه داده، مانند \fBremote\-global\-parameter4\-del\fP\&. .IP \(bu 2 \fBget\fP \- واکشی شیء انتخاب‌شده از پایگاه داده، مانند \fBremote\-subnet4\-get\-by\-id\fP\&. .IP \(bu 2 \fBget\-all\fP \- واکشی تمام اشیاء یک نوع خاص از پایگاه داده، مانند \fBremote\-option\-def4\-get\-all\fP\&. .IP \(bu 2 \fBlist\fP \- فهرست کردن تمام اشیاء یک نوع خاص در پایگاه داده، مانند \fBremote\-network4\-list\fP؛ این دسته از دستورات در مقایسه با خروجی \fBget\-all\fP اطلاعات خلاصه‌تری درباره هر شیء برمی‌گردانند\&. .IP \(bu 2 \fBset\fP \- ایجاد یا جایگزینی شیئی از نوع داده‌شده در پایگاه داده، مانند \fBremote\-option4\-global\-set\fP\&. .UNINDENT .sp همه انواع دستورات یک نگاشت اختیاری \fBremote\fP را می‌پذیرند که نمونه پایگاه داده مورد اشاره دستور را مشخص می‌کند. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-subnet4\-list\(dq, \(dqarguments\(dq: { \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq, \(dqhost\(dq: \(dq192.0.2.33\(dq, \(dqport\(dq: 3302 } } } .EE .UNINDENT .UNINDENT .sp پایگاه داده MySQL را که روی میزبان 192.0.2.33 و درگاه 3302 در حال اجراست برای واکشی فهرست زیرشبکه‌ها انتخاب می‌کند. تمام پارامترها در آرگومان \fBremote\fP اختیاری هستند. پارامتر \fBport\fP تنها همراه با \fBhost\fP قابل تعیین است\&. اگر قرار نیست هیچ گزینه‌ای در پارامتر \fBremote\fP مشخص شود، این پارامتر باید حذف گردد. در این حالت، سرور از نخستین پشتیبان (backend) فهرست‌شده در نگاشت \fBconfig\-control\fP در پیکربندی سرورِ دریافت‌کننده دستور استفاده خواهد کرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در نگارش کنونی Kea، تنها می‌توان سرور Kea را برای استفاده از یک پشتیبان پیکربندی واحد تنظیم کرد. به بیان دقیق‌تر، با استفاده از پارامتر \fBconfig\-control\fP تنها می‌توان سرور Kea را حداکثر به یک پایگاه داده (یا MySQL یا PostgreSQL) متصل کرد. بنابراین، پارامتر \fBremote\fP می‌تواند در دستورات نادیده گرفته شود و \fBlibdhcp_cb_cmds.so\fP به‌طور پیش‌فرض از همان تنها پشتیبان موجود استفاده می‌کند. دستورات نمونه زیر اغلب مقدار \(dqmysql\(dq را برای پارامتر \fBtype\fP نشان می‌دهند؛ در صورتی که از پایگاه داده PostgreSQL استفاده می‌کنید باید فرض شود که این مقدار \(dqpostgresql\(dq است. .UNINDENT .UNINDENT .SS دستورات کنترلی برای سرورهای DHCP (Control Commands for DHCP Servers) .sp این بخش به شرح و ارائه مثال‌هایی از دستورات کنترلی پیاده‌سازی‌شده توسط \fBlibdhcp_cb_cmds.so\fP برای مدیریت اطلاعات پیکربندی سرورهای DHCPv4 و DHCPv6 می‌پردازد. بسیاری از این دستورات بین DHCPv4 و DHCPv6 تقریباً یکسان هستند و تنها در نام دستور با یکدیگر تفاوت دارند. سایر دستورات تفاوت جزئی در ساختار داده‌های درج‌شده دارند؛ برای مثال، ساختار اطلاعات زیرشبکه IPv4 با زیرشبکه IPv6 متفاوت است. با این حال، ساختار آرگومان‌های دستورات آن‌ها یکسان است و از این رو توضیح دادن آن‌ها در کنار یکدیگر منطقی است. .sp علاوه بر این، در بخش‌های بعدی هر جا در متن به یک دستور DHCP یا پارامتر DHCP اشاره شود، به هر دو گونه DHCPv4 و DHCPv6 اشاره دارد. متن‌های مختص یک نوع سرور خاص، آن‌ها را با عنوان‌های: دستور DHCPv4، پارامتر DHCPv4، دستور DHCPv6، پارامتر DHCPv6 و غیره مشخص می‌کنند. .SS متاداده (Metadata) .sp پاسخ معمول به دستور \fBget\fP یا \fBlist\fP شامل فهرستی از اشیاء بازگردانده‌شده (مانند زیرشبکه‌ها) است و هر شیء حاوی نگاشت \fBmetadata\fP با اطلاعاتی مختص پایگاه داده برای توصیف آن شیء می‌باشد. به عبارت دیگر، متاداده حاوی هرگونه اطلاعاتی درباره شیء واکشی‌شده است که ممکن است برای مدیر سیستم مفید باشد اما از دیدگاه سرور DHCP جزئی از مشخصات فنی شیء به شمار نمی‌رود. در نگارش کنونی Kea، متاداده به \fBserver\-tag\fP محدود شده است\&. این مقدار، ارتباط شیء با یک سرور خاص یا همه سرورها را مشخص می‌کند. .sp در زیر یک نمونه پاسخ برای دستور \fBremote\-network4\-list\fP آمده است که شامل متاداده می‌باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 IPv4 shared network(s) found.\(dq, \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqlevel3\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } ], \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp پیاده‌سازی‌های کلاینت نباید فرض کنند که متاداده تنها شامل پارامتر \fBserver\-tags\fP است. در نگارش‌های آینده انتظار می‌رود این نگاشت با اطلاعات بیشتری گسترش یابد، از جمله زمان تغییر شیء، پیام ثبت‌شده در لاگ هنگام آخرین ویرایش و موارد مشابه..SS برچسب‌های کلاس گزینه به‌عنوان کلید (Option Class\-tags as Keys) .sp قابلیت برچسب‌گذاری کلاس گزینه (Option Class\-Tagging) \%<#\:option-class-tagging> فهرستی از کلاس‌های کلاینت، \fBclient\-classes\fP، را به مشخصات گزینه‌ها اضافه کرد. بنابراین در هر فهرستی از مشخصات گزینه‌ها (مانند \fIoption\-data\fP)، ممکن است بیش از یک مشخصه برای همان \fBcode\fP و \fBspace\fP وجود داشته باشد، اما با فهرست‌های \fBclient\-classes\fP متفاوت و محتوای داده‌ای گوناگون. .sp برای پشتیبانی از این ساختار، Kea افزون بر code و space، از فهرست \fBclient\-classes\fP گزینه نیز جهت شناسایی یکتای هر گزینه استفاده می‌کند. هنگام استفاده از Management API برای تغییر پیکربندی، به‌خاطر داشتن این موضوع مهم است. از نسخهٔ Kea 3.1.1، دستورهایی که یک گزینهٔ منفرد را دریافت، تنظیم یا حذف می‌کنند، علاوه بر پارامترهای \fBcode\fP و \fBspace\fP، یک پارامتر اختیاری \fBclient\-classes\fP را نیز می‌پذیرند. .sp اگر پارامتر \fBclient\-classes\fP قید نشود: .INDENT 0.0 .IP 1. 3 Get \- یکی از n موردی را که با code و space مطابقت دارد واکشی می‌کند. در صورتی که بیش از یک تطابق وجود داشته باشد، این‌که کدام گزینه بازگردانده می‌شود نامشخص است. .IP 2. 3 Set \- تنها گزینه‌ای را به‌روزرسانی می‌کند که با code و space مطابقت داشته و فهرست client\-classes آن خالی باشد. اگر تطابقی یافت نشود، گزینه ایجاد می‌شود. .IP 3. 3 Delete \- تمام گزینه‌هایی را که با code و space تطابق دارند، در صورت وجود، حذف می‌کند. .UNINDENT .sp اگر پارامتر \fBclient\-classes\fP مشخص شود: .INDENT 0.0 .IP 1. 3 Get \- در صورت وجود، گزینه‌ای را که با code، space و client\-classes تطابق دارد واکشی می‌کند. .IP 2. 3 Set \- فقط گزینه‌ای را به‌روزرسانی می‌کند که با code، space و client\-classes مطابقت داشته باشد. اگر تطابقی یافت نشود، گزینه ایجاد می‌شود. .IP 3. 3 Delete \- در صورت وجود، فقط گزینه‌ای را حذف می‌کند که با code، space و client\-classes تطابق دارد. .UNINDENT .sp یک فهرست خالی \fBclient\-classes\fP به‌صورت \(aq[ ]\(aq با یا بدون فاصله میان براکت‌ها مشخص می‌شود. هنگام مدیریت فهرست گزینه‌هایی که از برچسب‌گذاری کلاس کلاینت استفاده نمی‌کنند، می‌توان پارامتر \fBclient\-classes\fP را به‌سادگی نادیده گرفت. .SS دستورهای \fBremote\-server4\-del\fP و \fBremote\-server6\-del\fP (The \fBremote\-server4\-del\fP, \fBremote\-server6\-del\fP Commands) .sp این دستور برای حذف اطلاعات یک سرور DHCP انتخاب‌شده از پایگاه‌دادهٔ پیکربندی استفاده می‌شود. سرور با یک برچسب سرور (server tag) یکتا و غیرحساس به بزرگ و کوچکی حروف شناسایی می‌شود. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-server4\-del\(dq, \(dqarguments\(dq: { \(dqservers\(dq: [ { \(dqserver\-tag\(dq: \(dqserver1\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqpostgresql\(dq } } } .EE .UNINDENT .UNINDENT .sp در نتیجهٔ این دستور، تمام وابستگی‌های پیکربندی مربوط به سرور تعریف‌شده توسط کاربر با نام \(dqserver1\(dq از پایگاه‌داده حذف می‌شوند، از جمله اطلاعات پیکربندی غیرقابل‌اشتراک، مانند پارامترهای سراسری، تعاریف گزینه‌ها و گزینه‌های سراسری. هرگونه اطلاعات پیکربندی قابل‌اشتراک، یعنی عناصر پیکربندی که ممکن است با بیش از یک سرور مرتبط باشند، حفظ می‌شوند. به‌ویژه، زیرشبکه‌ها و شبکه‌های مشترک مرتبط با سرورهای حذف‌شده حفظ می‌گردند. اگر هر یک از عناصر پیکربندی قابل‌اشتراک تنها با سرور حذف‌شده در ارتباط بوده باشد، آن شیء بدون انتساب (یتیم یا orphaned) می‌شود. برای مثال: اگر یک زیرشبکه با استفاده از دستور \fBremote\-subnet4\-set\fP ایجاد شده و به \(dqserver1\(dq اختصاص یافته باشد و متعاقباً \(dqserver1\(dq حذف شود، زیرشبکه در پایگاه‌داده باقی می‌ماند اما هیچ سروری نمی‌تواند از این زیرشبکه استفاده کند. این زیرشبکه می‌تواند با دستور \fBremote\-subnet4\-set\fP به‌روزرسانی شود و با استفاده از برچسب سرور ویژهٔ \(dqall\(dq، به سرور دیگری یا به همهٔ سرورها اختصاص یابد. چنین زیرشبکه‌ای را می‌توان در صورت عدم نیاز، با استفاده از دستور \fBremote\-subnet4\-del\-by\-id\fP یا \fBremote\-subnet4\-del\-by\-prefix\fP نیز از پایگاه‌داده حذف کرد. .sp پاسخ موفقیت‌آمیز به دستور \fBremote\-server4\-del\fP به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 DHCPv4 server(s) deleted.\(dq, \(dqarguments\(dq: { \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 دستورهای \fBremote\-server4\-del\fP و \fBremote\-server6\-del\fP باید با احتیاط استفاده شوند، زیرا حذف تصادفی سرور می‌تواند باعث شود بخش‌هایی از پیکربندی‌های موجود برای همیشه از پایگاه‌داده از بین بروند. این عملیات برگشت‌پذیر نیست. ایجاد دوبارهٔ سروری که به‌طور تصادفی حذف شده، پیکربندی ازدست‌رفتهٔ آن سرور را بازنمی‌گرداند و این پیکربندی باید به‌صورت دستی توسط کاربر دوباره ایجاد شود. .UNINDENT .UNINDENT .SS دستورهای \fBremote\-server4\-get\fP و \fBremote\-server6\-get\fP (The \fBremote\-server4\-get\fP, \fBremote\-server6\-get\fP Commands) .sp این دستور برای واکشی اطلاعات یک سرور DHCP انتخاب‌شده از پایگاه‌دادهٔ پیکربندی استفاده می‌شود. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-server6\-get\(dq, \(dqarguments\(dq: { \(dqservers\(dq: [ { \(dqserver\-tag\(dq: \(dqserver1\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp این دستور اطلاعات سرور DHCPv6 را که با برچسب سرور \(dqserver1\(dq مشخص شده است واکشی می‌کند. برچسب سرور به حروف بزرگ و کوچک حساس نیست. یک پاسخ موفقیت‌آمیز، اطلاعات پایه‌ای دربارهٔ سرور مانند برچسب سرور و توضیحات کاربر دربارهٔ سرور را بازمی‌گرداند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqDHCP server server1 found.\(dq, \(dqarguments\(dq: { \(dqservers\(dq: [ { \(dqserver\-tag\(dq: \(dqserver1\(dq, \(dqdescription\(dq: \(dqA DHCPv6 server located on the first floor.\(dq } ], \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT.SS دستورهای \fBremote\-server4\-get\-all\fP و \fBremote\-server6\-get\-all\fP .sp این دستور برای واکشی تمام کارگزارهای DHCPv4 یا DHCPv6 تعریف‌شده توسط کاربر از پایگاه‌داده به کار می‌رود. ساختار دستور بسیار ساده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-server4\-get\-all\(dq, \(dqarguments\(dq: { \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پاسخ شامل اطلاعات پایه‌ای درباره هر کارگزار، مانند برچسب کارگزار و توضیحات آن است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqDHCPv4 servers found.\(dq, \(dqarguments\(dq: { \(dqservers\(dq: [ { \(dqserver\-tag\(dq: \(dqserver1\(dq, \(dqdescription\(dq: \(dqA DHCP server located on the first floor.\(dq }, { \(dqserver\-tag\(dq: \(dqserver2\(dq, \(dqdescription\(dq: \(dqAn old DHCP server to be soon replaced.\(dq } ], \(dqcount\(dq: 2 } } .EE .UNINDENT .UNINDENT .SS دستورهای \fBremote\-server4\-set\fP و \fBremote\-server6\-set\fP .sp این دستور برای ایجاد یا جایگزینی اطلاعات مربوط به یک کارگزار DHCP در پایگاه‌داده به کار می‌رود. اطلاعات کارگزار زمانی باید ایجاد شود که نیاز به تفکیک پیکربندی‌های استفاده‌شده توسط نمونه‌های گوناگون Kea متصل به یک پایگاه‌داده وجود داشته باشد. عناصر مختلف پیکربندی، مانند پارامترهای سراسری، زیرشبکه‌ها و غیره را می‌توان به‌طور صریح به کارگزارهای انتخاب‌شده پیوند داد (با استفاده از برچسب‌های کارگزار به‌عنوان شناسه)، که بدین ترتیب تنها این کارگزارها اجازه خواهند داشت از عناصر پیکربندی مربوطه استفاده کنند. استفاده از یک برچسب کارگزار مشخص برای برقراری چنین پیوندهایی تنها زمانی امکان‌پذیر است که اطلاعات کارگزار از طریق دستورهای \fBremote\-server4\-set\fP یا \fBremote\-server6\-set\fP در پایگاه‌داده ذخیره شده باشد. دستور زیر یک کارگزار DHCPv6 جدید را در پایگاه‌داده ایجاد می‌کند (یا اطلاعات موجود را به‌روزرسانی می‌کند): .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-server6\-set\(dq, \(dqarguments\(dq: { \(dqservers\(dq: [ { \(dqserver\-tag\(dq: \(dqserver1\(dq, \(dqdescription\(dq: \(dqA DHCP server on the ground floor.\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp برچسب کارگزار باید در میان تمام کارگزارهای موجود در پایگاه‌داده یکتا باشد. هنگامی که اطلاعات کارگزار تحت برچسب داده‌شده از قبل موجود باشد، با اطلاعات جدید جایگزین می‌شود. برچسب کارگزار مشخص‌شده به حروف بزرگ و کوچک حساس نیست، و حداکثر طول آن ۲۵۶ نویسه است. کلیدواژه‌های زیر رزرو شده‌اند و نمی‌توان از آن‌ها به عنوان برچسب کارگزار استفاده کرد: \(dqall\(dq و \(dqany\(dq. .sp در ادامه نمونه‌ای از پاسخ دستور بالا آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqDHCPv6 server successfully set.\(dq, \(dqarguments\(dq: { \(dqservers\(dq: [ { \(dqserver\-tag\(dq: \(dqserver1\(dq, \(dqdescription\(dq: \(dqA DHCP server on the ground floor.\(dq } ] } } .EE .UNINDENT .UNINDENT .SS دستورهای \fBremote\-global\-parameter4\-del\fP و \fBremote\-global\-parameter6\-del\fP .sp این دستورها برای حذف یک پارامتر سراسری DHCP از پایگاه‌دادهٔ پیکربندی به کار می‌روند. هنگامی که پارامتر از پایگاه‌داده حذف می‌شود، کارگزار از مقدار مشخص‌شده در فایل پیکربندی برای این پارامتر استفاده می‌کند، یا اگر پارامتر در فایل پیکربندی مشخص نشده باشد، مقدار پیش‌فرض را به کار می‌برد. .sp دستور زیر تلاش می‌کند پارامتر DHCPv4 به نام \fBrenew\-timer\fP را که میان همهٔ کارگزارها مشترک است از پایگاه‌داده حذف کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-global\-parameter4\-del\(dq, \(dqarguments\(dq: { \(dqparameters\(dq: [ \(dqrenew\-timer\(dq ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } .EE .UNINDENT .UNINDENT .sp اگر قرار است پارامتری مختص به یک کارگزار خاص حذف شود، فهرست \fBserver\-tags\fP باید شامل برچسب کارگزار مربوطه باشد. باید دقیقاً یک برچسب کارگزار در این فهرست مشخص شده باشد..SS دستورهای \fBremote\-global\-parameter4\-get\fP و \fBremote\-global\-parameter6\-get\fP .sp این دستورها برای دریافت یک پارامتر سراسری اسکالر (scalar) DHCP از پایگاه‌داده پیکربندی به کار می‌روند. .sp دستور زیر تلاش می‌کند پارامتر \fBboot\-file\-name\fP را برای \(dqserver1\(dq واکشی کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-global\-parameter4\-get\(dq, \(dqarguments\(dq: { \(dqparameters\(dq: [ \(dqboot\-file\-name\(dq ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .sp مقدار بازگردانده‌شده دارای یکی از چهار نوع داده اسکالر است: رشته (string)، عدد صحیح (integer)، عدد حقیقی (real)، یا بولی (boolean). پارامترهای پیکربندی سراسری غیر اسکالر، مانند map یا list، توسط این دستور بازگردانده نمی‌شوند. .sp در مورد مثال بالا، مقدار رشته‌ای بازگردانده می‌شود، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 DHCPv4 global parameter found.\(dq, \(dqarguments\(dq: { \(dqparameters\(dq: { \(dqboot\-file\-name\(dq: \(dq/dev/null\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqall\(dq ] } }, \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که پاسخ بالا نشان می‌دهد پارامتر بازگردانده‌شده به‌جای \(dqserver1\(dq استفاده‌شده در دستور، با سرورهای \(dqall\(dq مرتبط است. این نشان می‌دهد که هیچ مقدار خاصی برای \(dqserver1\(dq در پایگاه‌داده وجود ندارد و از این رو، مقدار مشترک بین همه سرورها بازگردانده شده است. اگر مقداری مختص \(dqserver1\(dq در پایگاه‌داده وجود داشت، آن مقدار به‌جای این بازگردانده می‌شد. .sp پاسخ نمونه برای مقدار عدد صحیح عبارت است از: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 DHCPv4 global parameter found.\(dq, \(dqarguments\(dq: { \(dqparameters\(dq: { \(dqrenew\-timer\(dq: 2000, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } }, \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp مقدار عدد حقیقی: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 DHCPv4 global parameter found.\(dq, \(dqarguments\(dq: { \(dqparameters\(dq: { \(dqt1\-percent\(dq: 0.85, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqall\(dq ] } }, \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp در نهایت، مقدار بولی: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 DHCPv4 global parameter found.\(dq, \(dqarguments\(dq: { \(dqparameters\(dq: { \(dqmatch\-client\-id\(dq: true, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqserver2\(dq ] } }, \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT.SS دستورهای \fBremote\-global\-parameter4\-get\-all\fP و \fBremote\-global\-parameter6\-get\-all\fP .sp این دستورها برای واکشی تمام پارامترهای سراسری DHCP از پایگاه داده برای سرور مشخص‌شده به کار می‌روند. مثال زیر نحوهٔ واکشی تمام پارامترهای سراسری مورد استفاده توسط سرور \(dqserver1\(dq را نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-global\-parameter4\-get\-all\(dq, \(dqarguments\(dq: { \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .sp پاسخ نمونه ممکن است به صورت زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqDHCPv4 global parameters found.\(dq, \(dqarguments\(dq: { \(dqparameters\(dq: [ { \(dqboot\-file\-name\(dq: \(dq/dev/null\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } }, { \(dqmatch\-client\-id\(dq: true, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } ], \(dqcount\(dq: 2 } } .EE .UNINDENT .UNINDENT .sp پاسخ نمونه شامل دو پارامتر است: یک پارامتر رشته‌ای و یک پارامتر بولی (boolean). فرادادهٔ (metadata) بازگردانده‌شده برای هر پارامتر نشان می‌دهد که آیا این پارامتر مختص \(dqserver1\(dq است یا برای همهٔ سرورها اعمال می‌شود. از آنجا که مقدار \fBmatch\-client\-id\fP با سرورهای \(dqall\(dq مرتبط است، نشان می‌دهد که تنظیم خاصی مختص \(dqserver1\(dq برای این پارامتر وجود ندارد. هر پارامتر همیشه دقیقاً یک برچسب سرور مرتبط با خود دارد، چرا که پارامترهای سراسری عناصر پیکربندی غیرقابل‌اشتراک هستند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگر برچسب سرور در دستور روی \(dqall\(dq تنظیم شده باشد، پاسخ تنها شامل پارامترهای سراسری مرتبط با سرور منطقی \(dqall\(dq خواهد بود. هنگامی که برچسب سرور به سرور خاصی اشاره کند (مانند مثال بالا)، فهرست بازگردانده‌شده پارامترهای مرتبط با این سرور و همهٔ سرورها را ترکیب می‌کند، اما اولویت با پارامترهای سرور خاص است. .UNINDENT .UNINDENT .SS دستورهای \fBremote\-global\-parameter4\-set\fP و \fBremote\-global\-parameter6\-set\fP .sp این دستور برای ایجاد پارامترهای سراسری اسکالر DHCP در پایگاه داده به کار می‌رود. اگر هر یک از پارامترها از قبل وجود داشته باشد، مقدار آن در نتیجهٔ این دستور جایگزین می‌شود. امکان تنظیم چندین پارامتر در قالب یک دستور واحد وجود دارد که هر کدام می‌توانند یکی از چهار نوع رشته (string)، عدد صحیح (integer)، عدد حقیقی (real) یا بولی (boolean) را داشته باشند. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-global\-parameter4\-set\(dq, \(dqarguments\(dq: { \(dqparameters\(dq: { \(dqboot\-file\-name\(dq: \(dq/dev/null\(dq, \(dqrenew\-timer\(dq: 2000, \(dqt1\-percent\(dq: 0.85, \(dqmatch\-client\-id\(dq: true }, \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .sp اگر هر یک از پارامترها توسط سرور DHCP پشتیبانی نشود یا نوع آن مطابقت نداشته باشد، خطایی بازگردانده می‌شود. هنگام تعیین چندین پارامتر در یک دستور واحد باید دقت شود، زیرا ممکن است فقط برخی از پارامترها با موفقیت ذخیره شوند و برخی دیگر با خطا مواجه شوند. در صورت بروز خطا هنگام پردازش این دستور، توصیه می‌شود از \fBremote\-global\-parameter4\-get\-all\fP یا \fBremote\-global\-parameter6\-get\-all\fP برای بررسی اینکه کدام پارامترها با موفقیت ذخیره/به‌روزرسانی شده‌اند و کدام با شکست مواجه شده‌اند، استفاده کنید. .sp فهرست \fBserver\-tags\fP اجباری است و باید شامل یک برچسب سرور واحد یا کلیدواژهٔ \(dqall\(dq باشد. در مثال بالا، تمام پارامترهای مشخص‌شده با سرور \(dqserver1\(dq مرتبط هستند. .SS دستورهای \fBremote\-network4\-del\fP و \fBremote\-network6\-del\fP .sp این دستورها برای حذف یک شبکهٔ اشتراکی (shared network) از نوع IPv4 یا IPv6 از پایگاه داده به کار می‌روند. پارامتر اختیاری \fBsubnets\-action\fP تعیین می‌کند که آیا زیرشبکه‌های متعلق به شبکهٔ اشتراکی حذف‌شده نیز باید حذف شوند یا حفظ گردند. پارامتر \fBsubnets\-action\fP به‌طور پیش‌فرض روی \fBkeep\fP تنظیم است که زیرشبکه‌ها را حفظ می‌کند. اگر روی \fBdelete\fP تنظیم شود، زیرشبکه‌ها همراه با شبکهٔ اشتراکی حذف می‌شوند. .sp دستور زیر: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-network6\-del\(dq, \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqlevel3\(dq } ], \(dqsubnets\-action\(dq: \(dqkeep\(dq, \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp شبکهٔ اشتراکی IPv6 با نام \(dqlevel3\(dq را حذف می‌کند. زیرشبکه‌ها حفظ می‌شوند، اما وابستگی آن‌ها از شبکهٔ اشتراکی حذف‌شده قطع شده و سراسری می‌شوند. این رفتار مطابق با رفتار دستورهای \fBnetwork4\-del\fP و \fBnetwork6\-del\fP با توجه به پارامتر \fBsubnets\-action\fP است. .sp توجه داشته باشید که پارامتر \fBserver\-tags\fP را نمی‌توان برای این دستور استفاده کرد..SS دستورهای \fBremote\-network4\-get\fP و \fBremote\-network6\-get\fP .sp این دستورها برای بازیابی اطلاعات مربوط به یک شبکه مشترک (shared network) از نوع IPv4 یا IPv6 به کار می‌روند. پارامتر اختیاری \fBsubnets\-include\fP مشخص می‌کند که آیا زیرشبکه‌های متعلق به شبکه مشترک نیز باید بازگردانده شوند یا خیر. مقدار پیش‌فرض این پارامتر \fBno\fP است که در این حالت زیرشبکه‌ها بازگردانده نمی‌شوند. اگر این پارامتر روی \fBfull\fP تنظیم شود، زیرشبکه‌ها همراه با شبکه مشترک بازگردانده می‌شوند. .sp دستور زیر شبکه مشترک IPv6 با نام \(dqlevel3\(dq را به همراه اطلاعات کامل زیرشبکه‌های متعلق به آن واکشی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-network6\-get\(dq, \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqlevel3\(dq } ], \(dqsubnets\-include\(dq: \(dqfull\(dq, \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که پارامتر \fBserver\-tags\fP را نمی‌توان برای این دستور استفاده کرد. .SS دستورهای \fBremote\-network4\-list\fP و \fBremote\-network6\-list\fP .sp این دستورها برای فهرست کردن تمام شبکه‌های مشترک IPv4 یا IPv6 برای یک سرور به کار می‌روند. .sp دستور زیر تمام شبکه‌های مشترکی را که قرار است توسط \(dqserver1\(dq و \(dqserver2\(dq استفاده شوند بازیابی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-network4\-list\(dq, \(dqarguments\(dq: { \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq, \(dqserver2\(dq ] } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP اجباری است و شامل یک یا چند برچسب سرور می‌باشد. این پارامتر می‌تواند حاوی کلیدواژه \(dqall\(dq باشد تا شبکه‌های مشترک مرتبط با همه سرورها را واکشی کند. هنگامی که فهرست \fBserver\-tags\fP حاوی مقدار \fBnull\fP باشد، پاسخ بازگردانده شده شامل فهرستی از شبکه‌های مشترک تخصیص‌نیافته خواهد بود؛ یعنی شبکه‌هایی که با هیچ سروری مرتبط نیستند. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-network4\-list\(dq, \(dqarguments\(dq: { \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ null ] } } .EE .UNINDENT .UNINDENT .sp پاسخ نمونه به این دستور در حالتی که برچسب‌های سرور غیر null مشخص شده باشند، مشابه این خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq3 IPv4 shared network(s) found.\(dq, \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqground floor\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqall\(dq ] } }, { \(dqname\(dq: \(dqfloor2\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } }, { \(dqname\(dq: \(dqfloor3\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqserver2\(dq ] } } ], \(dqcount\(dq: 3 } } .EE .UNINDENT .UNINDENT .sp اطلاعات بازگردانده شده درباره هر شبکه مشترک صرفاً شامل نام شبکه مشترک و متادیتا است. برای واکشی اطلاعات دقیق‌تر درباره شبکه مشترک انتخاب‌شده، از دستور \fBremote\-network4\-get\fP یا \fBremote\-network6\-get\fP استفاده کنید. .sp پاسخ نمونه بالا شامل سه شبکه مشترک است. یکی از شبکه‌های مشترک با تمام سرورها مرتبط است، بنابراین در فهرست شبکه‌های مشترکی که باید توسط \(dqserver1\(dq و \(dqserver2\(dq استفاده شوند گنجانده شده است. دو شبکه مشترک باقی‌مانده بازگردانده شده‌اند زیرا یکی از آن‌ها با \(dqserver1\(dq و دیگری با \(dqserver2\(dq مرتبط است. .sp هنگام فهرست کردن شبکه‌های مشترک تخصیص‌نیافته، پاسخ مشابه این خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 IPv4 shared network(s) found.\(dq, \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqfancy\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ null ] } } ], \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp مقدار \fBnull\fP در متادیتا نشان می‌دهد که شبکه مشترک بازگردانده‌شده تخصیص نیافته است..SS دستورهای \fBremote\-network4\-set\fP و \fBremote\-network6\-set\fP .sp این دستورها یک شبکهٔ اشتراکی IPv4 یا IPv6 جدید در پایگاه‌داده ایجاد کرده یا جایگزین نمونهٔ موجود می‌کنند. ساختار اطلاعات شبکهٔ اشتراکی همانند فایل پیکربندی Kea است (برای جزئیات به Shared Networks in DHCPv4 \%<#\:shared-network4> و Shared Networks in DHCPv6 \%<#\:shared-network6> مراجعه کنید)، با این تفاوت که مشخص کردن زیرشبکه‌ها همراه با اطلاعات شبکهٔ اشتراکی مجاز نیست. گنجاندن پارامتر \fBsubnet4\fP یا \fBsubnet6\fP درون اطلاعات شبکهٔ اشتراکی منجر به بروز خطا می‌شود. .sp این دستورها به منظور مدیریت اطلاعات مختص شبکهٔ اشتراکی و گزینه‌های DHCP طراحی شده‌اند. برای مرتبط‌سازی و لغو ارتباط زیرشبکه‌ها با شبکه‌های اشتراکی، باید از دستورهای \fBremote\-subnet4\-set\fP و \fBremote\-subnet6\-set\fP استفاده شود. .sp دستور زیر، شبکهٔ اشتراکی IPv6 با نام \(dqlevel3\(dq را به پایگاه‌داده اضافه می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-network6\-set\(dq, \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqlevel3\(dq, \(dqinterface\(dq: \(dqeth0\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqsntp\-servers\(dq, \(dqdata\(dq: \(dq2001:db8:1::1\(dq } ] } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } .EE .UNINDENT .UNINDENT .sp این دستور شامل پارامتر \fBinterface\fP است که نام رابط را در سطح شبکهٔ اشتراکی تعیین می‌کند. سایر پارامترهای سطح شبکهٔ اشتراکی که با این دستور مشخص نشده باشند، در پایگاه‌داده به عنوان \(dqunspecified\(dq علامت‌گذاری خواهند شد. کارگزار DHCP برای پارامترهای مشخص‌نشده از مقادیر سراسری استفاده می‌کند یا در صورتی که مقادیر سراسری تعیین نشده باشند، مقادیر پیش‌فرض به کار گرفته می‌شوند. .sp فهرست \fBserver\-tags\fP برای این دستور اجباری است و باید شامل یک یا چند برچسب کارگزار باشد. در نتیجه، شبکهٔ اشتراکی با تمامی کارگزارهای فهرست‌شده مرتبط می‌شود. هنگامی که کلیدواژهٔ \(dqall\(dq در آن قرار گیرد، شبکهٔ اشتراکی با تمامی کارگزارهایی که به پایگاه‌داده متصل می‌شوند مرتبط خواهد شد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مشابه سایر دستورهای \(dqset\(dq، در صورتی که شبکهٔ اشتراکی از قبل وجود داشته باشد، این دستور تمام اطلاعات مربوط به آن شبکهٔ اشتراکی مشخص‌شده را در پایگاه‌داده جایگزین می‌کند. بنابراین، هنگام ارسال این دستور، اطمینان حاصل کنید که همیشه تمام پارامترهایی را که باید برای نمونهٔ به‌روزشدهٔ شبکهٔ اشتراکی مشخص باشند، بگنجانید. هر پارامتر نامشخص، حتی اگر مقدار آن قبل از ارسال دستور در پایگاه‌داده موجود بوده باشد، به عنوان نامشخص (unspecified) علامت‌گذاری خواهد شد. .UNINDENT .UNINDENT .SS دستورهای \fBremote\-option\-def4\-del\fP و \fBremote\-option\-def6\-del\fP .sp این دستورها برای حذف تعریف یک گزینهٔ DHCP از پایگاه‌داده استفاده می‌شوند. تعریف گزینه توسط یک کد گزینه و فضای گزینه مشخص می‌شود. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option\-def6\-del\(dq, \(dqarguments\(dq: { \(dqoption\-defs\(dq: [ { \(dqcode\(dq: 1, \(dqspace\(dq: \(dqisc\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .sp تعریف گزینهٔ مرتبط با \(dqserver1\(dq را که دارای کد 1 و متعلق به فضای گزینهٔ \(dqisc\(dq است حذف می‌کند. فضاهای گزینهٔ پیش‌فرض برای گزینه‌های سطح بالای DHCPv4 و DHCPv6 به ترتیب \(dqdhcp4\(dq و \(dqdhcp6\(dq هستند. اگر چنین تعریف گزینه‌ای به‌طور صریح با \(dqserver1\(dq مرتبط نباشد، هیچ تعریفی حذف نمی‌شود. برای حذف تعریف گزینه‌ای که متعلق به کارگزارهای \(dqall\(dq است، باید از کلیدواژهٔ \(dqall\(dq به عنوان برچسب کارگزار استفاده شود. فهرست \fBserver\-tags\fP باید دقیقاً شامل یک برچسب باشد و نمی‌تواند مقدار \fBnull\fP داشته باشد. .sp از نگارش Kea 3.1.2 به بعد، کارگزار قبل از حذف تعریف گزینه، ابتدا بررسی می‌کند که آیا گزینه‌ای وجود دارد که به آن تعریف وابسته باشد یا خیر. در این صورت، دستور حذف به همراه پیام خطایی که دلیل آن را شرح می‌دهد رد خواهد شد. این رفتار پیش‌فرض را می‌توان با تنظیم پارامتر اختیاری \fBforce\fP روی مقدار true مطابق شکل زیر نادیده گرفت: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option\-def6\-del\(dq, \(dqarguments\(dq: { \(dqoption\-defs\(dq: [ { \(dqcode\(dq: 1, \(dqspace\(dq: \(dqisc\(dq, \(dqforce\(dq: true } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پارامتر \fBforce\fP تنها پس از بررسی دقیق باید استفاده شود. حذف یک تعریف گزینه در حالی که مشخصات گزینه‌ای وابسته وجود دارد، باعث کنار گذاشته شدن آن گزینه از پیکربندی در حال اجرا خواهد شد. این پارامتر برای مواردی در نظر گرفته شده که ممکن است نیاز به اصلاح تعریف باشد در حالی که خود گزینه در جای خود باقی بماند. .UNINDENT .UNINDENT.SS دستورهای \fBremote\-option\-def4\-get\fP و \fBremote\-option\-def6\-get\fP .sp این دستورها برای واکشی تعریف یک گزینه (option definition) مشخص DHCP از پایگاه‌داده به کار می‌روند. تعریف گزینه از طریق کد گزینه و فضای گزینه (option space) مشخص می‌شود. فضاهای پیش‌فرض گزینه برای گزینه‌های سطح بالای DHCPv4 و DHCPv6 به ترتیب \(dqdhcp4\(dq و \(dqdhcp6\(dq هستند. .sp دستور زیر یک تعریف گزینه DHCPv4 مرتبط با تمام سرورها را با کد ۱ و متعلق به فضای گزینه \(dqisc\(dq بازیابی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option\-def4\-get\(dq, \(dqarguments\(dq: { \(dqoption\-defs\(dq: [ { \(dqcode\(dq: 1, \(dqspace\(dq: \(dqisc\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } .EE .UNINDENT .UNINDENT .sp فهرست \fBserver\-tags\fP باید دقیقاً شامل یک برچسب سرور یا کلیدواژه \(dqall\(dq باشد و نمی‌تواند شامل مقدار \fInull\fP باشد. .SS دستورهای \fBremote\-option\-def4\-get\-all\fP و \fBremote\-option\-def6\-get\-all\fP .sp این دستورها برای واکشی تمام تعاریف گزینه‌های DHCP از پایگاه‌داده برای سرور مشخص‌شده یا تمام سرورها استفاده می‌شوند. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option\-def6\-get\-all\(dq, \(dqarguments\(dq: { \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } .EE .UNINDENT .UNINDENT .sp این دستور تلاش می‌کند تمام تعاریف گزینه‌های DHCPv6 مرتبط با سرورهای \(dqall\(dq را واکشی کند. فهرست \fBserver\-tags\fP برای این دستور اجباری است و باید دقیقاً شامل یک برچسب سرور یا کلیدواژه \(dqall\(dq باشد. این مقدار نمی‌تواند \fBnull\fP باشد. .sp نمونه پاسخ به این دستور به شرح زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 DHCPv6 option definition(s) found.\(dq, \(dqarguments\(dq: { \(dqoption\-defs\(dq: [ { \(dqname\(dq: \(dqbar\(dq, \(dqcode\(dq: 1012, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqtype\(dq: \(dqrecord\(dq, \(dqarray\(dq: true, \(dqrecord\-types\(dq: \(dqipv6\-address, uint16\(dq, \(dqencapsulate\(dq: \(dq\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } ], \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp پاسخ شامل تعریف گزینه‌ای مرتبط با تمام سرورها است، همان‌طور که در متادیتا مشخص شده است. .SS دستورهای \fBremote\-option\-def4\-set\fP و \fBremote\-option\-def6\-set\fP .sp این دستورها یک تعریف گزینه DHCP جدید ایجاد می‌کنند یا تعریف گزینه موجود در پایگاه‌داده را جایگزین می‌نمایند. ساختار اطلاعات تعریف گزینه مشابه فایل پیکربندی Kea است (نگاه کنید به گزینه‌های سفارشی DHCPv4 \%<#\:dhcp4-custom-options> و گزینه‌های سفارشی DHCPv6 \%<#\:dhcp6-custom-options>). دستور زیر تعریف گزینه DHCPv4 را در فضای گزینه سطح بالای \(dqdhcp4\(dq ایجاد کرده و آن را به \(dqserver1\(dq اختصاص می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option\-def4\-set\(dq, \(dqarguments\(dq: { \(dqoption\-defs\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqcode\(dq: 222, \(dqtype\(dq: \(dquint32\(dq, \(dqarray\(dq: false, \(dqrecord\-types\(dq: \(dq\(dq, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqencapsulate\(dq: \(dq\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .sp فهرست \fBserver\-tags\fP باید دقیقاً شامل یک برچسب سرور یا کلیدواژه \(dqall\(dq باشد و نمی‌تواند شامل مقدار \fBnull\fP باشد..SS دستورهای \fBremote\-option4\-global\-del\fP و \fBremote\-option6\-global\-del\fP .sp این دستورها برای حذف یک گزینه سراسری DHCP از پایگاه داده استفاده می‌شوند. گزینه بر اساس کد گزینه و فضای گزینه شناسایی می‌شود. از نسخه Kea 3.1.1 به بعد، یک پارامتر اختیاری \fBclient\-classes\fP نیز می‌تواند مشخص شود (به بخش Option Class\-tags as Keys مراجعه کنید). .sp برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option4\-global\-del\(dq, \(dqarguments\(dq: { \(dqoptions\(dq: [ { \(dqcode\(dq: 5, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqclient\-classes\(dq: [ \(dqclass\-one\(dq ] } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .sp مقدار \(dqdhcp4\(dq نشان‌دهنده فضای گزینه سطح بالایی است که گزینه‌های استاندارد DHCPv4 به آن تعلق دارند. پارامتر \fBserver\-tags\fP اجباری است و باید شامل یک برچسب گزینه تکی یا کلیدواژه \(dqall\(dq باشد. اگر برچسب سرور صریح مشخص شده باشد، این دستور تلاش می‌کند گزینه سراسری مرتبط با این سرور را حذف کند. اگر چنین گزینه‌ای مرتبط با سرور مشخص‌شده وجود نداشته باشد، هیچ گزینه‌ای حذف نمی‌شود. برای حذف گزینه‌ای که با همه سرورها مرتبط است، باید کلیدواژه \(dqall\(dq مشخص شود. .SS دستورهای \fBremote\-option4\-global\-get\fP و \fBremote\-option6\-global\-get\fP .sp این دستورها برای واکشی یک گزینه سراسری DHCP از پایگاه داده استفاده می‌شوند. گزینه بر اساس کد و فضای گزینه شناسایی می‌شود. بالاترین سطح فضاهای گزینه که گزینه‌های استاندارد DHCP به آن‌ها تعلق دارند، به ترتیب برای سرورهای DHCPv4 و DHCPv6 با نام‌های \(dqdhcp4\(dq و \(dqdhcp6\(dq شناخته می‌شوند. از نسخه Kea 3.1.1 به بعد، یک پارامتر اختیاری \fBclient\-classes\fP نیز می‌تواند مشخص شود (به بخش Option Class\-tags as Keys مراجعه کنید). .sp دستور زیر گزینه \(dqDNS Servers\(dq در IPv6 (کد 23) که با همه سرورها مرتبط است را بازیابی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option6\-global\-get\(dq, \(dqarguments\(dq: { \(dqoptions\(dq: [ { \(dqcode\(dq: 23, \(dqspace\(dq: \(dqdhcp6\(dq, \(dqclient\-classes\(dq: [ \(dqclass\-one\(dq ] } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP اجباری است و باید دقیقا شامل یک برچسب سرور یا کلیدواژه \(dqall\(dq باشد. این پارامتر نمی‌تواند حاوی مقدار \fBnull\fP باشد. .SS دستورهای \fBremote\-option4\-global\-get\-all\fP و \fBremote\-option6\-global\-get\-all\fP .sp این دستورها برای واکشی تمام گزینه‌های سراسری DHCP از پایگاه داده پیکربندی برای سرور داده‌شده یا برای همه سرورها استفاده می‌شوند. دستور زیر همه گزینه‌های سراسری DHCPv4 را برای \(dqserver1\(dq واکشی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option6\-global\-get\-all\(dq, \(dqarguments\(dq: { \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .sp فهرست \fBserver\-tags\fP برای این دستور اجباری است و باید دقیقا شامل یک برچسب سرور یا کلیدواژه \(dqall\(dq باشد؛ این فهرست نمی‌تواند شامل مقدار \fBnull\fP باشد. .sp در زیر یک پاسخ نمونه به این دستور آورده شده است که در آن یک گزینه تکی مرتبط با \(dqserver1\(dq بازگردانده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqDHCPv4 options found.\(dq, \(dqarguments\(dq: { \(dqoptions\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqcode\(dq: 6, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqcsv\-format\(dq: false, \(dqdata\(dq: \(dq192.0.2.3\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } ], \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT.SS دستورهای \fBremote\-option4\-global\-set\fP و \fBremote\-option6\-global\-set\fP .sp این دستورها یک گزینهٔ سراسری جدید DHCP ایجاد کرده یا یک گزینهٔ موجود در پایگاه‌داده را جایگزین می‌کنند. ساختار اطلاعات گزینه مشابه ساختار موجود در فایل پیکربندی Kea است (بخش گزینه‌های استاندارد DHCPv4 در \%<#\:dhcp4-std-options> و گزینه‌های استاندارد DHCPv6 در \%<#\:dhcp6-std-options> را ببینید). برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option6\-global\-set\(dq, \(dqarguments\(dq: { \(dqoptions\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8:1::1\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .sp فهرست \fBserver\-tags\fP برای این دستور اجباری است و باید دقیقاً شامل یک برچسب سرور یا کلیدواژهٔ \(dqall\(dq باشد؛ این مقدار نمی‌تواند حاوی مقدار \fBnull\fP باشد. دستور بالا گزینه را به سرور \(dqserver1\(dq مرتبط می‌سازد. .sp توجه داشته باشید که مشخص کردن نام گزینه به جای کد گزینه تنها برای گزینه‌های استاندارد DHCP به‌طور قابل‌اطمینان کار می‌کند. هنگام تعیین مقداری برای یک گزینهٔ سفارشی DHCP، باید به جای نام، کد گزینه مشخص شود. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option6\-global\-set\(dq, \(dqarguments\(dq: { \(dqoptions\(dq: [ { \(dqcode\(dq: 1, \(dqspace\(dq: \(dqisc\(dq, \(dqdata\(dq: \(dq2001:db8:1::1\(dq } ], \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .SS دستورهای \fBremote\-option4\-network\-del\fP و \fBremote\-option6\-network\-del\fP .sp این دستورها برای حذف یک گزینهٔ DHCP مختص شبکهٔ اشتراکی (shared network) از پایگاه‌داده به کار می‌روند. گزینه با یک کد گزینه و فضای گزینه شناسایی می‌شود، و از Kea 3.1.1 به بعد، یک پارامتر اختیاری \fBclient\-classes\fP نیز می‌تواند تعیین گردد (بخش Option Class\-tags as Keys را ببینید). این پارامترها در داخل فهرست \fBoptions\fP ارسال می‌شوند. فهرست دیگر، \fBshared\-networks\fP، شامل یک مَپ با نام شبکهٔ اشتراکی است که گزینه باید از آن حذف شود. اگر گزینه به‌طور صریح برای این شبکهٔ اشتراکی مشخص نشده باشد، هیچ گزینه‌ای حذف نمی‌شود. به‌ویژه، گزینهٔ مورد نظر ممکن است برای یک زیرشبکهٔ متعلق به آن شبکهٔ اشتراکی وجود داشته باشد. چنین موردی تحت تأثیر این دستور قرار نمی‌گیرد زیرا این دستور صرفاً گزینهٔ سطح شبکهٔ اشتراکی را حذف می‌کند. برای حذف یک گزینه در سطح زیرشبکه، باید به جای آن از دستورهای \fBremote\-option4\-subnet\-del\fP و \fBremote\-option6\-subnet\-del\fP استفاده شود. .sp دستور زیر تلاش می‌کند گزینه‌ای با کد گزینهٔ ۵ در بالاترین سطح فضای گزینه (top\-level option space) و یک فهرست خالی client\-classes را از شبکهٔ اشتراکی \(dqfancy\(dq حذف کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option4\-network\-del\(dq, \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqfancy\(dq } ], \(dqoptions\(dq: [ { \(dqcode\(dq: 5, \(dqspace\(dq: \(dqdhcp4\(dq, \(dqclient\-classes\(dq : [ ] } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp مقدار \(dqdhcp4\(dq نشان‌دهندهٔ بالاترین سطح فضای گزینه است که گزینه‌های استاندارد DHCPv4 به آن تعلق دارند. پارامتر \fBserver\-tags\fP نمی‌تواند برای این دستور مشخص شود. .SS دستورهای \fBremote\-option4\-network\-set\fP و \fBremote\-option6\-network\-set\fP .sp این دستورها یک گزینهٔ DHCP جدید مختص شبکهٔ اشتراکی ایجاد کرده یا یک گزینهٔ موجود در پایگاه‌داده را جایگزین می‌کنند. ساختار اطلاعات گزینه مشابه فایل پیکربندی Kea است (بخش گزینه‌های استاندارد DHCPv4 در \%<#\:dhcp4-std-options> و گزینه‌های استاندارد DHCPv6 در \%<#\:dhcp6-std-options> را ببینید). اطلاعات گزینه در فهرست \fBoptions\fP منتقل می‌شود. فهرست دیگری به نام \fBshared\-networks\fP شامل یک مَپ با نام شبکهٔ اشتراکی است که گزینه برای آن تنظیم می‌شود. اگر چنین گزینه‌ای از قبل برای شبکهٔ اشتراکی وجود داشته باشد، با نمونهٔ جدید جایگزین می‌شود. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option6\-network\-set\(dq, \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqfancy\(dq } ], \(dqoptions\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8:1::1\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP نمی‌تواند برای این دستور مشخص شود. .sp مشخص کردن نام گزینه به جای کد گزینه فقط برای گزینه‌های استاندارد DHCP به‌طور قابل‌اطمینان عمل می‌کند. هنگام تعیین یک مقدار برای گزینهٔ سفارشی DHCP، باید به جای نام، از کد گزینه استفاده شود..SS دستور \fBremote\-option6\-pd\-pool\-del\fP .sp این دستور برای حذف یک گزینه DHCPv6 مختص استخر واگذاری پیشوند (prefix delegation pool) از پایگاه‌داده به کار می‌رود. گزینه با یک کد گزینه و فضای گزینه شناسایی می‌شود، و از نسخه Kea 3.1.1 به بعد، پارامتر اختیاری \fBclient\-classes\fP نیز می‌تواند مشخص شود (به Option Class\-tags as Keys مراجعه کنید). این پارامترها درون فهرست \fBoptions\fP ارسال می‌شوند. فهرست دیگری به نام \fBpd\-pools\fP شامل یک نگاشت با پیشوند و طول استخر واگذاری پیشوند است که استخر را مشخص می‌کند. اگر گزینه به‌طور صریح برای این استخر مشخص نشده باشد، هیچ گزینه‌ای حذف نمی‌شود. به‌ویژه، گزینه داده‌شده ممکن است برای زیرشبکه‌ای شامل استخر مشخص‌شده وجود داشته باشد. چنین نمونه‌ای از گزینه تحت تأثیر این دستور قرار نمی‌گیرد، زیرا این دستور صرفاً یک گزینه در سطح استخر واگذاری پیشوند را حذف می‌کند. برای حذف گزینه‌ای در سطح زیرشبکه، باید به جای آن از دستور \fBremote\-option6\-subnet\-del\fP استفاده شود. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option6\-pd\-pool\-del\(dq, \(dqarguments\(dq: { \(dqpd\-pools\(dq: [ { \(dqprefix\(dq: \(dq3000::\(dq, \(dqprefix\-len\(dq: 64 } ], \(dqoptions\(dq: [ { \(dqcode\(dq: 23, \(dqspace\(dq: \(dqdhcp6\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp مقدار \(dqdhcp6\(dq نشان‌دهنده فضای گزینه سطح بالا است که گزینه‌های استاندارد DHCPv6 به آن تعلق دارند. پارامتر \fBserver\-tags\fP را نمی‌توان برای این دستور مشخص کرد. .SS دستور \fBremote\-option6\-pd\-pool\-set\fP .sp این دستور یک گزینه DHCPv6 جدید مختص استخر واگذاری پیشوند ایجاد کرده یا گزینه‌ای موجود در پایگاه‌داده را جایگزین می‌کند. ساختار اطلاعات گزینه مشابه پرونده پیکربندی Kea است (به Standard DHCPv4 Options \%<#\:dhcp4-std-options> و Standard DHCPv6 Options \%<#\:dhcp6-std-options> مراجعه کنید). اطلاعات گزینه در فهرست \fBoptions\fP حمل می‌شود. فهرست دیگری به نام \fBpd\-pools\fP شامل نگاشتی با پیشوند استخر واگذاری پیشوند و طول پیشوند است که استخر را شناسایی می‌کند. اگر چنین گزینه‌ای از قبل برای استخر واگذاری پیشوند وجود داشته باشد، با نمونه جدید جایگزین می‌شود. .sp برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option6\-pd\-pool\-set\(dq, \(dqarguments\(dq: { \(dqpd\-pools\(dq: [ { \(dqprefix\(dq: \(dq3001:1::\(dq, \(dqlength\(dq: 64 } ], \(dqoptions\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8:1::1\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP را نمی‌توان برای این دستور مشخص کرد. .sp مشخص کردن نام گزینه به جای کد گزینه، تنها برای گزینه‌های استاندارد DHCP به‌درستی کار می‌کند. هنگام تعیین مقدار برای یک گزینه DHCP تعریف‌شده توسط کاربر، باید کد گزینه به جای نام آن قید شود. .SS دستورهای \fBremote\-option4\-pool\-del\fP و \fBremote\-option6\-pool\-del\fP .sp این دستورها برای حذف یک گزینه DHCP مختص استخر نشانی از پایگاه‌داده به کار می‌روند. گزینه با یک کد گزینه و فضای گزینه شناسایی می‌شود، و از نسخه Kea 3.1.1 به بعد، پارامتر اختیاری \fBclient\-classes\fP نیز ممکن است مشخص شود (به Option Class\-tags as Keys مراجعه کنید). این پارامترها در فهرست \fBoptions\fP ارسال می‌شوند. فهرست دیگری به نام \fBpools\fP شامل یک نگاشت با محدوده نشانی IP یا پیشوند مشخص‌کننده استخر است. اگر گزینه به‌طور صریح برای این استخر مشخص نشده باشد، هیچ گزینه‌ای حذف نخواهد شد. به‌ویژه، گزینه داده‌شده ممکن است برای زیرشبکه‌ای شامل استخر مشخص‌شده وجود داشته باشد. چنین نمونه‌ای از گزینه تحت تأثیر این دستور قرار نمی‌گیرد، چرا که این دستور صرفاً گزینه‌ای در سطح استخر را حذف می‌کند. برای حذف گزینه‌ای در سطح زیرشبکه، باید به جای آن از دستور \fBremote\-option4\-subnet\-del\fP یا \fBremote\-option6\-subnet\-del\fP استفاده شود. .sp دستور زیر تلاش می‌کند گزینه‌ای با کد گزینه 5 در فضای گزینه سطح بالا را از یک استخر نشانی IPv4 حذف کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option4\-pool\-del\(dq, \(dqarguments\(dq: { \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.100\(dq } ], \(dqoptions\(dq: [ { \(dqcode\(dq: 5, \(dqspace\(dq: \(dqdhcp4\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp مقدار \(dqdhcp4\(dq نشان‌دهنده فضای گزینه سطح بالا است که گزینه‌های استاندارد DHCPv4 به آن تعلق دارند. پارامتر \fBserver\-tags\fP را نمی‌توان برای این دستور مشخص کرد..SS دستورهای \fBremote\-option4\-pool\-set\fP و \fBremote\-option6\-pool\-set\fP .sp این دستورها یک گزینهٔ DHCP جدیدِ مختص استخر آدرس ایجاد کرده یا گزینه‌ای موجود را در پایگاه داده جایگزین می‌کنند. ساختار اطلاعات گزینه همانند پروندهٔ پیکربندی Kea است (بخش گزینه‌های استاندارد DHCPv4 \%<#\:dhcp4-std-options> و گزینه‌های استاندارد DHCPv6 \%<#\:dhcp6-std-options> را ببینید). اطلاعات گزینه در فهرست \fBoptions\fP منتقل می‌شود. فهرست دیگری به نام \fBpools\fP شامل نگاشتی با بازهٔ نشانی IP یا پیشوندی است که استخر را مشخص می‌سازد. اگر چنین گزینه‌ای از قبل برای استخر وجود داشته باشد، با نمونهٔ جدید جایگزین می‌شود. .sp برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option4\-pool\-set\(dq, \(dqarguments\(dq: { \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.100\(dq } ], \(dqoptions\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqdata\(dq: \(dq10.0.0.1\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP را نمی‌توان برای این دستور مشخص کرد. .sp مشخص کردن نام گزینه به جای کد گزینه، فقط برای گزینه‌های استاندارد DHCP به‌طور قابل‌اطمینان کار می‌کند. هنگام تعیین مقدار برای یک گزینهٔ DHCP تعریف‌شده توسط کاربر (user\-defined)، باید کد گزینه به جای نام آن درج شود. .SS دستورهای \fBremote\-option4\-subnet\-del\fP و \fBremote\-option6\-subnet\-del\fP .sp این دستورها برای حذف یک گزینهٔ DHCP مختص زیرشبکه از پایگاه داده به کار می‌روند. گزینه با یک کد گزینه، فضای گزینه (option space) و از نسخهٔ Kea 3.1.1 به بعد، با یک پارامتر اختیاری \fBclient\-classes\fP شناسایی می‌شود (بخش Option Class\-tags as Keys را ببینید). این پارامترها درون فهرست \fBoptions\fP ارسال می‌شوند. فهرست دیگر، \fBsubnets\fP، شامل نگاشتی با شناسهٔ زیرشبکه‌ای است که گزینه باید از آن حذف شود. اگر گزینه به‌طور صریح برای این زیرشبکه مشخص نشده باشد، هیچ گزینه‌ای حذف نمی‌شود. .sp دستور زیر تلاش می‌کند گزینه‌ای با کد گزینهٔ 5 را در فضای گزینهٔ سطح‌بالا (top\-level) از زیرشبکه‌ای با شناسهٔ 123 حذف کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option4\-subnet\-del\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 123 } ], \(dqoptions\(dq: [ { \(dqcode\(dq: 5, \(dqspace\(dq: \(dqdhcp4\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp مقدار \(dqdhcp4\(dq نشان‌دهندهٔ فضای گزینهٔ سطح‌بالاست که گزینه‌های استاندارد DHCPv4 به آن تعلق دارند. پارامتر \fBserver\-tags\fP را نمی‌توان برای این دستور مشخص کرد. .SS دستورهای \fBremote\-option4\-subnet\-set\fP و \fBremote\-option6\-subnet\-set\fP .sp این دستورها یک گزینهٔ DHCP جدیدِ مختص زیرشبکه ایجاد کرده یا گزینه‌ای موجود را در پایگاه داده جایگزین می‌کنند. ساختار اطلاعات گزینه مشابه پروندهٔ پیکربندی Kea است (بخش گزینه‌های استاندارد DHCPv4 \%<#\:dhcp4-std-options> و گزینه‌های استاندارد DHCPv6 \%<#\:dhcp6-std-options> را ببینید). اطلاعات گزینه در فهرست \fBoptions\fP منتقل می‌شود. فهرست دیگری به نام \fBsubnets\fP شامل نگاشتی با شناسهٔ زیرشبکه‌ای است که گزینه باید برای آن تنظیم شود. اگر چنین گزینه‌ای از قبل برای زیرشبکه وجود داشته باشد، با نمونهٔ جدید جایگزین خواهد شد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-option6\-subnet\-set\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 123 } ], \(dqoptions\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq, \(dqdata\(dq: \(dq2001:db8:1::1\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP را نمی‌توان برای این دستور مشخص کرد. .sp مشخص کردن نام گزینه به جای کد گزینه، فقط برای گزینه‌های استاندارد DHCP به‌طور قابل‌اطمینان کار می‌کند. هنگام تعیین مقدار برای گزینهٔ DHCP تعریف‌شده توسط کاربر، باید کد گزینه به جای نام آن مشخص شود..SS دستورهای \fBremote\-subnet4\-del\-by\-id\fP و \fBremote\-subnet6\-del\-by\-id\fP .sp این نخستین گونه از دستورهایی است که برای حذف یک زیرشبکه IPv4 یا IPv6 از پایگاه‌داده به کار می‌روند. این دستور از شناسهٔ زیرشبکه برای شناسایی آن استفاده می‌کند. برای نمونه، جهت حذف زیرشبکهٔ IPv4 با شناسهٔ ۵: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-subnet4\-del\-by\-id\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 5 } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP نمی‌تواند همراه با این دستور استفاده شود. .SS دستورهای \fBremote\-subnet4\-del\-by\-prefix\fP و \fBremote\-subnet6\-del\-by\-prefix\fP .sp این دومین گونه از دستورهایی است که برای حذف یک زیرشبکه IPv4 یا IPv6 از پایگاه‌داده به کار می‌روند. این دستور از پیشوند زیرشبکه برای شناسایی آن استفاده می‌کند. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-subnet6\-del\-by\-prefix\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP نمی‌تواند همراه با این دستور استفاده شود. .SS دستورهای \fBremote\-subnet4\-get\-by\-id\fP و \fBremote\-subnet6\-get\-by\-id\fP .sp این نخستین گونه از دستورهایی است که برای واکشی یک زیرشبکه IPv4 یا IPv6 از پایگاه‌داده به کار می‌روند. این دستور از شناسهٔ زیرشبکه برای شناسایی آن استفاده می‌کند. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-subnet4\-get\-by\-id\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 5 } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP نمی‌تواند همراه با این دستور استفاده شود. .SS دستورهای \fBremote\-subnet4\-get\-by\-prefix\fP و \fBremote\-subnet6\-get\-by\-prefix\fP .sp این دومین گونه از دستورهایی است که برای واکشی یک زیرشبکه IPv4 یا IPv6 از پایگاه‌داده به کار می‌روند. این دستور از پیشوند زیرشبکه برای شناسایی آن استفاده می‌کند. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-subnet6\-get\-by\-prefix\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP نمی‌تواند همراه با این دستور استفاده شود. .SS دستورهای \fBremote\-subnet4\-list\fP و \fBremote\-subnet6\-list\fP .sp این دستورها برای فهرست کردن تمام زیرشبکه‌های IPv4 یا IPv6 از پایگاه‌داده برای سرورهای برگزیده یا همهٔ سرورها به کار می‌روند. دستور زیر تمامی سرورهای مورد استفاده توسط \(dqserver1\(dq و \(dqserver2\(dq را بازیابی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-subnet4\-list\(dq, \(dqarguments\(dq: { \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq, \(dqserver2\(dq ] } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP اجباری است و شامل یک یا چند برچسب سرور است. این پارامتر می‌تواند حاوی کلیدواژهٔ \(dqall\(dq باشد تا زیرشبکه‌های مرتبط با همهٔ سرورها را واکشی کند. هنگامی که فهرست \fBserver\-tags\fP حاوی مقدار \fBnull\fP باشد، پاسخ بازگردانده‌شده شامل فهرستی از زیرشبکه‌های تخصیص‌نیافته خواهد بود، یعنی زیرشبکه‌هایی که با هیچ سروری مرتبط نیستند. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-subnet4\-list\(dq, \(dqarguments\(dq: { \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ null ] } } .EE .UNINDENT .UNINDENT .sp پاسخ نمونه به این دستور هنگامی که برچسب‌های سرور غیر \fBnull\fP مشخص شده باشند، شبیه به این خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 IPv4 subnet(s) found.\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqshared\-network\-name\(dq: null, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqserver1\(dq, \(dqserver2\(dq ] } }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqshared\-network\-name\(dq: null, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } ], \(dqcount\(dq: 2 } } .EE .UNINDENT .UNINDENT .sp اطلاعات بازگردانده‌شده دربارهٔ هر زیرشبکه به شناسهٔ زیرشبکه، پیشوند و نام شبکهٔ مشترک مرتبط محدود می‌شود. برای بازیابی اطلاعات کامل دربارهٔ زیرشبکهٔ برگزیده، از دستور \fBremote\-subnet4\-get\-by\-id\fP / \fBremote\-subnet6\-get\-by\-id\fP یا دستور \fBremote\-subnet4\-get\-by\-prefix\fP / \fBremote\-subnet6\-get\-by\-prefix\fP استفاده کنید. .sp پاسخ نمونهٔ بالا شامل دو زیرشبکه است. یکی از زیرشبکه‌ها با هر دو سرور \(dqserver1\(dq و \(dqserver2\(dq مرتبط است. زیرشبکهٔ دوم با همهٔ سرورها مرتبط است، بنابراین در پیکربندی‌های \(dqserver1\(dq و \(dqserver2\(dq نیز حضور دارد. .sp هنگام فهرست کردن زیرشبکه‌های تخصیص‌نیافته، پاسخ مشابه این خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 IPv4 subnet(s) found.\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 3, \(dqsubnet\(dq: \(dq192.0.4.0/24\(dq, \(dqshared\-network\-name\(dq: null, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ null ] } } ], \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp مقدار \fBnull\fP در متادیتا نشان می‌دهد که زیرشبکهٔ بازگردانده‌شده تخصیص‌نیافته است..SS دستورهای \fBremote\-subnet4\-set\fP و \fBremote\-subnet6\-set\fP .sp این دستورها برای ایجاد یک زیرشبکه جدید IPv4 یا IPv6 و یا جایگزینی یک زیرشبکه موجود در پایگاه داده به کار می‌روند. تنظیم زیرشبکه همچنین آن را به یک شبکه مشترک (shared network) منتسب یا از آن منفصل می‌کند. .sp ساختار اطلاعات زیرشبکه مشابه ساختاری است که در فایل پیکربندی استفاده می‌شود (نگاه کنید به پیکربندی کارساز DHCPv4 \%<#\:dhcp4-configuration> و پیکربندی کارساز DHCPv6 \%<#\:dhcp6-configuration>). اطلاعات زیرشبکه منتقل‌شده در دستور \fBremote\-subnet4\-set\fP یا \fBremote\-subnet6\-set\fP باید شامل پارامتر اضافی \fBshared\-network\-name\fP باشد که مشخص می‌کند آیا زیرشبکه به یک شبکه مشترک تعلق دارد یا خیر. .sp مثال زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-subnet4\-set\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 5, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqshared\-network\-name\(dq: \(dqlevel3\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.100\-192.0.2.200\(dq } ], \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.2.1\(dq } ] } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } .EE .UNINDENT .UNINDENT .sp این دستور زیرشبکه را ایجاد کرده و آن را به شبکه مشترک \(dqlevel3\(dq منتسب می‌کند. شبکه مشترک \(dqlevel3\(dq باید پیش از ایجاد زیرشبکه با دستور \fBremote\-network4\-set\fP ایجاد شده باشد. .sp اگر زیرشبکه ایجادشده باید سراسری (global) باشد \- یعنی به هیچ شبکه مشترکی منتسب نباشد \- پارامتر \fBshared\-network\-name\fP باید صریحاً روی \fBnull\fP تنظیم شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-subnet4\-set\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 5, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqshared\-network\-name\(dq: null, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.100\-192.0.2.200\(dq } ], \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.2.1\(dq } ] } ], \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } .EE .UNINDENT .UNINDENT .sp زیرشبکه ایجادشده در مثال قبلی با زیرشبکه جدیدی با همان پارامترها جایگزین می‌شود، اما به صورت سراسری درمی‌آید. .sp پارامتر \fBshared\-network\-name\fP برای دستور \fBremote\-subnet4\-set\fP اجباری است. فهرست \fBserver\-tags\fP اجباری است و باید شامل یک یا چند برچسب کارساز باشد. در نتیجه، زیرشبکه به تمام کارسازهای فهرست‌شده منتسب می‌شود. همچنین در صورتی که کلیدواژه \(dqall\(dq به عنوان برچسب کارساز استفاده شود، ممکن است به تمام کارسازهای متصل به پایگاه داده منتسب گردد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 همانند سایر دستورهای \(dqset\(dq، این دستور در صورتی که اطلاعات زیرشبکه از قبل موجود باشد، تمام اطلاعات مربوط به آن زیرشبکه خاص را در پایگاه داده جایگزین می‌کند. بنابراین، هنگام ارسال این دستور، اطمینان حاصل کنید که همیشه تمام پارامترهایی را که باید برای نمونه به‌روزشدهٔ زیرشبکه مشخص شوند بگنجانید. هر پارامتر نامشخصی در پایگاه داده به عنوان نامشخص علامت‌گذاری خواهد شد، حتی اگر مقدار آن پیش از ارسال دستور وجود داشته باشد. .UNINDENT .UNINDENT .SS دستورهای \fBremote\-class4\-del\fP و \fBremote\-class6\-del\fP .sp این دستورها یک کلاس کلاینت DHCPv4 یا DHCPv6 را بر اساس نام حذف می‌کنند. اگر هر یک از کلاس‌های کلاینت در پایگاه داده به کلاس حذف‌شده وابسته باشند، در پاسخ به این دستور یک خطا بازگردانده می‌شود. در این حالت، برای حذف موفقیت‌آمیز کلاس، کلاس‌های کلاینت وابسته باید ابتدا حذف شوند. از دستور \fBremote\-class4\-get\-all\fP برای دریافت همه کلاس‌های کلاینت و پیدا کردن موارد وابسته استفاده کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-class4\-del\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqfoo\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP نمی‌تواند برای این دستور استفاده شود، زیرا کلاس‌های کلاینت به صورت یکتا با نام شناسایی می‌شوند..SS دستورهای \fBremote\-class4\-get\fP و \fBremote\-class6\-get\fP .sp این دستورها اطلاعات کلاس کلاینت DHCPv4 یا DHCPv6 را بر اساس نام کلاس کلاینت بازیابی می‌کنند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-class4\-get\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqfoo\(dq } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq } } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP نمی‌تواند برای این دستور استفاده شود، زیرا کلاس‌های کلاینت به صورت یکتا با نام شناسایی می‌شوند. .sp پاسخ این دستور شبیه به این است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqDHCPv4 client class \(aqfoo\(aq found.\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } ], \(dqcount\(dq: 1 } } .EE .UNINDENT .UNINDENT .SS دستورهای \fBremote\-class4\-get\-all\fP و \fBremote\-class6\-get\-all\fP .sp این دستورها تمام کلاس‌های کلاینت DHCPv4 یا DHCPv6 را برای یک سرور خاص، چندین سرور مشخص‌شده به طور صریح، و/یا همهٔ سرورها بازیابی می‌کنند. هر سرور معین، برچسب سرور اختصاصی خود را دارد و همچنین برچسب سرور \(dqall\(dq را داراست؛ این دستورها کلاس‌ها را هم برای یک سرور مستقل و هم برای سرورهای \(dqall\(dq بازیابی می‌کنند. برای مثال، دستور زیر تمام کلاس‌های کلاینت تعریف‌شده برای \(dqserver1\(dq و همچنین کلاس‌های کلاینت تعریف‌شده برای سرورهای \(dqall\(dq را بازیابی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-class4\-get\-all\(dq, \(dqarguments\(dq: { \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqserver1\(dq ] } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBserver\-tags\fP اجباری است و شامل یک یا چند برچسب سرور می‌باشد. اگر برچسب‌های سرور دیگری مشخص شوند، نیازی به قرار دادن \(dqall\(dq در \fBserver\-tags\fP نیست، زیرا هر سرور به طور خودکار برچسب سرور \(dqall\(dq را نیز دارد. اگر \fBserver\-tags\fP تنها شامل کلیدواژهٔ \(dqall\(dq باشد، فقط کلاس‌های کلاینت مرتبط با سرورهای \(dqall\(dq بازگردانده می‌شوند. هنگامی که فهرست \fBserver\-tags\fP شامل مقدار \fBnull\fP باشد، پاسخ بازگردانده‌شده حاوی فهرستی از کلاس‌های کلاینت تخصیص‌نیافته خواهد بود، یعنی شبکه‌هایی که با هیچ سروری مرتبط نیستند. .sp پاسخ این دستور شبیه به این است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 DHCPv4 client class(es) found.\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqall\(dq ] } }, { \(dqname\(dq: \(dqbar\(dq, \(dqtest\(dq: \(dqmember(\(aqfoo\(aq)\(dq, \(dqmetadata\(dq: { \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } ], \(dqcount\(dq: 2 } } .EE .UNINDENT .UNINDENT .SS دستورهای \fBremote\-class4\-set\fP و \fBremote\-class6\-set\fP .sp این دستورها یک کلاس کلاینت جدید DHCPv4 یا DHCPv6 را در پایگاه داده درج کرده یا یک کلاس موجود را جایگزین می‌کنند. ساختار اطلاعات کلاس کلاینت همانند فایل پیکربندی Kea است (برای جزئیات به Client Classification in DHCPv4 \%<#\:dhcp4-client-classifier> و Client Classification in DHCPv6 \%<#\:dhcp6-client-classifier> مراجعه کنید). .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-class4\-set\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqfoo\(dq, \(dqtest\(dq: \(dqmember(\(aqKNOWN\(aq) or member(\(aqbar\(aq)\(dq, \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqconfigfile\(dq, \(dqcode\(dq: 224, \(dqtype\(dq: \(dqstring\(dq } ], \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqconfigfile\(dq, \(dqdata\(dq: \(dq1APC\(dq } ] } ], \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } .EE .UNINDENT .UNINDENT .sp قوانین ترتیب کلاس‌های کلاینت که در Using Expressions in Classification \%<#\:classification-using-expressions> شرح داده شده‌اند، برای کلاس‌های درج‌شده در پایگاه داده نیز اعمال می‌شوند. این قوانین ایجاب می‌کنند کلاسی مانند \fIbar\fP که در عبارت ارزیابی (test) به آن ارجاع داده شده است، هنگام اجرای دستور بالا باید در پایگاه داده موجود باشد. .sp به صورت پیش‌فرض، یک کلاس کلاینت جدید در انتهای سلسله‌مراتب کلاس‌ها در پایگاه داده درج می‌شود و می‌تواند به هر کلاسی که با همان برچسب سرور یا با برچسب ویژهٔ سرور \(dqall\(dq مرتبط است ارجاع دهد. اگر یک کلاس موجود به‌روزرسانی شود، در موقعیت فعلی خود در سلسله‌مراتب کلاس‌ها باقی می‌ماند. .sp با این حال، دستورهای کلاس امکان مشخص کردن موقعیت کلاس کلاینتِ درج‌شده یا به‌روزرسانی‌شده را فراهم می‌سازند. پارامتر اختیاری \fBfollow\-class\-name\fP می‌تواند در دستور گنجانده شود تا نام کلاس موجودی را نشان دهد که کلاس مدیریت‌شده باید بعد از آن قرار گیرد. فرض کنید دو کلاس DHCPv6 در پایگاه داده وجود دارد: \fIfirst\-class\fP و \fIsecond\-class\fP\&. برای افزودن یک کلاس جدید، \fIthird\-class\fP، در بین این دو، از دستوری شبیه به این استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-class6\-set\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqthird\-class\(dq, \(dqtest\(dq: \(dqmember(\(aqfirst\-class\(aq)\(dq } ], \(dqfollow\-class\-name\(dq: \(dqfirst\-class\(dq, \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که \fIthird\-class\fP می‌تواند به \fIfirst\-class\fP وابسته باشد زیرا پس از \fIfirst\-class\fP قرار گرفته است؛ اما \fIthird\-class\fP نمی‌تواند به \fIsecond\-class\fP وابسته باشد زیرا قبل از آن قرار دارد. با این حال، می‌توان \fIsecond\-class\fP را به‌روزرسانی کرد تا به \fIthird\-class\fP وابسته شود. .sp پارامتر \fBfollow\-class\-name\fP می‌تواند به صراحت روی \fBnull\fP تنظیم شود، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqremote\-class6\-set\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqthird\-class\(dq, \(dqtest\(dq: \(dqmember(\(aqfirst\-class\(aq)\(dq } ], \(dqfollow\-class\-name\(dq: null, \(dqremote\(dq: { \(dqtype\(dq: \(dqmysql\(dq }, \(dqserver\-tags\(dq: [ \(dqall\(dq ] } } .EE .UNINDENT .UNINDENT .sp این رفتار مشابه زمانی است که پارامتر \fBfollow\-class\-name\fP اصلاً گنجانده نشود؛ یعنی کلاس جدید به انتهای سلسله‌مراتب کلاس‌ها افزوده می‌شود و کلاس به‌روزرسانی‌شده در موقعیت فعلی خود باقی می‌ماند..SS \fBlibdhcp_class_cmds.so\fP: دستورات کلاس (Class Commands) .sp این کتابخانهٔ قلاب (hook library) چندین دستور کنترلی را برای دستکاری کلاس‌های کلاینت (بخشی از پیکربندی سرورهای Kea DHCP) بدون نیاز به راه‌اندازی مجدد این سرورها فراهم می‌کند. با استفاده از این دستورات، افزودن، به‌روزرسانی، حذف و فهرست‌کردن کلاس‌های کلاینت پیکربندی‌شده برای یک سرور معین امکان‌پذیر است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_class_cmds.so\fP بخشی از کد متن‌باز است و برای همهٔ کاربران Kea در دسترس است. این کتابخانه پیش‌تر فقط برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها توسط فرایند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> قابل بارگذاری است. .UNINDENT .UNINDENT .SS دستور \fBclass\-add\fP .sp دستور \fBclass\-add\fP یک کلاس کلاینت جدید را به پیکربندی سرور DHCP اضافه می‌کند. این کلاس به انتهای فهرست کلاس‌های مورد استفادهٔ سرور پیوست می‌شود و می‌تواند به هر یک از کلاس‌های کلاینتی که قبلاً پیکربندی شده‌اند وابسته باشد. .sp مثال زیر نحوهٔ افزودن یک کلاس کلاینت جدید را به پیکربندی سرور DHCPv4 نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqclass\-add\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqipxe_efi_x64\(dq, \(dqtest\(dq: \(dqoption[93].hex == 0x0009\(dq, \(dqnext\-server\(dq: \(dq192.0.2.254\(dq, \(dqserver\-hostname\(dq: \(dqhal9000\(dq, \(dqboot\-file\-name\(dq: \(dq/dev/null\(dq } ] } } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که پارامتر \fBclient\-classes\fP یک فهرست JSON است، اما تنها اجازه می‌دهد یک کلاس کلاینت در آن قرار گیرد. .sp در اینجا پاسخ به دستور \fBclass\-add\fP در مثال ما آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqClass \(aqipxe_efi_x64\(aq added.\(dq } .EE .UNINDENT .UNINDENT .SS دستور \fBclass\-update\fP .sp دستور \fBclass\-update\fP یک کلاس کلاینت موجود را در پیکربندی سرور DHCP به‌روزرسانی می‌کند. اگر کلاس کلاینت با نام ارائه‌شده وجود نداشته باشد، سرور کد نتیجهٔ 3 را برمی‌گرداند؛ به این معنی که پیکربندی سرور تغییری نکرده و کلاس کلاینت وجود ندارد. در این صورت باید از دستور \fBclass\-add\fP برای ایجاد کلاس کلاینت جدید استفاده شود. .sp دستور \fBclass\-update\fP همان ساختار آرگومان دستور \fBclass\-add\fP را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqclass\-update\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqipxe_efi_x64\(dq, \(dqtest\(dq: \(dqoption[93].hex == 0x0017\(dq, \(dqnext\-server\(dq: \(dq0.0.0.0\(dq, \(dqserver\-hostname\(dq: \(dqxfce\(dq, \(dqboot\-file\-name\(dq: \(dq/dev/null\(dq } ] } } .EE .UNINDENT .UNINDENT .sp در اینجا پاسخ برای مثال ما آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqClass \(aqipxe_efi_x64\(aq updated.\(dq } .EE .UNINDENT .UNINDENT .sp هر پارامتری از کلاس کلاینت را می‌توان با این دستور تغییر داد، به جز \fBname\fP\&. در حال حاضر روشی برای تغییر نام کلاس وجود ندارد، زیرا نام کلاس به‌عنوان کلید جستجوی کلاسی که باید به‌روزرسانی شود استفاده می‌شود. برای دستیابی به اثری مشابه تغییر نام کلاس، می‌توان یک کلاس موجود را با دستور \fBclass\-del\fP حذف کرد و سپس با استفاده از \fBclass\-add\fP مجدداً آن را با نام متفاوتی اضافه نمود. با این حال توجه داشته باشید که کلاس با نام جدید به انتهای فهرست کلاس‌های پیکربندی‌شده اضافه خواهد شد. .sp همانند دیگر دستورات به‌روزرسانی، این دستور تمام محتویات یک مدخل را رونویسی (overwrite) می‌کند. اگر کلاس کلاینت قبلاً منبعی به آن اختصاص یافته بود و در دستور \fBclass\-update\fP آن منبع ذکر نشده باشد، از پیکربندی سرور حذف می‌شود. اگر به‌روزرسانی افزایشی کلاس مد نظر باشد، می‌توان با اجرای یک \fBclass\-get\fP برای دریافت وضعیت فعلی کلاس کلاینت، انتخاب کلاس کلاینت از پاسخ، اصلاح آن به نتیجهٔ دلخواه و سپس صدور دستور \fBclient\-update\fP همراه با کلاس کلاینت حاصل به این هدف دست یافت..SS دستور \fBclass\-del\fP .sp دستور \fBclass\-del\fP برای حذف یک کلاس خاص از پیکربندی کارگزار استفاده می‌شود. کلاسی که باید حذف شود بر اساس نام شناسایی می‌شود. اگر کلاس‌های دیگری به آن وابسته باشند، کلاس حذف نمی‌شود؛ برای حذف چنین کلاسی، باید ابتدا کلاس‌های وابسته حذف شوند. .sp نمونه دستور زیر برای حذف کلاس \fBipxe_efi_x64\fP آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqclass\-del\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqipxe_efi_x64\(dq } } .EE .UNINDENT .UNINDENT .sp در اینجا پاسخ به دستور \fBclass\-del\fP در مثال ما، هنگامی که کلاس کلاینت مشخص‌شده پیدا شده است، مشاهده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqClass \(aqipxe_efi_x64\(aq deleted.\(dq } .EE .UNINDENT .UNINDENT .sp اگر کلاس وجود نداشته باشد، نتیجه‌ی ۳ بازگردانده می‌شود. .SS دستور \fBclass\-list\fP .sp دستور \fBclass\-list\fP برای دریافت فهرستی از تمام کلاس‌های کلاینت به کار می‌رود. این دستور هیچ آرگومانی ندارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqclass\-list\(dq } .EE .UNINDENT .UNINDENT .sp در اینجا پاسخ کارگزار در این مثال، شامل فهرست کلاس‌های کلاینت، آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 classes found\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqipxe_efi_x64\(dq }, { \(dqname\(dq: \(dqpxeclient\(dq } ] } } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که فهرست بازگردانده‌شده شامل تعاریف کامل کلاس نیست، بلکه صرفاً نام کلاس‌ها را دربردارد. برای دریافت اطلاعات کامل کلاس، باید از دستور \fBclass\-get\fP استفاده شود. .SS دستور \fBclass\-get\fP .sp دستور \fBclass\-get\fP برای بازیابی اطلاعات دقیق درباره یک کلاس مشخص استفاده می‌شود. ساختار این دستور بسیار ساده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqclass\-get\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqpxeclient\(dq } } .EE .UNINDENT .UNINDENT .sp اگر کلاسی با نام مشخص‌شده وجود نداشته باشد، کد وضعیت ۳ بازگردانده می‌شود. اگر کلاس کلاینت مشخص‌شده وجود داشته باشد، جزئیات کلاس در قالب زیر بازگردانده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqClass \(aqpxeclient\(aq definition returned\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqpxeclient\(dq, \(dqonly\-in\-additional\-list\(dq: true, \(dqtest\(dq: \(dqoption[vendor\-class\-identifier].text == \(aqPXEClient\(aq\(dq, \(dqoption\-def\(dq: [ { \(dqname\(dq: \(dqconfigfile\(dq, \(dqcode\(dq: 209, \(dqtype\(dq: \(dqstring\(dq } ], \(dqoption\-data\(dq: [ ], \(dqnext\-server\(dq: \(dq0.0.0.0\(dq, \(dqserver\-hostname\(dq: \(dqxfce\(dq, \(dqboot\-file\-name\(dq: \(dq/dev/null\(dq } ] } } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که مثال بالا مختص DHCPv4 است؛ سه پارامتر پایانی تنها توسط کارگزار DHCPv4 بازگردانده می‌شوند و هرگز توسط کارگزار DHCPv6 بازگردانده نخواهند شد. همچنین، ممکن است برخی از پارامترهای ارائه‌شده در این مثال در صورتی که برای کلاس تعیین نشده باشند، بازگردانده نشوند. به‌طور مشخص، در صورتی که \fBonly\-in\-additional\-list\fP، \fBtest\fP و \fBoption\-def\fP برای کلاس مشخص نشده باشند، بازگردانده نمی‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نگارش 2.7.4 نرم‌افزار Kea، پارامتر \fBonly\-if\-required\fP با \fBonly\-in\-additional\-list\fP جایگزین شده و منسوخ گردیده است. برای اینکه به کاربران فرصت مهاجرت داده شود، دستورهای کلاس همچنان آن را به عنوان ورودی می‌پذیرند اما در خروجی به \fBonly\-in\-additional\-list\fP تبدیل می‌کنند. در نهایت، پشتیبانی از این نام قدیمی حذف خواهد شد. .UNINDENT .UNINDENT.SS \fBlibdhcp_ddns_tuning.so\fP: تنظیم دقیق DDNS .sp این کتابخانه قلاب (hook library) پشتیبانی از تنظیم دقیق جنبه‌های گوناگون به‌روزرسانی‌های DNS را اضافه می‌کند. این کتابخانه در حال حاضر از تولید رویه‌ای نام میزبان و امکان چشم‌پوشی از انجام به‌روزرسانی‌های DDNS برای کلاینت‌های مشخص پشتیبانی می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کتابخانه \fBlibdhcp_ddns_tuning.so\fP بخشی از کد متن‌باز است و برای تمام کاربران Kea در دسترس می‌باشد. این کتابخانه پیش‌تر تنها در اختیار مشتریان ISC با قرارداد پشتیبانی تجاری قرار داشت. .UNINDENT .UNINDENT .sp این کتابخانه، که در Kea 2.1.5 افزوده شد، می‌تواند توسط دیمن‌های \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> با اضافه کردن آن به عنصر \fBhooks\-libraries\fP در پیکربندی سرور بارگذاری شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_ddns_tuning.so\(dq, \(dqparameters\(dq: { ... } }, ... ], ... } .EE .UNINDENT .UNINDENT .SS تولید رویه‌ای نام میزبان (Procedural Host\-Name Generation) .sp این کتابخانه قلاب امکان تولید رویه‌ای نام‌های میزبان را بر اساس یک عبارت فراهم می‌سازد. این عبارت را می‌توان به‌صورت سراسری در پارامترهای قلاب با استفاده از \fIhostname\-expr\fP تعریف کرد. در صورت تعریف سراسری، این عبارت برای تمامی میزبان‌ها در تمامی زیرشبکه‌ها اعمال می‌شود. عبارت‌ها می‌توانند از تمام نشانه‌های (tokens) تعریف‌شده در Client Classification \%<#\:classify> استفاده کنند. نمونه‌ای از یک عبارت سراسری در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_ddns_tuning.so\(dq, \(dqparameters\(dq: { \(dqhostname\-expr\(dq: \(dq\(aqhost\-\(aq+hexstring(pkt4.mac,\(aq\-\(aq)\(dq, ... } }, ... ], ... } .EE .UNINDENT .UNINDENT .sp رفتار پیش‌فرض \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> این است که در صورت ارسال هر دو گزینه توسط یک کلاینت، گزینه FQDN (کد 81) را بر گزینه نام میزبان (کد 12) ترجیح دهد. مثال زیر \fBhostname\-expr\fP مورد نیاز برای معکوس کردن این قاعده را نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_ddns_tuning.so\(dq, \(dqparameters\(dq: { \(dqhostname\-expr\(dq : \(dqifelse(option[12].exists, option[host\-name].text, option[81].text)\(dq } } ] } .EE .UNINDENT .UNINDENT .sp همچنین می‌توان این پارامتر را در یک زیرشبکه با استفاده از سازوکار user\-context تعریف کرد. در صورت تعریف در سطح زیرشبکه، عبارت تنها برای آن زیرشبکه خاص اعمال خواهد شد. اگر عبارت زیرشبکه به‌صورت تهی، \fB\(dq\(dq\fP، تعریف شود، استفاده از عبارت سراسری را برای آن زیرشبکه لغو (یا غیرفعال) می‌کند. نمونه‌ای از یک عبارت در سطح زیرشبکه در زیر آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [{ \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq } ], \(dquser\-context\(dq: { \(dqddns\-tuning\(dq: { \(dqhostname\-expr\(dq: \(dq\(aqguest\-\(aq+int8totext(substring(pkt4.yiaddr, 0,1))+\(aq\-\(aq \e +int8totext(substring(pkt4.yiaddr, 1,2))+\(aq\-\(aq \e +int8totext(substring(pkt4.yiaddr, 2,3))+\(aq\-\(aq \e +int8totext(substring(pkt4.yiaddr, 3,4))\(dq } } }], ... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مقدار عبارت بالا از یک بک‌اسلش، \fB\e\fP، برای نمایش ادامه خط استفاده کرده است. این کار صرفاً برای خوانایی بهتر است و یک ساختار معتبر JSON که توسط تجزیه‌گر Kea پشتیبانی شود نیست. مقدار واقعی باید در یک خط ممتد نوشته شود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگام تولید نام میزبان باید به مسائل مربوط به حریم خصوصی توجه کرد. نام میزبان معمولاً در سامانه عمومی DNS درج می‌شود. افشای شناسه‌هایی که می‌توان از آن‌ها برای ردیابی دستگاه‌ها استفاده کرد، مانند آدرس MAC، معمولاً ایده بسیار نامناسبی است. در مثال عبارت سراسری فوق، صرفاً جهت سادگی از آدرس MAC استفاده شده است. .UNINDENT .UNINDENT.SS تولید نام میزبان در DHCPv4 .sp با نصب این کتابخانه، رفتار \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> هنگام ساخت نام‌های میزبان در پاسخ به پرس‌وجوی کلاینت (مانند DISCOVER یا REQUEST) به شرح زیر است: .INDENT 0.0 .INDENT 3.5 1. اگر نام میزبان از طریق یک رزرو میزبان (host reservation) ارائه شده باشد، از آن به همراه پارامترهای رفتاری DDNS برای ساخت نام میزبان نهایی استفاده کنید. به مرحله 4 بروید. .sp 2. اگر کلاینت گزینهٔ FQDN (گزینهٔ 81) را ارائه داده باشد، از مقدار نام دامنهٔ مشخص‌شده در آن، به همراه پارامترهای رفتاری DDNS، برای ساخت نام میزبان نهایی استفاده کنید. به مرحله 4 بروید. .sp 3. اگر کلاینت گزینهٔ host\-name (گزینهٔ 12) را ارائه داده باشد، از نام میزبان مشخص‌شده در آن، به همراه پارامترهای رفتاری DDNS، برای ساخت نام میزبان نهایی استفاده کنید. .sp 4. اگر یک عبارت host\-name مربوط به \fBddns\-tuning\fP در حوزهٔ کاری معتبر (چه سراسری یا زیرشبکه) وجود داشته باشد، نام میزبان را با استفاده از آن عبارت محاسبه کنید. اگر مقدار محاسبه‌شده یک نام کاملاً واجد شرایط (FQDN) نباشد و یک \fBddns\-qualifying\-suffix\fP در حوزهٔ کاری معتبر وجود داشته باشد، پسوند را به آن الحاق کنید. .sp 5. اگر مقدار محاسبه‌شده توسط hook یک رشتهٔ خالی نباشد و با نام میزبان ساخته‌شده در مراحل 1 یا 2 تفاوت داشته باشد، مقدار محاسبه‌شده تبدیل به نام میزبان نهایی می‌شود. .UNINDENT .UNINDENT .SS تولید نام میزبان در DHCPv6 .sp با نصب این کتابخانه، رفتار \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> هنگام ساخت نام‌های میزبان در پاسخ به پرس‌وجوی کلاینت (مانند SOLICIT، REQUEST، RENEW یا REBIND) به شرح زیر است: .INDENT 0.0 .INDENT 3.5 1. اگر کلاینت گزینهٔ FQDN (گزینهٔ 39) را ارائه داده باشد، از مقدار نام دامنهٔ مشخص‌شده در آن، به همراه پارامترهای رفتاری DDNS، برای ساخت نام میزبان نهایی استفاده کنید. به مرحله 4 بروید. .sp 2. اگر کلاینت FQDN ارائه نداده باشد اما \fBddns\-replace\-client\-name\fP برابر با \fBalways\fP یا \fBwhen\-not\-present\fP باشد، شکل نهایی نام میزبان را محاسبه کرده و از آن برای ایجاد یک FQDN خروجی استفاده کنید. به مرحله 4 بروید. .sp 3. اگر در این نقطه هیچ FQDN خروجی‌ای وجود نداشته باشد، پردازش client\-name برای این بسته متوقف می‌شود. بدون یک FQDN خروجی، هیچ راهی برای انتقال نام میزبان به کلاینت وجود ندارد. .sp 4. اگر نام میزبان از طریق یک host reservation ارائه شده باشد، از آن به همراه پارامترهای رفتاری DDNS برای ساخت نام میزبان نهایی استفاده کنید؛ این مقدار جایگزین مقدار FQDN محاسبه‌شده در مراحل 1 یا 2 می‌شود. .sp 5. اگر یک عبارت host name مربوط به \fBddns\-tuning\fP در حوزهٔ کاری معتبر (چه سراسری یا زیرشبکه) وجود داشته باشد، نام میزبان را با استفاده از آن عبارت محاسبه کنید. اگر مقدار محاسبه‌شده یک نام کاملاً واجد شرایط (FQDN) نباشد و یک \fBddns\-qualifying\-suffix\fP در حوزهٔ کاری معتبر وجود داشته باشد، پسوند را به آن الحاق کنید. .sp 6. اگر مقدار محاسبه‌شده توسط hook یک رشتهٔ خالی نباشد و با نام میزبان ساخته‌شده در مراحل 1 یا 2 تفاوت داشته باشد، مقدار محاسبه‌شده تبدیل به نام میزبان نهایی می‌شود. .UNINDENT .UNINDENT .SS نادیده گرفتن به‌روزرسانی‌های DDNS .sp \fBlibdhcp_ddns_tuning.so\fP همچنین امکان نادیده‌گرفتن به‌روزرسانی‌های DDNS را به‌ازای هر کلاینت فراهم می‌کند. این کتابخانه یک کلاس کلاینت ویژه به نام \(dqSKIP_DDNS\(dq را شناسایی می‌کند؛ هنگامی که یک کلاینت با این کلاس مطابقت داده شود، سرورهای Kea (\fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>) درخواست‌های به‌روزرسانی DDNS (یا NCRها) را به \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>\& ارسال نمی‌کنند. یک مورد کاربرد رایج، نادیده‌گرفتن به‌روزرسانی‌های DDNS برای رزروهای میزبان با آدرس ثابت است. این کار به سادگی و تنها با انتساب این کلاس به host reservation، همان‌طور که در زیر نشان داده شده است، انجام می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqreservations\(dq: [ { \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqip\-address\(dq: \(dq192.0.2.1\(dq, \(dqclient\-classes\(dq: [ \(dqSKIP_DDNS\(dq, \(dqfoo\(dq, \(dqbar\(dq ] }] } .EE .UNINDENT .UNINDENT .sp کتابخانهٔ هوک \fBlibdhcp_ddns_tuning.so\fP با هر بار درخواست، تمدید یا آزادسازی اجاره (lease) توسط کلاینت، وجود کلاس \fB\(dqSKIP_DDNS\(dq\fP را در فهرست کلاس‌های کلاینت بررسی کرده و به \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> دستور می‌دهد از ارسال به‌روزرسانی‌های DDNS صرف‌نظر کند. روند کاری مشابهی برای \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> نیز پشتیبانی می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqreservations\(dq: [ { \(dqduid\(dq: \(dq01:02:03:04:05:06\(dq, \(dqip\-address\(dq: \(dq2001:db8::1\(dq, \(dqclient\-classes\(dq: [ \(dqSKIP_DDNS\(dq, \(dqfoo\(dq, \(dqbar\(dq ] }] } .EE .UNINDENT .UNINDENT .sp اگرچه \(dqSKIP_DDNS\(dq یک کلاس ویژه است، اما می‌توان آن را با یک عبارت آزمایشی (test expression) تعریف کرد. تعریف آن به صورت زیر، به‌روزرسانی‌های DDNS را برای تمام کلاینت‌های KNOWN نادیده می‌گیرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqclient\-classes\(dq:[ { \(dqname\(dq: \(dqSKIP_DDNS\(dq, \(dqtest\(dq: \(dqmember(\(aqKNOWN\(aq)\(dq }] } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برای اینکه کلاس \fB\(dqSKIP_DDNS\(dq\fP اثرگذار باشد، کتابخانهٔ هوک \fBlibdhcp_ddns_tuning.so\fP باید بارگذاری شده باشد. .UNINDENT .UNINDENT.SS \fBlibdhcp_flex_id.so\fP: شناسه انعطاف‌پذیر برای رزروهای میزبان .sp نرم‌افزار Kea روشی برای مدیریت رزروهای میزبان فراهم می‌کند که شامل نشانی‌ها، پیشوندها، گزینه‌ها، کلاس‌های کلاینت و سایر قابلیت‌ها می‌شود. رزرو در DHCPv4 می‌تواند بر اساس نشانی سخت‌افزاری، DUID، circuit\-id، یا client\-id باشد، و در DHCPv6 بر اساس نشانی سخت‌افزاری یا DUID. با این حال، گاهی سناریوهایی وجود دارند که در آن‌ها رزرو پیچیده‌تر است؛ ممکن است از گزینه‌هایی غیر از موارد یادشده در بالا استفاده شود، بخش‌هایی از گزینه‌هایی خاص به کار رود، یا شاید حتی ترکیبی از چندین گزینه و فیلد برای شناسایی منحصربه‌فرد یک کلاینت استفاده شود. این سناریوها توسط برنامه قلاب (hook application) شناسه انعطاف‌پذیر (Flexible Identifiers) پوشش داده می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_flex_id.so\fP بخشی از کد منبع‌باز است و در دسترس تمام کاربران Kea قرار دارد. این کتابخانه پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرآیند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp \fBlibdhcp_flex_id.so\fP امکان تعریف یک عبارت (expression) را با استفاده از شیوه‌نگارشی که در ابتدا تنها برای دسته‌بندی کلاینت به کار می‌رفت فراهم می‌کند. (برای شرح مفصل ساختار نحوی موجود، Using Expressions in Classification \%<#\:classification-using-expressions> را ببینید.) یک تفاوت چشمگیر این است که برای دسته‌بندی کلاینت، عبارت در حال حاضر باید به \fBtrue\fP یا \fBfalse\fP ارزیابی شود، در حالی که انتظار می‌رود عبارت شناسه انعطاف‌پذیر به رشته‌ای ارزیابی گردد که به عنوان یک شناسه استفاده خواهد شد. این که عبارت به یک رشته خالی ارزیابی شود حالتی معتبر است (برای نمونه در مواردی که کلاینت گزینه‌های خاصی را ارسال نمی‌کند). سپس این عبارت برای هر بسته دریافتی ارزیابی شده و این ارزیابی شناسه‌ای تولید می‌کند که برای شناسایی کلاینت استفاده می‌شود. به‌ویژه، ممکن است رزروهای میزبانی وجود داشته باشند که به مقادیر خاصی از شناسه انعطاف‌پذیر گره خورده باشند. .sp این کتابخانه می‌تواند مشابه سایر کتابخانه‌های hook بارگذاری شود. این کتابخانه از پارامترهای زیر پشتیبانی می‌کند: \fBidentifier\-expression\fP، \fBreplace\-client\-id\fP و \fBignore\-iaid\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_flex_id.so\(dq, \(dqparameters\(dq: { \(dqidentifier\-expression\(dq: \(dqexpression\(dq, \(dqreplace\-client\-id\(dq: false, \(dqignore\-iaid\(dq: false } }, ... ] } .EE .UNINDENT .UNINDENT .sp کتابخانه شناسه انعطاف‌پذیر از هر دو پروتکل DHCPv4 و DHCPv6 پشتیبانی می‌کند. .sp بیایید موردی از یک شبکه IPv6 را در نظر بگیریم که برای هر یک از مشتریان متصل خود دارای یک رابط مستقل است. مشتریان می‌توانند هر دستگاهی را که می‌خواهند متصل کنند، بنابراین هر نوع شناسه‌ای (مانند یک client\-id) غیرقابل اتکا است. از این رو، مدیر شبکه ممکن است تصمیم بگیرد از گزینه‌ای که توسط یک relay agent درج شده برای تمایز بین کلاینت‌ها استفاده کند. در این استقرار خاص، مدیر شبکه تأیید کرده است که interface\-id برای هر رابطِ سمت مشتری منحصربه‌فرد است، بنابراین برای استفاده به عنوان رزرو مناسب است. با این حال، تنها شش بایت نخست interface\-id مد نظر است، زیرا بایت‌های باقی‌مانده یا به صورت تصادفی تغییر می‌کنند یا بین دستگاه‌ها یکتا نیستند. بنابراین، کاربر تصمیم می‌گیرد از شش بایت نخست گزینه interface\-id درج‌شده توسط relay agent استفاده کند. پس از افزودن \fBflex\-id\fP، هدف \fBhost\-reservation\-identifiers\fP می‌تواند با استفاده از پیکربندی زیر حاصل شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [{ # subnet definition starts here \(dqreservations\(dq: [{ \(dqflex\-id\(dq: \(dq\(aqport1234\(aq\(dq, # value of the first 8 bytes of the interface\-id \(dqip\-addresses\(dq: [ \(dq2001:db8::1\(dq ] }, ... ], ... }, ... ], # end of subnet definitions \(dqhost\-reservation\-identifiers\(dq: [\(dqduid\(dq, \(dqflex\-id\(dq], # add \(dqflex\-id\(dq to reservation identifiers \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_flex_id.so\(dq, \(dqparameters\(dq: { \(dqidentifier\-expression\(dq: \(dqsubstring(relay6[0].option[18].hex,0,8)\(dq } }, ... ], ... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگام تنظیم عبارت باید دقت شود. اگر عبارت تغییر کند، ممکن است تمام مقادیر \fBflex\-id\fP تغییر کنند و احتمالاً تمام رزروهای مبتنی بر \fBflex\-id\fP تا زمانی که به صورت دستی به‌روزرسانی شوند غیرقابل استفاده گردند. اکیداً به مدیران سیستم توصیه می‌شود که کار را با عبارت و تعداد اندکی از رزروها شروع کرده و سپس در صورت نیاز عبارت را تنظیم کنند. به محض اینکه نتیجه مطلوب با عبارت حاصل شد، رزروهای میزبان می‌توانند در مقیاس وسیع‌تری مستقر شوند. .UNINDENT .UNINDENT .sp مقادیر \fBflex\-id\fP در رزروهای میزبان را می‌توان به دو شیوه مشخص کرد. نخست، می‌توانند به عنوان یک رشته هگز (hex string) بیان شوند؛ برای نمونه رشته \(dqbar\(dq می‌تواند به صورت 626174 نمایش داده شود. در غیر این صورت، می‌تواند به عنوان یک مقدار درون نقل‌قول (با استفاده از نقل‌قول‌های دوتایی و تکی) بیان شود، مانند \(dq\(aqbar\(aq\(dq. حالت نخست برای نویسه‌های قابل چاپ مناسب‌تر است، در حالی که مقادیر رشته هگز برای نویسه‌های غیرقابل چاپ راحت‌تر بوده و نیازی به استفاده از عملگر \fBhexstring\fP ندارند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [{ # subnet definition starts here \(dqreservations\(dq: [{ \(dqflex\-id\(dq: \(dq01:02:03:04:05:06\(dq, # value of the first 8 bytes of the interface\-id \(dqip\-addresses\(dq: [ \(dq2001:db8::1\(dq ] }, ... ], ... }, ... ], # end of subnet definitions \(dqhost\-reservation\-identifiers\(dq: [\(dqduid\(dq, \(dqflex\-id\(dq], # add \(dqflex\-id\(dq to reservation identifiers \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_flex_id.so\(dq, \(dqparameters\(dq: { \(dqidentifier\-expression\(dq: \(dqvendor[4491].option[1026].hex\(dq } }, ... ], ... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 یک سناریوی کمتر رایج که مثال‌های بالا ممکن است در آن سودمند واقع شوند، برای کلاینت‌های DHCPv6 است که DUID خود را بین تبادل‌ها تغییر می‌دهند. شناخته شده است که کلاینت‌های PXE خاصی بدین شیوه رفتار می‌کنند. .UNINDENT .UNINDENT.SS پرچم \fBreplace\-client\-id\fP .sp هنگامی که \fBreplace\-client\-id\fP روی \fBfalse\fP تنظیم شده باشد (که تنظیم پیش‌فرض است)، \fBlibdhcp_flex_id.so\fP از شناسهٔ منعطف ارزیابی‌شده صرفاً برای شناسایی رزروهای میزبان، یعنی جستجو برای رزروها در یک پایگاه داده، استفاده می‌کند. این معادل عملکردی سایر شناسه‌ها، مشابه با آدرس سخت‌افزاری یا circuit\-id است. با این حال، این حالت عملکردی به این معنی است که اگر یک دستگاه کلاینت تعویض شود، ممکن است باعث ایجاد تداخل میان یک اجارهٔ موجود (تخصیص‌یافته به دستگاه قدیمی) و اجارهٔ جدید در حال تخصیص به دستگاه جدید شود. این تداخل به این دلیل رخ می‌دهد که شناسهٔ منعطف یکسانی برای دستگاه جایگزین‌شده محاسبه می‌شود، بنابراین کارساز تلاش خواهد کرد همان اجاره را تخصیص دهد. عدم تطابق میان شناسه‌های کلاینت ارسال‌شده توسط دستگاه جدید و دستگاه قدیمی باعث می‌شود که کارساز از این تخصیص جدید تا زمان منقضی شدن اجارهٔ قبلی امتناع ورزد. بروز این مشکل به عبارت خاصی که به عنوان شناسهٔ منعطف استفاده می‌شود وابسته است و در صورتی که فقط از گزینه‌ها و سایر پارامترهایی استفاده شود که محل اتصال دستگاه را مشخص می‌کنند (مانند circuit\-id)، به جای شناسایی خود دستگاه (مانند آدرس MAC)، احتمال رخ دادن آن بیشتر است. .sp کتابخانهٔ \fBlibdhcp_flex_id.so\fP روشی برای غلبه بر مشکل تداخل‌های اجاره از طریق جایگزینی پویای شناسهٔ کلاینت (یا DUID در DHCPv6) با مقداری مشتق‌شده از شناسهٔ منعطف ارائه می‌دهد. کارساز پرس‌وجوی کلاینت را به گونه‌ای پردازش می‌کند که گویی شناسهٔ منعطف در گزینهٔ شناسهٔ کلاینت (یا DUID) ارسال شده است. این امر تضمین می‌کند که به کلاینت بازگشتی (که همان شناسهٔ منعطف برای آن ارزیابی می‌شود)، علیرغم تغییر شناسهٔ کلاینت و/یا آدرس MAC، همان اجاره اختصاص داده شود. .sp در ادامه یک پیکربندی نمونه که این رفتار را فعال می‌کند آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_flex_id.so\(dq, \(dqparameters\(dq: { \(dqidentifier\-expression\(dq: \(dqexpression\(dq, \(dqreplace\-client\-id\(dq: true } }, ... ] } .EE .UNINDENT .UNINDENT .sp در مورد DHCPv4، مقدار مشتق‌شده از شناسهٔ منعطف با افزودن یک بایت با مقدار صفر به ابتدای شناسهٔ منعطف تشکیل می‌شود. در مورد DHCPv6، با افزودن دو بایت صفر پیش از شناسهٔ منعطف تشکیل می‌گردد. .sp توجه داشته باشید که برای اعمال این سازوکار، کارساز DHCPv4 باید طوری پیکربندی شود که مقدار گزینهٔ شناسهٔ کلاینت را در طول تخصیص اجاره رعایت کند، یعنی \fBmatch\-client\-id\fP باید روی \fBtrue\fP تنظیم شده باشد\&. برای جزئیات به Using Client Identifier and Hardware Address \%<#\:dhcp4-match-client-id> مراجعه کنید. هیچ تنظیم اضافی برای DHCPv6 لازم نیست. .sp اگر گزینهٔ \fBreplace\-client\-id\fP روی \fBtrue\fP تنظیم شود، مقدار پارامتر \fBecho\-client\-id\fP (که ارسال مجدد گزینهٔ client\-id را کنترل می‌کند) نادیده گرفته می‌شود. .sp بخش libdhcp_lease_cmds.so: Lease Commands for Easier Lease Management دستورهایی را شرح می‌دهد که برای بازیابی، به‌روزرسانی و حذف اجاره‌ها با استفاده از شناسه‌های گوناگون، مانند \fBhw\-address\fP و \fBclient\-id\fP استفاده می‌شوند\&. \fBlibdhcp_lease_cmds.so\fP به طور بومی از پرس‌وجوی اجاره‌ها بر اساس شناسهٔ منعطف پشتیبانی نمی‌کند. با این حال، هنگامی که \fBreplace\-client\-id\fP روی \fBtrue\fP تنظیم شده باشد، امکان پرس‌وجوی اجاره‌ها را با استفاده از مقداری مشتق‌شده از شناسهٔ منعطف فراهم می‌سازد. در DHCPv4، پرس‌وجو شبیه به این است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-get\(dq, \(dqarguments\(dq: { \(dqidentifier\-type\(dq: \(dqclient\-id\(dq, \(dqidentifier\(dq: \(dq00:54:64:45:66\(dq, \(dqsubnet\-id\(dq: 44 } } .EE .UNINDENT .UNINDENT .sp که در آن مقدار هگزادسیمال \(dq54:64:45:66\(dq یک شناسهٔ منعطف محاسبه‌شده برای کلاینت است. .sp در DHCPv6، پرس‌وجوی متناظر چیزی شبیه به این است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-get\(dq, \(dqarguments\(dq: { \(dqidentifier\-type\(dq: \(dqduid\(dq, \(dqidentifier\(dq: \(dq00:00:54:64:45:66\(dq, \(dqsubnet\-id\(dq: 10 } } .EE .UNINDENT .UNINDENT .SS پرچم \fBignore\-iaid\fP .sp هنگامی که \fBignore\-iaid\fP روی \fBtrue\fP تنظیم شود (مقدار پیش‌فرض \fBfalse\fP است)، \fBlibdhcp_flex_id.so\fP باعث می‌شود کارساز Kea DHCPv6 مقدار IAID را از بسته‌های ورودی IPv6 نادیده بگیرد. این پارامتر توسط کارساز Kea DHCPv4 نادیده گرفته می‌شود. .sp اگر بسته تنها شامل یک IA_NA باشد، مقدار IAID به \fB0\fP تغییر کرده و به همین صورت در مخزن اجاره ذخیره خواهد شد. به طور مشابه، اگر بسته تنها شامل یک IA_PD باشد، مقدار IAID به \fB0\fP تغییر یافته و به همین صورت در مخزن اجاره ذخیره می‌شود. IAID در پاسخ بازگشتی به کلاینت به مقدار اولیهٔ خود بازگردانده می‌شود. این تغییر در عبارت شناسه (identifier expression) در صورتی که IAID بخشی از عبارت باشد، قابل مشاهده است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برای جلوگیری از تداخل اجاره‌ها، اگر بستهٔ ورودی شامل بیش از یک IA_NA باشد، مقدار IAID روی هیچ‌یک از IA_NAها تغییر نخواهد کرد. به طور مشابه، اگر بستهٔ ورودی شامل بیش از یک IA_PD باشد، مقدار IAID روی هیچ‌یک از IA_PDها تغییر نمی‌کند. .UNINDENT .UNINDENT .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 این قابلیت با استانداردهای RFC مغایرت دارد و فقط در صورت لزوم باید فعال شود. در صورت فعال شدن، یک پیام هشدار در زمان پیکربندی صادر می‌شود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پارامتر \fBignore\-iaid\fP مستقل از قابلیت شناسهٔ منعطف عمل می‌کند و می‌توان از آن بدون مشخص کردن مقداری برای \fBidentifier\-expression\fP استفاده کرد\&. هنگامی که \fBidentifier\-expression\fP حذف شود یا به عنوان یک رشتهٔ خالی، \fI\(dq\(dq\fP، مشخص گردد، قابلیت شناسهٔ منعطف غیرفعال می‌شود. نسخه‌های Kea پیش از 3.1.2 نیازمند مقداری برای \fBidentifier\-expression\fP هستند اما مقدار رشتهٔ خالی را می‌پذیرند. از نسخهٔ Kea 3.1.2 به بعد، این پارامتر اختیاری است. .UNINDENT .UNINDENT.SS \fBlibdhcp_flex_option.so\fP: کنش‌های انعطاف‌پذیر گزینه برای تنظیم مقادیر گزینه‌ها .sp این کتابخانه به مدیران سیستم اجازه می‌دهد تا بر اساس نتیجه یک عبارت، کنشی را برای یک گزینه مشخص تعریف کنند. این کنش‌ها در مراحل نهایی ساخت بسته پاسخ پرسش (query response)، درست پیش از ارسال آن به کلاینت، اجرا می‌شوند. سه کنشی که در حال حاضر پشتیبانی می‌شوند عبارتند از \fBadd\fP، \fBsupersede\fP و \fBremove\fP\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_flex_option.so\fP بخشی از کد متن‌باز است و برای همه کاربران Kea در دسترس است. .UNINDENT .UNINDENT .sp سینتکس مورد استفاده برای عبارات کنش، همان سینتکسی است که برای طبقه‌بندی کلاینت (client classification) و کتابخانه قلاب (hook) شناسه منعطف (Flexible Identifier) استفاده می‌شود؛ برای شرح دقیق سینتکس، بخش Using Expressions in Classification \%<#\:classification-using-expressions> یا libdhcp_flex_id.so: Flexible Identifier for Host Reservations را ببینید. .sp کنش‌های \fBadd\fP و \fBsupersede\fP از عبارتی استفاده می‌کنند که یک رشته برمی‌گرداند، و در صورتی که رشته خالی باشد کاری انجام نمی‌دهند. کاربرد \fBremove\fP از عبارتی استفاده می‌کند که مقدار \fBtrue\fP یا \fBfalse\fP برمی‌گرداند، و در صورت \fBfalse\fP بودن کاری انجام نمی‌دهد. هنگامی که لازم باشد یک گزینه روی مقدار خالی تنظیم شود، این سازوکار کارایی ندارد، اما در عوض می‌توان از یک کلاس کلاینت (client class) استفاده کرد. .sp کنش \fBadd\fP تنها زمانی یک گزینه را اضافه می‌کند که آن گزینه از قبل وجود نداشته باشد و عبارت به رشته خالی ارزیابی نشود. کنش \fBsupersede\fP مشابه است، اما در صورتی که گزینه از قبل وجود داشته باشد، مقدار آن را بازنویسی می‌کند. کنش \fBremove\fP در صورتی که گزینه از قبل وجود داشته باشد و عبارت به \fBtrue\fP ارزیابی شود، آن گزینه را از بسته پاسخ حذف می‌کند. .sp گزینه‌ای که کنش بر آن اعمال می‌شود را می‌توان از طریق کد عددی یا نام آن مشخص کرد؛ مشخص کردن کد یا نام الزامی است. فضای گزینه (option space) بسته به سروری که کتابخانه هوک در آن بارگذاری شده است، DHCPv4 یا DHCPv6 خواهد بود. .sp \fBlibdhcp_flex_option.so\fP می‌تواند توسط هر یک از فرایندهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. این کتابخانه یک پارامتر اجباری \fBoptions\fP به همراه فهرستی از نگاشت‌های پارامتری به ازای هر گزینه دریافت می‌کند که شامل کنش‌های \fBcode\fP، \fBname\fP، \fBadd\fP، \fBsupersede\fP و \fBremove\fP است. مدخل‌های کنش یک مقدار رشته‌ای می‌پذیرند که نشان‌دهنده یک عبارت است. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_flex_option.so\(dq, \(dqparameters\(dq: { \(dqoptions\(dq: [ { \(dqcode\(dq: 67, \(dqadd\(dq: \(dqifelse(option[host\-name].exists,concat(option[host\-name].text,\(aq.boot\(aq),\(aq\(aq)\(dq } ] } } ] } } .EE .UNINDENT .UNINDENT .sp اگر (و تنها اگر) بسته \fBquery\fP شامل گزینه \fBhost\-name\fP (کد ۱۲) باشد، گزینه \fBboot\-file\-name\fP (کد ۶۷) با محتوای نام میزبان به همراه پسوند \fB\&.boot\fP به پاسخ افزوده می‌شود. .sp یکی از کاربردهای متداول، تغییر دادن گزینه subnet mask در DHCPv4 (کد ۱) است. مثال زیر این قابلیت را نشان می‌دهد، که در آن به تمامی بسته‌های ورودی شناسایی‌شده با آدرس درگاه 192.168.0.1، با یک ماسک زیرشبکه ۳۲/ در پاسخ پاسخ داده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_flex_option.so\(dq, \(dqparameters\(dq: { \(dqoptions\(dq: [ { \(dqcode\(dq: 1, \(dqsupersede\(dq: \(dqifelse(pkt4.giaddr==192.168.0.1, \(aq255.255.255.255\(aq, \(aq\(aq)\(dq } ] } } ] } } .EE .UNINDENT .UNINDENT .sp کتابخانه Flexible Option هم از DHCPv4 و هم از DHCPv6 پشتیبانی می‌کند. .sp کنش‌های \fBadd\fP و \fBsupersede\fP یک پارامتر بولی اختیاری \fBcsv\-format\fP دریافت می‌کنند. اگر مشخص نشود یا روی \fBfalse\fP تنظیم شود، داده‌های گزینه با استفاده از مقدار خام عبارت ارزیابی‌شده تنظیم می‌شوند. هنگامی که روی \fBtrue\fP پیکربندی شده باشد، این مقدار با استفاده از تعریف گزینه برگرفته از داده‌های گزینه مشخص‌شده در فایل پیکربندی تجزیه می‌شود. این قابلیت تنظیم مقادیر را برای گزینه‌هایی که از ساختارهای رکوردی پیچیده یا نام‌های دامنه کاملاً واجد شرایط (FQDN) استفاده می‌کنند، آسان می‌سازد. .sp برای نمونه، اگر ارزیابی عبارت مقدار \(dqexample.com\(dq را برگرداند و گزینه با نوع \fBfqdn\fP تعریف شده باشد، نام دامنه به قالب باینری DNS کدگذاری می‌شود. .sp از نسخه 2.1.4 نرم‌افزار Kea به بعد، پارامتر \fBclient\-class\fP یک محافظ کلاس (class guard) را مشخص می‌کند و نام یک client\-class را می‌پذیرد. در صورتی که خالی نباشد، بسته کلاینت برای استفاده از این مدخل باید به کلاس مشخص‌شده تعلق داشته باشد. .sp همچنین امکان داشتن چندین مدخل برای یک گزینه یکسان وجود دارد، اما هر مدخل باید دقیقاً دارای یک کنش باشد. اگر گزینه در \fBdhcp4\fP برای DHCPv4 یا در \fBdhcp6\fP برای DHCPv6 تعریف نشده باشد، محل تعریف گزینه را می‌توان با استفاده از نام آن، از طریق پارامتر جدید \fBspace\fP مشخص کرد. .sp از نسخه 2.1.4 نرم‌افزار Kea به بعد، زیرگزینه‌ها (sub\-options) با مدخل جدید \fBsub\-options\fP پشتیبانی می‌شوند که جایگزین کنش در پیکربندی گزینه دربرگیرنده (یعنی گزینه‌ای که زیرگزینه‌ها در آن قرار دارند) می‌شود. .sp پارامتر \fBsub\-options\fP فهرستی از مدخل‌های زیرگزینه را دریافت می‌کند که هر یک شامل موارد زیر است: .INDENT 0.0 .IP \(bu 2 \fBcode\fP \- کد زیرگزینه را مشخص می‌کند؛ مشخص کردن \fBcode\fP یا \fBname\fP الزامی است. اگر هر دو ارائه شوند، باید با یکدیگر مطابقت داشته باشند وگرنه پیکربندی در زمان بارگذاری رد می‌شود. .IP \(bu 2 \fBname\fP \- نام زیرگزینه را مشخص می‌کند؛ مشخص کردن \fBcode\fP یا \fBname\fP الزامی است. اگر هر دو ارائه شوند، باید با یکدیگر مطابقت داشته باشند وگرنه پیکربندی در زمان بارگذاری رد می‌شود. .IP \(bu 2 \fBspace\fP \- فضایی را مشخص می‌کند که زیرگزینه می‌تواند در آن تعریف شود. این پارامتر اختیاری است، زیرا می‌تواند از تعریف گزینه دربرگیرنده استخراج شود. اگر هیچ نام فضای معتبری در زمان بارگذاری موجود نباشد، پیکربندی رد می‌شود. توجه داشته باشید که فضاهای سازنده (vendor spaces) هم برای \fBvivso\-suboptions\fP در DHCPv4 و هم برای \fBvendor\-opts\fP در DHCPv6، چه از پیش‌تعریف‌شده (مانند شناسه سازنده DoCSIS با کد 4491) و چه سفارشی، پشتیبانی می‌شوند. .IP \(bu 2 \fBadd\fP \- (کنش) زیرگزینه را تنها در صورتی اضافه می‌کند که از قبل وجود نداشته باشد و عبارت به رشته خالی ارزیابی نشود. .IP \(bu 2 \fBsupersede\fP \- (کنش) در صورتی که عبارت به رشته خالی ارزیابی نشود، زیرگزینه را اضافه یا بازنویسی می‌کند. .IP \(bu 2 \fBremove\fP \- (کنش) در صورتی که زیرگزینه از قبل وجود داشته باشد و عبارت به true ارزیابی شود، آن را حذف می‌کند. .IP \(bu 2 \fBcontainer\-add\fP \- یک مقدار بولی است که مشخص می‌کند آیا در صورت عدم وجود گزینه دربرگیرنده در کنش‌های \fBadd\fP و \fBsupersede\fP، این گزینه باید ایجاد شود یا خیر. در صورت عدم تعیین، مقدار پیش‌فرض آن \fBtrue\fP است\&. .IP \(bu 2 \fBcontainer\-remove\fP \- یک مقدار بولی است که مشخص می‌کند آیا پس از حذف یک زیرگزینه توسط کنش \fBremove\fP، در صورتی که گزینه دربرگیرنده خالی بماند، باید حذف شود یا خیر. در صورت عدم تعیین، مقدار پیش‌فرض آن \fBtrue\fP است\&. .IP \(bu 2 \fBcsv\-format\fP \- یک مقدار بولی است که مشخص می‌کند آیا مقدار خام عبارت ارزیابی‌شده استفاده شود (false، پیش‌فرض) یا با استفاده از تعریف زیرگزینه تجزیه شود (true). .IP \(bu 2 \fBclient\-class\fP \- مشخص می‌کند که آیا در صورت عدم تعلق \fBquery\fP به کلاس کلاینت مشخص‌شده، باید از مدخل زیرگزینه صرف‌نظر شود یا خیر. توجه داشته باشید که پارامتر مشابه در مدخل گزینه دربرگیرنده، بر کل فهرست \fBsub\-options\fP اعمال می‌شود. .UNINDENT .sp برای نمونه، این پیکربندی یک زیرگزینه رشته‌ای را به گزینه \fBvendor\-encapsulated\-options\fP در DHCPv4 (کد ۴۳) اضافه می‌کند. این گزینه فضای \fBvendor\-encapsulated\-options\fP را کپسوله‌سازی می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_flex_option.so\(dq, \(dqparameters\(dq: { \(dqoptions\(dq: [ { \(dqcode\(dq: 43, \(dqsub\-options\(dq: [ { \(dqcode\(dq: 1, \(dqadd\(dq: \(dq\(aqfoobar\(aq\(dq } ] } ] } } ] } } .EE .UNINDENT .UNINDENT.SS \fBlibddns_gss_tsig.so\fP: امضای به‌روزرسانی‌های DNS با GSS\-TSIG .sp این کتابخانهٔ قلاب به سرور \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> اجازه می‌دهد تا از GSS\-TSIG برای امضای به‌روزرسانی‌های DNS استفاده کند. برای بحث و بررسی کامل دربارهٔ GSS\-TSIG در Kea، لطفاً به GSS\-TSIG \%<#\:gss-tsig>\& مراجعه کنید. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibddns_gss_tsig.so\fP بخشی از کد متن‌باز است و برای تمامی کاربران Kea در دسترس است. این کتابخانه پیش‌تر تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس بود. .UNINDENT .UNINDENT .SS \fBlibdhcp_ha.so\fP: تاب‌آوری در برابر قطعی با دسترسی‌پذیری بالا برای سرورهای Kea .sp این کتابخانهٔ قلاب می‌تواند بر روی یک جفت سرور DHCPv4 یا DHCPv6 بارگذاری شود تا قابلیت اطمینان سرویس DHCP در صورت وقوع قطعی در یک سرور افزایش یابد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_ha.so\fP بخشی از کد متن‌باز است و برای تمامی کاربران Kea در دسترس است. این کتابخانه پیش‌تر تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس بود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرایند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp دسترسی‌پذیری بالا (HA) برای سرویس DHCP از طریق اجرای چندین نمونه سرور همکار فراهم می‌شود. اگر هر یک از این نمونه‌ها به هر دلیلی (از کار افتادن نرم‌افزار DHCP، قطعی برق، خرابی سخت‌افزار) از دسترس خارج شود، نمونه سرور بازمانده می‌تواند به ارائهٔ سرویس قابل‌اطمینان به کلاینت‌ها ادامه دهد. بسیاری از پیاده‌سازی‌های سرور DHCP شامل پروتکل \(dqDHCP Failover\(dq هستند که مهم‌ترین ویژگی‌های آن ارتباط میان سرورها، تشخیص خرابی همتا، و همگام‌سازی اجاره‌ها میان سرورها است. با این حال، فرایند استانداردسازی failover برای DHCPv4 هرگز توسط IETF تکمیل نشد. استاندارد failover برای DHCPv6 (RFC 8156) منتشر شد، اما پیچیده و استفاده از آن دشوار است، محدودیت‌های عملیاتی چشمگیری دارد، و با همتای v4 خود متفاوت است. اگرچه استفاده از یک پروتکل failover \(dqاستاندارد\(dq ممکن است مفید باشد، بیشتر کاربران Kea صرفاً به دنبال یک راهکار کاربردی هستند که دسترسی‌پذیری بالای سرویس DHCP را تضمین کند. از این رو، کتابخانهٔ قلاب Kea HA مفاهیم اصلی را از پروتکل DHCP failover برگرفته، اما از راهکارهای اختصاصی خود برای ارتباطات و پیکربندی استفاده می‌کند. این کتابخانه ماشین وضعیت اختصاصی خود را ارائه می‌دهد که پیاده‌سازی آن را بسیار ساده‌تر کرده و به‌طور کلی سازگاری بهتری با Kea دارد، و قابلیت‌های یکسانی را در هر دو DHCPv4 و DHCPv6 فراهم می‌آورد. این سند عمداً از اصطلاح \(dqhigh availability\(dq به جای \(dqfailover\(dq استفاده می‌کند تا تأکید کند که این پیاده‌سازیِ پروتکل failover نیست. .sp بخش‌های بعدی به شرح پیکربندی و نحوهٔ کارکرد کتابخانهٔ قلاب Kea HA می‌پردازند. .SS پیکربندی‌های پشتیبانی‌شده (Supported Configurations) .sp کتابخانهٔ قلاب Kea HA از سه پیکربندی، که با عنوان حالت‌های HA نیز شناخته می‌شوند، پشتیبانی می‌کند: \fBload\-balancing\fP، \fBhot\-standby\fP و \fBpassive\-backup\fP\&. در حالت \fBload\-balancing\fP، دو سرور به درخواست‌های DHCP پاسخ می‌دهند. عملکرد \fBload\-balancing\fP همان‌گونه که در RFC 3074 \% شرح داده شده پیاده‌سازی گردیده است، و هر سرور به نیمی از پرس‌وجوهای DHCP دریافتی پاسخ می‌دهد. هنگامی که یکی از سرورها اجاره‌ای را برای یک کلاینت تخصیص می‌دهد، از طریق کانال کنترل (از طریق RESTful API) به سرور همتا اطلاع می‌دهد تا همتا بتواند اطلاعات اجاره را در پایگاه دادهٔ خود ذخیره کند. اگر ارتباط با سرور همتا ناموفق باشد، پرس‌وجوی DHCP دور انداخته می‌شود و پاسخی به کلاینت DHCP بازگردانده نخواهد شد. اگر به‌روزرسانی اجاره موفقیت‌آمیز باشد، پاسخ توسط سروری که اجاره را تخصیص داده به کلاینت DHCP ارسال می‌شود. با تبادل به‌روزرسانی‌های اجاره، هر دو سرور رونوشتی از تمامی اجاره‌های تخصیص‌یافته توسط کل راه‌اندازی HA را دریافت می‌کنند، و در صورت از دسترس خارج شدن همتا، هر یک از سرورها می‌توانند برای مدیریت کل ترافیک DHCP تغییر وضعیت دهند. .sp در پیکربندی \fBload\-balancing\fP، یکی از سرورها باید به عنوان \fBprimary\fP و دیگری به عنوان \fBsecondary\fP تعیین شود. از نظر عملکردی، تفاوتی میان این دو در طول کارکرد عادی وجود ندارد. با این حال، این تمایز هنگامی لازم است که دو سرور (تقریباً) در یک زمان راه‌اندازی شوند و ناچار باشند پایگاه‌های دادهٔ اجارهٔ خود را همگام‌سازی کنند. سرور primary ابتدا پایگاه داده را همگام می‌کند. سرور secondary قبل از شروع همگام‌سازی خود، منتظر می‌ماند تا سرور primary همگام‌سازی پایگاه دادهٔ اجاره را به پایان برساند. .sp در پیکربندی \fBhot\-standby\fP، یکی از سرورها به عنوان \fBprimary\fP و دیگری به عنوان \fBstandby\fP تعیین می‌شود. در طول کارکرد عادی، سرور primary تنها سروری است که به درخواست‌های DHCP پاسخ می‌دهد. سرور standby به‌روزرسانی‌های اجاره را از سرور primary از طریق کانال کنترل دریافت می‌کند؛ با این حال، تا زمانی که primary در حال اجرا باشد، یا به بیان دقیق‌تر، تا زمانی که standby سرور primary را آفلاین نداند، به هیچ پرس‌وجوی DHCP پاسخ نمی‌دهد. اگر سرور standby خرابی سرور primary را تشخیص دهد، شروع به پاسخ‌گویی به تمام پرس‌وجوهای DHCP می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 مدیران سیستم اغلب در این فکرند که آیا از حالت \fBload\-balancing\fP استفاده کنند یا \fBhot\-standby\fP. حالت \fBload\-balancing\fP این مزیت را دارد که بار DHCP را بین دو نمونه تقسیم کرده و ترافیک پردازش‌شده توسط هر یک از آن‌ها را کاهش می‌دهد. با این حال، همیشه برای مدیران سیستم واضح نیست که استفاده از حالت \fBload\-balancing\fP مستلزم تقسیم دستی استخرهای آدرس بین دو نمونهٔ Kea با استفاده از کلاس‌بندی کلاینت است، تا از تخصیص آدرس یکسان توسط هر دو سرور به کلاینت‌های مختلف ممانعت به عمل آید. چنین تفکیکی در حالت \fBhot\-standby\fP مورد نیاز نیست. بنابراین، مزیت استفاده از \fBhot\-standby\fP نسبت به \fBload\-balancing\fP این است که پیکربندی ساده‌تری دارد. در مقابل، \fBload\-balancing\fP پتانسیل کارایی بالاتری دارد اما به بهای پیکربندی پیچیده‌تر تمام می‌شود. برای جزئیات بیشتر در مورد چگونگی تقسیم استخرها با استفاده از کلاس‌بندی کلاینت، Load\-Balancing Configuration را ببینید. .UNINDENT .UNINDENT .sp در پیکربندی‌های شرح‌داده‌شده در بالا، هم سرور primary و هم سرور secondary/standby به عنوان سرورهای \fBactive\fP نامیده می‌شوند، چرا که آن‌ها به‌روزرسانی‌های اجاره را دریافت می‌کنند و می‌توانند با پاسخ دادن به پرس‌وجوهای DHCP که معمولاً توسط همتا رسیدگی می‌شد، به‌طور خودکار به خرابی‌های همتا واکنش نشان دهند. کتابخانهٔ قلاب HA از یک نوع/نقش سرور دیگر نیز پشتیبانی می‌کند: \fBbackup\fP\&. استفاده از سرور backup اختیاری است، و علاوه‌بر سرورهای فعال، می‌تواند در هر دو ساختار \fBload\-balancing\fP و \fBhot\-standby\fP پیاده‌سازی شود. هیچ محدودیتی در تعداد سرورهای backup در راه‌اندازی HA وجود ندارد؛ با این وجود، حضور سرورهای backup ممکن است تأخیر پاسخ‌های DHCP را افزایش دهد، چرا که سرورهای فعال نه‌تنها به‌روزرسانی‌های اجاره را برای یکدیگر، بلکه برای سرورهای backup نیز ارسال می‌کنند. سرورهای فعال پیش از پاسخ دادن به کلاینت‌های DHCP منتظر تأییدیه از جانب سرورهای backup نمی‌مانند، بنابراین بار اضافی ناشی از ارسال به‌روزرسانی‌های اجاره به سرورهای backup به حداقل می‌رسد. .sp در آخرین پیکربندی پشتیبانی‌شده، یعنی \fBpassive\-backup\fP، تنها یک سرور فعال و معمولاً یک یا چند سرور backup وجود دارد. یک پیکربندی \fBpassive\-backup\fP بدون هیچ سرور backup نیز پذیرفته می‌شود، اما تفاوتی با اجرای یک سرور تک بدون هیچ قابلیت HA ندارد. .sp پیکربندی \fBpassive\-backup\fP در شرایطی به کار می‌رود که مدیر سیستم بخواهد بدون اجرای یک ساختار کامل failover، از سرور(های) backup به عنوان فضایی اضافی برای ذخیره‌سازی اجاره‌ها بهره ببرد. در این حالت، در صورت خرابی سرور primary، سرویس DHCP از دست می‌رود؛ و مستلزم آن است که مدیر سیستم سرور primary را به صورت دستی مجدداً راه‌اندازی کند تا سرویس DHCP بازیابی شود. مدیر سیستم همچنین می‌تواند یکی از سرورهای backup را برای ارائهٔ سرویس DHCP به کلاینت‌ها پیکربندی کند، زیرا این سرورها باید اطلاعات دقیق یا تقریباً دقیقی از اجاره‌های تخصیص‌یافته داشته باشند. مزیت اصلی حالت \fBpassive\-backup\fP این است که مقداری افزونگی در اطلاعات اجاره فراهم می‌کند، اما با عملکرد بهتر سرور primary در پاسخ‌گویی به پرس‌وجوهای DHCP همراه است. سرور primary مجبور نیست پیش از ارسال پاسخ به کلاینت DHCP، منتظر دریافت تأییدیه‌های به‌روزرسانی اجاره از سرورهای backup بماند. این کار زمان پاسخ‌گویی را در مقایسه با حالت‌های \fBload\-balancing\fP و \fBhot\-standby\fP کاهش می‌دهد؛ حالت‌هایی که در آن‌ها سرور پاسخ‌دهنده به پرس‌وجوی DHCP باید پیش از پاسخ‌دهی به کلاینت، منتظر تأییدیه از سوی دیگر سرور فعال بماند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 یک مورد کاربرد جالب برای یک سرور فعال منفرد در حالت \fBpassive\-backup\fP، سرویس اعلان است که در آن نرم‌افزاری با معرفی خود به عنوان سرور backup، اعلان‌های هم‌زمان دربارهٔ اجاره‌های تخصیص‌یافته و حذف‌شده را از سرور primary دریافت می‌کند و می‌تواند آن‌ها را در یک صفحهٔ پایش نمایش دهد، هشدارها را به کار اندازد، و غیره. .UNINDENT .UNINDENT.SS "ساعت‌ها در سرورهای فعال (Clocks on Active Servers)" .sp همگام‌سازی ساعت‌ها برای کارکرد قابل‌اطمینان پیکربندی HA ضروری است. سرورها اطلاعات اجاره را \- از طریق به‌روزرسانی‌های اجاره و در طول همگام‌سازی پایگاه‌های داده \- از جمله زمان تخصیص اجاره و زمان انقضای آن، به اشتراک می‌گذارند. معمولاً مقداری انحراف ساعت (clock skew) بین سرورهای حاضر در راه‌اندازی HA وجود دارد؛ این موضوع تا زمانی که انحراف ساعت در مقایسه با طول عمر اجاره‌ها نسبتاً کم باشد، قابل قبول است. با این حال، اگر انحراف ساعت بیش از حد زیاد شود، زمان‌های انقضای متفاوت اجاره در سرورهای گوناگون ممکن است باعث اختلال در عملکرد سامانهٔ HA شود. برای نمونه، یک سرور ممکن است اجاره‌ای را منقضی‌شده تلقی کند در حالی که در واقعیت هنوز معتبر است. فرایند بازپس‌گیری اجاره ممکن است نام مرتبط با این اجاره را از DNS حذف کند و بعداً هنگامی که کلاینت سعی در تمدید اجاره دارد، مشکلاتی به وجود آورد. .sp هر سرور فعال با مقایسهٔ زمان فعلی خود با زمان بازگردانده‌شده توسط شریک خود در پاسخ به دستور \fBha\-heartbeat\fP، انحراف ساعت را پایش می‌کند. این کار تقریب مناسبی از انحراف ساعت ارائه می‌دهد، اگرچه بازهٔ زمانی بین ارسال پاسخ توسط شریک و دریافت آن توسط سروری که دستور \fBha\-heartbeat\fP را فرستاده است در نظر نمی‌گیرد. اگر انحراف ساعت از ۳۰ ثانیه بیشتر شود، یک پیام لاگ هشدار صادر می‌شود. مدیر سیستم می‌تواند با همگام‌سازی ساعت‌ها (برای مثال با استفاده از NTP) این مشکل را برطرف کند؛ سرورها باید اصلاح انحراف ساعت را تشخیص داده و صدور هشدار را متوقف کنند. .sp اگر انحراف ساعت اصلاح نشود و از ۶۰ ثانیه فراتر رود، سرویس HA در هر یک از سرورها خاتمه می‌یابد، به این معنی که ماشین حالت وارد وضعیت \fBterminated\fP می‌شود. سرورها به پاسخ‌گویی به کلاینت‌های DHCP (مانند حالت \fBload\-balancing\fP یا \fBhot\-standby\fP) ادامه خواهند داد، اما نه به‌روزرسانی‌های اجاره و نه ضربان‌های قلب (heartbeats) را رد و بدل نخواهند کرد و پایگاه‌های دادهٔ اجارهٔ آن‌ها از یکدیگر واگرا می‌شوند. در این حالت، مدیر سیستم باید ساعت‌ها را همگام کرده و سرورها را مجدداً راه‌اندازی کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 راه‌اندازی مجدد سرورها به صورت تک‌تک و بدون ترتیب خاصی امکان‌پذیر است. پیش از راه‌اندازی مجدد سرورها، ساعت‌ها حتماً باید همگام باشند. سرور ری‌استارت‌شده تا زمانی که شریک آن نیز ری‌استارت شود در وضعیت \fBwaiting\fP باقی می‌ماند. اگر شریک ظرف مدت ۱۰ دقیقه راه‌اندازی مجدد نشود، سرورِ ری‌استارت‌شده برای ادامهٔ پاسخ‌گویی به کلاینت‌های DHCP دوباره به وضعیت \fBterminated\fP بازمی‌گردد. برای از سر گرفتن سرویس عادی HA، هر دو سرور را مجدداً راه‌اندازی کنید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 انحراف ساعت تنها بین دو سرور فعال سنجیده می‌شود، و تنها سرورهای فعال در صورت بالا بودن بیش از حد انحراف وارد وضعیت \fBterminated\fP می‌شوند. انحراف ساعت بین سرورهای فعال و پشتیبان (backup) ارزیابی نمی‌شود، زیرا سرورهای فعال پیام‌های ضربان قلب را با سرورهای پشتیبان تبادل نمی‌کنند. .UNINDENT .UNINDENT .SS "پشتیبانی از HTTPS (HTTPS Support)" .sp از نسخهٔ Kea 1.9.7، کتابخانهٔ هوک دسترس‌پذیری بالا (High Availability) از HTTPS بر بستر TLS پشتیبانی می‌کند، همان‌گونه که در پشتیبانی از TLS/HTTPS \%<#\:tls>\& شرح داده شده است. .sp پارامترهای پیکربندی HTTPS عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBtrust\-anchor\fP \- نام فایل یا دایرکتوری‌ای را مشخص می‌کند که گواهی مرجع صدور گواهی (CA) مربوط به یک موجودیت Kea در آن یافت می‌شود. .IP \(bu 2 \fBcert\-file\fP \- نام فایل حاوی گواهی نهاد پایانی (end\-entity) مورد استفاده را مشخص می‌کند. .IP \(bu 2 \fBkey\-file\fP \- کلید خصوصی گواهی نهاد پایانی مورد استفاده را مشخص می‌کند. .UNINDENT .sp این پارامترها را می‌توان در هر دو سطح سراسری (global) و نظیر (peer) پیکربندی کرد. در صورت پیکربندی در هر دو سطح، مقدار peer استفاده می‌شود که امکان اشتراک‌گذاری مقادیر عمومی را فراهم می‌سازد. .sp هر سه پارامتر یا باید همگی تعیین نشده باشند (HTTPS غیرفعال) یا همگی مشخص شده باشند (HTTPS فعال). تعیین رشتهٔ خالی به عنوان مشخص‌نشده در نظر گرفته می‌شود؛ این قابلیت می‌تواند به عنوان مثال برای غیرفعال کردن HTTPS برای یک peer خاص در زمانی که در سطح سراسری فعال است، به کار رود. .sp از آنجا که کتابخانهٔ هوک High Availability یک کلاینت HTTPS است، هیچ پارامتر \fBcert\-required\fP در پیکربندی این هوک وجود ندارد. این پارامتر می‌تواند در سمت سرور تنظیم شود تا گواهی کلاینت در ارتباط کلاینت\-سرور الزامی شده و اعتبارسنجی شود. این پارامتر ارتباط بین نظیرهای HA را در سمت کلاینت تحت تأثیر قرار نمی‌دهد؛ برای اطلاعات دربارهٔ سمت سرور، به بخش زیر مراجعه کنید. .sp از نسخهٔ Kea 2.1.7 به بعد، سمت سرور HTTPS نیز پشتیبانی می‌شود: .INDENT 0.0 .IP \(bu 2 مدخل peer مربوط به نام سرور برای تنظیمات TLS استفاده می‌شود. .IP \(bu 2 پارامتر جدید \fBrequire\-client\-certs\fP مشخص می‌کند که آیا گواهی‌های کلاینت الزامی و اعتبارسنجی می‌شوند یا خیر، یعنی رفتاری مشابه \fBcert\-required\fP\& دارد. مقدار پیش‌فرض آن \fBtrue\fP است و یک پارامتر پیکربندی در سطح HA (در مقایسه با پیکربندی peer) به شمار می‌رود. .UNINDENT .sp نسخهٔ Kea 2.1.7 یک ویژگی امنیتی جدید با پارامتر پیکربندی HA به نام \fBrestrict\-commands\fP اضافه کرد: در صورت تنظیم روی \fBtrue\fP، دستوراتی که توسط این هوک استفاده نمی‌شوند رد خواهند شد. مقدار پیش‌فرض از نسخهٔ Kea 3.0.0 برابر با \fBtrue\fP است. .sp در ادامه نمونه‌ای از یک جفت سرور HA برای حالت \fBhot\-standby\fP به همراه TLS آورده شده است. .sp سرور ۱: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [{ \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [{ \(dqthis\-server\-name\(dq: \(dqserver1\(dq, \(dqtrust\-anchor\(dq: \(dq/usr/lib/kea/CA.pem\(dq, \(dqcert\-file\(dq: \(dq/usr/lib/kea/server1_cert.pem\(dq, \(dqkey\-file\(dq: \(dq/usr/lib/kea/server1_key.pem\(dq, \(dqmode\(dq: \(dqhot\-standby\(dq, \(dqheartbeat\-delay\(dq: 10000, \(dqmax\-response\-delay\(dq: 60000, \(dqmax\-ack\-delay\(dq: 5000, \(dqmax\-unacked\-clients\(dq: 5, \(dqpeers\(dq: [{ \(dqname\(dq: \(dqserver1\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.33:8005/\(dq, \(dqrole\(dq: \(dqprimary\(dq, \(dqauto\-failover\(dq: true }, { \(dqname\(dq: \(dqserver2\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.66:8005/\(dq, \(dqrole\(dq: \(dqstandby\(dq, \(dqauto\-failover\(dq: true }] }] } }], \(dqsubnet4\(dq: [{ \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.3.100 \- 192.0.3.250\(dq }] }], \(dqcontrol\-sockets\(dq: [{ \(dqsocket\-type\(dq: \(dqhttps\(dq, \(dqsocket\-address\(dq: \(dq192.168.56.33\(dq, \(dqsocket\-port\(dq: 8000, \(dqtrust\-anchor\(dq: \(dq/var/lib/kea/CA.pem\(dq, \(dqcert\-file\(dq: \(dq/var/lib/kea/server1_cert.pem\(dq, \(dqkey\-file\(dq: \(dq/var/lib/kea/server1_key.pem\(dq, \(dqcert\-required\(dq: true }] } } .EE .UNINDENT .UNINDENT .sp سرور ۲: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [{ \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [{ \(dqthis\-server\-name\(dq: \(dqserver2\(dq, \(dqtrust\-anchor\(dq: \(dq/usr/lib/kea/CA.pem\(dq, \(dqcert\-file\(dq: \(dq/usr/lib/kea/server2_cert.pem\(dq, \(dqkey\-file\(dq: \(dq/usr/lib/kea/server2_key.pem\(dq, \(dqmode\(dq: \(dqhot\-standby\(dq, \(dqheartbeat\-delay\(dq: 10000, \(dqmax\-response\-delay\(dq: 60000, \(dqmax\-ack\-delay\(dq: 5000, \(dqmax\-unacked\-clients\(dq: 5, \(dqpeers\(dq: [{ \(dqname\(dq: \(dqserver1\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.33:8005/\(dq, \(dqrole\(dq: \(dqprimary\(dq, \(dqauto\-failover\(dq: true }, { \(dqname\(dq: \(dqserver2\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.66:8005/\(dq, \(dqrole\(dq: \(dqstandby\(dq, \(dqauto\-failover\(dq: true }] }] } }], \(dqsubnet4\(dq: [{ \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.3.100 \- 192.0.3.250\(dq }] }], \(dqcontrol\-sockets\(dq:[{ \(dqsocket\-type\(dq: \(dqhttps\(dq, \(dqsocket\-address\(dq: \(dq192.168.56.66\(dq, \(dqsocket\-port\(dq: 8000, \(dqtrust\-anchor\(dq: \(dq/var/lib/kea/CA.pem\(dq, \(dqcert\-file\(dq: \(dq/var/lib/kea/server2_cert.pem\(dq, \(dqkey\-file\(dq: \(dq/var/lib/kea/server2_key.pem\(dq, \(dqcert\-required\(dq: true }] } } .EE .UNINDENT .UNINDENT.SS "وضعیت‌های سرور (Server States)" .sp یک سرور DHCP که در یک ساختار HA (دسترس‌پذیری بالا) کار می‌کند، یک ماشین وضعیت (state machine) را اجرا می‌نماید و وضعیت سرور می‌تواند توسط همتایانش با استفاده از دستور \fBha\-heartbeat\fP که از طریق RESTful API ارسال می‌شود، دریافت گردد. اگر سرور شریک (partner) در مدت‌زمان مشخص‌شده به دستور \fBha\-heartbeat\fP پاسخ ندهد، ارتباط قطع‌شده تلقی می‌شود و سرور ممکن است، بسته به پیکربندی، از تدابیر اضافی (که در ادامه این سند شرح داده شده است) برای بررسی اینکه آیا شریک همچنان فعال است یا خیر، استفاده کند. اگر مشخص شود که شریک کار نمی‌کند، سرور به وضعیت \fBpartner\-down\fP تغییر وضعیت می‌دهد تا تمام ترافیک DHCP هدایت‌شده به سیستم را مدیریت کند. .sp در این حالت، سرور بازمانده به ارسال دستور \fBha\-heartbeat\fP ادامه می‌دهد تا زمان فعال شدن مجدد شریک را تشخیص دهد. در آن هنگام، سرور شریک پایگاه‌داده اجاره‌ها (leases) را همگام‌سازی می‌کند. هنگامی که مجدداً آماده کار شد، سرور بازمانده به عملکرد عادی بازمی‌گردد؛ یعنی به وضعیت \fBload\-balancing\fP یا \fBhot\-standby\fP. .sp فهرست زیر شامل تمام وضعیت‌های ممکن سرور است: .INDENT 0.0 .IP \(bu 2 \fBbackup\fP \- عملکرد عادی سرور پشتیبان. در این وضعیت، به‌روزرسانی‌های اجاره را از سرور(های) فعال دریافت می‌کند. .IP \(bu 2 \fBcommunication\-recovery\fP \- یک سرور فعال که در حالت \fBload\-balancing\fP اجرا می‌شود، هنگامی که در کانال کنترلی با سرور شریک دچار مشکلات ارتباطی شود، ممکن است به این وضعیت منتقل گردد. این یک وضعیت میانی بین وضعیت‌های \fBload\-balancing\fP و \fBpartner\-down\fP است. در این وضعیت، سرور همچنان به پرس‌وجوهای DHCP پاسخ می‌دهد اما به‌روزرسانی‌های اجاره را برای شریک ارسال نمی‌کند؛ به‌روزرسانی‌های اجاره در صف قرار می‌گیرند و پس از برقراری مجدد ارتباط عادی ارسال می‌شوند. اگر ارتباط در مدت‌زمان مشخص‌شده از سر گرفته نشود، سرور اصلی (primary) به وضعیت \fBpartner\-down\fP تغییر وضعیت می‌دهد. وضعیت \fBcommunication\-recovery\fP برای اطمینان از سرویس‌دهی مطمئن DHCP در شرایطی معرفی شد که هر دو سرور فعال همچنان مشغول به کار هستند اما ارتباط بین آنها برای مدتی طولانی قطع شده است. می‌توان هر یک از سرورها را طوری پیکربندی کرد که هرگز وارد این وضعیت نشوند، با تنظیم \fBdelayed\-updates\-limit\fP روی 0 (برای جزئیات بیشتر درباره این پارامتر، به بخش Load\-Balancing Configuration در ادامه این فصل مراجعه کنید). غیرفعال کردن ورود به وضعیت \fBcommunication\-recovery\fP باعث می‌شود سرور به‌محض عدم توانایی در برقراری ارتباط با شریک خود، بررسی وضعیت \fBpartner\-down\fP را آغاز کند. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در Kea 1.9.4، با معرفی \fBdelayed\-updates\-limit\fP، رفتار پیش‌فرض سرور در حالت \fBload\-balancing\fP تغییر کرد. اکنون هنگامی که یک سرور با شریک خود دچار مشکلات ارتباطی می‌شود، وارد وضعیت \fBcommunication\-recovery\fP شده و تا زمان برقراری مجدد ارتباط، به‌روزرسانی‌های اجاره را صف‌بندی می‌کند. پیش از Kea 1.9.4، سروری که در حالت \fBload\-balancing\fP قادر به برقراری ارتباط با شریک خود نبود، بلافاصله انتقال به وضعیت \fBpartner\-down\fP را آغاز می‌کرد. .UNINDENT .UNINDENT .INDENT 0.0 .IP \(bu 2 \fBhot\-standby\fP \- عملکرد عادی سرور فعال در حال اجرا در حالت \fBhot\-standby\fP؛ هم سرور اصلی و هم سرور standby در حین عملکرد عادی خود در این وضعیت قرار دارند. سرور اصلی به پرس‌وجوهای DHCP پاسخ می‌دهد و به‌روزرسانی‌های اجاره را به سرور standby و هر سرور backup موجود ارسال می‌کند. .IP \(bu 2 \fBload\-balancing\fP \- عملکرد عادی سرور فعال در حال اجرا در حالت \fBload\-balancing\fP؛ هم سرور اصلی و هم سرور ثانویه (secondary) در حین عملکرد عادی خود در این وضعیت قرار دارند. هر دو سرور به پرس‌وجوهای DHCP پاسخ می‌دهند و به‌روزرسانی‌های اجاره را برای یکدیگر و هر سرور backup موجود ارسال می‌کنند. .IP \(bu 2 \fBin\-maintenance\fP \- یک سرور فعال در نتیجه دریافت اعلان از طرف شریک خود مبنی بر درخواست تعمیر و نگهداری ساختار HA توسط مدیر سیستم، به این وضعیت منتقل می‌شود. مدیر سیستم با ارسال دستور \fBha\-maintenance\-start\fP به سروری که قرار است مسئولیت پاسخ‌گویی به کلاینت‌های DHCP را در حین آفلاین شدن سرور دیگر برای تعمیرات بر عهده بگیرد، درخواست تعمیر و نگهداری را ثبت می‌کند. اگر سرور در وضعیت \fBin\-maintenance\fP باشد، می‌توان آن را با خیال راحت خاموش کرد. سرور شریک بلافاصله پس از پی بردن به خاموش شدن سرورِ در حال تعمیر، به وضعیت \fBpartner\-down\fP تغییر وضعیت می‌دهد. .IP \(bu 2 \fBpartner\-down\fP \- یک سرور فعال پس از تشخیص آفلاین بودن شریک خود (سرور فعال دیگر)، به این وضعیت منتقل می‌شود. اگر صرفاً یک سرور backup در دسترس نباشد، سرور به این وضعیت تغییر حالت نمی‌دهد. در وضعیت \fBpartner\-down\fP، سرور فعال به تمام پرس‌وجوهای DHCP پاسخ می‌دهد؛ از جمله پرس‌وجوهایی که در حالت عادی توسط سروری که اکنون در دسترس نیست مدیریت می‌شدند. .IP \(bu 2 \fBpartner\-in\-maintenance\fP \- یک سرور فعال پس از دریافت دستور \fBha\-maintenance\-start\fP از مدیر سیستم به این وضعیت منتقل می‌شود. سرور در این وضعیت مسئول پاسخ‌گویی به تمام درخواست‌های DHCP می‌شود. سرور دستور \fBha\-maintenance\-notify\fP را به شریک ارسال می‌کند که آن شریک باید وارد وضعیت \fBin\-maintenance\fP شود. سروری که در وضعیت \fBpartner\-in\-maintenance\fP باقی می‌ماند، به ارسال به‌روزرسانی‌های اجاره به شریک ادامه می‌دهد تا زمانی که متوجه شود شریک پاسخ دادن به این به‌روزرسانی‌ها، ضربان‌های قلب (heartbeats) یا هر دستور دیگری را متوقف کرده است. در این صورت، سرورِ در وضعیت \fBpartner\-in\-maintenance\fP به وضعیت \fBpartner\-down\fP تغییر حالت داده و به پاسخ‌گویی به پرس‌وجوها ادامه می‌دهد، اما دیگر به‌روزرسانی‌های اجاره را ارسال نمی‌کند. .IP \(bu 2 \fBpassive\-backup\fP \- یک سرور اصلی که در حالت HA به صورت \fBpassive\-backup\fP اجرا می‌شود، بلافاصله پس از راه‌اندازی (boot) به این وضعیت منتقل می‌شود. سرور اصلی در این وضعیت به تمام ترافیک DHCP پاسخ می‌دهد و به‌روزرسانی‌های اجاره را به سرورهای پشتیبان متصل به خود ارسال می‌کند. به‌طور پیش‌فرض، سرور اصلی منتظر تاییدیه از سرورهای پشتیبان نمی‌ماند و بلافاصله پس از ارسال به‌روزرسانی‌های اجاره به تمامی سرورهای پشتیبان، به پرس‌وجوی DHCP پاسخ می‌دهد. اگر هر یک از به‌روزرسانی‌های اجاره با شکست مواجه شود، سرور پشتیبان آن به‌روزرسانی را از دست می‌دهد اما کلاینت DHCP همچنان پیکربندی می‌شود. این پیکربندی پیش‌فرض را می‌توان با تنظیم پارامتر پیکربندی \fBwait\-backup\-ack\fP روی \fBtrue\fP تغییر داد؛ در این حالت، سرور اصلی همواره منتظر تاییدیه‌ها می‌ماند و اگر ارسال هر یک از به‌روزرسانی‌های مربوطه با شکست مواجه شود، پرس‌وجوی DHCP را نادیده می‌گیرد. این کار یکپارچگی پایگاه‌داده اجاره‌ها بین سرور اصلی و ثانویه را بهبود می‌بخشد. با این حال، در صورت بروز اختلال در ارتباط بین سرور فعال و هر یک از سرورهای پشتیبان، از دیدگاه کلاینت‌های DHCP در عمل منجر به از کار افتادن سرویس DHCP می‌شود. .IP \(bu 2 \fBready\fP \- یک سرور فعال پس از همگام‌سازی پایگاه‌داده اجاره‌های خود با یک شریک فعال، به این وضعیت منتقل می‌شود. این وضعیت به شریک (که ممکن است در وضعیت \fBpartner\-down\fP باشد) نشان می‌دهد که باید به عملکرد عادی بازگردد. اگر و هنگامی که این کار را انجام دهد، سرور در وضعیت \fBready\fP نیز عملکرد عادی خود را آغاز می‌کند. .IP \(bu 2 \fBsyncing\fP \- یک سرور فعال برای واکشی اجاره‌ها از شریک فعال و به‌روزرسانی پایگاه‌داده محلی اجاره‌ها، به این وضعیت منتقل می‌شود. هنگام قرار داشتن در این وضعیت، سرور دستور \fBdhcp\-disable\fP \%<#\:std-isccmd-dhcp-disable> را صادر می‌کند تا سرویس DHCP شریکی را که اجاره‌ها از آن واکشی می‌شوند، غیرفعال کند. سرویس DHCP حداکثر به مدت ۶۰ ثانیه غیرفعال می‌شود و در صورتی که شریک همگام‌کننده نتواند سرویس را مجدداً فعال کند، پس از این مدت به‌طور خودکار دوباره فعال می‌شود. اگر همگام‌سازی با موفقیت انجام شود، سرور همگام‌کننده دستور \fBha\-sync\-complete\-notify\fP را جهت اطلاع به شریک صادر می‌کند. در اکثر وضعیت‌ها، سرور شریک سرویس DHCP خود را مجدداً فعال می‌کند تا به پاسخ‌گویی به پرس‌وجوهای DHCP ادامه دهد. در وضعیت \fBpartner\-down\fP، شریک ابتدا پیش از فعال کردن سرویس DHCP اطمینان حاصل می‌کند که ارتباط بین سرورها دوباره برقرار شده است. عملیات همگام‌سازی به صورت همگام (synchronous) انجام می‌شود؛ سرور منتظر پاسخی از سوی شریک می‌ماند و در حین انجام همگام‌سازی اجاره‌ها کار دیگری انجام نمی‌دهد. سروری که پیکربندی شده تا پایگاه‌داده اجاره‌ها را با شریک خود همگام نکند، یعنی زمانی که پارامتر پیکربندی \fBsync\-leases\fP روی \fBfalse\fP تنظیم شده باشد، هرگز به این وضعیت منتقل نمی‌شود. در عوض، مستقیماً از وضعیت \fBwaiting\fP به وضعیت \fBready\fP منتقل می‌گردد. .IP \(bu 2 \fBterminated\fP \- یک سرور فعال زمانی به این وضعیت منتقل می‌شود که کتابخانه قلاب (hook library) دسترس‌پذیری بالا دیگر قادر به ارائه سرویس مطمئن نباشد و برای حل مشکل نیاز به مداخله دستی مدیر سیستم باشد. مشکلات مختلف در پیکربندی HA ممکن است باعث انتقال سرور به این وضعیت شود. در زمان قرار داشتن در این وضعیت، سرور بر اساس حالت HA انتخاب‌شده (\fBload\-balancing\fP یا \fBhot\-standby\fP) به پاسخ‌گویی به کلاینت‌های DHCP ادامه می‌دهد، اما به‌روزرسانی‌های اجاره ردوبدل نشده و ضربان‌های قلب ارسال نمی‌شوند. هنگامی که سرور وارد وضعیت \fBterminated\fP شد، تا زمانی که مجدداً راه‌اندازی نشود در این وضعیت باقی می‌ماند. مدیر سیستم باید پیش از راه‌اندازی مجدد سرور، مشکلی که این وضعیت را ایجاد کرده است برطرف کند (مانند همگام‌سازی ساعت‌ها)؛ در غیر این صورت، سرور به محض اینکه دریابد مشکل همچنان پابرجاست، مجدداً به وضعیت \fBterminated\fP بازخواهد گشت. .IP \(bu 2 \fBwaiting\fP \- هر نمونه سرورِ راه‌اندازی‌شده وارد این وضعیت می‌شود. یک سرور پشتیبان (backup) مستقیماً از این وضعیت به وضعیت \fBbackup\fP می‌رود. یک سرور فعال برای بررسی وضعیت شریک خود، یک ضربان قلب به آن ارسال می‌کند؛ اگر به نظر برسد که شریک در دسترس نیست، سرور به وضعیت \fBpartner\-down\fP منتقل می‌شود. اگر شریک در دسترس باشد، بسته به تنظیم پارامتر پیکربندی \fBsync\-leases\fP، سرور به وضعیت \fBsyncing\fP یا \fBready\fP منتقل می‌گردد. اگر به نظر برسد هر دو سرور در وضعیت \fBwaiting\fP قرار دارند (راه‌اندازی هم‌زمان)، ابتدا سرور اصلی به وضعیت بعدی منتقل می‌شود. سرور ثانویه یا standby تا زمانی که سرور اصلی به وضعیت \fBready\fP منتقل نشود، در وضعیت \fBwaiting\fP باقی می‌ماند. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر، راه‌اندازی مجدد سرویس HA از وضعیت \fBterminated\fP نیازمند راه‌اندازی مجدد سرور DHCP یا بارگذاری مجدد پیکربندی آن است. .UNINDENT .UNINDENT .sp اینکه آیا سرور به پرس‌وجوهای DHCP پاسخ می‌دهد و به کدام پرس‌وجوها پاسخ می‌دهد، در صورتی که هیچ اقدام مدیریتی برای پیکربندی دیگر سرور انجام نگرفته باشد، به وضعیت سرور بستگی دارد. جدول زیر رفتار پیش‌فرض را برای وضعیت‌های مختلف ارائه می‌دهد. .sp عبارت \fBDHCP Service Scopes\fP مشخص می‌کند که سرور در یک وضعیت معین به کدام گروه از پرس‌وجوهای DHCP دریافت‌شده پاسخ می‌دهد. پیکربندی HA باید نامی یکتا را برای هر سرور درون ساختار HA تعیین کند. این سند در مثال‌های ارائه‌شده از این قرارداد استفاده می‌کند: \(dqserver1\(dq برای سرور اصلی، \(dqserver2\(dq برای سرور ثانویه یا standby، و \(dqserver3\(dq برای سرور backup. در عمل تا زمانی که نام‌ها یکتا باقی بمانند، می‌توان از هر نامی استفاده کرد. .sp توضیحات دقیق این حوزه‌ها (scopes) در ادامه آمده است..SS رفتار پیش‌فرض سرور در وضعیت‌های گوناگون HA .TS box center; l|l|l|l. T{ وضعیت T} T{ نوع سرور T} T{ سرویس DHCP T} T{ محدوده‌های سرویس DHCP T} _ T{ backup T} T{ سرور backup T} T{ غیرفعال T} T{ هیچ‌کدام T} _ T{ communication\-recovery T} T{ primary یا secondary (تنها در حالت load\-balancing) T} T{ فعال T} T{ \(dqHA_server1\(dq یا \(dqHA_server2\(dq T} _ T{ hot\-standby T} T{ primary یا standby (حالت hot\-standby) T} T{ فعال T} T{ \(dqHA_server1\(dq در صورت primary بودن، در غیر این صورت هیچ‌کدام T} _ T{ load\-balancing T} T{ primary یا secondary (حالت load\-balancing) T} T{ فعال T} T{ \(dqHA_server1\(dq یا \(dqHA_server2\(dq T} _ T{ in\-maintenance T} T{ سرور فعال T} T{ غیرفعال T} T{ هیچ‌کدام T} _ T{ partner\-down T} T{ سرور فعال T} T{ فعال T} T{ تمام محدوده‌ها T} _ T{ partner\-in\-maintenance T} T{ سرور فعال T} T{ فعال T} T{ تمام محدوده‌ها T} _ T{ passive\-backup T} T{ سرور فعال T} T{ فعال T} T{ تمام محدوده‌ها T} _ T{ ready T} T{ سرور فعال T} T{ غیرفعال T} T{ هیچ‌کدام T} _ T{ syncing T} T{ سرور فعال T} T{ غیرفعال T} T{ هیچ‌کدام T} _ T{ terminated T} T{ سرور فعال T} T{ فعال T} T{ مشابه با وضعیت load\-balancing یا hot\-standby T} _ T{ waiting T} T{ هر سروری T} T{ غیرفعال T} T{ هیچ‌کدام T} .TE .sp در حالت \fBload\-balancing\fP دو محدوده برای سرورهای فعال مشخص شده است: \(dqHA_server1\(dq و \(dqHA_server2\(dq. پرس‌وجوهای DHCP که به \fBserver1\fP موازنه‌بار می‌شوند متعلق به محدودهٔ \(dqHA_server1\(dq و پرس‌وجوهایی که به \fBserver2\fP موازنه‌بار می‌شوند متعلق به محدودهٔ \(dqHA_server2\(dq هستند. اگر هر یک از سرورها در وضعیت \fBpartner\-down\fP باشد، شریک فعال مسئول پاسخگویی به هر دو محدوده است. .sp در حالت \fBhot\-standby\fP، تنها یک محدوده وجود دارد \- \(dqHA_server1\(dq \- زیرا تنها \fBserver1\fP به پرس‌وجوهای DHCP پاسخ می‌دهد. اگر آن سرور از دسترس خارج شود، \fBserver2\fP مسئول این محدوده خواهد بود. .sp سرورهای backup محدودهٔ اختصاصی خود را ندارند. در برخی موارد می‌توان از آن‌ها برای پاسخگویی به پرس‌وجوهای متعلق به محدوده‌های سرورهای فعال استفاده کرد. همچنین، سرور backup که نه در وضعیت \fBpartner\-down\fP و نه در عملکرد عادی باشد، به هیچ محدوده‌ای سرویس نمی‌دهد. .sp نام‌های محدوده می‌توانند برای مرتبط‌سازی استخرها (pools)، زیرشبکه‌ها و شبکه‌ها با سرورهای مشخص استفاده شوند، به طوری که فقط این سرورها بتوانند نشانی‌ها یا پیشوندها را از آن استخرها، زیرشبکه‌ها یا شبکه‌ها تخصیص دهند. این کار از طریق سازوکار طبقه‌بندی کلاینت (client classification) انجام می‌شود (برای جزئیات بیشتر به Load Balancing With Advanced Classification مراجعه کنید)..SS انتقال قلمرو در وضعیت Partner\-Down .sp هنگامی که یکی از سرورها درمی‌یابد شریک آن در دسترس نیست، شروع به سرویس‌دهی به کلاینت‌ها هم از قلمرو (scope) خود و هم از قلمرو شریک خارج از دسترس می‌کند. این فرایند برای کلاینت‌های جدید، یعنی آن‌هایی که پیام‌های DHCPDISCOVER (در DHCPv4) یا Solicit (در DHCPv6) را ارسال می‌کنند، سرراست است، زیرا آن درخواست‌ها به سرور خاصی فرستاده نمی‌شوند. سرورِ در دسترس هنگامی که در وضعیت \fBpartner\-down\fP قرار دارد، به تمام این‌گونه پرس‌وجوها پاسخ می‌دهد. .sp هنگامی که یک کلاینت اجاره‌ای را تجدید می‌کند، پیام DHCPREQUEST (در DHCPv4) یا Renew (در DHCPv6) خود را مستقیماً به سروری می‌فرستد که اجاره در حال تجدید را تخصیص داده است. اگر این سرور دیگر در دسترس نباشد، کلاینت پاسخی دریافت نخواهد کرد. در این حالت، کلاینت به استفاده از اجاره خود ادامه داده و تا زمان سپری شدن زمان‌سنج اتصال مجدد (T2)، برای تجدید آن تلاش می‌کند. سپس کلاینت وارد مرحله اتصال مجدد (rebinding) می‌شود که در آن پیام DHCPREQUEST (در DHCPv4) یا Rebind (در DHCPv6) را به هر سرور در دسترسی ارسال می‌کند. سرور برجا مانده درخواست اتصال مجدد را دریافت کرده و معمولاً طول عمر اجاره را تمدید می‌کند. سپس کلاینت بر حسب نیاز، برای تجدید اجاره خود به تماس با آن سرور جدید ادامه می‌دهد. .sp اگر و هنگامی که سرور دیگر دوباره در دسترس قرار گیرد، هر دو سرور فعال در نهایت به وضعیت \fBload\-balancing\fP یا \fBhot\-standby\fP تغییر حالت می‌دهند، که در آن مجدداً مسئول قلمروهای خود خواهند بود. برخی کلاینت‌های متعلق به قلمرو سرور راه‌اندازی‌مجددشده تلاش خواهند کرد اجاره‌های خود را از طریق سرور برجا مانده تجدید کنند، اما این سرور دیگر به آن‌ها پاسخ نخواهد داد؛ کلاینت در نهایت از طریق سازوکار اتصال مجدد (rebinding) دوباره به سرور صحیح بازخواهد گشت. .SS پیکربندی Load\-Balancing .sp در ادامه قطعه‌پیکربندی برای فعال‌سازی دسترسی‌پذیری بالا (HA) روی سرور primary در پیکربندی \fBload\-balancing\fP آمده است. همین پیکربندی باید روی سرورهای secondary و backup نیز اعمال شود، با این تفاوت که \fBthis\-server\-name\fP روی آن سرورها باید به ترتیب برابر \(dqserver2\(dq و \(dqserver3\(dq تنظیم شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 به یاد داشته باشید که حالت \fBload\-balancing\fP نیازمند آن است که استخرهای آدرس (address pools) و استخرهای پیشوند واگذارشده (delegated prefix pools) بین سرورهای فعال تقسیم شوند. در طول عملکرد عادی، سرورها از استخرهای غیرهم‌پوشان استفاده می‌کنند تا از تخصیص یک اجاره یکسان به کلاینت‌های مختلف توسط هر دو نمونه جلوگیری شود. سرور تنها زمانی از بخش‌های استخر متعلق به شریک استفاده می‌کند که شریک در حال اجرا نباشد. یادداشت‌های موجود در بخش Supported Configurations را که تفاوت‌های میان حالت‌های \fBload\-balancing\fP و \fBhot\-standby\fP را مشخص می‌کنند، ببینید. معناشناسی افرازبندی استخر (pool partitioning) در ادامه این بخش توضیح داده شده است. بخش Load Balancing With Advanced Classification مثال‌های پیشرفته‌ای از افرازبندی استخر ارائه می‌دهد. .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [{ \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [{ \(dqthis\-server\-name\(dq: \(dqserver1\(dq, \(dqmode\(dq: \(dqload\-balancing\(dq, \(dqheartbeat\-delay\(dq: 10000, \(dqmax\-response\-delay\(dq: 60000, \(dqmax\-ack\-delay\(dq: 5000, \(dqmax\-unacked\-clients\(dq: 5, \(dqmax\-rejected\-lease\-updates\(dq: 10, \(dqdelayed\-updates\-limit\(dq: 100, \(dqpeers\(dq: [{ \(dqname\(dq: \(dqserver1\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.33:8005/\(dq, \(dqrole\(dq: \(dqprimary\(dq, \(dqauto\-failover\(dq: true }, { \(dqname\(dq: \(dqserver2\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.66:8005/\(dq, \(dqrole\(dq: \(dqsecondary\(dq, \(dqauto\-failover\(dq: true }, { \(dqname\(dq: \(dqserver3\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.99:8005/\(dq, \(dqrole\(dq: \(dqbackup\(dq, \(dqbasic\-auth\-user\(dq: \(dqfoo\(dq, \(dqbasic\-auth\-password\(dq: \(dq1234\(dq, \(dqauto\-failover\(dq: false }] }] } }], \(dqsubnet4\(dq: [{ \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.3.100 \- 192.0.3.150\(dq, \(dqclient\-classes\(dq: [ \(dqHA_server1\(dq ] }, { \(dqpool\(dq: \(dq192.0.3.200 \- 192.0.3.250\(dq, \(dqclient\-classes\(dq: [ \(dqHA_server2\(dq ] }], \(dqoption\-data\(dq: [{ \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.3.1\(dq }], \(dqrelay\(dq: { \(dqip\-address\(dq: \(dq10.1.2.3\(dq } }] } .EE .UNINDENT .UNINDENT .sp برای فعال‌سازی HA دو کتابخانه هوک (hook) باید بارگیری شوند: \fBlibdhcp_lease_cmds.so\fP و \fBlibdhcp_ha.so\fP\&. دومی ویژگی HA را پیاده‌سازی می‌کند، در حالی که اولی دستورهای کنترلی مورد نیاز HA را برای دریافت و دستکاری اجاره‌ها در سرورهای دوردست فعال می‌سازد. در مثال ارائه‌شده در بالا، فرض شده است که کتابخانه‌های Kea در دایرکتوری \fB/usr/lib\fP نصب شده‌اند. اگر Kea در دایرکتوری \fB/usr\fP نصب نشده باشد، مکان کتابخانه‌های هوک باید متناسب با آن به‌روزرسانی شود. .sp پیکربندی HA در محدوده \fBlibdhcp_ha.so\fP مشخص می‌شود. توجه داشته باشید در حالی که پارامتر سطح بالای \fBhigh\-availability\fP یک فهرست است، در حال حاضر فقط یک ورودی پشتیبانی می‌شود. .sp پارامترهای سراسری زیر رفتار سرور را در رابطه با HA کنترل می‌کنند: .INDENT 0.0 .IP \(bu 2 \fBthis\-server\-name\fP \- شناسه یکتای سرور در این راه‌اندازی HA است. این شناسه باید با یکی از سرورهای مشخص‌شده در فهرست \fBpeers\fP مطابقت داشته باشد. .IP \(bu 2 \fBmode\fP \- حالت عملکرد HA را مشخص می‌کند. حالت‌هایی که در حال حاضر پشتیبانی می‌شوند \fBload\-balancing\fP و \fBhot\-standby\fP هستند. .IP \(bu 2 \fBheartbeat\-delay\fP \- مدت زمان بر حسب میلی‌ثانیه میان ارسال آخرین ضربان قلب (heartbeat) (یا دستور دیگری که برای شریک ارسال شده) و ضربان قلب بعدی را مشخص می‌کند. ضربان‌های قلب به صورت دوره‌ای برای دریافت وضعیت شریک و بررسی در حال کار بودن آن ارسال می‌شوند. مقدار پیش‌فرض این پارامتر 10000 میلی‌ثانیه است. .IP \(bu 2 \fBmax\-response\-delay\fP \- مدت زمان بر حسب میلی‌ثانیه از زمان آخرین ارتباط موفق با شریک را مشخص می‌کند که پس از آن سرور فرض می‌کند ارتباط با شریک قطع شده است. این مدت زمان باید بزرگتر از \fBheartbeat\-delay\fP باشد؛ معمولاً باید مضربی از \fBheartbeat\-delay\fP باشد. هنگامی که سرور تشخیص دهد ارتباط قطع شده است، ممکن است به وضعیت \fBpartner\-down\fP تغییر حالت دهد (زمانی که \fBmax\-unacked\-clients\fP برابر 0 است) یا رویه تشخیص خرابی را با استفاده از مقادیر دو پارامتر زیر فعال کند. مقدار پیش‌فرض این پارامتر 60000 میلی‌ثانیه است. .IP \(bu 2 \fBmax\-ack\-delay\fP \- یکی از پارامترهایی است که تشخیص خرابی شریک را کنترل می‌کند. هنگامی که ارتباط با شریک قطع می‌شود، سرور مقادیر فیلد \(dqsecs\(dq (در DHCPv4) یا گزینه \(dqelapsed time\(dq (در DHCPv6) را که نشان‌دهنده مدت زمانی است که کلاینت DHCP سعی در برقراری ارتباط با سرور DHCP داشته است، بررسی می‌کند. این پارامتر حداکثر زمان بر حسب میلی‌ثانیه برای تلاش کلاینت جهت ارتباط با سرور DHCP را مشخص می‌کند که پس از آن، این سرور فرض می‌کند ارتباط کلاینت با سرور DHCP ناموفق بوده است (تأییدنشده یا \(dqunacked\(dq است). مقدار پیش‌فرض این پارامتر 10000 است. .IP \(bu 2 \fBmax\-unacked\-clients\fP \- مشخص می‌کند چه تعداد کلاینت \(dqunacked\(dq مجاز هستند (به \fBmax\-ack\-delay\fP مراجعه کنید) پیش از آنکه این سرور فرض کند شریک آفلاین است و به وضعیت \fBpartner\-down\fP تغییر حالت دهد. مقدار ویژه 0 برای این پارامتر مجاز است که سازوکار تشخیص خرابی را غیرفعال می‌کند. در این حالت، سروری که نتواند از طریق کانال کنترلی با شریک خود ارتباط برقرار کند، فرض می‌کند که سرور شریک از کار افتاده است و بلافاصله به وضعیت \fBpartner\-down\fP می‌رود. مقدار پیش‌فرض این پارامتر 10 است. .IP \(bu 2 \fBmax\-rejected\-lease\-updates\fP \- مشخص می‌کند چه تعداد به‌روزرسانی اجاره برای کلاینت‌های متمایز، به دلیل تعارض میان اجاره و پیکربندی یا وضعیت شریک، می‌تواند با شکست مواجه شود پیش از آنکه سرور به وضعیت \fBterminated\fP تغییر حالت دهد. تعارض می‌تواند نشانه‌ای از پیکربندی نادرست باشد؛ معمولاً تعداد کمی از اجاره‌های دارای تعارض قابل قبول هستند زیرا فقط بر تعداد کمی از دستگاه‌ها تأثیر می‌گذارند. با این حال، اگر تعارض‌ها برای دستگاه‌های زیادی رخ دهد (برای مثال، کل یک زیرشبکه)، سرویس HA غیرقابل‌اعتماد شده و باید خاتمه یابد، و مشکل باید به صورت دستی توسط یک مدیر سیستم برطرف شود. انتخاب بالاترین مقدار قابل قبول برای \fBmax\-rejected\-lease\-updates\fP بر عهده مدیر سیستم است. مقدار پیش‌فرض 10 است. مقدار ویژه 0 سرور را به گونه‌ای پیکربندی می‌کند که هرگز سرویس HA را به دلیل تعارض‌های اجاره خاتمه ندهد. اگر مقدار 1 باشد، سرور با رخ دادن اولین تعارض به وضعیت \fBterminated\fP تغییر حالت می‌دهد. این پارامتر به به‌روزرسانی‌های دارای تعارض اجاره که به سرورهای پشتیبان (backup) ارسال می‌شوند ارتباطی ندارد. .IP \(bu 2 \fBdelayed\-updates\-limit\fP \- حداکثر تعداد به‌روزرسانی‌های اجاره را مشخص می‌کند که می‌توانند در زمانی که سرور در وضعیت \fBcommunication\-recovery\fP قرار دارد در صف قرار گیرند. این پارامتر در Kea 1.9.4 معرفی شد. مقدار ویژه 0 سرور را به گونه‌ای پیکربندی می‌کند که هرگز به وضعیت \fBcommunication\-recovery\fP تغییر حالت ندهد و رفتار سرور مشابه نسخه‌های قبلی Kea خواهد بود، یعنی اگر سرور نتواند به شریک خود دسترسی پیدا کند، مستقیماً به وضعیت \fBpartner\-down\fP می‌رود. مقدار پیش‌فرض این پارامتر 100 است. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پارامتر \fBmax\-rejected\-lease\-updates\fP در Kea 2.3.1 معرفی شد. پیش از این، سرور بین شکست در به‌روزرسانی اجاره به دلیل کار نکردن شریک و شکست به دلیل تعارض (مانند مشکلات پیکربندی) تمایزی قائل نمی‌شد. در نتیجه، گاهی اوقات سرور حتی با وجود این که شریک به طور عادی کار می‌کرد اما فقط برخی اجاره‌ها مشکل داشتند، می‌توانست به وضعیت \fBpartner\-down\fP تغییر حالت دهد. تعارض‌ها دیگر نباید باعث چنین انتقالی شوند. با این حال، بسته به تنظیمات \fBmax\-rejected\-lease\-updates\fP، تعارض‌های بیش از حد می‌تواند به خاتمه سرویس High Availability منجر شود. در آن حالت، هر دو سرور به پاسخ دادن به پرس‌وجوهای DHCP ادامه می‌دهند اما دیگر به‌روزرسانی‌های اجاره را ارسال نمی‌کنند. .UNINDENT .UNINDENT .sp مقادیر \fBmax\-ack\-delay\fP و \fBmax\-unacked\-clients\fP باید با دقت و با در نظر گرفتن ویژگی‌های شبکه‌ای که سرورهای DHCP در آن فعالیت می‌کنند انتخاب شوند. سرور مورد نظر ممکن است بر اساس سیاست‌های مدیریتی به برخی از کلاینت‌های DHCP پاسخ ندهد، یا سرور ممکن است پرس‌وجوهای ناقص یا نامعتبر کلاینت‌ها را دور بیندازد (drop کند). بنابراین، انتخاب مقداری بسیار پایین برای پارامتر \fBmax\-unacked\-clients\fP ممکن است باعث انتقال به وضعیت \fBpartner\-down\fP شود حتی اگر شریک همچنان در حال کار باشد. از سوی دیگر، انتخاب مقداری بیش از حد بالا ممکن است باعث شود در صورتی که ترافیک DHCP در شبکه بسیار کم باشد (مانند هنگام شب)، هرگز انتقالی به وضعیت \fBpartner\-down\fP صورت نگیرد، زیرا تعداد کلاینت‌های متمایزی که سعی در ارتباط با سرور دارند می‌تواند کمتر از مقدار تنظیم‌شده برای \fBmax\-unacked\-clients\fP باشد. .sp در برخی موارد ممکن است غیرفعال کردن کامل سازوکار تشخیص خرابی سودمند باشد، به ویژه اگر سرورها بسیار نزدیک به یکدیگر مستقر باشند و تفکیک شبکه (network partitioning) نامحتمل باشد، به این معنی که عدم پاسخ به ضربان‌های قلب تنها زمانی امکان‌پذیر باشد که شریک آفلاین باشد. در چنین مواردی، \fBmax\-unacked\-clients\fP را روی 0 تنظیم کنید. .sp پارامتر \fBdelayed\-updates\-limit\fP برای فعال یا غیرفعال کردن رویه \fBcommunication\-recovery\fP استفاده می‌شود و رفتار سرور را در وضعیت \fBcommunication\-recovery\fP کنترل می‌کند. این پارامتر تنها می‌تواند در حالت \fBload\-balancing\fP استفاده شود. .sp اگر سروری در وضعیت \fBload\-balancing\fP دچار مشکلات ارتباطی با شریک خود شود (شکست در ضربان قلب یا به‌روزرسانی اجاره)، سرور به وضعیت \fBcommunication\-recovery\fP تغییر حالت می‌دهد. در این وضعیت، سرور به پاسخ دادن به پرس‌وجوهای DHCP ادامه می‌دهد اما به‌روزرسانی‌های اجاره را برای شریک ارسال نمی‌کند. به‌روزرسانی‌های اجاره تا زمان برقراری مجدد ارتباط در صف قرار می‌گیرند تا اطمینان حاصل شود که سرویس DHCP حتی در صورت قطع ارتباط میان شرکا، در دسترس باقی می‌ماند. ممکن است قطع ارتباط در دو حالت رخ دهد: زمانی که یکی از سرورها متوقف شده باشد، یا زمانی که هر دو سرور در دسترس باقی بمانند اما نتوانند با یکدیگر ارتباط برقرار کنند. در حالت اول، سرور برجا مانده رویه عادی را دنبال کرده و در نهایت باید به وضعیت \fBpartner\-down\fP منتقل شود. در حالت دوم، هر دو سرور باید به وضعیت \fBcommunication\-recovery\fP بروند و هرگز نباید به وضعیت \fBpartner\-down\fP تغییر حالت دهند (اگر \fBmax\-unacked\-clients\fP روی یک مقدار غیرصفر تنظیم شده باشد)، زیرا به تمام پرس‌وجوهای DHCP پاسخ داده می‌شود و هیچ‌یک از سرورها هیچ پرس‌وجوی DHCP تأییدنشده‌ای (unacked) را مشاهده نخواهد کرد. .sp انگیزه معرفی رویه \fBcommunication\-recovery\fP مشکلاتی بود که ممکن است هنگامی رخ دهد که دو سرور آنلاین بمانند اما ارتباط بین آن‌ها برای مدتی قطع شود. در نسخه‌های قبلی Kea، سرورهایی که با مشکلات ارتباطی مواجه می‌شدند پیش از تغییر حالت به وضعیت \fBpartner\-down\fP، بسته‌های DHCP را دور می‌انداختند (drop می‌کردند). در برخی موارد هر دوی آن‌ها به وضعیت \fBpartner\-down\fP منتقل می‌شدند که این امر به طور بالقوه می‌توانست منجر به تخصیص آدرس‌های IP یا پیشوندهای واگذارشده یکسان به کلاینت‌های مختلف توسط هر دو سرور شود. با ورود به وضعیت میانی \fBcommunication\-recovery\fP، از این مشکلات جلوگیری می‌شود. .sp اگر سروری در وضعیت \fBcommunication\-recovery\fP ارتباط با شریک خود را مجدداً برقرار کند، تلاش می‌کند تمام به‌روزرسانی‌های معوقه اجاره را که در صف قرار داده است برای شریک ارسال کند. این کار به صورت همگام (synchronous) انجام می‌شود و ممکن است زمان قابل توجهی طول بکشد تا سرور به وضعیت \fBload\-balancing\fP تغییر حالت دهد و عملکرد عادی خود را از سر بگیرد. حداکثر تعداد به‌روزرسانی‌های اجاره که می‌توانند در وضعیت \fBcommunication\-recovery\fP صف‌بندی شوند با \fBdelayed\-updates\-limit\fP کنترل می‌شود. اگر از این حد فراتر رود، سرور صف‌بندی به‌روزرسانی‌های اجاره را متوقف کرده و پس از برقراری مجدد اتصال با شریک، به جای ارسال به‌روزرسانی‌های معوقه اجاره پیش از تغییر وضعیت به \fBload\-balancing\fP، یک همگام‌سازی کامل پایگاه‌داده انجام می‌دهد. حتی در صورت فراتر رفتن از این حد، سرور در وضعیت \fBcommunication\-recovery\fP همچنان پاسخگوی کلاینت‌های DHCP باقی می‌ماند. .sp شاید ترجیح داده شود در مواردی که خطر قطع طولانی‌مدت ارتباط بین سرورها وجود دارد و پایگاه‌داده اجاره بزرگ است، مقادیر بالاتری برای \fBdelayed\-updates\-limit\fP تنظیم شود تا از همگام‌سازی پرهزینه پایگاه‌داده اجاره جلوگیری گردد. از سوی دیگر، اگر پایگاه‌داده اجاره کوچک باشد، زمان مورد نیاز برای ارسال به‌روزرسانی‌های معوقه اجاره ممکن است طولانی‌تر از همگام‌سازی پایگاه‌داده اجاره باشد. در چنین مواردی شاید بهتر باشد از مقدار کمتری، مثلاً 10 استفاده شود. مقدار پیش‌فرض 100 یک سازش معقول است و باید در اکثر استقرارها با ترافیک متوسط به خوبی کار کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این پارامتر جدید است و مقادیری از آن که در برخی محیط‌ها به خوبی کار می‌کنند ممکن است در محیط‌های دیگر کارایی خوبی نداشته باشند. بازخورد کاربران به ما در ایجاد مجموعه‌ای بهتر از توصیه‌های کاربردی کمک خواهد کرد. .UNINDENT .UNINDENT .sp پارامتر \fBpeers\fP شامل فهرستی از سرورهای درون این راه‌اندازی HA است. این پیکربندی باید حداقل شامل یک سرور primary (اولیه) و یک سرور secondary (ثانویه) باشد. همچنین می‌تواند شامل تعداد نامحدودی سرور backup (پشتیبان) باشد. در این مثال، یک سرور پشتیبان وجود دارد که به‌روزرسانی‌های اجاره را از سرورهای فعال دریافت می‌کند. .sp این‌ها پارامترهایی هستند که برای هر یک از همتایان در این فهرست مشخص می‌شوند: .INDENT 0.0.IP \(bu 2 \fBname\fP \- نام یکتایی را برای کارساز مشخص می‌کند. .IP \(bu 2 \fBurl\fP \- نشانی URL مورد استفاده برای برقراری ارتباط با این کارساز از طریق کانال کنترلی را مشخص می‌کند. سایر کارسازها از این URL برای ارسال دستورهای کنترلی به این کارساز استفاده می‌کنند. .IP \(bu 2 \fBbasic\-auth\-user\fP \- شناسه کاربر (user ID) را برای احراز هویت پایه‌ای HTTP مشخص می‌کند. اگر مشخص نشود یا به صورت یک رشته خالی تعیین شود، هیچ سرآیند احراز هویتی به تراکنش‌های HTTP افزوده نمی‌شود. این مقدار نباید شامل نویسه دونقطه (:) باشد. .IP \(bu 2 \fBbasic\-auth\-user\-file\fP \- جایگزینی برای \fBbasic\-auth\-user\fP است: به جای درج شناسه کاربر در فایل پیکربندی، این شناسه در سطر نخست فایل مشخص‌شده توسط این پارامتر تعیین می‌شود. .IP \(bu 2 \fBbasic\-auth\-password\fP \- گذرواژه را برای احراز هویت پایه‌ای HTTP مشخص می‌کند. هنگامی که شناسه کاربر مشخص نشده باشد یا خالی باشد، این پارامتر نادیده گرفته می‌شود. گذرواژه اختیاری است؛ اگر مشخص نشود، یک گذرواژه خالی استفاده می‌شود. .IP \(bu 2 \fBbasic\-auth\-password\-file\fP \- جایگزینی برای \fBbasic\-auth\-password\fP است: به جای درج گذرواژه در فایل پیکربندی، این گذرواژه در سطر نخست فایل مشخص‌شده توسط این پارامتر تعیین می‌شود. .IP \(bu 2 \fBrole\fP \- نقش کارساز را در ساختار HA مشخص می‌کند. نقش‌های زیر در پیکربندی \fBload\-balancing\fP پشتیبانی می‌شوند: \fBprimary\fP، \fBsecondary\fP و \fBbackup\fP\&. در ساختار \fBload\-balancing\fP باید دقیقاً یک کارساز primary و یک کارساز secondary وجود داشته باشد. .IP \(bu 2 \fBauto\-failover\fP \- مقداری بولی است که تعیین می‌کند آیا کارسازی که از کار افتادن همتای خود را تشخیص می‌دهد، باید به صورت خودکار شروع به پاسخ‌گویی به کلاینت‌های همتا کند یا خیر. مقدار پیش‌فرض این پارامتر \fBtrue\fP است\&. .UNINDENT .sp در پیکربندی نمونه ما در بالا، هر دو کارساز فعال می‌توانند اجاره‌ها (leases) را از زیرشبکه \(dq192.0.3.0/24\(dq تخصیص دهند. این زیرشبکه شامل دو استخر آدرس است: \(dq192.0.3.100 \- 192.0.3.150\(dq و \(dq192.0.3.200 \- 192.0.3.250\(dq که با استفاده از رده‌بندی کلاینت به دامنه‌های کارساز HA مرتبط شده‌اند. هنگامی که \fBserver1\fP یک پرس‌وجوی DHCP را پردازش می‌کند، از استخر نخست برای تخصیص اجاره استفاده می‌نماید. در مقابل، هنگامی که \fBserver2\fP یک پرس‌وجوی DHCP را پردازش می‌کند، از استخر دوم استفاده می‌کند. اگر هر یک از کارسازها در وضعیت \fBpartner\-down\fP باشد، دیگری می‌تواند اجاره‌ها را از هر دو استخر ارائه دهد؛ و استخری را انتخاب می‌کند که برای پرس‌وجوی دریافت‌شده مناسب باشد. به بیان دیگر، اگر پرس‌وجو در حالت عادی توسط \fBserver2\fP پردازش می‌شد اما این کارساز در دسترس نباشد، \fBserver1\fP اجاره را از استخر \(dq192.0.3.200 \- 192.0.3.250\(dq تخصیص می‌دهد. سوکت کنترلی HTTP مربوط به \fIserver3\(ga\fP نیازمند احراز هویت پایه‌ای HTTP است و شناسه کاربر \(dqfoo\(dq را با گذرواژه \(dq1234\(dq مجاز می‌شناسد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 طرح‌واره \fBurl\fP می‌تواند \fBhttp\fP یا \fBhttps\fP باشد، اما از نسخه 1.9.6 نرم‌افزار Kea طرح‌واره \fBhttps\fP نیازمند راه‌اندازی TLS است. بخش نام میزبان باید یک آدرس IPv4 یا یک آدرس IPv6 داخل کروشه باشد، مانند \fBhttp://[2001:db8::1]:8080\fP\&. نام‌ها پذیرفته نمی‌شوند. .UNINDENT .UNINDENT .SS توازن بار با رده‌بندی پیشرفته (Load Balancing With Advanced Classification) .sp در بخش پیشین، مثالی از پیکربندی \fBload\-balancing\fP با رده‌بندی کلاینت محدود به کلاس‌های \(dqHA_server1\(dq و \(dqHA_server2\(dq ارائه دادیم که به صورت پویا به پرس‌وجوهای DHCP دریافتی اختصاص می‌یابند. در بسیاری از موارد، HA در استقرارهایی مورد نیاز است که از پیش از رده‌بندی‌های کلاینت دیگری استفاده می‌کنند. .sp سیستمی را فرض کنید که دستگاه‌ها را بر اساس معیارهای رده‌بندی مشخص‌شده در فایل پیکربندی Kea به دو گروه دسته‌بندی می‌کند: \(dqphones\(dq و \(dqlaptops\(dq. به هر دو نوع دستگاه از استخرهای آدرس متفاوتی اجاره تخصیص داده می‌شود. اضافه کردن HA در حالت \fBload\-balancing\fP منجر به تقسیم بیشتر هر یک از این استخرها می‌شود، چرا که هر کارساز اجاره‌ها را برای برخی گوشی‌ها و برخی لپ‌تاپ‌ها تخصیص می‌دهد. این موضوع نیازمند آن است که هر یک از استخرهای موجود بین \(dqHA_server1\(dq و \(dqHA_server2\(dq تقسیم شوند، بنابراین در نهایت کلاس‌های زیر را خواهیم داشت: .INDENT 0.0 .IP \(bu 2 \(dqphones_server1\(dq .IP \(bu 2 \(dqlaptops_server1\(dq .IP \(bu 2 \(dqphones_server2\(dq .IP \(bu 2 \(dqlaptops_server2\(dq .UNINDENT .sp پیکربندی متناظر کارساز با استفاده از رده‌بندی پیشرفته (و عبارت \fBmember\fP) در زیر آورده شده است. به منظور اختصار، پیکربندی کتابخانه قلاب HA از این مثال حذف شده است. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqclient\-classes\(dq: [{ \(dqname\(dq: \(dqphones\(dq, \(dqtest\(dq: \(dqsubstring(option[60].hex,0,6) == \(aqAastra\(aq\(dq }, { \(dqname\(dq: \(dqlaptops\(dq, \(dqtest\(dq: \(dqnot member(\(aqphones\(aq)\(dq }, { \(dqname\(dq: \(dqphones_server1\(dq, \(dqtest\(dq: \(dqmember(\(aqphones\(aq) and member(\(aqHA_server1\(aq)\(dq }, { \(dqname\(dq: \(dqphones_server2\(dq, \(dqtest\(dq: \(dqmember(\(aqphones\(aq) and member(\(aqHA_server2\(aq)\(dq }, { \(dqname\(dq: \(dqlaptops_server1\(dq, \(dqtest\(dq: \(dqmember(\(aqlaptops\(aq) and member(\(aqHA_server1\(aq)\(dq }, { \(dqname\(dq: \(dqlaptops_server2\(dq, \(dqtest\(dq: \(dqmember(\(aqlaptops\(aq) and member(\(aqHA_server2\(aq)\(dq }], \(dqhooks\-libraries\(dq: [{ \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [{ }] } }], \(dqsubnet4\(dq: [{ \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.3.100 \- 192.0.3.125\(dq, \(dqclient\-classes\(dq: [ \(dqphones_server1\(dq ] }, { \(dqpool\(dq: \(dq192.0.3.126 \- 192.0.3.150\(dq, \(dqclient\-classes\(dq: [ \(dqlaptops_server1\(dq ] }, { \(dqpool\(dq: \(dq192.0.3.200 \- 192.0.3.225\(dq, \(dqclient\-classes\(dq: [ \(dqphones_server2\(dq ] }, { \(dqpool\(dq: \(dq192.0.3.226 \- 192.0.3.250\(dq, \(dqclient\-classes\(dq: [ \(dqlaptops_server2\(dq ] }], \(dqoption\-data\(dq: [{ \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.3.1\(dq }], \(dqrelay\(dq: { \(dqip\-address\(dq: \(dq10.1.2.3\(dq } }] } } .EE .UNINDENT .UNINDENT .sp پیکربندی ارائه‌شده در بالا، محدوده نشانی را به چهار استخر تقسیم می‌کند: دو استخر اختصاص‌یافته به \(dqHA_server1\(dq و دو استخر به \(dqHA_server2\(dq. هر کارساز می‌تواند اجاره‌ها را به هر دو گروه گوشی‌ها و لپ‌تاپ‌ها اختصاص دهد. به هر دو گروه دستگاه‌ها از استخرهای متفاوتی نشانی تخصیص داده می‌شود. کلاس‌های \(dqHA_server1\(dq و \(dqHA_server2\(dq توکار (built\-in) هستند (بخش «کلاس‌های توکار کلاینت» (Built\-in Client Classes) \%<#\:built-in-client-classes> را ببینید) و نیازی به تعریف آن‌ها نیست. آن‌ها به صورت پویا توسط کتابخانه قلاب HA بر اساس الگوریتم \fBload\-balancing\fP تخصیص می‌یابند. هنگامی که پرس‌وجو متعلق به ترکیب معینی از سایر کلاس‌ها باشد، مانند \(dqHA_server1\(dq و \(dqphones\(dq، عبارت‌های \(dqphones_*\(dq و \(dqlaptop_*\(dq به \fBtrue\fP ارزیابی می‌شوند. استخر نیز بر اساس نتیجه چنین ارزیابی‌ای انتخاب می‌گردد. .sp برای آگاهی از جزئیات چگونگی استفاده از عبارت \fBmember\fP و وابستگی‌های کلاس، به «رده‌بندی کلاینت» (Client Classification) \%<#\:classify> مراجعه کنید..SS پیکربندی Hot\-Standby .sp در ادامه نمونه‌ای از پیکربندی سرور اصلی (primary) در پیکربندی \fBhot\-standby\fP آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [{ \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [{ \(dqthis\-server\-name\(dq: \(dqserver1\(dq, \(dqmode\(dq: \(dqhot\-standby\(dq, \(dqheartbeat\-delay\(dq: 10000, \(dqmax\-response\-delay\(dq: 60000, \(dqmax\-ack\-delay\(dq: 5000, \(dqmax\-unacked\-clients\(dq: 5, \(dqmax\-rejected\-lease\-updates\(dq: 10, \(dqpeers\(dq: [{ \(dqname\(dq: \(dqserver1\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.33:8005/\(dq, \(dqrole\(dq: \(dqprimary\(dq, \(dqauto\-failover\(dq: true }, { \(dqname\(dq: \(dqserver2\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.66:8005/\(dq, \(dqrole\(dq: \(dqstandby\(dq, \(dqauto\-failover\(dq: true }, { \(dqname\(dq: \(dqserver3\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.99:8005/\(dq, \(dqbasic\-auth\-user\(dq: \(dqfoo\(dq, \(dqbasic\-auth\-password\(dq: \(dq1234\(dq, \(dqrole\(dq: \(dqbackup\(dq, \(dqauto\-failover\(dq: false }] }] } }], \(dqsubnet4\(dq: [{ \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.3.100 \- 192.0.3.250\(dq, \(dqclient\-classes\(dq: [ \(dqHA_server1\(dq ] }], \(dqoption\-data\(dq: [{ \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.3.1\(dq }], \(dqrelay\(dq: { \(dqip\-address\(dq: \(dq10.1.2.3\(dq } }] } .EE .UNINDENT .UNINDENT .sp این پیکربندی شباهت بسیاری به پیکربندی \fBload\-balancing\fP شرح داده شده در «پیکربندی Load\-Balancing» دارد، با چند تفاوت قابل توجه. .sp پارامتر \fBmode\fP اکنون روی \fBhot\-standby\fP تنظیم شده است که در آن تنها یک سرور به کلاینت‌های DHCP پاسخ می‌دهد. اگر سرور اصلی (primary) برخط باشد، به تمام درخواست‌های DHCP پاسخ می‌دهد. سرور \fBstandby\fP تنها در صورتی تمام ترافیک DHCP را بر عهده می‌گیرد که متوجه در دسترس نبودن سرور اصلی شود. .sp در این حالت، سرور فعال غیر اصلی (non\-primary) \fBstandby\fP نامیده می‌شود و نقش آن نیز همین است. .sp در نهایت، از آنجا که همواره تنها یک سرور به پرس‌وجوهای DHCP پاسخ می‌دهد، تنها یک محدوده \- \(dqHA_server1\(dq \- درون تعاریف pool استفاده می‌شود. در واقع، پارامتر \fBclient\-class\fP را می‌توان بدون مشکل از این پیکربندی حذف کرد، زیرا با توجه به اینکه سرورها به صورت هم‌زمان اجاره‌ها را تخصیص نمی‌دهند، هیچ تداخلی در تخصیص اجاره‌ها توسط سرورهای مختلف رخ نخواهد داد. پارامتر \fBclient\-class\fP در این مثال بیشتر به منظور نمایش و برجسته کردن تفاوت‌های بین حالت‌های عملیاتی \fBhot\-standby\fP و \fBload\-balancing\fP باقی مانده است. .SS پیکربندی Passive\-Backup .sp در ادامه نمونه‌ای از فایل پیکربندی برای سرور اصلی در پیکربندی \fBpassive\-backup\fP آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [{ \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [{ \(dqthis\-server\-name\(dq: \(dqserver1\(dq, \(dqmode\(dq: \(dqpassive\-backup\(dq, \(dqwait\-backup\-ack\(dq: false, \(dqpeers\(dq: [{ \(dqname\(dq: \(dqserver1\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.33:8005/\(dq, \(dqrole\(dq: \(dqprimary\(dq }, { \(dqname\(dq: \(dqserver2\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.66:8005/\(dq, \(dqrole\(dq: \(dqbackup\(dq }, { \(dqname\(dq: \(dqserver3\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.99:8005/\(dq, \(dqbasic\-auth\-user\(dq: \(dqfoo\(dq, \(dqbasic\-auth\-password\(dq: \(dq1234\(dq, \(dqrole\(dq: \(dqbackup\(dq }] }] } }], \(dqsubnet4\(dq: [{ \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.3.100 \- 192.0.3.250\(dq }], \(dqoption\-data\(dq: [{ \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.3.1\(dq }], \(dqrelay\(dq: { \(dqip\-address\(dq: \(dq10.1.2.3\(dq } }] } } .EE .UNINDENT .UNINDENT .sp پیکربندی‌های سه همتا (peer) گنجانده شده است: یکی برای سرور اصلی (primary) و دو تا برای سرورهای پشتیبان (backup). .sp بسیاری از پارامترهای موجود در مثال‌های پیکربندی \fBload\-balancing\fP و \fBhot\-standby\fP در حالت \fBpassive\-backup\fP کاربردی ندارند، بنابراین در اینجا مشخص نشده‌اند. به عنوان مثال: \fBheartbeat\-delay\fP، \fBmax\-unacked\-clients\fP، \fBmax\-rejected\-lease\-updates\fP و موارد دیگری که به سازوکار failover مربوط می‌شوند، نباید در حالت \fBpassive\-backup\fP مشخص شوند. .sp پارامتر \fBwait\-backup\-ack\fP یک پارامتر بولی (boolean) است که در مثال‌های قبلی وجود نداشت. مقدار پیش‌فرض آن \fBfalse\fP است و نباید در حالت‌های \fBload\-balancing\fP و \fBhot\-standby\fP تغییر داده شود. در حالت \fBpassive\-backup\fP این پارامتر می‌تواند روی \fBtrue\fP تنظیم شود، که باعث می‌شود سرور اصلی قبل از پاسخ دادن به کلاینت DHCP، منتظر دریافت تأییدیه‌ها (acknowledgments) برای به‌روزرسانی‌های اجاره از سرورهای پشتیبان باشد. این کار تضمین می‌کند که اجاره قبل از اعطا به کلاینت در تمام سرورها منتشر شده است، اما در صورت بروز مشکل ارتباطی با یکی از سرورهای پشتیبان، خطر از دست رفتن سرویس DHCP را به همراه دارد. این تنظیم همچنین به دلیل زمانی که سرور اصلی صرف انتظار برای تأییدیه‌ها می‌کند، تأخیر (latency) پاسخ DHCP را افزایش می‌دهد. توصیه می‌کنیم در صورتی که قابلیت اطمینان سرویس DHCP از یکپارچگی اطلاعات اجاره بین سرور اصلی و سرورهای پشتیبان مهم‌تر است، و در تمام مواردی که تأخیر سرویس DHCP باید حداقل باشد، تنظیم \fBwait\-backup\-ack\fP روی مقدار پیش‌فرض خود (\fBfalse\fP) باقی بماند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر، سرورهای فعال به‌روزرسانی‌های اجاره را برای ارسال به همتاها در صف‌های داخلی قرار می‌دهند (یک صف برای هر همتا/URL). در حالت \fBpassive\-backup\fP، سرورهای فعال منتظر تأیید به‌روزرسانی‌های اجاره نمی‌مانند؛ بنابراین در زمان‌های ترافیک سنگین کلاینت‌ها، این احتمال وجود دارد که تعداد به‌روزرسانی‌های اجاره در صف ارسال سریع‌تر از توان تحویل آنها انباشته شود. با کاهش ترافیک کلاینت، صف‌ها شروع به خالی شدن می‌کنند. از نسخه Kea 2.0.0 به بعد، سرورهای فعال اندازه این صف‌ها را پایش می‌کنند و اگر تشخیص دهند که صفی بیش از حد سریع رشد می‌کند، هشدارهای دوره‌ای صادر می‌کنند (به HTTP_CLIENT_QUEUE_SIZE_GROWING در Kea Messages Manual \%<#\:kea-messages> مراجعه کنید). این هشدارها به محض شروع کوچک شدن صف متوقف می‌شوند. این پیام‌ها به عنوان یک شاخص پیش‌آگاهی در نظر گرفته شده‌اند و مشاهده گاه‌به‌گاه آن‌ها در زمان بار ترافیکی سنگین لزوماً نشان‌دهنده مشکل نیست. با این حال، اگر این هشدارها به طور مداوم در شرایط بار ترافیکی معمول رخ دهند، به احتمال زیاد نشان‌دهنده عدم تطابق در توانایی‌های سرور و/یا پیکربندی آن هستند؛ این موضوع باید بررسی شود، زیرا اندازه صف‌ها در نهایت ممکن است توانایی سرور فعال را در پاسخ‌گویی به موقع به کلاینت‌ها مختل کند. .UNINDENT .UNINDENT.SS اشتراک‌گذاری اطلاعات اجاره (Lease Information Sharing) .sp یک سرور مجهز به HA با ارسال دستورات کنترلی مناسب، شریک فعال خود را از اجاره‌های تخصیص‌یافته یا تمدیدشده مطلع می‌سازد، و شریک نیز اطلاعات اجاره را در پایگاه داده خود به‌روزرسانی می‌کند. هنگامی که سرور برای نخستین بار راه‌اندازی می‌شود یا پس از یک خرابی بازیابی می‌گردد، پایگاه داده اجاره‌های خود را با شریکش همگام‌سازی می‌کند. این دو سازوکار، سازگاری اطلاعات اجاره میان سرورها را تضمین کرده و اجازه می‌دهند در صورت از دسترس خارج شدن یکی از سرورها، سرور دیگر کل بار ترافیک DHCP را مدیریت کند. .sp با این حال در برخی موارد، چنانچه تبادل اطلاعات درباره اجاره‌های تخصیص‌یافته با استفاده از سازوکار دیگری انجام گیرد، غیرفعال کردن به‌روزرسانی‌های اجاره و/یا همگام‌سازی پایگاه داده میان سرورهای فعال مطلوب خواهد بود. Kea از انواع مختلف پایگاه‌های داده که می‌توانند برای ذخیره اجاره‌ها استفاده شوند، از جمله MySQL و PostgreSQL پشتیبانی می‌کند. این پایگاه‌های داده شامل راهکارهای توکار برای تکثیر داده‌ها (data replication) هستند که اغلب توسط مدیران Kea جهت فراهم آوردن افزونگی (redundancy) به کار گرفته می‌شوند. .sp کتابخانه قلاب HA از چنین سناریوهایی با غیرفعال کردن به‌روزرسانی‌های اجاره از طریق کانال کنترلی و/یا همگام‌سازی پایگاه داده اجاره پشتیبانی می‌کند و سرور را بر سازوکار تکثیر پایگاه داده متکی می‌سازد. این رفتار توسط دو پارامتر بولی \fBsend\-lease\-updates\fP و \fBsync\-leases\fP کنترل می‌شود که مقادیر پیش‌فرض آن‌ها \fBtrue\fP است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [ { \(dqthis\-server\-name\(dq: \(dqserver1\(dq, \(dqmode\(dq: \(dqload\-balancing\(dq, \(dqsend\-lease\-updates\(dq: false, \(dqsync\-leases\(dq: false, \(dqpeers\(dq: [ { \(dqname\(dq: \(dqserver1\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.33:8005/\(dq, \(dqrole\(dq: \(dqprimary\(dq }, { \(dqname\(dq: \(dqserver2\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.66:8005/\(dq, \(dqrole\(dq: \(dqsecondary\(dq } ] } ] } } ], ... } .EE .UNINDENT .UNINDENT .sp در متداول‌ترین حالت استفاده، هر دو پارامتر روی یک مقدار یکسان تنظیم می‌شوند؛ یعنی در صورت استفاده از تکثیر پایگاه داده هر دو روی \fBfalse\fP و در غیر این صورت هر دو روی \fBtrue\fP قرار می‌گیرند. معرفی دو پارامتر مجزا برای کنترل به‌روزرسانی‌های اجاره و همگام‌سازی پایگاه داده اجاره، با هدف پشتیبانی از موارد استفاده خاص صورت گرفته است؛ به عنوان مثال، زمانی که همگام‌سازی با کپی کردن یک فایل اجاره انجام می‌شود (بنابراین \fBsync\-leases\fP روی \fBfalse\fP تنظیم می‌گردد)، اما به‌روزرسانی‌های اجاره باید طبق روال عادی ارسال شوند (\fBsend\-lease\-updates\fP روی \fBtrue\fP تنظیم می‌شود). لازم به ذکر است که Kea به‌صورت توکار از چنین مواردی پشتیبانی نمی‌کند، اما کاربران می‌توانند اسکریپت‌ها و ابزارهای اختصاصی خود را پیرامون Kea توسعه دهند تا چنین سازوکارهایی فراهم شود. پیکربندی کتابخانه قلاب HA طوری طراحی شده است که انعطاف‌پذیری مدیریت را به حداکثر برساند. .SS کنترل حد اندازه صفحه اجاره (Controlling Lease\-Page Size Limit) .sp یک سرور مجهز به HA، پس از توقف فعالیت یا پس از دریافت دستور \fBha\-sync\fP، همگام‌سازی پایگاه داده اجاره را آغاز می‌کند. سرور از دستورات \fBlease4\-get\-page\fP و \fBlease6\-get\-page\fP برای واکشی اجاره‌ها از سرور شریک خود استفاده می‌کند (پرس‌وجوهای اجاره). اندازه صفحه نتایج (حداکثر تعداد اجاره‌هایی که در یک پاسخ واحد به یکی از این دستورات بازگردانده می‌شوند) از طریق پیکربندی کتابخانه قلاب HA قابل کنترل است. افزایش اندازه صفحه، تعداد پرس‌وجوهای اجاره ارسالی به سرور شریک را کاهش می‌دهد، اما باعث می‌شود سرور شریک پاسخ‌های حجیم‌تری تولید کند که موجب افزایش زمان انتقال و همچنین افزایش مصرف حافظه و CPU در هر دو سرور می‌گردد. کاهش اندازه صفحه به کاهش مصرف منابع کمک می‌کند، اما نیازمند ارسال پرس‌وجوهای اجاره بیشتری جهت واکشی کل پایگاه داده اجاره است. .sp مقدار پیش‌فرض دستور \fBsync\-page\-limit\fP که اندازه صفحه را کنترل می‌کند 10000 است. این بدان معناست که اگر اندازه پایگاه داده برابر یا کمتر از 10000 خط باشد، کل پایگاه داده اجاره می‌تواند با یک دستور واحد واکشی شود. .SS مهلت‌های زمانی (Timeouts) .sp در استقرارهایی با تعداد زیادی کلاینت متصل به شبکه، همگام‌سازی پایگاه داده اجاره پس از خرابی یک سرور ممکن است عملیاتی زمان‌بر باشد. سرور همگام‌ساز باید تمام اجاره‌ها را از شریک خود جمع‌آوری کند که پاسخی بزرگ را از طریق رابط RESTful به همراه دارد. سرور، اجاره‌ها را با استفاده از سازوکار صفحه‌بندی توضیح داده شده در «کنترل حد اندازه صفحه اجاره» دریافت می‌کند. پیش از واکشی صفحه اجاره‌ها، سرور همگام‌ساز دستور \fBdhcp\-disable\fP \%<#\:std-isccmd-dhcp-disable> را برای غیرفعال کردن سرویس DHCP در سرور شریک ارسال می‌کند. اگر این سرویس از قبل غیرفعال باشد، این دستور مهلت زمانی غیرفعال بودن سرویس DHCP را بازنشانی می‌کند که به‌طور پیش‌فرض روی 60 ثانیه تنظیم شده است. اگر واکشی یک صفحه واحد از اجاره‌ها بیش از زمان تعیین‌شده طول بکشد، سرور شریک فرض می‌کند که سرور همگام‌ساز از کار افتاده است و سرویس DHCP خود را از سر می‌گیرد. اتصال سرور همگام‌ساز با شریک خود نیز توسط مهلت زمانی محافظت می‌شود. اگر همگام‌سازی یک صفحه از اجاره‌ها بیشتر از زمان مشخص‌شده به طول بینجامد، سرور همگام‌ساز اتصال را قطع کرده و همگام‌سازی با شکست مواجه می‌شود. هر دو مقدار مهلت زمانی توسط یک پارامتر پیکربندی واحد به نام \fBsync\-timeout\fP کنترل می‌شوند. قطعه‌پیکربندی زیر نحوه اصلاح مهلت زمانی برای فعال‌سازی مجدد خودکار سرویس DHCP در سرور شریک و نحوه افزایش مهلت زمانی برای واکشی یک صفحه از اجاره‌ها از 60 ثانیه به 90 ثانیه را نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [ { \(dqthis\-server\-name\(dq: \(dqserver1\(dq, \(dqmode\(dq: \(dqload\-balancing\(dq, \(dqsync\-timeout\(dq: 90000, \(dqpeers\(dq: [ { \(dqname\(dq: \(dqserver1\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.33:8005/\(dq, \(dqrole\(dq: \(dqprimary\(dq }, { \(dqname\(dq: \(dqserver2\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.66:8005/\(dq, \(dqrole\(dq: \(dqsecondary\(dq } ] } ] } } ], ... } .EE .UNINDENT .UNINDENT .sp توجه به این نکته مهم است که افزایش این مقدار \fBsync\-timeout\fP ممکن است گاهی اوقات برای جلوگیری از بروز مشکلات مهلت زمانی در حین همگام‌سازی پایگاه داده اجاره کافی نباشد. سرور DHCP همچنین اتصال از سمت همتا را برای بررسی مهلت‌های زمانی زیر نظر می‌گیرد. این مهلت‌های زمانی در حال حاضر از طریق پیکربندی قابل تغییر نیستند؛ افزایش این مهلت‌های زمانی تنها با اصلاح آن‌ها در کد Kea و کامپایل مجدد سرور امکان‌پذیر است. ثابت‌های مربوطه در سورس Kea در مسیر \fBsrc/lib/config/timeouts.h\fP\& قرار دارند..SS توقف موقت ماشین وضعیت HA .sp ماشین وضعیت \fBhigh\-availability\fP شامل وضعیت‌های مختلف بسیاری است که با جزئیات در Server States شرح داده شده‌اند\&. کارساز هنگامی وارد هر وضعیت می‌شود که شرایط خاصی برآورده شوند، که اغلب اوقات وضعیت کارساز همکار را نیز در نظر می‌گیرد. در برخی وضعیت‌ها کارساز اقدامات خاصی انجام می‌دهد؛ برای مثال، همگام‌سازی پایگاه‌داده واگذاری‌ها در وضعیت \fBsyncing\fP، یا پاسخ‌گویی به پرس‌وجوهای DHCP مطابق با حالت عملیاتی پیکربندی‌شده در وضعیت‌های \fBload\-balancing\fP و \fBhot\-standby\fP. .sp به‌طور پیش‌فرض، گذارها بین وضعیت‌ها به‌صورت خودکار انجام می‌شوند و مدیر کارساز کنترل مستقیمی بر زمان وقوع گذارها ندارد؛ در بیشتر موارد، مدیر به چنین کنترلی نیاز ندارد. با این حال، در برخی شرایط ممکن است مدیر بخواهد ماشین وضعیت HA را در یک وضعیت مشخص \(dqمتوقف\(dq کند تا پیش از گذار کارساز به وضعیت بعدی، اقدامات مدیریتی بیشتری را انجام دهد. .sp خرابی کارسازی را در نظر بگیرید که منجر به از دست رفتن کل پایگاه‌داده واگذاری‌ها می‌شود. به‌طور معمول، کارساز با استعلام واگذاری‌ها از کارساز همکار به هنگام ورود به وضعیت \fBsyncing\fP، پایگاه‌داده واگذاری‌های خود را بازسازی می‌کند، اما این احتمال وجود دارد که همکار نیز دچار خرابی شده و فاقد اطلاعات واگذاری باشد. در این حالت، ممکن است نیاز باشد پایگاه‌داده واگذاری‌ها در هر دو کارساز از یک منبع خارجی، مانند یک کارساز پشتیبان، بازسازی شود. اگر قرار است پایگاه‌داده واگذاری‌ها از طریق RESTful API بازسازی شود، کارسازها باید در وضعیت اولیه، یعنی \fBwaiting\fP، راه‌اندازی شوند و در حین افزودن واگذاری‌ها در همین وضعیت باقی بمانند. به‌ویژه، کارسازها نباید برای همگام‌سازی پایگاه‌داده واگذاری‌های خود تلاشی کنند و نباید سرویس‌دهی به کلاینت‌های DHCP را آغاز نمایند. .sp کتابخانه قلاب HA پارامترهای پیکربندی و دستوری را برای کنترل توقف موقت و ازسرگیری ماشین وضعیت HA فراهم می‌کند. پیکربندی زیر باعث می‌شود که ماشین وضعیت HA پس از راه‌اندازی کارساز در وضعیت \fBwaiting\fP متوقف شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [ { \(dqthis\-server\-name\(dq: \(dqserver1\(dq, \(dqmode\(dq: \(dqload\-balancing\(dq, \(dqpeers\(dq: [ { \(dqname\(dq: \(dqserver1\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.33:8005/\(dq, \(dqrole\(dq: \(dqprimary\(dq }, { \(dqname\(dq: \(dqserver2\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.66:8005/\(dq, \(dqrole\(dq: \(dqsecondary\(dq } ], \(dqstate\-machine\(dq: { \(dqstates\(dq: [ { \(dqstate\(dq: \(dqwaiting\(dq, \(dqpause\(dq: \(dqonce\(dq } ] } } ] } } ], ... } .EE .UNINDENT .UNINDENT .sp مقدار \fBonce\fP برای پارامتر \fBpause\fP نشان می‌دهد که ماشین وضعیت باید در نخستین گذار به وضعیت \fBwaiting\fP متوقف شود؛ گذارهای بعدی به این وضعیت موجب توقف ماشین وضعیت نخواهند شد. دو مقدار پشتیبانی‌شده دیگر برای پارامتر \fBpause\fP مقادیر \fBalways\fP و \fBnever\fP هستند\&. مقدار اخیر مقدار پیش‌فرض برای هر وضعیت است که به کارساز دستور می‌دهد هرگز ماشین وضعیت را متوقف نکند. .sp به منظور خروج ماشین وضعیت از حالت توقف، باید دستور \fBha\-continue\fP به کارساز متوقف‌شده ارسال شود. این دستور هیچ آرگومانی نمی‌پذیرد. برای جزئیات درباره دستورهای ویژه \fBlibdhcp_ha.so\fP به Control Commands for High Availability مراجعه کنید\&. .sp پیکربندی ماشین وضعیت برای توقف در بیش از یک وضعیت امکان‌پذیر است. پیکربندی زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [ { \(dqthis\-server\-name\(dq: \(dqserver1\(dq, \(dqmode\(dq: \(dqload\-balancing\(dq, \(dqpeers\(dq: [ { \(dqname\(dq: \(dqserver1\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.33:8005/\(dq, \(dqrole\(dq: \(dqprimary\(dq }, { \(dqname\(dq: \(dqserver2\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.66:8005/\(dq, \(dqrole\(dq: \(dqsecondary\(dq } ], \(dqstate\-machine\(dq: { \(dqstates\(dq: [ { \(dqstate\(dq: \(dqready\(dq, \(dqpause\(dq: \(dqalways\(dq }, { \(dqstate\(dq: \(dqpartner\-down\(dq, \(dqpause\(dq: \(dqonce\(dq } ] } } ] } } ], ... } .EE .UNINDENT .UNINDENT .sp این پیکربندی به کارساز دستور می‌دهد که هر بار پس از گذار به وضعیت \fBready\fP و همچنین در نخستین گذار به وضعیت \fBpartner\-down\fP، ماشین وضعیت را متوقف کند. .sp برای مشاهده فهرست کامل وضعیت‌های کارساز به Server States مراجعه کنید. ماشین وضعیت را می‌توان در هر یک از وضعیت‌های پشتیبانی‌شده متوقف کرد؛ با این حال، متوقف کردن در وضعیت‌های \fBbackup\fP یا \fBterminated\fP کاربردی ندارد، زیرا کارساز در هر صورت هرگز از این وضعیت‌ها خارج نمی‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در وضعیت \fBsyncing\fP کارساز پیش از تلاش برای همگام‌سازی پایگاه‌داده واگذاری‌ها با کارساز همکار متوقف می‌شود. برای متوقف کردن ماشین وضعیت پس از همگام‌سازی پایگاه‌داده واگذاری‌ها، به جای آن از وضعیت \fBready\fP استفاده کنید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 وضعیت ماشین وضعیت HA به وضعیت کارساز همکار وابسته است. بنابراین، متوقف کردن ماشین وضعیت یک کارساز ممکن است بر عملکرد کارساز همکار تأثیر بگذارد. برای مثال: اگر کارساز اصلی در وضعیت \fBwaiting\fP متوقف شود، کارساز همکار نیز تا زمانی که ماشین وضعیت کارساز اصلی از سر گرفته نشده و آن کارساز به وضعیت \fBready\fP گذار نکند، در وضعیت \fBwaiting\fP باقی خواهد ماند. .UNINDENT .UNINDENT.SS پیکربندی چندنخی (HA+MT) .sp امکان پیکربندی HA برای استفاده از ارتباط مستقیم چندنخی بین همتایان (peers) وجود دارد. ما این حالت را HA+MT می‌نامیم. با فعال بودن HA+MT، هر همتا شنونده (کارساز) HTTP اختصاصی و داخلی خود را اجرا می‌کند که مستقیماً دستورها را دریافت کرده و به آن‌ها پاسخ می‌دهد؛ بنابراین ترتیبی بودن پردازش دستورها از جمله برای پروتکل HA میان همتایان حذف می‌شود. افزون بر این، هر دو جزء شنونده و کلاینت از چندنخی برای پشتیبانی از چندین اتصال هم‌روند میان همتایان استفاده می‌کنند. با حذف بار اضافی از کانال کنترلی و اجرای موازی مبادلات چندگانه دستورها، توان عملیاتی HA بین همتایان در بیشتر شرایط در مقایسه با نسخه‌های پیشین Kea به طور چشمگیری بهبود می‌یابد. .sp پارامترهای زیر برای پشتیبانی از عملکرد HA+MT به پیکربندی HA افزوده شده‌اند: .INDENT 0.0 .IP \(bu 2 \fBenable\-multi\-threading\fP \- ارتباط چندنخی همتایان HA‏ (HA+MT) را فعال یا غیرفعال می‌کند. برای عملکرد HA+MT، قابلیت چندنخی در هسته Kea باید فعال باشد. هنگامی که روی \fBfalse\fP باشد، کارساز برای ارتباط با همتای خود به یک سوکت کنترلی HTTP متکی خواهد بود و از پردازش کلاینت HTTP تک‌نخی استفاده می‌کند. مقدار پیش‌فرض \fBtrue\fP است\&. .IP \(bu 2 \fBhttp\-dedicated\-listener\fP \- ایجاد یک شنونده HTTP داخلی و اختصاصی را که کارساز از طریق آن پیام‌های HA را از همتایان خود دریافت می‌کند، فعال یا غیرفعال می‌کند. شنونده داخلی جایگزین ترافیک سوکت کنترلی می‌شود و به همتایان اجازه می‌دهد دستورهای HA خود را مستقیماً برای یکدیگر ارسال کنند. شنونده روی \fBurl\fP متعلق به همتا به شنود می‌پردازد\&. در صورت تنظیم روی \fBfalse\fP، کارساز به سوکت کنترلی HTTP متکی می‌شود. این پارامتر عمدتاً برای انعطاف‌پذیری و آزمون ارائه شده است؛ اجرای HA+MT بدون فعال بودن شنونده‌های اختصاصی، توان عملیاتی HA را به شدت محدود خواهد کرد. مقدار پیش‌فرض \fBtrue\fP است\&. .IP \(bu 2 \fBhttp\-listener\-threads\fP \- حداکثر تعداد نخ‌هایی را که شنونده اختصاصی باید استفاده کند مشخص می‌کند. مقدار \fB0\fP به کارساز دستور می‌دهد از همان تعداد نخ‌هایی استفاده کند که هسته Kea برای چندنخی DHCP به کار می‌برد. مقدار پیش‌فرض \fB0\fP است\&. .IP \(bu 2 \fBhttp\-client\-threads\fP \- حداکثر تعداد نخ‌هایی را که باید برای ارسال پیام‌های HA به همتایان استفاده شود، مشخص می‌کند. مقدار \fB0\fP به کارساز دستور می‌دهد از همان تعداد نخ‌هایی استفاده کند که هسته Kea برای چندنخی DHCP به کار می‌برد. مقدار پیش‌فرض \fB0\fP است\&. .UNINDENT .sp این پارامترها همان‌طور که در زیر نشان داده شده است، در قالب یک عنصر نگاشت با نام \fBmulti\-threading\fP با یکدیگر گروه‌بندی می‌شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { } }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [ { \(dqthis\-server\-name\(dq: \(dqserver1\(dq, \(dqmulti\-threading\(dq: { \(dqenable\-multi\-threading\(dq: true, \(dqhttp\-dedicated\-listener\(dq: true, \(dqhttp\-listener\-threads\(dq: 4, \(dqhttp\-client\-threads\(dq: 4 }, \(dqpeers\(dq: [ // This is the configuration of this server instance. { \(dqname\(dq: \(dqserver1\(dq, // This specifies the URL of our server instance. // Since the HA+MT uses a direct connection, the // DHCPv4 server open its own socket. Note that it // must be different than the one used by the control // socket (typically 8000). In this example, 8005 is used. \(dqurl\(dq: \(dqhttp://192.0.2.1:8005/\(dq, // This server is primary. The other one must be // secondary. \(dqrole\(dq: \(dqprimary\(dq }, // This is the configuration of our HA peer. { \(dqname\(dq: \(dqserver2\(dq, // This specifies the URL of our server instance. // Since the HA+MT uses a direct connection, the // DHCPv4 server open its own socket. Note that it // must be different than the one used by the control // socket (typically 8000). In this example, 8005 is used. \(dqurl\(dq: \(dqhttp://192.0.2.2:8005/\(dq, // The partner is a secondary. This server is a // primary as specified in the previous \(dqpeers\(dq // entry and in \(dqthis\-server\-name\(dq before that. \(dqrole\(dq: \(dqsecondary\(dq }, ... ], ... }, ... ] } }, ... ], ... } .EE .UNINDENT .UNINDENT .sp در مثال بالا، HA+MT با چهار نخ برای شنونده و چهار نخ برای کلاینت فعال شده است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پیکربندی درست پورت‌ها امری حیاتی است. یک اشتباه رایج، پیکربندی سوکت کنترلی برای شنود روی پورت 8000 و همچنین تنظیم شنونده‌های اختصاصی روی پورت 8000 است. در چنین پیکربندی، ارتباط همچنان از طریق سوکت کنترلی (در حالت تک‌نخی) کار خواهد کرد، اما کُند خواهد بود و کارساز DHCP در مقیدسازی سوکت‌ها (در حالت چندنخی) با شکست مواجه خواهد شد. مدیران سیستم باید اطمینان حاصل کنند که شنونده‌های اختصاصی از پورت دیگری استفاده می‌کنند (8001 یک جایگزین پیشنهادی است)؛ در صورتی که پورت‌ها نادرست پیکربندی شوند یا از پورت‌های اختصاص‌یافته به سوکت کنترلی استفاده شود، گلوگاه‌های کارایی ناشی از حالت تک‌نخی کارساز DHCP یا ماهیت ترتیبی سوکت کنترلی کارسازهای DHCP، هرگونه بهبود کارایی حاصل از HA+MT را بی‌اثر خواهند کرد. .UNINDENT .UNINDENT.SS محدودیت بسته‌های پارک‌شده (Parked\-Packet Limit) .sp برای آشنایی مقدماتی با پارک کردن بسته‌ها، به «محدودیت بسته‌های پارک‌شده» مراجعه کنید. .sp کتابخانه قلاب HA از این سازوکار استفاده می‌کند. هنگامی که یک سرور HA نیاز دارد یک به‌روزرسانی اجاره را برای همتایان خود ارسال کند تا آن‌ها را از تغییرات اجاره مطلع سازد، پاسخ به کلاینت را تا زمانی که همتایان به‌روزرسانی اجاره را تایید کنند، پارک می‌کند. در آن هنگام، سرور پاسخ را از حالت پارک خارج کرده و آن را به کلاینت ارسال می‌کند. این موضوع برای پرس‌وجوهای کلاینت که منجر به تغییرات اجاره می‌شوند اعمال می‌گردد، مانند DHCPREQUEST برای DHCPv4 و Request، Renew و Rebind برای DHCPv6. این سازوکار شامل DHCPDISCOVER (در نسخه ۴) یا Solicit (در نسخه ۶) نمی‌شود. .SS خاموش‌سازی کنترل‌شده و نگهداری سرورهای DHCP .sp داشتن یک جفت سرور ارائه‌دهنده دسترس‌پذیری بالا (High Availability) امکان خاموش‌سازی کنترل‌شده و نگهداری آن سرورها را بدون اختلال در سرویس DHCP فراهم می‌کند. برای مثال، مدیر سیستم می‌تواند یکی از سرورها را ارتقا دهد در حالی که سرور دیگر همچنان به پرس‌وجوهای DHCP پاسخ می‌دهد. هنگامی که سرور اول ارتقا یافت و دوباره برخط شد، می‌توان ارتقا را برای سرور دوم انجام داد. .sp مشکل متداولی که در نسخه‌های اولیه کتابخانه قلاب High Availability گزارش شده بود این بود که مدیر سیستم کنترل مستقیمی بر وضعیت سرور DHCP نداشت. خاموش کردن یکی از سرورها برای نگهداری لزوماً باعث نمی‌شد که سرور دیگر شروع به پاسخ دادن به تمام پرس‌وجوهای DHCP کند؛ زیرا الگوریتم تشخیص خرابی توضیح‌داده‌شده در «انتقال حوزه در حالت از کار افتادن شریک» نیازمند این است که شریک برای یک بازه زمانی پیکربندی‌شده پاسخ ندهد و بسته به پیکربندی، ممکن است همچنین نیاز داشته باشد که به تعدادی از درخواست‌های DHCP برای بازه زمانی مشخصی پاسخ داده نشود. با این حال، روند نگهداری ایجاب می‌کند که مدیر سیستم بتواند به یکی از سرورها دستور دهد که بلافاصله سرویس‌دهی به تمام کلاینت‌های DHCP را آغاز کند و سرور دیگر بلافاصله سرویس‌دهی به کلاینت‌های DHCP را متوقف کند تا بتوان آن را با ایمنی خاموش کرد. .sp قابلیت نگهداری در کتابخانه قلاب High Availability به این وضعیت رسیدگی می‌کند. دستور \fBha\-maintenance\-start\fP به مدیر سیستم امکان می‌دهد جفت سرورهای فعال را در وضعیتی قرار دهد که در آن یکی از آن‌ها به تمام پرس‌وجوهای DHCP پاسخ می‌دهد و دیگری منتظر خاموش شدن است. .sp فرض کنید راه‌اندازی HA شامل دو سرور فعال \fBserver1\fP و \fBserver2\fP است و سرور دوم باید برای نگهداری خاموش شود. مدیر سیستم می‌تواند دستور \fBha\-maintenance\-start\fP را به \fBserver1\fP ارسال کند، زیرا این سروری است که قرار است ترافیک DHCP را در زمان آفلاین بودن دیگری مدیریت کند. اگر وضعیت \fBserver1\fP یا وضعیت شریک آن اجازه خاموش‌سازی برای نگهداری را ندهد، \fBserver1\fP با یک خطا پاسخ می‌دهد؛ برای مثال، اگر نگهداری برای سرور پشتیبان پشتیبانی نشود یا سرور در وضعیت \fBterminated\fP باشد. همچنین، اگر درخواست \fBha\-maintenance\-start\fP پیش‌تر به سرور دیگر ارسال شده باشد، خطایی بازگردانده می‌شود. .sp با دریافت دستور \fBha\-maintenance\-start\fP، \fBserver1\fP دستور \fBha\-maintenance\-notify\fP را به \fBserver2\fP ارسال می‌کند تا آن را در وضعیت \fBin\-maintenance\fP قرار دهد. اگر \fBserver2\fP تایید کند، \fBserver1\fP به وضعیت \fBpartner\-in\-maintenance\fP تغییر وضعیت می‌دهد. این شبیه به وضعیت \fBpartner\-down\fP است، با این تفاوت که در وضعیت \fBpartner\-in\-maintenance\fP سرور \fBserver1\fP تا زمانی که مدیر سیستم \fBserver2\fP را خاموش کند، به ارسال به‌روزرسانی‌های اجاره به \fBserver2\fP ادامه می‌دهد\&. اکنون \fBserver1\fP به تمام پرس‌وجوهای DHCP پاسخ می‌دهد. .sp اکنون مدیر سیستم می‌تواند با ایمنی \fBserver2\fP را در وضعیت \fBin\-maintenance\fP خاموش کرده و اقدامات لازم برای نگهداری را انجام دهد. در حالی که \fBserver2\fP آفلاین است، بدیهی است که \fBserver1\fP قادر به برقراری ارتباط با شریک خود نخواهد بود، بنابراین بلافاصله به وضعیت \fBpartner\-down\fP منتقل می‌شود؛ این سرور همچنان به تمام پرس‌وجوهای DHCP پاسخ خواهد داد، اما دیگر به‌روزرسانی‌های اجاره را به \fBserver2\fP ارسال نمی‌کند\&. راه‌اندازی مجدد \fBserver2\fP پس از نگهداری، مذاکره عادی وضعیت، همگام‌سازی پایگاه‌داده اجاره‌ها و در نهایت گذار به وضعیت عادی \fBload\-balancing\fP یا \fBhot\-standby\fP را آغاز می‌کند. سپس می‌توان نگهداری را پس از ارسال دستور \fBha\-maintenance\-start\fP به \fBserver2\fP، روی \fBserver1\fP انجام داد\&. .sp اگر دستور \fBha\-maintenance\-start\fP به سرور ارسال شده باشد و سرور به وضعیت \fBpartner\-in\-maintenance\fP رفته باشد، بازگرداندن هر دوی آن و شریکش به وضعیت‌های قبلی‌شان به منظور از سرگیری عملکرد عادی جفت HA امکان‌پذیر است. این کار با ارسال دستور \fBha\-maintenance\-cancel\fP به سروری که در وضعیت \fBpartner\-in\-maintenance\fP قرار دارد انجام می‌شود. با این حال، اگر سرور در نتیجه تشخیص آفلاین بودن شریک، قبلاً به وضعیت \fBpartner\-down\fP تغییر وضعیت داده باشد، لغو نگهداری دیگر امکان‌پذیر نیست. در این حالت، لازم است سرور دیگر را دوباره راه‌اندازی کرده و اجازه داد فرایند عادی مذاکره وضعیت خود را تکمیل کند. .sp اگر سرور رابطه‌های متعددی با شرکای مختلف داشته باشد، دستور \fBha\-maintenance\-start\fP تلاش می‌کند تا تمام این رابطه‌ها را با ارسال \fBha\-maintenance\-notify\fP به همه سرورهای شریک، به وضعیت \fBpartner\-in\-maintenance\fP انتقال دهد. اگر این مرحله برای هر یک از سرورها با شکست مواجه شود، خطایی بازگردانده می‌شود. در صورت وقوع این رویداد، می‌توان از دستور \fBha\-maintenance\-cancel\fP برای از سرگیری عملکردهای عادی و رفع مشکل استفاده کرد. .SS دستورهای کنترلی برای دسترس‌پذیری بالا (High Availability) .sp اگرچه کتابخانه قلاب HA برای برطرف کردن خودکار مشکلات مربوط به قطعی سرویس DHCP از طریق هدایت مجدد ترافیک DHCP به سرور فعال باقی‌مانده و همگام‌سازی پایگاه‌داده اجاره‌ها در صورت نیاز طراحی شده است، ممکن است برای مدیر سیستم کنترل بیشتر بر رفتار هر دو سرور مفید باشد. به‌ویژه، ممکن است راه‌اندازی همگام‌سازی پایگاه‌داده اجاره‌ها بر حسب تقاضا، یا تنظیم دستی حوزه‌های در حال سرویس‌دهی HA سودمند باشد. .sp در صورتی که هر دو سرور فعال از کار بیفتند، گاهی اوقات می‌توان از سرور پشتیبان برای رسیدگی به ترافیک DHCP استفاده کرد. سرور پشتیبان عمل جایگزینی خودکار (failover) را انجام نمی‌دهد؛ بنابراین، برای استفاده از سرور پشتیبان جهت پاسخ‌گویی به پرس‌وجوهای DHCP، مدیر سرور باید این تابع را به صورت دستی فعال کند. .sp بخش‌های زیر دستورهای پشتیبانی‌شده توسط کتابخانه قلاب HA را که در دسترس مدیر سیستم هستند، شرح می‌دهند. .SS دستور \fBha\-sync\fP .sp دستور \fBha\-sync\fP به سرور فرمان می‌دهد که پایگاه‌داده محلی اجاره‌های خود را با همتای انتخابی همگام کند. سرور تمام اجاره‌ها را از همتا واکشی کرده و هرگونه اجاره محلی ذخیره‌شده را که قدیمی‌تر از موارد واکشی‌شده باشد، به‌روزرسانی می‌کند. همچنین در صورتی که هر یک از موارد واکشی‌شده در پایگاه‌داده محلی وجود نداشته باشد، اجاره‌های جدید ایجاد می‌کند. تمام اجاره‌هایی که توسط همتا بازگردانده نشده‌اند اما در پایگاه‌داده محلی موجود هستند، حفظ می‌شوند. همگام‌سازی پایگاه‌داده یک‌طرفه است؛ تنها پایگاه‌داده روی سروری که دستور به آن ارسال شده است به‌روزرسانی می‌شود. برای همگام‌سازی پایگاه‌داده همتا، باید یک دستور \fBha\-sync\fP جداگانه به آن همتا فرستاده شود. .sp همگام‌سازی پایگاه‌داده ممکن است برای هر دو نوع سرور فعال و پشتیبان اجرا شود. دستور \fBha\-sync\fP دارای ساختار زیر است (در یک مثال برای DHCPv4): .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqha\-sync\(dq, \(dqservice\(dq: [ \(dqdhcp4 \(dq], \(dqarguments\(dq: { \(dqserver\-name\(dq: \(dqserver2\(dq, \(dqmax\-period\(dq: 60 } } .EE .UNINDENT .UNINDENT .sp هنگامی که سرور این دستور را دریافت می‌کند، ابتدا سرویس DHCP سروری را که قرار است اجاره‌ها از آن واکشی شوند، با ارسال دستور \fBdhcp\-disable\fP \%<#\:std-isccmd-dhcp-disable> به آن سرور، غیرفعال می‌سازد. پارامتر \fBmax\-period\fP حداکثر مدت زمانی را (به ثانیه) مشخص می‌کند که سرویس DHCP باید غیرفعال باشد. اگر سرویس DHCP با موفقیت غیرفعال شود، سرور همگام‌کننده با صدور یک یا چند دستور \fBlease4\-get\-page\fP اجاره‌ها را از سرور دوردست واکشی می‌کند. هنگامی که همگام‌سازی پایگاه‌داده اجاره‌ها کامل شد، سرور همگام‌کننده دستور \fBdhcp\-enable\fP \%<#\:std-isccmd-dhcp-enable> را به همتا ارسال می‌کند تا سرویس DHCP آن را دوباره فعال کند. .sp مقدار \fBmax\-period\fP باید به اندازه کافی طولانی باشد تا تضمین شود که پیش از تکمیل همگام‌سازی به پایان نمی‌رسد. در غیر این صورت، سرور DHCP در حالی که همگام‌سازی هنوز در جریان است، عملکرد DHCP خود را به طور خودکار فعال خواهد کرد. اگر سرور DHCP متعاقباً در طول همگام‌سازی هرگونه اجاره‌ای را تخصیص دهد، آن اجاره‌های جدید (یا به‌روزرسانی‌شده) توسط سرور همگام‌کننده واکشی نخواهند شد که این امر منجر به ناسازگاری پایگاه‌داده می‌شود..SS دستور \fBha\-scopes\fP .sp این دستور به مدیر سیستم اجازه می‌دهد حوزه‌های (scopes) HA در حال سرویس‌دهی را تغییر دهد. این دستور هنگام بازیابی از خرابی یا هنگام انجام عملیات نگهداری می‌تواند مفید باشد. برای آگاهی از این که کدام حوزه‌ها برای حالت‌های عملیاتی مختلف HA در دسترس هستند، به Load\-Balancing Configuration و Hot\-Standby Configuration مراجعه کنید. .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 دستور \fBha\-scopes\fP می‌تواند سرورهای Kea را در وضعیت‌های متناقضی قرار دهد که ممکن است منجر به رفتارهای غیرمنتظره شود. تغییر حوزه‌ها وضعیت سرور یا رابطه آن با شریک (partner) را به طور خودکار تغییر نمی‌دهد. .sp به عنوان مثال، هنگامی که حوزه‌های اصلی (primary) را به سرور آماده‌به‌خدمت (standby) اضافه می‌کنیم، شروع به پاسخ‌گویی به ترافیک DHCP برای آن حوزه‌ها خواهد کرد. این موضوع می‌تواند به وضعیتی بیانجامد که در آن هر دو سرور به ترافیک یکسانی پاسخ می‌دهند که ممکن است باعث تداخل آدرس‌های IP شود. .UNINDENT .UNINDENT .sp دستور \fBha\-scopes\fP ساختار زیر را دارد؛ با استفاده از یک مثال در DHCPv4: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqha\-scopes\(dq, \(dqservice\(dq: [ \(dqdhcp4\(dq ], \(dqarguments\(dq: { \(dqscopes\(dq: [ \(dqHA_server1\(dq, \(dqHA_server2\(dq ], \(dqserver\-name\(dq: \(dqserver2\(dq } } .EE .UNINDENT .UNINDENT .sp این دستور سرور را برای رسیدگی به ترافیک حاصل از هر دو حوزه \(dqHA_server1\(dq و \(dqHA_server2\(dq پیکربندی می‌کند. برای غیرفعال کردن تمامی حوزه‌ها، یک فهرست خالی مشخص کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqha\-scopes\(dq, \(dqservice\(dq: [ \(dqdhcp4 \(dq], \(dqarguments\(dq: { \(dqscopes\(dq: [ ], \(dqserver\-name\(dq: \(dqserver2\(dq } } .EE .UNINDENT .UNINDENT .sp پارامتر اختیاری \fBserver\-name\fP نام یکی از شرکا را در رابطه HA که این دستور مربوط به آن است، مشخص می‌کند. اگر سرور دریافت‌کننده این دستور تنها یک رابطه HA در پیکربندی خود داشته باشد، می‌توان از این پارامتر صرف‌نظر کرد. .SS دستور \fBha\-continue\fP .sp این دستور برای ازسرگیری عملکرد ماشین وضعیت متوقف‌شده HA استفاده می‌شود، همان‌طور که در Pausing the HA State Machine شرح داده شده است. این دستور هیچ آرگومانی نمی‌پذیرد، بنابراین ساختار دستور به سادگی به شکل زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqha\-continue\(dq, \(dqservice\(dq: [ \(dqdhcp4\(dq ], \(dqarguments\(dq: { \(dqscopes\(dq: [ ], \(dqserver\-name\(dq: \(dqserver2\(dq } } .EE .UNINDENT .UNINDENT .sp پارامتر اختیاری \fBserver\-name\fP نام یکی از شرکا را در رابطه HA که این دستور مربوط به آن است، مشخص می‌کند. اگر سرور دریافت‌کننده این دستور تنها یک رابطه HA در پیکربندی خود داشته باشد، می‌توان از این پارامتر صرف‌نظر کرد. .SS دستور \fBha\-heartbeat\fP .sp بخش Server States توصیف می‌کند که چگونه دستور \fBha\-heartbeat\fP توسط یک جفت سرور فعال HA برای تشخیص خرابی یکی از شرکا استفاده می‌شود. با این حال، این دستور می‌تواند توسط مدیر سیستم نیز به یک یا هر دو سرور فرستاده شود تا وضعیت HA آن‌ها بررسی شود. این قابلیت امکان استقرار یک سامانه مانیتورینگ را بر روی سرورهای دارای قابلیت HA فراهم می‌سازد تا به صورت دوره‌ای بررسی کند که آیا آن‌ها فعال هستند یا نیاز به دخالت دستی وجود دارد. دستور \fBha\-heartbeat\fP هیچ آرگومانی نمی‌پذیرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqha\-heartbeat\(dq, \(dqservice\(dq: [ \(dqdhcp4\(dq ], \(dqarguments\(dq: { \(dqscopes\(dq: [ ], \(dqserver\-name\(dq: \(dqserver2\(dq } } .EE .UNINDENT .UNINDENT .sp پارامتر اختیاری \fBserver\-name\fP نام یکی از شرکا را در رابطه HA که این دستور مربوط به آن است، مشخص می‌کند. اگر سرور دریافت‌کننده این دستور تنها یک رابطه HA در پیکربندی خود داشته باشد، می‌توان از این پارامتر صرف‌نظر کرد. .sp پس از برقراری ارتباط موفق با سرور، پاسخی مشابه زیر باید بازگردانده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqHA peer status returned.\(dq, \(dqarguments\(dq: { \(dqstate\(dq: \(dqpartner\-down\(dq, \(dqdate\-time\(dq: \(dqThu, 07 Nov 2019 08:49:37 GMT\(dq, \(dqscopes\(dq: [ \(dqserver1\(dq ], \(dqunsent\-update\-count\(dq: 123 } } .EE .UNINDENT .UNINDENT .sp مقدار بازگردانده شده \fBstate\fP باید یکی از مقادیر فهرست‌شده در Server States باشد. در مثال بالا، وضعیت \fBpartner\-down\fP بازگردانده شده است که نشان می‌دهد سروری که به دستور پاسخ داده معتقد است شریک آن آفلاین است؛ بنابراین، به تمامی درخواست‌های DHCP فرستاده شده به سرورها پاسخ می‌دهد. برای اطمینان از اینکه شریک واقعاً آفلاین است، مدیر سیستم باید دستور \fBha\-heartbeat\fP را به سرور دوم بفرستد. اگر ارسال دستور ناموفق باشد، به عنوان مثال به دلیل ناتوانی در برقراری اتصال TCP به سرور DHCP، به احتمال بسیار زیاد سرور در حال اجرا نیست. .sp پارامتر \fBdate\-time\fP درک سرور از زمان را منتقل می‌کند. .sp مقدار \fBunsent\-update\-count\fP تعداد تجمعی تمام به‌روزرسانی‌های ارسال‌نشده اجاره (lease) از زمان بوت شدن سرور است؛ مقدار آن هنگام راه‌اندازی سرور روی 0 تنظیم می‌شود. این مقدار در طول کارکرد سرور هرگز به 0 بازنشانی نمی‌شود، حتی پس از آنکه شریک پایگاه داده را همگام‌سازی کند. این مقدار توسط شریکی که پاسخ ضربان قلب (heartbeat) را ارسال می‌کند، در صورتی که نتواند به‌روزرسانی اجاره را ارسال کند، افزایش می‌یابد. به عنوان مثال، فرض کنید خرابی در نتیجه یک قطعی موقت در ارتباط باشد. در آن صورت، شریکی که پاسخ ضربان قلب \fBpartner\-down\fP را دریافت می‌کند تغییرات مقدار را ردیابی کرده و می‌تواند پس از برقراری مجدد ارتباط تعیین کند که آیا به‌روزرسانی‌های اجاره جدیدی وجود دارد که دریافت نکرده باشد یا خیر. اگر مقادیر در هر دو سرور مطابقت نداشته باشند، نشانه‌ای است از این که شریک باید پایگاه داده اجاره‌های خود را همگام‌سازی کند. مقدار غیر صفر به خودی خود نشان‌دهنده مشکلی در حال حاضر با به‌روزرسانی‌های اجاره نیست، اما مقداری که مدام در حال افزایش باشد چنین است. .sp پاسخ معمول بازگردانده شده توسط یک سرور زمانی که هر دو سرور عملیاتی هستند، به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqHA peer status returned.\(dq, \(dqarguments\(dq: { \(dqstate\(dq: \(dqload\-balancing\(dq, \(dqdate\-time\(dq: \(dqThu, 07 Nov 2019 08:49:37 GMT\(dq, \(dqscopes\(dq: [ \(dqserver1\(dq ], \(dqunsent\-update\-count\(dq: 0 } } .EE .UNINDENT .UNINDENT .sp در بیشتر موارد، دستور \fBha\-heartbeat\fP باید به هر دو سرور دارای قابلیت HA ارسال شود تا وضعیت کل پیکربندی HA بررسی شود. به ویژه، اگر یکی از سرورها نشان دهد که در وضعیت \fBload\-balancing\fP قرار دارد، به این معنی است که این سرور طوری عمل می‌کند که گویی شریک آن سالم است و کار می‌کند. وقتی یک شریک از کار می‌افتد، مدتی طول می‌کشد تا سرور بازمانده متوجه آن شود. بخش Scope Transition in a Partner\-Down Case الگوریتمی را که سرور بازمانده قبل از انتقال به وضعیت \fBpartner\-down\fP دنبال می‌کند، شرح می‌دهد. اگر دستور \fBha\-heartbeat\fP در بازه زمانی بین از کار افتادن یکی از سرورها و انتقال سرور بازمانده به وضعیت \fBpartner\-down\fP ارسال شود، پاسخ دریافتی از سرور بازمانده این خرابی را بازتاب نمی‌دهد. ارسال مجدد دستور پس از اینکه سرور بازمانده وارد وضعیت \fBpartner\-down\fP شد، خرابی را تشخیص خواهد داد..SS دستور \fBstatus\-get\fP .sp دستور \fBstatus\-get\fP \%<#\:std-isccmd-status-get> یک دستور عمومی است که علاوه بر کارسازهای DHCP، توسط چندین دیمن Kea نیز پشتیبانی می‌شود. با این حال، هنگام ارسال به یک کارساز DHCP با HA فعال، می‌توان از آن برای آگاهی از جزئیات وضعیت کارساز مختص HA استفاده کرد. پاسخ نه تنها حاوی اطلاعات وضعیت کارساز دریافت‌کنندهٔ این دستور است، بلکه در صورت در دسترس بودن، شامل اطلاعات مربوط به شریک (partner) آن نیز می‌شود. .sp در ادامه یک نمونه پاسخ به دستور \fBstatus\-get\fP \%<#\:std-isccmd-status-get>، شامل وضعیت HA دو کارساز \fBload\-balancing\fP آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq\(dq, \(dqarguments\(dq: { \(dqpid\(dq: 1234, \(dquptime\(dq: 3024, \(dqreload\(dq: 1111, \(dqhigh\-availability\(dq: [ { \(dqha\-mode\(dq: \(dqload\-balancing\(dq, \(dqha\-servers\(dq: { \(dqlocal\(dq: { \(dqrole\(dq: \(dqprimary\(dq, \(dqscopes\(dq: [ \(dqserver1\(dq ], \(dqserver\-name\(dq: \(dqserver1\(dq, \(dqstate\(dq: \(dqload\-balancing\(dq, \(dqsystem\-time\(dq: \(dq2024\-01\-01 12:00:00\(dq }, \(dqremote\(dq: { \(dqage\(dq: 10, \(dqanalyzed\-packets\(dq: 8, \(dqclock\-skew\(dq: 0, \(dqcommunication\-interrupted\(dq: true, \(dqconnecting\-clients\(dq: 2, \(dqin\-touch\(dq: true, \(dqlast\-scopes\(dq: [ \(dqserver2\(dq ], \(dqlast\-state\(dq: \(dqload\-balancing\(dq, \(dqrole\(dq: \(dqsecondary\(dq, \(dqserver\-name\(dq: \(dqserver2\(dq, \(dqsystem\-time\(dq: \(dq2024\-01\-01 12:00:00\(dq, \(dqunacked\-clients\(dq: 1, \(dqunacked\-clients\-left\(dq: 2 } } } ], \(dqmulti\-threading\-enabled\(dq: true, \(dqthread\-pool\-size\(dq: 4, \(dqpacket\-queue\-size\(dq: 64, \(dqpacket\-queue\-statistics\(dq: [ 0.2, 0.1, 0.1 ], \(dqsockets\(dq: { \(dqstatus\(dq: \(dqready\(dq } } } .EE .UNINDENT .UNINDENT .sp آرگومان \fBhigh\-availability\fP فهرستی است که در حال حاضر تنها از یک عنصر تشکیل شده است. .sp نگاشت \fBha\-servers\fP شامل دو ساختار است: \fBlocal\fP و \fBremote\fP\&. اولی حاوی اطلاعات وضعیت کارسازی است که دستور را دریافت کرده است، در حالی که دومی دربردارندهٔ اطلاعات وضعیتی است که کارساز محلی از شریک خود دارد. مقدار \fBrole\fP برای کارساز شریک از فایل پیکربندی محلی جمع‌آوری می‌شود، بنابراین همواره باید در دسترس باشد. سایر اطلاعات وضعیت، مانند \fBlast\-scopes\fP و \fBlast\-state\fP، تا زمانی که کارساز محلی با ارسال موفقیت‌آمیز دستور \fBha\-heartbeat\fP با کارساز دوردست ارتباط برقرار نکند در دسترس نخواهند بود. اگر حداقل یک ارتباط از این دست انجام شده باشد، مقدار بازگشتی پارامتر \fBin\-touch\fP برابر با \fBtrue\fP قرار می‌گیرد. با بررسی این مقدار، فرستندهٔ دستور می‌تواند مشخص کند که آیا اطلاعات مربوط به کارساز دوردست قابل اعتماد است یا خیر. .sp پارامترهای \fBlast\-scopes\fP و \fBlast\-state\fP حاوی اطلاعاتی دربارهٔ حوزه‌های HA ارائه‌شده توسط شریک و وضعیت آن هستند. این اطلاعات هنگام تبادل دستور \fBha\-heartbeat\fP جمع‌آوری می‌شوند، بنابراین اگر مشکلی در ارتباط میان شرکا رخ دهد و این اطلاعات وضعیت تازه‌سازی نشوند، ممکن است دقیق نباشند. در چنین حالتی، ممکن است ارسال مستقیم دستور \fBstatus\-get\fP \%<#\:std-isccmd-status-get> به کارساز شریک برای بررسی وضعیت فعلی آن سودمند باشد. پارامتر \fBage\fP، سن اطلاعات دریافتی از شریک را بر حسب ثانیه مشخص می‌کند. .sp مقدار بولی \fBcommunication\-interrupted\fP مشخص می‌کند که آیا کارساز دریافت‌کنندهٔ دستور \fBstatus\-get\fP \%<#\:std-isccmd-status-get> (کارساز محلی) برای مدتی طولانی‌تر از زمان مشخص‌شده در \fBmax\-response\-delay\fP از برقراری ارتباط با شریک ناتوان بوده است یا خیر. در چنین شرایطی، کارسازهای فعال در وضعیت \fBcommunication\-interrupted\fP در نظر گرفته می‌شوند. در این نقطه، کارساز محلی ممکن است پایش ترافیک DHCP هدایت‌شده به سمت شریک را آغاز کند تا ببیند آیا شریک به این ترافیک پاسخ می‌دهد یا خیر. اطلاعات بیشتر دربارهٔ روال failover را می‌توان در پیکربندی Load\-Balancing یافت. .sp پارامتر \fBsystem\-time\fP زمان UTC را در لحظه‌ای که انحراف زمان میان گره محلی و شریک آخرین بار محاسبه شده است، نگه می‌دارد. این مقدار در قالب \fB%Y\-%m\-%d %H:%M:%S\fP به ترتیب برای هر گره فعال، یعنی محلی و دوردست، نمایش داده می‌شود. پارامتر \fBclock\-skew\fP در نگاشت \fBremote\fP در دسترس است و اختلاف این دو زمان را بر حسب ثانیه نگه می‌دارد. زمان محلی از زمان شریک کسر می‌شود. یک مقدار مثبت به این معنی است که ساعت شریک جلوتر است، در حالی که مقدار منفی نشان می‌دهد که شریک عقب‌تر است. اگر انحراف ساعت هنوز محاسبه نشده باشد، هر دو پارامتر \fBsystem\-time\fP و \fBclock\-skew\fP می‌توانند null باشند. .sp پارامترهای \fBconnecting\-clients\fP، \fBunacked\-clients\fP، \fBunacked\-clients\-left\fP و \fBanalyzed\-packets\fP همراه با پارامتر \fBcommunication\-interrupted\fP معرفی شده‌اند و اطلاعات مفیدی دربارهٔ وضعیت پایش ترافیک DHCP در حالت \fBcommunication\-interrupted\fP ارائه می‌دهند. به محض خروج کارساز از حالت \fBcommunication\-interrupted\fP، تمامی این پارامترها به 0 بازنشانی می‌شوند. .sp این پارامترها در حالت \fBcommunication\-interrupted\fP دارای معانی زیر هستند: .INDENT 0.0 .IP \(bu 2 \fBconnecting\-clients\fP \- این تعداد کلاینت‌های متفاوتی است که برای دریافت اجاره (lease) از کارساز دوردست تلاش کرده‌اند. این کلاینت‌ها با نشانی MAC و شناسهٔ کلاینت (در DHCPv4) یا DUID (در DHCPv6) متمایز می‌شوند. این تعداد شامل کلاینت‌های \(dqunacked\(dq (که مقدار فیلد \(dqsecs\(dq یا زمان سپری‌شده \(dqelapsed time\(dq برای آن‌ها از \fBmax\-response\-delay\fP فراتر رفته است) نیز می‌شود. .IP \(bu 2 \fBunacked\-clients\fP \- این تعداد کلاینت‌های متفاوتی است که \(dqunacked\(dq در نظر گرفته شده‌اند؛ یعنی کلاینت‌هایی که تلاششان برای دریافت اجاره بیشتر از مقدار فیلد \(dqsecs\(dq طول کشیده است، یا زمان سپری‌شده \(dqelapsed time\(dq برای آن‌ها از مقدار \fBmax\-response\-delay\fP فراتر رفته است. .IP \(bu 2 \fBunacked\-clients\-left\fP \- این مشخص‌کنندهٔ تعداد کلاینت‌های دیگری است که قبل از ورود کارساز به وضعیت \fBpartner\-down\fP باید \(dqunacked\(dq تلقی شوند. با افزایش مقدار \fBunacked\-clients\fP، این مقدار کاهش می‌یابد. زمانی که این مقدار به 0 برسد، کارساز محلی وارد وضعیت \fBpartner\-down\fP می‌شود. .IP \(bu 2 \fBanalyzed\-packets\fP \- این تعداد کل بسته‌های هدایت‌شده به کارساز شریک است که از زمان ورود به وضعیت قطع ارتباط، توسط کارساز محلی تحلیل شده‌اند. این عدد شامل ارسال‌های مجدد از سوی همان کلاینت‌ها نیز می‌باشد. .UNINDENT .sp پایش این مقادیر به پیش‌بینی زمان ورود کارساز محلی به حالت \fBpartner\-down\fP یا درک چرایی عدم ورود کارساز به این حالت کمک می‌کند. .sp پارامتر \fBha\-mode\fP حالت عملیاتی HA را که با استفاده از پارامتر \fBmode\fP در فایل پیکربندی انتخاب شده است، برمی‌گرداند. این پارامتر می‌تواند یکی از مقادیر زیر را داشته باشد: \fBload\-balancing\fP، \fBhot\-standby\fP، یا \fBpassive\-backup\fP\&. .sp پاسخ \fBstatus\-get\fP \%<#\:std-isccmd-status-get> تنها در حالت‌های \fBload\-balancing\fP و \fBhot\-standby\fP قالبی به صورت شرح‌داده‌شده در بالا دارد. در حالت \fBpassive\-backup\fP، نگاشت \fBremote\fP در پاسخ گنجانده نمی‌شود، زیرا در این حالت تنها یک کارساز فعال (محلی) وجود دارد. پاسخ شامل هیچ اطلاعاتی دربارهٔ وضعیت کارسازهای پشتیبان نیست..SS دستور \fBha\-maintenance\-start\fP .sp این دستور انتقال شرکای سرور به وضعیت \fBin\-maintenance\fP و انتقال سرورِ دریافت‌کنندهٔ دستور به وضعیت \fBpartner\-in\-maintenance\fP را در هر رابطهٔ HA آغاز می‌کند. برای جزئیات بیشتر به بخش «خاموشی کنترل‌شده و نگهداری سرورهای DHCP» (Controlled Shutdown and Maintenance of DHCP Servers) مراجعه کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqha\-maintenance\-start\(dq, \(dqservice\(dq: [ \(dqdhcp4\(dq ] } .EE .UNINDENT .UNINDENT .SS دستور \fBha\-maintenance\-cancel\fP .sp این دستور برای لغو فرآیند نگهداری‌ای که پیش‌تر با استفاده از دستور \fBha\-maintenance\-start\fP آغاز شده بود، استفاده می‌شود. سرور دریافت‌کنندهٔ این دستور ابتدا دستور \fBha\-maintenance\-notify\fP را در حالی که پرچم \fBcancel\fP روی \fBtrue\fP تنظیم شده است، به شرکای خود ارسال می‌کند. سپس سرور از وضعیت \fBpartner\-in\-maintenance\fP به وضعیت پیشین خود بازمی‌گردد. برای جزئیات به بخش «خاموشی کنترل‌شده و نگهداری سرورهای DHCP» (Controlled Shutdown and Maintenance of DHCP Servers) مراجعه کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqha\-maintenance\-cancel\(dq, \(dqservice\(dq: [ \(dqdhcp4\(dq ] } .EE .UNINDENT .UNINDENT .SS دستور \fBha\-maintenance\-notify\fP .sp این دستور توسط سروری که دستور \fBha\-maintenance\-start\fP یا \fBha\-maintenance\-cancel\fP را دریافت کرده است به شریک خود فرستاده می‌شود، تا موجب انتقال شریک به وضعیت \fBin\-maintenance\fP یا بازگشت آن از این وضعیت به وضعیت پیشین شود. برای جزئیات به بخش «خاموشی کنترل‌شده و نگهداری سرورهای DHCP» (Controlled Shutdown and Maintenance of DHCP Servers) مراجعه کنید. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqha\-maintenance\-notify\(dq, \(dqservice\(dq: [ \(dqdhcp4\(dq ], \(dqarguments\(dq: { \(dqcancel\(dq: false, \(dqstate\(dq: \(dqready\(dq, \(dqserver\-name\(dq: \(dqserver2\(dq } } .EE .UNINDENT .UNINDENT .sp آرگومان \fBstate\fP گیرنده را از وضعیت سرور فرستنده مطلع می‌سازد. گیرنده می‌تواند فوراً عملکرد ماشین وضعیت را بدون نیاز به ارسال یک ضربان قلب (heartbeat) جهت بررسی وضعیت شریک، از سر بگیرد. .sp پارامتر اختیاری \fBserver\-name\fP نام یکی از شرکا را در رابطهٔ HA که این دستور مربوط به آن است، مشخص می‌کند. اگر سرور دریافت‌کنندهٔ این دستور فقط یک رابطهٔ HA در پیکربندی خود داشته باشد، می‌توان از این پارامتر صرف‌نظر کرد. .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 دستور \fBha\-maintenance\-notify\fP برای استفاده توسط مدیران سیستم در نظر گرفته نشده است. این دستور برای ارتباطات داخلی بین یک جفت سرور DHCP فعال‌شده با قابلیت HA استفاده می‌شود. استفادهٔ مستقیم از این دستور پشتیبانی نمی‌شود و ممکن است عواقب ناخواسته‌ای ایجاد کند. .UNINDENT .UNINDENT .SS دستور \fBha\-reset\fP .sp این دستور موجب می‌شود سرور ماشین وضعیت دسترس‌پذیری بالا (High Availability) خود را با انتقال به وضعیت \fBwaiting\fP بازنشانی کند. یک شریک در وضعیت \fBcommunication\-recovery\fP ممکن است این دستور را ارسال کند تا سرور پایگاه دادهٔ اجاره‌های (lease database) خود را همگام‌سازی کند. همگام‌سازی پایگاه داده زمانی لازم است که شریک، پس از برقراری مجدد ارتباط متعاقب یک قطعی موقت، نتواند تمام به‌روزرسانی‌های پایگاه دادهٔ اجاره را ارسال نماید. همچنین زمانی که سرور در وضعیت \fBcommunication\-recovery\fP قرار دارد و مقدار \fBdelayed\-updates\-limit\fP فراتر رود، انجام این کار الزامی است. .sp یک مدیر سرور ممکن است این دستور را برای بازنشانی یک ماشین وضعیت که رفتار نادرستی دارد ارسال نماید. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqha\-reset\(dq, \(dqservice\(dq: [ \(dqdhcp4\(dq ], \(dqarguments\(dq: { \(dqserver\-name\(dq: \(dqserver2\(dq } } .EE .UNINDENT .UNINDENT .sp پارامتر اختیاری \fBserver\-name\fP نام یکی از شرکا را در رابطهٔ HA که این دستور مربوط به آن است، مشخص می‌کند. اگر سرور دریافت‌کنندهٔ این دستور تنها یک رابطهٔ HA در پیکربندی خود داشته باشد، می‌توان این پارامتر را نادیده گرفت. .sp این دستور پاسخ زیر را ایجاد می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqHA state machine reset.\(dq } .EE .UNINDENT .UNINDENT .sp اگر سرور دریافت‌کنندهٔ این دستور از قبل در وضعیت \fBwaiting\fP باشد، دستور هیچ اثری نخواهد داشت..SS دستور \fBha\-sync\-complete\-notify\fP .sp یک کارگزار این دستور را برای همتای خود ارسال می‌کند تا اعلام کند که همگام‌سازی پایگاه‌داده اجاره‌ها (lease\-database) را به پایان رسانده است. همتا در صورتی که بتواند در وضعیت فعلی خود اجاره‌های جدیدی تخصیص دهد، ممکن است سرویس DHCP خود را فعال کند. همتا در وضعیت \fBpartner\-down\fP تا زمانی که یک آزمون موفقیت‌آمیز \fBha\-heartbeat\fP به کارگزار همتای خود ارسال نکند، سرویس DHCP را فعال نمی‌کند. اگر اتصال همچنان در دسترس نباشد، کارگزار در وضعیت \fBpartner\-down\fP سرویس DHCP خود را فعال می‌کند تا به پاسخ‌دهی به کلاینت‌ها ادامه دهد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqha\-sync\-complete\-notify\(dq, \(dqservice\(dq: [ \(dqdhcp4\(dq ], \(dqarguments\(dq: { \(dqorigin\-id\(dq: 2000, \(dqserver\-name\(dq: \(dqserver2\(dq } } .EE .UNINDENT .UNINDENT .sp پارامتر اختیاری \fBserver\-name\fP نام یکی از همتاها را در رابطه HA که این دستور به آن مربوط می‌شود مشخص می‌کند. اگر کارگزار دریافت‌کننده این دستور تنها یک رابطه HA در پیکربندی خود داشته باشد، می‌توان این پارامتر را نادیده گرفت. .sp پارامتر \fBorigin\-id\fP برای انتخاب سرویس HA استفاده می‌شود که کارگزار دریافت‌کننده هنگام دریافت این اعلان، باید سرویس DHCP را برای آن فعال کند. این همان مبدأیی است که کارگزار فرستنده پیش‌تر برای غیرفعال کردن سرویس DHCP پیش از همگام‌سازی استفاده کرده بود. پارامتر \fBorigin\-id\fP جایگزین پارامتر منسوخ‌شده \fBorigin\fP است که در برخی از نسخه‌های پیشین Kea استفاده می‌شد. .sp این دستور پاسخ زیر را به همراه دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqServer successfully notified about the synchronization completion.\(dq } .EE .UNINDENT .UNINDENT .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 دستور \fBha\-sync\-complete\-notify\fP برای استفاده توسط مدیران سیستم در نظر گرفته نشده است. این دستور برای ارتباط داخلی میان یک جفت کارگزار DHCP با قابلیت HA استفاده می‌شود. استفاده مستقیم از این دستور پشتیبانی نمی‌شود و ممکن است پیامدهای ناخواسته‌ای به همراه داشته باشد. .UNINDENT .UNINDENT .SS پیکربندی هاب و اسپوک (Hub and Spoke) .sp یک چیدمان هاب و اسپوک (hub\-and\-spoke)، با یک کارگزار مرکزی و چندین کارگزار شعبه، روشی متداول برای اطمینان از تاب‌آوری کارگزارهای DHCP است. کارگزارهای شعبه، کارگزارهای اصلی در حالت \fBhot\-standby\fP هستند و به ترافیک محلی DHCP در مکان‌های مربوط به خود پاسخ می‌دهند. کارگزار مرکزی به عنوان یک کارگزار آماده‌به‌خدمت (standby) برای هر کارگزار شعبه عمل می‌کند. این کارگزار ماشین‌های وضعیت مستقلی را با کارگزارهای شعبه نگه می‌دارد که روابط (relationships) نامیده می‌شوند. اگر یکی از کارگزارهای شعبه دچار خرابی شود، کارگزار مرکزی می‌تواند ترافیک DHCP آن را به عهده بگیرد. در این حالت، یکی از روابط کارگزار مرکزی در وضعیت \fBpartner\-down\fP قرار می‌گیرد. سایر روابط ممکن است همچنان در وضعیت \fBhot\-standby\fP باقی بمانند و به طور فعال به ترافیک DHCP پاسخ ندهند. هنگامی که کارگزار شعبه دوباره فعال می‌شود، پایگاه‌داده اجاره را با کارگزار مرکزی همگام‌سازی می‌کند و کارگزار مرکزی دوباره کاملاً غیرفعال (passive) می‌شود. در موارد نادر، اگر چندین کارگزار شعبه متوقف شوند، کارگزار مرکزی مسئولیت تمام ترافیک آن‌ها را به عهده می‌گیرد و در صورتی که همه کارگزارهای شعبه از کار بیفتند، بالقوه کل ترافیک DHCP در کل شبکه را مدیریت خواهد کرد. یک ساختار ساده هاب و اسپوک متشکل از دو کارگزار شعبه و یک کارگزار مرکزی در زیر نشان داده شده است. .INDENT 0.0 .INDENT 3.5 .sp .EX +\-\-\-\-\- Central Server \-\-\-\-\-\-+ | | +\-\-\-\-\-\-\-\-\-\-+ relationship 1 | +\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-+ | relationship 2 +\-\-\-\-\-\-\-\-\-\-+ | Server 1 |===================| Server 2 | Server 4 |===================| Server 3 | +\-\-\-\-\-\-\-\-\-\-+ | +\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-+ | +\-\-\-\-\-\-\-\-\-\-+ | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ .EE .UNINDENT .UNINDENT .sp پیکربندی هر کارگزار شعبه شامل مجموعه‌ای از زیرشبکه‌های مناسب برای آن کارگزار شعبه است؛ کارگزارهای شعبه مختلف به زیرشبکه‌های متفاوتی سرویس می‌دهند. پیکربندی کارگزار مرکزی شامل تمام زیرشبکه‌های کارگزارهای شعبه است، به طوری که بتواند به ترافیک DHCP هدایت‌شده به هر کارگزار شعبه‌ای که دچار خرابی شده است پاسخ دهد. زیرشبکه‌ها در کارگزار مرکزی باید مانند قطعه‌کد زیر در قالب روابط گروه‌بندی شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqenp0s8\(dq, \(dqenp0s9\(dq ] }, \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: {} }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [ { \(dqthis\-server\-name\(dq: \(dqserver2\(dq, \(dqmode\(dq: \(dqhot\-standby\(dq, \(dqmulti\-threading\(dq: { \(dqenable\-multi\-threading\(dq: true, \(dqhttp\-dedicated\-listener\(dq: true, \(dqhttp\-listener\-threads\(dq: 4, \(dqhttp\-client\-threads\(dq: 4 }, \(dqpeers\(dq: [ { \(dqname\(dq: \(dqserver1\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.66:8007/\(dq, \(dqrole\(dq: \(dqprimary\(dq, \(dqauto\-failover\(dq: true }, { \(dqname\(dq: \(dqserver2\(dq, \(dqurl\(dq: \(dqhttp://192.168.56.33:8007/\(dq, \(dqrole\(dq: \(dqstandby\(dq, \(dqauto\-failover\(dq: true } ] }, { \(dqthis\-server\-name\(dq: \(dqserver4\(dq, \(dqmode\(dq: \(dqhot\-standby\(dq, \(dqmulti\-threading\(dq: { \(dqenable\-multi\-threading\(dq: true, \(dqhttp\-dedicated\-listener\(dq: true, \(dqhttp\-listener\-threads\(dq: 4, \(dqhttp\-client\-threads\(dq: 4 }, \(dqpeers\(dq: [ { \(dqname\(dq: \(dqserver3\(dq, \(dqurl\(dq: \(dqhttp://192.168.57.99:8007/\(dq, \(dqrole\(dq: \(dqprimary\(dq, \(dqauto\-failover\(dq: true }, { \(dqname\(dq: \(dqserver4\(dq, \(dqurl\(dq: \(dqhttp://192.168.57.33:8007/\(dq, \(dqrole\(dq: \(dqstandby\(dq, \(dqauto\-failover\(dq: true } ] } ] } } ], \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::/80\(dq } ], \(dqinterface\(dq: \(dqenp0s8\(dq, \(dquser\-context\(dq: { \(dqha\-server\-name\(dq: \(dqserver2\(dq } }, { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq2001:db8:2::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:2::/80\(dq } ], \(dqinterface\(dq: \(dqenp0s9\(dq, \(dquser\-context\(dq: { \(dqha\-server\-name\(dq: \(dqserver4\(dq } } ] } } .EE .UNINDENT .UNINDENT .sp نام‌های همتا در روابط باید یکتا باشند. بافت کاربر (user context) برای هر زیرشبکه شامل پارامتر \fBha\-server\-name\fP است که یک زیرشبکه را با یک رابطه مرتبط می‌کند. مقدار \fBha\-server\-name\fP می‌تواند هر یک از نام‌های همتا در رابطه باشد. به عنوان مثال، اگر یک رابطه شامل نام‌های همتای \fBserver1\fP و \fBserver2\fP باشد، فرقی نمی‌کند که \fBha\-server\-name\fP برابر با \fBserver1\fP باشد یا \fBserver2\fP\&. در هر دو حالت، زیرشبکه را با آن رابطه مرتبط می‌سازد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 توجه به این نکته مهم است که هر همتا در یک کارگزار Kea مشخص باید از ترکیب نشانی/پورت شنود یکتا استفاده کند. اگر نشانی و پورت یکسانی برای چندین همتا تعریف شود، سرویس Kea با خطایی مشابه زیر در راه‌اندازی شکست می‌خورد: .INDENT 0.0 .INDENT 3.5 .sp .EX DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file \(aqkea\-dhcp4.conf\(aq: Error initializing hooks: CmdHttpListener::run failed: unable to setup TCP acceptor for listening to the incoming HTTP requests: bind: Address already in use .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .sp مشخص کردن \fBha\-server\-name\fP در کارگزارهای شعبه الزامی نیست، با این فرض که کارگزارهای شعبه فقط شامل زیرشبکه‌هایی باشند که به آن‌ها سرویس می‌دهند. پیکربندی زیر را برای شعبه \fBserver3\fP در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqenp0s8\(dq ] }, \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: {} }, { \(dqlibrary\(dq: \(dqlibdhcp_ha.so\(dq, \(dqparameters\(dq: { \(dqhigh\-availability\(dq: [ { \(dqthis\-server\-name\(dq: \(dqserver3\(dq, \(dqmode\(dq: \(dqhot\-standby\(dq, \(dqmulti\-threading\(dq: { \(dqenable\-multi\-threading\(dq: true, \(dqhttp\-dedicated\-listener\(dq: true, \(dqhttp\-listener\-threads\(dq: 4, \(dqhttp\-client\-threads\(dq: 4 }, \(dqpeers\(dq: [ { \(dqname\(dq: \(dqserver3\(dq, \(dqurl\(dq: \(dqhttp://192.168.57.99:8007/\(dq, \(dqrole\(dq: \(dqprimary\(dq, \(dqauto\-failover\(dq: true }, { \(dqname\(dq: \(dqserver4\(dq, \(dqurl\(dq: \(dqhttp://192.168.57.33:8007/\(dq, \(dqrole\(dq: \(dqstandby\(dq, \(dqauto\-failover\(dq: true } ] } ] } } ], \(dqsubnet6\(dq: [ { \(dqid\(dq: 2, \(dqsubnet\(dq: \(dq2001:db8:2::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:2::/80\(dq } ], \(dqinterface\(dq: \(dqenp0s8\(dq, \(dquser\-context\(dq: { \(dqha\-server\-name\(dq: \(dqserver3\(dq } } ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگرچه می‌توان پارامترهای بافت کاربر \fBha\-server\-name\fP را در کارگزارهای شعبه نادیده گرفت، توصیه می‌کنیم آن‌ها را درج کنید. کارگزارها هنگام همگام‌سازی پایگاه‌داده، تمام اجاره‌ها را از همتاها دریافت می‌کنند؛ اگر زیرشبکه‌ها به صراحت با رابطه مرتبط نشده باشند، کارگزار شعبه تمام اجاره‌های دریافت شده از کارگزار مرکزی (شامل اجاره‌های مربوط به سایر روابط) را در پایگاه‌داده خود وارد می‌کند. مشخص کردن پارامتر \fBha\-server\-name\fP برای هر زیرشبکه پیکربندی‌شده در کارگزار شعبه، تضمین می‌کند که فقط اجاره‌های متعلق به رابطه خود در پایگاه‌داده کارگزار شعبه وارد شوند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نام‌های همتا در کارگزارهای شعبه باید با نام‌های همتا در روابط متناظر کارگزار مرکزی مطابقت داشته باشند، زیرا این نام‌ها برای ارسال سیگنال میان همتاهای HA استفاده می‌شوند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پیکربندی هاب و اسپوک در حال حاضر با پارامترهای \fBreselect\-subnet\-address\fP و \fBreselect\-subnet\-pool\fP از کتابخانه \fBlibdhcp_radius.so\fP ناسازگار است. کتابخانه قلاب دسترس‌پذیری بالا (High Availability hook library) از زیرشبکه انتخاب‌شده اولیه برای برگزیدن یک رابطه HA جهت پردازش بسته استفاده می‌کند. انتخاب مجدد زیرشبکه ممکن است با این فرایند تداخل ایجاد کند. برای جزئیات بیشتر، به بخش پیکربندی کتابخانه قلاب RADIUS در \%<#\:radius-config> مراجعه کنید. .UNINDENT .UNINDENT.SS \fBlibdhcp_host_cache.so\fP: رزروهای حافظه موقت میزبان برای بهبود کارایی .sp برخی از پس‌اندهای پایگاه‌داده، مانند RADIUS، کند هستند و ممکن است پاسخ‌دهی آن‌ها زمان زیادی ببرد. از آن‌جا که Kea به‌طور کلی همگام (synchronous) است، کارایی پس‌اند مستقیماً بر کارایی DHCP تأثیر می‌گذارد. به منظور به حداقل رساندن این اثر و بهبود کارایی، کتابخانهٔ Host Cache روشی برای ذخیره‌سازی محلی اطلاعات پایگاه‌داده در حافظه موقت (cache) فراهم می‌کند. این قابلیت شامل حافظه موقت منفی (negative caching)، یعنی توانایی به‌خاطر سپردن این که هیچ اطلاعاتی از کلاینت در پایگاه‌داده وجود ندارد، نیز می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_host_cache.so\fP بخشی از کد منبع‌باز است و برای همهٔ کاربران Kea در دسترس است. این قابلیت پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرایند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp در اصل، این کتابخانهٔ قلاب (hook library) می‌تواند با هر پس‌اندی که ممکن است موجب افت کارایی شود (MySQL، PostgreSQL یا RADIUS) استفاده شود. برای کارکرد سازوکار حسابرسی (accounting) در RADIUS، بارگذاری Host Cache الزامی است. .sp کتابخانهٔ قلاب Host Cache بسیار ساده است. این کتابخانه تنها یک پارامتر اختیاری (\fBmaximum\fP) می‌گیرد که حداکثر تعداد میزبان‌های ذخیره‌شده در حافظه موقت را مشخص می‌کند. در صورت عدم تعیین، مقدار پیش‌فرض 0 استفاده می‌شود که به معنای نبود محدودیت است. این کتابخانهٔ قلاب را می‌توان همانند هر کتابخانهٔ قلاب دیگری بارگذاری کرد؛ برای نمونه، این پیکربندی می‌تواند استفاده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp4\(dq: { # Your regular DHCPv4 configuration parameters here. \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_host_cache.so\(dq, \(dqparameters\(dq: { # Tells Kea to never cache more than 1000 hosts. \(dqmaximum\(dq: 1000 } } ], \&... } .EE .UNINDENT .UNINDENT .sp پس از بارگذاری، کتابخانهٔ قلاب Host Cache تعدادی دستور جدید ارائه می‌دهد که می‌توانند از طریق کانال کنترل (بخش Using the Control Channel \%<#\:ctrl-channel-client> را ببینید) استفاده شوند. یک نمونه کلاینت RESTful API در Overview of the Kea Shell \%<#\:shell-overview>\& شرح داده شده است. بخش‌های زیر دستورهای موجود را شرح می‌دهند. .SS دستور \fBcache\-flush\fP .sp این دستور امکان حذف تعداد مشخصی از مدخل‌های ذخیره‌شدهٔ میزبان را فراهم می‌کند. این دستور یک پارامتر می‌گیرد که تعداد میزبان‌های حذفی را مشخص می‌کند. یک نمونه کاربرد به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-flush\(dq, \(dqarguments\(dq: 1000 } .EE .UNINDENT .UNINDENT .sp این دستور 1000 میزبان را حذف می‌کند؛ برای حذف \fIتمام\fP میزبان‌های ذخیره‌شده، در عوض از \fBcache\-clear\fP استفاده کنید. میزبان‌ها با ترتیب FIFO (نخستین ورودی، نخستین خروجی) ذخیره می‌شوند، بنابراین همیشه قدیمی‌ترین مدخل‌ها حذف می‌گردند. .SS دستور \fBcache\-clear\fP .sp این دستور امکان حذف تمام مدخل‌های ذخیره‌شدهٔ میزبان را فراهم می‌کند. یک نمونه کاربرد به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-clear\(dq } .EE .UNINDENT .UNINDENT .sp این دستور تمام میزبان‌ها را حذف می‌کند. برای حذف تنها تعداد مشخصی از میزبان‌های ذخیره‌شده، لطفاً در عوض از \fBcache\-flush\fP استفاده کنید. .SS دستور \fBcache\-size\fP .sp این دستور تعداد مدخل‌های میزبان را بازمی‌گرداند. یک نمونه کاربرد به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-size\(dq } .EE .UNINDENT .UNINDENT .SS دستور \fBcache\-write\fP .sp به‌طور کلی، محتوای حافظه موقت یک وضعیت زمان اجرا در نظر گرفته می‌شود و کارساز می‌تواند طبق معمول خاموش یا بازراه‌اندازی شود؛ سپس حافظه موقت پس از بازراه‌اندازی مجدداً پر می‌شود. با این حال، در برخی موارد ذخیره کردن محتویات حافظه موقت سودمند است. یک نمونه از این موارد RADIUS است، که در آن میزبان‌های ذخیره‌شده همچنین صفت‌های اضافیِ ذخیره‌شدهٔ RADIUS را حفظ می‌کنند؛ روش آسانی برای به‌دست آوردن دوبارهٔ این اطلاعات وجود ندارد، زیرا کلاینت‌های در حال تمدید بسته‌های خود را مستقیماً به کارساز DHCP ارسال می‌کنند. مورد کاربرد دیگر زمانی است که مدیر سیستم می‌خواهد کارساز را بازراه‌اندازی کند و به دلایل کارایی، مایل است کارساز با یک حافظه موقت گرم و از پیش پرشده (hot/populated) شروع به کار کند. .sp این دستور امکان نوشتن محتویات حافظه موقت درون‌حافظه‌ای را در یک فایل روی دیسک فراهم می‌کند. این دستور یک پارامتر می‌پذیرد که نام فایل را مشخص می‌کند. یک نمونه کاربرد به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-write\(dq, \(dqarguments\(dq: \(dq/var/lib/kea/kea\-host\-cache.json\(dq } .EE .UNINDENT .UNINDENT .sp این کار موجب ذخیره شدن محتویات در فایل \fB/var/lib/kea/kea\-host\-cache.json\fP می‌شود. سپس می‌توان آن فایل را با دستور \fBcache\-load\fP بارگذاری کرد یا توسط هر ابزار دیگری که قادر به تجزیه و فهم قالب JSON باشد پردازش نمود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ 2.7.9 در Kea، فایل حافظه موقت تنها می‌تواند در دایرکتوری داده‌ای که در زمان کامپایل مشخص شده است نوشته شود: \fB\(dq[kea\-install\-dir]/var/lib/kea\(dq\fP\&. این مسیر می‌تواند در هنگام راه‌اندازی با مقداردهی متغیر محیطی \fBKEA_DHCP_DATA_DIR\fP به مسیر دلخواه بازنویسی شود. برای راحتی کار هنگام تعیین نام فایل سفارشی، کافی است بخش مسیر را از \fBfilename\fP حذف کنید. .UNINDENT .UNINDENT.SS دستور \fBcache\-load\fP .sp برای بررسی سناریوهای کاربردی که در آن‌ها نوشتن و بارگذاری محتویات حافظهٔ نهان میزبان روی دیسک می‌تواند مفید باشد، به بخش قبل مراجعه کنید. .sp این دستور اجازه می‌دهد محتویات یک فایل روی دیسک در یک حافظهٔ نهان درون حافظه (in\-memory cache) بارگذاری شود. این دستور یک پارامتر می‌گیرد که نام فایل را مشخص می‌کند. نمونه‌ای از کاربرد آن به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-load\(dq, \(dqarguments\(dq: \(dq/usr/local/share/kea/kea\-host\-cache.json\(dq } .EE .UNINDENT .UNINDENT .sp این دستور محتویات را در فایل \fB/usr/local/share/kea/kea\-host\-cache.json\fP ذخیره می‌کند. سپس می‌توان آن فایل را با دستور \fBcache\-load\fP بارگذاری کرد یا توسط هر ابزار دیگری که قادر به درک قالب JSON باشد پردازش نمود. .SS دستور \fBcache\-get\fP .sp این دستور مشابه \fBcache\-write\fP است، اما به جای نوشتن محتویات حافظهٔ نهان روی دیسک، محتویات را به ارسال‌کنندهٔ دستور بازمی‌گرداند. .sp این دستور اجازه می‌دهد محتویات یک فایل روی دیسک در یک حافظهٔ نهان درون حافظه بارگذاری شود. این دستور یک پارامتر می‌گیرد که نام فایل را مشخص می‌کند. نمونه‌ای از کاربرد آن به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-get\(dq } .EE .UNINDENT .UNINDENT .sp این دستور تمام میزبان‌های ذخیره‌شده در حافظهٔ نهان را برمی‌گرداند؛ پاسخ ممکن است حجیم باشد. .SS دستور \fBcache\-get\-by\-id\fP .sp این دستور مشابه \fBcache\-get\fP است، اما به جای بازگرداندن کل محتوا، تنها ورودی‌های منطبق با شناسهٔ ارائه‌شده را بازمی‌گرداند. .sp این دستور یک پارامتر می‌گیرد که شناسهٔ رزروهای میزبان موردنظر در حافظهٔ نهان را مشخص می‌کند. نمونه‌ای از کاربرد آن به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-get\-by\-id\(dq, \(dqarguments\(dq: { \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq } } .EE .UNINDENT .UNINDENT .sp این دستور تمام میزبان‌های ذخیره‌شده در حافظهٔ نهان را با آدرس سخت‌افزاری ارائه‌شده بازمی‌گرداند. .SS دستور \fBcache\-insert\fP .sp از این دستور می‌توان برای درج دستی یک میزبان در حافظهٔ نهان استفاده کرد؛ سناریوهای کاربردی بسیار اندکی وجود دارند که در آن‌ها این دستور ممکن است مفید باشد. این دستور انتظار دارد آرگومان‌های آن از نحو معمول برای تعیین رزروهای میزبان پیروی کنند (بخش رزروهای میزبان در DHCPv4 \%<#\:host-reservation-v4> یا رزروهای میزبان در DHCPv6 \%<#\:host-reservation-v6> را ببینید)، با یک تفاوت: مقدار \fBsubnet\-id\fP باید صراحتاً مشخص شود. .sp نمونه‌ای از دستور برای درج یک میزبان IPv4 در حافظهٔ نهان میزبان به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-insert\(dq, \(dqarguments\(dq: { \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqsubnet\-id4\(dq: 4, \(dqsubnet\-id6\(dq: 0, \(dqip\-address\(dq: \(dq192.0.2.100\(dq, \(dqhostname\(dq: \(dqsomehost.example.org\(dq, \(dqclient\-classes4\(dq: [ ], \(dqclient\-classes6\(dq: [ ], \(dqoption\-data4\(dq: [ ], \(dqoption\-data6\(dq: [ ], \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq, \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqhost\-id\(dq: 0 } } .EE .UNINDENT .UNINDENT .sp نمونه‌ای از دستور برای درج یک میزبان IPv6 در حافظهٔ نهان میزبان به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-insert\(dq, \(dqarguments\(dq: { \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqsubnet\-id4\(dq: 0, \(dqsubnet\-id6\(dq: 6, \(dqip\-addresses\(dq: [ \(dq2001:db8::cafe:babe\(dq ], \(dqprefixes\(dq: [ \(dq2001:db8:dead:beef::/64\(dq ], \(dqhostname\(dq: \(dq\(dq, \(dqclient\-classes4\(dq: [ ], \(dqclient\-classes6\(dq: [ ], \(dqoption\-data4\(dq: [ ], \(dqoption\-data6\(dq: [ ], \(dqnext\-server\(dq: \(dq0.0.0.0\(dq, \(dqserver\-hostname\(dq: \(dq\(dq, \(dqboot\-file\-name\(dq: \(dq\(dq, \(dqhost\-id\(dq: 0 } } .EE .UNINDENT .UNINDENT.SS دستور \fBcache\-remove\fP .sp گاهی اوقات حذف یک مدخل مشخص از کَش میزبان مفید است: برای مثال وضعیتی را در نظر بگیرید که دستگاه فعال است، Kea از پیش پیکربندی را ارائه داده، و مدخل میزبان در کَش قرار دارد. در پی یک اقدام مدیریتی (مثلاً مشتری قبوض خود را پرداخت نکرده یا به یک سرویس بهتر ارتقا یافته است)، اطلاعات در پایگاه‌دادهٔ پسین (مانند MySQL یا RADIUS) به‌روزرسانی می‌شود. با این حال، از آنجا که کَش در حال استفاده است، Kea متوجه تغییرات نمی‌شود زیرا مقادیر کَش‌شده به کار گرفته می‌شوند. دستور \fBcache\-remove\fP می‌تواند با حذف مدخل کَش‌شده پس از اعمال تغییرات مدیریتی، این مشکل را برطرف کند. .sp دستور \fBcache\-remove\fP به شیوه‌ای مشابه با دستور \fBreservation\-get\fP عمل می‌کند. این دستور امکان پرس‌وجو با استفاده از دو پارامتر را فراهم می‌کند: یا \fBsubnet\-id4\fP یا \fBsubnet\-id6\fP؛ یا \fBip\-address\fP (می‌تواند یک آدرس IPv4 یا IPv6 باشد)، \fBhw\-address\fP (مشخص‌کنندهٔ آدرس سخت‌افزاری/MAC)، \fBduid\fP، \fBcircuit\-id\fP، \fBclient\-id\fP، یا \fBflex\-id\fP\&. .sp یک دستور نمونه برای حذف یک میزبان IPv4 با آدرس رزروشدهٔ 192.0.2.1 از زیرشبکه‌ای با \fBsubnet\-id\fP برابر با 123 به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-remove\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.2.1\(dq, \(dqsubnet\-id\(dq: 123 } } .EE .UNINDENT .UNINDENT .sp نمونه‌ای دیگر که یک شناسهٔ میزبان IPv6 را بر اساس DUID و یک \fBsubnet\-id\fP مشخص حذف می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-remove\(dq, \(dqarguments\(dq: { \(dqduid\(dq: \(dq00:01:ab:cd:f0:a1:c2:d3:e4\(dq, \(dqsubnet\-id\(dq: 123 } } .EE .UNINDENT .UNINDENT .SS \fBlibdhcp_host_cmds.so\fP: دستورهای میزبان .sp Kea می‌تواند رزروهای میزبان را در یک پایگاه‌داده ذخیره کند؛ در بسیاری از استقرارهای بزرگ‌تر، اینکه بتوان این اطلاعات را در حین اجرای کارساز مدیریت کرد بسیار سودمند است. کتابخانهٔ دستورهای میزبان (Host Commands)، دستورهای مدیریتی را برای افزودن، پرس‌وجو، و حذف رزروهای میزبان به شکلی امن و بدون راه‌اندازی مجدد کارساز ارائه می‌دهد. به‌ویژه، این کتابخانه پارامترها را اعتبارسنجی می‌کند، بنابراین تلاش برای درج داده‌های نادرست \- مانند افزودن میزبانی با شناسهٔ متداخل در همان زیرشبکه \- رد می‌شود. این دستورها از طریق کانال فرمان (JSON بر بستر سوکت‌های UNIX یا HTTP/HTTPS) ارائه می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_host_cmds.so\fP بخشی از کد منبع‌باز است و در دسترس تمامی کاربران Kea قرار دارد. این قابلیت پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرایند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp در حال حاضر دستورهای زیر پشتیبانی می‌شوند: .INDENT 0.0 .IP \(bu 2 \fBreservation\-add\fP، که یک رزرو میزبان جدید اضافه می‌کند. .IP \(bu 2 \fBreservation\-get\fP، که در صورت تطابق با معیارهای مشخص‌شده، یک رزرو موجود را بازمی‌گرداند. .IP \(bu 2 \fBreservation\-get\-all\fP، که تمام رزروهای موجود در یک زیرشبکهٔ مشخص را بازمی‌گرداند. .IP \(bu 2 \fBreservation\-get\-page\fP، نوعی از \fBreservation\-get\-all\fP که رزروها را به صورت صفحه‌بندی‌شده بازمی‌گرداند؛ خواه تمام آن‌ها و خواه در یک زیرشبکهٔ مشخص. .IP \(bu 2 \fBreservation\-get\-by\-address\fP، که تمام رزروهای دارای یک آدرس IP مشخص یا یک پیشوند واگذارشده (بدون طول پیشوند)، و به‌طور اختیاری یک شناسهٔ زیرشبکه را بازمی‌گرداند. .IP \(bu 2 \fBreservation\-get\-by\-hostname\fP، که تمام رزروهای دارای یک نام میزبان مشخص و به‌طور اختیاری درون یک زیرشبکه را بازمی‌گرداند. .IP \(bu 2 \fBreservation\-get\-by\-id\fP، که تمام رزروهای دارای شناسهٔ مشخص را بازمی‌گرداند (از نسخهٔ 1.9.0 در Kea). .IP \(bu 2 \fBreservation\-del\fP، که برای حذف رزرو منطبق با معیارهای مشخص‌شده تلاش می‌کند. .IP \(bu 2 \fBreservation\-update\fP، که یک رزرو موجود منطبق با شناسه‌های ارائه‌شده در یک زیرشبکه را به‌روزرسانی (جایگزین) می‌کند. .UNINDENT .sp برای استفاده از دستورهایی که اطلاعات رزرو را تغییر می‌دهند (یعنی \fBreservation\-add\fP، \fBreservation\-del\fP، و \fBreservation\-update\fP) جهت تغییر داده‌های ذخیره‌شده در پایگاه‌دادهٔ میزبان، پایگاه‌دادهٔ میزبان‌ها باید مشخص شده باشد و نباید در حالت فقط‌خواندنی (read\-only) اجرا شود (برای جزئیات، به توضیحات \fBhosts\-databases\fP در بخش پیکربندی پایگاه‌دادهٔ میزبان‌های DHCPv4 \%<#\:hosts-databases-configuration4> و پیکربندی پایگاه‌دادهٔ میزبان‌های DHCPv6 \%<#\:hosts-databases-configuration6> مراجعه کنید). چنانچه \fBhosts\-databases\fP مشخص نشده باشد یا در حالت فقط‌خواندنی کار کند، \fBlibdhcp_host_cmds.so\fP بارگذاری خواهد شد، اما هرگونه تلاش برای استفاده از \fBreservation\-add\fP، \fBreservation\-del\fP، و \fBreservation\-update\fP جهت اصلاح داده‌ها در آن پایگاه‌داده با شکست مواجه خواهد شد. .sp این دستورها همچنین می‌توانند میزبان‌ها را از پیکربندی JSON، مستقل از پایگاه‌دادهٔ میزبان‌ها اصلاح کنند. تغییرات اعمال‌شده در پیکربندی JSON به صورت فرار (volatile) هستند و می‌توان با ارسال دستور \fBconfig\-write\fP \%<#\:std-isccmd-config-write> آن‌ها را دائمی کرد. .sp برای مشاهدهٔ شرح دستورهای پیشنهادی در آینده، به سند الزامات رابط کنترلی (Control API Requirements) در نشانی \% مراجعه کنید. .sp تمامی دستورهای میزبان از نحو JSON استفاده می‌کنند. این دستورها را می‌توان با استفاده از کانال کنترل صادر کرد (به رابط مدیریتی یا Management API \%<#\:ctrl-channel> مراجعه کنید). .sp این کتابخانه می‌تواند مشابه سایر کتابخانه‌های قلاب (hook libraries) بارگذاری شود. این کتابخانه هیچ پارامتری دریافت نمی‌کند و از هر دو کارساز DHCPv4 و DHCPv6 پشتیبانی می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_host_cmds.so\(dq }, ... ] } .EE .UNINDENT .UNINDENT.SS پارامتر \fBsubnet\-id\fP .sp پیش از بررسی هر دستور به طور مجزا، شایسته است در مورد پارامتر \fBsubnet\-id\fP بحث شود\&. در حال حاضر، این پارامتر برای تمام دستورات ارائه‌شده توسط این کتابخانه اجباری است، به استثنای \fBreservation\-get\-by\-hostname\fP و \fBreservation\-get\-by\-address\fP که در آن‌ها اختیاری است. \fBsubnet\-id\fP همچنین در \fBreservation\-get\-page\fP اختیاری بوده و در \fBreservation\-get\-by\-id\fP غیرمجاز است\&. .sp رزروها می‌توانند به صورت سراسری (global) مشخص شوند و لزوماً محدود به زیرشبکه خاصی نیستند. هنگامی که رزروها از طریق فایل پیکربندی ارائه می‌شوند، شناسه (ID) زیرشبکه دربرگیرنده (یا عدم وجود آن) در ساختار پیکربندی به صورت ضمنی مشخص است. با این حال، هنگام مدیریت رزروها با استفاده از دستورات host، لازم است حوزه‌ای (scope) که رزرو به آن تعلق دارد، به طور صریح مشخص شود. این کار از طریق پارامتر \fBsubnet\-id\fP انجام می‌شود. برای رزروهای سراسری، از مقدار صفر (0) استفاده کنید. برای رزروهای محدود به یک زیرشبکه خاص، از شناسه (ID) آن زیرشبکه استفاده نمایید. همچنین به یادداشت موجود در بخش دستور reservation\-add درباره دستور \fBreservation\-add\fP برای رزرو خالی (یعنی بدون آدرس یا پیشوند رزرو شده) مراجعه کنید. .sp از سوی دیگر، اگر \fBsubnet\-id\fP در پارامترهای دستور مشخص نشده باشد، به هر میزبان (host) در پاسخ‌ها اضافه می‌شود. اگر \fBsubnet\-id\fP دارای مقدار ویژه استفاده‌نشده باشد، بدان معناست که مدخل میزبان تنها به نسخه دیگر IP تعلق دارد (یعنی IPv6 در سرور DHCPv4 یا IPv4 در سرور DHCPv6) و این مدخل نادیده گرفته می‌شود. .SS پارامتر \fBoperation\-target\fP .sp اکثر دستورات host پارامتر \fBoperation\-target\fP را می‌پذیرند که منبع داده میزبان را انتخاب می‌کند. دستورات ممکن است داده‌ها را از پیکربندی سرور (یعنی مقصد عملیاتی حافظه - memory)، یک پایگاه داده (مقصد database) یا هر دو (تمام منابع) پردازش کنند. پارامتر operation\-target اختیاری است. به طور پیش‌فرض، دستوراتی که فقط داده‌ها را می‌خوانند از تمام منابع داده (حافظه و پایگاه داده) استفاده می‌کنند؛ دستوراتی که وضعیت را تغییر می‌دهند (یعنی \fBreservation\-add\fP، \fBreservation\-del\fP و \fBreservation\-update\fP) تنها از مقصد پایگاه داده (database) استفاده می‌کنند. .sp پارامتر \fBoperation\-target\fP مقادیر زیر را می‌پذیرد: .INDENT 0.0 .IP \(bu 2 \fBmemory\fP \- پرس‌وجو یا به‌روزرسانی پیکربندی زمان اجرای سرور .IP \(bu 2 \fBdatabase\fP \- پرس‌وجو یا به‌روزرسانی پایگاه(های) داده میزبان .IP \(bu 2 \fBall\fP \- پرس‌وجو یا به‌روزرسانی هم پیکربندی زمان اجرا و هم پایگاه(های) داده میزبان .IP \(bu 2 \fBdefault\fP \- پرس‌وجو یا به‌روزرسانی منبع داده پیش‌فرض میزبان \- بسته به دستور متفاوت است .UNINDENT .SS دستور \fBreservation\-add\fP .sp دستور \fBreservation\-add\fP امکان درج یک میزبان جدید را فراهم می‌کند. این دستور مجموعه‌ای از آرگومان‌ها را دریافت می‌کند که بسته به ماهیت رزرو میزبان متفاوت است. هر پارامتر مجاز در فایل پیکربندی که مربوط به رزرو میزبان باشد، در اینجا نیز مجاز است. برای جزئیات مربوط به رزروهای IPv4، بخش Host Reservations in DHCPv4 \%<#\:host-reservation-v4> را ببینید؛ برای رزروهای IPv6، بخش Host Reservations in DHCPv6 \%<#\:host-reservation-v6>\& را ببینید. پارامتر \fBsubnet\-id\fP اجباری است. از مقدار صفر (0) برای افزودن یک رزرو سراسری، یا شناسه (ID) زیرشبکه‌ای که رزرو باید به آن اضافه شود، استفاده کنید. این دستور می‌تواند به سادگیِ داشتن تنها دو مدخل اجباری باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-add\(dq, \(dqarguments\(dq: { \(dqreservation\(dq: { \(dqsubnet\-id\(dq: 1, \(dqhw\-address\(dq: \(dq1a:1b:1c:1d:1e:1f\(dq } } } .EE .UNINDENT .UNINDENT .sp با این حال، در این حالت هیچ منبعی به میزبان اختصاص داده نمی‌شود. یک آدرس IPv4 را می‌توان مانند این مثال اختصاص داد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-add\(dq, \(dqarguments\(dq: { \(dqreservation\(dq: { \(dqsubnet\-id\(dq: 1, \(dqhw\-address\(dq: \(dq1a:1b:1c:1d:1e:1f\(dq, \(dqip\-address\(dq: \(dq192.0.2.202\(dq } } } .EE .UNINDENT .UNINDENT .sp همچنین می‌تواند پارامترهای بسیار بیشتری را بپذیرد، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-add\(dq, \(dqarguments\(dq: { \(dqreservation\(dq: { \(dqsubnet\-id\(dq: 1, \(dqclient\-id\(dq: \(dq01:0a:0b:0c:0d:0e:0f\(dq, \(dqip\-address\(dq: \(dq192.0.2.205\(dq, \(dqnext\-server\(dq: \(dq192.0.2.1\(dq, \(dqserver\-hostname\(dq: \(dqhal9000\(dq, \(dqboot\-file\-name\(dq: \(dq/dev/null\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqdata\(dq: \(dq10.1.1.202,10.1.1.203\(dq } ], \(dqclient\-classes\(dq: [ \(dqspecial_snowflake\(dq, \(dqoffice\(dq ] } } } .EE .UNINDENT .UNINDENT .sp در اینجا یک مثال از رزرو پیچیده IPv6 آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-add\(dq, \(dqarguments\(dq: { \(dqreservation\(dq: { \(dqsubnet\-id\(dq: 1, \(dqduid\(dq: \(dq01:02:03:04:05:06:07:08:09:0A\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1:cafe::1\(dq ], \(dqprefixes\(dq: [ \(dq2001:db8:2:abcd::/64\(dq ], \(dqhostname\(dq: \(dqfoo.example.com\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqvendor\-opts\(dq, \(dqdata\(dq: \(dq4491\(dq }, { \(dqname\(dq: \(dqtftp\-servers\(dq, \(dqspace\(dq: \(dqvendor\-4491\(dq, \(dqdata\(dq: \(dq3000:1::234\(dq } ] } } } .EE .UNINDENT .UNINDENT .sp این دستور آرگومان \fBoperation\-target\fP را می‌پذیرد. به طور پیش‌فرض، رزرو را فقط به پایگاه داده میزبان‌ها اضافه می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-add\(dq, \(dqarguments\(dq: { \(dqreservation\(dq: {}, \(dqoperation\-target\(dq: \(dqall\(dq } } .EE .UNINDENT .UNINDENT .sp این دستور وضعیتی را بازمی‌گرداند که نشان‌دهنده موفقیت (result 0) یا شکست (result 1) است. یک دستور ناموفق همیشه شامل یک پارامتر text است که علت شکست را توضیح می‌دهد. در اینجا یک نمونه از افزودن موفقیت‌آمیز آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqHost added.\(dq } .EE .UNINDENT .UNINDENT .sp و در اینجا یک مثال از شکست آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 1, \(dqtext\(dq: \(dqMandatory \(aqsubnet\-id\(aq parameter missing.\(dq } .EE .UNINDENT .UNINDENT .sp از آنجا که انتظار می‌رود \fBreservation\-add\fP میزبان را ذخیره کند، پارامتر \fBhosts\-databases\fP باید در پیکربندی مشخص شده باشد و پایگاه‌های داده نباید در حالت فقط‌خواندنی (read\-only) اجرا شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 2.7.0 kea به بعد، یک رزرو خالی به صورت ضمنی سراسری است؛ یعنی اگر هیچ مدخل \fBsubnet\-id\fP وجود نداشته باشد و برای DHCPv4 پارامتر \fBip\-address\fP یا برای DHCPv6 پارامترهای \fBip\-addresses\fP و \fBprefixes\fP آدرس یا پیشوند رزروشده‌ای را مشخص نکنند، دستور معتبر است و یک رزرو میزبان سراسری (subnet\-id 0) اضافه می‌کند. .UNINDENT .UNINDENT.SS دستور \fBreservation\-get\fP .sp از \fBreservation\-get\fP می‌توان برای پرس‌وجوی پایگاه‌داده میزبان و بازیابی رزروهای موجود استفاده کرد. این دستور از دو نوع پارامتر پشتیبانی می‌کند: (\fBsubnet\-id\fP, \fBaddress\fP) یا (\fBsubnet\-id\fP, \fBidentifier\-type\fP, \fBidentifier\fP). نوع اول پرس‌وجو زمانی استفاده می‌شود که آدرس (چه IPv4 یا IPv6) مشخص است، اما جزئیات رزرو مشخص نیست. یک کاربرد رایج برای این نوع پرس‌وجو، بررسی رزرو بودن یک آدرس مشخص است. پرس‌وجوی دوم از شناسه‌ها استفاده می‌کند. برای بیشترین انعطاف‌پذیری، Kea اطلاعات شناسایی میزبان را به صورت یک جفت مقدار ذخیره می‌کند: نوع و شناسه واقعی. شناسه‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از \fB\(dqhw\-address\(dq\fP، \fB\(dqduid\(dq\fP، \fB\(dqcircuit\-id\(dq\fP، \fB\(dqclient\-id\(dq\fP و \fB\(dqflex\-id\(dq\fP\&. مقدار \fBsubnet\-id\fP اجباری است. برای دریافت یک رزرو سراسری، از مقدار صفر (0) استفاده کنید، یا شناسه زیرشبکه‌ای که رزرو متعلق به آن است را وارد نمایید. .sp یک نمونه دستور برای دریافت رزرو میزبان با یک جفت (\fBsubnet\-id\fP, \fBaddress\fP) به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 1, \(dqip\-address\(dq: \(dq192.0.2.202\(dq } } .EE .UNINDENT .UNINDENT .sp یک نمونه پرس‌وجو بر اساس (\fBsubnet\-id\fP, \fBidentifier\-type\fP, \fBidentifier\fP) به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 4, \(dqidentifier\-type\(dq: \(dqhw\-address\(dq, \(dqidentifier\(dq: \(dq01:02:03:04:05:06\(dq } } .EE .UNINDENT .UNINDENT .sp این دستور آرگومان \fBoperation\-target\fP را می‌پذیرد. به طور پیش‌فرض، رزرو را هم از حافظه موقت و هم از پایگاه‌داده میزبان‌ها دریافت می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 1, \(dqip\-address\(dq: \(dq192.0.2.202\(dq, \(dqoperation\-target\(dq: \(dqdatabase\(dq } } .EE .UNINDENT .UNINDENT .sp دستور \fBreservation\-get\fP معمولاً هنگامی که یک پرس‌وجو به درستی انجام شده باشد نتیجه 0 را برمی‌گرداند. به ویژه، زمانی که میزبان پیدا نشود، مقدار 0 بازگردانده می‌شود. اگر پرس‌وجو موفقیت‌آمیز باشد، پارامترهای میزبان بازگردانده می‌شوند. نمونه‌ای از پرس‌وجویی که میزبان را پیدا نکرده است به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqHost not found.\(dq } .EE .UNINDENT .UNINDENT .sp در اینجا نمونه‌ای از نتیجه بازگردانده شده در صورت یافتن موفقیت‌آمیز میزبان آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqclient\-classes\(dq: [ ], \(dqhostname\(dq: \(dqsomehost.example.org\(dq, \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqip\-address\(dq: \(dq192.0.2.100\(dq, \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqoption\-data\(dq: [ ], \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq, \(dqsubnet\-id\(dq: 4 }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dqHost found.\(dq } .EE .UNINDENT .UNINDENT .sp نمونه نتیجه بازگردانده شده در زمانی که پرس‌وجو ساختار نادرستی داشته باشد ممکن است به این شکل باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 1, \(dqtext\(dq: \(dqNo \(aqip\-address\(aq provided and \(aqidentifier\-type\(aq is either missing or not a string.\(dq } .EE .UNINDENT .UNINDENT.SS دستور \fBreservation\-get\-all\fP .sp \fBreservation\-get\-all\fP می‌تواند برای پرس‌وجو از پایگاه‌دادهٔ میزبان و دریافت تمام رزروها در یک زیرشبکهٔ مشخص به کار رود. این دستور از پارامترهایی استفاده می‌کند که \fBsubnet\-id\fP اجباری را فراهم می‌کنند\&. رزروهای سراسری میزبان می‌توانند با استفاده از مقدار صفر (0) برای \fBsubnet\-id\fP دریافت شوند. .sp برای نمونه، دریافت رزروهای میزبان برای زیرشبکهٔ 1: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-all\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp برخی میزبان‌های IPv4 را برمی‌گرداند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqhosts\(dq: [ { \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqclient\-classes\(dq: [ ], \(dqhostname\(dq: \(dqsomehost.example.org\(dq, \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqip\-address\(dq: \(dq192.0.2.100\(dq, \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqoption\-data\(dq: [ ], \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq, \(dqsubnet\-id\(dq: 1 }, { \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqclient\-classes\(dq: [ ], \(dqhostname\(dq: \(dqotherhost.example.org\(dq, \(dqhw\-address\(dq: \(dq01:02:03:04:05:ff\(dq, \(dqip\-address\(dq: \(dq192.0.2.200\(dq, \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqoption\-data\(dq: [ ], \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq, \(dqsubnet\-id\(dq: 1 }, ... ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq72 IPv4 host(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده‌شده توسط \fBreservation\-get\-all\fP می‌تواند بسیار طولانی باشد. سرور DHCP هنگام آماده‌سازی پاسخ برای \fBreservation\-get\-all\fP ترافیک DHCP را پردازش نمی‌کند، بنابراین اگر رزروهای زیادی در یک زیرشبکه وجود داشته باشد، این کار ممکن است مختل‌کننده باشد؛ با احتیاط استفاده کنید. برای استقرارهای بزرگ‌تر، لطفاً استفاده از \fBreservation\-get\-page\fP را به عنوان جایگزین در نظر بگیرید. .sp این دستور آرگومان \fBoperation\-target\fP را می‌پذیرد. به‌طور پیش‌فرض، رزروها را از هر دو حافظهٔ مقیم و پایگاه‌دادهٔ میزبان‌ها دریافت می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-all\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 1, \(dqoperation\-target\(dq: \(dqdatabase\(dq } } .EE .UNINDENT .UNINDENT .sp برای اطلاعات بیشتر، «دستور reservation\-get\-all» را ببینید\&. .SS دستور \fBreservation\-get\-page\fP .sp \fBreservation\-get\-page\fP می‌تواند برای پرس‌وجو از پایگاه‌دادهٔ میزبان و دریافت تمام رزروها در یک زیرشبکهٔ مشخص، به‌صورت صفحه‌بندی‌شده به کار رود. این دستور از پارامترهایی استفاده می‌کند که \fBsubnet\-id\fP اجباری را فراهم می‌کنند\&. برای دریافت رزروهای سراسری از مقدار صفر (0) استفاده کنید. دومین پارامتر اجباری، حد اندازهٔ صفحه است. پارامترهای اختیاری \fBsource\-index\fP و \fBfrom\-host\-id\fP که هر دو به‌طور پیش‌فرض 0 هستند، برای زنجیره‌سازی پرسمان‌های صفحه‌ای استفاده می‌شوند. از نسخهٔ 1.9.0 نرم‌افزار Kea، پارامتر \fBsubnet\-id\fP اختیاری است. .sp استفاده از پارامترهای \fBfrom\fP و \fBsource\-index\fP نیازمند توضیحات بیشتری است. برای فراخوانی اول، نباید این پارامترها مشخص شوند (یا باید صفر تعیین شوند). برای هرگونه فراخوانی بعدی، آنها باید روی مقادیر بازگردانده‌شده در فراخوانی‌های قبلی در نگاشت next شامل مقادیر \fBfrom\fP و \fBsource\-index\fP تنظیم گردند. فراخوانی‌های بعدی باید تا زمانی که همهٔ رزروها برگردانده شوند، ارسال گردند. پایان زمانی حاصل می‌شود که فهرست بازگردانده‌شده خالی باشد، تعداد 0 باشد، هیچ نگاشت next وجود نداشته باشد، و وضعیت نتیجهٔ 3 (empty) بازگردانده شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 پارامترهای \fBfrom\fP و \fBsource\-index\fP بازتاب‌دهندهٔ وضعیت درونی جست‌وجو هستند. نیازی به درک معنای آن‌ها نیست؛ تنها مقداری هستند که باید از یک پاسخ به پرسمان بعدی کپی شوند. با این حال، برای علاقه‌مندان، فیلد \fBfrom\fP یک نمایش ۶۴ بیتی از شناسهٔ میزبان است که توسط یک بک‌اند میزبان استفاده می‌شود. فیلد \fBsource\-index\fP یک نمایش درونی از چندین بک‌اند میزبان است: 0 برای نشان دادن میزبان‌های تعریف‌شده در یک فایل پیکربندی به کار می‌رود، و 1 نشان‌دهندهٔ نخستین بک‌اند پایگاه‌داده است. در برخی موارد نادر ممکن است بیش از یک بک‌اند پایگاه‌داده پیکربندی شده باشد، بنابراین احتمالاً مقدار 2 نیز وجود دارد. در هر صورت، Kea روی تمام بک‌اندهای پیکربندی‌شده پیمایش می‌کند. .UNINDENT .UNINDENT .sp برای نمونه، دریافت رزروهای میزبان برای زیرشبکهٔ 1 و درخواست صفحهٔ نخست می‌تواند به این صورت انجام شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-page\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 1, \(dqlimit\(dq: 10 } } .EE .UNINDENT .UNINDENT .sp از آنجا که این اولین فراخوانی است، \fBsource\-index\fP و \fBfrom\fP نباید مشخص شوند. آن‌ها روی مقادیر پیش‌فرض صفر خود تنظیم شده‌اند. .sp تعدادی میزبان همراه با اطلاعات برای دریافت صفحهٔ بعدی بازگردانده می‌شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqcount\(dq: 72, \(dqhosts\(dq: [ { \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqclient\-classes\(dq: [ ], \(dqhostname\(dq: \(dqsomehost.example.org\(dq, \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqip\-address\(dq: \(dq192.0.2.100\(dq, \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqoption\-data\(dq: [ ], \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq }, { \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqclient\-classes\(dq: [ ], \(dqhostname\(dq: \(dqotherhost.example.org\(dq, \(dqhw\-address\(dq: \(dq01:02:03:04:05:ff\(dq, \(dqip\-address\(dq: \(dq192.0.2.200\(dq, \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqoption\-data\(dq: [ ], \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq }, ... ], \(dqnext\(dq: { \(dqfrom\(dq: 1234567, \(dqsource\-index\(dq: 1 } }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq72 IPv4 host(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که فیلدهای \fBfrom\fP و \fBsource\-index\fP در پاسخ، داخل نگاشت next مشخص شده‌اند. این دو باید در دستور بعدی کپی شوند تا Kea کار را از همان جایی که دستور قبلی به پایان رسید ادامه دهد. برای دریافت صفحهٔ بعدی دستور زیر می‌تواند ارسال شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-page\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 1, \(dqsource\-index\(dq: 1, \(dqfrom\(dq: 1234567, \(dqlimit\(dq: 10 } } .EE .UNINDENT .UNINDENT .sp پاسخ شامل فهرستی از میزبان‌ها با فیلدهای به‌روزشدهٔ \fBsource\-index\fP و \fBfrom\fP خواهد بود. فراخوانی دستور را ادامه دهید تا آخرین صفحه دریافت شود. پاسخ آن به این شکل خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqcount\(dq: 0, \(dqhosts\(dq: [ ] }, \(dqresult\(dq: 3, \(dqtext\(dq: \(dq0 IPv4 host(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp این دستور آرگومان \fBoperation\-target\fP را نمی‌پذیرد. .sp این دستور پیچیده‌تر از \fBreservation\-get\-all\fP است، اما به کاربران اجازه می‌دهد فهرست‌های بزرگ‌تر رزرو میزبان را در بخش‌های کوچک‌تر دریافت کنند. برای استقرارهای کوچک با رزروهای اندک، استفاده از \fBreservation\-get\-all\fP ساده‌تر است\&..SS دستور \fBreservation\-get\-by\-address\fP .sp دستور \fBreservation\-get\-by\-address\fP می‌تواند برای پرس‌وجو از پایگاه داده میزبان و دریافت تمام رزروها برای یک نشانی IP مشخص یا یک پیشوند واگذارشده (بدون طول پیشوند)، در یک زیرشبکه تعیین‌شده یا در تمامی زیرشبکه‌ها استفاده شود. این دستور از پارامترهایی استفاده می‌کند که پارامتر اجباری \fBip\-address\fP و پارامترهای اختیاری \fBsubnet\-id\fP و \fBoperation\-target\fP را فراهم می‌آورند\&. .sp به عنوان مثال، دریافت رزروهای میزبان برای نشانی IPv4 با مقدار \(dq192.0.200.181\(dq در زیرشبکه ۱: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-by\-address\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.200.181\(dq, \(dqsubnet\-id\(dq: 1 }, \(dqservice\(dq: [ \(dqdhcp4\(dq ] } .EE .UNINDENT .UNINDENT .sp می‌تواند دو میزبان IPv4 را بازگرداند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqhosts\(dq: [ { \(dqboot\-file\-name\(dq: \(dq\(dq, \(dqclient\-classes\(dq: [], \(dqhostname\(dq: \(dq\(dq, \(dqhw\-address\(dq: \(dq99:99:99:99:99:01\(dq, \(dqip\-address\(dq: \(dq192.0.200.181\(dq, \(dqnext\-server\(dq: \(dq0.0.0.0\(dq, \(dqoption\-data\(dq: [], \(dqserver\-hostname\(dq: \(dq\(dq, \(dqsubnet\-id\(dq: 1 }, { \(dqboot\-file\-name\(dq: \(dq\(dq, \(dqcircuit\-id\(dq: \(dq1234\(dq, \(dqclient\-classes\(dq: [], \(dqhostname\(dq: \(dq\(dq, \(dqip\-address\(dq: \(dq192.0.200.181\(dq, \(dqnext\-server\(dq: \(dq0.0.0.0\(dq, \(dqoption\-data\(dq: [], \(dqserver\-hostname\(dq: \(dq\(dq, \(dqsubnet\-id\(dq: 1 } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 IPv4 host(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp برای جستجوی تمامی رزروها در همه زیرشبکه‌ها، کافی است از پارامتر \fBsubnet\-id\fP صرف‌نظر کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-by\-address\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.200.181\(dq }, \(dqservice\(dq: [ \(dqdhcp4\(dq ] } .EE .UNINDENT .UNINDENT .sp یک نمونه پاسخ می‌تواند به این صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqhosts\(dq: [ { \(dqboot\-file\-name\(dq: \(dq\(dq, \(dqclient\-classes\(dq: [], \(dqhostname\(dq: \(dq\(dq, \(dqhw\-address\(dq: \(dq99:99:99:99:99:02\(dq, \(dqip\-address\(dq: \(dq192.0.200.181\(dq, \(dqnext\-server\(dq: \(dq0.0.0.0\(dq, \(dqoption\-data\(dq: [], \(dqserver\-hostname\(dq: \(dq\(dq, \(dqsubnet\-id\(dq: 1 }, { \(dqboot\-file\-name\(dq: \(dq\(dq, \(dqcircuit\-id\(dq: \(dq1234\(dq, \(dqclient\-classes\(dq: [], \(dqhostname\(dq: \(dq\(dq, \(dqip\-address\(dq: \(dq192.0.200.181\(dq, \(dqnext\-server\(dq: \(dq0.0.0.0\(dq, \(dqoption\-data\(dq: [], \(dqserver\-hostname\(dq: \(dq\(dq, \(dqsubnet\-id\(dq: 1 }, { \(dqboot\-file\-name\(dq: \(dq\(dq, \(dqclient\-classes\(dq: [], \(dqhostname\(dq: \(dq\(dq, \(dqhw\-address\(dq: \(dq99:99:99:99:99:02\(dq, \(dqip\-address\(dq: \(dq192.0.200.181\(dq, \(dqnext\-server\(dq: \(dq0.0.0.0\(dq, \(dqoption\-data\(dq: [], \(dqserver\-hostname\(dq: \(dq\(dq, \(dqsubnet\-id\(dq: 0 }, { \(dqboot\-file\-name\(dq: \(dq\(dq, \(dqclient\-classes\(dq: [], \(dqhostname\(dq: \(dq\(dq, \(dqhw\-address\(dq: \(dq99:99:99:99:99:03\(dq, \(dqip\-address\(dq: \(dq192.0.200.181\(dq, \(dqnext\-server\(dq: \(dq0.0.0.0\(dq, \(dqoption\-data\(dq: [], \(dqserver\-hostname\(dq: \(dq\(dq, \(dqsubnet\-id\(dq: 2 } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq4 IPv4 host(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp هنگام استفاده از این دستور برای دریافت رزروهای میزبان DHCP6، می‌توان یک نشانی IPv6 یا یک پیشوند واگذارشده (delegated prefix) را به عنوان پارامتر \fBip\-address\fP ارائه داد. لطفاً توجه داشته باشید که این دستور در پیاده‌سازی فعلی طول پیشوند را به عنوان پارامتر نمی‌پذیرد. بنابراین، جستجو بر اساس نشانی IP مانند \fB2001:db8:2:cafe::\fP می‌تواند رزروهای میزبانی با پیشوندهای واگذارشده با طول‌های متفاوتی که با این جستجو مطابقت دارند را برگرداند. برای مثال: \fB2001:db8:2:cafe::/63\fP، \fB2001:db8:2:cafe::/64\fP و غیره. لطفاً مثال زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-by\-address\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq2001:db8:2:cafa::\(dq }, \(dqservice\(dq: [ \(dqdhcp6\(dq ] } .EE .UNINDENT .UNINDENT .sp پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqhosts\(dq: [ { \(dqclient\-classes\(dq: [], \(dqduid\(dq: \(dq01:02:03:04:05:06:07:88:98:fa\(dq, \(dqhostname\(dq: \(dqfoo.example.com\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1:cafe::2\(dq ], \(dqoption\-data\(dq: [], \(dqprefixes\(dq: [ \(dq2001:db8:2:abcd::/64\(dq, \(dq2001:db8:2:cafa::/63\(dq ], \(dqsubnet\-id\(dq: 8 }, { \(dqclient\-classes\(dq: [], \(dqduid\(dq: \(dq01:02:03:04:05:06:07:88:98:fb\(dq, \(dqhostname\(dq: \(dqfoo.example.com\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1:cafe::2\(dq ], \(dqoption\-data\(dq: [], \(dqprefixes\(dq: [ \(dq2001:db8:2:abcd::/64\(dq, \(dq2001:db8:2:cafa::/64\(dq ], \(dqsubnet\-id\(dq: 8 } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 IPv6 host(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp این دستور آرگومان \fBoperation\-target\fP را می‌پذیرد. به طور پیش‌فرض، این دستور رزرو را هم از فضای ذخیره‌سازی در حافظه (in-memory) و هم از پایگاه داده میزبان‌ها دریافت می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-by\-address\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.200.181\(dq, \(dqsubnet\-id\(dq: 1, \(dqoperation\-target\(dq: \(dqdatabase\(dq }, \(dqservice\(dq: [ \(dqdhcp4\(dq ] } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این دستور در موارد خاصی کاربرد دارد. به طور پیش‌فرض، داشتن بیش از یک رزرو میزبان برای یک نشانی IP یکسان در یک زیرشبکه معین مجاز نیست؛ همان‌طور که در Multiple Reservations for the Same IPv4 \%<#\:multiple-reservations-same-ip4> یا Multiple Reservations for the Same IPv6 \%<#\:multiple-reservations-same-ip6>\& توضیح داده شده است. به همین دلیل این دستور زمانی به کار می‌آید که پارامتر بولی \fBip\-reservations\-unique\fP روی \fBfalse\fP تنظیم شده باشد\&. کاربرد دیگر این دستور در زمان وجود زیرشبکه‌های دارای هم‌پوشانی با رزروهای نشانی IP یکسان (اما با شناسه‌های متفاوت) در زیرشبکه‌های مختلف است. .UNINDENT .UNINDENT.SS دستور \fBreservation\-get\-by\-hostname\fP .sp از \fBreservation\-get\-by\-hostname\fP می‌توان برای پرس‌وجو در پایگاه دادهٔ میزبان و واکشی تمام رزروها با یک نام میزبان مشخص یا در یک زیرشبکهٔ تعیین‌شده استفاده کرد. این دستور از پارامترهایی استفاده می‌کند که \fBhostname\fP اجباری و \fBsubnet\-id\fP اختیاری را فراهم می‌کنند\&. رزروهای سراسری میزبان را می‌توان با استفاده از مقدار صفر (0) برای \fBsubnet\-id\fP واکشی کرد. تطابق نام میزبان به بزرگی و کوچکی حروف حساس نیست. .sp برای نمونه، واکشی رزروهای میزبان برای \(dqfoobar\(dq در زیرشبکهٔ 1: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-by\-hostname\(dq, \(dqarguments\(dq: { \(dqhostname\(dq: \(dqfoobar.example.org\(dq, \(dqsubnet\-id\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp برخی از میزبان‌های IPv4 را بازمی‌گرداند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqhosts\(dq: [ { \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqclient\-classes\(dq: [ ], \(dqhostname\(dq: \(dqfoobar.example.org\(dq, \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqip\-address\(dq: \(dq192.0.2.100\(dq, \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqoption\-data\(dq: [ ], \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq }, { \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqclient\-classes\(dq: [ ], \(dqhostname\(dq: \(dqfoobar.example.org\(dq, \(dqhw\-address\(dq: \(dq01:02:03:04:05:ff\(dq, \(dqip\-address\(dq: \(dq192.0.2.200\(dq, \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqoption\-data\(dq: [ ], \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq }, ... ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq5 IPv4 host(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده شده توسط \fBreservation\-get\-by\-hostname\fP می‌تواند طولانی باشد، به‌ویژه زمانی که پاسخ‌ها به یک زیرشبکه محدود نشده باشند. .sp این دستور آرگومان \fBoperation\-target\fP را می‌پذیرد. به‌طور پیش‌فرض، رزرو را هم از حافظهٔ موقت و هم از پایگاه دادهٔ میزبان‌ها دریافت می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-by\-hostname\(dq, \(dqarguments\(dq: { \(dqhostname\(dq: \(dqfoobar.example.org\(dq, \(dqsubnet\-id\(dq: 1, \(dqoperation\-target\(dq: \(dqdatabase\(dq } } .EE .UNINDENT .UNINDENT .sp برای اطلاعات بیشتر، بخش دستور reservation\-get\-by\-hostname را ببینید\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگام استفاده از MySQL به‌عنوان بک‌اند میزبان، این دستور به این موضوع متکی است که ستون hostname در جدول hosts از یک چینش (collation) غیرحساس به حروف بزرگ و کوچک استفاده می‌کند، همان‌طور که در بخش MySQL \%<#\:mysql-database> از مستندات Kea Database Administration \%<#\:admin> توضیح داده شده است\&. .UNINDENT .UNINDENT .SS دستور \fBreservation\-get\-by\-id\fP .sp از \fBreservation\-get\-by\-id\fP می‌توان برای پرس‌وجو در پایگاه دادهٔ میزبان و واکشی تمام رزروها با یک شناسه‌گر مشخص (پارامترهای \fBidentifier\-type\fP و \fBidentifier\fP)، مستقل از زیرشبکه‌ها استفاده کرد. ساختار نحوی پارامترها همانند دستور \fBreservation\-get\fP است\&. برای جلوگیری از سردرگمی، امکان استفاده از پارامتر \fBsubnet\-id\fP وجود ندارد. این دستور از نسخهٔ 1.9.0 در Kea در دسترس است. .sp برای نمونه، واکشی رزروهای میزبان برای نشانی مک 01:02:03:04:05:06: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-by\-id\(dq, \(dqarguments\(dq: { \(dqidentifier\-type\(dq: \(dqhw\-address\(dq, \(dqidentifier\(dq: \(dq01:02:03:04:05:06\(dq } } .EE .UNINDENT .UNINDENT .sp برخی از میزبان‌های IPv4 را بازمی‌گرداند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqhosts\(dq: [ { \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqclient\-classes\(dq: [ ], \(dqhostname\(dq: \(dqfoo.example.org\(dq, \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqip\-address\(dq: \(dq192.0.2.100\(dq, \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqoption\-data\(dq: [ ], \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq, \(dqsubnet\-id\(dq: 123 }, { \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqclient\-classes\(dq: [ ], \(dqhostname\(dq: \(dqbar.example.org\(dq, \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqip\-address\(dq: \(dq192.0.2.200\(dq, \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqoption\-data\(dq: [ ], \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq, \(dqsubnet\-id\(dq: 345 }, ... ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq5 IPv4 host(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده شده توسط \fBreservation\-get\-by\-id\fP می‌تواند طولانی باشد، به‌ویژه زمانی که پاسخ‌ها به یک زیرشبکه محدود نشده باشند. .sp این دستور آرگومان \fBoperation\-target\fP را می‌پذیرد. به‌طور پیش‌فرض، رزرو را هم از حافظهٔ موقت و هم از پایگاه دادهٔ میزبان‌ها واکشی می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-get\-by\-id\(dq, \(dqarguments\(dq: { \(dqidentifier\-type\(dq: \(dqhw\-address\(dq, \(dqidentifier\(dq: \(dq01:02:03:04:05:06\(dq, \(dqoperation\-target\(dq: \(dqdatabase\(dq } } .EE .UNINDENT .UNINDENT .sp برای اطلاعات بیشتر، بخش دستور reservation\-get\-by\-id را ببینید\&..SS دستور \fBreservation\-del\fP .sp دستور \fBreservation\-del\fP می‌تواند برای حذف یک رزرو از پایگاه‌داده میزبان‌ها و/یا پیکربندی JSON استفاده شود. این دستور از دو نوع پارامتر پشتیبانی می‌کند: (\fBsubnet\-id\fP, \fBaddress\fP) یا (\fBsubnet\-id\fP, \fBidentifier\-type\fP, \fBidentifier\fP). نوع اول پرس‌وجو زمانی استفاده می‌شود که آدرس (خواه IPv4 یا IPv6) مشخص است، اما جزئیات رزرو مشخص نیست. یکی از کاربردهای رایج این نوع پرس‌وجو، حذف یک رزرو است (به عنوان مثال، یک آدرس مشخص دیگر نباید رزرو بماند). پرس‌وجوی دوم از شناسه‌ها استفاده می‌کند. برای حداکثر انعطاف‌پذیری، Kea اطلاعات شناسایی میزبان را به صورت یک جفت مقدار ذخیره می‌کند: نوع و شناسه واقعی. شناسه‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از \fB\(dqhw\-address\(dq\fP، \fB\(dqduid\(dq\fP، \fB\(dqcircuit\-id\(dq\fP، \fB\(dqclient\-id\(dq\fP و \fB\(dqflex\-id\(dq\fP\&. مقدار \fBsubnet\-id\fP الزامی است. از مقدار صفر (0) برای حذف یک رزرو سراسری (global)، یا شناسه زیرشبکه‌ای که رزرو باید از آن حذف شود، استفاده کنید. .sp یک نمونه دستور برای حذف یک رزرو میزبان با جفت (\fBsubnet\-id\fP, \fBaddress\fP) به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-del\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 1, \(dqip\-address\(dq: \(dq192.0.2.202\(dq } } .EE .UNINDENT .UNINDENT .sp یک نمونه حذف بر اساس (\fBsubnet\-id\fP, \fBidentifier\-type\fP, \fBidentifier\fP) به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-del\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 4, \(dqidentifier\-type\(dq: \(dqhw\-address\(dq, \(dqidentifier\(dq: \(dq01:02:03:04:05:06\(dq } } .EE .UNINDENT .UNINDENT .sp دستور \fBreservation\-del\fP در صورت موفقیت‌آمیز بودن حذف میزبان مقدار 0، و در صورت شکست مقدار 1 را برمی‌گرداند. در صورت بروز خطا، متن توضیحی ارائه می‌شود. در اینجا چند نمونه از نتایج احتمالی آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 1, \(dqtext\(dq: \(dqHost not deleted (not found).\(dq } .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqHost deleted.\(dq } .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 1, \(dqtext\(dq: \(dqUnable to delete a host because there is no hosts\-database configured.\(dq } .EE .UNINDENT .UNINDENT .sp این دستور آرگومان \fBoperation\-target\fP را می‌پذیرد. به طور پیش‌فرض، رزرو را فقط از پایگاه‌داده میزبان‌ها حذف می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-del\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 4, \(dqidentifier\-type\(dq: \(dqhw\-address\(dq, \(dqidentifier\(dq: \(dq01:02:03:04:05:06\(dq, \(dqoperation\-target\(dq: \(dqmemory\(dq } } .EE .UNINDENT .UNINDENT .SS دستور \fBreservation\-update\fP .sp دستور \fBreservation\-update\fP امکان به‌روزرسانی یک میزبان موجود را فراهم می‌کند. این دستور همان مجموعه آرگومان‌های \fBreservation\-add\fP را دریافت می‌کند و همچنین برای شناسایی میزبانی که به‌روزرسانی می‌شود، به یک شناسه میزبان و یک شناسه زیرشبکه (subnet ID) نیاز دارد. این دستور می‌تواند به سادگیِ داشتن تنها دو مدخل الزامی باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-update\(dq, \(dqarguments\(dq: { \(dqreservation\(dq: { \(dqsubnet\-id\(dq: 1, \(dqhw\-address\(dq: \(dq1a:1b:1c:1d:1e:1f\(dq } } } .EE .UNINDENT .UNINDENT .sp با این حال، در این حالت هیچ منبعی به میزبان اختصاص داده نمی‌شود. یک آدرس IPv4 را می‌توان مانند این مثال اختصاص داد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-update\(dq, \(dqarguments\(dq: { \(dqreservation\(dq: { \(dqsubnet\-id\(dq: 1, \(dqhw\-address\(dq: \(dq1a:1b:1c:1d:1e:1f\(dq, \(dqip\-address\(dq: \(dq192.0.2.202\(dq } } } .EE .UNINDENT .UNINDENT .sp همچنین می‌تواند پارامترهای بسیار بیشتری را بپذیرد، مانند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-update\(dq, \(dqarguments\(dq: { \(dqreservation\(dq: { \(dqsubnet\-id\(dq: 1, \(dqclient\-id\(dq: \(dq01:0a:0b:0c:0d:0e:0f\(dq, \(dqip\-address\(dq: \(dq192.0.2.205\(dq, \(dqnext\-server\(dq: \(dq192.0.2.1\(dq, \(dqserver\-hostname\(dq: \(dqhal9000\(dq, \(dqboot\-file\-name\(dq: \(dq/dev/null\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdomain\-name\-servers\(dq, \(dqdata\(dq: \(dq10.1.1.202,10.1.1.203\(dq } ], \(dqclient\-classes\(dq: [ \(dqoffice\(dq, \(dqspecial_snowflake\(dq ] } } } .EE .UNINDENT .UNINDENT .sp در اینجا نمونه‌ای از یک به‌روزرسانی رزرو پیچیده IPv6 آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqreservation\-update\(dq, \(dqarguments\(dq: { \(dqreservation\(dq: { \(dqsubnet\-id\(dq: 1, \(dqduid\(dq: \(dq01:02:03:04:05:06:07:08:09:0A\(dq, \(dqip\-addresses\(dq: [ \(dq2001:db8:1:cafe::1\(dq ], \(dqprefixes\(dq: [ \(dq2001:db8:2:abcd::/64\(dq ], \(dqhostname\(dq: \(dqfoo.example.com\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqvendor\-opts\(dq, \(dqdata\(dq: \(dq4491\(dq }, { \(dqname\(dq: \(dqtftp\-servers\(dq, \(dqspace\(dq: \(dqvendor\-4491\(dq, \(dqdata\(dq: \(dq3000:1::234\(dq } ] } } } .EE .UNINDENT .UNINDENT .sp دستور وضعیتی را بازمی‌گرداند که نشان‌دهنده موفقیت (نتیجه \fB0\fP) یا شکست (نتیجه \fB1\fP) است، و یک پارامتر متنی که موفقیت را تأیید کرده یا علت شکست را توضیح می‌دهد. در اینجا نمونه‌ای از یک به‌روزرسانی موفق آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqHost updated.\(dq } .EE .UNINDENT .UNINDENT .sp و در اینجا نمونه‌ای از یک شکست آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 1, \(dqtext\(dq: \(dqMandatory \(aqsubnet\-id\(aq parameter missing.\(dq } .EE .UNINDENT .UNINDENT .sp این دستور آرگومان \fBoperation\-target\fP را می‌پذیرد. به طور پیش‌فرض، رزرو را تنها به پایگاه‌داده میزبان‌ها اضافه می‌کند. از آنجا که انتظار می‌رود \fBreservation\-update\fP میزبان را ذخیره کند، پارامتر \fBhosts\-databases\fP باید در پیکربندی مشخص شده باشد، و اگر هدف عملیات پیکربندی JSON نباشد، پایگاه‌های داده نباید در حالت فقط‌خواندنی (read\-only) اجرا شوند. .sp همانند سایر دستورهای به‌روزرسانی و تنظیم، این دستور تمام محتویات مدخل را بازنویسی می‌کند. اگر میزبان قبلاً منبعی به آن اختصاص داده شده بود و دستور \fBreservation\-update\fP فاقد آن منبع باشد، آن منبع از پایگاه‌داده حذف می‌شود. اگر به‌روزرسانی افزایشی میزبان مد نظر باشد، این امر می‌تواند با اجرای دستور \fBreservation\-get\-by\-id\fP برای دریافت وضعیت فعلی میزبان، انتخاب میزبان از پاسخ، اصلاح آن به نتیجه مورد نظر و سپس اجرای دستور \fBreservation\-update\fP به همراه میزبان حاصل انجام گیرد..SS نکات کلی (General Mentions) .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 بک‌اندهای میزبان برای کتابخانه‌های قلابِ حافظهٔ پنهان میزبان (host cache) و RADIUS به دستورهایی که مجموعه‌ای از رزروهای میزبان را برمی‌گردانند، مانند \fBreservation\-get\-all\fP\&، پاسخ نمی‌دهند. در عوض باید از دستورهایی که یک مدخل میزبان را برمی‌گردانند یا دستورهای اختصاصی حافظهٔ پنهان میزبان استفاده شود. .UNINDENT .UNINDENT .SS \fBlibdhcp_lease_cmds.so\fP: دستورهای اجاره برای مدیریت آسان‌تر اجاره‌ها (Lease Commands for Easier Lease Management) .sp Kea به کاربران امکان می‌دهد اطلاعات اجاره (lease) را در چندین بک‌اند (memfile، MySQL و PostgreSQL) ذخیره کنند، و کتابخانهٔ Lease Commands رابطی فراهم می‌سازد که می‌تواند اجاره‌ها را به شیوه‌ای یکپارچه و ایمن دستکاری کند. به‌ویژه، انجام کارهایی را ممکن می‌سازد که پیش‌تر غیرممکن بودند: دستکاری اجاره در memfile در زمان اجرای Kea، بررسی صحت تغییرات (sanity check)، بررسی وجود اجاره، و حذف تمامی اجاره‌های متعلق به یک زیرشبکهٔ (subnet) خاص. این کتابخانهٔ قلاب همچنین می‌تواند خطاهای مبهم‌تر را شناسایی کند، مانند تلاش برای افزودن یک اجاره با یک \fBsubnet\-id\fP که در پیکربندی وجود ندارد، یا پیکربندی یک اجاره برای استفاده از نشانی‌ای که خارج از زیرشبکهٔ تعیین‌شده قرار دارد. این کتابخانه همچنین روشی غیربرنامه‌نویسی برای مدیریت بافتارهای کاربری (user contexts) مرتبط با اجاره‌ها ارائه می‌دهد. .sp از Kea 2.7.7، این کتابخانه همچنین از \fBbinding\-variables\fP پشتیبانی می‌کند. متغیرهای مقیدسازی (Binding variables) به کاربر امکان می‌دهند مقادیر سفارشی را برای هر اجاره ذخیره کند. این متغیرها در این بخش بررسی شده‌اند: Binding Variables\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_lease_cmds.so\fP بخشی از کد متن‌باز است و در دسترس تمام کاربران Kea قرار دارد. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرایند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp موقعیت‌های فراوانی وجود دارد که در آن‌ها یک دستور مدیریتی می‌تواند مفید باشد؛ برای نمونه، در زمان مهاجرت میان سرورها یا ارائه‌دهندگان مختلف، هنگامی که یک شبکهٔ خاص در حال از رده خارج شدن است، یا زمانی که دستگاهی قطع شده و مدیر سیستم می‌داند که دیگر بازنخواهد گشت. پرس‌وجوهای \fBget\fP ممکن است برای خودکارسازی برخی وظایف مدیریتی و نظارتی مفید باشند، و همچنین می‌توانند به‌عنوان گام‌های مقدماتی برای به‌روزرسانی و حذف اجاره‌ها عمل کنند. .sp این کتابخانه دستورهای زیر را ارائه می‌دهد: .INDENT 0.0 .IP \(bu 2 \fBlease4\-add\fP \- یک اجارهٔ IPv4 جدید اضافه می‌کند. .IP \(bu 2 \fBlease6\-add\fP \- یک اجارهٔ IPv6 جدید اضافه می‌کند. .IP \(bu 2 \fBlease6\-bulk\-apply\fP \- چندین اجارهٔ IPv6 را در یک تراکنش منفرد ایجاد، به‌روزرسانی، و/یا حذف می‌کند. .IP \(bu 2 \fBlease4\-get\fP \- بررسی می‌کند که آیا یک اجارهٔ IPv4 با پارامترهای مشخص‌شده وجود دارد یا خیر و در صورت وجود آن را برمی‌گرداند. .IP \(bu 2 \fBlease6\-get\fP \- بررسی می‌کند که آیا یک اجارهٔ IPv6 با پارامترهای مشخص‌شده وجود دارد یا خیر و در صورت وجود آن را برمی‌گرداند. .IP \(bu 2 \fBlease4\-get\-all\fP \- تمام اجاره‌های IPv4 یا تمام اجاره‌های IPv4 زیرشبکه‌های مشخص‌شده را برمی‌گرداند. .IP \(bu 2 \fBlease6\-get\-all\fP \- تمام اجاره‌های IPv6 یا تمام اجاره‌های IPv6 زیرشبکه‌های مشخص‌شده را برمی‌گرداند. .IP \(bu 2 \fBlease4\-get\-page\fP \- مجموعه‌ای (\(dqصفحه\(dq) از اجاره‌ها را از فهرست تمامی اجاره‌های IPv4 در پایگاه‌داده برمی‌گرداند. با پیمایش صفحات می‌توان تمامی اجاره‌ها را بازیابی کرد. .IP \(bu 2 \fBlease6\-get\-page\fP \- مجموعه‌ای (\(dqصفحه\(dq) از اجاره‌ها را از فهرست تمامی اجاره‌های IPv6 در پایگاه‌داده برمی‌گرداند. با پیمایش صفحات می‌توان تمامی اجاره‌ها را بازیابی کرد. .IP \(bu 2 \fBlease4\-get\-by\-hw\-address\fP \- تمام اجاره‌های IPv4 با نشانی سخت‌افزاری مشخص‌شده را برمی‌گرداند. .IP \(bu 2 \fBlease6\-get\-by\-hw\-address\fP \- تمام اجاره‌های IPv6 با نشانی سخت‌افزاری مشخص‌شده را برمی‌گرداند. .IP \(bu 2 \fBlease4\-get\-by\-client\-id\fP \- تمام اجاره‌های IPv4 با \fBclient\-id\fP مشخص‌شده را برمی‌گرداند. .IP \(bu 2 \fBlease6\-get\-by\-duid\fP \- تمام اجاره‌های IPv6 با DUID مشخص‌شده را برمی‌گرداند. .IP \(bu 2 \fBlease4\-get\-by\-state\fP \- تمام اجاره‌های IPv4 با وضعیت مشخص‌شده را برمی‌گرداند. .IP \(bu 2 \fBlease6\-get\-by\-state\fP \- تمام اجاره‌های IPv6 با وضعیت مشخص‌شده را برمی‌گرداند. .IP \(bu 2 \fBlease4\-get\-by\-hostname\fP \- تمام اجاره‌های IPv4 با نام میزبان مشخص‌شده را برمی‌گرداند. .IP \(bu 2 \fBlease6\-get\-by\-hostname\fP \- تمام اجاره‌های IPv6 با نام میزبان مشخص‌شده را برمی‌گرداند. .IP \(bu 2 \fBlease4\-del\fP \- یک اجارهٔ IPv4 با پارامترهای مشخص‌شده را حذف می‌کند. .IP \(bu 2 \fBlease6\-del\fP \- یک اجارهٔ IPv6 با پارامترهای مشخص‌شده را حذف می‌کند. .IP \(bu 2 \fBlease4\-update\fP \- یک اجارهٔ IPv4 موجود را به‌روزرسانی (جایگزین) می‌کند. .IP \(bu 2 \fBlease6\-update\fP \- یک اجارهٔ IPv6 موجود را به‌روزرسانی (جایگزین) می‌کند. .IP \(bu 2 \fBlease4\-wipe\fP \- تمام اجاره‌ها را از یک زیرشبکهٔ IPv4 خاص یا از تمام زیرشبکه‌ها حذف می‌کند. .IP \(bu 2 \fBlease6\-wipe\fP \- تمام اجاره‌ها را از یک زیرشبکهٔ IPv6 خاص یا از تمام زیرشبکه‌ها حذف می‌کند. .IP \(bu 2 \fBlease4\-resend\-ddns\fP \- درخواست به‌روزرسانی مدخل‌های DNS را برای یک اجارهٔ موجود دوباره ارسال می‌کند. .IP \(bu 2 \fBlease6\-resend\-ddns\fP \- درخواست به‌روزرسانی مدخل‌های DNS را برای یک اجارهٔ موجود دوباره ارسال می‌کند. .IP \(bu 2 \fBlease4\-write\fP \- پایگاه‌دادهٔ اجاره‌های memfile مربوط به IPv4 را درون یک فایل می‌نویسد. .IP \(bu 2 \fBlease6\-write\fP \- پایگاه‌دادهٔ اجاره‌های memfile مربوط به IPv6 را درون یک فایل می‌نویسد. .IP \(bu 2 \fBsflq\-pool4\-rebuild\fP \- یک استخر SFLQ مربوط به IPv4 را در بک‌اند اجاره بازسازی می‌کند. .IP \(bu 2 \fBsflq\-pool6\-rebuild\fP \- یک استخر SFLQ مربوط به IPv6 را در بک‌اند اجاره بازسازی می‌کند. .IP \(bu 2 \fBsflq\-pool4\-get\-all\fP \- تمام استخرهای SFLQ مربوط به IPv4 را از بک‌اند اجاره واکشی می‌کند. .IP \(bu 2 \fBsflq\-pool6\-get\-all\fP \- تمام استخرهای SFLQ مربوط به IPv6 را از بک‌اند اجاره واکشی می‌کند. .IP \(bu 2 \fBsflq\-pool4\-get\-by\-subnet\fP \- تمام استخرهای SFLQ مربوط به IPv4 متعلق به یک زیرشبکه را از بک‌اند اجاره واکشی می‌کند. .IP \(bu 2 \fBsflq\-pool6\-get\-by\-subnet\fP \- تمام استخرهای SFLQ مربوط به IPv6 متعلق به یک زیرشبکه را از بک‌اند اجاره واکشی می‌کند. .IP \(bu 2 \fBsflq\-pool4\-get\-by\-range\fP \- تمام استخرهای SFLQ مربوط به IPv4 که با یک محدودهٔ نشانی هم‌پوشانی دارند را از بک‌اند اجاره واکشی می‌کند. .IP \(bu 2 \fBsflq\-pool6\-get\-by\-range\fP \- تمام استخرهای SFLQ مربوط به IPv6 که با یک محدودهٔ نشانی هم‌پوشانی دارند را از بک‌اند اجاره واکشی می‌کند. .IP \(bu 2 \fBsflq\-pool4\-del\fP \- یک استخر SFLQ مربوط به IPv4 مطابق با یک محدودهٔ نشانی را از بک‌اند اجاره حذف می‌کند. .IP \(bu 2 \fBsflq\-pool6\-del\fP \- یک استخر SFLQ مربوط به IPv6 مطابق با یک محدودهٔ نشانی را از بک‌اند اجاره حذف می‌کند. .UNINDENT .sp تمامی دستورها از نحو JSON استفاده می‌کنند و می‌توان آن‌ها را از طریق کانال کنترل (ببینید Management API \%<#\:ctrl-channel>) صادر کرد. .sp این کتابخانه را می‌توان به همان شیوهٔ سایر کتابخانه‌های قلاب بارگذاری کرد و هیچ پارامتری دریافت نمی‌کند. این کتابخانه از هر دو سرور DHCPv4 و DHCPv6 پشتیبانی می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq }, ... ] } .EE .UNINDENT .UNINDENT.SS دستورهای \fBlease4\-add\fP و \fBlease6\-add\fP .sp دستورهای \fBlease4\-add\fP و \fBlease6\-add\fP امکان ایجاد یک اجاره (lease) جدید را فراهم می‌کنند. به طور معمول Kea هنگامی که دستگاه جدیدی را برای نخستین بار مشاهده می‌کند یک اجاره ایجاد می‌نماید؛ با این حال، گاهی ممکن است ایجاد دستی اجاره سودمند باشد. دستور \fBlease4\-add\fP حداقل به دو پارامتر نیاز دارد: یک نشانی IPv4 و یک شناسه، یعنی نشانی سخت‌افزاری (MAC). پارامتر سوم، \fBsubnet\-id\fP، اختیاری است. اگر \fBsubnet\-id\fP مشخص نشده باشد یا مقدار مشخص‌شده 0 باشد، Kea تلاش می‌کند با اجرای یک فرایند انتخاب زیرشبکه، مقدار آن را تعیین کند. با این حال، در صورت تعیین، مقدار آن باید با زیرشبکه موجود همخوانی داشته باشد. ساده‌ترین فراخوانی موفق ممکن است به شکل زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-add\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.2.202\(dq, \(dqhw\-address\(dq: \(dq1a:1b:1c:1d:1e:1f\(dq } } .EE .UNINDENT .UNINDENT .sp دستور \fBlease6\-add\fP به سه پارامتر نیاز دارد: یک نشانی IPv6، یک مقدار IAID (شناسه ارتباط هویتی، مقداری که توسط کلاینت‌ها ارسال می‌شود)، و یک DUID. همانند \fBlease4\-add\fP، پارامتر \fBsubnet\-id\fP اختیاری است. اگر \fBsubnet\-id\fP مشخص نشده باشد یا مقدار ارائه‌شده 0 باشد، Kea تلاش می‌کند با اجرای یک فرایند انتخاب زیرشبکه مقدار آن را تعیین کند. با این حال، در صورت مشخص شدن، مقدار آن باید با زیرشبکه موجود مطابقت داشته باشد. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-add\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 66, \(dqip\-address\(dq: \(dq2001:db8::3\(dq, \(dqduid\(dq: \(dq1a:1b:1c:1d:1e:1f:20:21:22:23:24\(dq, \(dqiaid\(dq: 1234 } } .EE .UNINDENT .UNINDENT .sp دستور \fBlease6\-add\fP همچنین می‌تواند برای افزودن اجاره‌ها برای پیشوندهای IPv6 استفاده شود. در این حالت سه پارامتر دیگر وجود دارد که باید مشخص شوند: \fBsubnet\-id\fP، \fBtype\fP (تنظیم‌شده بر روی \(dqIA_PD\(dq)، و طول پیشوند. پیشوند اصلی با استفاده از فیلد \fBip\-address\fP تنظیم می‌شود. توجه داشته باشید که Kea نمی‌تواند مقادیر \fBsubnet\-id\fP را برای پیشوندها حدس بزند؛ این مقادیر باید صریحاً مشخص شوند. برای نمونه، برای پیکربندی یک اجاره برای پیشوند 2001:db8:abcd::/48، می‌توان از دستور زیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-add\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 66, \(dqtype\(dq: \(dqIA_PD\(dq, \(dqip\-address\(dq: \(dq2001:db8:abcd::\(dq, \(dqprefix\-len\(dq: 48, \(dqduid\(dq: \(dq1a:1b:1c:1d:1e:1f:20:21:22:23:24\(dq, \(dqiaid\(dq: 1234 } } .EE .UNINDENT .UNINDENT .sp این دستورها می‌توانند چندین پارامتر اختیاری اضافی دریافت کنند: .INDENT 0.0 .IP \(bu 2 \fBvalid\-lft\fP \- طول عمر اجاره را بر حسب ثانیه مشخص می‌کند. در صورت عدم تعیین، از مقدار پیکربندی‌شده در زیرشبکه مربوط به \fBsubnet\-id\fP مشخص‌شده استفاده می‌شود. .IP \(bu 2 \fBexpire\fP \- یک مهر زمانی از زمان انقضای اجاره بر حسب قالب یونیکس (ثانیه‌ها از ۱ ژانویه ۱۹۷۰) ایجاد می‌کند. در صورت عدم تعیین، مقدار پیش‌فرض زمان فعلی به علاوه طول عمر اجاره (مقدار \fBvalid\-lft\fP) خواهد بود. .IP \(bu 2 \fBfqdn\-fwd\fP \- مشخص می‌کند که آیا اجاره باید طوری علامت‌گذاری شود که گویی یک به‌روزرسانی مستقیم DNS انجام شده است یا خیر. این مورد فقط بر داده‌های ذخیره‌شده در پایگاه‌داده اجاره اثر می‌گذارد و هیچ به‌روزرسانی DNS انجام نخواهد شد. در صورت پیکربندی، هنگام حذف اجاره به دلیل انقضا یا آزادسازی توسط یک کلاینت، یک به‌روزرسانی DNS برای حذف رکوردهای A یا AAAA انجام خواهد شد. در صورت عدم تعیین، مقدار پیش‌فرض \fBfalse\fP است. در صورتی که \fBfqdn\-fwd\fP بر روی \fBtrue\fP تنظیم شده باشد، پارامتر hostname باید مشخص گردد. .IP \(bu 2 \fBfqdn\-rev\fP \- مشخص می‌کند که آیا اجاره باید طوری علامت‌گذاری شود که گویی یک به‌روزرسانی معکوس DNS انجام شده است یا خیر. این مورد فقط بر داده‌های ذخیره‌شده در پایگاه‌داده اجاره اثر می‌گذارد و هیچ به‌روزرسانی DNS انجام نخواهد شد. در صورت پیکربندی، هنگام حذف اجاره به دلیل انقضا یا آزادسازی توسط یک کلاینت، یک به‌روزرسانی DNS برای حذف رکورد PTR انجام خواهد شد. در صورت عدم تعیین، مقدار پیش‌فرض \fBfalse\fP است. در صورتی که \fBfqdn\-fwd\fP بر روی \fBtrue\fP تنظیم شده باشد، پارامتر hostname باید مشخص گردد. .IP \(bu 2 \fBhostname\fP \- نام میزبان (hostname) مرتبط با این اجاره را مشخص می‌کند. در صورتی که هر یک از \fBfqdn\-fwd\fP یا \fBfqdn\-rev\fP بر روی \fBtrue\fP تنظیم شده باشند، مقدار آن نباید خالی باشد. در صورت عدم تعیین، مقدار پیش‌فرض یک رشته خالی است. .IP \(bu 2 \fBhw\-address\fP \- به صورت اختیاری نشانی سخت‌افزاری (MAC) را برای یک اجاره IPv6 مشخص می‌کند. این پارامتر برای اجاره IPv4 اجباری است. .IP \(bu 2 \fBclient\-id\fP \- به صورت اختیاری یک شناسه کلاینت را برای یک اجاره IPv4 مشخص می‌کند. .IP \(bu 2 \fBpreferred\-lft\fP \- به صورت اختیاری طول عمر ترجیحی را برای اجاره‌های IPv6 مشخص می‌کند. در صورت عدم تعیین، از مقدار پیکربندی‌شده برای زیرشبکه متناظر با \fBsubnet\-id\fP مشخص‌شده استفاده می‌شود. این پارامتر هنگام افزودن اجاره IPv4 استفاده نمی‌شود. .IP \(bu 2 \fBstate\fP \- وضعیت یک اجاره افزوده‌شده را مشخص می‌کند که می‌تواند 0 برای \fBdefault\fP، 1 برای \fBdeclined\fP، 2 برای \fBexpired\-reclaimed\fP و 3 برای وضعیت \fBreleased\fP باشد. هر مقدار دیگری باعث خطا می‌شود. استفاده از 1 برای نوع اجاره \fB\(dqIA_PD\(dq\fP غیرمجاز است و رد خواهد شد. .IP \(bu 2 \fBuser\-context\fP \- بافت کاربری (user context) مرتبط با این اجاره را مشخص می‌کند. این مقدار باید یک نگاشت JSON باشد. .UNINDENT .sp در اینجا نمونه‌ای از یک افزودن اجاره نسبتاً پیچیده آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-add\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 66, \(dqip\-address\(dq: \(dq2001:db8::3\(dq, \(dqduid\(dq: \(dq01:02:03:04:05:06:07:08\(dq, \(dqiaid\(dq: 1234, \(dqhw\-address\(dq: \(dq1a:1b:1c:1d:1e:1f\(dq, \(dqpreferred\-lft\(dq: 500, \(dqvalid\-lft\(dq: 1000, \(dqexpire\(dq: 12345678, \(dqfqdn\-fwd\(dq: true, \(dqfqdn\-rev\(dq: true, \(dqstate\(dq: 0, \(dqhostname\(dq: \(dqurania.example.org\(dq, \(dquser\-context\(dq: { \(dqversion\(dq: 1 } } } .EE .UNINDENT .UNINDENT .sp این دستور وضعیتی را برمی‌گرداند که نشان‌دهنده موفقیت (نتیجه 0) یا شکست (نتیجه 1) است. دستور شکست‌خورده همیشه شامل یک پارامتر متنی است که علت شکست را شرح می‌دهد. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqLease added.\(dq } .EE .UNINDENT .UNINDENT .sp نمونه شکست: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 1, \(dqtext\(dq: \(dqmissing parameter \(aqip\-address\(aq (:3:19)\(dq } .EE .UNINDENT .UNINDENT.SS دستور \fBlease6\-bulk\-apply\fP .sp دستور \fBlease6\-bulk\-apply\fP برای رفع افت کارایی در حالت دسترس‌پذیری بالا (High\-Availability) پیاده‌سازی شده است؛ در این حالت زمانی که چندین اجارهٔ آدرس و/یا پیشوند تخصیص داده می‌شود، یک تراکنش منفرد DHCPv6 منجر به ارسال چندین به‌روزرسانی اجاره به کارگزار همتا (partner) می‌گردد. حالتی را در نظر بگیرید که یک کلاینت DHCPv6 درخواست تخصیص دو آدرس IPv6 و دو پیشوند IPv6 را می‌دهد: این امر ممکن است منجر به تخصیص چهار اجاره شود. علاوه‌بر این، DHCPv6 ممکن است در مرحلهٔ تمدید (renew) یا اتصال مجدد (rebind)، آدرسی متفاوت از آدرس درخواستی کلاینت اختصاص دهد و اجاره‌هایی را که پیش‌تر توسط این کلاینت استفاده می‌شدند، حذف کند. در این حالت شش تغییر اجاره میان همتاهای HA ارسال می‌شود. ارسال این به‌روزرسانی‌ها در قالب دستورهای مجزا، مثلاً از طریق \fBlease6\-update\fP، بسیار ناکارآمد است و تأخیرهای غیرضروری در ارتباطات، هم میان همتاهای HA و هم در ارسال پاسخ به کلاینت DHCPv6، ایجاد می‌کند. .sp دستور \fBlease6\-bulk\-apply\fP با تجمیع تمام تغییرات اجاره \- چه اجاره‌های حذف‌شده و چه اجاره‌های جدید یا به‌روزرسانی‌شده \- در قالب یک دستور واحد با این مشکل مقابله می‌کند. کارگزار دریافت‌کننده روی اجاره‌های حذف‌شده پیمایش کرده و آن‌ها را از پایگاه دادهٔ اجاره‌های خود حذف می‌کند. سپس، روی اجاره‌های جدید/به‌روزرسانی‌شده پیمایش کرده و آن‌ها را به پایگاه داده اضافه نموده یا در صورت وجود، به‌روزرسانی می‌کند. .sp اگرچه دسترس‌پذیری بالا (High Availability) کاربرد اصلی این دستور است، اما در تمامی مواردی که ارسال چندین تغییر اجاره در قالب یک دستور واحد مد نظر باشد، می‌توان آزادانه از آن استفاده کرد. .sp در مثال زیر، دو اجاره را حذف کرده و دو اجارهٔ دیگر را در پایگاه داده اضافه یا به‌روزرسانی می‌کنیم: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-bulk\-apply\(dq, \(dqarguments\(dq: { \(dqdeleted\-leases\(dq: [ { \(dqip\-address\(dq: \(dq2001:db8:abcd::\(dq, \(dqtype\(dq: \(dqIA_PD\(dq, ... }, { \(dqip\-address\(dq: \(dq2001:db8:abcd::234\(dq, \(dqtype\(dq: \(dqIA_NA\(dq, ... } ], \(dqleases\(dq: [ { \(dqsubnet\-id\(dq: 66, \(dqip\-address\(dq: \(dq2001:db8:cafe::\(dq, \(dqtype\(dq: \(dqIA_PD\(dq, ... }, { \(dqsubnet\-id\(dq: 66, \(dqip\-address\(dq: \(dq2001:db8:abcd::333\(dq, \(dqtype\(dq: \(dqIA_NA\(dq, ... } ] } } .EE .UNINDENT .UNINDENT .sp اگر هر یک از اجاره‌ها ساختار ناصحیحی داشته باشند (malformed)، هیچ تغییری در پایگاه دادهٔ اجاره‌ها اعمال نمی‌شود. اگر اجاره‌ها ساختار معتبری داشته باشند اما در اعمال هر یک از تغییرات اجاره در پایگاه داده خطایی رخ دهد، پردازش دستور برای سایر اجاره‌ها ادامه می‌یابد. تمام اجاره‌هایی که دستور نتوانسته تغییرات آن‌ها را در پایگاه داده اعمال کند، در پاسخ فهرست می‌شوند. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqBulk apply of 2 IPv6 leases completed\(dq, \(dqarguments\(dq: { \(dqfailed\-deleted\-leases\(dq: [ { \(dqip\-address\(dq: \(dq2001:db8:abcd::\(dq, \(dqtype\(dq: \(dqIA_PD\(dq, \(dqresult\(dq: 3, \(dqerror\-message\(dq: \(dqno lease found\(dq } ], \(dqfailed\-leases\(dq: [ { \(dqip\-address\(dq: \(dq2001:db8:cafe::\(dq, \(dqtype\(dq: \(dqIA_PD\(dq, \(dqresult\(dq: 1, \(dqerror\-message\(dq: \(dqunable to communicate with the lease database\(dq } ] } } .EE .UNINDENT .UNINDENT .sp پاسخ بالا نشان می‌دهد که کتابخانهٔ قلاب (hook library) نتوانسته است اجارهٔ مربوط به پیشوند \(dq2001:db8:abcd::\(dq را حذف کرده و اجارهٔ مربوط به پیشوند \(dq2001:db8:cafe::\(dq را اضافه یا به‌روزرسانی کند. با این حال، همان‌طور که در پیام متنی مشخص است، دو تغییر اجارهٔ دیگر اعمال شده‌اند. مقدار \fBresult\fP ثابتی از وضعیت است که نوع خطای رخ‌داده برای اجارهٔ مشخص را نشان می‌دهد. معانی کدهای بازگردانده‌شده همانند نتایج بازگردانده‌شده برای دستورها است. به‌ویژه، نتیجهٔ 1 نشان‌دهندهٔ خطا در حین پردازش اجاره است، مانند خطای ارتباط با پایگاه داده. نتیجهٔ 3 نشان می‌دهد که تلاش برای حذف اجاره ناموفق بوده است زیرا چنین اجاره‌ای وجود ندارد (یک نتیجهٔ خالی). .SS دستورهای \fBlease4\-get\fP و \fBlease6\-get\fP .sp از دستورهای \fBlease4\-get\fP و \fBlease6\-get\fP می‌توان برای پرس‌وجوی پایگاه دادهٔ اجاره و بازیابی اجاره‌های موجود استفاده کرد. دستور \fBlease4\-get\fP از دو نوع پارامتر پشتیبانی می‌کند: (\fBaddress\fP) یا (\fBsubnet\-id\fP، \fBidentifier\-type\fP، \fBidentifier\fP). همچنین برای \fBlease6\-get\fP دو نوع وجود دارد: (\fBaddress\fP، \fBtype\fP) یا (\fBsubnet\-id\fP، \fBidentifier\-type\fP، \fBidentifier\fP، \fBIAID\fP، \fBtype\fP). نوع اول پرس‌وجو زمانی استفاده می‌شود که آدرس (چه IPv4 و چه IPv6) مشخص است، اما جزئیات اجاره مشخص نیست؛ یکی از موارد کاربرد رایج این نوع پرس‌وجو پی بردن به این است که آیا آدرس مورد نظر در حال استفاده است یا خیر. پرس‌وجوی دوم از شناسه‌ها استفاده می‌کند؛ شناسه‌هایی که در حال حاضر برای اجاره‌ها پشتیبانی می‌شوند عبارتند از: \fB\(dqhw\-address\(dq\fP (فقط IPv4)، \fB\(dqclient\-id\(dq\fP (فقط IPv4) و \fB\(dqduid\(dq\fP (فقط IPv6). .sp یک نمونه دستور \fBlease4\-get\fP برای دریافت اجاره با استفاده از آدرس IPv4: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-get\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.2.1\(dq } } .EE .UNINDENT .UNINDENT .sp یک نمونه از پرس‌وجوی \fBlease6\-get\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-get\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq2001:db8:1234:ab::\(dq, \(dqtype\(dq: \(dqIA_PD\(dq } } .EE .UNINDENT .UNINDENT .sp یک نمونه پرس‌وجو بر اساس \fB\(dqhw\-address\(dq\fP برای یک اجارهٔ IPv4 به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-get\(dq, \(dqarguments\(dq: { \(dqidentifier\-type\(dq: \(dqhw\-address\(dq, \(dqidentifier\(dq: \(dq08:08:08:08:08:08\(dq, \(dqsubnet\-id\(dq: 44 } } .EE .UNINDENT .UNINDENT .sp یک نمونه پرس‌وجو بر اساس \fB\(dqclient\-id\(dq\fP برای یک اجارهٔ IPv4 به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-get\(dq, \(dqarguments\(dq: { \(dqidentifier\-type\(dq: \(dqclient\-id\(dq, \(dqidentifier\(dq: \(dq01:01:02:03:04:05:06\(dq, \(dqsubnet\-id\(dq: 44 } } .EE .UNINDENT .UNINDENT .sp یک نمونه پرس‌وجو بر اساس (\fBsubnet\-id\fP، \fBidentifier\-type\fP، \fBidentifier\fP، \fBiaid\fP، \fBtype\fP) برای یک اجارهٔ IPv6: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-get\(dq, \(dqarguments\(dq: { \(dqidentifier\-type\(dq: \(dqduid\(dq, \(dqidentifier\(dq: \(dq08:08:08:08:08:08\(dq, \(dqiaid\(dq: 1234567, \(dqtype\(dq: \(dqIA_NA\(dq, \(dqsubnet\-id\(dq: 44 } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBtype\fP اختیاری است. مقادیر پشتیبانی‌شده عبارتند از: \fBIA_NA\fP (آدرس غیرموقت) و \fBIA_PD\fP (پیشوند IPv6). در صورت عدم تعیین، \fBIA_NA\fP در نظر گرفته می‌شود. .sp دستورهای \fBlease4\-get\fP و \fBlease6\-get\fP در صورت یافتن، نشانگری از نتیجهٔ عملیات و جزئیات اجاره را بازمی‌گردانند. نتیجه دارای یکی از مقادیر زیر است: 0 (موفقیت)، 1 (خطا)، یا 3 (خالی). نتیجهٔ خالی بدین معناست که پرس‌وجو به‌درستی انجام شده، اما شیء مورد نظر (در اینجا یک اجاره) یافت نشده است. در صورت یافت شدن، پارامترهای اجاره در قالب آرگومان‌ها بازگردانده می‌شوند. مقدار \fBclient\-id\fP در صورت خالی بودن بازگردانده نمی‌شود. .sp یک نمونه نتیجهٔ بازگردانده‌شده در زمانی که میزبان پیدا شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqclient\-id\(dq: \(dq42:42:42:42:42:42:42:42\(dq, \(dqcltt\(dq: 12345678, \(dqfqdn\-fwd\(dq: false, \(dqfqdn\-rev\(dq: true, \(dqhostname\(dq: \(dqmyhost.example.com.\(dq, \(dqhw\-address\(dq: \(dq08:08:08:08:08:08\(dq, \(dqip\-address\(dq: \(dq192.0.2.1\(dq, \(dqstate\(dq: 0, \(dqsubnet\-id\(dq: 44, \(dqvalid\-lft\(dq: 3600 }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv4 lease found.\(dq } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 زمان آخرین تراکنش کلاینت (فیلد \fBcltt\fP) با معادلهٔ زیر به مدت‌زمان اعتبار (\fBvalid\-lft\fP) و تاریخ انقضا (که در اینجا گزارش نمی‌شود اما در پایگاه‌های داده ذخیره می‌گردد) پیوند خورده است: cltt + valid\e_lft = expire .sp به استثنای مدت‌زمان اعتبار نامحدود که با مقدار ویژهٔ 0xfffffff (4294967295) کدگذاری شده است و باعث سرریز (overflow) مقدار expire در backendهای MySQL و نگارش‌های قدیمی PostgreSQL می‌شود که در آن‌ها مهر زمانی ۳۲ بیتی است. بنابراین در این پایگاه‌های دادهٔ اجاره، تاریخ انقضا همان cltt است؛ یعنی: cltt = expire زمانی که valid\e_lft = 4294967295 باشد و backend اجاره MySQL یا PostgreSQL باشد. .UNINDENT .UNINDENT.SS دستورهای \fBlease4\-get\-all\fP و \fBlease6\-get\-all\fP .sp دستورهای \fBlease4\-get\-all\fP و \fBlease6\-get\-all\fP برای دریافت تمام اجاره‌های (leases) IPv4 یا IPv6، یا تمام اجاره‌های مربوط به مجموعه‌ای مشخص از زیرشبکه‌ها به کار می‌روند. اگر هیچ آرگومانی همراه با دستور مشخص نشده باشد، تمام اجاره‌ها بازگردانده می‌شوند، همان‌طور که در مثال زیر آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-get\-all\(dq } .EE .UNINDENT .UNINDENT .sp در صورت ارائه آرگومان‌ها، انتظار می‌رود که شامل پارامتر \fB\(dqsubnets\(dq\fP باشند؛ این پارامتر فهرستی از شناسه‌های زیرشبکه‌ای است که اجاره‌های آن‌ها باید بازگردانده شوند. به عنوان مثال، برای دریافت تمام اجاره‌های IPv6 متعلق به زیرشبکه‌هایی با شناسه‌های 1، 2، 3 و 4: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-get\-all\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ 1, 2, 3, 4 ] } } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده‌شده شامل فهرست دقیقی از اجاره‌ها با قالب زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqleases\(dq: [ { \(dqcltt\(dq: 12345678, \(dqduid\(dq: \(dq42:42:42:42:42:42:42:42\(dq, \(dqfqdn\-fwd\(dq: false, \(dqfqdn\-rev\(dq: true, \(dqhostname\(dq: \(dqmyhost.example.com.\(dq, \(dqhw\-address\(dq: \(dq08:08:08:08:08:08\(dq, \(dqiaid\(dq: 1, \(dqip\-address\(dq: \(dq2001:db8:2::1\(dq, \(dqpreferred\-lft\(dq: 500, \(dqstate\(dq: 0, \(dqsubnet\-id\(dq: 44, \(dqtype\(dq: \(dqIA_NA\(dq, \(dqvalid\-lft\(dq: 3600 }, { \(dqcltt\(dq: 12345678, \(dqduid\(dq: \(dq21:21:21:21:21:21:21:21\(dq, \(dqfqdn\-fwd\(dq: false, \(dqfqdn\-rev\(dq: true, \(dqhostname\(dq: \(dq\(dq, \(dqiaid\(dq: 1, \(dqip\-address\(dq: \(dq2001:db8:0:0:2::\(dq, \(dqpreferred\-lft\(dq: 500, \(dqprefix\-len\(dq: 80, \(dqstate\(dq: 0, \(dqsubnet\-id\(dq: 44, \(dqtype\(dq: \(dqIA_PD\(dq, \(dqvalid\-lft\(dq: 3600 } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 IPv6 lease(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 دستورهای \fBlease4\-get\-all\fP و \fBlease6\-get\-all\fP ممکن است به پاسخ‌های بسیار بزرگی منجر شوند. از آنجا که کارگزار محدودیتی بر روی تعداد اجاره‌های بازگردانده‌شده در نتیجه این دستور اعمال نمی‌کند، این امر ممکن است در حین تولید پاسخ و ارسال آن از طریق کانال کنترل، بر پاسخ‌گویی کارگزار DHCP اثر منفی بگذارد. .UNINDENT .UNINDENT .SS دستورهای \fBlease4\-get\-page\fP و \fBlease6\-get\-page\fP .sp دستورهای \fBlease4\-get\-all\fP و \fBlease6\-get\-all\fP ممکن است منجر به پاسخ‌های بسیار بزرگی شوند؛ تولید چنین پاسخی ممکن است توان پردازشی CPU و همچنین حافظه را مصرف کند. حتی ممکن است باعث عدم پاسخ‌گویی کارگزار شود. در پایگاه‌داده‌های بزرگ اجاره، معمولاً بهتر است اجاره‌ها به‌صورت تکه‌تکه و با استفاده از سازوکار صفحه‌بندی دریافت شوند. \fBlease4\-get\-page\fP و \fBlease6\-get\-page\fP به ترتیب یک سازوکار صفحه‌بندی برای کارگزارهای DHCPv4 و DHCPv6 پیاده‌سازی می‌کنند. دستور زیر 1024 اجاره اول IPv4 را دریافت می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-get\-page\(dq, \(dqarguments\(dq: { \(dqfrom\(dq: \(dqstart\(dq, \(dqlimit\(dq: 1024 } } .EE .UNINDENT .UNINDENT .sp کلمه کلیدی \fBstart\fP نشان می‌دهد که صفحه اول اجاره‌ها باید دریافت شود. به عنوان جایگزین، می‌توان یک آدرس صفر IPv4 را برای دریافت صفحه اول مشخص کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-get\-page\(dq, \(dqarguments\(dq: { \(dqfrom\(dq: \(dq0.0.0.0\(dq, \(dqlimit\(dq: 1024 } } .EE .UNINDENT .UNINDENT .sp به طور مشابه، می‌توان آدرس صفر IPv6 را در دستور \fBlease6\-get\-page\fP مشخص نمود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-get\-page\(dq, \(dqarguments\(dq: { \(dqfrom\(dq: \(dq::\(dq, \(dqlimit\(dq: 6 } } .EE .UNINDENT .UNINDENT .sp پاسخ دارای ساختار زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqleases\(dq: [ { \(dqip\-address\(dq: \(dq2001:db8:2::1\(dq, ... }, { \(dqip\-address\(dq: \(dq2001:db8:2::9\(dq, ... }, { \(dqip\-address\(dq: \(dq2001:db8:3::1\(dq, ... }, { \(dqip\-address\(dq: \(dq2001:db8:5::3\(dq, ... }, { \(dqip\-address\(dq: \(dq2001:db8:4::1\(dq, ... }, { \(dqip\-address\(dq: \(dq2001:db8:2::7\(dq, ... }, ... ], \(dqcount\(dq: 6 }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq6 IPv6 lease(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که جزئیات اجاره‌ها در پاسخ بالا به منظور اختصار حذف شده‌اند. .sp به طور کلی، فهرست بازگردانده‌شده بر اساس ترتیب خاصی مرتب نشده است. برخی از بک‌اندهای پایگاه‌داده اجاره ممکن است اجاره‌ها را به ترتیب صعودی آدرس‌ها مرتب کنند، اما کلاینت کنترل‌کننده نباید به این رفتار اتکا کند. .sp پارامتر \fBcount\fP حاوی تعداد اجاره‌های بازگردانده‌شده در این صفحه است. .sp برای واکشی صفحه بعدی، کلاینت باید آخرین آدرس صفحه فعلی را به عنوان ورودی برای فراخوانی دستور بعدی \fBlease4\-get\-page\fP یا \fBlease6\-get\-page\fP استفاده کند. در این مثال، این آدرس به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-get\-page\(dq, \(dqarguments\(dq: { \(dqfrom\(dq: \(dq2001:db8:2::7\(dq, \(dqcount\(dq: 6 } } .EE .UNINDENT .UNINDENT .sp زیرا 2001:db8:2::7 آخرین آدرس در صفحه فعلی است. .sp کلاینت می‌تواند هنگامی که مقدار \fBcount\fP کمتر از مقدار مشخص‌شده در دستور باشد، فرض کند که به آخرین صفحه رسیده است؛ این شامل حالتی نیز می‌شود که \fBcount\fP برابر با 0 باشد، به این معنی که هیچ اجاره‌ای پیدا نشده است..SS دستورهای \fBlease4\-get\-by\-*\fP و \fBlease6\-get\-by\-*\fP .sp دستورهای \fBlease4\-get\-by\-*\fP و \fBlease6\-get\-by\-*\fP می‌توانند برای پرس‌وجو از پایگاه داده اجاره‌ها و دریافت تمام اجاره‌های موجودِ منطبق با یک ویژگی مشخص (که با \fB*\fP نشان داده شده است) استفاده شوند. این موارد می‌توانند شامل یک آدرس سخت‌افزاری مشخص (فقط IPv4)، شناسه‌های \fBclient\-id\fP (فقط IPv4)، \fBduid\fP (فقط IPv6)، یا hostname باشند. .sp یک مثال از دستور \fBlease4\-get\-by\-hw\-address\fP برای دریافت اجاره‌های IPv4 با یک آدرس سخت‌افزاری مشخص: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-get\-by\-hw\-address\(dq, \(dqarguments\(dq: { \(dqhw\-address\(dq: \(dq08:08:08:08:08:08\(dq } } .EE .UNINDENT .UNINDENT .sp یک مثال از \fBlease6\-get\-by\-hostname\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-get\-by\-hostname\(dq, \(dqarguments\(dq: { \(dqhostname\(dq: \(dqmyhost.example.org\(dq } } .EE .UNINDENT .UNINDENT .sp کلید \fBby\fP تنها پارامتر است. پاسخ بازگردانده شده شامل فهرستی با جزئیات از اجاره‌ها با همان قالب \fBlease4\-get\-all\fP یا \fBlease6\-get\-all\fP\& است. این فهرست می‌تواند خالی باشد و معمولاً بزرگ نیست. .sp از نسخه 3.1.5 Kea، دستورهای \fBby\-state\fP اضافه شده‌اند به طوری که: .INDENT 0.0 .IP \(bu 2 پارامتر \fBstate\fP همچنین یک رشته (در مقابل یک عدد) را برای نام‌های معمول وضعیت می‌پذیرد (default (یا assigned) (0)، declined (1)، expired\-reclaimed (2)، released (3)، و registered (4)). .IP \(bu 2 یک پارامتر اختیاری subnet\-id که اجاره‌ها را به زیرشبکه مشخص‌شده محدود می‌کند. هنگامی که حذف شود یا روی 0 تنظیم گردد، تمام اجاره‌ها با وضعیت داده‌شده بازگردانده می‌شوند. .UNINDENT .SS دستورهای \fBlease4\-del\fP و \fBlease6\-del\fP .sp \fBlease4\-del\fP و \fBlease6\-del\fP می‌توانند برای حذف یک اجاره از پایگاه داده اجاره‌ها استفاده شوند. این دستورها مانند دستورهای \fBlease4\-get\fP و \fBlease6\-get\fP از دو نوع پارامتر پشتیبانی می‌کنند: (\fBaddress\fP) برای هر دو نسخه v4 و v6، همچنین (\fBsubnet\-id\fP، \fBidentifier\-type\fP، \fBidentifier\fP) برای v4، و (\fBsubnet\-id\fP، \fBidentifier\-type\fP، \fBidentifier\fP، \fBtype\fP، \fBIAID\fP) برای v6. نوع اول پرس‌وجو زمانی استفاده می‌شود که آدرس (چه IPv4 یا IPv6) مشخص است، اما جزئیات اجاره مشخص نیست. یک مورد استفاده معمول زمانی است که مدیر سیستم می‌خواهد یک آدرس مشخص دیگر استفاده نشود. شکل دوم دستور از شناسه‌ها استفاده می‌کند. برای حداکثر انعطاف‌پذیری، این رابط کاربری از شناسه‌ها به صورت یک جفت مقدار استفاده می‌کند: نوع و شناسه واقعی. شناسه‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از \fB\(dqhw\-address\(dq\fP (فقط IPv4)، \fB\(dqclient\-id\(dq\fP (فقط IPv4)، و \fB\(dqduid\(dq\fP (فقط IPv6). .sp یک مثال از دستور برای حذف یک اجاره IPv4 بر اساس آدرس: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-del\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.2.202\(dq } } .EE .UNINDENT .UNINDENT .sp یک مثال از حذف اجاره IPv4 بر اساس \fB\(dqhw\-address\(dq\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-del\(dq, \(dqarguments\(dq: { \(dqidentifier\(dq: \(dq08:08:08:08:08:08\(dq, \(dqidentifier\-type\(dq: \(dqhw\-address\(dq, \(dqsubnet\-id\(dq: 44 } } .EE .UNINDENT .UNINDENT .sp اجاره‌های آدرس IPv6 نیز به همین روش حذف می‌شوند، اما با استفاده از \fBlease6\-del\fP\&. اجاره‌های پیشوند IPv6 نیز با استفاده از \fBlease6\-del\fP حذف می‌شوند، اما با چند مرحله اضافی. به پیشوند باید از طریق آدرس آن ارجاع داده شود و از طول پیشوند صرف‌نظر شود. برای مثال، جهت حذف 2001:db8:1::/48 می‌توان از دستور زیر استفاده کرد. پارامتر \fBsubnet\-id\fP اختیاری است. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-del\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq2001:db8:1::\(dq, \(dqtype\(dq: \(dqIA_PD\(dq, \(dqsubnet\-id\(dq: 1 } } .EE .UNINDENT .UNINDENT .sp پارامتر دیگری با نام \fBupdate\-ddns\fP، در صورت \fBtrue\fP بودن، به سرور دستور می‌دهد که در صورت برقراری شرایط زیر، پس از حذف موفقیت‌آمیز اجاره، درخواستی را به \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> جهت حذف مدخل‌های DNS در صف قرار دهد: .INDENT 0.0 .IP \(bu 2 به‌روزرسانی DDNS فعال باشد (یعنی \fB\(dqdhcp\-ddns\(dq:{ \(dqenable\-updates\(dq: true }\fP). .IP \(bu 2 نام میزبان (hostname) اجاره خالی نباشد. .IP \(bu 2 حداقل یکی از پرچم‌های جهت DNS اجاره (\fBfqdn_fwd\fP یا \fBfqdn_rev\fP) برابر با true باشد. .UNINDENT .sp مقدار پیش‌فرض این پارامتر \fBfalse\fP\& است. مثالی از کاربرد آن در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-del\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.2.202\(dq, \(dqupdate\-ddns\(dq: true } } .EE .UNINDENT .UNINDENT .sp دستورهای \fBlease4\-del\fP و \fBlease6\-del\fP نتیجه‌ای را برمی‌گردانند که بیانگر پیامد عملیات است. این نتیجه یکی از مقادیر زیر را دارد: 0 (موفقیت)، 1 (خطا)، یا 3 (خالی). نتیجه خالی به این معنی است که پرس‌وجو به درستی انجام شده، اما شیء مورد نظر (در اینجا، یک اجاره) یافت نشده است..SS دستورهای \fBlease4\-update\fP و \fBlease6\-update\fP .sp دستورهای \fBlease4\-update\fP و \fBlease6\-update\fP می‌توانند برای به‌روزرسانی اجاره‌های موجود به کار روند. از آنجا که تمام پایگاه‌های داده پس‌زمینه اجاره‌ها بر اساس نشانی‌های IP نمایه شده‌اند، امکان به‌روزرسانی خود نشانی وجود ندارد، اما تمام فیلدهای دیگر قابل تغییر هستند. اگر نیاز به تغییر نشانی باشد، لطفاً از \fBlease4\-del\fP / \fBlease6\-del\fP و به دنبال آن از \fBlease4\-add\fP / \fBlease6\-add\fP استفاده کنید\&. .sp پارامتر \fBsubnet\-id\fP اختیاری است. اگر مشخص نشود، یا مقدار تعیین‌شده 0 باشد، Kea تلاش می‌کند مقدار آن را با اجرای یک رویه انتخاب زیرشبکه تعیین کند. با این حال اگر مشخص شده باشد، مقدار آن باید با زیرشبکه موجود مطابقت داشته باشد. .sp پارامتر بولی اختیاری \fB\(dqforce\-create\(dq\fP مشخص می‌کند که آیا در صورت عدم وجود اجاره در پایگاه داده، باید ایجاد شود یا خیر. مقدار پیش‌فرض آن \fBfalse\fP است که نشان می‌دهد در صورت عدم وجود اجاره، ایجاد نخواهد شد. در چنین حالتی، هنگام تلاش برای به‌روزرسانی یک اجاره ناموجود، خطا بازگردانده می‌شود. اگر پارامتر \fB\(dqforce\-create\(dq\fP روی \fBtrue\fP تنظیم شده باشد و اجاره مورد نظر وجود نداشته باشد، با دریافت دستور \fBlease4\-update\fP / \fBlease6\-update\fP، اجاره جدید ایجاد می‌شود. .sp نمونه‌ای از دستور برای به‌روزرسانی یک اجاره IPv4: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-update\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.2.1\(dq, \(dqhostname\(dq: \(dqnewhostname.example.org\(dq, \(dqhw\-address\(dq: \(dq1a:1b:1c:1d:1e:1f\(dq, \(dqsubnet\-id\(dq: 44, \(dqforce\-create\(dq: true } } .EE .UNINDENT .UNINDENT .sp نمونه‌ای از دستور برای به‌روزرسانی یک اجاره IPv6: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-update\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq2001:db8::1\(dq, \(dqduid\(dq: \(dq88:88:88:88:88:88:88:88\(dq, \(dqiaid\(dq: 7654321, \(dqhostname\(dq: \(dqnewhostname.example.org\(dq, \(dqsubnet\-id\(dq: 66, \(dqforce\-create\(dq: false } } .EE .UNINDENT .UNINDENT .sp همانند سایر دستورهای به‌روزرسانی، این دستور تمام محتویات مدخل را بازنویسی می‌کند. اگر اجاره قبلاً منبعی تخصیص داده شده داشت، و در دستور \fBlease4\-update\fP / \fBlease6\-update\fP آن منبع وجود نداشته باشد، از پایگاه داده اجاره‌ها حذف خواهد شد. اگر به‌روزرسانی تدریجی اجاره مد نظر باشد، این کار با ارسال دستور \fBlease4\-get\fP / \fBlease6\-get\fP برای دریافت وضعیت فعلی اجاره، انتخاب اجاره از پاسخ، تغییر آن به وضعیت مطلوب، و سپس ارسال دستور \fBlease4\-update\fP / \fBlease6\-update\fP همراه با اجاره حاصل، قابل انجام است. .SS دستورهای \fBlease4\-wipe\fP و \fBlease6\-wipe\fP .sp دستورهای \fBlease4\-wipe\fP و \fBlease6\-wipe\fP برای حذف تمام اجاره‌های مرتبط با یک زیرشبکه مشخص طراحی شده‌اند. انتظار می‌رود این وظیفه مدیریتی زمانی استفاده شود که یک زیرشبکه موجود در حال بازنشستگی و خروج از سرویس است. این اجاره‌ها به درستی منقضی نمی‌شوند؛ هیچ به‌روزرسانی DNS انجام نمی‌گیرد، هیچ پیام لاگی ایجاد نمی‌شود، و برای اجاره‌های در حال حذف هیچ قلابی (hook) فراخوانی نمی‌گردد. .sp نمونه‌ای از \fBlease4\-wipe\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-wipe\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 44 } } .EE .UNINDENT .UNINDENT .sp نمونه‌ای از \fBlease6\-wipe\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-wipe\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq: 66 } } .EE .UNINDENT .UNINDENT .sp این دستورها یک توصیف متنی از تعداد اجاره‌های حذف‌شده، به علاوه کد وضعیت 0 (موفقیت) در صورت حذف هرگونه اجاره یا 3 (خالی) در صورت عدم وجود اجاره را بازمی‌گردانند. اگر پارامترها نادرست باشند یا استثنای دیگری رخ دهد، ممکن است کد وضعیت 1 (خطا) بازگردانده شود. .sp شناسه \fBsubnet\-id\fP 0 دارای معنای خاصی است؛ این مقدار به Kea اعلام می‌کند که اجاره‌ها را از تمام زیرشبکه‌های پیکربندی‌شده حذف کند. همچنین، پارامتر \fBsubnet\-id\fP می‌تواند حذف شود. اگر مشخص نشود، اجاره‌های تمام زیرشبکه‌ها پاک‌سازی خواهند شد. .sp نکته: در حال حاضر تنها فضای ذخیره‌سازی اجاره memfile از این دستور پشتیبانی می‌کند. .SS دستورهای \fBlease4\-resend\-ddns\fP و \fBlease6\-resend\-ddns\fP .sp دستورهای \fBlease4\-resend\-ddns\fP و \fBlease6\-resend\-ddns\fP می‌توانند برای ایجاد یک درخواست به \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> جهت به‌روزرسانی مدخل‌های DNS برای یک اجاره موجود استفاده شوند. اجاره مورد نظر با یک پارامتر واحد به نام \fB\(dqip\-address\(dq\fP انتخاب می‌شود\&. برای ایجاد درخواست به‌روزرسانی، باید به‌روزرسانی DDNS فعال باشد و پیش‌تر مدخل‌های DNS برای این اجاره ثبت شده (یا اقدام به ثبت شده) باشند. به عبارت دیگر، تمام موارد زیر باید برقرار باشند: .INDENT 0.0 .IP \(bu 2 به‌روزرسانی DDNS باید فعال باشد (یعنی \fB\(dqdhcp\-ddns\(dq:{ \(dqenable\-updates\(dq: true\(dq}\fP). .IP \(bu 2 نام میزبان (hostname) اجاره نباید خالی باشد. .IP \(bu 2 حداقل یکی از پرچم‌های جهت DNS اجاره (\fBfqdn_fwd\fP یا \fBfqdn_rev\fP) باید true باشد. .UNINDENT .sp نمونه‌ای از دستور \fBlease4\-resend\-ddns\fP برای دریافت اجاره با استفاده از نشانی IPv4: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease4\-resend\-ddns\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.2.1\(dq } } .EE .UNINDENT .UNINDENT .sp نمونه‌ای از پرس‌وجوی \fBlease6\-resend\-ddns\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlease6\-resend\-ddns\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq2001:db8:1::1\(dq } } .EE .UNINDENT .UNINDENT .sp دستورهای \fBlease4\-resend\-ddns\fP و \fBlease6\-resend\-ddns\fP وضعیت نتیجه عملیات را بازمی‌گردانند. این وضعیت یکی از مقادیر زیر است: 0 (موفقیت)، 1 (خطا)، یا 3 (خالی). نتیجه خالی بدین معناست که پرس‌وجو به درستی تکمیل شده، اما شیء (در این مورد یک اجاره) پیدا نشده است. .sp نتیجه موفقیت‌آمیز به این معنا نیست که DNS با موفقیت به‌روزرسانی شده است؛ بلکه نشان می‌دهد درخواستی برای به‌روزرسانی DNS با موفقیت ایجاد شده و برای ارسال به \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> در صف قرار گرفته است\&. .sp در اینجا نمونه‌ای از نتیجه بازگردانده‌شده در صورت یافتن اجاره آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqNCR generated for: 2001:db8:1::1, hostname: example.com.\(dq } .EE .UNINDENT .UNINDENT.SS دستورهای \fBlease4\-write\fP و \fBlease6\-write\fP .sp دستورهای \fBlease4\-write\fP و \fBlease6\-write\fP می‌توانند برای بازیابی در شرایط اضطراری که فایل اجاره memfile آسیب دیده است (برای نمونه به اشتباه حذف شده یا به دلیل پر شدن سیستم‌فایل ناقص شده است)، اما پایگاه‌داده درون‌حافظه‌ای (in\-memory) همچنان معتبر است، استفاده شوند. این دستورها تنها توسط بک‌اند پایگاه‌داده memfile پشتیبانی می‌شوند و پایگاه‌داده اجاره را در یک فایل CSV می‌نویسند. آن‌ها مسیر فایل را به عنوان آرگومان \fBfilename\fP دریافت می‌کنند. اگر فایل خروجی مشخص‌شده با فایل پیکربندی‌شده memfile یکسان باشد، بک‌اند در تلاشی برای همگام‌سازی هر دو فایل و تصویرهای درون‌حافظه‌ای پایگاه‌داده اجاره، فایل را بسته و دوباره باز می‌کند. پسوند \fB\&.bak\fP و شماره PID سرور به نام فایل قبلی افزوده می‌شوند؛ برای نمونه: \fB\&.bak14326\fP\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از Kea 2.7.9 به این سو، فایل اجاره تنها ممکن است در دایرکتوری داده تعیین‌شده هنگام کامپایل نوشته شود: \fB\(dq[kea\-install\-dir]/var/lib/kea\(dq\fP\&. این مسیر ممکن است در زمان راه‌اندازی با تنظیم متغیر محیطی \fBKEA_DHCP_DATA_DIR\fP به مسیر دلخواه بازنویسی شود. اگر مسیری به غیر از این مقدار در \fBfilename\fP استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی امتناع می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت می‌کند. برای سهولت در مشخص کردن نام فایل سفارشی، کافی است بخش مسیر را از \fBfilename\fP حذف کنید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این دستورها جایگزین سازوکار LFC نمی‌شوند؛ آن‌ها باید تنها در شرایط استثنایی استفاده شوند، مانند بازیابی پس از اتمام فضای دیسک. .UNINDENT .UNINDENT .SS دستورهای مدیریت استخرهای SFLQ .sp دستورهای زیر می‌توانند برای مدیریت داده‌های SFLQ (مانند استخرها و اجاره‌های آزاد) موجود در بک‌اند اجاره برای زیرشبکه‌هایی که از Shared FLQ Allocator استفاده می‌کنند، به کار روند. در شرایط عادی، این اطلاعات به طور خودکار توسط سازوکارهای SFLQ Allocator ایجاد و نگهداری می‌شوند. با این دستورهای API، امکان مشاهده، ساخت (مجدد) و حذف استخرهای SFLQ فراهم می‌شود. .sp نخست، درک این نکته مهم است که استخرهای SFLQ به طور یکتا بر اساس آدرس‌های آغازین و پایانی خود شناسایی می‌شوند. برای هر محدوده معتبر IPv4 یا IPv6، تنها می‌تواند یک استخر وجود داشته باشد. با این حال، استخرها می‌توانند محدوده‌های همپوشان داشته باشند. .sp دستورهایی که استخرها را واکشی می‌کنند، مقادیر زیر را برای هر استخر بازمی‌گردانند: .INDENT 0.0 .IP \(bu 2 \fBstart\-address\fP \- آدرس آغازین استخر .IP \(bu 2 \fBend\-address\fP \- آدرس پایانی استخر .IP \(bu 2 \fBsubnet\-id\fP \- شناسه زیرشبکه‌ای که استخر برای آن ایجاد شده است .IP \(bu 2 \fBlease\-type\fP \- برای IPv4 همیشه \(dqV4\(dq است، برای IPv6 یا \(dqIA_NA\(dq است یا \(dqIA_PD\(dq .IP \(bu 2 \fBdelegated\-len\fP \- برای استخرهای \(dqV4\(dq و \(dqIA_NA\(dq همیشه ۱۲۸ است. برای استخرهای \(dqIA_PD\(dq طول پیشوند واگذارشده است. .IP \(bu 2 \fBcreated\-ts\fP \- زمان ایجاد استخر. .IP \(bu 2 \fBmodified\-ts\fP \- زمان آخرین به‌روزرسانی استخر. این مقدار در ابتدا پس از تکمیل ایجاد استخر تنظیم می‌شود. پس از آن، هر بار که تخصیص SFLQ یک اجاره آزاد را از استخر برمی‌دارد، به‌روزرسانی می‌شود. .IP \(bu 2 \fBfree\-leases\fP تعداد آدرس‌های در حال حاضر آزاد در استخر. .UNINDENT .sp حداقل سه حالت وجود دارد که این دستورها در آن‌ها به احتمال زیاد بیشترین کاربرد را خواهند داشت. نخست، به عنوان راهکاری برای جست‌وجو و حذف استخرهای منسوخ‌شده. از آنجا که استخرها می‌توانند بین تعداد دلخواهی از سرورها به اشتراک گذاشته شوند، و هیچ‌یک از آن‌ها نمی‌توانند با قطعیت بدانند چه زمانی یک استخر دیگر مورد نیاز نیست، داده‌های SFLQ یک استخر را نمی‌توان هنگامی که طرح تخصیص آن به چیزی غیر از SFLQ Allocator تغییر می‌کند، به طور خودکار حذف کرد. اگرچه استخرهای غیرفعال نباید باعث اختلال در عملکرد سرورها شوند، اما فضا و نمایه‌ها را در بک‌اند اجاره مصرف می‌کنند. .sp حالت دوم، طرح‌های تخصیص ترکیبی است. برای اینکه تخصیص SFLQ به درستی کار کند، همه سرورهایی که از یک استخر معین (یعنی محدوده آدرس یا پیشوند) تخصیص می‌دهند، باید از SFLQ استفاده کنند. اگر برخی از سرورها استفاده کنند در حالی که برخی دیگر استفاده نکنند، داده‌های SFLQ می‌توانند به سرعت نادرست شوند. این مشکل را می‌توان با متوقف کردن سرورهایی که از SFLQ برای استخر(های) مربوطه استفاده نمی‌کنند، بازسازی استخر(ها) با استفاده از دستورهای sflq\-pool*\-rebuild، تغییر آن سرورها برای استفاده از SFLQ برای استخر(ها) و سپس راه‌اندازی مجدد آن‌ها رفع کرد. .sp حالت سوم، استخرهای همپوشان است (یعنی استخرهایی که محدوده‌های آدرس/پیشوند آن‌ها با یکدیگر تداخل دارند). Kea این موضوع را به عنوان یک پیکربندی عامدانه پشتیبانی می‌کند، اما همچنین ممکن است به صورت ناخواسته در صورتی رخ دهد که تغییرات پیکربندی به صورت یکپارچه در چندین سرور اعمال نشوند. واکشی استخرهای SFLQ بر اساس محدوده آدرس، تمام استخرهای SFLQ که با محدوده ورودی همپوشانی دارند را برمی‌گرداند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 ایجاد یا حذف استخرهای SFLQ در زمانی که سرورها به طور فعال از محدوده‌های آدرس آن‌ها تخصیص می‌دهند، می‌تواند منجر به نتایج متناقض شود و به طور کلی توصیه نمی‌شود. دستورهایی که استخرهای SFLQ را واکشی می‌کنند می‌توانند در هر زمان با اطمینان استفاده شوند. .UNINDENT .UNINDENT .SS دستورهای \fBsflq\-pool4\-rebuild\fP و \fBsflq\-pool6\-rebuild\fP .sp دستورهای \fBsflq\-pool4\-rebuild\fP و \fBsflq\-pool6\-rebuild\fP می‌توانند برای بازسازی داده‌های اجاره آزاد برای استخرهای SFLQ موجود استفاده شوند. این امر در مواردی مفید است که یک یا چند سرور از سایر طرح‌های تخصیص برای محدوده‌های آدرسی که شامل استخرهای SFLQ هستند استفاده کرده باشند. اجرای این دستور باعث می‌شود که بک‌اند اجاره، داده‌های اجاره آزاد برای استخر مشخص‌شده را دور ریخته و سپس مجدداً بازسازی کند. تنها استخری بازسازی خواهد شد که دقیقاً با آدرس آغازین و پایانی ارائه‌شده مطابقت داشته باشد. .sp یک نمونه از دستور \fBsflq\-pool4\-rebuild\fP برای بازسازی استخر SFLQ مربوط به IPv4 در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsflq\-pool4\-rebuild\(dq, \(dqarguments\(dq: { \(dqstart\-address\(dq: \(dq192.0.2.0\(dq, \(dqend\-address\(dq: \(dq192.0.2.255\(dq } } .EE .UNINDENT .UNINDENT .sp یک نمونه از دستور \fBsflq\-pool6\-rebuild\fP برای بازسازی استخر SFLQ مربوط به IPv6 برای یک استخر آدرس در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsflq\-pool6\-rebuild\(dq, \(dqarguments\(dq: { \(dqstart\-address\(dq: \(dq2001:db8:1::\(dq, \(dqend\-address\(dq: \(dq2001:db8:1::FFFF\(dq } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برای استخرهای بزرگ (برای مثال >= ۱ میلیون آدرس/پیشوند)، این دستور می‌تواند بیست ثانیه یا بیشتر زمان ببرد. در طول این مدت سرور درخواست‌های کلاینت‌ها را پردازش نخواهد کرد. اطمینان حاصل کنید ابزاری که با آن دستورها را ارسال می‌کنید برای مهلت‌های زمانی (time outs) طولانی پیکربندی شده باشد. هنگامی که درخواست به بک‌اند اجاره ارسال شود، پرس‌وجو به اجرای خود ادامه خواهد داد، حتی اگر اتصال کلاینت API قطع شود. .UNINDENT .UNINDENT .sp این دستور وضعیتی را بازمی‌گرداند که نشان‌دهنده موفقیت (result 0) یا شکست (result 1) است. دستور شکست‌خورده همواره حاوی پارامتر متنی است که علت شکست را شرح می‌دهد. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqSFLQ pool rebuilt.\(dq } .EE .UNINDENT .UNINDENT.SS دستورهای \fBsflq\-pool4\-get\-all\fP و \fBsflq\-pool6\-get\-all\fP .sp از \fBsflq\-pool4\-get\-all\fP و \fBsflq\-pool6\-get\-all\fP می‌توان برای واکشی فهرستی از تمامی استخرهای IPv4 یا IPv6 در SFLQ استفاده کرد. آن‌ها هیچ آرگومانی نمی‌پذیرند. .sp یک نمونه دستور \fBsflq\-pool4\-get\-all\fP برای واکشی استخرهای IPv4 در SFLQ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsflq\-pool4\-get\-all\(dq } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده‌شده شامل یک فهرست تفصیلی از تمام استخرهای IPv4 در SLFQ به قالب زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqpools\(dq: [ { \(dqcreated\-ts\(dq: \(dq2026\-05\-05 11:16:36.000000\(dq, \(dqdelegated\-len\(dq: 128, \(dqend\-address\(dq: \(dq178.0.255.255\(dq, \(dqfree\-leases\(dq: 65535, \(dqlease\-type\(dq: \(dqV4\(dq, \(dqmodified\-ts\(dq: \(dq2026\-05\-05 11:16:36.000000\(dq, \(dqstart\-address\(dq: \(dq178.0.0.1\(dq, \(dqsubnet\-id\(dq: 1 }, { \(dqcreated\-ts\(dq: \(dq2026\-05\-05 11:18:02.000000\(dq, \(dqdelegated\-len\(dq: 128, \(dqend\-address\(dq: \(dq192.0.2.255\(dq, \(dqfree\-leases\(dq: 256, \(dqlease\-type\(dq: \(dqV4\(dq, \(dqmodified\-ts\(dq: \(dq2026\-05\-05 11:18:02.000000\(dq, \(dqstart\-address\(dq: \(dq192.0.2.0\(dq, \(dqsubnet\-id\(dq: 2 } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 pool(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp یک نمونه دستور \fBsflq\-pool6\-get\-all\fP برای واکشی استخرهای IPv6 در SFLQ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsflq\-pool6\-get\-all\(dq } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده‌شده شامل یک فهرست تفصیلی از تمام استخرهای IPv6 در SLFQ به قالب زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqpools\(dq: [ { \(dqcreated\-ts\(dq: \(dq2026\-05\-05 13:21:10.000000\(dq, \(dqdelegated\-len\(dq: 120, \(dqend\-address\(dq: \(dq2001:db8:1::ffff\(dq, \(dqfree\-leases\(dq: 256, \(dqlease\-type\(dq: \(dqIA_PD\(dq, \(dqmodified\-ts\(dq: \(dq2026\-05\-05 13:21:10.000000\(dq, \(dqstart\-address\(dq: \(dq2001:db8:1::\(dq, \(dqsubnet\-id\(dq: 1 }, { \(dqcreated\-ts\(dq: \(dq2026\-05\-05 08:40:40.000000\(dq, \(dqdelegated\-len\(dq: 128, \(dqend\-address\(dq: \(dq3001::ffff\(dq, \(dqfree\-leases\(dq: 65520, \(dqlease\-type\(dq: \(dqIA_NA\(dq, \(dqmodified\-ts\(dq: \(dq2026\-05\-05 08:40:41.000000\(dq, \(dqstart\-address\(dq: \(dq3001::10\(dq, \(dqsubnet\-id\(dq: 2 } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 pool(s) found.\(dq } .EE .UNINDENT .UNINDENT .SS دستورهای \fBsflq\-pool4\-get\-by\-subnet\fP و \fBsflq\-pool6\-get\-by\-subnet\fP .sp از \fBsflq\-pool4\-get\-by\-subnet\fP و \fBsflq\-pool6\-get\-by\-subnet\fP می‌توان برای واکشی فهرستی از تمامی استخرهای IPv4 یا IPv6 در SFLQ که برای یک زیرشبکه ایجاد شده‌اند، استفاده کرد. .sp یک نمونه دستور \fBsflq\-pool4\-get\-by\-subnet\fP برای واکشی استخرهای IPv4 در SFLQ در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsflq\-pool4\-get\-by\-subnet\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq : 1 } } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده‌شده شامل یک فهرست تفصیلی از استخرهای IPv4 در SLFQ به قالب زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqpools\(dq: [ { \(dqcreated\-ts\(dq: \(dq2026\-05\-05 11:18:02.000000\(dq, \(dqdelegated\-len\(dq: 128, \(dqend\-address\(dq: \(dq192.0.2.255\(dq, \(dqfree\-leases\(dq: 256, \(dqlease\-type\(dq: \(dqV4\(dq, \(dqmodified\-ts\(dq: \(dq2026\-05\-05 11:18:02.000000\(dq, \(dqstart\-address\(dq: \(dq192.0.2.0\(dq, \(dqsubnet\-id\(dq: 1 } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 pool(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp یک نمونه دستور \fBsflq\-pool6\-get\-by\-subnet\fP برای واکشی استخرهای IPv6 در SFLQ در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsflq\-pool6\-get\-by\-subnet\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq : 100 } } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده‌شده شامل یک فهرست تفصیلی از استخرهای IPv6 در SLFQ به قالب زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqpools\(dq: [ { \(dqcreated\-ts\(dq: \(dq2026\-05\-05 13:21:10.000000\(dq, \(dqdelegated\-len\(dq: 120, \(dqend\-address\(dq: \(dq2001:db8:1::ffff\(dq, \(dqfree\-leases\(dq: 256, \(dqlease\-type\(dq: \(dqIA_PD\(dq, \(dqmodified\-ts\(dq: \(dq2026\-05\-05 13:21:10.000000\(dq, \(dqstart\-address\(dq: \(dq2001:db8:1::\(dq, \(dqsubnet\-id\(dq: 100 } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 pool(s) found.\(dq } .EE .UNINDENT .UNINDENT.SS دستورات \fBsflq\-pool4\-get\-by\-range\fP و \fBsflq\-pool6\-get\-by\-range\fP .sp \fBsflq\-pool4\-get\-by\-range\fP و \fBsflq\-pool6\-get\-by\-range\fP می‌توانند برای دریافت فهرستی از تمام استخرهای SFLQ مربوط به IPv4 یا IPv6 که برای یک زیرشبکه ساخته شده‌اند، استفاده شوند. .sp یک نمونه دستور \fBsflq\-pool4\-get\-by\-range\fP برای دریافت استخرهای SFLQ مربوط به IPv4 در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsflq\-pool4\-get\-by\-range\(dq, \(dqarguments\(dq: { \(dqstart\-address\(dq: \(dq178.0.0.0\(dq, \(dqend\-address\(dq: \(dq178.255.255.255\(dq } } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده‌شده شامل یک فهرست دقیق از استخرهای SFLQ مربوط به IPv4 به قالب زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqpools\(dq: [ { \(dqcreated\-ts\(dq: \(dq2026\-05\-05 11:16:36.000000\(dq, \(dqdelegated\-len\(dq: 128, \(dqend\-address\(dq: \(dq178.0.255.255\(dq, \(dqfree\-leases\(dq: 65535, \(dqlease\-type\(dq: \(dqV4\(dq, \(dqmodified\-ts\(dq: \(dq2026\-05\-05 11:16:36.000000\(dq, \(dqstart\-address\(dq: \(dq178.0.0.1\(dq, \(dqsubnet\-id\(dq: 1 } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 pool(s) found.\(dq } .EE .UNINDENT .UNINDENT .sp یک نمونه دستور \fBsflq\-pool6\-get\-by\-range\fP برای دریافت استخرهای SFLQ مربوط به IPv6 در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsflq\-pool6\-get\-by\-range\(dq, \(dqarguments\(dq: { \(dqstart\-address\(dq: \(dq3001::\(dq, \(dqend\-address\(dq: \(dq3002::\(dq } } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده‌شده شامل یک فهرست دقیق از استخرهای SFLQ مربوط به IPv6 به قالب زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqpools\(dq: [ { \(dqcreated\-ts\(dq: \(dq2026\-05\-05 08:40:40.000000\(dq, \(dqdelegated\-len\(dq: 128, \(dqend\-address\(dq: \(dq3001::ffff\(dq, \(dqfree\-leases\(dq: 65520, \(dqlease\-type\(dq: \(dqIA_NA\(dq, \(dqmodified\-ts\(dq: \(dq2026\-05\-05 08:40:41.000000\(dq, \(dqstart\-address\(dq: \(dq3001::10\(dq, \(dqsubnet\-id\(dq: 3001 }, { \(dqcreated\-ts\(dq: \(dq2026\-05\-05 08:40:41.000000\(dq, \(dqdelegated\-len\(dq: 64, \(dqend\-address\(dq: \(dq3001:20:0:ff:ffff:ffff:ffff:ffff\(dq, \(dqfree\-leases\(dq: 256, \(dqlease\-type\(dq: \(dqIA_PD\(dq, \(dqmodified\-ts\(dq: \(dq2026\-05\-05 08:40:41.000000\(dq, \(dqstart\-address\(dq: \(dq3001:20::\(dq, \(dqsubnet\-id\(dq: 3001 } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 pool(s) found.\(dq } .EE .UNINDENT .UNINDENT .SS دستورات \fBsflq\-pool4\-del\fP و \fBsflq\-pool6\-del\fP .sp از \fBsflq\-pool4\-del\fP و \fBsflq\-pool6\-del\fP می‌توان برای حذف یک استخر SFLQ مربوط به IPv4 یا IPv6 استفاده کرد. آن‌ها به دو آرگومان \fBstart\-address\fP و \fBend\-address\fP نیاز دارند. تنها استخری حذف خواهد شد که بازه آن با این مقادیر مطابقت داشته باشد و آن هم تنها در صورتی که هیچ استخر SFLQ دیگری با بازه توصیف‌شده توسط این مقادیر هم‌پوشانی نداشته باشد. اگر هرگونه استخر هم‌پوشانی شناسایی شود، عملیات حذف با پیام خطایی مبنی بر این وضعیت شکست خواهد خورد. یک پارامتر اختیاری \fBforce\fP وجود دارد که می‌تواند برای نادیده گرفتن این محافظت استفاده شود. هنگامی که روی \fBtrue\fP تنظیم شود، استخر منطبق بدون بررسی استخرهای هم‌پوشان حذف خواهد شد. .sp حذف یک استخر در زمانی که استخرهای هم‌پوشان وجود دارند، می‌تواند باعث ایجاد حفره‌هایی در داده‌های اجاره‌های آزاد (free lease) در محل‌های هم‌پوشانی شود. اگر قرار است استخرهای هم‌پوشان همچنان مورد استفاده قرار گیرند، باید از دستورات \fBsflq\-poolX\-rebuild\fP برای بازسازی داده‌های اجاره‌های آزاد برای استخرهای باقی‌مانده استفاده شود. .sp به عنوان راهکار دیگر، می‌توان تمام استخرهای هم‌پوشان را حذف کرد و راه‌اندازی (مجدد) یا پیکربندی (مجدد) بعدی کارساز Kea، تمام استخرهای مورد نیاز را به صورت خودکار بازآفرینی خواهد کرد. .sp یک نمونه دستور \fBsflq\-pool4\-del\fP برای حذف یک استخر SFLQ مربوط به IPv4 در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsflq\-pool4\-del\(dq, \(dqarguments\(dq: { \(dqstart\-address\(dq: \(dq192.0.2.10\(dq, \(dqend\-address\(dq: \(dq192.0.2.20\(dq, \(dqforce\(dq: false } } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده‌شده، در صورتی که استخرهای هم‌پوشان وجود داشته باشند، ممکن است به شکل زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 1, \(dqtext\(dq: \(dqDelete would affect 2 overlapping pools\(dq } .EE .UNINDENT .UNINDENT .sp و اگر هیچ استخر هم‌پوشانی وجود نداشته باشد یا \fBforce\fP روی true تنظیم شده باشد و استخر منطبق موجود باشد، نتیجه مشابه مورد نشان‌داده‌شده در زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqSFLQ pool deleted\(dq } .EE .UNINDENT .UNINDENT .sp یک نمونه دستور \fBsflq\-pool6\-del\fP برای حذف یک استخر SFLQ مربوط به IPv6 در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsflq\-pool6\-del\(dq, \(dqarguments\(dq: { \(dqstart\-address\(dq: \(dq3001::\(dq, \(dqend\-address\(dq: \(dq3001::10:FFFF\(dq, \(dqforce\(dq: false } } .EE .UNINDENT .UNINDENT .sp پاسخ بازگردانده‌شده، در صورتی که استخرهای هم‌پوشان وجود داشته باشند، ممکن است به شکل زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 1, \(dqtext\(dq: \(dqDelete would affect 3 overlapping pools\(dq } .EE .UNINDENT .UNINDENT .sp و اگر هیچ استخر هم‌پوشانی وجود نداشته باشد یا \fBforce\fP روی true تنظیم شده باشد و استخر منطبق موجود باشد، نتیجه مشابه مورد نشان‌داده‌شده در زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqSFLQ pool deleted\(dq } .EE .UNINDENT .UNINDENT.SS متغیرهای انتساب (Binding Variables) .sp متغیرهای انتساب به کاربران اجازه می‌دهند مقادیر سفارشی را همراه با هر اجاره (lease) ذخیره کنند. این مقادیر با استفاده از عبارت‌ها محاسبه شده و در \fBuser\-context\fP مربوط به اجاره ذخیره می‌شوند. این قابلیت شبیه به دستور \fBset\fP در ISC DHCP است. .sp آن‌ها به عنوان پارامترهایی برای کتابخانه قلاب lease\-cmds پیکربندی می‌شوند. هر متغیر دارای پارامترهای زیر است: .INDENT 0.0 .IP \(bu 2 .INDENT 2.0 .TP .B name نام متغیری که در \fBuser\-context\fP نمایش داده خواهد شد. این نام باید در فهرست متغیرهای انتساب یکتا باشد. .UNINDENT .IP \(bu 2 .INDENT 2.0 .TP .B expression عبارتی که برای محاسبه مقدار متغیر استفاده می‌شود (نگاه کنید به: :ref: \fIclassification\-using\-expressions\fP). .UNINDENT .IP \(bu 2 .INDENT 2.0 .TP .B source بسته‌ای که به عنوان ورودی عبارت استفاده می‌شود. این مقدار می‌تواند \fBquery\fP (بسته ارسال‌شده توسط کلاینت) یا \fBresponse\fP (بسته‌ای که سرور در پاسخ ارسال می‌کند) باشد. .UNINDENT .UNINDENT .sp مثال زیر یک گزینه تعریف‌شده توسط کاربر ارسال‌شده از طرف کلاینت را به همراه domain\-name ارسال‌شده توسط سرور برای هر اجاره DHCPv4 ذخیره می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [{ \(dqlibrary\(dq: \(dqlibdhcp_lease_cmds.so\(dq, \(dqparameters\(dq: { \(dqbinding\-variables\(dq: [{ \(dqname\(dq: \(dqopt\-222\(dq, \(dqexpression\(dq: \(dqhexstring(option[222].hex, \(aq:\(aq)\(dq, \(dqsource\(dq: \(dqquery\(dq },{ \(dqname\(dq: \(dqdomain\-name\(dq, \(dqexpression\(dq: \(dqoption[15].text\(dq, \(dqsource\(dq: \(dqresponse\(dq }] } }] } .EE .UNINDENT .UNINDENT .sp مقادیر به صورت جفت‌های نام\-مقدار در نگاشت \fBISC\fP در \fBuser\-context\fP اجاره ذخیره می‌شوند و محتویات آن شبیه به موارد زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqISC\(dq: { \(dqbinding\-variables\(dq: [{ \(dqdomain\-name\(dq: \(dqexample.org\(dq, \(dqopt\-222\(dq: \(dq01:02:03:04\(dq } ]} } .EE .UNINDENT .UNINDENT .sp هنگام ذخیره‌سازی در بک‌اندهای پایگاه‌داده، user\-context فاقد شکست‌های خط نشان داده شده در بالا خواهد بود و به صورت زیر نمایش می‌یابد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqISC\(dq: { \(dqbinding\-variables\(dq: { \(dqdomain\-name\(dq: \(dqexample.org\(dq, \(dqopt\-222\(dq: \(dq01:02:03:04\(dq } } } .EE .UNINDENT .UNINDENT .sp هنگام استفاده از فضای ذخیره‌سازی اجاره memfile، مقدار \fBuser\-context\fP با جایگزینی کاماها با توالی گریز \(dq,\(dq در خروجی قرار می‌گیرد. این امر برای جلوگیری از تداخل در تجزیه فایل اجاره ضروری است. خروجی مثال بالا در یک فایل اجاره memfile به صورت زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqISC\(dq: { \(dqbinding\-variables\(dq: { \(dqdomain\-name\(dq: \(dqexample.org\(dq, \(dqopt\-222\(dq: \(dq01:02:03:04\(dq } } } .EE .UNINDENT .UNINDENT .sp مقادیر متغیر انتساب هر زمان که اجاره‌ای تخصیص داده شده یا تمدید گردد ارزیابی می‌شوند. برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>، در صورتی که \fBoffer\-lifetime\fP بزرگتر از صفر باشد نیز اضافه می‌شوند. اجاره در بک‌اند تنها زمانی به‌روزرسانی می‌شود که مقادیر تغییر کرده باشند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگام استفاده هم‌زمان با کتابخانه قلاب Ping Check، کتابخانه قلاب lease\-cmds باید پس از Ping Check در بخش \fBhooks\-libraries\fP در پیکربندی سرور فهرست شود. .sp هنگام استفاده هم‌زمان با کتابخانه قلاب HA، کتابخانه قلاب lease\-cmds باید قبل از HA در بخش \fBhooks\-libraries\fP در پیکربندی سرور فهرست شود. این امر تضمین می‌کند که متغیرهای انتساب پیش از ارسال به‌روزرسانی‌های اجاره توسط HA به همتایانش (peer(s)) ارزیابی شوند. .UNINDENT .UNINDENT .SS \fBlibdhcp_lease_query.so\fP: پشتیبانی از Leasequery .sp این کتابخانه پشتیبانی از DHCPv4 Leasequery مطابق با RFC 4388 \%؛ و برای DHCPv6 Leasequery مطابق با (RFC 5007 \%) را فراهم می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_lease_query.so\fP بخشی از کد متن‌باز بوده و در دسترس تمام کاربران Kea است. این قابلیت پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرایندهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp نسخه 2.3.4 از Kea پشتیبانی از DHCPv6 Bulk Leasequery (RFC 5460 \%) را اضافه کرد؛ نسخه 2.3.5 از Kea پشتیبانی از DHCPv4 Bulk Leasequery (RFC 6926 \%) را با استفاده از بک‌اند اجاره memfile اضافه نمود..SS پرسمان اجاره DHCPv4 (DHCPv4 Leasequery) .sp قابلیت پرسمان اجاره ساده DHCPv4 (DHCPv4 simple Leasequery) به درخواست‌کننده امکان استعلام اطلاعات اجاره‌های فعال را برای یک آدرس IP مشخص یا یک کلاینت مشخص فراهم می‌کند. استاندارد RFC 4388 سه نوع از این پرسمان‌ها را معین کرده است: .INDENT 0.0 .IP \(bu 2 پرسمان بر اساس آدرس IP .INDENT 2.0 .INDENT 3.5 آدرس IP مورد نظر در فیلد \fBciaddr\fP پرسمان قرار می‌گیرد. .UNINDENT .UNINDENT .IP \(bu 2 پرسمان بر اساس آدرس سخت‌افزاری .INDENT 2.0 .INDENT 3.5 آدرس سخت‌افزاری مورد نظر در فیلد \fBchaddr\fP پرسمان قرار می‌گیرد. .UNINDENT .UNINDENT .IP \(bu 2 پرسمان بر اساس شناسه کلاینت .INDENT 2.0 .INDENT 3.5 شناسه کلاینت مورد نظر در گزینه \fBdhcp\-client\-identifier\fP (کد 61) پرسمان ارسال می‌شود. .UNINDENT .UNINDENT .UNINDENT .sp بسته ورودی DHCPLEASEQUERY باید تنها یکی از سه مقدار بالا را ارائه دهد. پرسمان‌هایی که بیش از یکی از این مقادیر را ارائه دهند دور ریخته می‌شوند. .sp علاوه بر این، پرسمان باید حاوی آدرس IP درخواست‌کننده در فیلد \fBgiaddr\fP\& باشد. این مقدار نه تنها به عنوان مقصد پاسخ پرسمان استفاده می‌شود، بلکه برای اعتبارسنجی درخواست‌کننده در برابر فهرستی شناخته‌شده از آدرس‌های IP مجاز به پرسمان نیز به کار می‌رود. این فهرست از آدرس‌های درخواست‌کننده معتبر به عنوان بخشی از پیکربندی کتابخانه قلاب (hook library) مربوط به Leasequery مشخص می‌شود (بخش پیکربندی در زیر را ببینید). .sp سرور در پاسخ به یک پرسمان معتبر، یکی از سه نوع پیام زیر را برمی‌گرداند: .INDENT 0.0 .IP \(bu 2 DHCPLEASEUNKNOWN .INDENT 2.0 .INDENT 3.5 زمانی بازگردانده می‌شود که آدرس IP مورد نظر برای سرور ناشناخته باشد (پرسمان بر اساس آدرس IP)؛ یا هیچ اجاره فعالی برای کلاینت مورد نظر وجود نداشته باشد (پرسمان بر اساس آدرس سخت‌افزاری یا شناسه کلاینت). .UNINDENT .UNINDENT .IP \(bu 2 DHCPLEASEUNASSIGNED .INDENT 2.0 .INDENT 3.5 زمانی بازگردانده می‌شود که آدرس IP برای سرور شناخته‌شده باشد اما هیچ اجاره فعالی برای آن وجود نداشته باشد (تنها برای پرسمان بر اساس آدرس IP اعمال می‌شود). .UNINDENT .UNINDENT .IP \(bu 2 DHCPLEASEACTIVE .INDENT 2.0 .INDENT 3.5 زمانی بازگردانده می‌شود که حداقل یک اجاره فعال منطبق با معیارها یافت شود. .UNINDENT .UNINDENT .UNINDENT .sp برای هر دو پاسخ DHCPLEASEUNKNOWN و DHCPLEASEUNASSIGNED، تنها اطلاعاتی که در پاسخ به درخواست‌کننده بازگردانده می‌شود، همان پارامتر پرسمان است (یعنی یکی از موارد: آدرس IP، آدرس سخت‌افزاری یا شناسه کلاینت). .sp برای DHCPLEASEACTIVE، سرور اطلاعات زیر را برای جدیدترین اجاره فعال منطبق با معیارها در پاسخ ارائه می‌دهد: .INDENT 0.0 .IP \(bu 2 \fBciaddr\fP \- روی آدرس IP اجاره تنظیم می‌شود .IP \(bu 2 \fBchaddr\fP \- روی آدرس سخت‌افزاری اجاره تنظیم می‌شود .UNINDENT .sp علاوه بر این، یک یا چند مورد از گزینه‌های زیر نیز گنجانده می‌شوند: .SS گزینه‌های DHCPLEASEACTIVE .TS box center; l|l|l. T{ گزینه T} T{ کد T} T{ محتوا T} _ T{ dhcp\-client\-identifier T} T{ 61 T} T{ از روی اجاره کپی می‌شود (در صورت وجود) T} _ T{ client\-last\-transaction\-time T} T{ 91 T} T{ مدت زمانی که از client\-last\-transaction\-time (CLTT) اجاره سپری شده است. این مقدار همچنین توسط سرور برای تنظیم مقادیر طول عمر و زمان‌سنج‌ها استفاده می‌شود. T} _ T{ dhcp\-lease\-time T} T{ 51 T} T{ طول عمر اجاره که مقدار CLTT از آن کسر شده است T} _ T{ dhcp\-renewal\-time T} T{ 58 T} T{ همان‌طور که توسط پیکربندی kea\-dhcp4 کنترل شده و سپس مقدار CLTT از آن کسر شده است T} _ T{ dhcp\-rebind\-time T} T{ 59 T} T{ همان‌طور که توسط پیکربندی kea\-dhcp4 تعیین شده و سپس مقدار CLTT از آن کسر شده است T} _ T{ dhcp\-agent\-options T} T{ 82 T} T{ در صورتی که روی اجاره ذخیره شده باشد. (ببینید: ذخیره‌سازی اطلاعات توسعه‌یافته اجاره \%<#\:dhcp4-store-extended-info>) T} _ T{ associated\-ip T} T{ 92 T} T{ فهرستی از تمام آدرس‌های IP دیگری که کلاینت برای آن‌ها اجاره فعال دارد. (برای پرسمان بر اساس آدرس IP اعمال نمی‌شود) T} .TE .sp گزینه \fBdhcp\-server\-identifier\fP (کد 54) در تمام پاسخ‌ها در راستای مطابقت با RFC 2131، بخش 4.3.1 بازگردانده می‌شود. .sp استاندارد RFC 4388 به درخواست‌کنندگان اجازه می‌دهد تا گزینه‌های خاصی را از طریق \fBdhcp\-parameter\-request\-list\fP (PRL، گزینه 55) درخواست کنند. این مورد در حال حاضر در Kea پشتیبانی نمی‌شود..SS پیکربندی Leasequery در DHCPv4 .sp پیکربندی کتابخانه قلاب (hook library) Leasequery برای استفاده سرراست است. این کتابخانه از یک پارامتر منفرد، \fBrequesters\fP، پشتیبانی می‌کند که فهرستی از نشانی‌های IP است که بسته‌های DHCPLEASEQUERY از آن‌ها پذیرفته می‌شوند. به عبارت دیگر، این فهرستی از درخواست‌دهندگان شناخته‌شده است. کد زیر یک نمونه پیکربندی را با دو نشانی درخواست‌دهنده نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_query.so\(dq, \(dqparameters\(dq: { \(dqrequesters\(dq: [ \(dq192.0.1.1\(dq, \(dq10.0.0.2\(dq ] } } ], ... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از Kea 3.1.4 به بعد، امکان گنجاندن محدوده‌های نشانی درخواست‌دهنده در قالب CIDR مانند \(dq192.0.1.0/24\(dq نیز وجود دارد. لطفاً توجه داشته باشید که مشخص کردن محدوده‌ها ممکن است امنیت کمتری نسبت به استفاده صرف از نشانی‌های IP صریح داشته باشد. .UNINDENT .UNINDENT .SS پرس‌وجوی Leasequery در DHCPv6 .sp قابلیت Leasequery ساده در DHCPv6 به درخواست‌دهنده این امکان را می‌دهد که اطلاعات اجاره (lease) فعال را برای یک نشانی IP منفرد یا یک DUID کلاینت منفرد پرس‌وجو کند. نوع پرس‌وجو و پارامترها در یک گزینه \fBlq\-query\fP (44) متصل به پیام \fBDHCPV6_LEASEQUERY\fP منتقل می‌شوند: .INDENT 0.0 .IP \(bu 2 \fBquery\-type\fP .INDENT 2.0 .INDENT 3.5 این مقدار یا \fBquery\-by\-address\fP (1) است یا \fBquery\-by\-clientid\fP (2). .UNINDENT .UNINDENT .IP \(bu 2 \fBlink\-address\fP .INDENT 2.0 .INDENT 3.5 نشانی پیوند سراسری (global link address)، هنگامی که خالی نباشد، پرس‌وجو را ملزم می‌کند که به اجاره‌های درون آن \(dqپیوند\(dq محدود شود. Kea از این مقدار برای انتخاب تنها آن دسته از اجاره‌هایی استفاده می‌کند که به زیرشبکه‌هایی با پیشوند منطبق بر این مقدار تعلق دارند. اجاره‌های فعال برای تفویض‌های پیشوند (prefix delegations) مربوط به یک زیرشبکه منطبق، در پاسخ پرس‌وجو گنجانده می‌شوند، حتی اگر خود پیشوند تفویض‌شده خارج از پیشوند زیرشبکه قرار گیرد. .UNINDENT .UNINDENT .IP \(bu 2 \fBquery\-options\fP .INDENT 2.0 .INDENT 3.5 هنگام پرس‌وجو بر اساس نشانی، باید یک گزینه منفرد \fBiaaddr\fP (12) ارائه شود. هنگام پرس‌وجو بر اساس شناسه کلاینت (client ID)، باید یک گزینه منفرد \fBclientid\fP (1) ارائه شود. استاندارد RFC 5007 همچنین یک گزینه اختیاری \fBoro\fP (6) را برای درخواست بازگرداندن گزینه‌های خاص برای اجاره‌های منطبق مشخص کرده است. این قابلیت در حال حاضر پیاده‌سازی نشده است. .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 بخش 3.3 استاندارد RFC 5007 \% بیان می‌کند که پرس‌وجو بر اساس نشانی IP باید یا یک اجاره (مثلاً انتساب) برای خود نشانی، یا یک اجاره برای پیشوند تفویض‌شده‌ای که شامل آن نشانی است بازگرداند. .UNINDENT .UNINDENT .sp پرس‌وجوهای \fBDHCPV6_LEASEQUERY\fP تنها در صورتی پذیرفته می‌شوند که نشانی مبدأ پرس‌وجو با مدخلی در فهرست نشانی‌های IP شناخته‌شده و مجاز برای پرس‌وجو مطابقت داشته باشد. این فهرست از نشانی‌های معتبر درخواست‌دهنده به عنوان بخشی از پیکربندی کتابخانه قلاب Leasequery مشخص می‌شود (به بخش پیکربندی در زیر مراجعه کنید). پرس‌وجوهای دریافتی از درخواست‌دهندگان ناشناس ثبت (log) و دور انداخته می‌شوند. .sp سرور در پاسخ به یک پرس‌وجوی معتبر، فعالیت‌های لازم را انجام داده و یک \fBDHCPV6_LEASEQUERY_REPLY\fP برمی‌گرداند. همه پاسخ‌ها حداقل شامل یک گزینه \fBstatus\-code\fP (13) هستند که نتیجه پرس‌وجو را مطابق با جدول زیر نشان می‌دهد: .SS مقادیر گزینه وضعیت DHCPV6_LEASEQUERY_REPLY بر اساس نتیجه پرس‌وجو .TS box center; l|l|l|l. T{ نتیجه پرس‌وجو T} T{ برچسب وضعیت T} T{ کد وضعیت T} T{ متن وضعیت T} _ T{ فیلد نوع پرس‌وجوی نامعتبر T} T{ STATUS_UnknownQueryType T} T{ 7 T} T{ \(dqunknown query\-type\(dq T} _ T{ پرس‌وجو بر اساس نشانی IP فاقد گزینه نشانی T} T{ STATUS_Malformed T} T{ 10 T} T{ \(dqmissing D6O_IAADDR\(dq T} _ T{ پرس‌وجو بر اساس نشانی IP برای نشانی‌ای که در هیچ استخر پیکربندی‌شده‌ای قرار ندارد T} T{ STATUS_NotConfigured T} T{ 9 T} T{ \(dqaddress not in a configured pool\(dq T} _ T{ پرس‌وجو بر اساس نشانی IP که تنها یک اجاره غیرفعال یافت (مانند منقضی‌شده، ردشده، بازپس‌گرفته‌شده\-منقضی‌شده) T} T{ STATUS_Success T} T{ 0 T} T{ \(dqinactive lease exists\(dq T} _ T{ پرس‌وجو بر اساس نشانی IP که هیچ اجاره‌ای (فعال یا غیرفعال) نیافت T} T{ STATUS_Success T} T{ 0 T} T{ \(dqno active lease\(dq T} _ T{ پرس‌وجو بر اساس نشانی IP که یک اجاره فعال برای نشانی یافت T} T{ STATUS_Success T} T{ 0 T} T{ \(dqactive lease found\(dq T} _ T{ پرس‌وجو بر اساس شناسه کلاینت فاقد گزینه شناسه کلاینت T} T{ STATUS_Malformed T} T{ 10 T} T{ \(dqmissing D6O_CLIENTID\(dq T} _ T{ پرس‌وجو بر اساس شناسه کلاینت با نشانی پیوندی که با هیچ زیرشبکه پیکربندی‌شده‌ای مطابقت ندارد T} T{ STATUS_NotConfigured T} T{ 9 T} T{ \(dqnot a configured link\(dq T} _ T{ پرس‌وجو بر اساس شناسه کلاینت که هیچ اجاره منطبقی نیافت T} T{ STATUS_Success T} T{ 0 T} T{ \(dqno active leases\(dq T} _ T{ پرس‌وجو بر اساس شناسه کلاینت که یک یا چند اجاره فعال یافت T} T{ STATUS_Success T} T{ 0 T} T{ \(dqactive lease(s) found\(dq T} .TE .sp برای سناریوهایی که در آن‌ها پرس‌وجو یا نامعتبر بوده یا هیچ اجاره فعال منطبقی برای آن یافت نشده است، \fBDHCPV6_LEASEQUERY_REPLY\fP طبق جدول فوق تنها شامل گزینه \fBstatus\-code\fP (12) خواهد بود. .sp هنگامی که یک پرس‌وجو اجاره‌های فعال را در بیش از یک زیرشبکه بیابد و \fBlink\-address\fP پرس‌وجو خالی باشد، آنگاه علاوه بر status\-code، پیام \fBDHCPV6_LEASEQUERY_REPLY\fP شامل یک گزینه \fBlq\-client\-link\fP (48) خواهد بود. گزینه \fBlq\-client\-link\fP شامل فهرستی از نشانی‌های IPv6 است، یک نشانی برای هر زیرشبکه‌ای که در آن اجاره‌ای یافت شده است (به RFC 5007، بخش 4.1.2.5 \% مراجعه کنید). با این حال، اگر \fBlink\-address\fP پرس‌وجو خالی نباشد، فهرست پرس‌وجوها هرس می‌شود تا فقط شامل اجاره‌هایی باشد که متعلق به آن زیرشبکه هستند. .sp هنگامی که پرس‌وجو منجر به یک یا چند اجاره فعال شود که همگی به یک زیرشبکه منفرد تعلق دارند، علاوه بر \fBstatus\-code\fP، پیام \fBDHCPV6_LEASEQUERY_REPLY\fP شامل یک گزینه \fBclient\-data\fP (45) خواهد بود (به RFC 5007، بخش 4.1.2.2 \% مراجعه کنید). گزینه client\-data گزینه‌های زیر را کپسوله‌سازی می‌کند:.SS OPTION_CLIENT_DATA بازگردانده‌شده هنگام یافتن اجاره(های) فعال .TS box center; l|l|l. T{ گزینه T} T{ کد T} T{ محتوا T} _ T{ clientid T} T{ 1 T} T{ رونویسی‌شده از روی اجاره (در صورت وجود) T} _ T{ clt\-time T} T{ 46 T} T{ مدت زمانی که از زمان آخرین تراکنش کلاینت (CLTT) اجاره سپری شده است. این مقدار توسط کارگزار نیز برای تنظیم طول‌عمر و مقادیر تایمر استفاده خواهد شد. T} _ T{ iaaddr T} T{ 5 T} T{ یک گزینه به ازای هر نشانی منطبق‌شده. فیلدها در هر گزینه: \- نشانی اجاره \- طول‌عمر معتبر کاهش‌یافته با CLTT \- طول‌عمر ترجیحی کاهش‌یافته با CLTT T} _ T{ iaprefix T} T{ 26 T} T{ یک گزینه به ازای هر پیشوند منطبق‌شده. فیلدها در هر گزینه: \- پیشوند \- طول پیشوند \- طول‌عمر معتبر کاهش‌یافته با CLTT \- طول‌عمر ترجیحی کاهش‌یافته با CLTT T} .TE .sp اگر اجاره با تازه‌ترین مقدار client\-last\-transaction\-time (CLTT) دارای اطلاعات رله (relay) در بافت کاربری (user context) خود باشد (ببینید ذخیره‌سازی اطلاعات گسترش‌یافته اجاره \%<#\:store-extended-info-v6>)، آنگاه یک گزینه \fBOPTION_LQ_RELAY_DATA\fP به پاسخ افزوده می‌شود (ببینید RFC 5007, Section 4.1.2.4 \%). .sp اطلاعات رله در اجاره، فهرستی با یک مدخل برای هر لایه رله است که بسته کلاینت (برای نمونه \fBDHCPV6_REQUEST\fP) از آن عبور کرده است؛ به‌طوری‌که نخستین مدخل در فهرست، بیرونی‌ترین لایه (نزدیک‌ترین به کارگزار) است. فیلد \fBpeer\-address\fP از \fBlq\-rely\-option\fP بر روی نشانی همتای این رله تنظیم می‌شود. سپس از فهرست رله‌ها برای ساخت یک پیام \fBDHCPV6_RELAY_FORW\fP معادل پیامی که حاوی بسته کلاینت بود (منهای بسته کلاینت) استفاده می‌شود. این پیام در فیلد \fBDHCP\-relay\-message\fP از گزینه \fBlq\-relay\-data\fP ذخیره می‌شود. .SS پیکربندی DHCPv6 Leasequery .sp پیکربندی کتابخانه قلاب (hook library) Leasequery برای استفاده سرراست است. این کتابخانه از یک پارامتر منفرد، یعنی \fBrequesters\fP پشتیبانی می‌کند که فهرستی از نشانی‌های IP است که بسته‌های DHCPV6_LEASEQUERY از آن‌ها پذیرفته می‌شوند. به عبارت دیگر، این فهرستی از درخواست‌کنندگان شناخته‌شده است. کد زیر یک پیکربندی نمونه را با دو نشانی درخواست‌کننده نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_query.so\(dq, \(dqparameters\(dq: { \(dqrequesters\(dq: [ \(dq2001:db8:1::1\(dq, \(dq2001:db8:2::1\(dq ], \(dqprefix\-lengths\(dq: [ 72 ] } } ], ... } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از Kea 3.1.4 به بعد، گنجاندن محدوده‌هایی از نشانی‌های درخواست‌کننده در قالب CIDR مانند \(dq2001:db8:1::/64\(dq نیز امکان‌پذیر است. لطفاً توجه داشته باشید که تعیین محدوده‌ها ممکن است امنیت کمتری نسبت به استفاده انحصاری از نشانی‌های صریح IP داشته باشد. .UNINDENT .UNINDENT .sp هنگامی که یک پرس‌وجو بر پایه نشانی IP با هیچ اجاره نشانی موجودی منطبق نشود، جستجویی برای یافتن یک پیشوند واگذارشده (delegated prefix) منطبق انجام می‌پذیرد. این کار با پیمایش روی فهرستی از طول‌های پیشوند به ترتیب نزولی، استخراج پیشوندی با آن طول از نشانی مورد پرس‌وجو، و جستجو برای واگذاری منطبق با پیشوند حاصل انجام می‌شود. این فرآیند برای هر طول در فهرست تا زمانی که تطابقی یافت شود یا فهرست به پایان برسد ادامه می‌یابد. .sp به‌طور پیش‌فرض، فهرست طول‌های پیشوند مورد استفاده در جستجو، پس از رویدادهای پیکربندی (یا پیکربندی مجدد) به‌صورت پویا تعیین می‌شود. فهرست حاصل شامل مقادیر یکتای \fBdelegated\-len\fP است که از مجموعه استخرهای PD پیکربندی‌شده فعلی گردآوری شده است. .sp یک پارامتر اختیاری به نام \fBprefix\-lengths\fP وجود دارد که امکان پیکربندی صریح فهرست را به‌جای تعیین پویای آن فراهم می‌آورد. این امر کنترل دقیق‌تری را بر روی اینکه کدام طول‌های پیشوند جستجو شوند ممکن می‌سازد. در مثال بالا، جستجوی طول پیشوند صرف‌نظر از اینکه استخرهایی با مقادیر دیگر برای \fBdelegated\-len\fP وجود داشته باشند یا خیر، به یک دور با استفاده از طول 72 محدود شده است\&. مشخص کردن یک فهرست خالی، همان‌گونه که در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX : \(dqprefix\-lengths\(dq: [ ] : .EE .UNINDENT .UNINDENT .sp جستجو برای پیشوندهای واگذارشده را برای پرس‌وجو بر پایه نشانی IP غیرفعال می‌کند..SS پرسش دسته‌ای اجاره در DHCPv4 (DHCPv4 Bulk Leasequery) .sp قابلیت DHCPv4 Bulk Leasequery به یک درخواست‌کننده امکان می‌دهد تا اطلاعات اجاره‌های فعال را روی یک اتصال TCP پرس‌وجو کند. این ویژگی به سرور اجازه می‌دهد تا تمام اجاره‌های منطبق با یک پرس‌وجوی داده‌شده را برگرداند. .sp دو مورد از انواع پرس‌وجوهای مشخص‌شده در RFC 4388 \- پرسش بر اساس نشانی MAC و پرسش بر اساس Client\-identifier \- انواع پرسش‌های دسته‌ای اجاره (Bulk Leasequery) تعیین‌شده در RFC 6926 هستند. آن RFC همچنین این انواع جدید Bulk Leasequery را تعریف می‌کند: .INDENT 0.0 .IP \(bu 2 پرسش بر اساس شناسه رله (Query by Relay Identifier) .INDENT 2.0 .INDENT 3.5 این پرس‌وجو حامل یک گزینه RAI (dhcp\-agent\-options (82)) به همراه زیرگزینه relay\-id (12) است. .UNINDENT .UNINDENT .IP \(bu 2 پرسش بر اساس شناسه دوردست (Query by Remote ID) .INDENT 2.0 .INDENT 3.5 این پرس‌وجو حامل یک گزینه RAI (گزینه dhcp\-agent\-options (82)) به همراه زیرگزینه remote\-id (2) است. .UNINDENT .UNINDENT .IP \(bu 2 پرسش برای تمام نشانی‌های IP پیکربندی‌شده (Query for All Configured IP Addresses) .INDENT 2.0 .INDENT 3.5 این نوع پرس‌وجو زمانی انتخاب می‌شود که هیچ نوع پرس‌وجوی دیگری مشخص نشده باشد. .UNINDENT .UNINDENT .UNINDENT .sp استاندارد RFC 6926 همچنین گزینه‌های جدیدی را برای Bulk Leasequery تعریف می‌کند: .INDENT 0.0 .IP \(bu 2 status\-code (151) .INDENT 2.0 .INDENT 3.5 این گزینه پاسخ، یک کد وضعیت نظیر MalformedQuery یا NotAllowed را به همراه یک پیام متنی اختیاری حمل می‌کند. .UNINDENT .UNINDENT .IP \(bu 2 base\-time (152) .INDENT 2.0 .INDENT 3.5 این گزینه پاسخ، زمان مطلق فعلی را که پاسخ در آن ایجاد شده است حمل می‌کند. تمام گزینه‌های پاسخ دیگرِ مبتنی بر زمان، وابسته به این مقدار هستند. .UNINDENT .UNINDENT .IP \(bu 2 start\-time\-of\-state (153) .INDENT 2.0 .INDENT 3.5 این گزینه پاسخ، زمان انتقال اجاره به وضعیت فعلی‌اش را حمل می‌کند. .UNINDENT .UNINDENT .IP \(bu 2 query\-start\-time (154) .INDENT 2.0 .INDENT 3.5 این گزینه پرس‌وجو یک زمان شروع پرس‌وجو را تعیین می‌کند؛ پاسخ‌ها فقط شامل اجاره‌هایی خواهند بود که قدیمی‌تر از این مقدار باشند. .UNINDENT .UNINDENT .IP \(bu 2 query\-end\-time (155) .INDENT 2.0 .INDENT 3.5 این گزینه پرس‌وجو یک زمان پایان پرس‌وجو را تعیین می‌کند؛ پاسخ‌ها فقط شامل اجاره‌هایی خواهند بود که جدیدتر از این مقدار باشند. .UNINDENT .UNINDENT .IP \(bu 2 dhcp\-state (156) .INDENT 2.0 .INDENT 3.5 این گزینه پاسخ، وضعیت اجاره را حمل می‌کند. .UNINDENT .UNINDENT .IP \(bu 2 data\-source (157) .INDENT 2.0 .INDENT 3.5 این گزینه پاسخ، منبع داده را به عنوان یک پرچم دوردست (remote flag) حمل می‌کند. .UNINDENT .UNINDENT .UNINDENT .sp استاندارد RFC 6926 از گزینه Virtual Subnet Selection (221) تعریف‌شده در RFC 6607 مجدداً استفاده کرده و آن را گسترش می‌دهد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برنامه Kea هنوز از پرس‌وجوی تمام نشانی‌های IP پیکربندی‌شده پشتیبانی نمی‌کند، بنابراین گزینه dhcp\-state قابل استفاده نیست، زیرا تنها اجاره‌های فعال می‌توانند در پاسخ‌ها بازگردانده شوند. Kea زمان شروع وضعیت اجاره و همچنین اطلاعات محلی/دوردست را نگهداری نمی‌کند، از این رو نمی‌تواند گزینه‌های متناظر start\-time\-of\-state و data\-source را منتشر کند. Kea از VPNها پشتیبانی نمی‌کند، بنابراین وجود گزینه 221 در پرس‌وجو به عنوان خطای (NotAllowed) در نظر گرفته می‌شود. .UNINDENT .UNINDENT .SS پرسش دسته‌ای اجاره در DHCPv6 (DHCPv6 Bulk Leasequery) .sp قابلیت DHCPv6 Bulk Leasequery به یک درخواست‌کننده توانایی پرس‌وجوی اطلاعات اجاره‌های فعال را روی یک اتصال TCP می‌دهد. این امر به سرور امکان می‌دهد تا تمام اجاره‌های فعال منطبق با پرس‌وجو را بازگرداند. .sp انواع جدیدی از پرس‌وجو در دسترس هستند: \fBquery\-by\-relay\-id\fP (3)، \fBquery\-by\-link\-address\fP (4) و \fBquery\-by\-remote\-id\fP (5). .sp یک کد وضعیت جدید، \fBSTATUS_QueryTerminated\fP (11)، تعریف شده است اما هنوز توسط کتابخانه قلاب (hook library) استفاده نمی‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برنامه Kea تلاش می‌کند تا پارامترهای نشانی پیوند (link address) را به پیشوندهای زیرشبکه‌های پیکربندی‌شده نگاشت کند. اگر نشانی داده‌شده خارج از تمام پیشوندهای زیرشبکه پیکربندی‌شده قرار گیرد، پرس‌وجو با کد وضعیت \fBSTATUS_NotConfigured\fP\& با شکست مواجه می‌شود. چنانچه پارامتر link address برای \fBquery\-by\-relay\-id\fP یا \fBquery\-by\-remote\-id\fP برابر با \fB::\fP نباشد (یعنی خالی نباشد)، تنها پیشوندهای واگذارشده‌ای که درون پیشوندهای زیرشبکه منطبق قرار دارند بازگردانده می‌شوند. در حال حاضر، \fBquery\-by\-address\fP از یافتن پیشوندهای واگذارشده با مشخص کردن نشانی‌ای که درون پیشوند قرار دارد، پشتیبانی نمی‌کند. .UNINDENT .UNINDENT.SS پیکربندی Bulk Leasequery .sp پیکربندی Bulk Leasequery از طریق یک پارامتر نگاشت (map) جدید به نام \fBadvanced\fP با این ورودی‌های ممکن مشخص می‌شود: .INDENT 0.0 .IP \(bu 2 \fBbulk\-query\-enabled\fP .INDENT 2.0 .INDENT 3.5 هنگامی که \fBtrue\fP باشد، Kea اتصال‌ها را از نشانی‌های IP موجود در فهرست requesters می‌پذیرد و bulk leasequeryهای دریافتی را پردازش می‌کند. مقدار پیش‌فرض \fBfalse\fP است\&. .UNINDENT .UNINDENT .IP \(bu 2 \fBactive\-query\-enabled\fP .INDENT 2.0 .INDENT 3.5 این یک پارامتر پیش‌بینی‌شده است: در صورت تنظیم، باید \fBfalse\fP باشد\&. .UNINDENT .UNINDENT .IP \(bu 2 \fBextended\-info\-tables\-enabled\fP .INDENT 2.0 .INDENT 3.5 هنگامی که \fBtrue\fP باشد، پسانه اجاره (lease backend) اطلاعات تکمیلی اجاره DHCPv6 (اطلاعات رله) را در جدول‌ها مدیریت می‌کند تا از انواع جدید DHCPv6 Bulk Leasequery شامل by\-relay\-id و by\-remote\-id پشتیبانی کند. مقدار پیش‌فرض، استفاده از همان مقدار \fBbulk\-query\-enabled\fP است\&. .UNINDENT .UNINDENT .IP \(bu 2 \fBlease\-query\-ip\fP .INDENT 2.0 .INDENT 3.5 این نشانی IP است که باید برای اتصال‌ها روی آن شنود انجام شود. این نشانی باید از همان خانواده سرور باشد، برای مثال IPv6 برای سرور DHCPv6\&. .UNINDENT .UNINDENT .IP \(bu 2 \fBlease\-query\-port\fP .INDENT 2.0 .INDENT 3.5 این درگاهی (پورت) است که باید روی آن شنود شود. مقدار پیش‌فرض 67 برای IPv4 و 547 برای IPv6 است؛ یعنی همان مقدار سرویس UDP DHCP، اما برای TCP\&. .UNINDENT .UNINDENT .IP \(bu 2 \fBmax\-bulk\-query\-threads\fP .INDENT 2.0 .INDENT 3.5 این مقدار حداکثر تعداد ریسه‌هایی (threads) را نشان می‌دهد که پردازش bulk leasequery باید استفاده کند. مقدار 0 به سرور دستور می‌دهد از همان تعداد ریسه‌هایی استفاده کند که هسته Kea برای چندریسمانی (multi\-threading) پروتکل DHCP به کار می‌برد. مقدار پیش‌فرض 0 است\&. .UNINDENT .UNINDENT .IP \(bu 2 \fBmax\-requester\-connections\fP .INDENT 2.0 .INDENT 3.5 این حداکثر تعداد اتصال‌های هم‌زمان درخواست‌کننده است. مقدار پیش‌فرض 10 است؛ مقدار باید بزرگ‌تر از 0 باشد\&. .UNINDENT .UNINDENT .IP \(bu 2 \fBmax\-concurrent\-queries\fP .INDENT 2.0 .INDENT 3.5 این حداکثر تعداد پرس‌وجوهای هم‌زمان به ازای هر اتصال است. مقدار 0 به Kea امکان می‌دهد که تعداد را تعیین کند، و مقدار پیش‌فرض است\&. .UNINDENT .UNINDENT .IP \(bu 2 \fBmax\-requester\-idle\-time\fP .INDENT 2.0 .INDENT 3.5 این مدت‌زمانی است که پس از دریافت داده از یک درخواست‌کننده، پیش از اینکه اتصال آن به دلیل بیکار بودن (idle) بسته شود، می‌تواند سپری شود (به ثانیه). مقدار پیش‌فرض 300 است\&. .UNINDENT .UNINDENT .IP \(bu 2 \fBmax\-leases\-per\-fetch\fP .INDENT 2.0 .INDENT 3.5 این حداکثر تعداد اجاره‌ها برای بازگرداندن در یک واکشی (fetch) منفرد است. مقدار پیش‌فرض 100 است\&. .UNINDENT .UNINDENT .UNINDENT .sp پس از پشتیبانی از TLS، انتظار داریم پارامترهای مشترک TLS پیاده‌سازی شوند. .sp برای نمونه، برای DHCPv4: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_query.so\(dq, \(dqparameters\(dq: { \(dqrequesters\(dq: [ \(dq192.0.2.1\(dq, \(dq192.0.2.2\(dq ], \(dqadvanced\(dq : { \(dqbulk\-query\-enabled\(dq: true, \(dqactive\-query\-enabled\(dq: false, \(dqlease\-query\-ip\(dq: \(dq127.0.0.1\(dq, \(dqlease\-query\-tcp\-port\(dq: 67, \(dqmax\-bulk\-query\-threads\(dq: 0, \(dqmax\-requester\-connections\(dq: 10, \(dqmax\-concurrent\-queries\(dq: 4, \(dqmax\-requester\-idle\-time\(dq: 300, \(dqmax\-leases\-per\-fetch\(dq: 100 } } } ], ... } .EE .UNINDENT .UNINDENT .sp یا برای DHCPv6: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_lease_query.so\(dq, \(dqparameters\(dq: { \(dqrequesters\(dq: [ \(dq2001:db8:1::1\(dq, \(dq2001:db8:2::1\(dq ], \(dqadvanced\(dq : { \(dqbulk\-query\-enabled\(dq: true, \(dqactive\-query\-enabled\(dq: false, \(dqextended\-info\-tables\-enabled\(dq: true, \(dqlease\-query\-ip\(dq: \(dq::1\(dq, \(dqlease\-query\-tcp\-port\(dq: 547, \(dqmax\-bulk\-query\-threads\(dq: 0, \(dqmax\-requester\-connections\(dq: 10, \(dqmax\-concurrent\-queries\(dq: 4, \(dqmax\-requester\-idle\-time\(dq: 300, \(dqmax\-leases\-per\-fetch\(dq: 100 } } } ], ... } .EE .UNINDENT .UNINDENT.SS به‌روزرسانی اجاره‌های موجود در بک‌اندهای اجارهٔ SQL .sp ویژگی Bulk Leasequery نیازمند داده‌های اضافه‌تری برای اطلاعات اجارهٔ ذخیره‌شده است. در بک‌اندهای اجارهٔ SQL، اجاره‌هایی که پیش از پیکربندی کارساز برای Bulk Leasequery ایجاد شده‌اند، فاقد این داده‌های جدید مورد نیاز هستند. برای پر کردن این داده‌ها، اجرای این دستورهای API ضروری است: .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اجاره‌های موجود باید توسط Kea با فعال بودن \fBstore\-extended\-info\fP ایجاد شده باشند تا داده‌های جدید از اطلاعات تکمیلی (extended info) قابل استخراج و ذخیره‌سازی باشند. .UNINDENT .UNINDENT .sp برای داده‌های اجارهٔ DHCPv4، دستور به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqextended\-info4\-upgrade\(dq } .EE .UNINDENT .UNINDENT .sp برای داده‌های اجارهٔ DHCPv6، دستور به این صورت است: .sp برای اطلاعات تکمیلی مورد استفاده توسط relay ID و توسط remote ID، دستور به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqextended\-info6\-upgrade\(dq } .EE .UNINDENT .UNINDENT .sp در تمام موارد، پاسخ نشان می‌دهد که عملیات با موفقیت انجام شده یا شکست خورده است و شامل تعداد اجاره‌های به‌روزشده یا ماهیت خطا خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqUpgraded 1000 leases\(dq } .EE .UNINDENT .UNINDENT .sp این دستور \fBextended\-info6\-upgrade\fP باید در شرایط زیر اجرا شود: .INDENT 0.0 .IP \(bu 2 طرحوارهٔ (schema) پایگاه داده از نگارش 2.4.1 یا نگارش‌های قدیمی‌تر ارتقا یافته باشد. هنگام ارتقا از نگارش 2.3.8 یا قدیمی‌تر می‌توان از \fBextended\-info4\-upgrade\fP استفاده کرد. .IP \(bu 2 قابلیت Bulk Leasequery فعال نبوده باشد؛ جدول‌ها تنها زمانی نگهداری می‌شوند که v6 BLQ فعال باشد. .IP \(bu 2 داده‌های موجود در جدول‌ها سازگار به نظر نرسند؛ جدول‌ها به صورت اتمیک نگهداری نمی‌شوند، بنابراین سازگاری تضمین نمی‌شود. برای نمونه، هنگامی که یک پایگاه داده میان چند کارساز به اشتراک گذاشته شده است، ممکن است بین به‌روزرسانی‌ها شرایط رقابتی رخ دهد. .UNINDENT .sp عملکرد دستور extended info توسط پارامتر \fBextended\-info\-checks\fP زیر عنصر \fBsanity\-checks\fP کنترل می‌شود. لطفاً «بررسی‌های سلامت در DHCPv4» \%<#\:sanity-checks4> یا «بررسی‌های سلامت در DHCPv6» \%<#\:sanity-checks6>\& را ببینید. .sp برای تعداد زیادی از اجاره‌ها، ممکن است تکمیل این دستور مدتی زمان ببرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هر دو دستور \fBextended\-info4\-upgrade\fP و \fBextended\-info6\-upgrade\fP برای استفادهٔ یک‌باره پس از ارتقا به نگارشی از Kea در نظر گرفته شده‌اند که به طور کامل از Bulk Leasequery در بک‌اندهای پایگاه داده پشتیبانی می‌کند. این دستورها برای استفادهٔ مکرر نیستند و در نگارش‌های آیندهٔ Kea حذف خواهند شد. .UNINDENT .UNINDENT .SS \fBlibdhcp_legal_log.so\fP: ثبت وقایع قانونی (Forensic Logging) .sp کتابخانهٔ قلاب Forensic Logging، قلاب‌هایی را فراهم می‌کند که گزارش تفصیلی تخصیص‌ها، تمدیدها، آزادسازی‌ها و سایر رویدادهای مربوط به اجاره را در مجموعه‌ای از فایل‌های لاگ ثبت می‌نمایند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کتابخانهٔ \fBlibdhcp_legal_log.so\fP بخشی از کد منبع‌باز است و در دسترس همهٔ کاربران Kea قرار دارد. این کتابخانه پیش‌تر تنها در دسترس مشتریان ISC دارای قرارداد پشتیبانی تجاری بود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه فقط می‌تواند توسط فرایندهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp در بسیاری از حوزه‌های قضایی، شرکت‌ها \- به ویژه ISPها \- باید اطلاعات مربوط به نشانی‌هایی را که به کلاینت‌های DHCP اجاره داده‌اند ثبت کنند. این کتابخانه برای کمک به برآورده کردن این الزام طراحی شده است. اگر اطلاعاتی که ثبت می‌کند کافی باشد، می‌توان مستقیماً از آن استفاده کرد. .sp چنانچه حوزه‌ای قضایی نیازمند ذخیرهٔ اطلاعات متفاوتی باشد، کاربران می‌توانند از قابلیت قالب‌بندی سفارشی برای استخراج اطلاعات از بستهٔ درخواست ورودی یا بستهٔ پاسخ خروجی استفاده کنند. به مدیران سیستم توصیه می‌شود با احتیاط از این ویژگی استفاده نمایند، زیرا ممکن است بر کارایی کارساز اثر بگذارد. از قالب سفارشی نمی‌توان برای دستورهای کانال کنترل استفاده کرد. .sp همچنین می‌توان از این کتابخانه به عنوان الگو یا نمونه‌ای برای قلاب ثبت گزارش سفارشی خود کاربر استفاده کرد. ثبت گزارش به عنوان مجموعه‌ای از قلاب‌ها انجام می‌شود تا امکان سفارشی‌سازی آن برای هر نیاز خاصی وجود داشته باشد؛ تغییر دادن یک کتابخانهٔ قلاب بسیار ساده‌تر و امن‌تر از دستکاری کد هسته است. علاوه بر این، با استفاده از ویژگی‌های قلاب، کاربرانی که نیازی به ثبت این اطلاعات ندارند می‌توانند آن را کنار بگذارند و از افت کارایی جلوگیری کنند..SS نام‌گذاری فایل لاگ (Log File Naming) .sp نام‌های فایل‌های لاگ از یک الگوی مشخص پیروی می‌کنند. .sp در صورت استفاده از \fBday\fP، \fBmonth\fP یا \fByear\fP به‌عنوان واحد زمانی، نام فایل از قالب زیر پیروی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX path/base\-name.CCYYMMDD.txt .EE .UNINDENT .UNINDENT .sp که در آن \fBCC\fP بیانگر قرن، \fBYY\fP نشان‌دهندهٔ سال، \fBMM\fP نشان‌دهندهٔ ماه، و \fBDD\fP نشان‌دهندهٔ روز است. .sp در صورت استفاده از \fBsecond\fP به‌عنوان واحد زمانی، نام فایل از قالب زیر پیروی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX path/base\-name.TXXXXXXXXXXXXXXXXXXXX.txt .EE .UNINDENT .UNINDENT .sp که در آن \fBXXXXXXXXXXXXXXXXXXXX\fP بیانگر زمان بر حسب ثانیه از ابتدای مبدأ یونیکس (UNIX epoch) است. .sp هنگام استفاده از \fBsecond\fP به‌عنوان واحد زمانی، فایل پس از سپری شدن تعداد ثانیه‌های مشخص‌شده در \fBcount\fP چرخانده می‌شود. در مقابل، هنگام استفاده از \fBday\fP، \fBmonth\fP یا \fByear\fP به‌عنوان واحد زمانی، فایل هر زمان که بر اساس مورد، شمارش (\fBcount\fP) روز، ماه یا سال آغاز شود، چرخانده می‌شود. .sp مقدارهای \fB\(dqpath\(dq\fP و \fB\(dqbase\-name\(dq\fP همان‌طور که در زیر شرح داده شده در پیکربندی مشخص می‌شوند؛ بخش «پیکربندی قلاب‌های ثبت لاگ قضایی (Configuring the Forensic Logging Hooks)» را ببینید\&. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگام اجرای کارسازهای Kea برای هر دو پروتکل DHCPv4 و DHCPv6، نام‌های لاگ باید متمایز باشند. مثال‌های موجود در «پیکربندی قلاب‌های ثبت لاگ قضایی (Configuring the Forensic Logging Hooks)» را ببینید\&. .UNINDENT .UNINDENT .SS پیکربندی قلاب‌های ثبت لاگ قضایی (Configuring the Forensic Logging Hooks) .sp برای استفاده از این قابلیت، کتابخانهٔ قلاب (hook library) باید در پیکربندی پودمان‌های کارساز DHCP مورد نظر گنجانده شود. \fBlibdhcp_legal_log.so\fP می‌تواند لاگ‌ها را در یک فایل متنی یا در یک پایگاه‌داده ذخیره کند (ایجاد شده با استفاده از \fBkea\-admin\fP \%<#\:std-iscman-kea-admin>؛ بخش‌های «ساخت اولیهٔ پایگاه‌دادهٔ MySQL» \%<#\:mysql-database-create> و «ساخت اولیهٔ پایگاه‌دادهٔ PostgreSQL» \%<#\:pgsql-database-create> را ببینید). این کتابخانه در کنار کتابخانه‌های Kea در \fB\(dq[kea\-install\-dir]/var/log/kea\(dq\fP نصب می‌شود، که در آن \fBkea\-install\-dir\fP توسط گزینهٔ \fB\-\-prefix\fP در meson setup تعیین می‌شود و به‌طور پیش‌فرض \fB/usr/local\fP است\&. با فرض مقدار پیش‌فرض، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> را می‌توان به‌صورت زیر برای بارگذاری \fBlibdhcp_legal_log.so\fP پیکربندی کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_legal_log.so\(dq, \(dqparameters\(dq: { \(dqpath\(dq: \(dq/var/log/kea\(dq, \(dqbase\-name\(dq: \(dqkea\-forensic4\(dq } } ] } } .EE .UNINDENT .UNINDENT .sp برای \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>، پیکربندی به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_legal_log.so\(dq, \(dqparameters\(dq: { \(dqpath\(dq: \(dq/var/log/kea\(dq, \(dqbase\-name\(dq: \(dqkea\-forensic6\(dq } } ] } } .EE .UNINDENT .UNINDENT .sp پارامترهای کتابخانهٔ قلاب برای پیکربندی فایل متنی عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBpath\fP \- دایرکتوری‌ای که فایل(های) لاگ قضایی در آن نوشته خواهند شد. مقدار پیش‌فرض \fB\(dq[kea\-install\-dir]/var/log/kea\(dq\fP است\&. این دایرکتوری باید وجود داشته باشد. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 2.7.9 به بعد، فایل‌های لاگ قانونی فقط می‌توانند در دایرکتوری خروجی تعیین‌شده در حین کامپایل نوشته شوند: \fB\(dq[kea\-install\-dir]/var/log/kea\(dq\fP\&. این مسیر را می‌توان در زمان راه‌اندازی با تنظیم متغیر محیطی \fBKEA_LEGAL_LOG_DIR\fP روی مسیر دلخواه بازنویسی کرد. اگر مسیری غیر از این مقدار در \fBpath\fP استفاده شود، Kea خطایی صادر کرده و از شروع به کار خودداری می‌کند، یا در صورت در حال اجرا بودن، یک خطای جبران‌ناپذیر ثبت می‌کند. برای سهولت در استفاده، کافی است پارامتر \fBpath\fP را حذف کنید. .UNINDENT .UNINDENT .INDENT 0.0 .IP \(bu 2 \fBbase\-name\fP \- یک مقدار دلخواه که همراه با تاریخ فعلی سیستم برای تشکیل نام فایل لاگ قضایی جاری استفاده می‌شود. مقدار پیش‌فرض آن \fBkea\-legal\fP است\&. .IP \(bu 2 \fBtime\-unit\fP \- واحد زمانی مورد استفاده برای چرخش فایل لاگ را پیکربندی می‌کند. مقدارهای معتبر عبارتند از \fBsecond\fP، \fBday\fP، \fBmonth\fP یا \fByear\fP\&. مقدار پیش‌فرض آن \fBday\fP است\&. .IP \(bu 2 \fBcount\fP \- تعداد واحدهای زمانی که باید تا زمان چرخش فایل لاگ سپری شوند را پیکربندی می‌کند. این مقدار می‌تواند هر عدد مثبتی باشد، یا 0 که چرخش لاگ را غیرفعال می‌کند. مقدار پیش‌فرض آن 1 است. .UNINDENT .sp اگر چرخش لاگ غیرفعال باشد، هنگام بارگذاری کتابخانه یک فایل جدید ایجاد می‌شود؛ نام فایل جدید با هر نام فایل قبلی متفاوت خواهد بود. .sp اقدامات اضافی را می‌توان درست قبل از بستن فایل قدیمی و پس از باز کردن فایل جدید انجام داد. این اقدامات باید به یک فایل اجرایی یا اسکریپت خارجی اشاره داشته باشند و با تنظیمات زیر پیکربندی می‌شوند: .INDENT 0.0 .IP \(bu 2 \fBprerotate\fP \- یک فایل اجرایی یا اسکریپت خارجی که با نام فایلی که قرار است بسته شود فراخوانی می‌شود. Kea منتظر پایان فرایند نمی‌ماند. .IP \(bu 2 \fBpostrotate\fP \- یک فایل اجرایی یا اسکریپت خارجی که با نام فایلی که باز شده است فراخوانی می‌شود. Kea منتظر پایان فرایند نمی‌ماند. .UNINDENT .sp این فایل‌های اجرایی باید در دایرکتوری \fB\(dq[kea\-install\-dir]/share/kea/scripts/\(dq\fP ذخیره شوند که می‌توان آن را هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_HOOK_SCRIPTS_PATH\fP روی یک مسیر متفاوت بازنویسی کرد. .sp می‌توان قالب‌بندی سفارشی را برای ثبت اطلاعاتی فعال کرد که از بستهٔ درخواست کلاینت یا از بستهٔ پاسخ کارساز قابل استخراج هستند. با احتیاط استفاده کنید زیرا ممکن است بر عملکرد کارساز تأثیر بگذارد. قالب سفارشی نمی‌تواند برای دستورهای کانال کنترلی استفاده شود. دو پارامتر را می‌توان برای این هدف، به‌صورت هم‌زمان یا جداگانه استفاده کرد: .INDENT 0.0 .IP \(bu 2 \fBrequest\-parser\-format\fP \- یک عبارت ارزیابی‌شده و تجزیه‌شده که برای استخراج و ثبت داده‌ها از بستهٔ ورودی استفاده می‌شود. .IP \(bu 2 \fBresponse\-parser\-format\fP \- یک عبارت ارزیابی‌شده و تجزیه‌شده که برای استخراج و ثبت داده‌ها از بستهٔ پاسخ کارساز استفاده می‌شود. .UNINDENT .sp برای مشاهدهٔ فهرستی از عبارت‌ها، به بخش «استفاده از عبارت‌ها در دسته‌بندی» \%<#\:classification-using-expressions> مراجعه کنید. در صورت پیکربندی هر یک از \fBrequest\-parser\-format\fP یا \fBresponse\-parser\-format\fP، قالب لاگ پیش‌فرض استفاده نخواهد شد. اگر هر دوی آن‌ها پیکربندی شوند، پیام لاگ حاصل با الحاق داده‌های استخراج‌شده از درخواست و داده‌های استخراج‌شده از پاسخ ساخته می‌شود. .sp قالب‌بندی سفارشی ثبت لاگ در چندین خط را با استفاده از رشتهٔ هگز 0x0a (کد ASCII برای خط جدید) امکان‌پذیر می‌کند. در فایل لاگ، در ابتدای هر خط برچسب زمانی لاگ اضافه می‌شود. برای بک‌اند پایگاه‌داده، داده‌ها (شامل نویسهٔ خط جدید) در همان مدخل ذخیره می‌شوند. .sp مثال‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_legal_log.so\(dq, \(dqparameters\(dq: { \(dqpath\(dq: \(dq/var/log/kea\(dq, \(dqbase\-name\(dq: \(dqkea\-forensic6\(dq, \(dqrequest\-parser\-format\(dq: \(dq\(aqfirst line\(aq + 0x0a + \(aqsecond line\(aq\(dq, \(dqresponse\-parser\-format\(dq: \(dq\(aqalso second line\(aq + 0x0a + \(aqthird line\(aq\(dq } } ] } } .EE .UNINDENT .UNINDENT .sp برخی داده‌ها ممکن است در درخواست یا فقط در پاسخ در دسترس باشند؛ داده‌های موجود در بستهٔ درخواست ممکن است با داده‌های موجود در بستهٔ پاسخ تفاوت داشته باشند. .sp زمینهٔ lease\-client فقط با استفاده از قالب پیش‌فرض قابل چاپ است، زیرا این اطلاعات مستقیماً در بستهٔ درخواست یا بستهٔ پاسخ ذخیره نمی‌شود. .sp پارامتر \fBtimestamp\-format\fP می‌تواند برای تغییر برچسب زمانی ثبت‌شده در ابتدای هر خط استفاده شود. قالب‌بندی‌های مجاز مواردی هستند که توسط strftime پشتیبانی می‌شوند به‌علاوهٔ قالب اضافی \(aq%Q\(aq که زیرواحدهای میکروثانیه را اضافه می‌کند. مقدار پیش‌فرض عبارت است از: \(dq%Y\-%m\-%d %H:%M:%S %Z\(dq. این پارامتر برای بک‌اندهای پایگاه‌داده که در آن‌ها برچسب زمانی در سطح طرحواره (schema) تعریف شده است، اثری ندارد. .sp مثال‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_legal_log.so\(dq, \(dqparameters\(dq: { \(dqpath\(dq: \(dq/var/log/kea\(dq, \(dqbase\-name\(dq: \(dqkea\-forensic6\(dq, \(dqtimestamp\-format\(dq: \(dq%H%t%w %F%%\(dq } } ] } } .EE .UNINDENT .UNINDENT .sp پارامترهای اضافی برای اتصال پایگاه‌داده را می‌توان مشخص کرد، برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_legal_log.so\(dq, \(dqparameters\(dq: { \(dqname\(dq: \(dqdatabase\-name\(dq, \(dqpassword\(dq: \(dq1234\(dq, \(dqtype\(dq: \(dqmysql\(dq, \(dquser\(dq: \(dquser\-name\(dq } } ] } } .EE .UNINDENT .UNINDENT .sp برای اطلاعات مشخص‌تر دربارهٔ پارامترهای مرتبط با پایگاه‌داده، لطفاً به «پیکربندی پایگاه‌دادهٔ اجاره‌ها» \%<#\:database-configuration4> و «پیکربندی پایگاه‌دادهٔ اجاره‌ها» \%<#\:database-configuration6>\& مراجعه کنید. .sp اگر تمایل دارید ثبت لاگ قضایی را به زیرشبکه‌های خاصی محدود کنید، پارامتر بولی \fB\(dqlegal\-logging\(dq\fP می‌تواند در یک زمینهٔ کاربری (user context) از این زیرشبکه‌ها مشخص شود. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.1 \- 192.0.2.200\(dq } ], \(dquser\-context\(dq: { \(dqlegal\-logging\(dq: false } } ] } } .EE .UNINDENT .UNINDENT .sp این پیکربندی ثبت لاگ قضایی را برای زیرشبکهٔ \(dq192.0.2.0/24\(dq غیرفعال می‌کند. اگر پارامتر \fB\(dqlegal\-logging\(dq\fP مشخص نشده باشد، مقدار پیش‌فرض آن \fBtrue\fP خواهد بود که ثبت لاگ قضایی را برای زیرشبکه فعال می‌کند. .sp مثال زیر نحوهٔ غیرفعال کردن انتخابی ثبت لاگ قضایی را برای یک زیرشبکهٔ IPv6 نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::1\-2001:db8:1::ffff\(dq } ], \(dquser\-context\(dq: { \(dqlegal\-logging\(dq: false } } ] } } .EE .UNINDENT .UNINDENT .sp برای کسب اطلاعات بیشتر دربارهٔ زمینه‌های کاربری در پیکربندی Kea، به «زمینه‌های کاربری در IPv4» \%<#\:dhcp4-user-contexts> و «زمینه‌های کاربری در IPv6» \%<#\:dhcp6-user-contexts> مراجعه کنید..SS "ورودی‌های گزارش DHCPv4 (DHCPv4 Log Entries)" .sp برای DHCPv4، این کتابخانه بر اساس پیام‌های DHCPREQUEST،‏ DHCPDECLINE،‏ DHCPRELEASE و غیره، و پاسخ‌های آن‌ها ورودی ایجاد می‌کند. بسته‌ها و اجاره‌های حاصل با رهگیری از طریق نقاط قلاب (hook points) زیر در نظر گرفته می‌شوند: .INDENT 0.0 .IP \(bu 2 \fBpkt4_receive\fP .IP \(bu 2 \fBleases4_committed\fP .IP \(bu 2 \fBpkt4_send\fP .IP \(bu 2 \fBlease4_release\fP .IP \(bu 2 \fBlease4_decline\fP .UNINDENT .sp هر ورودی یک رشته‌ی واحد بدون نشانگرهای انتهای خط درون‌متنی و همراه با برچسب زمان در ابتدا است، و بخش‌های زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX timestamp address duration device\-id {client\-info} {relay\-info} {user\-context} .EE .UNINDENT .UNINDENT .sp به طوری که: .INDENT 0.0 .IP \(bu 2 \fBtimestamp\fP \- تاریخ و زمانی که ورودی گزارش نوشته شده است، در قالب strftime با فرمت \(dq%Y\-%m\-%d %H:%M:%S %Z\(dq (\(dq%Z\(dq نام منطقه زمانی است). .IP \(bu 2 \fBaddress\fP \- نشانی IPv4 اجاره‌داده‌شده‌ی اعطا شده، و اینکه آیا واگذار (assigned)، تمدید (renewed)، یا آزاد (released) شده است. .IP \(bu 2 \fBduration\fP \- طول عمر اجاره که بر حسب روز (در صورت وجود)، ساعت، دقیقه و ثانیه بیان می‌شود. طول عمر اجاره‌ی 0xFFFFFFFF با متن \(dqinfinite duration\(dq مشخص می‌شود. این اطلاعات هنگام آزادسازی اجاره ارائه نمی‌شود. .IP \(bu 2 \fBdevice\-id\fP \- نشانی سخت‌افزاری کلاینت که به صورت یک نوع عددی و رشته‌ای از ارقام هگزادسیمال نشان داده می‌شود. .IP \(bu 2 \fBclient\-info\fP \- گزینه‌ی شناسه کلاینت DHCP (گزینه 61) در صورت وجود، که به صورت یک رشته هگز نمایش داده می‌شود. هنگامی که محتوای آن قابل چاپ باشد، نمایش داده می‌شود. .IP \(bu 2 \fBrelay\-info\fP \- برای بسته‌های رله‌شده، مقادیر \fBgiaddr\fP و گزینه‌های RAI شامل \fBcircuit\-id\fP، \fBremote\-id\fP، و \fBsubscriber\-id\fP (زیرگزینه‌های ۱، ۲ و ۶ از گزینه ۸۲)، در صورت وجود. مقادیر \fBcircuit\-id\fP و \fBremote\-id\fP به صورت رشته‌های هگز ارائه می‌شوند. هنگامی که محتوای آن‌ها قابل چاپ باشد، نمایش داده می‌شود. .IP \(bu 2 \fBuser\-context\fP \- بافت کاربری اختیاری مرتبط با اجاره. .UNINDENT .sp برای مثال (شکست‌های خط در اینجا صرفاً برای خوانایی اضافه شده‌اند؛ آن‌ها در فایل گزارش وجود ندارند): .INDENT 0.0 .INDENT 3.5 .sp .EX 2018\-01\-06 01:02:03 CET Address: 192.2.1.100 has been renewed for 1 hrs 52 min 15 secs to a device with hardware address: hwtype=1 08:00:2b:02:3f:4e, client\-id: 17:34:e2:ff:09:92:54 connected via relay at address: 192.2.16.33, identified by circuit\-id: 68:6f:77:64:79 (howdy) and remote\-id: 87:f6:79:77:ef .EE .UNINDENT .UNINDENT .sp یا برای آزادسازی: .INDENT 0.0 .INDENT 3.5 .sp .EX 2018\-01\-06 01:02:03 CET Address: 192.2.1.100 has been released from a device with hardware address: hwtype=1 08:00:2b:02:3f:4e, client\-id: 17:34:e2:ff:09:92:54 connected via relay at address: 192.2.16.33, identified by circuit\-id: 68:6f:77:64:79 (howdy) and remote\-id: 87:f6:79:77:ef .EE .UNINDENT .UNINDENT .sp علاوه بر ثبت فعالیت‌های اجاره بر اساس ترافیک کلاینت DHCPv4، این کتابخانه‌ی قلاب همچنین ورودی‌هایی را برای دستورهای کانال کنترلی مدیریت اجاره زیر ثبت می‌کند: \fBlease4\-add\fP،‏ \fBlease4\-update\fP، و \fBlease4\-del\fP\&. این موارد نمی‌توانند قالب‌بندی سفارشی داشته باشند. هر ورودی یک رشته‌ی واحد بدون نشانگرهای انتهای خط درون‌متنی است، و به طور معمول ساختاری به شکل زیر دارد: .sp \fBlease4\-add:\fP .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* Administrator added a lease of address: *address* to a device with hardware address: *device\-id* .EE .UNINDENT .UNINDENT .sp بسته به آرگومان‌های دستور add، ممکن است شامل client\-id و duration نیز باشد. .sp مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX 2018\-01\-06 01:02:03 CET Administrator added a lease of address: 192.0.2.202 to a device with hardware address: 1a:1b:1c:1d:1e:1f for 1 days 0 hrs 0 mins 0 secs .EE .UNINDENT .UNINDENT .sp \fBlease4\-update:\fP .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* Administrator updated information on the lease of address: *address* to a device with hardware address: *device\-id* .EE .UNINDENT .UNINDENT .sp بسته به آرگومان‌های دستور update، ممکن است شامل client\-id و مدت‌زمان اجاره (lease duration) نیز باشد. .sp مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX 2018\-01\-06 01:02:03 CET Administrator updated information on the lease of address: 192.0.2.202 to a device with hardware address: 1a:1b:1c:1d:1e:1f, client\-id: 1234567890 .EE .UNINDENT .UNINDENT .sp \fBlease4\-del:\fP عملیات حذف دارای دو شکل است، یکی بر اساس نشانی و دیگری بر اساس شناسه و نوع شناسه: .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* Administrator deleted the lease for address: *address* .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* Administrator deleted a lease for a device identified by: *identifier\-type* of *identifier* .EE .UNINDENT .UNINDENT .sp در حال حاضر تنها نوع \fB@b hw\-address\fP (نشانی سخت‌افزاری) پشتیبانی می‌شود. .sp مثال‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX 2018\-01\-06 01:02:03 CET Administrator deleted the lease for address: 192.0.2.202 2018\-01\-06 01:02:12 CET Administrator deleted a lease for a device identified by: hw\-address of 1a:1b:1c:1d:1e:1f .EE .UNINDENT .UNINDENT .sp اگر کتابخانه‌ی قلاب دسترسی‌پذیری بالا (High Availability) فعال باشد، شریک (partner) به طور دوره‌ای دستورهای اجاره را با قالبی مشابه ارسال می‌کند؛ تنها تفاوت این است که صادرکننده‌ی دستور به جای \(dqAdministrator\(dq برابر \(dqHA partner\(dq خواهد بود. .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* HA partner added ... .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* HA partner updated ... .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* HA partner deleted ... .EE .UNINDENT .UNINDENT .sp گزینه‌های \fBrequest\-parser\-format\fP و \fBresponse\-parser\-format\fP می‌توانند به ترتیب برای استخراج و ثبت داده‌ها از بسته‌ی ورودی و بسته‌ی پاسخ کارساز استفاده شوند. مقدار پیکربندی‌شده، یک عبارت تجزیه‌شده‌ی ارزیابی‌شونده است که یک رشته را بازمی‌گرداند. فهرستی از توکن‌ها در فرآیند رده‌بندی کارساز توصیف شده است. با احتیاط استفاده شود زیرا ممکن است بر کارایی کارساز تأثیر بگذارد. اگر هر یک از آن‌ها پیکربندی شود، قالب پیش‌فرض ثبت گزارش استفاده نمی‌شود. اگر هر دوی آن‌ها پیکربندی شوند، پیام گزارش حاصل با الحاق داده‌های ثبت‌شده‌ی استخراج‌شده از درخواست و داده‌های ثبت‌شده‌ی استخراج‌شده از پاسخ ساخته می‌شود. .sp قالب‌بندی سفارشی امکان ثبت گزارش در چند خط را با استفاده از رشته هگز 0x0a (کد ASCII برای خط جدید) فراهم می‌کند. در مورد فایل گزارش، در ابتدای هر خط برچسب زمان گزارش قرار می‌گیرد. برای بک‌اند پایگاه داده، داده‌ها (شامل نویسه خط جدید) در همان ورودی ذخیره می‌شوند. .sp مثال‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_legal_log.so\(dq, \(dqparameters\(dq: { \(dqname\(dq: \(dqdatabase\-name\(dq, \(dqpassword\(dq: \(dq1234\(dq, \(dqtype\(dq: \(dqmysql\(dq, \(dquser\(dq: \(dquser\-name\(dq, \(dqrequest\-parser\-format\(dq: \(dq\(aqlog entry\(aq + 0x0a + \(aqsame log entry\(aq\(dq, \(dqresponse\-parser\-format\(dq: \(dq\(aqalso same log entry\(aq + 0x0a + \(aqagain same log entry\(aq\(dq } } ] } } .EE .UNINDENT .UNINDENT .sp برخی داده‌ها ممکن است فقط در درخواست یا فقط در پاسخ در دسترس باشند، و برخی داده‌ها در بسته‌ی ورودی ممکن است با داده‌های موجود در بسته‌ی پاسخ تفاوت داشته باشند. .sp مثال‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqrequest\-parser\-format\(dq: \(dqifelse(pkt4.msgtype == 4 or pkt4.msgtype == 7, \(aqAddress: \(aq + ifelse(option[50].exists, addrtotext(option[50].hex), addrtotext(pkt4.ciaddr)) + \(aq has been released from a device with hardware address: hwtype=\(aq + substring(hexstring(pkt4.htype, \(aq\(aq), 7, 1) + \(aq \(aq + hexstring(pkt4.mac, \(aq:\(aq) + ifelse(option[61].exists, \(aq, client\-id: \(aq + hexstring(option[61].hex, \(aq:\(aq), \(aq\(aq) + ifelse(pkt4.giaddr == 0.0.0.0, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(pkt4.giaddr) + ifelse(option[82].option[1].exists, \(aq, circuit\-id: \(aq + hexstring(option[82].option[1].hex, \(aq:\(aq), \(aq\(aq) + ifelse(option[82].option[2].exists, \(aq, remote\-id: \(aq + hexstring(option[82].option[2].hex, \(aq:\(aq), \(aq\(aq) + ifelse(option[82].option[6].exists, \(aq, subscriber\-id: \(aq + hexstring(option[82].option[6].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq)\(dq, \(dqresponse\-parser\-format\(dq: \(dqifelse(pkt4.msgtype == 5, \(aqAddress: \(aq + addrtotext(pkt4.yiaddr) + \(aq has been assigned for \(aq + uint32totext(option[51].hex) + \(aq seconds to a device with hardware address: hwtype=\(aq + substring(hexstring(pkt4.htype, \(aq\(aq), 7, 1) + \(aq \(aq + hexstring(pkt4.mac, \(aq:\(aq) + ifelse(option[61].exists, \(aq, client\-id: \(aq + hexstring(option[61].hex, \(aq:\(aq), \(aq\(aq) + ifelse(pkt4.giaddr == 0.0.0.0, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(pkt4.giaddr) + ifelse(option[82].option[1].exists, \(aq, circuit\-id: \(aq + hexstring(option[82].option[1].hex, \(aq:\(aq), \(aq\(aq) + ifelse(option[82].option[2].exists, \(aq, remote\-id: \(aq + hexstring(option[82].option[2].hex, \(aq:\(aq), \(aq\(aq) + ifelse(option[82].option[6].exists, \(aq, subscriber\-id: \(aq + hexstring(option[82].option[6].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq)\(dq } .EE .UNINDENT .UNINDENT .sp جزئیات: .sp این پیکربندی داده‌های زیر را در هنگام درخواست (request) و تمدید (renew) ثبت خواهد کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX Address: 192.2.1.100 has been assigned for 6735 seconds to a device with hardware address: hwtype=1 08:00:2b:02:3f:4e, client\-id: 17:34:e2:ff:09:92:54 connected via relay at address: 192.2.16.33, circuit\-id: 68:6f:77:64:79, remote\-id: 87:f6:79:77:ef, subscriber\-id: 1a:2b:3c:4d:5e:6f .EE .UNINDENT .UNINDENT .sp این پیکربندی داده‌های زیر را در هنگام آزادسازی (release) و رد کردن (decline) ثبت خواهد کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX Address: 192.2.1.100 has been released from a device with hardware address: hwtype=1 08:00:2b:02:3f:4e, client\-id: 17:34:e2:ff:09:92:54 connected via relay at address: 192.2.16.33, circuit\-id: 68:6f:77:64:79, remote\-id: 87:f6:79:77:ef, subscriber\-id: 1a:2b:3c:4d:5e:6f .EE .UNINDENT .UNINDENT .sp نتیجه‌ی مشابهی را می‌توان تنها با پیکربندی \fBrequest\-parser\-format\fP به دست آورد. .sp مثال‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqrequest\-parser\-format\(dq: \(dqifelse(pkt4.msgtype == 3, \(aqAddress: \(aq + ifelse(option[50].exists, addrtotext(option[50].hex), addrtotext(pkt4.ciaddr)) + \(aq has been assigned\(aq + ifelse(option[51].exists, \(aq for \(aq + uint32totext(option[51].hex) + \(aq seconds\(aq, \(aq\(aq) + \(aq to a device with hardware address: hwtype=\(aq + substring(hexstring(pkt4.htype, \(aq\(aq), 7, 1) + \(aq \(aq + hexstring(pkt4.mac, \(aq:\(aq) + ifelse(option[61].exists, \(aq, client\-id: \(aq + hexstring(option[61].hex, \(aq:\(aq), \(aq\(aq) + ifelse(pkt4.giaddr == 0.0.0.0, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(pkt4.giaddr) + ifelse(option[82].option[1].exists, \(aq, circuit\-id: \(aq + hexstring(option[82].option[1].hex, \(aq:\(aq), \(aq\(aq) + ifelse(option[82].option[2].exists, \(aq, remote\-id: \(aq + hexstring(option[82].option[2].hex, \(aq:\(aq), \(aq\(aq) + ifelse(option[82].option[6].exists, \(aq, subscriber\-id: \(aq + hexstring(option[82].option[6].hex, \(aq:\(aq), \(aq\(aq)), ifelse(pkt4.msgtype == 4 or pkt4.msgtype == 7, \(aqAddress: \(aq + ifelse(option[50].exists, addrtotext(option[50].hex), addrtotext(pkt4.ciaddr)) + \(aq has been released from a device with hardware address: hwtype=\(aq + substring(hexstring(pkt4.htype, \(aq\(aq), 7, 1) + \(aq \(aq + hexstring(pkt4.mac, \(aq:\(aq) + ifelse(option[61].exists, \(aq, client\-id: \(aq + hexstring(option[61].hex, \(aq:\(aq), \(aq\(aq) + ifelse(pkt4.giaddr == 0.0.0.0, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(pkt4.giaddr) + ifelse(option[82].option[1].exists, \(aq, circuit\-id: \(aq + hexstring(option[82].option[1].hex, \(aq:\(aq), \(aq\(aq) + ifelse(option[82].option[2].exists, \(aq, remote\-id: \(aq + hexstring(option[82].option[2].hex, \(aq:\(aq), \(aq\(aq) + ifelse(option[82].option[6].exists, \(aq, subscriber\-id: \(aq + hexstring(option[82].option[6].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq))\(dq } .EE .UNINDENT .UNINDENT .sp جزئیات:.SS "ورودی‌های گزارش DHCPv6 (DHCPv6 Log Entries)" .sp برای DHCPv6، کتابخانه بر اساس پیام‌های REQUEST،‏ RENEW،‏ RELEASE و DECLINE و غیره و پاسخ‌های آن‌ها ورودی ایجاد می‌کند. بسته‌ها و اجاره‌های حاصل در نظر گرفته شده و از طریق نقاط قلاب (hook points) زیر رهگیری می‌شوند: .INDENT 0.0 .IP \(bu 2 \fBpkt6_receive\fP .IP \(bu 2 \fBleases6_committed\fP .IP \(bu 2 \fBpkt6_send\fP .IP \(bu 2 \fBlease6_release\fP .IP \(bu 2 \fBlease6_decline\fP .UNINDENT .sp هر ورودی یک رشته منفرد بدون نشانگرهای انتهای خط درون‌متنی و با یک برچسب زمانی (timestamp) در ابتدا است که بخش‌های زیر را شامل می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX timestamp address duration device\-id {relay\-info}* {user\-context} .EE .UNINDENT .UNINDENT .sp که در آن: .INDENT 0.0 .IP \(bu 2 \fBtimestamp\fP \- تاریخ و زمان ثبت ورودی گزارش، در قالب strftime به صورت \(dq%Y\-%m\-%d %H:%M:%S %Z\(dq (که \(dq%Z\(dq نام منطقه زمانی است). .IP \(bu 2 \fBaddress\fP \- آدرس یا پیشوند IPv6 اجاره داده‌شده، و وضعیت آن از نظر تخصیص‌یافته، تمدیدشده یا آزادشده بودن. .IP \(bu 2 \fBduration\fP \- طول عمر اجاره بیان‌شده به روز (در صورت وجود)، ساعت، دقیقه و ثانیه. طول عمر اجاره با مقدار 0xFFFFFFFF با متن \(dqinfinite duration.\(dq مشخص خواهد شد. این اطلاعات هنگام آزادسازی اجاره ارائه نمی‌شود. .IP \(bu 2 \fBdevice\-id\fP \- شناسه DUID و آدرس سخت‌افزاری کلاینت (در صورت وجود). .IP \(bu 2 \fBrelay\-info\fP \- برای بسته‌های رله‌شده، محتوای پیام‌های کارگزار رله، و گزینه‌های \fBremote\-id\fP (کد ۳۷)، \fBsubscriber\-id\fP (کد ۳۸) و \fBinterface\-id\fP (کد ۱۸) در صورت وجود. توجه داشته باشید که گزینه \fBinterface\-id\fP، در صورت وجود، کل رابطی را که کارگزار رله پیام را روی آن دریافت کرده مشخص می‌کند. این معمولاً به یک پیوند واحد در شبکه ترجمه می‌شود، اما به توپولوژی خاص شبکه بستگی دارد. با این وجود، این اطلاعات مفیدی برای تعیین دقیق‌تر مکان دستگاه است، بنابراین در صورت وجود ثبت می‌شود. .IP \(bu 2 \fBuser\-context\fP \- بافت کاربر (user context) اختیاری مرتبط با اجاره. .UNINDENT .sp به عنوان مثال (شکست‌های خط در اینجا برای خوانایی اضافه شده‌اند؛ آن‌ها در فایل گزارش وجود ندارند): .INDENT 0.0 .INDENT 3.5 .sp .EX 2018\-01\-06 01:02:03 PST Address:2001:db8:1:: has been assigned for 0 hrs 11 mins 53 secs to a device with DUID: 17:34:e2:ff:09:92:54 and hardware address: hwtype=1 08:00:2b:02:3f:4e (from Raw Socket) connected via relay at address: fe80::abcd for client on link address: 3001::1, hop count: 1, identified by remote\-id: 01:02:03:04:0a:0b:0c:0d:0e:0f and subscriber\-id: 1a:2b:3c:4d:5e:6f .EE .UNINDENT .UNINDENT .sp یا برای آزادسازی: .INDENT 0.0 .INDENT 3.5 .sp .EX 2018\-01\-06 01:02:03 PST Address:2001:db8:1:: has been released from a device with DUID: 17:34:e2:ff:09:92:54 and hardware address: hwtype=1 08:00:2b:02:3f:4e (from Raw Socket) connected via relay at address: fe80::abcd for client on link address: 3001::1, hop count: 1, identified by remote\-id: 01:02:03:04:0a:0b:0c:0d:0e:0f and subscriber\-id: 1a:2b:3c:4d:5e:6f .EE .UNINDENT .UNINDENT .sp علاوه بر ثبت فعالیت‌های اجاره ناشی از ترافیک کلاینت DHCPv6، کتابخانه قلاب ورودی‌هایی را نیز برای دستورهای کانال کنترلی مدیریت اجاره زیر ثبت می‌کند: \fBlease6\-add\fP، \fBlease6\-update\fP و \fBlease6\-del\fP\&. هر ورودی یک رشته منفرد بدون نشانگرهای انتهای خط درون‌متنی است، و معمولاً شکل زیر را خواهد داشت: .sp \fBlease6\-add:\fP .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* Administrator added a lease of address: *address* to a device with DUID: *DUID* .EE .UNINDENT .UNINDENT .sp بسته به آرگومان‌های دستور add، ممکن است شامل آدرس سخت‌افزاری و مدت‌زمان نیز باشد. .sp مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX 2018\-01\-06 01:02:03 PST Administrator added a lease of address: 2001:db8::3 to a device with DUID: 1a:1b:1c:1d:1e:1f:20:21:22:23:24 for 1 days 0 hrs 0 mins 0 secs .EE .UNINDENT .UNINDENT .sp \fBlease6\-update:\fP .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* Administrator updated information on the lease of address: *address* to a device with DUID: *DUID* .EE .UNINDENT .UNINDENT .sp بسته به آرگومان‌های دستور update، ممکن است شامل آدرس سخت‌افزاری و مدت‌زمان اجاره نیز باشد. .sp مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX 2018\-01\-06 01:02:03 PST Administrator updated information on the lease of address: 2001:db8::3 to a device with DUID: 1a:1b:1c:1d:1e:1f:20:21:22:23:24, hardware address: 1a:1b:1c:1d:1e:1f .EE .UNINDENT .UNINDENT .sp \fBlease6\-del:\fP عملیات حذف دارای دو شکل است، یکی بر اساس آدرس و دیگری بر اساس شناسه و نوع شناسه: .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* Administrator deleted the lease for address: *address* .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* Administrator deleted a lease for a device identified by: *identifier\-type* of *identifier* .EE .UNINDENT .UNINDENT .sp در حال حاضر تنها نوع \fBDUID\fP پشتیبانی می‌شود. .sp مثال‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX 2018\-01\-06 01:02:03 PST Administrator deleted the lease for address: 2001:db8::3 2018\-01\-06 01:02:11 PST Administrator deleted a lease for a device identified by: duid of 1a:1b:1c:1d:1e:1f:20:21:22:23:24 .EE .UNINDENT .UNINDENT .sp اگر کتابخانه قلاب High Availability فعال باشد، شریک (partner) به صورت دوره‌ای دستورهای اجاره را با قالبی مشابه ارسال می‌کند؛ تنها تفاوت این است که صادرکننده دستور به جای \(dqAdministrator\(dq عبارت \(dqHA partner\(dq است. .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* HA partner added ... .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* HA partner updated ... .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX *timestamp* HA partner deleted ... .EE .UNINDENT .UNINDENT .sp گزینه‌های \fBrequest\-parser\-format\fP و \fBresponse\-parser\-format\fP می‌توانند به ترتیب برای استخراج و ثبت داده‌ها از بسته ورودی و بسته پاسخ سرور استفاده شوند. مقدار پیکربندی‌شده یک عبارت ارزیابی‌شده و تجزیه‌شده است که یک رشته برمی‌گرداند. فهرستی از نشانه‌ها (tokens) در فرآیند دسته‌بندی سرور شرح داده شده است. با احتیاط استفاده کنید زیرا ممکن است بر عملکرد سرور تأثیر بگذارد. اگر هر یک از آن‌ها پیکربندی شود، قالب پیش‌فرض ثبت وقایع استفاده نمی‌شود. اگر هر دوی آن‌ها پیکربندی شوند، پیام گزارش حاصل با الحاق داده‌های ثبت‌شده استخراج‌شده از درخواست و داده‌های ثبت‌شده استخراج‌شده از پاسخ ساخته می‌شود. .sp قالب‌بندی سفارشی ثبت گزارش در چند خط را با استفاده از رشته هگز 0x0a (کد اسکی خط جدید) مجاز می‌سازد. در مورد فایل گزارش، در ابتدای هر خط برچسب زمانی گزارش اضافه می‌شود. برای بک‌اند پایگاه داده، داده‌ها (شامل نویسه خط جدید) در همان ورودی ذخیره می‌شوند. .sp مثال‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_legal_log.so\(dq, \(dqparameters\(dq: { \(dqname\(dq: \(dqdatabase\-name\(dq, \(dqpassword\(dq: \(dq1234\(dq, \(dqtype\(dq: \(dqmysql\(dq, \(dquser\(dq: \(dquser\-name\(dq, \(dqrequest\-parser\-format\(dq: \(dq\(aqlog entry\(aq + 0x0a + \(aqsame log entry\(aq\(dq, \(dqresponse\-parser\-format\(dq: \(dq\(aqalso same log entry\(aq + 0x0a + \(aqagain same log entry\(aq\(dq } } ] } } .EE .UNINDENT .UNINDENT .sp برخی داده‌ها ممکن است فقط در درخواست یا فقط در پاسخ موجود باشند، و برخی داده‌ها در بسته ورودی ممکن است با داده‌های بسته پاسخ تفاوت داشته باشند. .sp نکات: .sp در مورد IPv6، بسته‌ها می‌توانند حاوی چندین گزینه IA_NA (۳) یا IA_PD (۲۵) باشند که هر کدام شامل چندین گزینه از جمله زیرگزینه‌های OPTION_IAADDR (۵) یا OPTION_IAPREFIX (۲۵) هستند. برای اینکه بتوان اجاره فعلی مرتبط با ورودی گزارش را چاپ کرد، کتابخانه قلاب forensic log به طور داخلی گزینه IA_NA یا IA_PD متناظر و زیرگزینه مربوطه که با اجاره فعلی مطابقت دارد را تفکیک می‌کند. کتابخانه قلاب روی تمام آدرس‌های تازه تخصیص‌یافته و همه آدرس‌های حذف‌شده پیمایش خواهد کرد و هر آدرس را برای ثبت به عنوان اجاره فعلی برای ورودی گزارش مربوطه در دسترس قرار می‌دهد. .sp آن‌ها با استفاده از عبارت‌های تجزیه‌کننده زیر در دسترس هستند: .sp اجاره فعلی مرتبط با OPTION_IAADDR: .INDENT 0.0 .INDENT 3.5 .sp .EX addrtotext(substring(option[3].option[5].hex, 0, 16)) .EE .UNINDENT .UNINDENT .sp اجاره فعلی مرتبط با OPTION_IAPREFIX: .INDENT 0.0 .INDENT 3.5 .sp .EX addrtotext(substring(option[25].option[26].hex, 9, 16)) .EE .UNINDENT .UNINDENT .sp سایر پارامترهای گزینه‌ها در آفست‌های مربوط به خود در گزینه در دسترس هستند. لطفاً برای جزئیات بیشتر RFC9915 را مطالعه کنید. .sp مثال‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqrequest\-parser\-format\(dq: \(dqifelse(pkt6.msgtype == 8 or pkt6.msgtype == 9, ifelse(option[3].option[5].exists, \(aqAddress: \(aq + addrtotext(substring(option[3].option[5].hex, 0, 16)) + \(aq has been released from a device with DUID: \(aq + hexstring(option[1].hex, \(aq:\(aq) + ifelse(relay6[0].peeraddr == \(aq\(aq, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(relay6[0].peeraddr) + \(aq for client on link address: \(aq + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, \(aq, remote\-id: \(aq + hexstring(relay6[0].option[37].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[38].exists, \(aq, subscriber\-id: \(aq + hexstring(relay6[0].option[38].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[18].exists, \(aq, connected at location interface\-id: \(aq + hexstring(relay6[0].option[18].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq) + ifelse(option[25].option[26].exists, \(aqPrefix: \(aq + addrtotext(substring(option[25].option[26].hex, 9, 16)) + \(aq/\(aq + uint8totext(substring(option[25].option[26].hex, 8, 1)) + \(aq has been released from a device with DUID: \(aq + hexstring(option[1].hex, \(aq:\(aq) + ifelse(relay6[0].peeraddr == \(aq\(aq, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(relay6[0].peeraddr) + \(aq for client on link address: \(aq + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, \(aq, remote\-id: \(aq + hexstring(relay6[0].option[37].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[38].exists, \(aq, subscriber\-id: \(aq + hexstring(relay6[0].option[38].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[18].exists, \(aq, connected at location interface\-id: \(aq + hexstring(relay6[0].option[18].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq), \(aq\(aq)\(dq, \(dqresponse\-parser\-format\(dq: \(dqifelse(pkt6.msgtype == 7, ifelse(option[3].option[5].exists and not (substring(option[3].option[5].hex, 20, 4) == 0), \(aqAddress: \(aq + addrtotext(substring(option[3].option[5].hex, 0, 16)) + \(aq has been assigned for \(aq + uint32totext(substring(option[3].option[5].hex, 20, 4)) + \(aq seconds to a device with DUID: \(aq + hexstring(option[1].hex, \(aq:\(aq) + ifelse(relay6[0].peeraddr == \(aq\(aq, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(relay6[0].peeraddr) + \(aq for client on link address: \(aq + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, \(aq, remote\-id: \(aq + hexstring(relay6[0].option[37].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[38].exists, \(aq, subscriber\-id: \(aq + hexstring(relay6[0].option[38].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[18].exists, \(aq, connected at location interface\-id: \(aq + hexstring(relay6[0].option[18].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq) + ifelse(option[25].option[26].exists and not (substring(option[25].option[26].hex, 4, 4) == 0), \(aqPrefix: \(aq + addrtotext(substring(option[25].option[26].hex, 9, 16)) + \(aq/\(aq + uint8totext(substring(option[25].option[26].hex, 8, 1)) + \(aq has been assigned for \(aq + uint32totext(substring(option[25].option[26].hex, 4, 4)) + \(aq seconds to a device with DUID: \(aq + hexstring(option[1].hex, \(aq:\(aq) + ifelse(relay6[0].peeraddr == \(aq\(aq, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(relay6[0].peeraddr) + \(aq for client on link address: \(aq + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, \(aq, remote\-id: \(aq + hexstring(relay6[0].option[37].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[38].exists, \(aq, subscriber\-id: \(aq + hexstring(relay6[0].option[38].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[18].exists, \(aq, connected at location interface\-id: \(aq + hexstring(relay6[0].option[18].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq), \(aq\(aq)\(dq } .EE .UNINDENT .UNINDENT .sp جزئیات: .sp این پیکربندی داده‌های زیر را هنگام request،‏ renew و rebind برای NA ثبت می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX Address: 2001:db8:1:: has been assigned for 713 seconds to a device with DUID: 17:34:e2:ff:09:92:54 connected via relay at address: fe80::abcd for client on link address: 3001::1, remote\-id: 01:02:03:04:0a:0b:0c:0d:0e:0f, subscriber\-id: 1a:2b:3c:4d:5e:6f, connected at location interface\-id: 72:65:6c:61:79:31:3a:65:74:68:30 .EE .UNINDENT .UNINDENT .sp این پیکربندی داده‌های زیر را هنگام request،‏ renew و rebind برای PD ثبت می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX Prefix: 2001:db8:1::/64 has been assigned for 713 seconds to a device with DUID: 17:34:e2:ff:09:92:54 connected via relay at address: fe80::abcd for client on link address: 3001::1, remote\-id: 01:02:03:04:0a:0b:0c:0d:0e:0f, subscriber\-id: 1a:2b:3c:4d:5e:6f, connected at location interface\-id: 72:65:6c:61:79:31:3a:65:74:68:30 .EE .UNINDENT .UNINDENT .sp این پیکربندی داده‌های زیر را هنگام release و decline برای NA ثبت می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX Address: 2001:db8:1:: has been released from a device with DUID: 17:34:e2:ff:09:92:54 connected via relay at address: fe80::abcd for client on link address: 3001::1, remote\-id: 01:02:03:04:0a:0b:0c:0d:0e:0f, subscriber\-id: 1a:2b:3c:4d:5e:6f, connected at location interface\-id: 72:65:6c:61:79:31:3a:65:74:68:30 .EE .UNINDENT .UNINDENT .sp این پیکربندی داده‌های زیر را هنگام release و decline برای PD ثبت می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX Prefix: 2001:db8:1::/64 has been released from a device with DUID: 17:34:e2:ff:09:92:54 connected via relay at address: fe80::abcd for client on link address: 3001::1, remote\-id: 01:02:03:04:0a:0b:0c:0d:0e:0f, subscriber\-id: 1a:2b:3c:4d:5e:6f, connected at location interface\-id: 72:65:6c:61:79:31:3a:65:74:68:30 .EE .UNINDENT .UNINDENT .sp نتیجه مشابهی را می‌توان تنها با پیکربندی \fBrequest\-parser\-format\fP به دست آورد. .sp مثال‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqrequest\-parser\-format\(dq: \(dqifelse(pkt6.msgtype == 3 or pkt6.msgtype == 5 or pkt6.msgtype == 6, ifelse(option[3].option[5].exists, \(aqAddress: \(aq + addrtotext(substring(option[3].option[5].hex, 0, 16)) + \(aq has been assigned for \(aq + uint32totext(substring(option[3].option[5].hex, 20, 4)) + \(aq seconds to a device with DUID: \(aq + hexstring(option[1].hex, \(aq:\(aq) + ifelse(relay6[0].peeraddr == \(aq\(aq, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(relay6[0].peeraddr) + \(aq for client on link address: \(aq + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, \(aq, remote\-id: \(aq + hexstring(relay6[0].option[37].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[38].exists, \(aq, subscriber\-id: \(aq + hexstring(relay6[0].option[38].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[18].exists, \(aq, connected at location interface\-id: \(aq + hexstring(relay6[0].option[18].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq) + ifelse(option[25].option[26].exists, \(aqPrefix: \(aq + addrtotext(substring(option[25].option[26].hex, 9, 16)) + \(aq/\(aq + uint8totext(substring(option[25].option[26].hex, 8, 1)) + \(aq has been assigned for \(aq + uint32totext(substring(option[25].option[26].hex, 4, 4)) + \(aq seconds to a device with DUID: \(aq + hexstring(option[1].hex, \(aq:\(aq) + ifelse(relay6[0].peeraddr == \(aq\(aq, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(relay6[0].peeraddr) + \(aq for client on link address: \(aq + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, \(aq, remote\-id: \(aq + hexstring(relay6[0].option[37].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[38].exists, \(aq, subscriber\-id: \(aq + hexstring(relay6[0].option[38].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[18].exists, \(aq, connected at location interface\-id: \(aq + hexstring(relay6[0].option[18].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq), ifelse(pkt6.msgtype == 8 or pkt6.msgtype == 9, ifelse(option[3].option[5].exists, \(aqAddress: \(aq + addrtotext(substring(option[3].option[5].hex, 0, 16)) + \(aq has been released from a device with DUID: \(aq + hexstring(option[1].hex, \(aq:\(aq) + ifelse(relay6[0].peeraddr == \(aq\(aq, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(relay6[0].peeraddr) + \(aq for client on link address: \(aq + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, \(aq, remote\-id: \(aq + hexstring(relay6[0].option[37].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[38].exists, \(aq, subscriber\-id: \(aq + hexstring(relay6[0].option[38].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[18].exists, \(aq, connected at location interface\-id: \(aq + hexstring(relay6[0].option[18].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq) + ifelse(option[25].option[26].exists, \(aqPrefix: \(aq + addrtotext(substring(option[25].option[26].hex, 9, 16)) + \(aq/\(aq + uint8totext(substring(option[25].option[26].hex, 8, 1)) + \(aq has been released from a device with DUID: \(aq + hexstring(option[1].hex, \(aq:\(aq) + ifelse(relay6[0].peeraddr == \(aq\(aq, \(aq\(aq, \(aq connected via relay at address: \(aq + addrtotext(relay6[0].peeraddr) + \(aq for client on link address: \(aq + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, \(aq, remote\-id: \(aq + hexstring(relay6[0].option[37].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[38].exists, \(aq, subscriber\-id: \(aq + hexstring(relay6[0].option[38].hex, \(aq:\(aq), \(aq\(aq) + ifelse(relay6[0].option[18].exists, \(aq, connected at location interface\-id: \(aq + hexstring(relay6[0].option[18].hex, \(aq:\(aq), \(aq\(aq)), \(aq\(aq), \(aq\(aq))\(dq } .EE .UNINDENT .UNINDENT .sp جزئیات:.SS پس‌بند پایگاه داده (Database Backend) .sp هنگامی که Kea با پشتیبانی از پس‌بند پایگاه داده پیکربندی شده باشد، مدخل‌های لاگ می‌توانند درون یک پایگاه داده درج شوند. Kea از جدول با نام \fBlogs\fP استفاده می‌کند که شامل یک برچسب زمانی تولید شده توسط نرم‌افزار پایگاه داده و یک لاگ متنی با همان قالب فایل‌ها بدون برچسب زمانی است. .sp لطفاً برای اطلاعات در مورد استفاده از پایگاه داده MySQL به MySQL \%<#\:mysql-database>، یا برای اطلاعات پایگاه داده PostgreSQL به PostgreSQL \%<#\:pgsql-database> مراجعه کنید. جدول \fBlogs\fP بخشی از طرح‌واره‌های پایگاه داده Kea است. .sp پارامترهای پیکربندی بر اساس پارامترهای استاندارد پایگاه داده اجاره (lease)، همان‌طور که در Lease Database Configuration \%<#\:database-configuration4>\& تعریف شده است، گسترش می‌یابند. پارامتر \fBtype\fP باید \fBmysql\fP، \fBpostgresql\fP، \fBlogfile\fP یا \fBsyslog\fP باشد؛ هنگامی که وجود نداشته باشد یا روی \fBlogfile\fP تنظیم شده باشد، از فایل‌ها استفاده می‌شود. .sp هیچ ابزار خاصی برای کار با پایگاه داده ارائه نشده است، اما می‌توان از ابزارهای استاندارد استفاده کرد؛ به عنوان مثال، برای استخراج جدول logs از یک پایگاه داده MySQL: .INDENT 0.0 .INDENT 3.5 .sp .EX $ mysql \-\-user keatest \-\-password 1234 \-e \(dqselect * from logs;\(dq +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-+ | timestamp | address | log | id | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-+ | 2022\-03\-30 17:38:41 | 192.168.50.1 | Address: 192.168.50.1 has been assigned for 0 hrs 10 mins 0 secs to a device with hardware address: hwtype=1 ff:01:02:03:ff:04, client\-id: 00:01:02:03:04:05:06 | 31 | | 2022\-03\-30 17:38:43 | 192.168.50.1 | Address: 192.168.50.1 has been assigned for 0 hrs 10 mins 0 secs to a device with hardware address: hwtype=1 ff:01:02:03:ff:04, client\-id: 00:01:02:03:04:05:06 | 32 | | 2022\-03\-30 17:38:45 | 192.168.50.1 | Address: 192.168.50.1 has been assigned for 0 hrs 10 mins 0 secs to a device with hardware address: hwtype=1 ff:01:02:03:ff:04, client\-id: 00:01:02:03:04:05:06 | 33 | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-+ .EE .UNINDENT .UNINDENT .sp همانند سایر ویژگی‌های مبتنی بر پایگاه داده، ثبت لاگ قانونی (forensic logging) از بازیابی اتصال پایگاه داده پشتیبانی می‌کند که می‌تواند با تنظیم پارامتر \fBon\-fail\fP فعال شود. در صورت عدم تعیین، مقدار پارامتر \fBon\-fail\fP در ثبت لاگ قانونی به‌طور پیش‌فرض برابر با \fBserve\-retry\-continue\fP\& است. این بر خلاف کتابخانه‌های \fBlibdhcp_lease_cmds.so\fP، \fBlibdhcp_host_cmds.so\fP و \fBlibdhcp_cb_cmds.so\fP است که در آن‌ها \fBon\-fail\fP به‌طور پیش‌فرض برابر با \fBstop\-retry\-exit\fP\& می‌باشد. در این حالت، کارساز به خدمت‌رسانی به کلاینت‌ها ادامه می‌دهد و حتی در صورت شکست سازوکار بازیابی نیز خاموش نمی‌شود. اگر \fBon\-fail\fP بر روی \fBserve\-retry\-exit\fP تنظیم شود، در صورتی که اتصال به پس‌بند پایگاه داده طبق پارامترهای \fBmax\-reconnect\-tries\fP و \fBreconnect\-wait\-time\fP بازیابی نشود، کارساز خاموش خواهد شد، اما تا زمانی که این سازوکار فعال است به سرویس‌دهی به کلاینت‌ها ادامه می‌دهد. .sp در هنگام راه‌اندازی کارساز، ناتوانی در اتصال به هر یک از پس‌بندهای پیکربندی‌شده تنها در صورتی مهلک تلقی می‌شود که \fBretry\-on\-startup\fP بر روی \fBfalse\fP (پیش‌فرض) تنظیم شده باشد. یک خطای مهلک ثبت شده و کارساز خارج می‌شود، بر این فرض که پیکربندی باید در زمان راه‌اندازی معتبر باشد. خروج به سیستم‌عامل به اسکریپت‌های ناظر (nanny scripts) اجازه می‌دهد تا مشکل را تشخیص دهند. اگر \fBretry\-on\-startup\fP بر روی \fBtrue\fP تنظیم شود، کارساز تلاش‌ها برای اتصال مجدد را حتی در زمان راه‌اندازی کارساز یا در هنگام رخدادهای پیکربندی مجدد آغاز می‌کند و اقدام مشخص‌شده در پارامتر \fBon\-fail\fP را اعمال می‌نماید. .SS پس‌بند Syslog (Syslog Backend) .sp مدخل‌های لاگ را می‌توان با تنظیم \fBtype\fP بر روی \fBsyslog\fP\& در syslog درج کرد. هنگامی که نوع syslog پیکربندی شده باشد، پارامتر \fBpattern\fP جزئیاتی را که برای ثبت لاگ استفاده می‌شوند مشخص می‌کند. برای جزئیات بیشتر به Logging \%<#\:logging>\& مراجعه کنید. در صورت عدم پیکربندی، پیش‌فرض آن به شرح زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dq%\-5p [%c.%t] %m\en\(dq .EE .UNINDENT .UNINDENT .sp پارامتر \fBfacility\fP بخش (facility) مورد نظر در syslog را مشخص می‌کند و مقدار پیش‌فرض آن \fBlocal0\fP\& است. .SS \fBlibdhcp_limits.so\fP: محدودیت‌ها برای مدیریت تخصیص اجاره و پردازش بسته (Limits to Manage Lease Allocation and Packet Processing) .sp این کتابخانه قلاب (hook library) دو نوع محدودیت را فعال می‌کند: .INDENT 0.0 .IP 1. 3 محدودسازی اجاره: حداکثر اجازه تخصیص \fBn\fP اجاره را در هر لحظه می‌دهد. .IP 2. 3 محدودسازی نرخ: اجازه می‌دهد در هر \fBtime_unit\fP حداکثر به \fBn\fP بسته پاسخ داده شود. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_limits.so\fP بخشی از کد متن‌باز است و در دسترس تمام کاربران Kea قرار دارد. این کتابخانه پیش‌تر تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس بود. .UNINDENT .UNINDENT .SS پیکربندی (Configuration) .sp مثال‌های زیر مربوط به \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> هستند، اما به همان ترتیب برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>\& نیز صدق می‌کنند. نویسه‌های عام \fB\(dq\(dq\fP و \fB\(dq\(dq\fP باید با کلیدها و مقادیر مربوطه برای هر نوع محدودیت شرح داده شده در بخش‌های بعد جایگزین شوند. .sp این کتابخانه می‌تواند توسط هر دو کارساز \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> با افزودن مسیر آن در عنصر \fB\(dqhooks\-libraries\(dq\fP از پیکربندی کارساز بارگذاری شود. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_limits.so\(dq } ] } } .EE .UNINDENT .UNINDENT .sp این اقدام به تنهایی هیچ چیزی را محدود نمی‌کند. محدودیت‌های مورد نظر به بافت کاربر (user context) در بخش پیکربندی عنصری که کلاینت‌های مشمول محدودیت را مشخص می‌کند اضافه می‌شوند: یک کلاس کلاینت یا یک زیرشبکه. پس از پیکربندی مجدد، در صورتی که Kea محدودیت‌های پیکربندی‌شده را تشخیص دهد، یک خط برای هر محدودیت پیکربندی‌شده لاگ می‌اندازد. پیام لاگ حاوی شناسه \fBLIMITS_CONFIGURED\fP خواهد بود. .sp نحوه تعریف محدودیت اجاره برای یک کلاس کلاینت به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: \(dqcable\-modem\-1\(dq, \(dqtest\(dq: \(dqoption[123].hex == 0x000C4B1E\(dq, \(dquser\-context\(dq: { \(dqlimits\(dq: { \(dq\(dq: \(dq\(dq } } } ] } } .EE .UNINDENT .UNINDENT .sp نحوه تعریف محدودیت اجاره برای یک زیرشبکه سراسری (global subnet) به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8::/64\(dq, \(dquser\-context\(dq: { \(dqlimits\(dq: { \(dq\(dq: \(dq\(dq } } } ] } } .EE .UNINDENT .UNINDENT .sp نحوه تعریف محدودیت اجاره برای یک زیرشبکه درون یک شبکه اشتراکی (shared network) به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqshared\-networks\(dq: [ { \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqsubnet\(dq: \(dq2001:db8::/64\(dq, \(dquser\-context\(dq: { \(dqlimits\(dq: { \(dq\(dq: \(dq\(dq } } } ] } ] } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کتابخانه قلاب Limits از نام کلاس برای شناسایی کلاس کلاینت و از شناسه زیرشبکه (subnet ID) برای شناسایی یک زیرشبکه استفاده می‌کند. تغییر عبارت آزمون (test expression) در یک کلاس کلاینت یا محدوده شبکه یک زیرشبکه در حالی که نام یا شناسه بدون تغییر باقی بماند، شمارنده اجاره را برای کلاس کلاینت یا زیرشبکه مربوطه بازنشانی نمی‌کند. برای بازنشانی شمارنده اجاره، نام کلاس کلاینت یا شناسه زیرشبکه را تغییر دهید. .UNINDENT .UNINDENT.SS محدودسازی اجاره (Lease Limiting) .sp این امکان وجود دارد که تعداد اجاره‌هایی که یک گروه از کلاینت‌ها می‌توانند از یک سرور Kea DHCP یا از مجموعه‌ای از سرورهای همکار Kea DHCP دریافت کنند، محدود شود. .sp مقدار محدودیت اجاره می‌تواند به صورت یک عدد صحیح ۳۲ بیتی بدون علامت، یعنی بین \fB0\fP و \fB4,294,967,295\fP مشخص شود. هر نوع اجاره را می‌توان به صورت جداگانه محدود کرد. اجاره‌های IPv4 و اجاره‌های IA_NA در IPv6 از طریق مدخل پیکربندی \fB\(dqaddress\-limit\(dq\fP محدود می‌شوند. اجاره‌های IA_PD در IPv6 از طریق مدخل پیکربندی \fB\(dqprefix\-limit\(dq\fP محدود می‌شوند. در اینجا چند مثال آورده شده است: .INDENT 0.0 .IP \(bu 2 \fB\(dqaddress\-limit\(dq: 4\fP .IP \(bu 2 \fB\(dqprefix\-limit\(dq: 2\fP .UNINDENT .sp برای محدودسازی اجاره، کلاس‌های کلاینت و تعداد اجاره‌های مرتبط با آن‌ها \- که در برابر محدودیت‌های پیکربندی‌شده سنجیده می‌شوند \- برای هر اجاره در فراخوان‌های قلاب (hook callouts) زیر به‌روزرسانی می‌شوند: .INDENT 0.0 .IP \(bu 2 \fBlease4_select\fP .IP \(bu 2 \fBlease4_renew\fP .IP \(bu 2 \fBlease6_select\fP .IP \(bu 2 \fBlease6_renew\fP .IP \(bu 2 \fBlease6_rebind\fP .UNINDENT .sp در نتیجه، کلاس‌هایی که مقدار \fB\(dqonly\-in\-additional\-list\(dq\fP برای آن‌ها \(dqtrue\(dq است، نمی‌توانند تحت محدودیت اجاره قرار گیرند. لطفاً برای اطلاعات بیشتر درباره اینکه کدام کلاس‌های کلاینت می‌توانند برای محدود کردن تعداد اجاره‌ها استفاده شوند، به مراحل دسته‌بندی \%<#\:classify-classification-steps> مراجعه کنید. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تحت بار کاری بالا، ممکن است یک سرور Kea DHCP اجاره‌های بیشتری نسبت به آنچه محدودیت دقیقاً اجازه می‌دهد تخصیص دهد. این موضوع فقط در زمان جهش‌های ترافیکی شدید رخ می‌دهد که از کلاینت‌های متعلق به همان کلاس یا همان زیرشبکه (بسته به آنچه محدود شده است) ناشی می‌شوند. کاربران ممکن است علاقه‌مند به دنبال کردن روند توسعه محدودیت‌های اجاره اتمیک \% در گیت‌لب ISC باشند. .UNINDENT .UNINDENT .SS محدودسازی نرخ (Rate Limiting) .sp امکان محدود کردن بسامد یا نرخی که بسته‌های ورودی بر اساس آن پاسخ دریافت می‌کنند وجود دارد. .sp مقدار محدودیت نرخ می‌تواند با قالب \fB\(dq

packets per \(dq\fP مشخص شود. \fB

\fP هر عددی است که بتوان آن را به صورت یک عدد صحیح ۳۲ بیتی بدون علامت نمایش داد، یعنی بین \fB0\fP و \fB4,294,967,295\fP\&. \fB\fP می‌تواند هر یک از مقادیر \fBsecond\fP، \fBminute\fP، \fBhour\fP، \fBday\fP، \fBweek\fP، \fBmonth\fP، یا \fByear\fP باشد. برای سادگی، یک \fBmonth\fP معادل ۳۰ روز در نظر گرفته می‌شود؛ به طور مشابه، یک \fByear\fP برای اهداف محدودسازی ۳۶۵ روز در نظر گرفته می‌شود. این ساختار نحوی طیف گسترده‌ای از نرخ‌ها را از یک اجاره در سال تا چهار میلیارد اجاره در ثانیه پوشش می‌دهد. این مقدار به مدخل پیکربندی \fB\(dqrate\-limit\(dq\fP اختصاص داده می‌شود. در اینجا چند مثال آورده شده است: .INDENT 0.0 .IP \(bu 2 \fB\(dqrate\-limit\(dq: 1 packet per second\fP .IP \(bu 2 \fB\(dqrate\-limit\(dq: 4 packets per minute\fP .IP \(bu 2 \fB\(dqrate\-limit\(dq: 16 packets per hour\fP .UNINDENT .sp مقدار پیکربندی‌شده \fB0\fP بسته، روشی مناسب برای غیرفعال‌سازی کامل پردازش بسته برای برخی از کلاینت‌های خاص است. به این ترتیب، این مقدار بیانگر معنای تحت‌اللفظی خود است و برخلاف آنچه ممکن است تصور شود، یک مقدار ویژه برای غیرفعال کردن کلی محدودسازی نیست. غیرفعال کردن کامل محدودسازی با حذف مدخل پیکربندی برگ (leaf) \fB\(dqrate\-limit\(dq\fP، نگاشت یا زمینه کاربری (user context) \fB\(dqlimits\(dq\fP پیرامون آن، یا پیکربندی کتابخانه قلاب حاصل می‌شود. همین امر برای مقدار \fB0\fP در محدودسازی اجاره نیز صدق می‌کند. با این حال، دستیابی به آن مورد کاربرد با محدودسازی نرخ بهتر انجام می‌شود؛ زیرا بار محاسباتی کمتری به Kea وارد می‌کند، چرا که تصمیم برای نادیده‌گرفتن (drop) درخواست یا ارسال NAK در مراحل اولیه گرفته می‌شود. .sp از نظر محدودسازی نرخ، کلاس‌های کلاینت به ترتیب در فراخوان‌های \fBpkt4_receive\fP و \fBpkt6_receive\fP ارزیابی می‌شوند تا محدودیت‌های نرخ در زودترین زمان ممکن در چرخه پردازش بسته بررسی شوند. بدین ترتیب، تنها کلاس‌هایی که صرفاً از طریق یک عبارت آزمون مستقل به بسته اختصاص یافته‌اند، قابل استفاده هستند. کلاس‌هایی که به رزروهای میزبان (host reservations) یا کلاس‌های ویژه \fBBOOTP\fP یا \fBKNOWN\fP وابسته‌اند، و همچنین کلاس‌هایی که با \fB\(dqonly\-in\-additional\-list\(dq: true\fP مشخص شده‌اند، نمی‌توانند مشمول محدودسازی نرخ شوند. برای جزئیات بیشتر درباره اینکه کدام کلاس‌های کلاینت می‌توانند برای محدود کردن نرخ بسته به کار روند، به مراحل دسته‌بندی \%<#\:classify-classification-steps> مراجعه کنید. .sp محدودیت‌های نرخ مبتنی بر زیرشبکه فقط بر روی زیرشبکه اولیه‌ای که برای یک بسته مشخص انتخاب شده اعمال می‌شوند. اگر زیرشبکه انتخاب‌شده متعاقباً تغییر کند (همان‌طور که ممکن است برای زیرشبکه‌های یک شبکه اشتراکی یا هنگام فعال بودن انتخاب مجدد در کتابخانه‌هایی مانند قلاب RADIUS رخ دهد)، محدودیت‌های نرخ در زیرشبکه جدیدِ انتخاب‌شده نادیده گرفته می‌شوند. به بیان دیگر، بسته‌ها فقط با محدودیت نرخ زیرشبکه اصلی کنترل می‌شوند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 شاید منطقی به نظر برسد که تعیین محدودیت نرخ \fBn\fP بسته در هر واحد زمانی منجر به \fBn\fP تبادل DORA یا \fBn\fP تبادل SARR می‌شود. با این حال، به طور پیش‌فرض، تمام بسته‌های ورودی شمرده می‌شوند \- یعنی یک تبادل پیام کامل معادل دو بسته به حساب می‌آید. برای رسیدن به این نتیجه که یک تبادل پیام فقط یک بار شمرده شود، از محدودسازی نرخ کلاس کلاینت همراه با یک عبارت آزمون استفاده کنید که \fBpkt4.msgtype\fP را به پیام‌های DHCPDISCOVER یا \fBpkt6.msgtype\fP را به پیام‌های SOLICIT مقید کند. .UNINDENT .UNINDENT .SS \fBlibdhcp_mysql.so\fP: پس‌زمینه پایگاه داده برای MySQL (Database Backend for MySQL) .INDENT 0.0 .TP .B این کتابخانه قلاب، ذخیره‌سازی در پایگاه داده MySQL را برای موارد زیر پیاده‌سازی می‌کند: .INDENT 7.0 .IP \(bu 2 پس‌زمینه اجاره (Lease Backend) .IP \(bu 2 پس‌زمینه میزبان (Host Backend) .IP \(bu 2 پس‌زمینه پیکربندی (Configuration Backend) .UNINDENT .UNINDENT .SS پس‌زمینه پیکربندی MySQL (MySQL Configuration Backend) .sp این کتابخانه قلاب همراه با \fBlibdhcp_cb_cmds.so\fP کار می‌کند تا API لازم برای ایجاد، خواندن، به‌روزرسانی و حذف (CRUD) پیکربندی در یک پایگاه داده MySQL را پیاده‌سازی کند. لطفاً برای جزئیات بیشتر به libdhcp_cb_cmds.so: Configuration Backend Commands مراجعه کنید. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_mysql.so\fP بخشی از کد منبع‌باز است و برای همه کاربران Kea در دسترس است. با این حال، این کتابخانه قلاب فقط با \fBlibdhcp_cb_cmds.so\fP کار می‌کند که مدیریت آسان پیکربندی را با استفاده از دستورات API فراهم می‌سازد. \fBlibdhcp_cb_cmds.so\fP تنها در دسترس مشتریان ISC با قرارداد پشتیبانی پولی است؛ برای اطلاعات بیشتر درباره گزینه‌های اشتراک، لطفاً فرم موجود در \%\& را تکمیل کنید. .UNINDENT .UNINDENT.SS \fBlibdhcp_perfmon.so\fP: پایش کارایی (Performance Monitoring) .sp کتابخانه قلاب پایش کارایی (perfmon) به کارسازهای Kea DHCPv4 و DHCPv6 قابلیت رهگیری و گزارش داده‌های مرتبط با کارایی را می‌دهد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_perfmon.so\fP بخشی از کد متن‌باز است و برای هر کاربر Kea در دسترس می‌باشد. .UNINDENT .UNINDENT .SS نمای کلی (Overview) .sp کتابخانه perfmon که در Kea 2.5.6 افزوده شده است، می‌تواند توسط دیمن‌های \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> با افزودن آن به عنصر \fBhooks\-libraries\fP در پیکربندی کارساز بارگذاری شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_perfmon.so\(dq, \(dqparameters\(dq: { ... } }, ... ], ... } .EE .UNINDENT .UNINDENT .sp این کتابخانه چرخه حیات بسته‌های پرس‌وجوی کلاینت را هنگام پردازش توسط Kea، از زمان دریافت پرس‌وجو توسط هسته تا آماده شدن پاسخ برای ارسال رهگیری می‌کند. این رهگیری توسط یک پشته رویداد بسته هدایت می‌شود که شامل فهرستی از جفت‌های رویداد/برچسب زمانی برای نقاط عطف مهم در طول پردازش پرس‌وجوی کلاینت است. فهرست رویدادهای ممکن در زیر آورده شده است: .INDENT 0.0 .IP 1. 3 socket_received \- هسته پرس‌وجوی کلاینت را در بافر سوکت قرار داد .IP 2. 3 buffer_read \- کارساز پرس‌وجوی کلاینت را از بافر سوکت خواند .IP 3. 3 mt_queued \- کارساز پرس‌وجوی کلاینت را در صف کار استخر ریسه خود قرار داد (فقط در حالت چندریسمانی) .IP 4. 3 process_started \- کارساز پردازش پرس‌وجو را آغاز کرده است .IP 5. 3 process_completed \- کارساز پاسخ را ساخته و آماده ارسال آن است .UNINDENT .sp این فهرست احتمالاً در طول زمان گسترش خواهد یافت؛ همچنین برای توسعه‌دهندگان قلاب‌ها این امکان فراهم خواهد بود که رویدادهای اختصاصی خود را اضافه کنند. این موضوع در نسخه‌های بعدی با جزئیات تشریح خواهد شد. .SS ثبت غیرفعال رویدادها (Passive Event Logging) .sp هنگامی که کتابخانه قلاب perfmon بارگذاری می‌شود، محتویات پشته رویداد بسته را برای هر پرس‌وجوی کلاینت که یک بسته پاسخ تولید می‌کند در گزارش ثبت می‌کند. مدخل گزارش شامل شناسه‌های پرس‌وجوی کلاینت است و به دنبال آن فهرستی از جفت‌های رویداد/برچسب زمانی به همان ترتیبی که رخ داده‌اند می‌آید. .sp برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>، گزارش با برچسب \fBPERFMON_DHCP4_PKT_EVENTS\fP مشخص شده و در سطح اشکال‌زدایی (debug) ۵۰ یا بالاتر لاگر منتشر می‌شود. برای یک DHCPDISCOVER، این گزارش پس از آماده شدن DHCPOFFER برای ارسال منتشر می‌شود و مشابه تصویر زیر خواهد بود (به مدخل دوم نگاه کنید): .INDENT 0.0 .INDENT 3.5 .sp .EX 2024\-03\-20 10:52:20.069 INFO [kea\-dhcp4.leases/50033.140261252249344] DHCP4_LEASE_OFFER [hwtype=1 08:00:27:25:d3:f4], cid=[no info], tid=0xc288f9: lease 178.16.2.0 will be offered 2024\-03\-20 10:52:20.070 DEBUG [kea\-dhcp4.perfmon\-hooks/50033.140261252249344] PERFMON_DHCP4_PKT_EVENTS query: [hwtype=1 08:00:27:25:d3:f4], cid=[no info], tid=0xc288f9 events=[2024\-Mar\-20 14:52:20.067563 : socket_received, 2024\-Mar\-20 14:52:20.067810 : buffer_read, 2024\-Mar\-20 14:52:20.067897 : mt_queued, 2024\-Mar\-20 14:52:20.067952 : process_started, 2024\-Mar\-20 14:52:20.069614 : process_completed] .EE .UNINDENT .UNINDENT .sp برای \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>، گزارش با برچسب \fBPERFMON_DHCP6_PKT_EVENTS\fP مشخص شده و در سطح اشکال‌زدایی (debug) ۵۰ یا بالاتر لاگر منتشر می‌شود. برای یک DHCPV6_SOLICIT، این گزارش پس از آماده شدن DHCPV6_ADVERTISE برای ارسال منتشر می‌شود و مشابه تصویر زیر خواهد بود (به مدخل دوم نگاه کنید): .INDENT 0.0 .INDENT 3.5 .sp .EX 2024\-03\-20 10:22:14.030 INFO [kea\-dhcp6.leases/47195.139913679886272] DHCP6_LEASE_ADVERT duid=[00:03:00:01:08:00:27:25:d3:f4], [no hwaddr info], tid=0xb54806: lease for address 3002:: and iaid=11189196 will be advertised 2024\-03\-20 10:22:14.031 DEBUG [kea\-dhcp6.perfmon\-hooks/47195.139913679886272] PERFMON_DHCP6_PKT_EVENTS query: duid=[00:03:00:01:08:00:27:25:d3:f4], [no hwaddr info], tid=0xb54806 events=[2024\-Mar\-20 14:22:14.028729 : socket_received, 2024\-Mar\-20 14:22:14.028924 : buffer_read, 2024\-Mar\-20 14:22:14.029005 : process_started, 2024\-Mar\-20 14:22:14.030566 : process_completed] .EE .UNINDENT .UNINDENT .SS پایش مدت‌زمان (Duration Monitoring) .sp هنگامی که پایش فعال باشد، داده‌های رویداد پشته در یک بازه زمانی مشخص تجمیع می‌شوند. این تجمیع‌ها با عنوان \(dqمدت‌زمان‌های پایش‌شده\(dq یا برای راحتی به سادگی \(dqمدت‌زمان‌ها\(dq شناخته می‌شوند. مدت‌زمان‌ها به طور یکتا با یک \(dqکلید مدت‌زمان\(dq مشخص می‌شوند که شامل مقادیر زیر است: .INDENT 0.0 .IP \(bu 2 query message type \- نوع پیام پرس‌وجوی کلاینت (مانند DHCPDISCOVER، DHCPV6_REQUEST) .IP \(bu 2 response message type \- نوع پیام پاسخ کارساز (مانند DHCPOFFER، DHCPV6_REPLY) .IP \(bu 2 start event label \- رویدادی که آغاز فعالیت را مشخص می‌کند (مانند socket_received، process_started) .IP \(bu 2 stop event label \- رویدادی که پایان فعالیت را مشخص می‌کند (مانند buffer_read، process_completed) .IP \(bu 2 subnet id \- زیرشبکه انتخاب‌شده در حین پردازش پیام (یا 0 برای مدت‌زمان‌های سراسری) .UNINDENT .sp به محض اینکه کارساز ساخت پاسخ برای یک پرس‌وجو را تمام کند، پشته رویداد آن پرس‌وجو به مجموعه‌ای از به‌روزرسانی‌ها برای مدت‌زمان‌های پایش‌شده پردازش می‌شود. اگر پس از به‌روزرسانی مشخص شود که بازه نمونه‌برداری یک مدت‌زمان کامل شده است، برای گزارش‌دهی ارسال می‌شود و یک بازه نمونه‌برداری جدید آغاز می‌گردد. طول بازه توسط پارامتر پیکربندی \fBinterval\-width\-secs\fP تعیین می‌شود. .sp پشته رویداد برای چرخه DHCPDISCOVER/DHCPOFFER در حالت چندریسمانی که در بالا نمایش داده شد شامل رویدادهای زیر است: .INDENT 0.0 .INDENT 3.5 .TS box center; l|l. T{ برچسب زمانی رویداد T} T{ برچسب رویداد T} _ T{ 2024\-Mar\-20 14:52:20.067563 T} T{ socket_received T} _ T{ 2024\-Mar\-20 14:52:20.067810 T} T{ buffer_read T} _ T{ 2024\-Mar\-20 14:52:20.067897 T} T{ mt_queued T} _ T{ 2024\-Mar\-20 14:52:20.067952 T} T{ process_started T} _ T{ 2024\-Mar\-20 14:52:20.069614 T} T{ process_completed T} .TE .UNINDENT .UNINDENT .sp با فرض اینکه شناسه زیرشبکه (subnet ID) انتخاب‌شده 100 بوده باشد، به‌روزرسانی‌های مدت‌زمان ایجادشده توسط perfmon بر اساس این رویدادها در زیر نمایش داده شده است: .INDENT 0.0 .INDENT 3.5 .TS box center; l|l. T{ کلیدهای مدت‌زمان برای شناسه زیرشبکه 100 T} T{ به‌روزرسانی به میکروثانیه T} _ T{ DHCPDISCOVER.DHCPOFFER.socket_received\-buffer_read.100 T} T{ 247 T} _ T{ DHCPDISCOVER.DHCPOFFER.buffer_read\-mt_queue.100 T} T{ 87 T} _ T{ DHCPDISCOVER.DHCPOFFER.mt_queued\-process_started.100 T} T{ 55 T} _ T{ DHCPDISCOVER.DHCPOFFER.process_started\-process_completed.100 T} T{ 1662 T} _ T{ DHCPDISCOVER.DHCPOFFER.composite\-total_response.100 T} T{ 2051 T} .TE .UNINDENT .UNINDENT .sp توجه داشته باشید که علاوه بر به‌روزرسانی‌های رویدادهای مجاور، یک به‌روزرسانی مدت‌زمان اضافی برای مدت‌زمان کل تمام پشته وجود دارد که کلید آن شامل جفت‌رویداد \fBcomposite\-total_response\fP است. این مقدار، کل زمان لازم برای پاسخگویی را از هنگام دریافت پرس‌وجو تا زمان آماده شدن پاسخ برای ارسال رهگیری می‌کند. در نهایت، به‌روزرسانی‌های مدت‌زمان سراسری نیز برای هر یک از موارد فوق وجود دارد: .INDENT 0.0 .INDENT 3.5 .TS box center; l|l. T{ کلیدهای مدت‌زمان سراسری T} T{ به‌روزرسانی به میکروثانیه T} _ T{ DHCPDISCOVER.DHCPOFFER.socket_received\-buffer_read.0 T} T{ 247 T} _ T{ DHCPDISCOVER.DHCPOFFER.buffer_read\-mt_queue.0 T} T{ 87 T} _ T{ DHCPDISCOVER.DHCPOFFER.mt_queued\-process_started.0 T} T{ 55 T} _ T{ DHCPDISCOVER.DHCPOFFER.process_started\-process_completed.0 T} T{ 1662 T} _ T{ DHCPDISCOVER.DHCPOFFER.composite\-total_response.0 T} T{ 2051 T} .TE .UNINDENT .UNINDENT.SS گزارش‌دهی آمارها (Statistics Reporting) .sp هنگامی که فعال باشد، perfmon در هر بار تکمیل یک بازه نمونه‌برداری توسط یک مدت‌زمان (duration)، داده‌های آن را گزارش می‌دهد (به \fBstats\-mgr\-reporting\fP در بخش پیکربندی مراجعه کنید). هر آمار از قرارداد نام‌گذاری زیر پیروی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX {subnet\-id[x]}.perfmon.\-.\-. .EE .UNINDENT .UNINDENT .sp برای هر مورد، هم یک مقدار سراسری و هم یک مقدار ویژهٔ زیرشبکه وجود دارد. در حال حاضر، تنها مقداری که برای یک کلید مدت‌زمان مشخص گزارش می‌شود \fBmean\-usecs\fP است؛ این آمار میانگین زمان بین جفت‌رویدادِ آن مدت‌زمان در طول آخرین بازهٔ تکمیل‌شده است. به عبارت دیگر، اگر در طول یک بازهٔ مشخص هفت رخداد (یعنی به‌روزرسانی) با مجموع 3500us رخ داده باشد، مقدار \fBmean\-usecs\fP گزارش‌شده 500us خواهد بود. با ادامهٔ مثال بالا، آمارهای گزارش‌شده برای مقادیر در سطح زیرشبکه به صورت زیر نام‌گذاری می‌شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX subnet[100].perfmon.DHCPDISCOVER.DHCPOFFER.socket_received\-buffer_read.mean\-usecs subnet[100].perfmon.DHCPDISCOVER.DHCPOFFER.buffer_read\-mt_queue.mean\-usecs subnet[100].perfmon.DHCPDISCOVER.DHCPOFFER.mt_queued\-process_started.mean\-usecs subnet[100].perfmon.DHCPDISCOVER.DHCPOFFER.process_started\-process_completed.mean\-usecs subnet[100].perfmon.DHCPDISCOVER.DHCPOFFER.composite\-total_response.mean\-usecs .EE .UNINDENT .UNINDENT .sp و برای مقادیر سراسری به این صورت نمایش داده می‌شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX perfmon.DHCPDISCOVER.DHCPOFFER.socket_received\-buffer_read.mean\-usecs perfmon.DHCPDISCOVER.DHCPOFFER.buffer_read\-mt_queue.mean\-usecs perfmon.DHCPDISCOVER.DHCPOFFER.mt_queued\-process_started.mean\-usecs perfmon.DHCPDISCOVER.DHCPOFFER.process_started\-process_completed.mean\-usecs perfmon.DHCPDISCOVER.DHCPOFFER.composite\-total_response.mean\-usecs .EE .UNINDENT .UNINDENT .sp نتایج به StatsMgr گزارش می‌شوند؛ مؤلفه‌ای داخلی در Kea که داده‌ها را به عنوان آمارهایی گزارش می‌کند که می‌توان با دستورهای آماری آن‌ها را دریافت کرد. این داده‌ها با استفاده از دستورهای \fBstatistic\-get\-all\fP \%<#\:std-isccmd-statistic-get-all>، \fBstatistic\-global\-get\-all\fP \%<#\:std-isccmd-statistic-global-get-all>، یا \fBstatistic\-get\fP \%<#\:std-isccmd-statistic-get>\& قابل واکشی هستند. .SS هشدارها (Alarms) .sp می‌توان هشدارها را برای نظارت بر مدت‌زمان‌های خاصی تعریف کرد. هر هشدار یک حد بالا، \fBhigh\-water\-ms\fP، و یک حد پایین، \fBlow\-water\-ms\fP تعریف می‌کند. اگر میانگین مقدار گزارش‌شده برای مدت‌زمان از حد بالا فراتر رود، یک لاگ هشدار در سطح WARN صادر می‌شود، که در این مرحله هشدار «فعال‌شده» (\(dqtriggered\(dq) در نظر گرفته می‌شود. پس از فعال شدن، تا زمانی که میانگین گزارش‌شده برای مدت‌زمان بالاتر از حد پایین باقی بماند، لاگ سطح WARN در بازه گزارش هشدار که توسط \fBalarm\-report\-secs\fP مشخص شده تکرار می‌شود. هنگامی که میانگین به زیر حد پایین افت کند، هشدار پاک شده و یک لاگ در سطح INFO صادر می‌شود. .sp لاگ سطح WARN ناشی از فعال شدن هشدار شبیه به نمونه زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX 2024\-03\-20 10:22:14.030 WARN [kea\-dhcp6.leases/47195.139913679886272] PERFMON_ALARM_TRIGGERED Alarm for DHCPDISCOVER.DHCPOFFER.composite\-total_response.0 has been triggered since 2024\-03\-20 10:18:20.070000, reported mean duration 00:00:00.700000 exceeds high\-water\-ms: 500 .EE .UNINDENT .UNINDENT .sp لاگ سطح INFO ناشی از پاک شدن هشدار به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX 2024\-03\-20 10:30:14.030 INFO [kea\-dhcp6.leases/47195.139913679886272] PERFMON_ALARM_CLEARED Alarm for DHCPDISCOVER.DHCPOFFER.composite\-total_response.0 has been cleared, reported mean duration 00:00:00.010000 is now below low\-water\-ms: 25 .EE .UNINDENT .UNINDENT .SS دستورهای API (API Commands) .SS دستور \fBperfmon\-control\fP .sp از این دستور می‌توان برای فعال یا غیرفعال کردن پایش فعال و گزارش‌دهی آمارها در زمان اجرا، بدون تغییر یا بارگذاری مجدد پیکربندی، استفاده کرد. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqperfmon\-control\(dq, \(dqarguments\(dq: { \(dqenable\-monitoring\(dq: true, \(dqstats\-mgr\-reporting\(dq: false } } .EE .UNINDENT .UNINDENT .sp صرف‌نظر از آرگومان‌های ارائه‌شده (در صورت وجود)، مقادیر حاصل از هر دو پرچم همواره بازگردانده می‌شوند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqperfmon\-control success\(dq, \(dqarguments\(dq: { \(dqenable\-monitoring\(dq: true, \(dqstats\-mgr\-reporting\(dq: false } } .EE .UNINDENT .UNINDENT .SS دستور \fBperfmon\-get\-all\-durations\fP .sp این دستور تمام داده‌های مدت‌زمان پایش‌شده را که در حال حاضر توسط کتابخانه قلاب (hook library) Perfmon در حافظه نگه‌داری می‌شوند، واکشی می‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqperfmon\-get\-all\-durations\(dq, \(dqarguments\(dq: { \(dqresult\-set\-format\(dq: true } } .EE .UNINDENT .UNINDENT .sp در صورت موفقیت دستور، نتیجه 0 همراه با داده‌های مدت‌زمان پایش‌شده بازگردانده می‌شود، در حالی که در صورت نامعتبر بودن دستور یا بروز خطا در پردازش دستور، نتیجه 1 بازگردانده می‌شود. .sp قالب داده‌های مدت‌زمان پایش‌شده بازگردانده‌شده، توسط آرگومان اختیاری \fBresult\-set\-format\fP تعیین می‌شود. هنگامی که false باشد (پیش‌فرض)، فهرست مدت‌زمان‌ها به صورت فهرستی از عناصر تکی مطابق شکل زیر بازگردانده خواهد شد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqdurations\(dq: [{ \(dqduration\-key\(dq: { \(dqquery\-type\(dq: \(dqDHCPDISCOVER\(dq, \(dqresponse\-type\(dq: \(dqDHCPOFFER\(dq, \(dqstart\-event\(dq: \(dqbuffer_read\(dq, \(dqstop\-event\(dq: \(dqmt_queued\(dq, \(dqsubnet\-id\(dq: 0 }, \(dqmax\-duration\-usecs\(dq: 118, \(dqmin\-duration\-usecs\(dq: 31, \(dqoccurrences\(dq: 501, \(dqstart\-time\(dq: \(dq2024\-06\-12 17:52:06.814884\(dq, \(dqtotal\-duration\-usecs\(dq: 23951, \(dqmean\-duration\-usecs\(dq: 47 }, ... ], \(dqresult\-set\-format\(dq: false, \(dqinterval\-width\-secs\(dq: 5, \(dqtimestamp\(dq: \(dq2024\-06\-12 17:52:22.397233\(dq }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dqperfmon\-get\-all\-durations: n found\(dq } .EE .UNINDENT .UNINDENT .sp هنگامی که \fBresult\-set\-format\fP برابر با true باشد، فهرست مدت‌زمان‌ها در قالبی مشابه با مجموعه نتایج (result set) پایگاه‌داده SQL به صورت زیر بازگردانده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqdurations\-result\-set\(dq: { \(dqcolumns\(dq: [ \(dqquery\-type\(dq, \(dqresponse\-type\(dq, \(dqstart\-event\(dq, \(dqend\-event\(dq, \(dqsubnet\-id\(dq, \(dqinterval\-start\(dq, \(dqoccurrence\(dq, \(dqmin\-duration\-usecs\(dq, \(dqmax\-duration\-usecs\(dq, \(dqtotal\-duration\-usecs\(dq, \(dqmean\-duration\-usecs\(dq ], \(dqrows\(dq: [ [ \(dqDHCPDISCOVER\(dq, \(dqDHCPOFFER\(dq, \(dqbuffer_read\(dq, \(dqmt_queued\(dq, 0, \(dq2024\-06\-12 17:52:06.814884\(dq, 501, 31, 118, 23951, 47 ], ... ] }, \(dqresult\-set\-format\(dq: true, \(dqinterval\-width\-secs\(dq: 5, \(dqtimestamp\(dq: \(dq2024\-06\-12 17:52:22.397233\(dq }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dqperfmon\-get\-all\-durations: n found\(dq } .EE .UNINDENT .UNINDENT .sp مقادیر داده برای هر مدت‌زمان از آخرین بازه داده‌های تکمیل‌شده آن مدت‌زمان خواهد بود. اگر یک مدت‌زمان فاقد چنین بازه‌ای باشد، مقدار \fBinterval\-start\fP برابر با \(dq\(dq گزارش شده و مقادیر باقی‌مانده صفر خواهند بود..SS "پیکربندی (Configuration)" .sp استفاده از کتابخانه قلاب پایش کارایی از طریق چندین پارامتر پیکربندی می‌شود: .INDENT 0.0 .IP \(bu 2 .INDENT 2.0 .TP .B enable\-monitoring این پارامتر تجمیع داده‌های رویداد را برای گزارش‌گیری، آمار و هشدارها فعال می‌کند. مقدار پیش‌فرض آن \fBfalse\fP\& است. .UNINDENT .IP \(bu 2 .INDENT 2.0 .TP .B interval\-width\-secs مدت‌زمانی را بر حسب ثانیه مشخص می‌کند که طی آن، مدت‌زمان انجام وظایف مجزا پیش از گزارش شدن در یک مجموعه تجمیع می‌شوند. مقدار پیش‌فرض ۶۰ ثانیه است. .UNINDENT .IP \(bu 2 .INDENT 2.0 .TP .B stats\-mgr\-reporting گزارش‌دهی مقادیر تجمیع‌شده به StatsMgr را فعال می‌کند. مقدار پیش‌فرض آن \fBtrue\fP\& است. .UNINDENT .IP \(bu 2 .INDENT 2.0 .TP .B alarm\-report\-secs مدت‌زمانی را بر حسب ثانیه میان دفعات ثبت لاگ برای یک هشدار پس از برانگیخته شدن آن مشخص می‌کند. مقدار پیش‌فرض ۳۰۰ ثانیه است. .UNINDENT .IP \(bu 2 .INDENT 2.0 .TP .B alarms فهرستی اختیاری از هشدارهایی است که مقادیر تجمیعی مدت‌زمان‌های خاصی را پایش می‌کنند. هر هشدار با این چهار پارامتر تعریف می‌شود: .UNINDENT .INDENT 2.0 .IP \(bu 2 .INDENT 2.0 .TP .B duration\-key مدت‌زمان پایش‌شده را برای موارد زیر مشخص می‌کند: .UNINDENT .INDENT 2.0 .IP \(bu 2 query\-type \- نوع پیام پرس‌وجوی کلاینت (مانند DHCPDISCOVER، DHCPV6_REQUEST) .IP \(bu 2 response\-type \- نوع پیام پاسخ سرور (مانند DHCPOFFER، DHCPV6_REPLY) .IP \(bu 2 start\-event \- رویدادی که آغاز وظیفه را مشخص می‌کند (مانند socket_received، process_started) .IP \(bu 2 stop\-event \- رویدادی که پایان وظیفه را مشخص می‌کند .IP \(bu 2 subnet\-id \- زیرشبکه انتخاب‌شده هنگام پردازش پیام (یا 0 برای مدت‌زمان‌های سراسری) .UNINDENT .IP \(bu 2 .INDENT 2.0 .TP .B enable\-alarm این هشدار را فعال یا غیرفعال می‌کند؛ مقدار پیش‌فرض \fBtrue\fP\& است. .UNINDENT .IP \(bu 2 .INDENT 2.0 .TP .B high\-water\-ms مقداری را بر حسب میلی‌ثانیه مشخص می‌کند که مدت‌زمان باید بیش از آن باشد تا این هشدار برانگیخته شود؛ باید بزرگ‌تر از صفر باشد. .UNINDENT .IP \(bu 2 .INDENT 2.0 .TP .B low\-water\-ms مقداری را بر حسب میلی‌ثانیه مشخص می‌کند که مدت‌زمان باید به کمتر از آن افت کند تا این هشدار پاک شود؛ باید بزرگ‌تر از صفر اما کمتر از \fBhigh\-water\-ms\fP\& باشد. .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 ثبت غیرفعال وقایع رویدادها همواره فعال است، حتی بدون مشخص کردن بخش \(dqparameters\(dq. .UNINDENT .UNINDENT .sp نمونه‌ای از پیکربندی در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_perfmon.so\(dq, \(dqparameters\(dq: { \(dqenable\-monitoring\(dq: true, \(dqinterval\-width\-secs\(dq: 5, \(dqstats\-mgr\-reporting\(dq: true, \(dqalarm\-report\-secs\(dq: 600, \(dqalarms\(dq: [ { \(dqduration\-key\(dq: { \(dqquery\-type\(dq: \(dqDHCPDISCOVER\(dq, \(dqresponse\-type\(dq: \(dqDHCPOFFER\(dq, \(dqstart\-event\(dq: \(dqprocess\-started\(dq, \(dqstop\-event\(dq: \(dqprocess\-completed\(dq, \(dqsubnet\-id\(dq: 0 }, \(dqenable\-alarm\(dq: true, \(dqhigh\-water\-ms\(dq: 500, \(dqlow\-water\-ms\(dq: 25 }] } }] } .EE .UNINDENT .UNINDENT .SS "\fBlibdhcp_ping_check.so\fP: بررسی پینگ (Ping Check)" .sp این کتابخانه قلاب قابلیت انجام «بررسی پینگ» (\(dqping check\(dq) روی یک آدرس IPv4 نامزد را پیش از پیشنهاد آن به یک کلاینت DHCP می‌افزاید. این ویژگی مشابه رفتاری است که در ISC DHCP وجود دارد و در RFC 2131 \%، بخش ۳.۱، بند ۲ پیشنهاد شده است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کتابخانه \fBlibdhcp_ping_check.so\fP بخشی از کد متن‌باز است و برای همه کاربران Kea در دسترس است. این قابلیت پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود. .UNINDENT .UNINDENT.SS "نمای کلی (Overview)" .sp کتابخانهٔ Ping Check، که در Kea 2.5.4 اضافه شده است، می‌تواند با افزوده شدن به عنصر \fBhooks\-libraries\fP در پیکربندی کارگزار، توسط دیمن \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> بارگذاری شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_ping_check.so\(dq, \(dqparameters\(dq: { ... } }, ... ], ... } .EE .UNINDENT .UNINDENT .sp هنگامی که این کتابخانه بارگذاری شود، در صورتی که همهٔ شرایط زیر برقرار باشند، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> پیش از پیشنهاد یک اجاره به کلاینت، یک بررسی پینگ (ping check) انجام می‌دهد: .INDENT 0.0 .IP 1. 3 کتابخانهٔ قلاب ping check بارگذاری شده باشد. .IP 2. 3 بررسی پینگ فعال باشد. .IP 3. 3 کارگزار در حال پاسخ‌گویی به یک DHCPDISCOVER باشد. .IP 4. 3 اجارهٔ کاندید نه فعال باشد و نه رزرو شده. .IP 5. 3 هر یک از موارد زیر درست باشد: .INDENT 3.0 .INDENT 3.5 a. این نخستین پیشنهاد این اجاره به این کلاینت باشد. این بررسی تنها در صورتی قابل انجام است که \fBoffer\-lifetime\fP بزرگ‌تر از صفر باشد (یعنی تخصیص موقت در DHCPDISCOVER فعال باشد). اگر \fBoffer\-lifetime\fP صفر باشد، بررسی‌های پینگ برای هر DHCPOFFER انجام می‌شوند، زیرا کارگزار راهی برای دانستن اینکه آیا پیش‌تر پیشنهادی ارائه شده است یا خیر ندارد. .INDENT 0.0 .IP b. 3 اجاره به کلاینتی غیر از مالک پیشین آن در حال پیشنهاد داده شدن باشد. .UNINDENT .sp c. اجاره به مالک پیشین آن پیشنهاد داده شود و بیش از تعداد ثانیه‌های مشخص‌شده توسط \fBping\-cltt\-secs\fP از CLTT اجارهٔ اولیه سپری شده باشد. .UNINDENT .UNINDENT .UNINDENT .sp هنگامی که کتابخانهٔ ping check بارگذاری شده باشد، کارگزار \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> با انجام مراحل زیر به یک DHCPDISCOVER پاسخ می‌دهد: .sp 1. انتخاب یک آدرس IPv4 کاندید از طریق روندهای معمول و استفاده از آن برای ساخت یک DHCPOFFER. .sp 2. پارک کردن DHCPOFFER و درخواست یک بررسی پینگ از کتابخانهٔ قلاب ping check از طریق فراخوان \fBlease4_offer\fP آن. برای آشنایی مقدماتی با پارک بسته‌ها، به Parked\-Packet Limit مراجعه کنید. .sp 3. آزمودن شرایط فراخوان که در بالا شرح داده شد: اگر برقرار نباشند، بدون انجام بررسی بازمی‌گردد و کارگزار DHCPOFFER را به کلاینت ارسال می‌کند. در غیر این صورت، فراخوان یک بررسی پینگ برای آدرس اجاره آغاز می‌کند. .sp 4. پس از پایان بررسی پینگ، در صورتی که نتیجهٔ بررسی حاکی از در دسترس بودن آدرس باشد، کارگزار DHCPOFFER را به کلاینت ارسال می‌کند؛ در غیر این صورت، DHCPFOFFER را دور انداخته و یک اجارهٔ DECLINED برای آن آدرس ایجاد می‌کند. .sp هر بررسی پینگ شامل مراحل زیر است: .sp 1. اگر تعداد ECHO REPLYهای ارسال‌شده کمتر از حداقل تعداد پیکربندی‌شده برای ارسال باشد، یک ICMP ECHO REQUEST به آدرس اجاره ارسال می‌شود. در غیر این صورت، نتیجه گرفته می‌شود که آدرس در دسترس است. .sp 2. اگر هیچ ECHO REPLYای در بازهٔ زمانی قابل‌پیکربندی دریافت نشود، بازگشت به مرحلهٔ 1. .INDENT 0.0 .IP 3. 3 به محض دریافت یک ICMP ECHO REPLY، نتیجه گرفته می‌شود که اجاره در دسترس نیست (NOT available). .IP 4. 3 اگر هر یک از موارد زیر رخ دهد: .INDENT 3.0 .INDENT 3.5 .INDENT 0.0 .IP a. 3 دریافت پیام ICMP DESTINATION UNREACHABLE .IP b. 3 شکست در ارسال ICMP ECHO REQUEST به دلیل خطای شبکه (مانند غیرقابل‌دسترس بودن شبکه) .IP c. 3 شکست در ارسال ICMP ECHO REQUEST به دلیل خطای دسترسی و مجوزها (مانند اینکه آدرس اجاره یک آدرس برودکست باشد) .IP d. 3 شکست در ارسال ICMP ECHO REQUEST با خطای پر بودن بافر سوکت (socket buffer full) .UNINDENT .sp از بررسی آدرس صرف‌نظر کرده و آن را در دسترس تلقی می‌کند. .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 خطاهای \(dqSocket buffer full\(dq نشان می‌دهند که محدودیت‌های نرخ (rate limits) سیستم‌عامل روی ICMP رد شده است. کارگزار آن‌ها را دوباره تلاش نمی‌کند، زیرا احتمالاً تنها وضعیت را وخیم‌تر خواهد کرد. اگر این اتفاق به طور مداوم رخ دهد، ممکن است بار کلاینت‌ها روی کارگزار برای انجام بررسی پینگ بیش از حد زیاد باشد. بررسی پینگ برای سیستم‌هایی با توان عملیاتی (throughput) بالا توصیه نمی‌شود. .UNINDENT .UNINDENT .SS "پیکربندی (Configuration)" .sp کتابخانهٔ قلاب ping check در حال حاضر از پارامترهای پیکربندی زیر پشتیبانی می‌کند که می‌توانند در سطوح سراسری (global) و زیرشبکه (subnet) تنظیم شوند؛ مقادیر سطح زیرشبکه بر مقادیر سراسری تقدم دارند: .INDENT 0.0 .IP \(bu 2 \fBenable\-ping\-check\fP \- این پارامتر بررسی پینگ را در یک حوزهٔ مشخص فعال یا غیرفعال می‌کند. .IP \(bu 2 \fBmin\-ping\-requests\fP \- حداقل تعداد ECHO REQUESTهای ارسال‌شده بدون دریافت پاسخ، پیش از اعلام در دسترس بودن یک آدرس. مقدار پیش‌فرض 1 است؛ این مقدار باید بزرگ‌تر از صفر باشد. .IP \(bu 2 \fBreply\-timeout\fP \- حداکثر مدت زمانی که برای دریافت پاسخ به یک ECHO REQUEST منفرد منتظر می‌ماند. این مقدار بر حسب میلی‌ثانیه مشخص شده و باید بزرگ‌تر از صفر باشد؛ مقدار پیش‌فرض 100 است. .IP \(bu 2 \fBping\-cltt\-secs\fP \- تعداد ثانیه‌هایی را مشخص می‌کند که در صورت تعلق کلاینت به عنوان مالک قبلی اجاره، باید پس از CLTT اجاره سپری شود تا بررسی پینگ انجام شود. مقدار پیش‌فرض 60 ثانیه است. .UNINDENT .sp پارامتر زیر تنها در سطح سراسری پشتیبانی می‌شود: .INDENT 0.0 .IP \(bu 2 \fBping\-channel\-threads\fP \- در حالت چندنخی (multi\-threaded)، این تعداد نخ‌ها در استخر نخ (thread pool) کانال است. مقدار پیش‌فرض 0 است که به کتابخانه دستور می‌دهد از همان تعداد نخ‌های هستهٔ Kea استفاده کند. اگر این مقدار در حالت تک‌نخی بودن Kea مشخص شود، نادیده گرفته خواهد شد. .UNINDENT .sp گزیدهٔ پیکربندی زیر یک پیکربندی در سطح سراسری را نمایش می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [{ \(dqlibrary\(dq: \(dqlibdhcp_ping_check.so\(dq, \(dqparameters\(dq: { \(dqenable\-ping\-check\(dq : true, \(dqmin\-ping\-requests\(dq : 1, \(dqreply\-timeout\(dq : 100, \(dqping\-cltt\-secs\(dq : 60, \(dqping\-channel\-threads\(dq : 0 } }] } .EE .UNINDENT .UNINDENT .sp گزیدهٔ زیر یک پیکربندی در سطح زیرشبکه را نشان می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqsubnet4\(dq: [{ \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqpools\(dq: [{ \(dqpool\(dq: \(dq192.0.2.10 \- 192.0.2.20\(dq }], \(dquser\-context\(dq: { \(dqping\-check\(dq: { \(dqenable\-ping\-check\(dq : true, \(dqmin\-ping\-requests\(dq : 2, \(dqreply\-timeout\(dq : 250, \(dqping\-cltt\-secs\(dq : 120 } } }] } .EE .UNINDENT .UNINDENT.SS \fBlibdhcp_pgsql.so\fP: بک‌اند پایگاه‌داده برای PostgreSQL .INDENT 0.0 .TP .B این کتابخانه هوک ذخیره‌سازی پایگاه‌داده PostgreSQL را برای موارد زیر پیاده‌سازی می‌کند: .INDENT 7.0 .IP \(bu 2 بک‌اند اجاره (Lease Backend) .IP \(bu 2 بک‌اند میزبان (Host Backend) .IP \(bu 2 بک‌اند پیکربندی (Configuration Backend) .UNINDENT .UNINDENT .SS بک‌اند پیکربندی PostgreSQL .sp این کتابخانه هوک در ارتباط با \fBlibdhcp_cb_cmds.so\fP کار می‌کند تا API لازم جهت ایجاد، خواندن، به‌روزرسانی و حذف (CRUD) پیکربندی را در یک پایگاه‌داده PostgreSQL پیاده‌سازی کند. لطفاً برای جزئیات بیشتر به libdhcp_cb_cmds.so: Configuration Backend Commands مراجعه کنید. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_pgsql.so\fP بخشی از کد متن‌باز است و برای تمام کاربران Kea در دسترس می‌باشد. با این حال، این کتابخانه هوک تنها با \fBlibdhcp_cb_cmds.so\fP کار می‌کند که مدیریت آسان پیکربندی را با استفاده از دستورات API ممکن می‌سازد. \fBlibdhcp_cb_cmds.so\fP تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس است؛ برای اطلاعات بیشتر درباره گزینه‌های اشتراک، لطفاً فرم موجود در \%\& را تکمیل نمایید. .UNINDENT .UNINDENT .SS \fBlibdhcp_radius.so\fP: پشتیبانی از سرور RADIUS .sp این کتابخانه هوک به سرورهای DHCP در Kea امکان می‌دهد تا از پروتکل RADIUS برای احراز صلاحیت کلاینت‌های DHCP از طریق سرویس دسترسی (access service)، یا برای ژورنال‌سازی اجاره‌های DHCP از طریق سرویس حسابرسی (accounting service) استفاده کنند. برای جزئیات مربوط به RADIUS در Kea، لطفاً RADIUS \%<#\:radius>\& را ببینید. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_radius.so\fP بخشی از کد متن‌باز است و برای تمامی کاربران Kea در دسترس می‌باشد. این مورد پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود. .UNINDENT .UNINDENT .SS \fBlibdhcp_rbac.so\fP: کنترل دسترسی مبتنی بر نقش (RBAC) .SS نمای کلی کنترل دسترسی مبتنی بر نقش (RBAC) .sp پیش از پردازش دستورات در درخواست‌های HTTP دریافتی، \fBlibdhcp_rbac.so\fP پارامترهای مشخصی را دریافت می‌کند، مانند بخش common\-name در نام موضوع (subject name) گواهی کلاینت، تا نقشی را به درخواست اختصاص دهد. پیکربندی مرتبط با این نقش برای پذیرش یا رد دستور استفاده می‌شود. پس از پردازش، پاسخ می‌تواند بازنویسی شود؛ مثلاً بخش‌هایی از آن حذف گردند. .INDENT 0.0 .TP .B خلاصه‌ای از مراحل پردازش یک درخواست: .INDENT 7.0 .IP \(bu 2 کتابخانه HTTP برخی از اطلاعات را برای استفاده‌های بعدی ثبت می‌کند، مانند آدرس دوردست (remote address). .IP \(bu 2 هنگامی که TLS الزامی باشد اما درخواست توسط TLS محافظت نشده باشد، درخواست با ارسال پاسخ \(dqunauthorized\(dq رد می‌شود. .IP \(bu 2 دستور از درخواست استخراج می‌شود. .IP \(bu 2 با استفاده از اطلاعات ثبت‌شده در درخواست، یک نقش اختصاص داده می‌شود. .IP \(bu 2 نقش برای پذیرش (عبور دادن) یا رد کردن (ارسال یک پاسخ forbidden به) دستور استفاده می‌شود. .UNINDENT .TP .B خلاصه‌ای از مراحل پردازش یک پاسخ: .INDENT 7.0 .IP \(bu 2 اطلاعات پیوست‌شده به درخواست، در طول پردازش درخواست (هنگامی که درخواست پذیرفته شد) بازیابی می‌شوند. .IP \(bu 2 فیلترهای درخواست بر روی پاسخ اعمال می‌شوند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_rbac.so\fP تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس است. برای اطلاعات بیشتر درباره گزینه‌های اشتراک، لطفاً فرم موجود در \%\& را تکمیل نمایید. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 2.7.2 در Kea، کنترل دسترسی مبتنی بر نقش (RBAC) دیگر محدود به Control Agent نیست: می‌تواند توسط هر سرور دیگری که از سوکت‌های کنترلی HTTP/HTTPS پشتیبانی می‌کند مانند سرورهای DHCPv4، DHCPv6 و DDNS استفاده شود. از نسخه 3.1.8 در Kea، مؤلفه منسوخ‌شده Control Agent حذف گردیده است. .UNINDENT .UNINDENT .SS پیکربندی کنترل دسترسی مبتنی بر نقش .SS تخصیص نقش .sp تخصیص نقش توسط روش role\-assignment پیکربندی‌شده مدیریت می‌شود. .SS روش‌های تخصیص نقش .TS box center; l|l. T{ نام T} T{ توضیحات T} _ T{ remote\-address T} T{ آدرس IP دوردست/کلاینت T} _ T{ cert\-subject T} T{ بخش common\-name از نام موضوع (subject name) گواهی کلاینت T} _ T{ cert\-issuer T} T{ بخش common\-name از نام صادرکننده (issuer name) گواهی کلاینت T} _ T{ basic\-authentication T} T{ شناسه کاربری در احراز هویت اولیه HTTP T} _ T{ custom\-value T} T{ یک نقش دیگر می‌تواند در هوک‌های خارجی طراحی شود T} .TE.SS "پیکربندی نقش (Role Configuration)" .SS "پارامترهای پیکربندی نقش (Role Configuration Parameters)" .TS box center; l|l. T{ نام T} T{ توضیحات T} _ T{ name T} T{ نام نقش (به‌استثنای نقش‌های پیش‌فرض و ناشناخته) T} _ T{ accept\-commands T} T{ فهرست دسترسی مجاز (accept) T} _ T{ reject\-commands T} T{ فهرست دسترسی ردشده (reject) T} _ T{ other\-commands T} T{ مشخص می‌کند برای دستوراتی که با فهرست‌های مجاز و ردشده مطابقت ندارند چه عملی انجام شود (پیش‌فرض: reject) T} _ T{ list\-match\-first T} T{ با تعیین فهرستی که باید ابتدا بررسی و اعمال شود، مشخص می‌کند برای دستوراتی که با هر دو فهرست مجاز و ردشده تطابق دارند چه اقدامی صورت گیرد (پیش‌فرض: accept) T} _ T{ response\-filters T} T{ فیلترهایی که باید روی پاسخ‌ها اعمال شوند T} .TE .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 تخصیص نقش ممکن است با \fBcert\-subject\fP شکست بخورد، هنگامی که گواهی کلاینت الزامی نبوده باشد، یا ممکن است فاقد نام عمومی موضوع (subject common name) بوده و در عوض دارای یک نام جایگزین موضوع DNS باشد. در این حالت، تخصیص نقش یک نقش خالی بازمی‌گرداند و از مدخل \fBdefault\-role\fP استفاده می‌شود. .sp تخصیص نقش می‌تواند مقداری غیرمنتظره بازگرداند، مثلاً در صورت وجود یک نام نقش ثبت‌نشده یا یک اشتباه تایپی. در این حالت، مدخل \fBunknown\-role\fP به کار گرفته می‌شود. .sp رفتار پیش‌فرض برای هر دوی \fBdefault\-role\fP و \fBunknown\-role\fP رد کردن (reject) تمام دستورات است. .UNINDENT .UNINDENT .SS "دستورات API (API Commands)" .sp تمام دستورات REST API در فایل‌هایی درون دایرکتوری سورس \fBsrc/share/api\fP، یا در نسخهٔ نصب‌شدهٔ Kea در \fB\&.../share/kea/api\fP شرح داده شده‌اند. \fBlibdhcp_rbac.so\fP این فایل‌ها را می‌خواند تا نام، حق دسترسی (یعنی \fBread\fP یا \fBwrite\fP)، و نام قلاب (hook) را دریافت کند. حق دسترسی را می‌توان در فایل تغییر داد اما تغییرات تنها پس از راه‌اندازی مجدد سرور یا کارگزار اعمال می‌شوند. حذف تعاریف دستور از \fB\&.../share/kea/api\fP پیامدهایی به همراه دارد: اگر فهرست کنترل دسترسی مبتنی بر \fBread\fP یا \fBwrite\fP باشد و فایل تعریف موجود نباشد، سرور یا کارگزار همواره چنین دستوری را رد می‌کند. اگر فهرست کنترل دسترسی از \fBcommands\fP برای تعیین نام یک دستور استفاده کند و فایل تعریف آن دستور خاص در \fB\&.../share/kea/api\fP مفقود باشد، سرور Kea هنگام راه‌اندازی و خروج یک خطا لاگ می‌کند. .SS "پارامترهای اضافی تعریف دستور (Extra Command-Definition Parameters)" .TS box center; l|l. T{ نام T} T{ توضیحات T} _ T{ name T} T{ (اجباری) نام دستور T} _ T{ access T} T{ (اجباری) حق دسترسی، یعنی \fBread\fP یا \fBwrite\fP T} _ T{ hook T} T{ (اختیاری) نام قلاب (برای دستورات سرورها یا کارگزارها خالی است یا وجود ندارد) T} .TE .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این فایل‌های شرح دستور از نظر امنیتی حساس هستند؛ به عنوان مثال با مجوزهای دسترسی بیش از حد آزادانه، یک مهاجم محلی ممکن است آن‌ها را تغییر داده و هدف RBAC را بی‌اثر سازد. .UNINDENT .UNINDENT .SS "فهرست‌های کنترل دسترسی (Access Control Lists)" .sp فهرست‌های کنترل دسترسی را می‌توان با استفاده از یک نام (رشته) یا یک نگاشت تک‌مدخلی مشخص کرد..SS فهرست دسترسی نام‌گذاری‌شده از پیش تعریف‌شده .TS box center; l|l. T{ نام T} T{ توضیحات T} _ T{ ALL T} T{ با همه‌چیز مطابقت دارد T} _ T{ NONE T} T{ با هیچ‌چیز مطابقت ندارد T} _ T{ READ T} T{ با دستورهای دارای حق دسترسی خواندن (read\-access) مطابقت دارد T} _ T{ WRITE T} T{ با دستورهای دارای حق دسترسی نوشتن (write\-access) مطابقت دارد T} .TE .sp مشخصات فهرست دسترسی نگاشتی، از یک نوع فهرست در نام تک‌ورودی و از پارامتر در مقدار آن استفاده می‌کنند. .SS انواع فهرست دسترسی .TS box center; l|l|l. T{ نام T} T{ توضیحات T} T{ پارامتر T} _ T{ not T} T{ نقیض منطقی T} T{ فهرست دسترسی T} _ T{ and T} T{ عطف منطقی T} T{ فهرستی از فهرست‌های دسترسی T} _ T{ or T} T{ فصل منطقی T} T{ فهرستی از فهرست‌های دسترسی T} _ T{ command T} T{ فهرست صریح T} T{ فهرستی از نام‌های دستور T} _ T{ access T} T{ بر اساس حق دسترسی T} T{ حق دسترسی (\fBread\fP یا \fBwrite\fP) T} _ T{ hook T} T{ بر اساس قلاب T} T{ نام قلاب (می‌تواند خالی باشد) T} .TE .SS فیلترهای پاسخ .SS فیلترهای پاسخ از پیش تعریف‌شده .TS box center; l|l. T{ نام T} T{ توضیحات T} _ T{ list\-commands T} T{ دستورهای غیرمجاز را از پاسخ list\-commands حذف می‌کند T} .TE .SS پارامترهای سراسری .sp پارامترهای سراسری عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBassign\-role\-method\fP: نام روشی که برای تخصیص نقش استفاده می‌شود. این پارامتر اجباری است. .IP \(bu 2 \fBapi\-files\fP: مسیر دایرکتوری‌ای که فایل‌های API توصیف‌کننده دستورها در آن یافت می‌شوند. این پارامتر اجباری است. .IP \(bu 2 \fBrequire\-tls\fP: تعیین اینکه آیا درخواست‌های دریافت‌شده از طریق HTTP (در مقایسه با HTTPS) رد شوند یا خیر. مقدار پیش‌فرض آن زمانی که روش تخصیص نقش مبتنی بر گواهی‌ها نباشد، \fBfalse\fP است. .IP \(bu 2 \fBcommands\fP: فهرست پیکربندی‌های دستورهای اضافی. .IP \(bu 2 \fBaccess\-control\-lists\fP: تعاریف فهرست‌های کنترل دسترسی نام‌گذاری‌شده (هر تعریف یک نگاشت تک‌مدخلی است؛ نام مدخل، نام فهرست دسترسی و مقدار آن، مشخصات مربوطه است). این نام در بخش‌های دیگر پیکربندی، مانند \(dqaccept\-commands\(dq استفاده می‌شود. .IP \(bu 2 \fBroles\fP: پیکربندی‌های نقش. .IP \(bu 2 \fBdefault\-role\fP: پیکربندی نقش پیش‌فرض (زمانی استفاده می‌شود که \(dq\(dq تخصیص یافته باشد). .IP \(bu 2 \fBunknown\-role\fP: پیکربندی نقش ناشناخته (زمانی استفاده می‌شود که نقش تخصیص‌یافتهٔ غیرخالی هیچ پیکربندی‌ای نداشته باشد). .UNINDENT.SS "پیکربندی‌های نمونه (Sample Configurations)" .sp پیکربندی‌های نمونه در kea4/hooks\-rbac.json \%<#\:config-example-kea4-hooks-rbac-json> و kea6/hooks\-rbac.json \%<#\:config-example-kea6-hooks-rbac-json>\& موجود هستند. .SS "الگوریتم پذیرش/رد (Accept/Reject Algorithm)" .sp این شبه‌کدِ الگوریتم تصمیم‌گیری پذیرش/رد است که مقدار \fBtrue\fP (پذیرش) یا \fBfalse\fP (رد) را برمی‌گرداند. .INDENT 0.0 .INDENT 3.5 .sp .EX bool match(command) { if (list\-match\-first == accept) { if (accept_list && accept_list\->match(command)) { return (true); } if (reject_list && reject_list\->match(command)) { return (false); } } else { if (reject_list && reject_list\->match(command)) { return (false); } if (accept_list && accept_list\->match(command)) { return (true); } } if (others == reject) { return (false); } else { return (true); } } .EE .UNINDENT .UNINDENT .SS "دستورات هوک سفارشی و بازتعریف دستور (Custom Hook Commands and Command Redefinition)" .sp امکان داشتن یک هوک سفارشی همراه با دستورات جدید وجود دارد. در این حالت، می‌توان از کنترل دسترسی بر پایه نقش (Role Based Access Control) به دو روش برای مدیریت دستور جدید استفاده کرد. .sp پارامتر سراسری \fBcommand\fP می‌تواند برای تعریف نام، نوع دسترسی و نام هوک آن به کار رود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommands\(dq: [ { \(dqname\(dq: \(dqmy\-new\-command\(dq, \(dqaccess\(dq: \(dqwrite\(dq, \(dqhook\(dq: \(dqmy\-custom\-hook\(dq } ], \&... } .EE .UNINDENT .UNINDENT .sp سپس دستور جدید می‌تواند در \fBroles\fP مشخص شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqroles\(dq: [ { \(dqname\(dq: \(dquser1\(dq, \(dqaccept\-commands\(dq: { \(dqcommands\(dq: [ \(dqmy\-new\-command\(dq ] }, \(dqreject\-commands\(dq: \(dqWRITE\(dq, \(dqlist\-match\-first\(dq: \(dqaccept\(dq }, { \(dqname\(dq: \(dquser2\(dq, \(dqaccept\-commands\(dq: { \(dqhook\(dq: \(dqmy\-custom\-hook\(dq }, \(dqreject\-commands\(dq: \(dqALL\(dq, \(dqlist\-match\-first\(dq: \(dqaccept\(dq } ], \&... } .EE .UNINDENT .UNINDENT .sp روش دوم، ایجاد یک فایل سفارشی در \fB\&.../share/kea/api\fP و تعریف نوع دسترسی دستور(های) سفارشی است. .sp همچنین امکان بازتعریف یک دستور موجود با حذف فایل تعریف آن از \fB\&.../share/kea/api\fP و تعریف آن در پارامتر سراسری \fBcommands\fP وجود دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommands\(dq: [ { \(dqname\(dq: \(dqdhcp\-disable\(dq, \(dqaccess\(dq: \(dqread\(dq, \(dqhook\(dq: \(dqmy\-custom\-hook\-3\(dq } ] } .EE .UNINDENT .UNINDENT .sp با این رویکرد، مدیر سیستم می‌تواند پیکربندی‌های تمام دستورهای موجود را در فایل پیکربندی سرور قرار دهد. .SS "مثال جامع (Extensive Example)" .sp در اینجا مثالی جامع برای نقشی آورده شده است که همهٔ دستورهای خواندن را، به استثنای \fBconfig\-get\fP \%<#\:std-isccmd-config-get> می‌پذیرد (برای نمونه، جهت پنهان‌سازی گذرواژه‌ها). برای هر کاربر راه‌دور که به عنوان \(dquser1\(dq شناخته نشده باشد، تمام دستورها باید رد شوند. .sp گزینهٔ نخست، قرار دادن دستورهای مجاز در فهرست \(dqaccept\-commands\(dq و رد کردن هر چیز دیگری است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqroles\(dq: [ { \(dqname\(dq: \(dquser1\(dq, \(dqaccept\-commands\(dq: { \(dqand\(dq: [ \(dqREAD\(dq, { \(dqnot\(dq: { \(dqcommands\(dq: [ \(dqconfig\-get\(dq ] } } ] }, \(dqreject\-commands\(dq: \(dqALL\(dq, // This is the default but as the config relies on it // it is explicitly set. \(dqlist\-match\-first\(dq: \(dqaccept\(dq }, \&... ], \&... } .EE .UNINDENT .UNINDENT .sp یک جایگزین رایج، تنظیم نکردن فهرست \(dqreject\-commands\(dq است، یعنی خالی گذاشتن آن و تکیه بر \(dqother\-commands\(dq برای رد کردن هر چیز دیگر. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqroles\(dq: [ { \(dqname\(dq: \(dquser2\(dq, \(dqaccept\-commands\(dq: { \(dqand\(dq: [ \(dqREAD\(dq, { \(dqnot\(dq: { \(dqcommands\(dq: [ \(dqconfig\-get\(dq ] } } ] }, // This is the default but as the config relies on it // it is explicitly set. \(dqother\-commands\(dq: \(dqreject\(dq }, \&... ], \&... } .EE .UNINDENT .UNINDENT .sp همچنین می‌توان عکس آن را انجام داد، یعنی تنها فهرست \(dqreject\-commands\(dq تنظیم شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqroles\(dq: [ { \(dqname\(dq: \(dquser3\(dq, \(dqreject\-commands\(dq: { \(dqor\(dq: [ \(dqWRITE\(dq, { \(dqcommands\(dq: [ \(dqconfig\-get\(dq ] } ] }, \(dqother\-commands\(dq: \(dqaccept\(dq }, \&... ], \&... } .EE .UNINDENT .UNINDENT .sp یا از هر دو فهرست استفاده شود به گونه‌ای که استثنا در فهرست \(dqreject\-commands\(dq قرار گیرد؛ این فهرست باید ابتدا بررسی شود زیرا \(dqconfig\-get\(dq دارای حق دسترسی خواندن (read\-access) است. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqroles\(dq: [ { \(dqname\(dq: \(dquser4\(dq, \(dqaccept\-commands\(dq: \(dqREAD\(dq, \(dqreject\-commands\(dq: { \(dqcommands\(dq: [ \(dqconfig\-get\(dq ] }, \(dqlist\-match\-first\(dq: \(dqreject\(dq }, \&... ], \&... } .EE .UNINDENT .UNINDENT .sp برای بررسی هر پیکربندی، ایدهٔ خوبی است که از فیلتر پاسخ \(dqlist\-commands\(dq استفاده شود که خطاهایی مانند دستورهای مفقود (رد شده) و دستورهای اضافی (پذیرفته شده) را نشان می‌دهد. .sp می‌توان از \fBaccess\-control\-lists\fP برای تعریف فهرست‌های کنترل دسترسی و سپس استفادهٔ مجدد در \fBroles\fP بهره برد: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqaccess\-control\-lists\(dq:[ { \(dqmy\-list\-one\(dq:{ \(dqor\(dq:[ { \(dqhook\(dq: \(dqsubnet_cmds\(dq }, { \(dqcommands\(dq:[ \(dqlist\-commands\(dq ] } ] } }, { \(dqmy\-list\-two\(dq:{ \(dqand\(dq:[ \(dqREAD\(dq, { \(dqnot\(dq:{ \(dqcommands\(dq:[ \(dqconfig\-get\(dq ] } } ] } }, { \(dqmy\-list\-three\(dq:{ \(dqor\(dq:[ { \(dqhook\(dq:\(dqsubnet_cmds\(dq }, { \(dqhook\(dq:\(dqclass_cmds\(dq }, { \(dqhook\(dq:\(dqlease_cmds\(dq } ] } } ], \(dqroles\(dq:[ { \(dqname\(dq:\(dqadmin\(dq, \(dqaccept\-commands\(dq:\(dqmy\-list\-one\(dq, \(dqreject\-commands\(dq:\(dqALL\(dq, \(dqlist\-match\-first\(dq:\(dqaccept\(dq }, { \(dqname\(dq:\(dqadmin2\(dq, \(dqaccept\-commands\(dq:\(dqmy\-list\-two\(dq, \(dqreject\-commands\(dq:\(dqALL\(dq, \(dqlist\-match\-first\(dq:\(dqaccept\(dq } ], \(dqunknown\-role\(dq:{ \(dqaccept\-commands\(dq:\(dqmy\-list\-three\(dq, \(dqreject\-commands\(dq:\(dqALL\(dq }, \&... } .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT.SS \fBlibdhcp_run_script.so\fP: پشتیبانی اجرای اسکریپت برای اسکریپت‌های قلاب خارجی .sp کتابخانه قلاب Run Script، پشتیبانی از فراخوانی یک اسکریپت خارجی را برای نقاط قلاب (hook points) خاص در پردازش بسته‌ها اضافه می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_run_script.so\fP بخشی از کد منبع‌باز است و برای هر کاربر Kea در دسترس است. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرآیند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_run_script.so\(dq, \(dqparameters\(dq: { \(dqname\(dq: \(dq/full_path_to/script_name.sh\(dq, \(dqsync\(dq: false } } ] } .EE .UNINDENT .UNINDENT .sp پارامترها شامل \fBname\fP هستند که مسیر کامل اسکریپت خارجی را برای فراخوانی در هر نقطه قلاب مشخص می‌کند، و همچنین گزینه \fBsync\fP، تا بتوان به‌طور همگام (synchronous) برای اتمام اجرای اسکریپت منتظر ماند. اگر پارامتر \fBsync\fP برابر با \fBfalse\fP باشد، اسکریپت راه‌اندازی شده و Kea منتظر پایان اجرای آن نخواهد ماند، که باعث می‌شود تمام پارامترهای خروجی (OUT) اسکریپت (از جمله گام بعدی) نادیده گرفته شوند. .sp اسکریپت خارجی باید در دایرکتوری \fB\(dq[kea\-install\-dir]/share/kea/scripts/\(dq\fP ذخیره شود که می‌توان آن را هنگام راه‌اندازی با تنظیم متغیر محیطی \fBKEA_HOOK_SCRIPTS_PATH\fP به یک مسیر دیگر بازنویسی کرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اسکریپت تمام امتیازات و دسترسی‌ها را از سروری که آن را فراخوانی می‌کند به ارث می‌برد. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر، فعال‌سازی فراخوانی‌های همگام به اسکریپت‌های خارجی پشتیبانی نمی‌شود. .UNINDENT .UNINDENT .sp این کتابخانه توابع نقطه قلاب متعددی را پیاده‌سازی کرده است که در مرحله خاصی از پردازش بسته فراخوانی می‌شوند. .sp نقاط قلاب dhcpv4: .INDENT 0.0 .INDENT 3.5 .sp .EX lease4_renew lease4_expire lease4_recover leases4_committed lease4_release lease4_decline .EE .UNINDENT .UNINDENT .sp نقاط قلاب dhcpv6: .INDENT 0.0 .INDENT 3.5 .sp .EX lease6_renew lease6_rebind lease6_expire lease6_recover leases6_committed lease6_release lease6_decline addr6_register .EE .UNINDENT .UNINDENT .sp هر نقطه قلاب داده‌های داخلی Kea را استخراج کرده و آن‌ها را به‌صورت متغیرهای محیطی رشته‌ای صادر (export) می‌کند. این پارامترها با استفاده از محیط فرآیند فرزند با اسکریپت مقصد به اشتراک گذاشته می‌شوند. تنها پارامتری که به فراخوانی اسکریپت مقصد ارسال می‌شود، نام نقطه قلاب است. .sp نمونه‌ای از یک اسکریپت که تمامی نقاط قلاب را پیاده‌سازی می‌کند در زیر ارائه شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX #!/bin/sh unknown_handle() { echo \(dqUnhandled function call ${*}\(dq exit 123 } lease4_renew () { ... } lease4_expire () { ... } lease4_recover () { ... } leases4_committed () { ... } lease4_release () { ... } lease4_decline () { ... } lease6_renew () { ... } lease6_rebind () { ... } lease6_expire () { ... } lease6_recover () { ... } leases6_committed () { ... } lease6_release () { ... } lease6_decline () { ... } addr6_register () { ... } case \(dq$1\(dq in \(dqlease4_renew\(dq) lease4_renew ;; \(dqlease4_expire\(dq) lease4_expire ;; \(dqlease4_recover\(dq) lease4_recover ;; \(dqleases4_committed\(dq) leases4_committed ;; \(dqlease4_release\(dq) lease4_release ;; \(dqlease4_decline\(dq) lease4_decline ;; \(dqlease6_renew\(dq) lease6_renew ;; \(dqlease6_rebind\(dq) lease6_rebind ;; \(dqlease6_expire\(dq) lease6_expire ;; \(dqlease6_recover\(dq) lease6_recover ;; \(dqleases6_committed\(dq) leases6_committed ;; \(dqlease6_release\(dq) lease6_release ;; \(dqlease6_decline\(dq) lease6_decline ;; \(dqaddr6_register\(dq) addr6_register ;; *) unknown_handle \(dq${@}\(dq ;; esac .EE .UNINDENT .UNINDENT .sp پارامترهای موجود برای هر نقطه قلاب در زیر ارائه شده است. .sp DHCPv4: .sp \fBlease4_renew\fP .INDENT 0.0 .INDENT 3.5 .sp .EX QUERY4_TYPE QUERY4_TXID QUERY4_LOCAL_ADDR QUERY4_LOCAL_PORT QUERY4_REMOTE_ADDR QUERY4_REMOTE_PORT QUERY4_IFACE_INDEX QUERY4_IFACE_NAME QUERY4_HOPS QUERY4_SECS QUERY4_FLAGS QUERY4_CIADDR QUERY4_SIADDR QUERY4_YIADDR QUERY4_GIADDR QUERY4_RELAYED QUERY4_HWADDR QUERY4_HWADDR_TYPE QUERY4_LOCAL_HWADDR QUERY4_LOCAL_HWADDR_TYPE QUERY4_REMOTE_HWADDR QUERY4_REMOTE_HWADDR_TYPE QUERY4_OPTION_82 QUERY4_OPTION_82_SUB_OPTION_1 QUERY4_OPTION_82_SUB_OPTION_2 SUBNET4_ID SUBNET4_NAME SUBNET4_PREFIX SUBNET4_PREFIX_LEN PKT4_CLIENT_ID PKT4_HWADDR PKT4_HWADDR_TYPE LEASE4_ADDRESS LEASE4_CLTT LEASE4_HOSTNAME LEASE4_HWADDR LEASE4_HWADDR_TYPE LEASE4_STATE LEASE4_SUBNET_ID LEASE4_VALID_LIFETIME LEASE4_CLIENT_ID .EE .UNINDENT .UNINDENT .sp \fBlease4_expire\fP .INDENT 0.0 .INDENT 3.5 .sp .EX LEASE4_ADDRESS LEASE4_CLTT LEASE4_HOSTNAME LEASE4_HWADDR LEASE4_HWADDR_TYPE LEASE4_STATE LEASE4_SUBNET_ID LEASE4_VALID_LIFETIME LEASE4_CLIENT_ID REMOVE_LEASE .EE .UNINDENT .UNINDENT .sp \fBlease4_recover\fP .INDENT 0.0 .INDENT 3.5 .sp .EX LEASE4_ADDRESS LEASE4_CLTT LEASE4_HOSTNAME LEASE4_HWADDR LEASE4_HWADDR_TYPE LEASE4_STATE LEASE4_SUBNET_ID LEASE4_VALID_LIFETIME LEASE4_CLIENT_ID .EE .UNINDENT .UNINDENT .sp \fBleases4_committed\fP .INDENT 0.0 .INDENT 3.5 .sp .EX QUERY4_TYPE QUERY4_TXID QUERY4_LOCAL_ADDR QUERY4_LOCAL_PORT QUERY4_REMOTE_ADDR QUERY4_REMOTE_PORT QUERY4_IFACE_INDEX QUERY4_IFACE_NAME QUERY4_HOPS QUERY4_SECS QUERY4_FLAGS QUERY4_CIADDR QUERY4_SIADDR QUERY4_YIADDR QUERY4_GIADDR QUERY4_RELAYED QUERY4_HWADDR QUERY4_HWADDR_TYPE QUERY4_LOCAL_HWADDR QUERY4_LOCAL_HWADDR_TYPE QUERY4_REMOTE_HWADDR QUERY4_REMOTE_HWADDR_TYPE QUERY4_OPTION_82 QUERY4_OPTION_82_SUB_OPTION_1 QUERY4_OPTION_82_SUB_OPTION_2 LEASES4_SIZE DELETED_LEASES4_SIZE .EE .UNINDENT .UNINDENT .sp اگر \fBLEASES4_SIZE\fP یا \fBDELETED_LEASES4_SIZE\fP غیر صفر باشد، آنگاه هر اجاره (lease) دارای شناسه یکتای خود خواهد بود، همان‌طور که در زیر نشان داده شده است. اولین نمایه از ۰ آغاز می‌شود. .INDENT 0.0 .INDENT 3.5 .sp .EX LEASES4_AT0_ADDRESS LEASES4_AT0_CLTT LEASES4_AT0_HOSTNAME LEASES4_AT0_HWADDR LEASES4_AT0_HWADDR_TYPE LEASES4_AT0_STATE LEASES4_AT0_SUBNET_ID LEASES4_AT0_VALID_LIFETIME LEASES4_AT0_CLIENT_ID DELETED_LEASES4_AT0_ADDRESS DELETED_LEASES4_AT0_CLTT DELETED_LEASES4_AT0_HOSTNAME DELETED_LEASES4_AT0_HWADDR DELETED_LEASES4_AT0_HWADDR_TYPE DELETED_LEASES4_AT0_STATE DELETED_LEASES4_AT0_SUBNET_ID DELETED_LEASES4_AT0_VALID_LIFETIME DELETED_LEASES4_AT0_CLIENT_ID .EE .UNINDENT .UNINDENT .sp \fBlease4_release\fP .INDENT 0.0 .INDENT 3.5 .sp .EX QUERY4_TYPE QUERY4_TXID QUERY4_LOCAL_ADDR QUERY4_LOCAL_PORT QUERY4_REMOTE_ADDR QUERY4_REMOTE_PORT QUERY4_IFACE_INDEX QUERY4_IFACE_NAME QUERY4_HOPS QUERY4_SECS QUERY4_FLAGS QUERY4_CIADDR QUERY4_SIADDR QUERY4_YIADDR QUERY4_GIADDR QUERY4_RELAYED QUERY4_HWADDR QUERY4_HWADDR_TYPE QUERY4_LOCAL_HWADDR QUERY4_LOCAL_HWADDR_TYPE QUERY4_REMOTE_HWADDR QUERY4_REMOTE_HWADDR_TYPE QUERY4_OPTION_82 QUERY4_OPTION_82_SUB_OPTION_1 QUERY4_OPTION_82_SUB_OPTION_2 LEASE4_ADDRESS LEASE4_CLTT LEASE4_HOSTNAME LEASE4_HWADDR LEASE4_HWADDR_TYPE LEASE4_STATE LEASE4_SUBNET_ID LEASE4_VALID_LIFETIME LEASE4_CLIENT_ID .EE .UNINDENT .UNINDENT .sp \fBlease4_decline\fP .INDENT 0.0 .INDENT 3.5 .sp .EX QUERY4_TYPE QUERY4_TXID QUERY4_LOCAL_ADDR QUERY4_LOCAL_PORT QUERY4_REMOTE_ADDR QUERY4_REMOTE_PORT QUERY4_IFACE_INDEX QUERY4_IFACE_NAME QUERY4_HOPS QUERY4_SECS QUERY4_FLAGS QUERY4_CIADDR QUERY4_SIADDR QUERY4_YIADDR QUERY4_GIADDR QUERY4_RELAYED QUERY4_HWADDR QUERY4_HWADDR_TYPE QUERY4_LOCAL_HWADDR QUERY4_LOCAL_HWADDR_TYPE QUERY4_REMOTE_HWADDR QUERY4_REMOTE_HWADDR_TYPE QUERY4_OPTION_82 QUERY4_OPTION_82_SUB_OPTION_1 QUERY4_OPTION_82_SUB_OPTION_2 LEASE4_ADDRESS LEASE4_CLTT LEASE4_HOSTNAME LEASE4_HWADDR LEASE4_HWADDR_TYPE LEASE4_STATE LEASE4_SUBNET_ID LEASE4_VALID_LIFETIME LEASE4_CLIENT_ID .EE .UNINDENT .UNINDENT .sp DHCPv6: .sp \fBlease6_renew\fP .INDENT 0.0 .INDENT 3.5 .sp .EX QUERY6_TYPE QUERY6_TXID QUERY6_LOCAL_ADDR QUERY6_LOCAL_PORT QUERY6_REMOTE_ADDR QUERY6_REMOTE_PORT QUERY6_IFACE_INDEX QUERY6_IFACE_NAME QUERY6_REMOTE_HWADDR QUERY6_REMOTE_HWADDR_TYPE QUERY6_PROTO QUERY6_CLIENT_ID LEASE6_ADDRESS LEASE6_CLTT LEASE6_HOSTNAME LEASE6_HWADDR LEASE6_HWADDR_TYPE LEASE6_STATE LEASE6_SUBNET_ID LEASE6_VALID_LIFETIME LEASE6_DUID LEASE6_IAID LEASE6_PREFERRED_LIFETIME LEASE6_PREFIX_LEN LEASE6_TYPE PKT6_IA_IAID PKT6_IA_IA_TYPE PKT6_IA_IA_T1 PKT6_IA_IA_T2 .EE .UNINDENT .UNINDENT .sp \fBlease6_rebind\fP .INDENT 0.0 .INDENT 3.5 .sp .EX QUERY6_TYPE QUERY6_TXID QUERY6_LOCAL_ADDR QUERY6_LOCAL_PORT QUERY6_REMOTE_ADDR QUERY6_REMOTE_PORT QUERY6_IFACE_INDEX QUERY6_IFACE_NAME QUERY6_REMOTE_HWADDR QUERY6_REMOTE_HWADDR_TYPE QUERY6_PROTO QUERY6_CLIENT_ID LEASE6_ADDRESS LEASE6_CLTT LEASE6_HOSTNAME LEASE6_HWADDR LEASE6_HWADDR_TYPE LEASE6_STATE LEASE6_SUBNET_ID LEASE6_VALID_LIFETIME LEASE6_DUID LEASE6_IAID LEASE6_PREFERRED_LIFETIME LEASE6_PREFIX_LEN LEASE6_TYPE PKT6_IA_IAID PKT6_IA_IA_TYPE PKT6_IA_IA_T1 PKT6_IA_IA_T2 .EE .UNINDENT .UNINDENT .sp \fBlease6_expire\fP .INDENT 0.0 .INDENT 3.5 .sp .EX LEASE6_ADDRESS LEASE6_CLTT LEASE6_HOSTNAME LEASE6_HWADDR LEASE6_HWADDR_TYPE LEASE6_STATE LEASE6_SUBNET_ID LEASE6_VALID_LIFETIME LEASE6_DUID LEASE6_IAID LEASE6_PREFERRED_LIFETIME LEASE6_PREFIX_LEN LEASE6_TYPE REMOVE_LEASE .EE .UNINDENT .UNINDENT .sp \fBlease6_recover\fP .INDENT 0.0 .INDENT 3.5 .sp .EX LEASE6_ADDRESS LEASE6_CLTT LEASE6_HOSTNAME LEASE6_HWADDR LEASE6_HWADDR_TYPE LEASE6_STATE LEASE6_SUBNET_ID LEASE6_VALID_LIFETIME LEASE6_DUID LEASE6_IAID LEASE6_PREFERRED_LIFETIME LEASE6_PREFIX_LEN LEASE6_TYPE .EE .UNINDENT .UNINDENT .sp \fBleases6_committed\fP .INDENT 0.0 .INDENT 3.5 .sp .EX QUERY6_TYPE QUERY6_TXID QUERY6_LOCAL_ADDR QUERY6_LOCAL_PORT QUERY6_REMOTE_ADDR QUERY6_REMOTE_PORT QUERY6_IFACE_INDEX QUERY6_IFACE_NAME QUERY6_REMOTE_HWADDR QUERY6_REMOTE_HWADDR_TYPE QUERY6_PROTO QUERY6_CLIENT_ID LEASES6_SIZE DELETED_LEASES6_SIZE .EE .UNINDENT .UNINDENT .sp اگر \fBLEASES6_SIZE\fP یا \fBDELETED_LEASES6_SIZE\fP غیر صفر باشد، آنگاه هر اجاره دارای شناسه یکتای خود خواهد بود، همان‌طور که در زیر نشان داده شده است. اولین نمایه از ۰ آغاز می‌شود. .INDENT 0.0 .INDENT 3.5 .sp .EX LEASES6_AT0_ADDRESS LEASES6_AT0_CLTT LEASES6_AT0_HOSTNAME LEASES6_AT0_HWADDR LEASES6_AT0_HWADDR_TYPE LEASES6_AT0_STATE LEASES6_AT0_SUBNET_ID LEASES6_AT0_VALID_LIFETIME LEASES6_AT0_DUID LEASES6_AT0_IAID LEASES6_AT0_PREFERRED_LIFETIME LEASES6_AT0_PREFIX_LEN LEASES6_AT0_TYPE DELETED_LEASES6_AT0_ADDRESS DELETED_LEASES6_AT0_CLTT DELETED_LEASES6_AT0_HOSTNAME DELETED_LEASES6_AT0_HWADDR DELETED_LEASES6_AT0_HWADDR_TYPE DELETED_LEASES6_AT0_STATE DELETED_LEASES6_AT0_SUBNET_ID DELETED_LEASES6_AT0_VALID_LIFETIME DELETED_LEASES6_AT0_DUID DELETED_LEASES6_AT0_IAID DELETED_LEASES6_AT0_PREFERRED_LIFETIME DELETED_LEASES6_AT0_PREFIX_LEN DELETED_LEASES6_AT0_TYPE .EE .UNINDENT .UNINDENT .sp \fBlease6_release\fP .INDENT 0.0 .INDENT 3.5 .sp .EX QUERY6_TYPE QUERY6_TXID QUERY6_LOCAL_ADDR QUERY6_LOCAL_PORT QUERY6_REMOTE_ADDR QUERY6_REMOTE_PORT QUERY6_IFACE_INDEX QUERY6_IFACE_NAME QUERY6_REMOTE_HWADDR QUERY6_REMOTE_HWADDR_TYPE QUERY6_PROTO QUERY6_CLIENT_ID LEASE6_ADDRESS LEASE6_CLTT LEASE6_HOSTNAME LEASE6_HWADDR LEASE6_HWADDR_TYPE LEASE6_STATE LEASE6_SUBNET_ID LEASE6_VALID_LIFETIME LEASE6_DUID LEASE6_IAID LEASE6_PREFERRED_LIFETIME LEASE6_PREFIX_LEN LEASE6_TYPE .EE .UNINDENT .UNINDENT .sp \fBlease6_decline\fP .INDENT 0.0 .INDENT 3.5 .sp .EX QUERY6_TYPE QUERY6_TXID QUERY6_LOCAL_ADDR QUERY6_LOCAL_PORT QUERY6_REMOTE_ADDR QUERY6_REMOTE_PORT QUERY6_IFACE_INDEX QUERY6_IFACE_NAME QUERY6_REMOTE_HWADDR QUERY6_REMOTE_HWADDR_TYPE QUERY6_PROTO QUERY6_CLIENT_ID LEASE6_ADDRESS LEASE6_CLTT LEASE6_HOSTNAME LEASE6_HWADDR LEASE6_HWADDR_TYPE LEASE6_STATE LEASE6_SUBNET_ID LEASE6_VALID_LIFETIME LEASE6_DUID LEASE6_IAID LEASE6_PREFERRED_LIFETIME LEASE6_PREFIX_LEN LEASE6_TYPE .EE .UNINDENT .UNINDENT .sp \fBaddr6_register\fP .INDENT 0.0 .INDENT 3.5 .sp .EX QUERY6_TYPE QUERY6_TXID QUERY6_LOCAL_ADDR QUERY6_LOCAL_PORT QUERY6_REMOTE_ADDR QUERY6_REMOTE_PORT QUERY6_IFACE_INDEX QUERY6_IFACE_NAME QUERY6_REMOTE_HWADDR QUERY6_REMOTE_HWADDR_TYPE QUERY6_PROTO QUERY6_CLIENT_ID ADDRESS6 OLD_LEASE6_ADDRESS OLD_LEASE6_CLTT OLD_LEASE6_HOSTNAME OLD_LEASE6_HWADDR OLD_LEASE6_HWADDR_TYPE OLD_LEASE6_STATE OLD_LEASE6_SUBNET_ID OLD_LEASE6_VALID_LIFETIME OLD_LEASE6_DUID OLD_LEASE6_IAID OLD_LEASE6_PREFERRED_LIFETIME OLD_LEASE6_PREFIX_LEN OLD_LEASE6_TYPE NEW_LEASE6_ADDRESS NEW_LEASE6_CLTT NEW_LEASE6_HOSTNAME NEW_LEASE6_HWADDR NEW_LEASE6_HWADDR_TYPE NEW_LEASE6_STATE NEW_LEASE6_SUBNET_ID NEW_LEASE6_VALID_LIFETIME NEW_LEASE6_DUID NEW_LEASE6_IAID NEW_LEASE6_PREFERRED_LIFETIME NEW_LEASE6_PREFIX_LEN NEW_LEASE6_TYPE .EE .UNINDENT .UNINDENT .sp متغیر OLD_LEASE6 همیشه وجود ندارد. .sp نقطه قلاب leases4_committed برای مدیریت فهرست آدرس‌ها به حلقه‌های for نیاز دارد. این کار را می‌توان به صورت زیر انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX leases4_committed() { for i in $(seq 0 $((LEASES4_SIZE\-1))); do LEASE4_ADDRESS=$(eval \(dqecho \e$LEASES4_AT${i}_ADDRESS\(dq) ... done for i in $(seq 0 $((DELETED_LEASES4_SIZE\-1))); do DELETED_LEASE4_ADDRESS=$(eval \(dqecho \e$DELETED_LEASES4_AT${i}_ADDRESS\(dq) ... done exit 0 } .EE .UNINDENT .UNINDENT .sp نقطه قلاب leases6_committed برای مدیریت فهرست آدرس‌ها به حلقه‌های for نیاز دارد. این کار را می‌توان به صورت زیر انجام داد: .INDENT 0.0 .INDENT 3.5 .sp .EX leases6_committed() { for i in $(seq 0 $((LEASES6_SIZE\-1))); do LEASE6_ADDRESS=$(eval \(dqecho \e$LEASES6_AT${i}_ADDRESS\(dq) ... done for i in $(seq 0 $((DELETED_LEASES6_SIZE\-1))); do DELETED_LEASE6_ADDRESS=$(eval \(dqecho \e$DELETED_LEASES6_AT${i}_ADDRESS\(dq) ... done exit 0 } .EE .UNINDENT .UNINDENT.SS \fBlibdhcp_stat_cmds.so\fP: دستورات آماری برای آمار تکمیلی اجاره‌ها .sp این کتابخانه دستورات بیشتری را برای واکشی آمار اجاره‌ها (leases) از کارسازهای Kea DHCP فراهم می‌کند. این دستورات برای برطرف کردن مشکلی در به‌دست آوردن آمار دقیق اجاره‌ها در استقرارهایی با چندین کارساز Kea که از یک پس‌بند (backend) اجاره مشترک استفاده می‌کنند، اضافه شده‌اند. آمار درون حافظه‌ای (in\-memory) نگهداری‌شده توسط هر یک از کارسازها تنها تغییرات اجاره انجام‌شده توسط همان کارساز را ردیابی می‌کند؛ بنابراین، در استقراری با چندین کارساز (برای مثال دو کارساز \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> که از یک پایگاه‌داده PostgreSQL یکسان برای ذخیره‌سازی اجاره‌ها استفاده می‌کنند)، این آمار ناقص هستند. پس‌بندهای MySQL و PostgreSQL در Kea تغییرات تخصیص اجاره را به محض وقوع از طریق تریگرهای پایگاه‌داده ردیابی می‌کنند. علاوه بر این، تمام پس‌بندهای اجاره برای پشتیبانی از واکشی آمار اجاره‌ها برای یک زیرشبکه، بازه‌ای از زیرشبکه‌ها یا تمام زیرشبکه‌ها توسعه یافته‌اند. در نهایت، این کتابخانه دستوراتی را برای واکشی این آمار ارائه می‌دهد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 کتابخانه \fBlibdhcp_stat_cmds.so\fP بخشی از کد منبع‌باز است و برای تمام کاربران Kea در دسترس است. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرایند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp دستورات ارائه‌شده توسط این کتابخانه عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBstat\-lease4\-get\fP \- آمار اجاره‌های DHCPv4 را واکشی می‌کند. .IP \(bu 2 \fBstat\-lease6\-get\fP \- آمار اجاره‌های DHCPv6 را واکشی می‌کند. .UNINDENT .sp کتابخانه دستورات آماری (Statistics Commands) بخشی از کد منبع‌باز است و برای تمام کاربران Kea در دسترس است. .sp تمام دستورات از ساختار JSON استفاده می‌کنند و می‌توانند مستقیماً از طریق کانال کنترل (بخش Management API \%<#\:ctrl-channel> را ببینید) به کارسازها ارسال شوند. .sp این کتابخانه همانند سایر کتابخانه‌ها بارگذاری می‌شود و در حال حاضر هیچ پارامتری ندارد: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqDhcp6\(dq: { \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibdhcp_stat_cmds.so\(dq }, ... ] } .EE .UNINDENT .UNINDENT .sp در استقراری با چندین کارساز Kea DHCP که یک فضای ذخیره‌سازی مشترک اجاره را به اشتراک می‌گذارند، این کتابخانه قلاب (hook library) می‌تواند توسط یک یا تمام کارسازها بارگذاری شود. با این حال، پاسخ یک کارساز به دستور \fBstat\-lease4\-get\fP / \fBstat\-lease6\-get\fP تنها شامل داده‌های مربوط به زیرشبکه‌های شناخته‌شده برای آن کارساز خواهد بود. به عبارت دیگر، اگر زیرشبکه‌ای در پیکربندی کارساز وجود نداشته باشد، Kea آماری برای آن واکشی نخواهد کرد. .SS دستورات \fBstat\-lease4\-get\fP و \fBstat\-lease6\-get\fP .sp دستورات \fBstat\-lease4\-get\fP و \fBstat\-lease6\-get\fP آمار اجاره را برای بازه‌ای از زیرشبکه‌های شناخته‌شده واکشی می‌کنند. بازه زیرشبکه‌ها از طریق استفاده از پارامترهای اختیاری ورودی دستور مشخص می‌شود: .INDENT 0.0 .IP \(bu 2 \fBsubnet\-id\fP \- شناسه زیرشبکه‌ای که آمار اجاره برای آن باید واکشی شود؛ برای دریافت آمار یک زیرشبکه تکی به کار می‌رود. اگر زیرشبکه وجود نداشته باشد، کد نتیجه دستور ۳ خواهد بود (یعنی \fBCONTROL_RESULT_EMPTY\fP). .IP \(bu 2 \fBsubnet\-range\fP \- جفتی از شناسه‌های زیرشبکه که بازه فراگیری (شامل هر دو سر بازه) از زیرشبکه‌ها را که آمار برای آن‌ها باید واکشی شود توصیف می‌کند. این بازه ممکن است شامل یک یا چند شناسه باشد که با هیچ زیرشبکه‌ای مطابقت ندارند؛ در این حالت، دستور تنها آمار اجاره را برای آن‌هایی که وجود دارند در خروجی می‌آورد. با این حال، اگر بازه شامل هیچ زیرشبکه شناخته‌شده‌ای نباشد، کد نتیجه دستور ۳ خواهد بود (یعنی \fBCONTROL_RESULT_EMPTY\fP). .INDENT 2.0 .IP \(bu 2 \fBfirst\-subnet\-id\fP \- شناسه نخستین زیرشبکه در بازه. .IP \(bu 2 \fBlast\-subnet\-id\fP \- شناسه آخرین زیرشبکه در بازه. .UNINDENT .UNINDENT .sp استفاده از \fBsubnet\-id\fP و \fBsubnet\-range\fP مانعة‌الجمع است (نمی‌توان هم‌زمان از هر دو استفاده کرد). اگر هیچ پارامتری داده نشود، نتیجه حاوی داده‌های تمام زیرشبکه‌های شناخته‌شده خواهد بود. توجه داشته باشید که در پیکربندی‌هایی با زیرشبکه‌های متعدد، این امر می‌تواند منجر به پاسخی حجیم شود. .sp دستور زیر آمار اجاره را برای تمام زیرشبکه‌های شناخته‌شده از یک کارساز \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> واکشی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstat\-lease4\-get\(dq } .EE .UNINDENT .UNINDENT .sp دستور زیر آمار اجاره را برای زیرشبکه با شناسه ۱۰ از یک کارساز \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> واکشی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstat\-lease6\-get\(dq, \(dqarguments\(dq: { \(dqsubnet\-id\(dq : 10 } } .EE .UNINDENT .UNINDENT .sp دستور زیر آمار اجاره را برای تمام زیرشبکه‌های با شناسه‌ای در بازه ۱۰ تا ۵۰ از یک کارساز \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> واکشی می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstat\-lease4\-get\(dq, \(dqarguments\(dq: { \(dqsubnet\-range\(dq: { \(dqfirst\-subnet\-id\(dq: 10, \(dqlast\-subnet\-id\(dq: 50 } } } .EE .UNINDENT .UNINDENT .sp پاسخ هر یک از این دو دستور شامل سه عنصر خواهد بود: .INDENT 0.0 .IP \(bu 2 \fBresult\fP \- یک مقدار عددی که نتیجه دستور را مشخص می‌کند به طوری که: .INDENT 2.0 .IP \(bu 2 \fB0\fP \- دستور موفقیت‌آمیز بود؛ .IP \(bu 2 \fB1\fP \- خطایی رخ داد، و توضیح آن در عنصر \(dqtext\(dq است؛ یا .IP \(bu 2 \fB2\fP \- واکشی هیچ داده منطبقی نیافت. .UNINDENT .IP \(bu 2 \fBtext\fP \- توضیحی درباره نتیجه دستور. هنگامی که دستور با موفقیت انجام شود، شامل نام دستور به همراه تعداد سطرهای بازگردانده‌شده است. .IP \(bu 2 \fBarguments\fP \- یک نگاشت حاوی داده‌های بازگردانده‌شده توسط دستور به عنوان عنصر \(dqresult\-set\(dq، که از الگوی پاسخ‌های دستورات SQL پیروی می‌کند: .INDENT 2.0 .IP \(bu 2 \fBcolumns\fP \- فهرستی از برچسب‌های متنی ستون‌ها. .sp ستون‌های بازگردانده‌شده برای DHCPv4 عبارتند از: .INDENT 2.0 .IP \(bu 2 \fBsubnet\-id\fP \- شناسه زیرشبکه. .IP \(bu 2 \fBtotal\-addresses\fP \- تعداد کل نشانی‌های موجود برای مدیریت DHCPv4 در زیرشبکه. به عبارت دیگر، این شمارش تمام نشانی‌ها در همه استخرهای (pools) پیکربندی‌شده در زیرشبکه است. .IP \(bu 2 \fBcumulative\-assigned\-addresses\fP \- تعداد تجمعی نشانی‌هایی در زیرشبکه که از زمان شروع به کار کارساز توسط آن به یک کلاینت تخصیص داده شده‌اند. .IP \(bu 2 \fBassigned\-addresses\fP \- تعداد نشانی‌هایی در زیرشبکه که در حال حاضر به یک کلاینت تخصیص داده شده‌اند. .IP \(bu 2 \fBdeclined\-addresses\fP \- تعداد نشانی‌هایی در زیرشبکه که در حال حاضر رد شده‌اند (declined) و بنابراین برای تخصیص در دسترس نیستند. .UNINDENT .sp ستون‌های بازگردانده‌شده برای DHCPv6 عبارتند از: .INDENT 2.0 .IP \(bu 2 \fBsubnet\-id\fP \- شناسه زیرشبکه..IP \(bu 2 \fBtotal\-nas\fP \- تعداد آدرس‌های NA موجود برای مدیریت DHCPv6 در زیرشبکه. به عبارت دیگر، این تعداد کل آدرس‌های NA در تمام استخرهای NA پیکربندی‌شده در زیرشبکه است. .IP \(bu 2 \fBcumulative\-assigned\-nas\fP \- تعداد تجمعی آدرس‌های NA در زیرشبکه که از زمان راه‌اندازی سرور به یک کلاینت اختصاص داده شده‌اند. .IP \(bu 2 \fBassigned\-nas\fP \- تعداد آدرس‌های NA در زیرشبکه که در حال حاضر به یک کلاینت اختصاص داده شده‌اند. .IP \(bu 2 \fBdeclined\-addresses\fP \- تعداد آدرس‌های NA که در حال حاضر رد شده‌اند (declined) و در نتیجه برای تخصیص در دسترس نیستند. .IP \(bu 2 \fBtotal\-pds\fP \- تعداد کل پیشوندهای PD موجود برای مدیریت DHCPv6 در زیرشبکه. به عبارت دیگر، این تعداد کل پیشوندها در تمام استخرهای پیشوند پیکربندی‌شده در زیرشبکه است. .IP \(bu 2 \fBcumulative\-assigned\-pds\fP \- تعداد تجمعی پیشوندهای PD در زیرشبکه که از زمان راه‌اندازی سرور به یک کلاینت اختصاص یافته‌اند. .IP \(bu 2 \fBassigned\-pds\fP \- تعداد پیشوندهای PD در زیرشبکه که در حال حاضر به یک کلاینت اختصاص داده شده‌اند. .UNINDENT .IP \(bu 2 \fBrows\fP \- فهرستی از سطرها، یک سطر به ازای هر شناسه زیرشبکه (subnet ID). هر سطر شامل مقادیر داده‌ای متناظر با ستون‌های فهرست‌شده در \(dqcolumns\(dq و به همان ترتیب برای یک زیرشبکه مشخص است. .IP \(bu 2 \fBtimestamp\fP \- تاریخ و زمان متنیِ واکشی داده‌ها، بیان‌شده بر اساس GMT. .UNINDENT .UNINDENT .sp پاسخ به یک دستور DHCPv4 ممکن است به صورت زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqstat\-lease4\-get: 2 rows found\(dq, \(dqarguments\(dq: { \(dqresult\-set\(dq: { \(dqcolumns\(dq: [ \(dqsubnet\-id\(dq, \(dqtotal\-addresses\(dq, \(dqcumulative\-assigned\-addresses\(dq, \(dqassigned\-addresses\(dq, \(dqdeclined\-addresses\(dq ], \(dqrows\(dq: [ [ 10, 256, 300, 111, 0 ], [ 20, 4098, 2034, 2034, 4 ] ], \(dqtimestamp\(dq: \(dq2018\-05\-04 15:03:37.000000\(dq } } } .EE .UNINDENT .UNINDENT .sp پاسخ به یک دستور DHCPv6 با این فرض که زیرشبکه 10 هیچ استخر پیشوندی ندارد، زیرشبکه 20 هیچ استخر NA ندارد، و زیرشبکه 30 دارای هر دو استخر NA و PD است، ممکن است به شکل زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqstat\-lease6\-get: 2 rows found\(dq, \(dqarguments\(dq: { \(dqresult\-set\(dq: { \(dqcolumns\(dq: [ \(dqsubnet\-id\(dq, \(dqtotal\-nas\(dq, \(dqcumulative\-assigned\-nas\(dq, \(dqassigned\-nas\(dq, \(dqdeclined\-addresses\(dq, \(dqtotal\-pds\(dq, \(dqcumulative\-assigned\-pds\(dq, \(dqassigned\-pds\(dq ], \(dqrows\(dq: [ [ 10, 4096, 5000, 2400, 3, 0, 0, 0], [ 20, 0, 0, 0, 0, 1048, 300, 233 ], [ 30, 256, 60, 60, 0, 1048, 15, 15 ] ], \(dqtimestamp\(dq: \(dq2018\-05\-04 15:03:37.000000\(dq } } } .EE .UNINDENT .UNINDENT .SS \fBlibdhcp_subnet_cmds.so\fP: دستورهای زیرشبکه برای مدیریت زیرشبکه‌ها و شبکه‌های اشتراکی .sp این کتابخانه دستورهایی را برای پرس‌وجو و دستکاری پیکربندی‌های زیرشبکه و شبکه اشتراکی (shared network) در Kea ارائه می‌دهد. این دستورها می‌توانند در استقرارهایی با تعداد زیادی زیرشبکه که توسط سرورهای DHCP مدیریت می‌شوند، هنگامی که آن زیرشبکه‌ها مکرراً به‌روزرسانی می‌شوند، بسیار مفید باشند. این دستورها رویکردی سبک را برای دستکاری زیرشبکه‌ها بدون نیاز به پیکربندی مجددِ کامل سرور، و بدون تأثیر بر پیکربندی‌های موجود سرور فراهم می‌کنند. همچنین قابلیت مدیریت شبکه‌های اشتراکی (فهرست‌کردن، بازیابی جزئیات، افزودن موارد جدید، حذف موارد موجود، و افزودن زیرشبکه‌ها به شبکه‌های اشتراکی و حذف آن‌ها از شبکه اشتراکی) نیز ارائه شده است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_subnet_cmds.so\fP بخشی از کد متن‌باز است و برای همه کاربران Kea در دسترس است. این کتابخانه پیش‌تر فقط برای مشتریان ISC با قرارداد پشتیبانی پولی در دسترس بود. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه فقط می‌تواند توسط فرایند \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp در حال حاضر دستورهای زیر پشتیبانی می‌شوند: .INDENT 0.0 .IP \(bu 2 \fBsubnet4\-list\fP / \fBsubnet6\-list\fP \- تمام زیرشبکه‌های پیکربندی‌شده را فهرست می‌کند. .IP \(bu 2 \fBsubnet4\-get\fP / \fBsubnet6\-get\fP \- اطلاعات تفصیلی مربوط به یک زیرشبکه مشخص را بازیابی می‌کند. .IP \(bu 2 \fBsubnet4\-add\fP / \fBsubnet6\-add\fP \- یک زیرشبکه جدید به پیکربندی سرور اضافه می‌کند. .IP \(bu 2 \fBsubnet4\-update\fP / \fBsubnet6\-update\fP \- یک زیرشبکه مشخص را در پیکربندی سرور به‌روزرسانی (جایگزین) می‌کند. .IP \(bu 2 \fBsubnet4\-del\fP / \fBsubnet6\-del\fP \- یک زیرشبکه را از پیکربندی سرور حذف می‌کند. .IP \(bu 2 \fBsubnet4\-delta\-add\fP / \fBsubnet6\-delta\-add\fP \- بخش‌هایی از یک زیرشبکه مشخص را در پیکربندی سرور به‌روزرسانی (جایگزین) می‌کند. .IP \(bu 2 \fBsubnet4\-delta\-del\fP / \fBsubnet6\-delta\-del\fP \- بخش‌هایی از یک زیرشبکه مشخص را در پیکربندی سرور حذف می‌کند. .IP \(bu 2 \fBnetwork4\-list\fP / \fBnetwork6\-list\fP \- تمام شبکه‌های اشتراکی پیکربندی‌شده را فهرست می‌کند. .IP \(bu 2 \fBnetwork4\-get\fP / \fBnetwork6\-get\fP \- اطلاعات تفصیلی مربوط به یک شبکه اشتراکی مشخص را بازیابی می‌کند. .IP \(bu 2 \fBnetwork4\-add\fP / \fBnetwork6\-add\fP \- یک شبکه اشتراکی جدید به پیکربندی سرور اضافه می‌کند. .IP \(bu 2 \fBnetwork4\-del\fP / \fBnetwork6\-del\fP \- یک شبکه اشتراکی را از پیکربندی سرور حذف می‌کند. .IP \(bu 2 \fBnetwork4\-subnet\-add\fP / \fBnetwork6\-subnet\-add\fP \- یک زیرشبکه موجود را به یک شبکه اشتراکی موجود اضافه می‌کند. .IP \(bu 2 \fBnetwork4\-subnet\-del\fP / \fBnetwork6\-subnet\-del\fP \- یک زیرشبکه را از یک شبکه اشتراکی موجود حذف کرده و آن را به یک زیرشبکه عادی تنزل می‌دهد. .UNINDENT.SS دستور \fBsubnet4\-list\fP .sp این دستور برای فهرست کردن تمام زیرشبکه‌های پیکربندی‌شده فعلی به کار می‌رود. هر زیرشبکه به همراه شناسه زیرشبکه، پیشوند زیرشبکه و نام شبکه مشترک (در صورت موجود بودن) بازگردانده می‌شود. برای بازیابی اطلاعات دقیق درباره زیرشبکه، از دستور \fBsubnet4\-get\fP استفاده کنید. .sp این دستور ساختار ساده‌ای دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet4\-list\(dq } .EE .UNINDENT .UNINDENT .sp فهرست زیرشبکه‌ها با قالب زیر بازگردانده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 IPv4 subnets found\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 10, \(dqshared\-network\-name\(dq: \(dqnet1\(dq, \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq }, { \(dqid\(dq: 100, \(dqshared\-network\-name\(dq: null, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq } ] } } .EE .UNINDENT .UNINDENT .sp اگر هیچ زیرشبکه IPv4ای پیدا نشود، یک کد خطا به همراه شرح خطا بازگردانده می‌شود. .SS دستور \fBsubnet6\-list\fP .sp این دستور برای فهرست کردن تمام زیرشبکه‌های پیکربندی‌شده فعلی به کار می‌رود. هر زیرشبکه به همراه شناسه زیرشبکه، پیشوند زیرشبکه و نام شبکه مشترک (در صورت موجود بودن) بازگردانده می‌شود. برای بازیابی اطلاعات دقیق درباره زیرشبکه، از دستور \fBsubnet6\-get\fP استفاده کنید. .sp این دستور ساختار ساده‌ای دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet6\-list\(dq } .EE .UNINDENT .UNINDENT .sp فهرست زیرشبکه‌ها با قالب زیر بازگردانده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 IPv6 subnets found\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 11, \(dqshared\-network\-name\(dq: null, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq }, { \(dqid\(dq: 233, \(dqshared\-network\-name\(dq: \(dqsome\-net\(dq, \(dqsubnet\(dq: \(dq3000::/16\(dq } ] } } .EE .UNINDENT .UNINDENT .sp اگر هیچ زیرشبکه IPv6ای پیدا نشود، یک کد خطا به همراه شرح خطا بازگردانده می‌شود. .SS دستور \fBsubnet4\-get\fP .sp این دستور برای بازیابی اطلاعات دقیق درباره زیرشبکه مشخص‌شده به کار می‌رود. این دستور معمولاً پس از \fBsubnet4\-list\fP استفاده می‌شود، که برای کشف زیرشبکه‌های موجود به همراه شناسه‌ها و پیشوندهای زیرشبکه مربوطه‌شان به کار می‌رود. سپس از هر کدام از این پارامترها می‌توان در \fBsubnet4\-get\fP برای دریافت اطلاعات زیرشبکه استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet4\-get\(dq, \(dqarguments\(dq: { \(dqid\(dq: 10 } } .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet4\-get\(dq, \(dqarguments\(dq: { \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq } } .EE .UNINDENT .UNINDENT .sp اگر زیرشبکه وجود داشته باشد، پاسخ مشابه زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqInfo about IPv4 subnet 10.0.0.0/8 (id 10) returned\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqsubnet\(dq: \(dq10.0.0.0/8\(dq, \(dqid\(dq: 1, \(dqoption\-data\(dq: [ { ... }, ... ], ... } ] } } .EE .UNINDENT .UNINDENT.SS دستور \fBsubnet6\-get\fP .sp این دستور برای بازیابی اطلاعات تفصیلی درباره زیرشبکه مشخص‌شده به کار می‌رود. این دستور معمولاً پس از \fBsubnet6\-list\fP اجرا می‌شود که برای یافتن زیرشبکه‌های موجود به همراه شناسه‌ها و پیشوندهای زیرشبکه مربوطه‌شان استفاده می‌گردد. سپس می‌توان از هر یک از این پارامترها در \fBsubnet6\-get\fP برای دریافت اطلاعات زیرشبکه استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet6\-get\(dq, \(dqarguments\(dq: { \(dqid\(dq: 11 } } .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet6\-get\(dq, \(dqarguments\(dq: { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq } } .EE .UNINDENT .UNINDENT .sp اگر زیرشبکه وجود داشته باشد، پاسخ مشابه این خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqInfo about IPv6 subnet 2001:db8:1::/64 (id 11) returned\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqid\(dq: 1, \(dqoption\-data\(dq: [ { ... }, ... ], ... } ] } } .EE .UNINDENT .UNINDENT .SS دستور \fBsubnet4\-add\fP .sp این دستور برای ایجاد و افزودن یک زیرشبکه جدید به پیکربندی موجود سرور به کار می‌رود. این عملیات هیچ تاثیری بر سایر زیرشبکه‌ها ندارد. شناسه زیرشبکه باید مشخص شود و در میان تمام زیرشبکه‌ها یکتا باشد. اگر شناسه یا پیشوند زیرشبکه یکتا نباشد، خطایی گزارش شده و زیرشبکه افزوده نمی‌شود. .sp اطلاعات زیرشبکه درون این دستور دارای همان ساختار اطلاعات زیرشبکه در فایل پیکربندی سرور است، با این استثنا که رزروهای ایستای میزبان را نمی‌توان درون \fBsubnet4\-add\fP\& مشخص کرد. برای افزودن، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح‌داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet4\-add\(dq, \(dqarguments\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 123, \(dqsubnet\(dq: \(dq10.20.30.0/24\(dq, ... } ] } } .EE .UNINDENT .UNINDENT .sp پاسخ به این دستور ساختار زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv4 subnet added\(dq, \(dqarguments\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 123, \(dqsubnet\(dq: \(dq10.20.30.0/24\(dq } ] } } .EE .UNINDENT .UNINDENT .SS دستور \fBsubnet6\-add\fP .sp این دستور برای ایجاد و افزودن یک زیرشبکه جدید به پیکربندی موجود سرور به کار می‌رود. این عملیات هیچ تاثیری بر سایر زیرشبکه‌ها ندارد. شناسه زیرشبکه باید مشخص شود و در میان تمام زیرشبکه‌ها یکتا باشد. اگر شناسه یا پیشوند زیرشبکه یکتا نباشد، خطایی گزارش شده و زیرشبکه افزوده نمی‌شود. .sp اطلاعات زیرشبکه درون این دستور دارای همان ساختار اطلاعات زیرشبکه در فایل پیکربندی سرور است، با این استثنا که رزروهای ایستای میزبان را نمی‌توان درون \fBsubnet6\-add\fP\& مشخص کرد. برای افزودن، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح‌داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet6\-add\(dq, \(dqarguments\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 234, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, ... } ] } } .EE .UNINDENT .UNINDENT .sp پاسخ به این دستور ساختار زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv6 subnet added\(dq, \(dqarguments\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 234, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq } ] } } .EE .UNINDENT .UNINDENT .sp از Kea 2.6.0 به بعد، Kea دیگر شناسه‌های زیرشبکه را به‌طور خودکار تولید نمی‌کند؛ آن‌ها باید برای \fBsubnet4\-add\fP و \fBsubnet6\-add\fP\& مشخص شوند. در صورت عدم تعیین، Kea تلاش می‌کند مقدار بعدی \fBsubnet\-id\fP را اختصاص دهد. این تولیدکننده خودکار مقادیر شناسه ساده است؛ مقدار اختصاص‌یافته خودکار قبلی را به علاوه ۱ برمی‌گرداند. این سازوکار به خوبی کار می‌کند، مگر اینکه یک زیرشبکه به‌صورت دستی با مقداری بزرگ‌تر از مقادیر قبلاً استفاده‌شده ایجاد شود. برای مثال، اگر \fBsubnet4\-add\fP پنج بار فراخوانی شود، هر بار بدون شناسه، Kea شناسه‌های ۱، ۲، ۳، ۴ و ۵ را اختصاص خواهد داد و همه‌چیز به درستی کار خواهد کرد. با این حال، اگر \fBsubnet4\-add\fP پنج بار فراخوانی شود، در حالی که اولین زیرشبکه دارای \fBsubnet\-id\fP با مقدار ۳ باشد و باقی آن‌ها فاقد \fBsubnet\-id\fP باشند، عملیات با شکست مواجه خواهد شد. اولین دستور (با مقدار صریح) از \fBsubnet\-id\fP مقدار ۳ استفاده خواهد کرد؛ دومین دستور زیرشبکه‌ای با شناسه ۱ ایجاد می‌کند؛ سومی از مقدار ۲ استفاده خواهد کرد؛ و سرانجام مقدار \fBsubnet\-id\fP چهارمی به‌طور خودکار برابر با ۳ تولید خواهد شد. اما از آن‌جا که هم‌اکنون زیرشبکه‌ای با آن شناسه وجود دارد، فرآیند با شکست مواجه خواهد شد. .sp توصیه عمومی این است که یا هرگز از مقادیر صریح استفاده نکنید تا مقادیر تولید‌شده به‌طور خودکار همیشه کار کنند؛ یا همیشه از مقادیر صریح استفاده کنید تا از تولید خودکار هرگز استفاده نشود. این دو رویکرد تنها در صورتی می‌توانند با هم ترکیب شوند که مدیر سیستم از نحوه کارکرد تولید خودکار داخلی \fBsubnet\-id\fP در Kea آگاه باشد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 شناسه‌های زیرشبکه باید بزرگ‌تر از صفر و کوچک‌تر از 4294967295 باشند. .UNINDENT .UNINDENT.SS دستور \fBsubnet4\-update\fP .sp این دستور برای به‌روزرسانی (بازنویسی) یک زیرشبکهٔ منفرد در پیکربندی موجود سرور استفاده می‌شود. این عملیات هیچ اثری بر سایر زیرشبکه‌ها ندارد. شناسهٔ زیرشبکه برای شناسایی زیرشبکه‌ای که باید جایگزین شود به‌کار می‌رود؛ این شناسه باید مشخص شده و در میان تمام زیرشبکه‌ها یکتا باشد. پیشوند زیرشبکه نباید به‌روزرسانی شود. .sp اطلاعات زیرشبکه در این دستور ساختاری مشابه با اطلاعات زیرشبکه در فایل پیکربندی سرور دارد، با این استثنا که رزروهای میزبان ایستا را نمی‌توان در \fBsubnet4\-update\fP\& مشخص کرد. برای به‌روزرسانی، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet4\-update\(dq, \(dqarguments\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 123, \(dqsubnet\(dq: \(dq10.20.30.0/24\(dq, ... } ] } } .EE .UNINDENT .UNINDENT .sp پاسخ به این دستور ساختار زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv4 subnet updated\(dq, \(dqarguments\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 123, \(dqsubnet\(dq: \(dq10.20.30.0/24\(dq } ] } } .EE .UNINDENT .UNINDENT .sp همانند سایر دستورهای به‌روزرسانی، این دستور تمام محتویات مدخل را بازنویسی می‌کند. اگر زیرشبکهٔ IPv4 پیش‌تر منبعی به آن تخصیص یافته بود و دستور \fBsubnet4\-update\fP فاقد آن منبع باشد، آن منبع از پیکربندی سرور حذف خواهد شد. چنانچه به‌روزرسانی افزایشی زیرشبکه مد نظر باشد، از \fBsubnet4\-delta\-add\fP\& استفاده کنید. .SS دستور \fBsubnet6\-update\fP .sp این دستور برای به‌روزرسانی (بازنویسی) یک زیرشبکهٔ منفرد در پیکربندی موجود سرور استفاده می‌شود. این عملیات هیچ اثری بر سایر زیرشبکه‌ها ندارد. شناسهٔ زیرشبکه برای شناسایی زیرشبکه‌ای که باید جایگزین شود به‌کار می‌رود؛ این شناسه باید مشخص شده و در میان تمام زیرشبکه‌ها یکتا باشد. پیشوند زیرشبکه نباید به‌روزرسانی شود. .sp اطلاعات زیرشبکه در این دستور ساختاری مشابه با اطلاعات زیرشبکه در فایل پیکربندی سرور دارد، با این استثنا که رزروهای میزبان ایستا را نمی‌توان در \fBsubnet6\-update\fP\& مشخص کرد. برای به‌روزرسانی، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet6\-update\(dq, \(dqarguments\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 234, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, ... } ] } } .EE .UNINDENT .UNINDENT .sp پاسخ به این دستور ساختار زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv6 subnet updated\(dq, \(dqarguments\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 234, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq } ] } } .EE .UNINDENT .UNINDENT .sp همانند سایر دستورهای به‌روزرسانی، این دستور تمام محتویات مدخل را بازنویسی می‌کند. اگر زیرشبکهٔ IPv6 پیش‌تر منبعی به آن تخصیص یافته بود و دستور \fBsubnet6\-update\fP فاقد آن منبع باشد، آن منبع از پیکربندی سرور حذف خواهد شد. چنانچه به‌روزرسانی افزایشی زیرشبکه مد نظر باشد، از \fBsubnet6\-delta\-add\fP\& استفاده کنید. .SS دستور \fBsubnet4\-del\fP .sp این دستور برای حذف یک زیرشبکه از پیکربندی سرور به‌کار می‌رود. این دستور اثری بر سایر زیرشبکه‌های پیکربندی‌شده ندارد، اما حذف یک زیرشبکه پیامدهای خاصی به همراه دارد. .sp در بیشتر موارد، سرور اجاره‌هایی (leases) را به کلاینت‌های متعلق به آن زیرشبکه تخصیص داده است. همچنین ممکن است سرور با رزروهای میزبان ایستایی پیکربندی شده باشد که به این زیرشبکه مرتبط هستند. پیاده‌سازی کنونی دستور \fBsubnet4\-del\fP نه اجاره‌ها و نه رزروهای میزبان مرتبط با زیرشبکه را حذف نمی‌کند. این امن‌ترین رویکرد است زیرا سرور ردیابی اجاره‌های تخصیص‌یافته به کلاینت‌های این زیرشبکه را از دست نمی‌دهد. با این حال، حذف زیرشبکه ممکن است همچنان باعث بروز خطاها و تداخل‌های پیکربندی شود. برای مثال: پس از حذف زیرشبکه، ممکن است مدیر سرور زیرشبکهٔ جدیدی را با همان شناسه‌ای که پیش‌تر برای زیرشبکهٔ حذف‌شده استفاده شده بود، به‌روزرسانی کند. این بدان معناست که اجاره‌های موجود و رزروهای ایستا با این زیرشبکهٔ جدید تداخل خواهند داشت؛ بنابراین، توصیه می‌کنیم که این دستور با احتیاط بسیار بالا استفاده شود. .sp این دستور همچنین می‌تواند برای حذف کامل یک زیرشبکهٔ IPv4 که بخشی از یک شبکهٔ مشترک (shared network) است استفاده شود. برای حذف صرف زیرشبکه از یک شبکهٔ مشترک و نگه‌داشتن پیکربندی آن زیرشبکه، در عوض از دستور \fBnetwork4\-subnet\-del\fP استفاده کنید. .sp این دستور ساختار زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet4\-del\(dq, \(dqarguments\(dq: { \(dqid\(dq: 123 } } .EE .UNINDENT .UNINDENT .sp یک پاسخ موفقیت‌آمیز ممکن است به این شکل باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv4 subnet 192.0.2.0/24 (id 123) deleted\(dq, \(dqarguments\(dq: { \(dqsubnets\(dq: [ { \(dqid\(dq: 123, \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq } ] } } .EE .UNINDENT .UNINDENT.SS دستور \fBsubnet6\-del\fP .sp این دستور برای حذف یک زیرشبکه از پیکربندی سرور استفاده می‌شود. این دستور هیچ تأثیری بر سایر زیرشبکه‌های پیکربندی‌شده ندارد، اما حذف یک زیرشبکه پیامدهای خاصی به همراه دارد. .sp در بیشتر موارد، سرور اجاره‌هایی را به کلاینت‌های متعلق به این زیرشبکه اختصاص داده است. سرور همچنین ممکن است با رزروهای ایستای میزبان که با این زیرشبکه مرتبط هستند، پیکربندی شده باشد. پیاده‌سازی فعلی دستور \fBsubnet6\-del\fP نه اجاره‌ها و نه رزروهای میزبان مرتبط با یک زیرشبکه را حذف نمی‌کند. این امن‌ترین رویکرد است چرا که سرور ردیابی اجاره‌های اختصاص‌یافته به کلاینت‌های این زیرشبکه را از دست نمی‌دهد. با این حال، حذف زیرشبکه ممکن است همچنان باعث بروز خطاها و تداخل‌های پیکربندی شود. برای مثال: پس از حذف زیرشبکه، مدیر سرور ممکن است یک زیرشبکه جدید با شناسه‌ای که پیش‌تر برای زیرشبکه حذف‌شده استفاده می‌شد، اضافه کند. این بدان معناست که اجاره‌های موجود و رزروهای ایستا با این زیرشبکه جدید در تداخل خواهند بود. بنابراین، توصیه می‌کنیم که این دستور با احتیاط بسیار زیاد استفاده شود. .sp این دستور همچنین می‌تواند برای حذف کامل یک زیرشبکه IPv6 که بخشی از یک شبکه مشترک است استفاده شود. برای صرفاً حذف زیرشبکه از یک شبکه مشترک و حفظ پیکربندی زیرشبکه، به جای آن از دستور \fBnetwork6\-subnet\-del\fP استفاده کنید. .sp این دستور ساختار زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet6\-del\(dq, \(dqarguments\(dq: { \(dqid\(dq: 234 } } .EE .UNINDENT .UNINDENT .sp یک پاسخ موفق ممکن است به این شکل باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv6 subnet 2001:db8:1::/64 (id 234) deleted\(dq, \(dqsubnets\(dq: [ { \(dqid\(dq: 234, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq } ] } .EE .UNINDENT .UNINDENT .SS دستور \fBsubnet4\-delta\-add\fP .sp این دستور برای به‌روزرسانی یک زیرشبکه از طریق افزودن یا بازنویسی بخش‌هایی از آن در پیکربندی موجود سرور استفاده می‌شود. این عملیات هیچ تأثیری بر سایر زیرشبکه‌ها ندارد. از شناسه زیرشبکه برای تعیین زیرشبکه جهت به‌روزرسانی استفاده می‌شود؛ این شناسه باید مشخص شود و باید در میان تمام زیرشبکه‌ها یکتا باشد. پیشوند زیرشبکه نباید به‌روزرسانی شود. .sp اطلاعات زیرشبکه در این دستور ساختاری مشابه با اطلاعات زیرشبکه در فایل پیکربندی سرور دارد، با این استثنا که رزروهای ایستای میزبان را نمی‌توان در \fBsubnet4\-delta\-add\fP\& مشخص کرد. برای به‌روزرسانی، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح‌داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود. .sp این دستور از کلیدها برای شناسایی شیء مربوطه استفاده می‌کند. کلیدها قابل به‌روزرسانی نیستند. برای افزودن اشیای دیگر با کلیدهای متداخل، ابتدا باید اشیاء حذف شوند. استخرهای آدرس با پارامتر \fIpool\fP شناسایی می‌شوند؛ گزینه‌ها با پارامترهای \fIname\fP یا \fIcode\fP و \fIspace\fP شناسایی می‌شوند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet4\-delta\-add\(dq, \(dqarguments\(dq: { \(dqsubnet4\(dq: [ { \(dqvalid\-lifetime\(dq: 120, \(dqid\(dq: 123, \(dqsubnet\(dq: \(dq10.20.30.0/24\(dq, \(dqoption\-data\(dq: [ { \(dqalways\-send\(dq: false, \(dqcode\(dq: 3, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq192.0.3.1\(dq, \(dqname\(dq: \(dqrouters\(dq, \(dqspace\(dq: \(dqdhcp4\(dq } ], \(dqpools\(dq: [ { \(dqpool\(dq: \(dq10.20.30.1\-10.20.30.10\(dq, \(dqoption\-data\(dq: [ { \(dqalways\-send\(dq: false, \(dqcode\(dq: 4, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq192.0.4.1\(dq, \(dqname\(dq: \(dqtime\-servers\(dq, \(dqspace\(dq: \(dqdhcp4\(dq } ] } ] } ] } } .EE .UNINDENT .UNINDENT .sp پاسخ به این دستور ساختار زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv4 subnet updated\(dq, \(dqarguments\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 123, \(dqsubnet\(dq: \(dq10.20.30.0/24\(dq } ] } } .EE .UNINDENT .UNINDENT .sp این دستور زیرشبکه \(dq10.20.30.0/24\(dq با شناسه 123 را با تغییر طول‌عمر معتبر، با افزودن یا تغییر گزینه سطح زیرشبکه 3 (\(dqrouters\(dq)، با افزودن یا تغییر پارامترهای استخر \(dq10.20.30.1\-10.20.30.10\(dq، و با افزودن یا تغییر گزینه سطح استخر 4 (\(dqtime\-servers\(dq) به‌روزرسانی می‌کند..SS دستور \fBsubnet6\-delta\-add\fP .sp این دستور برای به‌روزرسانی یک زیرشبکه با افزودن یا بازنویسی بخش‌هایی از آن در پیکربندی موجود سرور استفاده می‌شود. این عملیات هیچ اثری بر سایر زیرشبکه‌ها ندارد. شناسهٔ زیرشبکه برای شناسایی زیرشبکه‌ای که باید به‌روزرسانی شود استفاده می‌شود؛ این مقدار باید مشخص گردد و در میان تمام زیرشبکه‌ها منحصربه‌فرد باشد. پیشوند زیرشبکه نباید به‌روزرسانی شود. .sp اطلاعات زیرشبکه در این دستور ساختاری یکسان با اطلاعات زیرشبکه در فایل پیکربندی سرور دارد، با این استثنا که رزروهای ایستای میزبان نمی‌توانند درون \fBsubnet6\-delta\-add\fP\& مشخص شوند. برای به‌روزرسانی، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح‌داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود. .sp این دستور از کلیدها برای شناسایی شیء مربوطه استفاده می‌کند. کلیدها قابل به‌روزرسانی نیستند. اشیاء ابتدا باید حذف شوند تا بتوان اشیاء دیگری را با کلیدهای متداخل اضافه کرد. استخرهای آدرس با پارامتر \fIpool\fP شناسایی می‌شوند؛ استخرهای پیشوند با پارامترهای \fIprefix\fP، \fIprefix\-len\fP و \fIdelegated\-len\fP شناسایی می‌شوند؛ و گزینه‌ها با پارامترهای \fIname\fP یا \fIcode\fP و \fIspace\fP شناسایی می‌گردند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet6\-delta\-add\(dq, \(dqarguments\(dq: { \(dqsubnet6\(dq: [ { \(dqvalid\-lifetime\(dq: 120, \(dqid\(dq: 243, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqoption\-data\(dq: [ { \(dqalways\-send\(dq: false, \(dqcode\(dq: 23, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq3000::3:1\(dq, \(dqname\(dq: \(dqdns\-servers\(dq, \(dqspace\(dq: \(dqdhcp6\(dq } ], \(dqpd\-pools\(dq: [ { \(dqprefix\(dq: \(dq2001:db8:2::\(dq, \(dqprefix\-len\(dq: 48, \(dqdelegated\-len\(dq: 64, \(dqoption\-data\(dq: [ { \(dqalways\-send\(dq: false, \(dqcode\(dq: 22, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq3000::4:1\(dq, \(dqname\(dq: \(dqsip\-server\-addr\(dq, \(dqspace\(dq: \(dqdhcp6\(dq } ] } ], \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8:1::1\-2001:db8:1::10\(dq, \(dqoption\-data\(dq: [ { \(dqalways\-send\(dq: false, \(dqcode\(dq: 31, \(dqcsv\-format\(dq: true, \(dqdata\(dq: \(dq3000::5:1\(dq, \(dqname\(dq: \(dqsntp\-servers\(dq, \(dqspace\(dq: \(dqdhcp6\(dq } ] } ] } ] } } .EE .UNINDENT .UNINDENT .sp پاسخ این دستور ساختار زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv6 subnet updated\(dq, \(dqarguments\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 234, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq } ] } } .EE .UNINDENT .UNINDENT .sp این دستور زیرشبکهٔ \(dq2001:db8:1::/64\(dq با شناسهٔ 243 را با تغییر طول عمر معتبر (valid lifetime)، افزودن یا تغییر گزینهٔ سطح زیرشبکهٔ 23 (\(dqdns\-servers\(dq)، افزودن یا تغییر پارامترهای استخر \(dq2001:db8:1::1\-2001:db8:1::10\(dq، افزودن یا تغییر گزینهٔ سطح استخر 31 (\(dqsntp\-servers\(dq)، افزودن یا تغییر پارامترهای pd\-pool با عنوان \(dq2001:db8:2::\(dq با prefix\-len برابر با 48، و افزودن یا تغییر گزینهٔ سطح pd\-pool شمارهٔ 22 (\(dqsip\-server\-addr\(dq) به‌روزرسانی می‌کند. .SS دستور \fBsubnet4\-delta\-del\fP .sp این دستور برای به‌روزرسانی یک زیرشبکه با حذف بخش‌هایی از آن در پیکربندی موجود سرور استفاده می‌شود. این عملیات هیچ اثری بر سایر زیرشبکه‌ها ندارد. شناسهٔ زیرشبکه برای شناسایی زیرشبکه‌ای که باید به‌روزرسانی شود استفاده می‌شود؛ این مقدار باید مشخص گردد و در میان تمام زیرشبکه‌ها منحصربه‌فرد باشد. پیشوند زیرشبکه نباید به‌روزرسانی شود. .sp اطلاعات زیرشبکه در این دستور ساختاری یکسان با اطلاعات زیرشبکه در فایل پیکربندی سرور دارد، با این استثنا که رزروهای ایستای میزبان نمی‌توانند درون \fBsubnet4\-delta\-del\fP\& مشخص شوند. برای به‌روزرسانی، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح‌داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود. .sp این دستور انعطاف‌پذیر است و می‌تواند بخشی از زیرشبکه را با مشخص کردن کل شیئی که باید حذف شود، یا صرفاً با مشخص کردن کلیدهای شناسایی‌کنندهٔ شیء مربوطه حذف کند. استخرهای آدرس با پارامتر \fIpool\fP شناسایی می‌شوند؛ و گزینه‌ها با پارامترهای \fIname\fP یا \fIcode\fP، و \fIspace\fP شناسایی می‌گردند. اگر گزینه متعلق به فضای پیش‌فرض \fIdhcp4\fP باشد، پارامتر \fIspace\fP می‌تواند نادیده گرفته شود. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet4\-delta\-del\(dq, \(dqarguments\(dq: { \(dqsubnet4\(dq: [ { \(dqvalid\-lifetime\(dq: 0, \(dqid\(dq: 123, \(dqsubnet\(dq: \(dq10.20.30.0/24\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqrouters\(dq } ], \(dqpools\(dq: [ { \(dqoption\-data\(dq: [ { \(dqcode\(dq: 4 } ], \(dqpool\(dq: \(dq10.20.30.11\-10.20.30.20\(dq }, { \(dqpool\(dq: \(dq10.20.30.21\-10.20.30.30\(dq } ] } ] } } .EE .UNINDENT .UNINDENT .sp پاسخ این دستور ساختار زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv4 subnet updated\(dq, \(dqarguments\(dq: { \(dqsubnet4\(dq: [ { \(dqid\(dq: 123, \(dqsubnet\(dq: \(dq10.20.30.0/24\(dq } ] } } .EE .UNINDENT .UNINDENT .sp این دستور زیرشبکهٔ \(dq10.20.30.0/24\(dq با شناسهٔ 123 را با حذف طول عمر معتبر (valid lifetime)، حذف گزینهٔ سطح زیرشبکهٔ 3 (\(dqrouters\(dq)، حذف استخر \(dq10.20.30.21\-10.20.30.30\(dq و حذف گزینهٔ سطح استخر 4 (\(dqtime\-servers\(dq) در استخر \(dq10.20.30.11\-10.20.30.20\(dq به‌روزرسانی می‌کند. نیازی نیست مقادیر اسکالر با آنچه پیکربندی شده مطابقت داشته باشند، اما همچنان باید حضور داشته باشند تا ساختار معتبر JSON حفظ شود و مقدار معتبری برای تجزیه شدن (parse) باشند..SS دستور \fBsubnet6\-delta\-del\fP .sp این دستور برای به‌روزرسانی یک زیرشبکه از طریق حذف بخش‌هایی از آن در پیکربندی موجود کارساز به کار می‌رود. این عملیات هیچ تأثیری بر سایر زیرشبکه‌ها ندارد. از شناسهٔ زیرشبکه برای تعیین زیرشبکه جهت به‌روزرسانی استفاده می‌شود؛ این شناسه باید مشخص شده و در میان تمام زیرشبکه‌ها یکتا باشد. پیشوند زیرشبکه نباید به‌روزرسانی شود. .sp اطلاعات زیرشبکه در این دستور ساختاری مشابه با اطلاعات زیرشبکه در فایل پیکربندی کارساز دارد، با این استثنا که رزروهای ایستا برای میزبان را نمی‌توان درون \fBsubnet6\-delta\-del\fP\& مشخص کرد. برای به‌روزرسانی، حذف و اصلاح رزروهای ایستا باید از دستورهای شرح داده شده در libdhcp_host_cmds.so: Host Commands استفاده شود. .sp این دستور انعطاف‌پذیر است و می‌تواند با مشخص کردن کل شیئی که باید حذف شود، یا تنها با مشخص کردن کلیدهای شناسایی‌کنندهٔ آن شیء، بخش مربوطه از زیرشبکه را حذف کند. استخرهای آدرس با پارامتر \fIpool\fP مشخص می‌شوند؛ استخرهای پیشوند با پارامترهای \fIprefix\fP، \fIprefix\-len\fP و \fIdelegated\-len\fP شناسایی می‌شوند؛ و گزینه‌ها با پارامترهای \fIname\fP یا \fIcode\fP و \fIspace\fP مشخص می‌گردند. در صورتی که گزینه متعلق به فضای پیش‌فرض \fIdhcp6\fP باشد، می‌توان پارامتر \fIspace\fP را نادیده گرفت. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqsubnet6\-delta\-del\(dq, \(dqarguments\(dq: { \(dqsubnet6\(dq: [ { \(dqvalid\-lifetime\(dq: 0, \(dqid\(dq: 234, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqdns\-servers\(dq } ], \(dqpd\-pools\(dq: [ { \(dqprefix\(dq: \(dq2001:db8:3::\(dq, \(dqprefix\-len\(dq: 48, \(dqdelegated\-len\(dq: 64, \(dqoption\-data\(dq: [ { \(dqcode\(dq: 22 } ] }, { \(dqprefix\(dq: \(dq2001:db8:4::\(dq, \(dqprefix\-len\(dq: 48, \(dqdelegated\-len\(dq: 64 } ], \(dqpools\(dq: [ { \(dqoption\-data\(dq: [ { \(dqcode\(dq: 31 } ], \(dqpool\(dq: \(dq2001:db8:1::11\-2001:db8:1::20\(dq }, { \(dqpool\(dq: \(dq2001:db8:1::21\-2001:db8:1::30\(dq } ] } ] } } .EE .UNINDENT .UNINDENT .sp پاسخ این دستور ساختار زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv6 subnet updated\(dq, \(dqarguments\(dq: { \(dqsubnet6\(dq: [ { \(dqid\(dq: 234, \(dqsubnet\(dq: \(dq2001:db8:1::/64\(dq } ] } } .EE .UNINDENT .UNINDENT .sp این دستور زیرشبکهٔ \(dq2001:db8:1::/64\(dq با شناسهٔ 243 را با حذف valid lifetime، حذف گزینهٔ 23 در سطح زیرشبکه (\(dqdns\-servers\(dq)، حذف استخر \(dq2001:db8:1::21\-2001:db8:1::30\(dq، حذف گزینهٔ 31 در سطح استخر (\(dqsntp\-servers\(dq) در استخر \(dq2001:db8:1::11\-2001:db8:1::20\(dq، حذف pd\-pool با عنوان \(dq2001:db8:4::\(dq با prefix\-len برابر با 48، و حذف گزینهٔ 22 در سطح pd\-pool (\(dqsip\-server\-addr\(dq) در pd\-pool با عنوان \(dq2001:db8:3::\(dq با prefix\-len برابر با 48 به‌روزرسانی می‌کند. نیازی نیست مقادیر اسکالر با آنچه پیکربندی شده مطابقت داشته باشند، اما برای حفظ ساختار معتبر json و داشتن یک مقدار معتبر جهت امکان تجزیه شدن، همچنان باید مشخص شوند. .SS دستورهای \fBnetwork4\-list\fP و \fBnetwork6\-list\fP .sp این دستورها برای دریافت فهرست کامل شبکه‌های اشتراکی پیکربندی‌شده در حال حاضر به کار می‌روند. این فهرست تنها شامل اطلاعات بسیار پایه‌ای دربارهٔ هر شبکهٔ اشتراکی است. اگر به جزئیات بیشتری نیاز است، لطفاً از \fBnetwork4\-get\fP یا \fBnetwork6\-get\fP برای بازیابی تمامی اطلاعات موجود استفاده کنید. این دستور به هیچ پارامتری نیاز ندارد و فراخوانی آن بسیار ساده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqnetwork4\-list\(dq } .EE .UNINDENT .UNINDENT .sp یک نمونه پاسخ برای \fBnetwork4\-list\fP به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqfloor1\(dq }, { \(dqname\(dq: \(dqoffice\(dq } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 IPv4 network(s) found\(dq } .EE .UNINDENT .UNINDENT .sp دستور \fBnetwork6\-list\fP برای هر دو بخش دستور و پاسخ، دقیقاً از ساختار نحوی یکسانی استفاده می‌کند..SS دستورهای \fBnetwork4\-get\fP و \fBnetwork6\-get\fP .sp این دستورها برای دریافت اطلاعات دقیق درباره شبکه‌های اشتراکی (shared networks)، شامل زیرشبکه‌هایی که در حال حاضر بخشی از یک شبکه مشخص هستند، استفاده می‌شوند. هر دو دستور یک پارامتر اجباری به نام \fBname\fP می‌گیرند که نام شبکه اشتراکی را مشخص می‌کند. یک دستور نمونه برای دریافت جزئیات یک شبکه اشتراکی IPv4 با نام \(dqfloor13\(dq به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqnetwork4\-get\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqfloor13\(dq } } .EE .UNINDENT .UNINDENT .sp یک پاسخ نمونه می‌تواند به صورت زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqInfo about IPv4 shared network \(aqfloor13\(aq returned\(dq, \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqmatch\-client\-id\(dq: true, \(dqname\(dq: \(dqfloor13\(dq, \(dqoption\-data\(dq: [ ], \(dqrebind\-timer\(dq: 90, \(dqrelay\(dq: { \(dqip\-address\(dq: \(dq0.0.0.0\(dq }, \(dqrenew\-timer\(dq: 60, # Specify if the server should look up global reservations. \(dqreservations\-global\(dq: false, # Specify if the server should look up in\-subnet reservations. \(dqreservations\-in\-subnet\(dq: true, # Specify if the server can assume that all reserved addresses # are out\-of\-pool. \(dqreservations\-out\-of\-pool\(dq: false, \(dqsubnet4\(dq: [ { \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqid\(dq: 5, ... # many other subnet\-specific details here }, { \(dqid\(dq: 6, \(dqsubnet\(dq: \(dq192.0.3.0/31\(dq, ... # many other subnet\-specific details here } ], \(dqvalid\-lifetime\(dq: 120 } ] } } .EE .UNINDENT .UNINDENT .sp پاسخ واقعی شامل فیلدهای اضافی بسیاری است که در اینجا برای وضوح بیشتر حذف شده‌اند. قالب پاسخ دقیقاً همان قالبی است که در \fBconfig\-get\fP \%<#\:std-isccmd-config-get> استفاده می‌شود، با این تفاوت که تنها به بازگرداندن اطلاعات شبکه اشتراکی محدود شده است. .SS دستورهای \fBnetwork4\-add\fP و \fBnetwork6\-add\fP .sp این دستورها برای افزودن یک شبکه اشتراکی جدید استفاده می‌شوند که باید نامی یکتا داشته باشد. این دستور به یک پارامتر به نام \fBshared\-networks\fP نیاز دارد که یک لیست است و باید دقیقاً شامل یک مدخل (entry) باشد که شبکه را تعریف می‌کند. تنها عنصر اجباری برای یک شبکه، نام آن است. اگرچه از نظر عملیاتی منطقی به نظر نمی‌رسد، اما امکان افزودن یک شبکه اشتراکی خالی که هیچ زیرشبکه‌ای در آن وجود ندارد، ممکن است. این کار برای اهداف آزمایشی مجاز است، اما داشتن شبکه‌های خالی (یا شبکه‌هایی با تنها یک زیرشبکه) در محیط‌های عملیاتی (production) توصیه نمی‌شود. برای جزئیات مربوط به نحو (syntax)، به Shared Networks in DHCPv4 \%<#\:shared-network4> و Shared Networks in DHCPv6 \%<#\:shared-network6>\& مراجعه کنید. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برخلاف توارث پارامترها در حین پردازش یک پیکربندی کامل جدید، این دستور توارث پارامتر را به طور کامل مدیریت نمی‌کند. هر پارامتر مفقود به جای این که از محدوده سراسری (global scope) به ارث برده شود، با مقادیر پیش‌فرض پر خواهد شد. .UNINDENT .UNINDENT .sp یک نمونه که نحوه افزودن یک شبکه اشتراکی IPv4 جدید را نشان می‌دهد به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqnetwork4\-add\(dq, \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqfloor13\(dq, \(dqsubnet4\(dq: [ { \(dqid\(dq: 100, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.2.2\-192.0.2.99\(dq } ], \(dqsubnet\(dq: \(dq192.0.2.0/24\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.2.1\(dq } ] }, { \(dqid\(dq: 101, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq192.0.3.2\-192.0.3.99\(dq } ], \(dqsubnet\(dq: \(dq192.0.3.0/24\(dq, \(dqoption\-data\(dq: [ { \(dqname\(dq: \(dqrouters\(dq, \(dqdata\(dq: \(dq192.0.3.1\(dq } ] } ] } ] } } .EE .UNINDENT .UNINDENT .sp با فرض اینکه قبلاً هیچ شبکه اشتراکی با نام \(dqfloor13\(dq و هیچ زیرشبکه‌ای با شناسه‌های 100 و 101 پیکربندی نشده باشد، دستور با موفقیت اجرا خواهد شد و پاسخ زیر را برمی‌گرداند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqfloor13\(dq } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dqA new IPv4 shared network \(aqfloor13\(aq added\(dq } .EE .UNINDENT .UNINDENT .sp دستور \fBnetwork6\-add\fP هم برای پرس‌وجو و هم برای پاسخ از همین نحو استفاده می‌کند. با این حال، برخی پارامترها فقط مخصوص IPv4 هستند (مانند \fBmatch\-client\-id\fP) و برخی دیگر فقط مخصوص IPv6 هستند (مانند \fBinterface\-id\fP). همین موضوع برای زیرشبکه‌های درون شبکه نیز صدق می‌کند..SS دستورهای \fBnetwork4\-del\fP و \fBnetwork6\-del\fP .sp این دستورها برای حذف شبکه‌های اشتراکی موجود به کار می‌روند. هر دو دستور دقیقاً یک پارامتر می‌گیرند، \fBname\fP، که نام شبکه مورد نظر برای حذف را مشخص می‌کند. نمونه‌ای از فراخوانی دستور \fBnetwork4\-del\fP به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqnetwork4\-del\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqfloor13\(dq } } .EE .UNINDENT .UNINDENT .sp با فرض اینکه چنین شبکه‌ای پیکربندی شده باشد، پاسخ مشابه نمونه زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqarguments\(dq: { \(dqshared\-networks\(dq: [ { \(dqname\(dq: \(dqfloor13\(dq } ] }, \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv4 shared network \(aqfloor13\(aq deleted\(dq } .EE .UNINDENT .UNINDENT .sp دستور \fBnetwork6\-del\fP دقیقاً از همان نحو برای هر دوی دستور و پاسخ استفاده می‌کند. .sp اگر زیرشبکه‌هایی متعلق به شبکه اشتراکیِ در حال حذف وجود داشته باشند، آن‌ها به یک زیرشبکه ساده تنزل داده می‌شوند. یک پارامتر اختیاری به نام \fBsubnets\-action\fP وجود دارد که در صورت تعیین شدن، یکی از دو مقدار ممکن را می‌پذیرد: \fBkeep\fP (که پیش‌فرض است) و \fBdelete\fP\&. این گزینه مشخص می‌کند که آیا زیرشبکه‌ها به زیرشبکه‌های ساده تنزل یابند یا حذف شوند. یک نمونه استفاده در دستور \fBnetwork6\-del\fP که شبکه اشتراکی و تمام زیرشبکه‌های درون آن را حذف می‌کند می‌تواند به صورت زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqnetwork4\-del\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqfloor13\(dq, \(dqsubnets\-action\(dq: \(dqdelete\(dq } } .EE .UNINDENT .UNINDENT .sp همچنین برای حذف کامل زیرشبکه‌ها، استفاده از دستورهای \fBsubnet4\-del\fP یا \fBsubnet6\-del\fP امکان‌پذیر است. .SS دستورهای \fBnetwork4\-subnet\-add\fP و \fBnetwork6\-subnet\-add\fP .sp این دستورها برای افزودن زیرشبکه‌های موجود به شبکه‌های اشتراکی موجود به کار می‌روند. چندین روش برای افزودن یک شبکه اشتراکی جدید وجود دارد. مدیر سیستم می‌تواند کل شبکه اشتراکی را یک‌جا اضافه کند، چه از طریق ویرایش فایل پیکربندی یا با فراخوانی دستور \fBnetwork4\-add\fP یا \fBnetwork6\-add\fP به همراه زیرشبکه‌های مورد نظر در آن. این رویکرد برای زیرشبکه‌های اشتراکی کاملاً جدید به خوبی عمل می‌کند. با این حال، ممکن است مواردی پیش بیاید که آدرس‌های یک زیرشبکه موجود رو به اتمام باشد و لازم باشد با فضای آدرس‌دهی بیشتر گسترش یابد؛ به عبارت دیگر، باید زیرشبکه دیگری بر روی آن افزوده شود. برای این سناریو، مدیر سیستم می‌تواند از \fBnetwork4\-add\fP یا \fBnetwork6\-add\fP استفاده کرده و سپس با استفاده از \fBnetwork4\-subnet\-add\fP یا \fBnetwork6\-subnet\-add\fP، یک زیرشبکه موجود را به این شبکه اشتراکی تازه ایجاد شده اضافه کند. .sp دستورهای \fBnetwork4\-subnet\-add\fP و \fBnetwork6\-subnet\-add\fP دو پارامتر دریافت می‌کنند: \fBid\fP، که یک عدد صحیح است و شناسه (ID) یک زیرشبکه موجود را برای افزوده شدن به یک شبکه اشتراکی مشخص می‌کند؛ و \fBname\fP، که نام شبکه اشتراکی‌ای را که زیرشبکه به آن اضافه خواهد شد مشخص می‌سازد. زیرشبکه نباید به هیچ شبکه موجودی تعلق داشته باشد؛ برای انتساب مجدد یک زیرشبکه از یک شبکه اشتراکی به شبکه دیگر، ابتدا از دستورهای \fBnetwork4\-subnet\-del\fP یا \fBnetwork6\-subnet\-del\fP استفاده کنید. .sp نمونه‌ای از فراخوانی دستور \fBnetwork4\-subnet\-add\fP به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqnetwork4\-subnet\-add\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqfloor13\(dq, \(dqid\(dq: 5 } } .EE .UNINDENT .UNINDENT .sp با فرض وجود شبکه‌ای به نام \(dqfloor13\(dq، و وجود زیرشبکه‌ای با \fBsubnet\-id\fP برابر با 5 که بخشی از شبکه موجود نیست، این دستور پاسخی مشابه زیر را بازمی‌گرداند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv4 subnet 10.0.0.0/8 (id 5) is now part of shared network \(aqfloor13\(aq\(dq } .EE .UNINDENT .UNINDENT .sp دستور \fBnetwork6\-subnet\-add\fP دقیقاً از همان نحو برای هر دوی دستور و پاسخ استفاده می‌کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 برخلاف توارث پارامترها در طول پردازش یک پیکربندی کامل و جدید یا هنگام افزودن یک شبکه اشتراکی جدید به همراه زیرشبکه‌های جدید، این دستور وراثت پارامترها را به طور کامل مدیریت نمی‌کند. هر پارامتر مشخص‌نشده به جای به ارث رسیدن از دامنه سراسری یا از شبکه اشتراکی، با مقادیر پیش‌فرض پر خواهد شد. .UNINDENT .UNINDENT.SS دستورهای \fBnetwork4\-subnet\-del\fP و \fBnetwork6\-subnet\-del\fP .sp این دستورها برای حذف یک زیرشبکه که بخشی از یک شبکهٔ اشتراکی (shared network) موجود است و تنزل آن به یک زیرشبکهٔ مستقل و عادی به کار می‌روند. برای حذف کامل یک زیرشبکه، در عوض از دستورهای \fBsubnet4\-del\fP یا \fBsubnet6\-del\fP استفاده کنید. دستورهای \fBnetwork4\-subnet\-del\fP و \fBnetwork6\-subnet\-del\fP دو پارامتر می‌گیرند: \fBid\fP که یک عدد صحیح است و شناسهٔ زیرشبکهٔ موجودی را مشخص می‌کند که باید از یک شبکهٔ اشتراکی حذف شود؛ و \fBname\fP که نام شبکهٔ اشتراکی را که زیرشبکه از آن حذف خواهد شد مشخص می‌کند. .sp یک نمونه از فراخوانی دستور \fBnetwork4\-subnet\-del\fP به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqnetwork4\-subnet\-del\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqfloor13\(dq, \(dqid\(dq: 5 } } .EE .UNINDENT .UNINDENT .sp با فرض اینکه زیرشبکه‌ای با \fBsubnet\-id\fP برابر با ۵ وجود داشته که بخشی از یک شبکهٔ اشتراکی با نام \(dqfloor13\(dq بوده است، پاسخ مشابه زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqIPv4 subnet 10.0.0.0/8 (id 5) is now removed from shared network \(aqfloor13\(aq\(dq } .EE .UNINDENT .UNINDENT .sp دستور \fBnetwork6\-subnet\-del\fP برای هر دوی دستور و پاسخ از همان ساختار نحوی استفاده می‌کند. .SS \fBlibdhcp_user_chk.so\fP: بررسی کاربر (User Check) .sp این کتابخانه چندین هدف را دنبال می‌کند: .INDENT 0.0 .IP \(bu 2 تخصیص کاربران «جدید» یا «ثبت‌نشده» به یک زیرشبکهٔ محدود، در حالی که کاربران «شناخته‌شده» یا «ثبت‌شده» به زیرشبکه‌های بدون محدودیت تخصیص می‌یابند. .IP \(bu 2 امکان سفارشی‌سازی گزینه‌های پاسخ DHCP یا مقادیر گزینه‌های سازنده بر اساس هویت کاربر. .IP \(bu 2 فراهم آوردن یک گزارش بی‌درنگ از فعالیت ثبت کاربران، که می‌تواند توسط یک مصرف‌کنندهٔ خارجی نمونه‌برداری شود. .IP \(bu 2 ارائه به عنوان نمونه‌ای نمایشی از قابلیت‌های گوناگونی که می‌توان با استفاده از رابط قلاب‌ها (hooks interface) پیاده‌سازی کرد. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBlibdhcp_user_chk.so\fP بخشی از کد متن‌باز است و در دسترس تمام کاربران Kea قرار دارد. .UNINDENT .UNINDENT .sp این کتابخانه پس از بارگذاری، امکان جداسازی درخواست‌های دریافتی به کلاینت‌های شناخته‌شده و ناشناخته را فراهم می‌کند. برای کلاینت‌های شناخته‌شده، بسته‌ها طبق روال معمول پردازش می‌شوند، هرچند امکان بازنویسی ارسال برخی گزینه‌ها به ازای هر میزبان وجود دارد. کلاینت‌هایی که در فهرست میزبان‌های شناخته‌شده نیستند، به عنوان ناشناخته تلقی شده و به آخرین زیرشبکهٔ تعریف‌شده در فایل پیکربندی تخصیص می‌یابند. .sp به عنوان نمونه‌ای از یک مورد کاربرد، این رفتار می‌تواند برای قرار دادن کاربران ناشناخته در یک زیرشبکهٔ مجزا پیاده‌سازی شود که به یک «باغ محصور» (walled garden) منتهی می‌شود؛ جایی که آن‌ها تنها به یک درگاه ثبت‌نام دسترسی دارند. پس از اینکه داده‌های لازم را پر کردند، مشخصات آن‌ها به فایل کلاینت‌های شناخته‌شده افزوده می‌شود و پس از راه‌اندازی مجدد دستگاه، یک آدرس مناسب دریافت می‌کنند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه چندین سال قبل از در دسترس قرار گرفتن سازوکار رزرو میزبان (host reservation) توسعه یافته بود. رزرو میزبان بسیار قدرتمندتر و انعطاف‌پذیرتر است، اما توانایی \fBuser_chk\fP در مراجعه به یک منبع اطلاعات خارجی دربارهٔ کلاینت‌ها و تغییر رفتار Kea همچنان مفید و دارای ارزش آموزشی است. .UNINDENT .UNINDENT .sp این کتابخانه در زمان بارگذاری و هر بار که یک بستهٔ دریافتی پردازش می‌شود، فایل \fB/usr/local/share/kea/user_chk_registry.txt\fP را می‌خواند. انتظار می‌رود هر خط از فایل شامل یک قطعه کد JSON مستقل باشد که باید دارای دو مدخل زیر باشد: .INDENT 0.0 .IP \(bu 2 \fBtype\fP \- که مقدار آن برای کاربران IPv4 برابر با \fB\(dqHW_ADDR\(dq\fP یا برای کاربران IPv6 برابر با \fB\(dqDUID\(dq\fP است. .IP \(bu 2 \fBid\fP \- که مقدار آن یا آدرس سخت‌افزاری یا DUID از درخواست است، که در قالب رشته‌ای از ارقام هگزادسیمال، با یا بدون جداکننده‌های \(dq:\(dq قالب‌بندی شده است. .UNINDENT .sp و می‌تواند صفر یا تعداد بیشتری از مدخل‌های زیر را داشته باشد: .INDENT 0.0 .IP \(bu 2 \fBbootfile\fP \- که مقدار آن مسیر فایل مورد نظر است. .IP \(bu 2 \fBtftp_server\fP \- که مقدار آن نام میزبان یا آدرس IP کارساز مورد نظر است. .UNINDENT .sp نمونه‌ای از یک فایل ثبت کاربر در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqtype\(dq : \(dqHW_ADDR\(dq, \(dqid\(dq : \(dq0c:0e:0a:01:ff:04\(dq, \(dqbootfile\(dq : \(dq/usr/local/share/kea/v4bootfile\(dq } { \(dqtype\(dq : \(dqHW_ADDR\(dq, \(dqid\(dq : \(dq0c:0e:0a:01:ff:06\(dq, \(dqtftp_server\(dq : \(dqtftp.v4.example.com\(dq } { \(dqtype\(dq : \(dqDUID\(dq, \(dqid\(dq : \(dq00:01:00:01:19:ef:e6:3b:00:0c:01:02:03:04\(dq, \(dqbootfile\(dq : \(dq/usr/local/share/kea/v6bootfile\(dq } { \(dqtype\(dq : \(dqDUID\(dq, \(dqid\(dq : \(dq00:01:00:01:19:ef:e6:3b:00:0c:01:02:03:06\(dq, \(dqtftp_server\(dq : \(dqtftp.v6.example.com\(dq } .EE .UNINDENT .UNINDENT .sp همانند هر کتابخانهٔ قلاب دیگری که توسط ISC ارائه می‌شود، سازوکار درونی کد \fBuser_chk\fP به خوبی مستند شده است. کاربران برای کسب اطلاعات دربارهٔ چگونگی عملکرد درونی کد، می‌توانند به بخش کتابخانهٔ user_chk در راهنمای توسعه‌دهندگان Kea \% مراجعه کنند. این بخش به همراه بخش چارچوب قلاب‌ها در راهنمای توسعه‌دهندگان Kea \% باید راهنمایی‌های لازم را در اختیار کاربران قرار دهد تا این کتابخانه را توسعه دهند و شاید حتی کتابخانه‌ای را از ابتدا بنویسند..SH "آمارها (STATISTICS)" .SS "نمای کلی آمارها (Statistics Overview)" .sp هر دو کارگزار Kea DHCP از جمع‌آوری آمارها پشتیبانی می‌کنند. یک کارگزار DHCP فعال با رویدادهای گوناگونی مواجه می‌شود که می‌توانند باعث جمع‌آوری آمارهای مشخصی گردند. برای نمونه، یک کارگزار DHCPv4 ممکن است بسته‌ای دریافت کند (آمار \fBpkt4\-received\fP یک واحد افزایش می‌یابد) که پس از تجزیه، به‌عنوان DHCPDISCOVER شناسایی می‌شود (\fBpkt4\-discover\-received\fP). کارگزار آن را پردازش کرده و تصمیم می‌گیرد یک DHCPOFFER را به‌عنوان پاسخ خود ارسال کند (آمارهای \fBpkt4\-offer\-sent\fP و \fBpkt4\-sent\fP یک واحد افزایش می‌یابند). چنین رویدادهایی مکرراً رخ می‌دهند، بنابراین داشتن مقادیری در مرتبه چند ده هزار برای آمارها غیرمعمول نیست. آن‌ها می‌توانند ابزاری آسان و قدرتمند برای نظارت بر سلامت یک کارگزار و یک شبکه باشند. برای مثال، اگر رشد آمار \fBpkt4\-received\fP متوقف شود، به این معنی است که بسته‌های کلاینت‌ها به کارگزار نمی‌رسند. .sp چهار نوع آمار وجود دارد: .INDENT 0.0 .IP \(bu 2 \fIinteger\fP \- این رایج‌ترین نوع است. به‌صورت یک عدد صحیح ۶۴ بیتی (int64_t در C++) پیاده‌سازی شده است، بنابراین می‌تواند هر مقداری بین \-2^63 تا 2^63\-1 را در خود نگه دارد. .IP \(bu 2 \fIbig integer\fP \- این نوع برای نگهداری اعداد بزرگ در نظر گرفته شده است. به‌صورت یک عدد صحیح ۱۲۸ بیتی (boost::multiprecision::int128_t در C++) پیاده‌سازی شده است، بنابراین می‌تواند هر مقداری بین \-2^127 تا 2^127\-1 را نگهداری کند. .IP \(bu 2 \fIfloating point\fP \- این نوع برای ذخیره دقت ممیز شناور طراحی شده است. به‌صورت نوع double در C++ پیاده‌سازی شده است. .IP \(bu 2 \fIduration\fP \- این نوع برای ثبت بازه‌های زمانی در نظر گرفته شده است. این نوع از \(gaboost::posix_time::time_duration استفاده می‌کند که ساعت‌ها، دقیقه‌ها، ثانیه‌ها و میکروثانیه‌ها را ذخیره می‌نماید. .IP \(bu 2 \fIstring\fP \- این نوع برای ثبت آمارها به شکل متنی در نظر گرفته شده است. این نوع از std::string در C++ استفاده می‌کند. .UNINDENT .sp در طول عملکرد عادی، کارگزارهای DHCPv4 و DHCPv6 آمارها را جمع‌آوری می‌کنند. برای فهرستی از آمارهای DHCPv4 و DHCPv6، به‌ترتیب به Statistics in the DHCPv4 Server \%<#\:dhcp4-stats> و Statistics in the DHCPv6 Server \%<#\:dhcp6-stats> مراجعه کنید. .sp برای استخراج داده‌ها از ماژول آمار، می‌توان از کانال کنترل استفاده کرد. برای جزئیات به Management API \%<#\:ctrl-channel> مراجعه کنید. بازیابی یک آمار منفرد یا همه آمارها، بازنشانی آمارها (یعنی تنظیم آن‌ها روی یک مقدار خنثی، معمولاً صفر)، یا حتی حذف کامل یک آمار مشخص یا تمام آمارها امکان‌پذیر است. برای فهرستی از دستورات مربوط به آمار به بخش Commands for Manipulating Statistics مراجعه کنید. .sp ابزارهای خارجی می‌توانند از آمارها برای نظارت بر Kea استفاده کنند. یک نمونه از چنین ابزارهایی Stork است. برای جزئیات درباره نحوه استفاده از آن و سایر منابع داده جهت بازیابی دوره‌ای آمارها برای کسب دید بهتر از سلامت و وضعیت عملیاتی Kea، به Monitoring Kea With Stork \%<#\:stork> مراجعه نمایید. .SS "چرخه حیات آمارها (Statistics Lifecycle)" .sp تمام آمارهای پشتیبانی‌شده توسط کارگزارهای Kea هنگام راه‌اندازی کارگزار مقداردهی اولیه می‌شوند و در پاسخ به دستوراتی مانند \fBstatistic\-get\-all\fP بازگردانده می‌شوند. آمارهای زمان اجرا مربوط به بسته‌های DHCP پردازش‌شده، در ابتدا روی ۰ تنظیم شده و هنگام راه‌اندازی مجدد کارگزار بازنشانی می‌گردند. .sp آمارهای مربوط به هر زیرشبکه (Per\-subnet) هنگام انجام پیکربندی مجدد، دوباره محاسبه می‌شوند. .sp به‌طور کلی، زمانی که یک آمار مقداردهی اولیه شد، تا زمانی که صراحتاً از طریق \fBstatistic\-remove\fP یا \fBstatistic\-remove\-all\fP حذف نشود، یا زمانی که کارگزار خاموش گردد، در مدیر (manager) نگهداری می‌شود. .sp حذف آماری که مکرراً به‌روزرسانی می‌شود منطقی نیست، زیرا با ثبت بعدی آن توسط کد کارگزار، دوباره اضافه خواهد شد. دستورات \fBstatistic\-remove\fP و \fBstatistic\-remove\-all\fP برای حذف آمارهایی در نظر گرفته شده‌اند که انتظار نمی‌رود در آینده نزدیک مشاهده شوند. برای نمونه، یک دستگاه با پیکربندی نادرست در شبکه ممکن است باعث شود کلاینت‌ها نشانی‌های تکراری را گزارش کنند، بنابراین کارگزار مقادیر رو به رشدی از \fBpkt4\-decline\-received\fP را گزارش خواهد داد. پس از یافتن مشکل و حذف دستگاه، مدیر سیستم ممکن است بخواهد آمار \fBpkt4\-decline\-received\fP را حذف کند تا دیگر گزارش نشود، مگر اینکه و تا زمانی که دوباره یک نشانی تکراری شناسایی گردد. .SS "دستورات دستکاری آمارها (Commands for Manipulating Statistics)" .sp چندین دستور تعریف شده است که می‌توان از آن‌ها برای دسترسی (\fB\-get\fP)، بازنشانی به صفر یا یک مقدار خنثی (\fB\-reset\fP)، یا حذف کامل یک آمار (\fB\-remove\fP) استفاده کرد. حد زمانی آمار (\fB\-sample\-age\-set\fP) و حد اندازه بر اساس تعداد (\fB\-sample\-count\-set\fP)، که کنترل می‌کنند نمونه‌های یک آمار معین چه مدت یا به چه تعداد نگهداری شوند، نیز قابل تغییر هستند. .sp تفاوت بین \fB\-reset\fP و \fB\-remove\fP تا حدی ظریف است. دستور \fB\-reset\fP مقدار آمار را روی صفر یا یک مقدار خنثی تنظیم می‌کند، به‌طوری که پس از این عملیات، آمار مقداری برابر با 0 (integer)، 0.0 (float)، 0h0m0s0us (duration)، یا \(dq\(dq (string) خواهد داشت. هنگام درخواست، آماری با مقادیر ذکرشده بازگردانده می‌شود. \fB\-remove\fP یک آمار را به‌طور کامل حذف می‌کند، به‌طوری که آمار دیگر گزارش نمی‌شود. با این حال، کد کارگزار در صورت وجود دلیلی برای ثبت، ممکن است مجدداً آن را اضافه کند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 بخش‌های زیر دستوراتی را شرح می‌دهند که می‌توانند به کارگزار ارسال شوند؛ این مثال‌ها تکه‌هایی از یک فایل پیکربندی نیستند. برای اطلاعات بیشتر درباره ارسال دستورات به Kea، به Management API \%<#\:ctrl-channel>\& مراجعه کنید. .UNINDENT .UNINDENT .SS "دستور \fBstatistic\-get\fP (The \fBstatistic\-get\fP Command)" .sp دستور \fBstatistic\-get\fP یک آمار منفرد را بازیابی می‌کند. این دستور یک پارامتر تک‌رشته‌ای به نام \fBname\fP می‌گیرد که نام آمار را مشخص می‌سازد. یک نمونه دستور می‌تواند مانند این باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-get\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqpkt4\-received\(dq } } .EE .UNINDENT .UNINDENT .sp کارگزار جزئیات آمار درخواست‌شده را بازمی‌گرداند؛ نتیجه 0 نشان‌دهنده موفقیت و مقدار پارامتر \fBarguments\fP همان آمار مشخص‌شده است. اگر آمار درخواست‌شده یافت نشود، پاسخ حاوی یک نگاشت خالی خواهد بود، یعنی فقط { } به‌عنوان آرگومان، اما کد وضعیت همچنان نشان‌دهنده موفقیت (0) است. .sp در اینجا یک نمونه پاسخ آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-get\(dq, \(dqarguments\(dq: { \(dqpkt4\-received\(dq: [ [ 125, \(dq2019\-07\-30 10:11:19.498739\(dq ], [ 100, \(dq2019\-07\-30 10:11:19.498662\(dq ] ] }, \(dqresult\(dq: 0 } .EE .UNINDENT .UNINDENT.SS دستور \fBstatistic\-reset\fP .sp دستور \fBstatistic\-reset\fP آمار مشخص‌شده را به مقدار خنثی آن تنظیم می‌کند: 0 برای عدد صحیح، 0.0 برای ممیز شناور، 0h0m0s0us برای بازه زمانی، و \(dq\(dq برای نوع رشته‌ای. این دستور یک پارامتر تک‌رشته‌ای به نام \fBname\fP می‌گیرد که نام آمار را مشخص می‌کند. یک نمونه دستور ممکن است بدین صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-reset\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqpkt4\-received\(dq } } .EE .UNINDENT .UNINDENT .sp اگر آمار مشخص‌شده یافت شود و بازنشانی با موفقیت انجام گیرد، کارساز پاسخی با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد پارامترهای خالی بازمی‌گرداند. در صورت بروز خطا (برای نمونه، آمار درخواستی یافت نشود)، کارساز کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد متن شامل شرح خطا خواهد بود. .SS دستور \fBstatistic\-remove\fP .sp دستور \fBstatistic\-remove\fP یک آمار را حذف می‌کند. این دستور یک پارامتر تک‌رشته‌ای به نام \fBname\fP می‌گیرد که نام آمار را مشخص می‌کند. یک نمونه دستور ممکن است بدین صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-remove\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqpkt4\-received\(dq } } .EE .UNINDENT .UNINDENT .sp اگر آمار مشخص‌شده یافت شود و حذف آن با موفقیت صورت گیرد، کارساز پاسخی با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد پارامترهای خالی بازمی‌گرداند. در صورت بروز خطا (برای نمونه، آمار درخواستی یافت نشود)، کارساز کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد متن شامل شرح خطا خواهد بود. .SS دستور \fBstatistic\-get\-all\fP .sp دستور \fBstatistic\-get\-all\fP تمامی آمارهای ثبت‌شده را بازیابی می‌کند. یک نمونه دستور ممکن است بدین صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-get\-all\(dq, \(dqarguments\(dq: { } } .EE .UNINDENT .UNINDENT .sp در اینجا یک نمونه پاسخ که تمامی آمارهای جمع‌آوری‌شده را بازمی‌گرداند آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-get\-all\(dq, \(dqarguments\(dq: { \(dqassigned\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836096\(dq ] ], \(dqcumulative\-assigned\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836166\(dq ] ], \(dqdeclined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836156\(dq ] ], \(dqpkt4\-ack\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616247\(dq ] ], \(dqpkt4\-ack\-sent\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616290\(dq ] ], \(dqpkt4\-admin\-filtered\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616352\(dq ] ], \(dqpkt4\-decline\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616296\(dq ] ], \(dqpkt4\-duplicate\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616352\(dq ] ], \(dqpkt4\-discover\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616303\(dq ] ], \(dqpkt4\-inform\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616308\(dq ] ], \(dqpkt4\-limit\-exceeded\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616310\(dq ] ], \(dqpkt4\-nak\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616312\(dq ] ], \(dqpkt4\-nak\-sent\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616314\(dq ] ], \(dqpkt4\-not\-for\-us\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616351\(dq ] ], \(dqpkt4\-offer\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616318\(dq ] ], \(dqpkt4\-offer\-sent\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616323\(dq ] ], \(dqpkt4\-parse\-failed\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616326\(dq ] ], \(dqpkt4\-processing\-failed\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616351\(dq ] ], \(dqpkt4\-queue\-full\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616352\(dq ] ], \(dqpkt4\-receive\-drop\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616330\(dq ] ], \(dqpkt4\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616335\(dq ] ], \(dqpkt4\-release\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616339\(dq ] ], \(dqpkt4\-request\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616343\(dq ] ], \(dqpkt4\-rfc\-violation\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616351\(dq ] ], \(dqpkt4\-sent\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616348\(dq ] ], \(dqpkt4\-service\-disabled\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616351\(dq ] ], \(dqpkt4\-unknown\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616354\(dq ] ], \(dqreclaimed\-declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836159\(dq ] ], \(dqreclaimed\-leases\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836163\(dq ] ], \(dqsubnet[1].assigned\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836173\(dq ] ], \(dqsubnet[1].cumulative\-assigned\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836098\(dq ] ], \(dqsubnet[1].declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836178\(dq ] ], \(dqsubnet[1].pool[0].assigned\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836205\(dq ] ], \(dqsubnet[1].pool[0].cumulative\-assigned\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836137\(dq ] ], \(dqsubnet[1].pool[0].declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836213\(dq ] ], \(dqsubnet[1].pool[0].reclaimed\-declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836225\(dq ] ], \(dqsubnet[1].pool[0].reclaimed\-leases\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836236\(dq ] ], \(dqsubnet[1].pool[0].total\-addresses\(dq: [ [ 11010049, \(dq2023\-06\-13 20:42:46.836128\(dq ] ], \(dqsubnet[1].reclaimed\-declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836186\(dq ] ], \(dqsubnet[1].reclaimed\-leases\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836194\(dq ] ], \(dqsubnet[1].total\-addresses\(dq: [ [ 11010049, \(dq2023\-06\-13 20:42:46.836083\(dq ] ], \(dqsubnet[1].v4\-lease\-reuses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836105\(dq ] ], \(dqsubnet[1].v4\-reservation\-conflicts\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836111\(dq ] ], \(dqv4\-allocation\-fail\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616358\(dq ] ], \(dqv4\-allocation\-fail\-classes\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616363\(dq ] ], \(dqv4\-allocation\-fail\-no\-pools\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616368\(dq ] ], \(dqv4\-allocation\-fail\-shared\-network\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616372\(dq ] ], \(dqv4\-allocation\-fail\-subnet\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616376\(dq ] ], \(dqv4\-lease\-reuses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616410\(dq ] ], \(dqv4\-reservation\-conflicts\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616412\(dq ] ] }, \(dqresult\(dq: 0 } .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-get\-all\(dq, \(dqarguments\(dq: { \(dqassigned\-nas\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196757\(dq ] ], \(dqassigned\-pds\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196757\(dq ] ], \(dqcumulative\-assigned\-nas\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196757\(dq ] ], \(dqcumulative\-assigned\-pds\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196758\(dq ] ], \(dqcumulative\-registered\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196758\(dq ] ], \(dqdeclined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196754\(dq ] ], \(dqpkt6\-addr\-reg\-inform\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177731\(dq ] ], \(dqpkt6\-addr\-reg\-reply\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177731\(dq ] ], \(dqpkt6\-addr\-reg\-reply\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177731\(dq ] ], \(dqpkt6\-admin\-filtered\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-advertise\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177731\(dq ] ], \(dqpkt6\-advertise\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177739\(dq ] ], \(dqpkt6\-decline\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177739\(dq ] ], \(dqpkt6\-dhcpv4\-query\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177740\(dq ] ], \(dqpkt6\-dhcpv4\-response\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177740\(dq ] ], \(dqpkt6\-dhcpv4\-response\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177741\(dq ] ], \(dqpkt6\-duplicate\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-infrequest\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177742\(dq ] ], \(dqpkt6\-limit\-exceeded\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177742\(dq ] ], \(dqpkt6\-not\-for\-us\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-parse\-failed\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177742\(dq ] ], \(dqpkt6\-processing\-failed\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-queue\-full\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-rebind\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177743\(dq ] ], \(dqpkt6\-receive\-drop\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177743\(dq ] ], \(dqpkt6\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177744\(dq ] ], \(dqpkt6\-release\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177744\(dq ] ], \(dqpkt6\-renew\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177745\(dq ] ], \(dqpkt6\-reply\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177745\(dq ] ], \(dqpkt6\-reply\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177746\(dq ] ], \(dqpkt6\-request\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-rfc\-violation\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-service\-disabled\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-solicit\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177748\(dq ] ], \(dqpkt6\-unknown\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177748\(dq ] ], \(dqreclaimed\-declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196755\(dq ] ], \(dqreclaimed\-leases\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196756\(dq ] ], \(dqsubnet[1].assigned\-nas\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196760\(dq ] ], \(dqsubnet[1].assigned\-pds\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196761\(dq ] ], \(dqsubnet[1].cumulative\-assigned\-nas\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196727\(dq ] ], \(dqsubnet[1].cumulative\-assigned\-pds\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196729\(dq ] ], \(dqsubnet[1].cumulative\-registered\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196727\(dq ] ], \(dqsubnet[1].declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196763\(dq ] ], \(dqsubnet[1].pd\-pool[0].assigned\-pds\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196785\(dq ] ], \(dqsubnet[1].pd\-pool[0].cumulative\-assigned\-pds\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196744\(dq ] ], \(dqsubnet[1].pd\-pool[0].reclaimed\-leases\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196789\(dq ] ], \(dqsubnet[1].pd\-pool[0].total\-pds\(dq: [ [ 256, \(dq2023\-06\-13 21:28:57.196741\(dq ] ], \(dqsubnet[1].pool[0].assigned\-nas\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196773\(dq ] ], \(dqsubnet[1].pool[0].cumulative\-assigned\-nas\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196739\(dq ] ], \(dqsubnet[1].pool[0].declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196775\(dq ] ], \(dqsubnet[1].pool[0].reclaimed\-declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196779\(dq ] ], \(dqsubnet[1].pool[0].reclaimed\-leases\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196783\(dq ] ], \(dqsubnet[1].pool[0].total\-nas\(dq: [ [ 281474976710656, \(dq2023\-06\-13 21:28:57.196736\(dq ] ], \(dqsubnet[1].reclaimed\-declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196766\(dq ] ], \(dqsubnet[1].reclaimed\-leases\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196770\(dq ] ], \(dqsubnet[1].registered\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196727\(dq ] ], \(dqsubnet[1].total\-nas\(dq: [ [ 281474976710656, \(dq2023\-06\-13 21:28:57.196720\(dq ] ], \(dqsubnet[1].total\-pds\(dq: [ [ 256, \(dq2023\-06\-13 21:28:57.196724\(dq ] ], \(dqsubnet[1].v6\-ia\-na\-lease\-reuses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196731\(dq ] ], \(dqsubnet[1].v6\-ia\-pd\-lease\-reuses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196733\(dq ] ], \(dqv6\-allocation\-fail\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177749\(dq ] ], \(dqv6\-allocation\-fail\-classes\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177755\(dq ] ], \(dqv6\-allocation\-fail\-no\-pools\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177756\(dq ] ], \(dqv6\-allocation\-fail\-shared\-network\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177756\(dq ] ], \(dqv6\-allocation\-fail\-subnet\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177757\(dq ] ], \(dqv6\-ia\-na\-lease\-reuses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177757\(dq ] ], \(dqv6\-ia\-pd\-lease\-reuses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177758\(dq ] ] }, \(dqresult\(dq: 0 } .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-get\-all\(dq, \(dqarguments\(dq: { \(dqncr\-error\(dq: [ [ 0, \(dq2023\-06\-13 21:42:54.627751\(dq ] ], \(dqncr\-invalid\(dq: [ [ 0, \(dq2023\-06\-13 21:42:54.627749\(dq ] ], \(dqncr\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:42:54.627737\(dq ] ], \(dqqueue\-mgr\-queue\-full\(dq: [ [ 0, \(dq2023\-06\-13 21:42:54.627737\(dq ] ], \(dqupdate\-error\(dq: [ [ 0, \(dq2023\-06\-13 21:42:54.627759\(dq ] ], \(dqupdate\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:42:54.627752\(dq ] ], \(dqupdate\-signed\(dq: [ [ 0, \(dq2023\-06\-13 21:42:54.627753\(dq ] ], \(dqupdate\-success\(dq: [ [ 0, \(dq2023\-06\-13 21:42:54.627755\(dq ] ], \(dqupdate\-timeout\(dq: [ [ 0, \(dq2023\-06\-13 21:42:54.627757\(dq ] ], \(dqupdate\-unsigned\(dq: [ [ 0, \(dq2023\-06\-13 21:42:54.627754\(dq ] ] }, \(dqresult\(dq: 0 } .EE .UNINDENT .UNINDENT.SS دستور \fBstatistic\-global\-get\-all\fP .sp دستور \fBstatistic\-global\-get\-all\fP تمام آمارهای سراسری ثبت‌شده را بازیابی می‌کند (مشابه \fBstatistic\-get\-all\fP، اما بدون آمارهای زیرشبکه). یک دستور نمونه می‌تواند به این صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-global\-get\-all\(dq, \(dqarguments\(dq: { } } .EE .UNINDENT .UNINDENT .sp در ادامه یک نمونه پاسخ که تمام آمارهای جمع‌آوری‌شده را بازمی‌گرداند آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-global\-get\-all\(dq, \(dqarguments\(dq: { \(dqassigned\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836096\(dq ] ], \(dqcumulative\-assigned\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836166\(dq ] ], \(dqdeclined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836156\(dq ] ], \(dqpkt4\-ack\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616247\(dq ] ], \(dqpkt4\-ack\-sent\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616290\(dq ] ], \(dqpkt4\-admin\-filtered\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616352\(dq ] ], \(dqpkt4\-decline\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616296\(dq ] ], \(dqpkt4\-discover\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616303\(dq ] ], \(dqpkt4\-duplicate\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616352\(dq ] ], \(dqpkt4\-inform\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616308\(dq ] ], \(dqpkt4\-limit\-exceeded\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616310\(dq ] ], \(dqpkt4\-nak\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616312\(dq ] ], \(dqpkt4\-nak\-sent\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616314\(dq ] ], \(dqpkt4\-not\-for\-us\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616351\(dq ] ], \(dqpkt4\-offer\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616318\(dq ] ], \(dqpkt4\-offer\-sent\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616323\(dq ] ], \(dqpkt4\-parse\-failed\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616326\(dq ] ], \(dqpkt4\-processing\-failed\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616351\(dq ] ], \(dqpkt4\-queue\-full\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616352\(dq ] ], \(dqpkt4\-receive\-drop\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616330\(dq ] ], \(dqpkt4\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616335\(dq ] ], \(dqpkt4\-release\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616339\(dq ] ], \(dqpkt4\-request\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616343\(dq ] ], \(dqpkt4\-rfc\-violation\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616351\(dq ] ], \(dqpkt4\-sent\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616348\(dq ] ], \(dqpkt4\-service\-disabled\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616351\(dq ] ], \(dqpkt4\-unknown\-received\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616354\(dq ] ], \(dqreclaimed\-declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836159\(dq ] ], \(dqreclaimed\-leases\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.836163\(dq ] ], \(dqv4\-allocation\-fail\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616358\(dq ] ], \(dqv4\-allocation\-fail\-classes\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616363\(dq ] ], \(dqv4\-allocation\-fail\-no\-pools\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616368\(dq ] ], \(dqv4\-allocation\-fail\-shared\-network\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616372\(dq ] ], \(dqv4\-allocation\-fail\-subnet\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616376\(dq ] ], \(dqv4\-lease\-reuses\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616410\(dq ] ], \(dqv4\-reservation\-conflicts\(dq: [ [ 0, \(dq2023\-06\-13 20:42:46.616412\(dq ] ] }, \(dqresult\(dq: 0 } .EE .UNINDENT .UNINDENT .sp یا .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-global\-get\-all\(dq, \(dqarguments\(dq: { \(dqassigned\-nas\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196757\(dq ] ], \(dqassigned\-pds\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196757\(dq ] ], \(dqcumulative\-assigned\-nas\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196757\(dq ] ], \(dqcumulative\-assigned\-pds\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196758\(dq ] ], \(dqcumulative\-registered\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196758\(dq ] ], \(dqdeclined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196754\(dq ] ], \(dqpkt6\-addr\-reg\-inform\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177731\(dq ] ], \(dqpkt6\-addr\-reg\-reply\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177731\(dq ] ], \(dqpkt6\-addr\-reg\-reply\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177731\(dq ] ], \(dqpkt6\-admin\-filtered\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-advertise\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177731\(dq ] ], \(dqpkt6\-advertise\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177739\(dq ] ], \(dqpkt6\-decline\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177739\(dq ] ], \(dqpkt6\-dhcpv4\-query\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177740\(dq ] ], \(dqpkt6\-dhcpv4\-response\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177740\(dq ] ], \(dqpkt6\-dhcpv4\-response\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177741\(dq ] ], \(dqpkt6\-duplicate\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-infrequest\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177742\(dq ] ], \(dqpkt6\-limit\-exceeded\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177742\(dq ] ], \(dqpkt6\-not\-for\-us\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-parse\-failed\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177742\(dq ] ], \(dqpkt6\-processing\-failed\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-queue\-full\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-rebind\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177743\(dq ] ], \(dqpkt6\-receive\-drop\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177743\(dq ] ], \(dqpkt6\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177744\(dq ] ], \(dqpkt6\-release\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177744\(dq ] ], \(dqpkt6\-renew\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177745\(dq ] ], \(dqpkt6\-reply\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177745\(dq ] ], \(dqpkt6\-reply\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177746\(dq ] ], \(dqpkt6\-request\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-rfc\-violation\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-sent\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-service\-disabled\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177747\(dq ] ], \(dqpkt6\-solicit\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177748\(dq ] ], \(dqpkt6\-unknown\-received\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177748\(dq ] ], \(dqreclaimed\-declined\-addresses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196755\(dq ] ], \(dqreclaimed\-leases\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.196756\(dq ] ], \(dqv6\-allocation\-fail\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177749\(dq ] ], \(dqv6\-allocation\-fail\-classes\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177755\(dq ] ], \(dqv6\-allocation\-fail\-no\-pools\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177756\(dq ] ], \(dqv6\-allocation\-fail\-shared\-network\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177756\(dq ] ], \(dqv6\-allocation\-fail\-subnet\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177757\(dq ] ], \(dqv6\-ia\-na\-lease\-reuses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177757\(dq ] ], \(dqv6\-ia\-pd\-lease\-reuses\(dq: [ [ 0, \(dq2023\-06\-13 21:28:57.177758\(dq ] ] }, \(dqresult\(dq: 0 } .EE .UNINDENT .UNINDENT.SS دستور \fBstatistic\-reset\-all\fP .sp دستور \fBstatistic\-reset\fP تمام آمارها را به مقادیر خنثای آن‌ها بازنشانی می‌کند: 0 برای عدد صحیح (integer)، 0.0 برای ممیز شناور (float)، 0h0m0s0us برای بازه زمانی، و \(dq\(dq برای نوع رشته (string). یک نمونه دستور می‌تواند به این صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-reset\-all\(dq, \(dqarguments\(dq: { } } .EE .UNINDENT .UNINDENT .sp اگر عملیات موفقیت‌آمیز باشد، سرور با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد parameters خالی پاسخ می‌دهد. در صورت بروز خطا، سرور یک کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود. .SS دستور \fBstatistic\-remove\-all\fP .sp دستور \fBstatistic\-remove\-all\fP برای حذف تمامی آمارها تلاش می‌کند. یک نمونه دستور می‌تواند به این صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-remove\-all\(dq, \(dqarguments\(dq: { } } .EE .UNINDENT .UNINDENT .sp اگر حذف تمامی آمارها موفقیت‌آمیز باشد، سرور با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد parameters خالی پاسخ می‌دهد. در صورت بروز خطا، سرور یک کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود. .SS دستور \fBstatistic\-sample\-age\-set\fP .sp دستور \fBstatistic\-sample\-age\-set\fP یک محدودیت زمانی بر روی نمونه‌های یک آماره مشخص تنظیم می‌کند. این دستور دو پارامتر دریافت می‌کند: یک رشته به نام \fBname\fP که نام آماره را مشخص می‌کند، و یک مقدار عدد صحیح به نام \fBduration\fP که محدودیت زمانی آماره مشخص‌شده را بر حسب ثانیه تعیین می‌کند. یک نمونه دستور می‌تواند به این صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-sample\-age\-set\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqpkt4\-received\(dq, \(dqduration\(dq: 1245 } } .EE .UNINDENT .UNINDENT .sp اگر دستور موفقیت‌آمیز باشد، سرور با وضعیت 0 به نشانه موفقیت و یک فیلد parameters خالی پاسخ می‌دهد. در صورت بروز خطا (مانند پیدا نشدن آماره درخواستی)، سرور کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود. .SS دستور \fBstatistic\-sample\-age\-set\-all\fP .sp دستور \fBstatistic\-sample\-age\-set\-all\fP محدودیت‌های مبتنی بر زمان را بر روی نمونه‌های تمامی آمارها تنظیم می‌کند. این دستور یک پارامتر عدد صحیح به نام \fBduration\fP دریافت می‌کند که محدودیت زمانی آماره را بر حسب ثانیه تعیین می‌کند. یک نمونه دستور می‌تواند به این صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-sample\-age\-set\-all\(dq, \(dqarguments\(dq: { \(dqduration\(dq: 1245 } } .EE .UNINDENT .UNINDENT .sp اگر دستور موفقیت‌آمیز باشد، سرور با وضعیت 0 به نشانه موفقیت و یک فیلد parameters خالی پاسخ می‌دهد. در صورت بروز خطا، سرور یک کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود. .SS دستور \fBstatistic\-sample\-count\-set\fP .sp دستور \fBstatistic\-sample\-count\-set\fP یک محدودیت مبتنی بر اندازه (تعداد) بر روی نمونه‌های یک آماره مشخص تنظیم می‌کند. یک نمونه دستور می‌تواند به این صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-sample\-count\-set\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dqpkt4\-received\(dq, \(dqmax\-samples\(dq: 100 } } .EE .UNINDENT .UNINDENT .sp اگر دستور موفقیت‌آمیز باشد، سرور با وضعیت 0 به نشانه موفقیت و یک فیلد parameters خالی پاسخ می‌دهد. در صورت بروز خطا (مانند پیدا نشدن آماره درخواستی)، سرور کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود..SS دستور \fBstatistic\-sample\-count\-set\-all\fP .sp دستور \fBstatistic\-sample\-count\-set\-all\fP محدودیت‌های مبتنی بر اندازه را بر روی نمونه‌های تمامی آمارها تنظیم می‌کند. یک نمونه از این دستور می‌تواند به شکل زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqstatistic\-sample\-count\-set\-all\(dq, \(dqarguments\(dq: { \(dqmax\-samples\(dq: 100 } } .EE .UNINDENT .UNINDENT .sp اگر دستور با موفقیت اجرا شود، سرور با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد خالی parameters پاسخ می‌دهد. در صورت بروز خطا، سرور یک کد وضعیت 1 (خطا) بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود. .SS سری‌های زمانی (Time Series) .sp در برخی آمارها، یک نقطه داده منفرد و جداگانه ممکن است مفید باشد. با این حال، برخی از آمارها، مانند اندازه بسته‌های دریافتی، زمان پردازش بسته، یا تعداد پرس‌وجوهای پایگاه داده مورد نیاز برای پردازش یک بسته، تجمعی نیستند و نگهداری چندین نقطه داده، احتمالاً برای انجام تحلیل‌های آماری در آینده، مفید خواهد بود. .sp هر یک از آمارهای Kea تا ۲۰ نقطه داده را در خود نگه می‌دارند؛ تعیین چنین محدودیتی از رشد نامحدود حافظه جلوگیری می‌کند. دو روش برای تعیین محدودیت‌ها وجود دارد: بر پایه زمان (برای مثال، نگهداری نمونه‌های ۵ دقیقه گذشته) و بر پایه اندازه. محدودیت بر پایه اندازه را می‌توان با استفاده از یکی از دو دستور تغییر داد: \fBstatistic\-sample\-count\-set\fP، برای تعیین محدودیت اندازه برای یک آمار منفرد، و \fBstatistic\-sample\-count\-set\-all\fP، برای تنظیم محدودیت‌های مبتنی بر اندازه برای تمامی آمارها. برای تنظیم محدودیت‌های بر پایه زمان برای یک آمار مشخص، از \fBstatistic\-sample\-age\-set\fP استفاده کنید؛ از \fBstatistic\-sample\-age\-set\-all\fP نیز برای تعیین محدودیت‌های بر پایه زمان برای تمامی آمارها استفاده نمایید. برای هر آمار معین تنها یک نوع محدودیت می‌تواند فعال باشد؛ فضای ذخیره‌سازی یا بر پایه زمان محدود می‌شود یا اندازه، نه هر دو. .SH "رابط مدیریتی (MANAGEMENT API)" .sp یک رویکرد سنتی در پیکربندی دیمن‌ها (daemons) فرض می‌کند که پیکربندی سرور در فایل‌های پیکربندی ذخیره شده است و با تغییر پیکربندی، دیمن مجدداً راه‌اندازی می‌شود. این رویکرد این عیب عمده را دارد که دوره‌هایی از توقف سرویس‌دهی (downtime) را به وجود می‌آورد که در آن ترافیک کلاینت‌ها رسیدگی نمی‌شود. ریسک دیگر این است که اگر پیکربندی جدید به هر دلیلی نامعتبر باشد، ممکن است سرور از راه‌اندازی خودداری کند، که این موضوع زمان خاموشی را تا رفع مشکل بیشتر افزایش می‌دهد. .sp برای جلوگیری از چنین مشکلاتی، سرورهای DHCPv4، DHCPv6 و D2 در Kea از سازوکاری پشتیبانی می‌کنند که امکان پیکربندی مجدد به‌صورت برخط را بدون نیاز به خاموش کردن سرور فراهم می‌سازد. به سرورها می‌توان دستور داد تا سوکت‌های کنترلی را که یک کانال ارتباطی است باز کنند. سرور قادر است دستورها را روی این کانال دریافت کرده، آن‌ها را اجرا کند و وضعیت را گزارش دهد. .sp سرورهای DHCPv4، DHCPv6 و D2 دستورها را از طریق سوکت‌های دامنه یونیکس (UNIX domain sockets) دریافت می‌کنند. برای جزئیات بیشتر در مورد نحوه پیکربندی این سوکت‌ها، بخش‌های UNIX Control Socket \%<#\:dhcp4-unix-ctrl-channel>، UNIX Control Socket \%<#\:dhcp6-unix-ctrl-channel> و UNIX Control Socket \%<#\:d2-unix-ctrl-channel>\& را ببینید. در حالی که امکان کنترل مستقیم سرورها با استفاده از سوکت‌های دامنه یونیکس وجود دارد، اما این کار مستلزم آن است که کلاینت کنترل‌کننده روی همان ماشین سرور در حال اجرا باشد. معمولاً از SSH برای اتصال از راه دور به ماشین تحت کنترل استفاده می‌شود. .sp مدیران شبکه معمولاً ترجیح می‌دهند به جای استفاده مستقیم از سوکت‌های دامنه یونیکس، از نوعی RESTful API برای کنترل سرورها بهره ببرند. Kea نسخه ۳ سرورها را با سوکت‌های HTTP/HTTPS گسترش می‌دهد. برای جزئیات درباره نحوه پیکربندی این سوکت‌ها، بخش‌های HTTP/HTTPS Control Socket \%<#\:dhcp4-http-ctrl-channel>، HTTP/HTTPS Control Socket \%<#\:dhcp6-http-ctrl-channel> و HTTP/HTTPS Control Socket \%<#\:d2-http-ctrl-channel>\& را ببینید. .sp اتصال‌های کنترلی بر روی هر دو سوکت‌ HTTP و دامنه یونیکس با زمان‌های انتظار (timeout) محافظت می‌شوند. مقدار زمان انتظار روی ۱۰ ثانیه تنظیم شده و غیرقابل پیکربندی است. .sp این API می‌تواند توسط ابزارهای خارجی برای مدیریت و پایش عملکرد Kea مورد استفاده قرار گیرد. نمونه‌ای از این ابزارهای نظارتی، ISC Stork است. برای جزئیات، بخش Monitoring Kea With Stork \%<#\:stork>\& را ببینید. .SS ساختار داده‌ها (Data Syntax) .sp ارتباط از طریق کانال کنترلی با استفاده از ساختارهای JSON انجام می‌شود. در صورت پیکربندی، Kea یک سوکت باز کرده و به اتصال‌های ورودی گوش می‌دهد. فرآیندی که به این سوکت متصل می‌شود باید دستورهای JSON را با ساختاری مانند زیر ارسال کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqfoo\(dq, \(dqarguments\(dq: { \(dqparam1\(dq: \(dqvalue1\(dq, \(dqparam2\(dq: \(dqvalue2\(dq, ... } } .EE .UNINDENT .UNINDENT .sp همان دستور هنگامی که از طریق رابط RESTful به سرور ارسال می‌شود دارای ساختار زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX POST / HTTP/1.1\er\en Content\-Type: application/json\er\en Content\-Length: 147\er\en\er\en { \(dqcommand\(dq: \(dqfoo\(dq, \(dqarguments\(dq: { \(dqparam1\(dq: \(dqvalue1\(dq, \(dqparam2\(dq: \(dqvalue2\(dq, ... } } .EE .UNINDENT .UNINDENT .sp پارامتر \fBcommand\fP حاوی نام دستوری است که باید اجرا شود و وجود آن اجباری است. نگاشت \fBarguments\fP شامل پارامترهای مورد نیاز برای اجرای دستور داده‌شده است. محتوا و قالب دقیق این نگاشت مختص هر دستور می‌باشد. .sp سروری که دستور ورودی را پردازش می‌کند، پاسخی به این شکل ارسال می‌نماید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, // 0|1|2|3|4 \(dqtext\(dq: \(dqtextual description\(dq, \(dqarguments\(dq: { \(dqargument1\(dq: \(dqvalue1\(dq, \(dqargument2\(dq: \(dqvalue2\(dq, ... } } .EE .UNINDENT .UNINDENT .sp مقدار \fBresult\fP یک کد وضعیت است که نتیجه دستور را نشان می‌دهد. کدهای وضعیت عمومی زیر در حال حاضر پشتیبانی می‌شوند: .INDENT 0.0 .IP \(bu 2 \fB0\fP \- دستور با موفقیت پردازش شده است. .IP \(bu 2 \fB1\fP \- در حین پردازش دستور، یک خطا یا شکست عمومی رخ داده است. .IP \(bu 2 \fB2\fP \- دستور مشخص‌شده توسط سرور دریافت‌کننده پشتیبانی نمی‌شود. .IP \(bu 2 \fB3\fP \- عملیات درخواستی انجام شده است اما منبع درخواستی پیدا نشد. این کد وضعیت زمانی بازگردانده می‌شود که یک دستور هیچ منبعی را بازنگرداند یا بر هیچ منبعی تأثیر نگذارد. .IP \(bu 2 \fB4\fP \- دستور خوش‌ساخت پردازش شده است اما تغییرات درخواستی اعمال نشد، زیرا با وضعیت سرور یا درک آن از پیکربندی در تضاد بود. .IP \(bu 2 \fB5\fP \- دستور پردازش‌شده با شکست مواجه شد و پیکربندی به طور جزئی تغییر یافته است. سازوکار بازگردانی (rollback) قادر به بازگرداندن پیکربندی قبلی نبود. .UNINDENT .sp برای نمونه، یک دستور با ساختار صحیح که زیرشبکه‌ای موجود در پیکربندی سرور را درخواست می‌کند، نتیجه 0 را بازمی‌گرداند. اگر سرور با وضعیت خطا مواجه شود، 1 را بازمی‌گرداند. اگر دستور یک زیرشبکه IPv6 را درخواست کند، اما به سرور DHCPv4 ارسال شده باشد، نتیجه 2 خواهد بود. اگر پرس‌وجو به دنبال زیرشبکه‌ای با \fBsubnet\-id\fP باشد که تطابقی دارد، نتیجه 3 است. اگر دستور تلاش کند یک اجاره (lease) را به‌روزرسانی کند اما \fBsubnet\-id\fP مشخص‌شده با شناسه موجود در پیکربندی سرور مطابقت نداشته باشد، نتیجه 4 خواهد بود. .sp کتابخانه‌های هوک (Hook libraries) گاهی اوقات می‌توانند کدهای وضعیت بیشتری متناسب با شرایط استفاده خود بازگردانند. .sp فیلد \fBtext\fP معمولاً هنگامی ظاهر می‌شود که نتیجه غیرصفر باشد و حاوی شرح خطای رخ‌داده است، اما اغلب برای نتایج موفقیت‌آمیز نیز نمایش می‌یابد. متن دقیق مختص هر دستور است، اما به‌طور کلی از متن واضح انگلیسی برای توصیف نتیجه دستور استفاده می‌کند. نگاشت \fBarguments\fP شامل مقادیر داده‌های اضافی بازگردانده‌شده توسط سرور است که مختص دستور صادرشده می‌باشد. ممکن است این نگاشت وجود داشته باشد، اما این به دستور مربوطه بستگی دارد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 1.9.7 Kea، همانند فایل پیکربندی، امکان قرار دادن کامنت در دستورها نیز وجود دارد. برای نمونه: .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqfoo\(dq, # command arguments are here. \(dqarguments\(dq: { \(dqparam1\(dq: \(dqvalue1\(dq, ... /* \(dqparam2\(dq: \(dqvalue2\(dq, ... */ } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 2.7.5 Kea، امکان تعیین سرآیندهای (headers) اضافی HTTP که به پاسخ‌های HTTP افزوده می‌شوند، وجود دارد. هر سرآیند با نام و مقدار خود و به‌صورت اختیاری یک زمینه کاربری (user context) مشخص می‌شود. برای نمونه: .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqhttp\-headers\(dq: [ { \(dqname\(dq: \(dqStrict\-Transport\-Security\(dq, \(dqvalue\(dq: \(dqmax\-age=31536000\(dq } ], ... } .EE .UNINDENT .UNINDENT .sp یک سرآیند HSTS اضافه می‌کند که اعلام می‌دارد HTTPS (در مقایسه با HTTP) باید به مدت یک سال استفاده شود..SS قالب پاسخ دستور HTTP .sp برای سازگاری با نسخه‌های پیشین با Control Agent منسوخ‌شده (حذف‌شده)، پاسخ‌های دریافتی از طریق HTTP همواره درون یک آرایه (فهرست JSON) تک‌عضوی قرار می‌گیرند. .sp برای نمونه، پاسخ برای یک دستور ارسال‌شده ساختاری به شرح زیر خواهد داشت: .INDENT 0.0 .INDENT 3.5 .sp .EX [ { \(dqresult\(dq: 0, // 0|1|2|3|4 \(dqtext\(dq: \(dqtextual description\(dq, \(dqarguments\(dq: { \(dqargument1\(dq: \(dqvalue1\(dq, \(dqargument2\(dq: \(dqvalue2\(dq, ... } } ] .EE .UNINDENT .UNINDENT .sp یک استثنا برای این مورد، خطاهای احراز هویت یا تعیین سطح دسترسی هستند که باعث می‌شوند سرور دستور را به طور کامل رد کند. پاسخ به چنین خطایی در قالب یک مدخل تکی (نگاشت JSON) به شرح زیر ساختاردهی می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 403, \(dqtext\(dq: \(dqForbidden\(dq } .EE .UNINDENT .UNINDENT .sp این نوع خطاها روی سیستم‌هایی که برای احراز هویت اولیه (basic authentication) پیکربندی شده‌اند یا سرورهایی که \fBlibdhcp_rbac.so\fP \%<#\:std-ischooklib-libdhcp_rbac\:.so>\& را بارگذاری می‌کنند، امکان‌پذیر است. .SS استفاده از کانال کنترل .sp ساده‌ترین راه برای شروع تعامل با API کنترل، استفاده از ابزارهای متداول UNIX/Linux مانند \fBsocat\fP و \fBcurl\fP است\&. .sp به منظور کنترل سرویس مورد نظر Kea از طریق یک UNIX domain socket، از \fBsocat\fP در حالت تعاملی به شرح زیر استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ socat UNIX:/path/to/the/kea/socket \- .EE .UNINDENT .UNINDENT .sp یا در حالت دسته‌ای (batch mode)، گزینه \(dqignoreeof\(dq را همانند زیر درج کنید تا اطمینان حاصل شود \fBsocat\fP به اندازه کافی منتظر پاسخ سرور می‌ماند: .INDENT 0.0 .INDENT 3.5 .sp .EX $ echo \(dq{ some command...}\(dq | socat UNIX:/path/to/the/kea/socket \-,ignoreeof .EE .UNINDENT .UNINDENT .sp که در آن \fB/path/to/the/kea/socket\fP مسیری است که در پارامتر \fBDhcp4/control\-socket/socket\-name\fP در فایل پیکربندی Kea مشخص شده است. متن ارسال‌شده به \fBsocat\fP به Kea فرستاده می‌شود و پاسخ‌های دریافتی از Kea در خروجی استاندارد چاپ می‌شوند. این روش به طور مستقیم با سرور مورد نظر ارتباط برقرار می‌کند. .sp همچنین باز کردن برنامه‌نویسی‌شده‌ی یک سوکت UNIX آسان است. نمونه‌ای از یک کلاینت ساده که به زبان C نوشته شده است در Kea Developer\(aqs Guide، در فصل Control Channel Overview و در بخش Using Control Channel \% در دسترس است. .sp برای استفاده از RESTful API نرم‌افزار Kea با \fBcurl\fP، دستور زیر را به کار ببرید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ curl \-X POST \-H \(dqContent\-Type: application/json\(dq \-d \(aq{ \(dqcommand\(dq: \(dqconfig\-get\(dq }\(aq http://kea.example.org:8000 .EE .UNINDENT .UNINDENT .sp این دستور فرض می‌کند که سرور روی میزبان \fBkea.example.org\fP در حال اجرا بوده و سرویس RESTful را روی درگاه 8000 اجرا می‌کند. .SS دستورهای پشتیبانی‌شده توسط هر دو سرور DHCPv4 و DHCPv6 .SS دستور \fBbuild\-report\fP .sp دستور \fBbuild\-report\fP همان چیزی را که آرگومان خط فرمان \fB\-W\fP نمایش می‌دهد روی کانال کنترل بازمی‌گرداند؛ یعنی محتوای تعبیه‌شده در فایل \fBconfig.report\fP. این دستور هیچ پارامتری دریافت نمی‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqbuild\-report\(dq } .EE .UNINDENT .UNINDENT .SS دستور \fBconfig\-get\fP .sp دستور \fBconfig\-get\fP پیکربندی فعلی مورد استفاده توسط سرور را بازیابی می‌کند. این دستور هیچ پارامتری دریافت نمی‌کند. پیکربندی بازگردانده‌شده تقریباً معادل پیکربندی است که با استفاده از گزینه خط فرمان \fB\-c\fP در زمان راه‌اندازی سرور بارگذاری شده بود، یا بعداً با استفاده از دستور \fBconfig\-set\fP تنظیم شده است. با این حال، ممکن است تفاوت‌های خاصی وجود داشته باشد، زیرا کامنت‌ها نگهداری نمی‌شوند. اگر در پیکربندی اصلی از گنجاندن فایل (file inclusion) استفاده شده باشد، پیکربندی بازگردانده‌شده شامل تمام پارامترها از همه فایل‌های گنجانده‌شده خواهد بود. در Kea 2.4.0 و نسخه‌های بعدی، پاسخ موفقیت‌آمیز همچنین حاوی یک خلاصه (digest) از نوع SHA\-256 است که می‌توان از آن برای تشخیص آسان تغییر پیکربندی استفاده کرد. .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 پیکربندی بازگردانده‌شده پنهان‌سازی (redact) نمی‌شود؛ یعنی اگر گذرواژه‌های پایگاه داده در پیکربندی اصلی مشخص شده باشند، به صورت متن خام (plain text) خواهند بود. باید دقت شود که کانال دستور در دسترس کاربران بدون امتیاز قرار نگیرد. .UNINDENT .UNINDENT .sp یک نمونه فراخوانی دستور به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqconfig\-get\(dq } .EE .UNINDENT .UNINDENT.SS دستور \fBconfig\-hash\-get\fP .sp دستور \fBconfig\-hash\-get\fP هش SHA\-256 پیکربندی فعلی مورد استفاده توسط کارگزار را بازیابی می‌کند. این دستور هیچ پارامتری دریافت نمی‌کند. هش بازگردانده‌شده می‌تواند برای تشخیص تغییرات پیکربندی استفاده شود. .sp نمونه‌ای از فراخوانی دستور به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqconfig\-hash\-get\(dq } .EE .UNINDENT .UNINDENT .sp و پاسخ کارگزار: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqarguments\(dq: { \(dqhash\(dq: \(dq5C3C90EF7035249E2FF74D003C19F34EE0B83A3D329E741B52B2EF95A2C9CC5C\(dq } } .EE .UNINDENT .UNINDENT .sp در Kea نسخه 2.4.0 و بالاتر، دستورهای \fBconfig\-set\fP و \fBconfig\-get\fP نیز هش SHA\-256 پیکربندی جدید یا فعلی را برمی‌گردانند. این ویژگی می‌تواند برای تشخیص اینکه آیا پیکربندی تغییر کرده است یا خیر استفاده شود. .SS دستور \fBconfig\-reload\fP .sp دستور \fBconfig\-reload\fP به Kea فرمان می‌دهد که فایل پیکربندی قبلی را دوباره بارگذاری کند. این عملیات در صورتی مفید است که فایل پیکربندی توسط یک منبع خارجی تغییر کرده باشد؛ برای مثال، یک مدیر سیستم می‌تواند فایل پیکربندی را دستکاری کند و از این دستور برای واداشتن Kea به اعمال تغییرات استفاده نماید. .sp هنگام استفاده از این دستور همراه با دستور \fBconfig\-set\fP باید احتیاط کرد. Kea مکان فایل پیکربندی را که با آن راه‌اندازی شده بود به خاطر می‌سپارد، و این پیکربندی می‌تواند از طریق دستور \fBconfig\-set\fP دچار تغییرات چشمگیری شده باشد. هنگامی که \fBconfig\-reload\fP پس از \fBconfig\-set\fP صادر شود، Kea تلاش می‌کند پیکربندی اولیه خود را دوباره از فایل بارگذاری کند، که در نتیجه آن ممکن است تمام تغییرات اعمال‌شده از طریق \fBconfig\-set\fP یا سایر دستورها از دست برود. .sp دستور \fBconfig\-reload\fP هیچ پارامتری دریافت نمی‌کند. نمونه‌ای از فراخوانی دستور به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqconfig\-reload\(dq } .EE .UNINDENT .UNINDENT .sp اگر فایل پیکربندی نادرست باشد، بارگذاری مجدد آن می‌تواند منجر به بروز خطایی شود که کارگزار را در وضعیتی غیرقابل استفاده رها می‌کند. برای یادگیری نحوه بازیابی از وضعیت کارگزار از کار افتاده، به بخش دستور config\-set مراجعه کنید. .SS دستور \fBconfig\-test\fP .sp دستور \fBconfig\-test\fP به کارگزار فرمان می‌دهد بررسی کند که آیا پیکربندی جدید ارائه‌شده در آرگومان‌های دستور قابل بارگذاری است یا خیر. انتظار می‌رود پیکربندی ارائه‌شده، پیکربندی کامل کارگزار مورد نظر به همراه پیکربندی اختیاری ثبات وقایع (logger) باشد. پیکربندی تا حد امکان بدون تلاش واقعی کارگزار برای بارگذاری آن اعتبارسنجی (sanity\-check) می‌شود؛ با این حال ممکن است پیکربندی‌ای که این دستور را با موفقیت پشت سر می‌گذارد، همچنان در دستور \fBconfig\-set\fP یا هنگام راه‌اندازی با خطا مواجه شود. ساختار دستور به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqconfig\-test\(dq, \(dqarguments\(dq: { \(dq\(dq: { } } } .EE .UNINDENT .UNINDENT .sp که در آن نام مؤلفه پیکربندی برای یک کارگزار معین، مانند \(dqDhcp4\(dq یا \(dqDhcp6\(dq است. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqconfig\-test\(dq, \(dqarguments\(dq: { \(dqDhcp6\(dq: { ... } } } .EE .UNINDENT .UNINDENT .sp پاسخ کارگزار شامل یک کد عددی به نام \fBresult\fP (صفر برای موفقیت، غیر صفر در صورت شکست)، و یک رشته به نام \fBtext\fP است که نتیجه را شرح می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqConfiguration seems sane...\(dq } یا { \(dqresult\(dq: 1, \(dqtext\(dq: \(dqunsupported parameter: BOGUS (:16:26)\(dq } .EE .UNINDENT .UNINDENT.SS دستور \fBconfig\-write\fP .sp دستور \fBconfig\-write\fP به کارساز Kea اعلام می‌کند که پیکربندی فعلی خود را درون فایلی روی دیسک بنویسد. این دستور یک آرگومان اختیاری به نام \(dqfilename\(dq می‌پذیرد که نام فایل مقصد برای نوشتن پیکربندی را مشخص می‌کند. در صورت عدم تعیین، از نام استفاده‌شده در هنگام راه‌اندازی Kea (که به عنوان آرگومان \fB\-c\fP داده شده است) استفاده می‌شود. اگر یک مسیر نسبی تعیین شود، Kea فایل‌های خود را فقط در دایرکتوری محل اجرای خود می‌نویسد. .sp یک نمونه از فراخوانی دستور به شکل زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqconfig\-write\(dq, \(dqarguments\(dq: { \(dqfilename\(dq: \(dqconfig\-modified\-2017\-03\-15.json\(dq } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 2.7.9 Kea به بعد، فایل پیکربندی تنها می‌تواند در همان دایرکتوری فایل پیکربندی اولیه استفاده‌شده هنگام راه‌اندازی Kea (که به عنوان آرگومان \fB\-c\fP داده شده است) نوشته شود. .UNINDENT .UNINDENT .SS دستور \fBleases\-reclaim\fP .sp دستور \fBleases\-reclaim\fP به کارساز دستور می‌دهد که تمام اجاره‌های منقضی‌شده را فوراً بازپس‌گیری کند. این دستور ساختار نحوی JSON زیر را دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqleases\-reclaim\(dq, \(dqarguments\(dq: { \(dqremove\(dq: true } } .EE .UNINDENT .UNINDENT .sp پارامتر بولی \fBremove\fP اجباری است و مشخص می‌کند که آیا اجاره‌های بازپس‌گرفته‌شده باید از پایگاه‌داده اجاره‌ها حذف شوند (در صورت \fBtrue\fP)، یا در وضعیت \fBexpired\-reclaimed\fP باقی بمانند (در صورت \fBfalse\fP). حالت دوم قابلیت وابستگی اجاره (lease affinity) را تسهیل می‌کند؛ یعنی امکان تخصیص مجدد یک اجاره منقضی‌شده به یک کلاینت بازگشتی که پیش‌تر از آن اجاره استفاده می‌کرده است. برای جزئیات به Configuring Lease Affinity \%<#\:lease-affinity> مراجعه کنید. همچنین، برای اطلاعات عمومی درباره پردازش اجاره‌های منقضی‌شده (بازپس‌گیری اجاره)، به Lease Reclamation \%<#\:lease-reclamation> مراجعه نمایید. .SS دستور \fBinterface\-add\fP .sp دستور \fBinterface\-add\fP فهرست رابط‌های استفاده‌شده برای پردازش ترافیک DHCP را به‌روزرسانی می‌کند. این دستور فهرستی از رابط‌ها را به همراه آدرس‌های مربوطه (در صورت تعیین) که کارساز باید شنود ترافیک DHCP را روی آن‌ها آغاز کند، به عنوان پارامتر دریافت می‌کند. اگر مدخل‌های تکراری در فهرست دستور وجود داشته باشند یا مدخل‌های موجود در پیکربندی در حال اجرا را تکرار کنند، این مدخل‌ها هیچ تأثیری بر پیکربندی جدید نخواهند داشت. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این دستور تنها می‌تواند به فهرست موجود رابط‌ها اضافه کند. هیچ راهی برای حذف یک رابط پس از اضافه شدن آن و شروع شنود ترافیک DHCP توسط کارساز وجود ندارد. .UNINDENT .UNINDENT .sp لطفاً توجه داشته باشید که پیکربندی جدید تنها در حافظه نگهداری می‌شود؛ اگر کارساز بازراه‌اندازی شود یا بارگذاری مجدد پیکربندی از طریق یک سیگنال صورت گیرد، کارساز از پیکربندی ذخیره‌شده در فایل پیکربندی خود استفاده خواهد کرد. پاسخ کارساز شامل یک کد عددی، \fBresult\fP (۰ برای موفقیت و غیر صفر برای شکست)، و یک رشته، \fBtext\fP، است که نتیجه را توصیف می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqInterface configuration successfully updated.\(dq } .EE .UNINDENT .UNINDENT .sp پیکربندی به‌روزرسانی‌شده همچنین می‌تواند با استفاده از دستور \fBconfig\-get\fP (درون مپ پیکربندی \(dqinterfaces\-config\(dq) بازیابی شود. .SS دستور \fBinterface\-list\fP .sp دستور \fBinterface\-list\fP فهرست رابط‌های شناسایی‌شده را بازیابی می‌کند. این دستور هیچ پارامتری نمی‌پذیرد. .SS دستور \fBinterface\-redetect\fP .sp دستور \fBinterface\-redetect\fP پس از اجرای یک روند شناسایی مجدد که تنها رابط‌ها و آدرس‌های جدیداً کشف‌شده را اضافه می‌کند، بدون آنکه رابط‌ها یا آدرس‌های شناسایی‌شده قبلی را حذف کند، فهرست رابط‌های شناسایی‌شده را بازیابی می‌نماید. این دستور هیچ پارامتری دریافت نمی‌کند.\(dq .SS دستور \fBlist\-commands\fP .sp دستور \fBlist\-commands\fP فهرستی از تمام دستورهای پشتیبانی‌شده توسط کارساز را بازیابی می‌کند. این دستور هیچ آرگومانی نمی‌پذیرد. یک نمونه فراخوانی ممکن است به شکل زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqlist\-commands\(dq, \(dqarguments\(dq: { } } .EE .UNINDENT .UNINDENT .sp کارساز با فهرستی از تمامی دستورهای پشتیبانی‌شده پاسخ می‌دهد. عنصر arguments فهرستی از رشته‌ها است که هر کدام نشان‌دهنده یک دستور پشتیبانی‌شده است..SS دستور \fBconfig\-set\fP .sp دستور \fBconfig\-set\fP به سرور اعلام می‌کند که پیکربندی فعلی خود را با پیکربندی جدید ارائه‌شده در آرگومان‌های دستور جایگزین کند. انتظار می‌رود پیکربندی ارائه‌شده، پیکربندی کامل سرور مورد نظر به همراه پیکربندی اختیاری ثبات وقایع (logger) باشد. اگرچه پیکربندی logger اختیاری است، اکیداً توصیه می‌شود؛ چرا که بدون آن سرور به پیکربندی پیش‌فرض ثبت وقایع خود بازمی‌گردد. ساختار دستور به شرح زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqconfig\-set\(dq, \(dqarguments\(dq: { \(dq\(dq: { } } } .EE .UNINDENT .UNINDENT .sp که در آن نام مؤلفه پیکربندی برای یک سرور مشخص است، مانند \(dqDhcp4\(dq یا \(dqDhcp6\(dq. برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqconfig\-set\(dq, \(dqarguments\(dq: { \(dqDhcp6\(dq: { ... } } } .EE .UNINDENT .UNINDENT .sp چنانچه نامعتبر بودن پیکربندی جدید محرز شود، سرور پیکربندی فعلی خود را حفظ می‌کند؛ با این حال، در برخی موارد یک پیام خطای مهلک ثبت می‌شود که نشان می‌دهد سرور دیگر هیچ سرویسی ارائه نمی‌دهد: در این شرایط باید در اسرع وقت یک پیکربندی کارآمد بارگذاری شود. در صورتی که کانال کنترل (control channel) از کار افتاده باشد، همچنان می‌توان با استفاده از سیگنال \fBSIGHUP\fP فایل پیکربندی را مجدداً بارگذاری کرد. اگر این روش نیز ناموفق بود، سرور را مجدداً راه‌اندازی کنید. .sp لطفاً توجه داشته باشید که پیکربندی جدید تنها در حافظه نگه‌داری می‌شود؛ اگر سرور مجدداً راه‌اندازی شود یا بارگذاری مجدد پیکربندی از طریق یک سیگنال فعال گردد، سرور از پیکربندی ذخیره‌شده در فایل پیکربندی خود استفاده خواهد کرد. پاسخ سرور شامل یک کد عددی به نام \fBresult\fP (صفر برای موفقیت، و مقداری غیر صفر در صورت شکست) و یک رشته متنی به نام \fBtext\fP است که نتیجه را شرح می‌دهد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqConfiguration successful.\(dq } یا { \(dqresult\(dq: 1, \(dqtext\(dq: \(dqunsupported parameter: BOGUS (:16:26)\(dq } .EE .UNINDENT .UNINDENT .sp در Kea 2.4.0 و نسخه‌های بعدی، پاسخ موفقیت‌آمیز دریافتی از دیمن‌های DHCPv4، DHCPv6، یا DHCP\-DDNS همچنین حاوی یک خلاصه درهم‌ساز (digest) از نوع SHA\-256 از پیکربندی جدید اعمال‌شده است. از این خلاصه می‌توان به‌سادگی برای تشخیص اینکه آیا پیکربندی تغییر کرده است یا خیر استفاده کرد. .SS دستور \fBshutdown\fP .sp دستور \fBshutdown\fP به سرور دستور می‌دهد تا روال خاموش شدن خود را آغاز کند؛ این دستور معادل ارسال سیگنال \fBSIGTERM\fP به فرایند است. این دستور هیچ آرگومانی نمی‌پذیرد. یک نمونه دستور ممکن است به شکل زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqshutdown\(dq, \(dqarguments\(dq: { \(dqexit\-value\(dq: 3 } } .EE .UNINDENT .UNINDENT .sp سرور با تأییدیه‌ای مبنی بر آغاز شدن فرایند خاموش‌سازی پاسخ می‌دهد. پارامتر اختیاری \fBexit\-value\fP مقدار عددی خروج فرایند سرور به سیستم را مشخص می‌کند. مقدار پیش‌فرض صفر است. .sp دیمن DDNS از یک پارامتر اضافی به نام \fBtype\fP پشتیبانی می‌کند که نحوه پاک‌سازی فرایند هنگام خروج را کنترل می‌نماید. حالت‌های خاموش‌سازی پشتیبانی‌شده عبارتند از: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \(dqnormal\(dq \- مدیر صف را متوقف کرده و قبل از خروج، تمامی تراکنش‌های جاری را به پایان می‌رساند. این حالت پیش‌فرض است. .IP \(bu 2 \(dqdrain_first\(dq \- مدیر صف را متوقف می‌کند، اما به پردازش درخواست‌های درون صف تا خالی شدن کامل آن ادامه می‌دهد. .IP \(bu 2 \(dqnow\(dq \- فوراً خارج می‌شود. .UNINDENT .UNINDENT .UNINDENT .sp یک نمونه دستور ممکن است به این صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqshutdown\(dq, \(dqarguments\(dq: { \(dqexit\-value\(dq: 3, \(dqtype\(dq: \(dqdrain_first\(dq } } .EE .UNINDENT .UNINDENT.SS دستور \fBdhcp\-disable\fP .sp دستور \fBdhcp\-disable\fP سرویس DHCP را به‌طور سراسری غیرفعال می‌کند. کارکرد کارساز ادامه می‌یابد، اما تمام پیام‌های دریافتی DHCP را دور می‌اندازد (drop می‌کند). این دستور زمانی مفید است که نگهداری کارساز مستلزم آن باشد که کارساز موقتاً تخصیص اجاره‌های جدید و تمدید اجاره‌های موجود را متوقف کند. همچنین در پیکربندی‌های مشابه failover در طول همگام‌سازی پایگاه‌های داده اجاره هنگام راه‌اندازی، یا بازیابی پس از خرابی مفید است. پارامتر اختیاری \fBmax\-period\fP مدت زمان بر حسب ثانیه را مشخص می‌کند که پس از آن سرویس DHCP باید به‌طور خودکار دوباره فعال شود، چنانچه دستور \fBdhcp\-enable\fP پیش از سپری شدن این زمان ارسال نشده باشد. .sp از Kea 1.9.4، یک پارامتر اضافی به نام \fBorigin\fP وجود دارد که منبع دستور را مشخص می‌کند. مدیر کارساز معمولاً باید این پارامتر را نادیده بگیرد، زیرا مقدار پیش‌فرض \(dquser\(dq نشان‌دهنده آن است که مدیر دستور را ارسال کرده است. در Kea نسخه ۲.۵.۵ تا ۲.۵.۷، این پارامتر همچنین در ارتباط میان شرکای HA برای مشخص کردن شناسه سرویس HA ارسال‌کننده دستور در قالب عددی به کار می‌رفت. با این حال، به دلیل مسائل سازگاری با نسخه‌های قدیمی‌تر Kea که مقادیر عددی را به‌درستی تجزیه نمی‌کردند، معرفی پارامتر جدید \fBorigin\-id\fP در Kea 2.5.8 ضروری شد. .sp این پارامتر حاوی یک مقدار عددی است که منشأ دستور را نشان می‌دهد. همان مقدار را همچنان می‌توان با استفاده از پارامتر \fBorigin\fP ارسال کرد، اما ممکن است باعث مسائل سازگاری یادشده میان شرکای HA با نسخه‌های متفاوت Kea شود؛ اگر از هر دو استفاده شود، \fBorigin\-id\fP اولویت دارد. نسخه‌های جدید Kea استفاده از \fBorigin\-id\fP را در ارتباط میان شرکای HA ترجیح می‌دهند، اما در کل توصیه می‌شود هر دو پارامتر نادیده گرفته شوند و از مقدار پیش‌فرض استفاده شود. .sp کدهای زیر منشأهای پشتیبانی‌شده را در قالب عددی نشان می‌دهند: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fB1\fP \- یک دستور کاربری؛ معادل با تعیین \fB\(dqorigin\(dq: \(dquser\(dq\fP\&. .IP \(bu 2 \fB2000\fP، \fB2001\fP، \fB2002\fP و غیره \- منشأهای تعیین‌شده توسط شرکای HA که در آن مقادیر افزایشی بالای \fB2000\fP، شناسه‌های متمایز سرویس HA هستند که در صورت وجود روابط متعدد میان شرکا استفاده می‌شوند. .UNINDENT .UNINDENT .UNINDENT .sp در مثال زیر: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqdhcp\-disable\(dq, \(dqarguments\(dq: { \(dqmax\-period\(dq: 20, \(dqorigin\-id\(dq: 2002, \(dqorigin\(dq: \(dquser\(dq } } .EE .UNINDENT .UNINDENT .sp منشأ مؤثر \fB2002\fP است، که نشان می‌دهد یکی از شرکای HA در حال ارسال دستور برای سرویسی با شناسه \fB2\fP است. در این حالت، پارامتر \fBorigin\fP نادیده گرفته خواهد شد. .SS دستور \fBdhcp\-enable\fP .sp دستور \fBdhcp\-enable\fP سرویس DHCP را به‌طور سراسری فعال می‌کند. .sp از Kea 1.9.4، یک پارامتر اضافی به نام \fBorigin\fP وجود دارد که منبع دستور را مشخص می‌کند. مدیر کارساز معمولاً باید این پارامتر را نادیده بگیرد، زیرا مقدار پیش‌فرض \(dquser\(dq نشان می‌دهد که مدیر دستور را ارسال کرده است. در Kea نسخه ۲.۵.۵ تا ۲.۵.۷، این پارامتر همچنین در ارتباط میان شرکای HA برای مشخص کردن شناسه سرویس HA ارسال‌کننده دستور در قالب عددی استفاده می‌شد. با این حال، به دلیل مسائل سازگاری با نسخه‌های قدیمی‌تر Kea که مقادیر عددی را به‌درستی تجزیه نمی‌کردند، معرفی پارامتر جدید \fBorigin\-id\fP در Kea 2.5.8 ضروری شد. .sp این پارامتر حاوی یک مقدار عددی است که منشأ دستور را نشان می‌دهد. همان مقدار را همچنان می‌توان با استفاده از پارامتر \fBorigin\fP ارسال کرد، اما می‌تواند باعث ایجاد مسائل سازگاری یادشده میان شرکای HA با نسخه‌های متفاوت Kea شود؛ اگر از هر دو استفاده شود، \fBorigin\-id\fP اولویت دارد. نسخه‌های جدید Kea استفاده از \fBorigin\-id\fP را در ارتباط میان شرکای HA ترجیح می‌دهند، اما در کل توصیه می‌شود هر دو پارامتر نادیده گرفته شوند و از مقدار پیش‌فرض استفاده شود. .sp کدهای زیر منشأهای پشتیبانی‌شده را در قالب عددی نشان می‌دهند: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fB1\fP \- یک دستور کاربری؛ معادل با تعیین \fB\(dqorigin\(dq: \(dquser\(dq\fP\&. .IP \(bu 2 \fB2000\fP، \fB2001\fP، \fB2002\fP و غیره \- منشأهای تعیین‌شده توسط شرکای HA که در آن مقادیر افزایشی بالای \fB2000\fP، شناسه‌های متمایز سرویس HA هستند که در صورت وجود روابط متعدد میان شرکا استفاده می‌شوند. .UNINDENT .UNINDENT .UNINDENT .sp در مثال زیر: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqdhcp\-enable\(dq, \(dqarguments\(dq: { \(dqorigin\-id\(dq: 2002, \(dqorigin\(dq: \(dquser\(dq } } .EE .UNINDENT .UNINDENT .sp منشأ مؤثر \fB2002\fP است، که نشان می‌دهد یکی از شرکای HA در حال ارسال دستور برای سرویسی با شناسه \fB2\fP است. در این حالت، پارامتر \fBorigin\fP نادیده گرفته خواهد شد. .SS دستور \fBstatus\-get\fP .sp دستور \fBstatus\-get\fP اطلاعات زمان اجرای کارساز را برمی‌گرداند: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBpid\fP: شناسه فرایند (PID). .IP \(bu 2 \fBuptime\fP: تعداد ثانیه‌های سپری‌شده از زمان شروع به کار کارساز. .IP \(bu 2 \fBreload\fP: تعداد ثانیه‌های سپری‌شده از آخرین بارگذاری (مجدد) پیکربندی. .IP \(bu 2 \fBhigh\-availability\fP: اطلاعات وضعیت مختص HA درباره کارسازهای DHCP پیکربندی‌شده برای استفاده از کتابخانه قلاب (hook) مربوط به HA: .INDENT 2.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBlocal\fP: وضعیت، نقش (primary، secondary و...)، و دامنه‌های (یعنی آنچه کارساز عملاً در حال پردازش آن است) کارساز محلی. .IP \(bu 2 \fBremote\fP: آخرین وضعیت شناخته‌شده کارساز دوردست، دامنه‌های HA ارائه‌شده توسط آن، و نقش کارساز دوردست در رابطه HA. .UNINDENT .UNINDENT .UNINDENT .IP \(bu 2 \fBmulti\-threading\-enabled\fP: پرچمی که نشان می‌دهد آیا چندنخی فعال است یا خیر. .IP \(bu 2 \fBthread\-pool\-size\fP: تعداد نخ‌های سرویس DHCP. .IP \(bu 2 \fBpacket\-queue\-size\fP: حداکثر اندازه صف بسته‌ها. صرف‌نظر از تعداد نخ‌های در حال اجرا، تنها یک صف وجود دارد. .IP \(bu 2 \fBpacket\-queue\-statistics\fP: میانگین اندازه صف برای ۱۰، ۱۰۰ و ۱۰۰۰ بسته آخر، با استفاده از رویکردی مشابه با دستور \fBtop\fP در UNIX. میانگین اندازه صف برای ۱۰ بسته آخر را می‌توان یک مقدار لحظه‌ای در نظر گرفت، در حالی که میانگین برای ۱۰۰۰ بسته آخر روندی بلندمدت‌تر را نشان می‌دهد. .UNINDENT .UNINDENT .UNINDENT .sp اطلاعات \fBhigh\-availability\fP تنها زمانی بازگردانده می‌شود که دستور به کارسازهای DHCP در یک راه‌اندازی HA ارسال شود. این پارامتر هنگامی که دستور \fBstatus\-get\fP به دیمن DDNS ارسال شود، هرگز بازگردانده نمی‌شود. .sp پارامترهای \fBthread\-pool\-size\fP، \fBpacket\-queue\-size\fP و \fBpacket\-queue\-statistics\fP تنها زمانی بازگردانده می‌شوند که دستور به کارسازهای DHCP با چندنخی فعال ارسال شود. این سه پارامتر و \fBmulti\-threading\-enabled\fP هرگز هنگامی که دستور \fBstatus\-get\fP به دیمن DDNS ارسال شود، بازگردانده نمی‌شوند. .sp برای کسب اطلاعات بیشتر درباره وضعیت HA بازگردانده‌شده توسط دستور \fBstatus\-get\fP، لطفاً به بخش دستور status\-get \%<#\:command-ha-status-get> مراجعه کنید..SS دستور \fBserver\-tag\-get\fP: .sp دستور \fBserver\-tag\-get\fP برچسب کارگزار (server tag) پیکربندی‌شده برای کارگزار DHCPv4 یا DHCPv6 را بازمی‌گرداند (بخش Configuration Sharing and Server Tags \%<#\:cb-sharing> مفهوم server tag را شرح می‌دهد). .SS دستور \fBconfig\-backend\-pull\fP: .sp دستور \fBconfig\-backend\-pull\fP بررسی دوره‌ای (polling) بک‌اندهای پیکربندی را آغاز می‌کند (که برای اثربخشی این دستور باید پیکربندی شده باشند)، همان‌طور که در Enabling the Configuration Backend \%<#\:dhcp4-cb-json>\& توضیح داده شده است. .SS دستور \fBversion\-get\fP .sp دستور \fBversion\-get\fP اطلاعات گسترش‌یافته‌ای را دربارهٔ نسخهٔ Kea بازمی‌گرداند؛ این همان اطلاعاتی است که از طریق آرگومان خط فرمان \fB\-V\fP در دسترس است. این دستور هیچ پارامتری دریافت نمی‌کند. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqversion\-get\(dq } .EE .UNINDENT .UNINDENT .SS دستور \fBkea\-lfc\-start\fP .sp دستور \fBkea\-lfc\-start\fP فرایند \fBkea\-lfc\fP را آغاز می‌کند که فایل اجاره‌ها را پاک‌سازی می‌نماید (بخش The LFC Process \%<#\:kea-lfc> را ببینید). این دستور هیچ آرگومانی نمی‌پذیرد و در مواردی که بک‌اند اجاره \fBmemfile\fP نباشد، پارامتر \fBpersist\fP در \fBlease\-database\fP روی \fBfalse\fP پیکربندی شده باشد (اما نه زمانی که \fBlfc\-interval\fP برابر با \fB0\fP است)، تشخیص دهد که یک فرایند LFC در حال حاضر در حال اجرا است، یا خطایی مانع از آغاز یک فرایند LFC جدید شود، وضعیت موفقیت‌آمیز را برنمی‌گرداند. .SS دستورهای پشتیبانی‌شده توسط کارگزار DHCPv4 .SS دستور \fBsubnet4\-select\-test\fP .sp دستور \fBsubnet4\-select\-test\fP روشی را برای آزمایش انتخاب زیرشبکهٔ DHCPv4 بر اساس مجموعه‌ای از پارامترهای ورودی فراهم می‌کند که معمولاً در بستهٔ کارخواه ارائه می‌شوند. پارامترهای شناخته‌شده رشته دریافت می‌کنند و عبارتند از: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBinterface\fP \- نام رابط ورودی .IP \(bu 2 \fBaddress\fP \- نشانی کارخواه .IP \(bu 2 \fBrelay\fP \- نشانی رله/دروازه .IP \(bu 2 \fBlocal\fP \- نشانی محلی/مقصد .IP \(bu 2 \fBremote\fP \- نشانی دوردست/مبدأ .IP \(bu 2 \fBlink\fP \- نشانی link\-selection مربوط به RAI .IP \(bu 2 \fBsubnet\fP \- نشانی subnet\-selection .IP \(bu 2 \fBclasses\fP \- (فهرستی از رشته‌ها) کلاس‌های کارخواه (جهت امکان انتخاب یک زیرشبکهٔ حفاظت‌شده) .UNINDENT .UNINDENT .UNINDENT .sp هنگامی که پرچم سازگاری \fBignore\-rai\-link\-selection\fP برابر با \fBtrue\fP باشد، RAI link\-selection نادیده گرفته می‌شود\&. هنگامی که نادیده گرفته نشود، نسبت به subnet\-selection اولویت دارد. .sp صرف‌نظر از خطاها، نتایج احتمالی عبارتند از: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 (خالی) \(dqno selected subnet\(dq .IP \(bu 2 \(dqselected shared network \(aq\(aq starting with subnet \(aq\(aq id \(dq .IP \(bu 2 \(dqselected subnet \(aq\(aq id \(dq .UNINDENT .UNINDENT .UNINDENT .SS دستور \fBsubnet4o6\-select\-test\fP .sp دستور \fBsubnet4o6\-select\-test\fP روشی را برای آزمایش انتخاب زیرشبکهٔ DHCPv4\-over\-DHCPv6 بر اساس مجموعه‌ای از پارامترهای ورودی فراهم می‌کند که معمولاً در بستهٔ کارخواه ارائه می‌شوند. پارامترهای شناخته‌شده رشته دریافت می‌کنند و عبارتند از: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBinterface\fP \- نام رابط ورودی کارگزار DHCPv6 .IP \(bu 2 \fBinterface\-id\fP \- محتوای دودویی گزینهٔ رلهٔ interface\-id .IP \(bu 2 \fBaddress\fP \- نشانی کارخواه .IP \(bu 2 \fBrelay\fP \- نشانی رله/دروازه .IP \(bu 2 \fBlocal\fP \- نشانی محلی/مقصد .IP \(bu 2 \fBremote\fP \- نشانی IPv6 دوردست/مبدأ کارگزار DHCPv6 .IP \(bu 2 \fBlink\fP \- نشانی IPv6 اولین پیوند رله .IP \(bu 2 \fBsubnet\fP \- نشانی subnet\-selection .IP \(bu 2 \fBclasses\fP \- (فهرستی از رشته‌ها) کلاس‌های کارخواه (جهت امکان انتخاب یک زیرشبکهٔ حفاظت‌شده) .UNINDENT .UNINDENT .UNINDENT .sp طبق کد، تنها گزینش‌گرهای \fBremote\fP، \fBinterface\-id\fP و \fBinterface\fP استفاده می‌شوند. در پیاده‌سازی DHCPv4\-over\-DHCPv6 مقادیر \fBinterface\fP و \fBremote\fP از کارگزار DHCPv6 منتقل می‌شوند، \fBinterface\-id\fP و \fBlink\fP در بخش اطلاعات رلهٔ بستهٔ DHCPv6 حمل می‌شوند و در نتیجه مانند کارگزار DHCPv6 هستند. .sp صرف‌نظر از خطاها، نتایج احتمالی عبارتند از: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 (خالی) \(dqno selected subnet\(dq .IP \(bu 2 \(dqselected shared network \(aq\(aq starting with subnet \(aq\(aq id \(dq .IP \(bu 2 \(dqselected subnet \(aq\(aq id \(dq .UNINDENT .UNINDENT .UNINDENT.SS دستورات پشتیبانی‌شده توسط کارساز DHCPv6 .SS دستور \fBsubnet6\-select\-test\fP .sp دستور \fBsubnet6\-select\-test\fP روشی را برای آزمایش انتخاب زیرشبکه DHCPv6 بر اساس مجموعه‌ای از پارامترهای ورودی که معمولاً در بسته کارخواه (client) ارائه می‌شوند، فراهم می‌کند. پارامترهای شناخته‌شده رشته می‌پذیرند و عبارتند از: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBinterface\fP \- نام رابط ورودی .IP \(bu 2 \fBinterface\-id\fP \- محتوای دودویی گزینه بازپخش (relay) مربوط به interface\-id .IP \(bu 2 \fBremote\fP \- نشانی دوردست/مبدأ .IP \(bu 2 \fBlink\fP \- نخستین نشانی پیوند رله .IP \(bu 2 \fBclasses\fP \- (فهرستی از رشته‌ها) کلاس‌های کارخواه (جهت امکان انتخاب یک زیرشبکه محافظت‌شده) .UNINDENT .UNINDENT .UNINDENT .sp جدا از خطاها، نتایج احتمالی عبارتند از: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 (خالی) \(dqno selected subnet\(dq .IP \(bu 2 \(dqselected shared network \(aq\(aq starting with subnet \(aq\(aq id \(dq .IP \(bu 2 \(dqselected subnet \(aq\(aq id \(dq .UNINDENT .UNINDENT .UNINDENT .SS دستورات پشتیبانی‌شده توسط کارساز D2 .sp کارساز D2 تنها از زیرمجموعه‌ای از دستورات کارسازهای DHCPv4/DHCPv6 پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBbuild\-report\fP .IP \(bu 2 \fBconfig\-get\fP .IP \(bu 2 \fBconfig\-hash\-get\fP .IP \(bu 2 \fBconfig\-reload\fP .IP \(bu 2 \fBconfig\-set\fP .IP \(bu 2 \fBconfig\-test\fP .IP \(bu 2 \fBconfig\-write\fP .IP \(bu 2 \fBlist\-commands\fP .IP \(bu 2 \fBshutdown\fP .IP \(bu 2 \fBstatus\-get\fP .IP \(bu 2 \fBversion\-get\fP .UNINDENT .SS مهاجرت از Control Agent منسوخ‌شده (حذف‌شده) .sp از نسخه 2.7.2 Kea، کارسازهای DHCP از کانال‌های کنترلی HTTP/HTTPS پشتیبانی می‌کنند؛ بنابراین به Control Agent (CA) دیگر نیازی نیست، و از نسخه 3.1.8 Kea، این مؤلفه (CA) به‌طور کامل حذف شده است. .sp کارسازهای DHCPv4، DHCPv6 و D2 مدخل \fBcontrol\-socket\fP را به فهرست \fBcontrol\-sockets\fP گسترش داده‌اند. برای مهاجرت پیکربندی CA، عنصری را با مشخصات زیر به این فهرست اضافه کنید: .INDENT 0.0 .IP \(bu 2 \fBsocket\-type\fP تنظیم‌شده روی \fBhttp\fP یا \fBhttps\fP .IP \(bu 2 \fBsocket\-address\fP با محتوای \fBhttp\-host\fP مربوط به CA .IP \(bu 2 \fBsocket\-port\fP با محتوای \fBhttp\-port\fP مربوط به CA .IP \(bu 2 \fBtrust\-anchor\fP (بدون تغییر) .IP \(bu 2 \fBcert\-file\fP (بدون تغییر) .IP \(bu 2 \fBkey\-file\fP (بدون تغییر) .IP \(bu 2 \fBcert\-required\fP (بدون تغییر) .IP \(bu 2 \fBauthentication\fP (بدون تغییر) .UNINDENT .sp بافتار کاربر (User context) نیز پشتیبانی می‌شود. لطفاً برای مقادیر پیش‌فرض و سایر جزئیات، بخش‌های مربوط به سوکت کنترلی HTTP را ببینید: سوکت کنترلی HTTP/HTTPS برای DHCP4 \%<#\:dhcp4-http-ctrl-channel>، سوکت کنترلی HTTP/HTTPS برای DHCP6 \%<#\:dhcp6-http-ctrl-channel> و سوکت کنترلی HTTP/HTTPS برای DHCP\-DDNS \%<#\:d2-http-ctrl-channel>\&. .sp توجه داشته باشید که دو کارساز باید از جفت‌های نشانی / درگاه متفاوتی استفاده کنند. این قاعده برای شنوندگان HA نیز صدق می‌کند. .sp به‌منظور حفظ سازگاری، نتیجه JSON این سوکت‌های کنترلی HTTP/HTTPS همچنان درون یک فهرست کپسوله‌سازی می‌شود. .SH "ثبت وقایع (LOGGING)" .SS پیکربندی ثبت وقایع .sp در طول اجرای برنامه، Kea ممکن است پیام‌های ثبتی (log) متعددی ایجاد کند. این پیام‌ها از نظر سطح اهمیت (برخی مهم‌تر از بقیه هستند) و منبع تولید (مؤلفه‌های مختلف، مانند قلاب‌ها، پیام‌های متفاوتی صادر می‌کنند) فرق دارند. آگاهی از اینکه کدام پیام‌ها حیاتی و کدام غیرحیاتی هستند و پیکربندی متناسب سازوکار ثبت وقایع بسیار مفید است. برای نمونه، پیام‌های سطح اشکال‌زدایی (debug\-level) را می‌توان با اطمینان در یک استقرار عادی نادیده گرفت. هرچند، این پیام‌ها هنگام عیب‌یابی یک مشکل بسیار کارآمد هستند. .sp سامانه ثبت وقایع در Kea از طریق مدخل \fBloggers\fP در بخش server فایل پیکربندی تنظیم می‌شود. .SS ثبت‌کننده‌ها (Loggers) .sp در Kea، پیام‌ها از طریق موجودیتی موسوم به \(dqlogger\(dq (ثبت‌کننده) ثبت می‌شوند. مؤلفه‌های گوناگون پیام‌ها را از طریق ثبت‌کننده‌های مختلفی به ثبت می‌رسانند و هر ثبت‌کننده می‌تواند مستقل از سایرین پیکربندی شود. برخی از مؤلفه‌ها، به‌ویژه فرایندهای کارساز DHCP، ممکن است از چندین ثبت‌کننده جهت ثبت پیام‌های مربوط به بخش‌های منطقی مختلفِ آن مؤلفه استفاده کنند. برای مثال، کارساز DHCPv4 از یک ثبت‌کننده برای پیام‌های دریافت و ارسال بسته‌ها، و از ثبت‌کننده‌ای دیگر برای پیام‌های مرتبط با تخصیص اجاره (lease) و مواردی از این دست استفاده می‌کند. برخی از کتابخانه‌های مورداستفاده در کارساز Kea مانند libdhcpsrv از ثبت‌کننده‌های مختص به خود بهره می‌برند. .sp کاربرانی که کتابخانه‌های قلاب (hook libraries - کدی که در زمان اجرا به کارساز پیوست می‌شود) را توسعه می‌دهند، وظیفه ایجاد ثبت‌کننده‌های مورد استفاده در آن کتابخانه‌ها را بر عهده دارند. این ثبت‌کننده‌ها باید نام‌های منحصربه‌فردی داشته باشند که با نام‌های استفاده‌شده توسط Kea تداخل نداشته باشد. بدین ترتیب، پیام‌های صادرشده توسط کتابخانه قلاب از پیام‌های بخش مرکزی کد Kea قابل تفکیک خواهند بود. همچنین نام‌های متمایز این امکان را می‌دهند که ثبت‌کننده‌های قلاب به‌طور مستقل از ثبت‌کننده‌های Kea پیکربندی شوند. در صورت لزوم، یک کتابخانه قلاب می‌تواند از چندین ثبت‌کننده جهت ثبت پیام‌های مربوط به بخش‌های منطقی متفاوت کتابخانه بهره ببرد. .sp در بخش server فایل پیکربندی، می‌توان تنظیمات مربوط به صفر یا چند ثبت‌کننده (از جمله ثبت‌کننده‌های مورداستفاده در کتابخانه‌های قلاب اختصاصی) را تعیین کرد. در صورت عدم تعیین ثبت‌کننده‌ها، کد از مقادیر پیش‌فرض استفاده می‌کند؛ در این حالت Kea پیام‌های با سطح اهمیت INFO یا بیشتر را در خروجی استاندارد ثبت می‌کند. یک بازه زمانی کوتاه میان شروع به کار Kea تا زمان خواندن پیکربندی وجود دارد؛ ثبت وقایع در این بازه کوتاه را می‌توان از طریق متغیرهای محیطی کنترل نمود. برای کسب اطلاعات بیشتر، بخش Logging During Kea Startup را ببینید\&. .sp سه مؤلفه اصلی در پیکربندی یک ثبت‌کننده عبارتند از: \fBname\fP (مؤلفه‌ای که پیام‌ها را ایجاد می‌کند)، \fBseverity\fP (چه چیزی ثبت شود)، و \fBoutput_commands\fP (محل ذخیره یا ارسال لاگ). علاوه بر این، گزینه \fBdebuglevel\fP نیز وجود دارد که تنها در صورت انتخاب سطح ثبت وقایع debug کاربرد دارد..SS ثبت‌کنندهٔ \fBname\fP (رشته) .sp هر ثبت‌کننده (logger) در سامانه یک نام دارد: نام فایل باینری مؤلفه‌ای که از آن برای ثبت پیام‌ها استفاده می‌کند. برای نمونه، جهت پیکربندی ثبت رخدادها برای سرور DHCPv4، مدخلی برای ثبت‌کننده‌ای با نام «kea\-dhcp4» اضافه کنید. این پیکربندی سپس توسط ثبت‌کننده‌های موجود در سرور DHCPv4 و تمامی کتابخانه‌های مورد استفادهٔ آن به کار گرفته خواهد شد، مگر آن‌که کتابخانه‌ای ثبت‌کنندهٔ ویژهٔ خود را تعریف کرده باشد و پیکربندی ثبت‌کنندهٔ مشخصی وجود داشته باشد که بر آن ثبت‌کننده اعمال شود. .sp هنگام ردیابی یک مشکل در عملکرد سرور، استفاده از ثبت در سطح DEBUG برای به‌دست آوردن خروجی با جزئیات کامل جهت عیب‌یابی مورد نیاز است. با این حال، احتمال دارد این حجم زیاد از جزئیات در مواردی که سرور ترافیک بالایی را پردازش می‌کند، سامانهٔ ثبت رخداد را تحت فشار شدید قرار دهد. برای کاهش این مشکل، Kea می‌تواند از چندین ثبت‌کننده برای بخش‌های عملکردی مختلف سرور استفاده کند که هر کدام را می‌توان به طور مستقل پیکربندی کرد. اگر کاربر تا حد قابل قبولی مطمئن باشد که مشکل از بخش خاصی از سرور سرچشمه می‌گیرد، یا مشکل به نوع خاصی از عملیات مربوط است، می‌تواند سطح جزئیات بالا را تنها برای ثبت‌کنندهٔ مربوطه فعال کند و از این طریق پیام‌های DEBUG را به حداقلِ لازم محدود سازد. .sp ثبت‌کننده‌ها به یک کتابخانه یا فایل باینریِ مشخص از Kea وابسته هستند. با این وجود، هر کتابخانه یا فایل باینری می‌تواند (و معمولاً چنین است) شامل چندین ثبت‌کننده باشد. برای نمونه، فایل باینری سرور DHCPv4 شامل ثبت‌کننده‌های مجزایی برای تجزیهٔ بسته‌ها (packet parsing)، بسته‌های دور انداخته‌شده (dropped packets)، فراخوانی‌ها (callouts) و غیره است. .sp ثبت‌کننده‌ها یک سلسله‌مراتب را تشکیل می‌دهند. برای هر برنامه در Kea، یک ثبت‌کنندهٔ «ریشه» (\(dqroot\(dq) وجود دارد که هم‌نام با آن برنامه است (برای نمونه، ثبت‌کنندهٔ ریشه برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>، یعنی سرور DHCPv4، نامش \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> است). سایر ثبت‌کننده‌ها فرزندان این ثبت‌کننده به شمار می‌روند و متناسب با آن نام‌گذاری می‌شوند؛ مثلاً موتور تخصیص در سرور DHCPv4، پیام‌ها را با استفاده از ثبت‌کننده‌ای به نام \fBkea\-dhcp4.alloc\-engine\fP\& ثبت می‌کند. .sp این رابطه اهمیت دارد، زیرا هر ثبت‌کنندهٔ فرزند، پیکربندی پیش‌فرض خود را از ثبت‌کنندهٔ ریشهٔ والد خود دریافت می‌کند. در حالت معمول، پیکربندی ثبت‌کنندهٔ ریشه تنها پیکربندیِ ثبتی است که در فایل پیکربندی مشخص می‌شود و بنابراین برای همهٔ ثبت‌کننده‌ها اعمال می‌گردد. اگر مدخلی برای یک ثبت‌کنندهٔ معین ایجاد شود، هر ویژگیِ مشخص‌شده بر ویژگی‌های ثبت‌کنندهٔ ریشه ارجحیت خواهد داشت، در حالی که ویژگی‌های مشخص‌نشده از آن به ارث برده می‌شوند. .sp برای روشن‌تر شدن موضوع، فرض کنید در حال استفاده از سرور DHCPv4 با ثبت‌کنندهٔ ریشهٔ \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> هستیم که در سطح INFO ثبت می‌کند. به منظور فعال‌سازی سطح جزئیات DEBUG برای بسته‌های دور انداخته‌شدهٔ DHCPv4، باید مدخل پیکربندی‌ای برای این ثبت‌کننده با \fB\(dqname\(dq: \(dqkea\-dhcp4.bad\-packets”\fP، \fB\(dqseverity\(dq: \(dqDEBUG\(dq\fP و یک سطح اشکال‌زدایی صریح بسازیم. تمام پارامترهای پیکربندی دیگر می‌توانند برای این ثبت‌کننده حذف شوند در صورتی که قرار باشد از مقادیر پیش‌فرض تعیین‌شده در پیکربندی ثبت‌کنندهٔ ریشه استفاده کند. .sp ویژگی \fBdebuglevel\fP تنها در صورتی به ارث می‌رسد که \fBseverity\fP نیز وجود نداشته باشد. برای به‌دست آمدن نتایج قابل پیش‌بینی، اگر \fBseverity\fP برابر \fB\(dqDEBUG\(dq\fP باشد، این دو ویژگی همیشه باید یا با هم به صراحت مشخص شوند یا هر دو حذف شوند. مدخلی با شدت صریح \fB\(dqDEBUG\(dq\fP، مقدار \fBdebuglevel\fP را از ثبت‌کنندهٔ ریشه به ارث نمی‌برد و در صورت عدم تعیین، به طور پیش‌فرض \fB0\fP در نظر گرفته می‌شود که در نتیجه هیچ پیام اشکال‌زدایی‌ای ثبت نخواهد شد. این پیامدِ تکیه بر سازوکار توارث log4cplus است. .sp اگر چندین مشخصهٔ ثبت‌کننده در پیکربندی وجود داشته باشد که ممکن است با یک ثبت‌کنندهٔ خاص تطابق داشته باشند، مشخصه‌ای که نام ثبت‌کنندهٔ دقیق‌تری دارد اولویت خواهد داشت. برای نمونه، اگر مدخل‌هایی هم برای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و هم برای \fBkea\-dhcp4.dhcpsrv\fP وجود داشته باشد، برنامهٔ اصلی سرور DHCPv4 — و تمام کتابخانه‌های مورد استفادهٔ آن به جز کتابخانهٔ \fBdhcpsrv\fP (کتابخانهٔ libdhcpsrv) — پیام‌ها را بر اساس پیکربندی موجود در مدخل اول (\fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>) ثبت می‌کنند. پیام‌های تولیدشده توسط کتابخانهٔ \fBdhcpsrv\fP بر اساس پیکربندی تعیین‌شده در مدخل دوم ثبت می‌شوند. .sp ثبت‌کننده‌هایی که در حال حاضر تعریف شده‌اند در جدول زیر فهرست شده‌اند. ستون «بستهٔ نرم‌افزاری» (\(dqSoftware Package\(dq) در این جدول مشخص می‌کند که آیا ثبت‌کننده‌های خاص متعلق به کد اصلی Kea (فایل‌های باینری و کتابخانه‌های متن‌باز Kea) هستند، یا کتابخانه‌های قلاب (hook) (متن‌باز یا اشتراکی). .SS فهرست ثبت‌کننده‌های پشتیبانی‌شده توسط سرورهای Kea و کتابخانه‌های قلاب ارائه‌شده همراه با بسته‌های Kea/اشتراکی .TS box center; l|l|l. T{ نام ثبت‌کننده T} T{ بستهٔ نرم‌افزاری T} T{ توضیحات T} _ T{ \fBkea\-dhcp4\fP T} T{ core T} T{ ثبت‌کنندهٔ ریشه برای سرور DHCPv4. تمام مؤلفه‌های مورد استفادهٔ سرور DHCPv4 تنظیمات را از این ثبت‌کننده به ارث می‌برند. T} _ T{ \fBkea\-dhcp6\fP T} T{ core T} T{ ثبت‌کنندهٔ ریشه برای سرور DHCPv6. تمام مؤلفه‌های مورد استفادهٔ سرور DHCPv6 تنظیمات را از این ثبت‌کننده به ارث می‌برند. T} _ T{ \fBkea\-dhcp4.alloc\-engine\fP, \fBkea\-dhcp6.alloc\-engine\fP T} T{ core T} T{ مورد استفاده توسط موتور تخصیص اجاره، که مسئول مدیریت اجاره‌ها در پایگاه دادهٔ اجاره است؛ یعنی ایجاد، تغییر، و حذف اجاره‌های DHCP در نتیجهٔ پردازش پیام‌های دریافتی از کلاینت‌ها. T} _ T{ \fBkea\-dhcp4.auth\fP, \fBkea\-dhcp6.auth\fP T} T{ core T} T{ برای ثبت بسته‌های ناهنجار HTTP در هنگام استفاده از احراز هویت پایه (basic authentication). T} _ T{ \fBkea\-dhcp4.bad\-packets\fP, \fBkea\-dhcp6.bad\-packets\fP T} T{ core T} T{ مورد استفاده توسط سرورهای DHCP برای ثبت بسته‌های ورودی کلاینت که دور انداخته شده‌اند یا سرور با یک DHCPNAK به آن‌ها پاسخ داده است. این قابلیت به مدیران سیستم امکان می‌دهد تا یک خروجی ثبت مجزا پیکربندی کنند که تنها حاوی موارد دور انداختن و رد بسته باشد. T} _ T{ \fBkea\-dhcp4.bootp\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_bootp.so\fP \%<#\:std-ischooklib-libdhcp_bootp\:.so> T} T{ این ثبت‌کننده برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب BOOTP به کار می‌رود. T} _ T{ \fBkea\-dhcp4.callouts\fP, \fBkea\-dhcp6.callouts\fP, \fBkea\-dhcp\-ddns.callouts\fP T} T{ core T} T{ برای ثبت پیام‌های مربوط به ثبت و اجرای فراخوانی‌ها (callouts) برای یک نقطهٔ قلاب خاص. T} _ T{ \fBkea\-dhcp4.cb\-cmds\-hooks\fP, \fBkea\-dhcp6.cb\-cmds\-hooks\fP T} T{ کتابخانهٔ قلاب اشتراکی \fBlibdhcp_cb_cmds.so\fP \%<#\:std-ischooklib-libdhcp_cb_cmds\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Config Backend Commands. T} _ T{ \fBkea\-dhcp4.class\-cmds\-hooks\fP, \fBkea\-dhcp6.class\-cmds\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_class_cmds.so\fP \%<#\:std-ischooklib-libdhcp_class_cmds\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Class Commands. T} _ T{ \fBkea\-dhcp4.commands\fP, \fBkea\-dhcp6.commands\fP T} T{ core T} T{ برای ثبت پیام‌های مرتبط با رسیدگی به دستورهای دریافت شده توسط سرور DHCP از طریق کانال دستور (command channel). T} _ T{ \fBkea\-dhcp4.database\fP, \fBkea\-dhcp6.database\fP T} T{ core T} T{ برای ثبت پیام‌های مرتبط با عملیات عمومی پایگاه‌های دادهٔ رابطه‌ای. T} _ T{ \fBkea\-dhcp4.ddns\-tuning\-hooks\fP, \fBkea\-dhcp6.ddns\-tuning\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_ddns_tuning.so\fP \%<#\:std-ischooklib-libdhcp_ddns_tuning\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب DDNS Tuning. T} _ T{ \fBkea\-dhcp4.ddns\fP, \fBkea\-dhcp6.ddns\fP T} T{ core T} T{ مورد استفاده توسط سرور DHCP برای ثبت پیام‌های مرتبط با پردازش گزینه‌های Client FQDN و Hostname. همچنین شامل پیام‌های ثبت مربوط به به‌روزرسانی‌های مرتبط با DNS است. T} _ T{ \fBkea\-dhcp4.dhcp4\fP, \fBkea\-dhcp6.dhcp6\fP T} T{ core T} T{ برای ثبت عملیات پایه به کار می‌رود. T} _ T{ \fBkea\-dhcp4.dhcpsrv\fP, \fBkea\-dhcp6.dhcpsrv\fP T} T{ core T} T{ ثبت‌کننده‌های پایه برای کتابخانهٔ \fBlibkea\-dhcpsrv.so\fP\&. T} _ T{ \fBkea\-dhcp4.eval\fP, \fBkea\-dhcp6.eval\fP T} T{ core T} T{ برای ثبت پیام‌های مرتبط با کد ارزیابی عبارت دسته‌بندی کلاینت. T} _ T{ \fBkea\-dhcp4.flex\-id\-hooks\fP, \fBkea\-dhcp6.flex\-id\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_flex_id.so\fP \%<#\:std-ischooklib-libdhcp_flex_id\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Flexible Identifier. T} _ T{ \fBkea\-dhcp4.flex\-option\-hooks\fP, \fBkea\-dhcp6.flex\-option\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_flex_option.so\fP \%<#\:std-ischooklib-libdhcp_flex_option\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Flexible Option. T} _ T{ \fBkea\-dhcp4.ha\-hooks\fP, \fBkea\-dhcp6.ha\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_ha.so\fP \%<#\:std-ischooklib-libdhcp_ha\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب دسترسی‌پذیری بالا (High Availability). T} _ T{ \fBkea\-dhcp4.hooks\fP, \fBkea\-dhcp6.hooks\fP, \fBkea\-dhcp\-ddns.hooks\fP T} T{ core T} T{ برای ثبت پیام‌های مرتبط با مدیریت کتابخانه‌های قلاب، مانند ثبت و لغو ثبت کتابخانه‌ها، و مقداردهی اولیهٔ اجرای فراخوانی‌ها برای نقاط قلاب مختلف در سرور DHCP به کار می‌رود. T} _ T{ \fBkea\-dhcp4.host\-cache\-hooks\fP, \fBkea\-dhcp6.host\-cache\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_host_cache.so\fP \%<#\:std-ischooklib-libdhcp_host_cache\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Host Cache. T} _ T{ \fBkea\-dhcp4.host\-cmds\-hooks\fP, \fBkea\-dhcp6.host\-cmds\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_host_cmds.so\fP \%<#\:std-ischooklib-libdhcp_host_cmds\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Host Commands. به طور کلی، این پیام‌ها مربوط به بارگذاری و تخلیهٔ کتابخانه و اجرای دستورها توسط کتابخانه هستند. T} _ T{ \fBkea\-dhcp4.hosts\fP, \fBkea\-dhcp6.hosts\fP T} T{ core T} T{ درون \fBlibkea\-dhcpsrv.so\fP برای ثبت پیام‌های مربوط به مدیریت رزروهای میزبان در DHCP (یعنی بازیابی رزروها و افزودن رزروهای جدید) استفاده می‌شود. T} _ T{ \fBkea\-dhcp4.lease\-cmds\-hooks\fP, \fBkea\-dhcp6.lease\-cmds\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_lease_cmds.so\fP \%<#\:std-ischooklib-libdhcp_lease_cmds\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Lease Commands. به طور کلی، این پیام‌ها مربوط به بارگذاری و تخلیهٔ کتابخانه و اجرای دستورها توسط کتابخانه هستند. T} _ T{ \fBkea\-dhcp4.limits\-hooks\fP, \fBkea\-dhcp6.limits\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_limits.so\fP \%<#\:std-ischooklib-libdhcp_limits\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Limits. T} _ T{ \fBkea\-dhcp4.lease\-query\-hooks\fP, \fBkea\-dhcp6.lease\-query\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_lease_query.so\fP \%<#\:std-ischooklib-libdhcp_lease_query\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Leasequery. T} _ T{ \fBkea\-dhcp4.leases\fP, \fBkea\-dhcp6.leases\fP T} T{ core T} T{ توسط سرور DHCP برای ثبت پیام‌های مرتبط با تخصیص اجاره به کار می‌رود. این پیام‌ها شامل اطلاعات دقیق دربارهٔ اجاره‌های تخصیص‌یافته یا ارائه‌شده، خطاها در طول تخصیص اجاره و غیره می‌باشند. T} _ T{ \fBkea\-dhcp4.legal\-log\-hooks\fP, \fBkea\-dhcp6.legal\-log\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_legal_log.so\fP \%<#\:std-ischooklib-libdhcp_legal_log\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Forensic Logging. T} _ T{ \fBkea\-dhcp4.mysql\-cb\-hooks\fP, \fBkea\-dhcp6.mysql\-cb\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_mysql.so\fP \%<#\:std-ischooklib-libdhcp_mysql\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب MySQL Configuration Backend. T} _ T{ \fBkea\-dhcp4.mysql\-hb\-hooks\fP, \fBkea\-dhcp6.mysql\-hb\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_mysql.so\fP \%<#\:std-ischooklib-libdhcp_mysql\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب MySQL Host Backend. T} _ T{ \fBkea\-dhcp4.mysql\-lb\-hooks\fP, \fBkea\-dhcp6.mysql\-lb\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_mysql.so\fP \%<#\:std-ischooklib-libdhcp_mysql\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب MySQL Lease Backend. T} _ T{ \fBkea\-dhcp4.options\fP, \fBkea\-dhcp6.options\fP T} T{ core T} T{ توسط سرور DHCP برای ثبت پیام‌های مربوط به پردازش گزینه‌ها در پیام‌های DHCP به کار می‌رود؛ مانند تجزیهٔ گزینه‌ها، کدگذاری گزینه‌ها به قالب on\-wire، و دسته‌بندی بسته‌ها با استفاده از گزینه‌های موجود در بسته‌های دریافتی. T} _ T{ \fBkea\-dhcp4.packets\fP, \fBkea\-dhcp6.packets\fP T} T{ core T} T{ بیشتر برای ثبت پیام‌های مرتبط با انتقال بسته‌های DHCP استفاده می‌شود؛ یعنی دریافت بسته و ارسال پاسخ. چنین پیام‌هایی شامل اطلاعاتی دربارهٔ نشانی‌های IP مبدأ و مقصد و رابط‌های مورد استفاده برای انتقال بسته‌ها هستند. این ثبت‌کننده همچنین برای ثبت پیام‌های مرتبط با انتخاب زیرشبکه به کار می‌رود، چرا که این انتخاب معمولاً بر اساس نشانی‌های IP، نشانی‌های رله، و/یا نام رابط‌ها صورت می‌گیرد که می‌توان آن‌ها را حتی پیش از تجزیه شدن پیام DHCP درون بسته، از بستهٔ دریافتی استخراج کرد. T} _ T{ \fBkea\-dhcp4.perfmon\-hooks\fP, \fBkea\-dhcp6.perfmon\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_perfmon.so\fP \%<#\:std-ischooklib-libdhcp_perfmon\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Performance Monitoring. T} _ T{ \fBkea\-dhcp4.ping\-check\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_ping_check.so\fP \%<#\:std-ischooklib-libdhcp_ping_check\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Ping Check. T} _ T{ \fBkea\-dhcp4.pgsql\-cb\-hooks\fP, \fBkea\-dhcp6.pgsql\-cb\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_pgsql.so\fP \%<#\:std-ischooklib-libdhcp_pgsql\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب PostgreSQL Configuration Backend. T} _ T{ \fBkea\-dhcp4.pgsql\-hb\-hooks\fP, \fBkea\-dhcp6.pgsql\-hb\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_pgsql.so\fP \%<#\:std-ischooklib-libdhcp_pgsql\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب PostgreSQL Host Backend. T} _ T{ \fBkea\-dhcp4.pgsql\-lb\-hooks\fP, \fBkea\-dhcp6.pgsql\-lb\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_pgsql.so\fP \%<#\:std-ischooklib-libdhcp_pgsql\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب PostgreSQL Lease Backend. T} _ T{ \fBkea\-dhcp4.run\-script\-hooks\fP, \fBkea\-dhcp6.run\-script\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_run_script.so\fP \%<#\:std-ischooklib-libdhcp_run_script\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Run Script. T} _ T{ \fBkea\-dhcp4.radius\-hooks\fP, \fBkea\-dhcp6.radius\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_radius.so\fP \%<#\:std-ischooklib-libdhcp_radius\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب RADIUS. T} _ T{ \fBkea\-dhcp4.stat\-cmds\-hooks\fP, \fBkea\-dhcp6.stat\-cmds\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_stat_cmds.so\fP \%<#\:std-ischooklib-libdhcp_stat_cmds\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Statistics Commands. به طور کلی، این پیام‌ها مربوط به بارگذاری و تخلیهٔ کتابخانه و اجرای دستورها توسط کتابخانه هستند. T} _ T{ \fBkea\-dhcp4.subnet\-cmds\-hooks\fP, \fBkea\-dhcp6.subnet\-cmds\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_subnet_cmds.so\fP \%<#\:std-ischooklib-libdhcp_subnet_cmds\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Subnet Commands. به طور کلی، این پیام‌ها مربوط به بارگذاری و تخلیهٔ کتابخانه و اجرای دستورها توسط کتابخانه هستند. T} _ T{ \fBkea\-dhcp4.tcp\fP, \fBkea\-dhcp6.tcp\fP T} T{ core T} T{ برای ثبت پیام‌های مرتبط با ترافیک TCP. T} _ T{ \fBkea\-dhcp4.user_chk\fP, \fBkea\-dhcp6.user_chk\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibdhcp_user_chk.so\fP \%<#\:std-ischooklib-libdhcp_user_chk\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب User Check. T} _ T{ \fBkea\-dhcp\-ddns\fP T} T{ core T} T{ ثبت‌کنندهٔ ریشه برای دیمن \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>\&. تمام مؤلفه‌های مورد استفاده توسط این دیمن تنظیمات را از این ثبت‌کننده به ارث می‌برند، مگر اینکه پیکربندی‌هایی برای ثبت‌کننده‌های تخصصی‌تر وجود داشته باشد. T} _ T{ \fBkea\-dhcp\-ddns.dctl\fP T} T{ core T} T{ برای ثبت اطلاعات اولیه دربارهٔ فرآیند، سیگنال‌های دریافتی، و پیکربندی‌های مجدد فراخوانی‌شده. T} _ T{ \fBkea\-dhcp\-ddns.asiodns\fP T} T{ core T} T{ برای ثبت پیام‌ها دربارهٔ رخدادهای شبکه در عملیات DDNS. T} _ T{ \fBkea\-dhcp\-ddns.dhcpddns\fP T} T{ core T} T{ توسط دیمن \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> برای ثبت رخدادهای مرتبط با عملیات DDNS استفاده می‌شود. T} _ T{ \fBkea\-dhcp\-ddns.dhcp\-to\-d2\fP T} T{ core T} T{ توسط دیمن \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> برای ثبت اطلاعات دربارهٔ رخدادهای مربوط به دریافت پیام‌ها از سرورهای DHCP و افزودن آن‌ها به صف پردازش استفاده می‌شود. T} _ T{ \fBkea\-dhcp\-ddns.d2\-to\-dns\fP T} T{ core T} T{ توسط دیمن \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> برای ثبت اطلاعات دربارهٔ رخدادهای مربوط به ارسال و دریافت پیام‌ها به و از سرورهای DNS استفاده می‌شود. T} _ T{ \fBkea\-dhcp\-ddns.gss\-tsig\-hooks\fP T} T{ کتابخانهٔ قلاب متن‌باز \fBlibddns_gss_tsig.so\fP \%<#\:std-ischooklib-libddns_gss_tsig\:.so> T} T{ برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب GSS\-TSIG. T} _ T{ \fBkea\-dhcp\-ddns.libdhcp\-ddns\fP T} T{ core T} T{ برای ثبت رخدادهای مرتبط با عملیات DDNS استفاده می‌شود. T} _ T{ \fBkea\-netconf\fP T} T{ core T} T{ ثبت‌کنندهٔ ریشه برای عامل NETCONF. تمام مؤلفه‌های مورد استفادهٔ NETCONF تنظیمات را از این ثبت‌کننده به ارث می‌برند در صورتی که ثبت‌کنندهٔ تخصصی‌تری ارائه نشده باشد. T} .TE .sp توجه داشته باشید که کتابخانه‌های قلابِ تعریف‌شده توسط کاربر نباید از هیچ‌یک از ثبت‌کننده‌های ذکرشده در بالا استفاده کنند، بلکه باید ثبت‌کننده‌های جدیدی با نام‌هایی متناسب با کتابخانه‌های استفاده‌کننده از آن‌ها تعریف نمایند. فرض کنید کاربری کتابخانه‌ای به نام «libdhcp\-packet\-capture» ایجاد کرده است تا بسته‌های دریافتی و ارسالی توسط سرور را در یک فایل ذخیره کند. نام مناسب برای این ثبت‌کننده می‌تواند \fBkea\-dhcp4.packet\-capture\-hooks\fP\& باشد. (توجه داشته باشید که پیاده‌ساز کتابخانهٔ قلاب تنها بخش دوم این نام، یعنی «packet\-capture» را مشخص می‌کند؛ بخش اول نام ثبت‌کنندهٔ ریشه است و توسط سامانهٔ ثبت رخداد Kea به ابتدای آن افزوده می‌شود). همچنین ذکر این نکته حائز اهمیت است که چون این ثبت‌کنندهٔ جدید فرزندی از یک ثبت‌کنندهٔ ریشه است، پیکربندی را از ثبت‌کنندهٔ ریشه به ارث می‌برد؛ امری که می‌توان با ایجاد مدخلی در فایل پیکربندی آن را بازنویسی کرد. .sp ساده‌ترین راه برای یافتن نام یک ثبت‌کننده این است که تمام عملیات ثبت رخداد را طوری پیکربندی کنید که به یک مقصد واحد ارسال شود و در آن‌جا به دنبال نام‌های ثبت‌کنندهٔ خاص بگردید. برای جزئیات بیشتر به بخش «قالب پیام‌های ثبت» (Logging Message Format) مراجعه کنید..SS ثبت‌کننده \fBseverity\fP (رشته) .sp این مورد ردهٔ پیام‌های ثبت‌شده را مشخص می‌کند. هر پیام به همراه یک سطح اهمیت مرتبط ثبت می‌شود که ممکن است یکی از موارد زیر باشد (به ترتیب نزولی سطح اهمیت): .INDENT 0.0 .IP \(bu 2 FATAL \- مرتبط با پیام‌های تولیدشده در شرایطی که آن‌چنان وخیم است که کارساز نمی‌تواند به اجرای خود ادامه دهد. .IP \(bu 2 ERROR \- مرتبط با پیام‌های تولیدشده در وضعیت خطا. کارساز به اجرای خود ادامه می‌دهد، اما نتایج ممکن است مطابق انتظار نباشد. .IP \(bu 2 WARN \- بیانگر یک وضعیت غیرعادی است. با این حال، کارساز به طور عادی به اجرای خود ادامه می‌دهد. .IP \(bu 2 INFO \- یک پیام اطلاع‌رسانی که نشان‌دهندهٔ وقوع یک رویداد است. .IP \(bu 2 DEBUG \- پیام‌های تولیدشده برای اهداف اشکال‌زدایی. .UNINDENT .sp هنگامی که سطح اهمیت یک ثبت‌کننده روی یکی از این مقادیر تنظیم شود، تنها پیام‌های مربوط به همان سطح و سطوح بالاتر ثبت می‌شوند (برای مثال، تنظیم سطح اهمیت گزارش‌گیری روی INFO باعث ثبت پیام‌های INFO، WARN، ERROR و FATAL می‌شود). همچنین می‌توان سطح اهمیت را روی NONE تنظیم کرد که در این صورت از ثبت تمامی پیام‌های آن ثبت‌کننده جلوگیری می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 ابزار \fBkeactrl\fP \%<#\:std-iscman-keactrl>، که در «مدیریت Kea با keactrl» \%<#\:keactrl> شرح داده شده است، می‌تواند طوری پیکربندی شود که کارسازها را در حالت پرحرف (verbose) راه‌اندازی کند. در این صورت، تنظیمات سطح اهمیت گزارش‌گیری در فایل پیکربندی هیچ اثری نخواهد داشت؛ کارسازها بدون توجه به تنظیمات گزارش‌گیری مشخص‌شده در فایل پیکربندی، از سطح اهمیت DEBUG استفاده می‌کنند. برای کنترل سطح اهمیت از طریق فایل پیکربندی، لطفاً مطمئن شوید که مقدار \fBkea_verbose\fP درون پیکربندی \fBkeactrl\fP \%<#\:std-iscman-keactrl> روی \(dqno\(dq تنظیم شده باشد. .UNINDENT .UNINDENT .SS ثبت‌کننده \fBdebuglevel\fP (عدد صحیح) .sp هنگامی که سطح اهمیت یک ثبت‌کننده روی DEBUG تنظیم شده باشد، این مقدار سطح پیام‌های اشکال‌زدایی برای چاپ را مشخص می‌کند. این مقدار در بازهٔ 0 (کمترین جزئیات) تا 99 (بیشترین جزئیات) قرار دارد. اگر سطح اهمیت ثبت‌کننده روی DEBUG نباشد، این مقدار نادیده گرفته می‌شود. .SS ثبت‌کننده \fBoutput\-options\fP (فهرست) .sp هر ثبت‌کننده می‌تواند صفر یا چند \fBoutput\-options\fP داشته باشد. این گزینه‌ها محل ارسال پیام‌های گزارش را مشخص می‌کنند و در ادامه به تفصیل توضیح داده شده‌اند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نام مستعار \fBoutput\-options\fP در Kea 2.5.1 اضافه شد تا بتوان آن را به‌جای کلید پیکربندی قبلی یعنی \fBoutput_options\fP به کار برد. این کار برای حفظ یکپارچگی تمامی کلیدهای پیکربندی انجام شد، یعنی استفاده از خط تیره (\fI\-\fP) به جای زیرخط (\fI_\fP) در نام کلید. .sp از نسخهٔ Kea 2.5.2، کلید \fBoutput\-options\fP به کلید پیکربندی پیش‌فرض تبدیل شده و از \fBoutput_options\fP می‌توان به عنوان یک نام مستعار استفاده کرد. .sp از نسخهٔ Kea 2.7.4، کلید پیکربندی \fBoutput_options\fP منسوخ شده است و در نسخه‌های آینده حذف خواهد شد. لطفاً با جایگزین کردن آن با \fBoutput\-options\fP، پیکربندی خود را به‌روزرسانی کنید. .UNINDENT .UNINDENT .SS گزینهٔ \fBoutput\fP (رشته) .sp این مقدار نوع خروجی را تعیین می‌کند. چندین مقدار خاص در اینجا مجاز هستند: \fBstdout\fP (پیام‌ها روی خروجی استاندارد چاپ می‌شوند)، \fBstderr\fP (پیام‌ها روی خطای استاندارد چاپ می‌شوند)، \fBsyslog\fP (پیام‌ها با استفاده از نام پیش‌فرض در syslog ثبت می‌شوند)، \fBsyslog:name\fP (پیام‌ها با استفاده از نام مشخص‌شده در syslog ثبت می‌شوند). هر مقدار دیگری به عنوان نام فایلی که پیام‌ها باید در آن نوشته شوند تفسیر می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخهٔ Kea 2.7.9، فایل‌های گزارش تنها می‌توانند در پوشهٔ خروجی تعیین‌شده در حین کامپایل نوشته شوند: \fB\(dq[kea\-install\-dir]/var/log/kea\(dq\fP\&. این مسیر را می‌توان در زمان راه‌اندازی با تنظیم متغیر محیطی \fBKEA_LOG_FILE_DIR\fP روی مسیر دلخواه بازنویسی کرد. اگر مسیری غیر از این مقدار در \fBoutput\fP استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی خودداری می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌جبران ثبت خواهد کرد. برای سهولت در استفاده، کافی است بخش مسیر را از \fBoutput\fP حذف کرده و فقط نام فایل را مشخص کنید. .UNINDENT .UNINDENT .SS گزینهٔ \fBflush\fP (بولی) .sp این گزینه بافرها را پس از هر پیام گزارش تخلیه می‌کند. انجام این کار کارایی را کاهش می‌دهد اما تضمین می‌کند که در صورت خاتمهٔ غیرعادی برنامه، تمامی پیام‌ها تا لحظهٔ خاتمه ثبت شوند. مقدار پیش‌فرض \fBtrue\fP است. .SS گزینهٔ \fBmaxsize\fP (عدد صحیح) .sp این گزینه تنها زمانی که مقصد یک فایل باشد کاربرد دارد؛ این مقدار حداکثر اندازه‌ای به بایت است که یک فایل گزارش می‌تواند داشته باشد. هنگامی که اندازه به حداکثر رسید، نام فایل تغییر یافته و یک فایل جدید ایجاد می‌شود. در ابتدا یک \(dq.1\(dq به انتهای نام افزوده می‌شود؛ اگر فایلی با پسوند \(dq.1\(dq وجود داشته باشد، نام آن به \(dq.2\(dq تغییر می‌یابد و به همین ترتیب ادامه پیدا می‌کند. به این فرآیند چرخش گفته می‌شود. .sp مقدار پیش‌فرض 10240000 (۱۰ مگابایت) است. کوچک‌ترین مقداری که می‌توان بدون غیرفعال کردن چرخش تعیین کرد، 204800 است. هر مقداری کمتر از این مقدار، از جمله 0، چرخش را غیرفعال می‌کند. بزرگ‌ترین مقدار ممکن INT_MAX مگابایت است که تقریباً برابر با ۲ پتابایت می‌باشد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 به دلیل محدودیتی در کتابخانهٔ گزارش‌گیری زیربنایی (log4cplus)، چرخش فایل‌های گزارش (از \(dq.1\(dq به \(dq.2\(dq و غیره) ممکن است نتایج عجیبی نشان دهد؛ ممکن است در زمان چرخش، چندین فایل کوچک وجود داشته باشند. این امر زمانی رخ می‌دهد که چندین فرآیند تلاش کنند فایل‌ها را به طور هم‌زمان بچرخانند. نسخهٔ 1.1.0 کتابخانهٔ log4cplus این مشکل را برطرف کرد، بنابراین اگر برای ساخت Kea از این نسخه یا نسخه‌های جدیدتر log4cplus استفاده شود، این مشکل نباید رخ دهد. حتی با نسخه‌های قدیمی‌تر نیز انتظار می‌رود که این مسئله به ندرت رخ دهد، مگر اینکه پیام‌های گزارش با بسامد بسیار بالا توسط چندین فرآیند مختلف تولید شوند. .UNINDENT .UNINDENT.SS گزینهٔ \fBmaxver\fP (عدد صحیح) .sp این گزینه تنها زمانی کاربرد دارد که مقصد یک فایل بوده و چرخش فعال باشد (یعنی \fBmaxsize\fP به اندازهٔ کافی بزرگ باشد). این پارامتر، حداکثر تعداد نسخه‌های چرخیده‌ای است که نگهداری می‌شوند. هنگامی که تعداد فایل‌ها به این حد نصاب برسد، در هر بار چرخش لاگ، قدیمی‌ترین فایل، یعنی \(dqlog\-name.maxver\(dq، دور ریخته می‌شود. به عبارت دیگر، حداکثر فایل لاگ فعال به همراه \fBmaxver\fP فایل چرخیده وجود خواهد داشت. کمترین مقدار و مقدار پیش‌فرض ۱ است. .SS گزینهٔ \fBpattern\fP (رشته) .sp از این گزینه می‌توان برای مشخص کردن الگوی چیدمان پیام‌ها برای یک ثبت‌کننده (logger) استفاده کرد. سیستم ثبت گزارش Kea با استفاده از کتابخانهٔ log4cplus پیاده‌سازی شده و قالب‌بندی خروجی آن، از نظر مفهومی بر پایهٔ قالب‌بندی printf در زبان C است؛ این موضوع با جزئیات در بخش بعدی، قالب پیام‌های ثبت وقایع، بررسی شده است\&. .sp هر نوع خروجی (\fBstdout\fP، فایل یا \fBsyslog\fP) یک \fBpattern\fP پیش‌فرض دارد که محتوای پیام‌های لاگ آن را شرح می‌دهد. از این پارامتر می‌توان برای مشخص کردن الگوی دلخواه استفاده کرد. الگوی هر ثبت‌کننده به صورت جداگانه تعیین می‌شود، بنابراین هر ثبت‌کنندهٔ پیکربندی‌شده می‌تواند الگوی مخصوص به خود را داشته باشد. حذف کردن پارامتر \fBpattern\fP یا مقداردهی آن با یک رشتهٔ خالی، \(dq\(dq، باعث می‌شود Kea از الگوی پیش‌فرض برای نوع خروجی آن ثبت‌کننده استفاده کند. .sp علاوه بر خود متن لاگ، الگوهای پیش‌فرض استفاده‌شده برای \fBstdout\fP و فایل‌ها حاوی اطلاعاتی نظیر تاریخ و زمان، سطح ثبت‌کننده و اطلاعات فرایند هستند. الگوی پیش‌فرض برای \fBsyslog\fP عمدتاً به سطح لاگ، منبع و متن لاگ محدود می‌شود. این امر از تکرار اطلاعاتی که معمولاً توسط syslog ارائه می‌شوند جلوگیری می‌کند. .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 اکیداً به کاربران توصیه می‌شود که الگو(های) خود را بر روی یک نمونهٔ محلی و غیرعملیاتی از Kea که در پیش‌زمینه اجرا شده و لاگ‌ها را در \fBstdout\fP می‌نویسد، آزمایش کنند\&. .UNINDENT .UNINDENT .SS قالب پیام‌های ثبت وقایع .sp همان‌طور که در بالا اشاره شد، محتوای پیام لاگ Kea از طریق ساختاری شبیه به قالب‌بندی printf در زبان C کنترل می‌شود. «الگو» (\(dqpattern\(dq) استفاده‌شده برای هر پیام، با رشته‌ای توصیف می‌شود که حاوی یک یا چند جزء قالب‌بندی به عنوان بخشی از یک رشتهٔ متنی است. این رشته علاوه بر اجزا می‌تواند شامل هر متن مفید دیگری برای مدیر سیستم نیز باشد. .sp رفتار رشته‌های قالب‌بندی Kea توسط log4cplus تعیین می‌شود. گزینه‌های قالب‌بندی زمان زیر درون \fB%D{}\fP یا \fB%d{}\fP امکان‌پذیر هستند: .SS فهرست اجزای رشته‌های قالب زمان پشتیبانی‌شده توسط ثبت‌کنندهٔ Kea .TS box center; l|l. T{ جزء T} T{ مقدار T} _ T{ \fB%a\fP T} T{ نام اختصاری روز هفته T} _ T{ \fB%A\fP T} T{ نام کامل روز هفته T} _ T{ \fB%b\fP T} T{ نام اختصاری ماه T} _ T{ \fB%B\fP T} T{ نام کامل ماه T} _ T{ \fB%c\fP T} T{ رشتهٔ استاندارد تاریخ و زمان T} _ T{ \fB%d\fP T} T{ روزِ ماه به صورت ده‌دهی (1\-31) T} _ T{ \fB%H\fP T} T{ ساعت (0\-23) T} _ T{ \fB%I\fP T} T{ ساعت (1\-12) T} _ T{ \fB%j\fP T} T{ روزِ سال به صورت ده‌دهی (1\-366) T} _ T{ \fB%m\fP T} T{ ماه به صورت ده‌دهی (1\-12) T} _ T{ \fB%M\fP T} T{ دقیقه به صورت ده‌دهی (0\-59) T} _ T{ \fB%p\fP T} T{ معادل محلی (locale) برای AM یا PM T} _ T{ \fB%q\fP T} T{ میلی‌ثانیه به صورت ده‌دهی (0\-999) T} _ T{ \fB%Q\fP T} T{ میکروثانیه به صورت ده‌دهی (0\-999.999) T} _ T{ \fB%S\fP T} T{ ثانیه به صورت ده‌دهی (0\-59) T} _ T{ \fB%U\fP T} T{ هفتهٔ سال، با یکشنبه به عنوان روز نخست (0\-53) T} _ T{ \fB%w\fP T} T{ روز هفته به صورت ده‌دهی (0\-6، یکشنبه برابر 0 است) T} _ T{ \fB%W\fP T} T{ هفتهٔ سال، با دوشنبه به عنوان روز نخست (0\-53) T} _ T{ \fB%x\fP T} T{ رشتهٔ استاندارد تاریخ T} _ T{ \fB%X\fP T} T{ رشتهٔ استاندارد زمان T} _ T{ \fB%y\fP T} T{ سال به صورت ده‌دهی بدون قرن (0\-99) T} _ T{ \fB%Y\fP T} T{ سال به صورت ده‌دهی شامل قرن T} _ T{ \fB%Z\fP T} T{ نام منطقهٔ زمانی T} _ T{ \fB%%\fP T} T{ علامت درصد T} .TE .sp برای اطلاعات بیشتر، به مستندات تابع \fBstrftime()\fP موجود در هدر \fB\fP یا صفحهٔ راهنمای یونیکس \fBstrftime(3)\fP مراجعه کنید. .sp احتمالاً ساده‌ترین راه برای درک این موضوع، بررسی الگوی پیش‌فرض برای \fBstdout\fP و فایل‌ها است؛ در حال حاضر هر دوی آن‌ها یکسان هستند. این الگو در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dq%D{%Y\-%m\-%d %H:%M:%S.%q} %\-5p [%c/%i.%t] %m\en\(dq .EE .UNINDENT .UNINDENT .sp و یک لاگ معمول تولیدشده توسط این الگو چیزی شبیه به این خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX 2019\-08\-05 14:27:45.871 DEBUG [kea\-dhcp4.dhcpsrv/8475.12345] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim\-expired\-leases .EE .UNINDENT .UNINDENT .sp که به صورت زیر تفکیک می‌شود: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0.IP \(bu 2 \fB%D{%Y\-%m\-%d %H:%M:%S.%q}\fP عبارت \(dq%D\(dq تاریخ و زمان محلی هنگام تولید پیام گزارش است، در حالی که همه چیز میان آکولادها، \(dq{}\(dq، مؤلفه‌های تاریخ و زمان هستند. بر اساس گزارش نمونه بالا، این عبارت مقدار زیر را تولید می‌کند: \fB2019\-08\-05 14:27:45.871\fP .IP \(bu 2 \fB%\-5p\fP میزان شدت پیام، که در حداقل پنج نویسه با استفاده از فاصله‌گذاری از راست (right-padding) با فاصله‌ها در خروجی درج می‌شود. در گزارش نمونه ما: \fBDEBUG\fP .IP \(bu 2 \fB%c\fP منبع گزارش. این مورد شامل دو بخش است: فرایند Kea تولیدکننده پیام، در این مورد، \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>؛ و مؤلفه درون برنامه‌ای که پیام از آن صادر شده است، \fBdhcpsrv\fP (برای مثال نام کتابخانه استفاده‌شده توسط پیاده‌سازی‌های کارگزار DHCP). .IP \(bu 2 \fB%i\fP شناسه فرایند (PID). از گزارش نمونه: \fB8475\fP\&. .IP \(bu 2 \fB%t\fP شناسه ریسه (thread ID). از گزارش نمونه: \fB12345\fP\&. قالب شناسه ریسه به سیستم‌عامل وابسته است: برای مثال در برخی سیستم‌ها یک آدرس است، بنابراین در مبنای شانزده (هگزادسیمال) نمایش داده می‌شود. .IP \(bu 2 \fB%m\fP خود متن پیام گزارش. تمام پیام‌های گزارش Kea با یک شناسه پیام شروع شده و به دنبال آن متن دلخواه گزارش می‌آید. هر پیام در Kea دارای یک شناسه یکتا است که می‌تواند به عنوان نمایه‌ای برای راهنمای پیام‌های Kea \%<#\:kea-messages> استفاده شود، جایی که می‌توان اطلاعات بیشتری کسب کرد. در گزارش نمونه بالا، شناسه عبارت است از \fBDHCPSRV_TIMERMGR_START_TIMER\fP\&. متن گزارش معمولاً شرح مختصری با جزئیات شرایطی است که باعث ثبت گزارش شده است. در نمونه ما، اطلاعات ثبت‌شده، \fBstarting timer: reclaim\-expired\-leases\fP، توضیح می‌دهد که زمان‌سنج مربوط به چرخه بازپس‌گیری اجاره‌های منقضی‌شده شروع شده است. .UNINDENT .UNINDENT .UNINDENT .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 حذف \fB%m\fP متن پیام گزارش را از خروجی حذف کرده و آن را تا حدودی بی‌فایده می‌سازد. \fB%m\fP باید اجباری در نظر گرفته شود. .UNINDENT .UNINDENT .sp در نهایت، توجه داشته باشید که فاصله‌گذاری بین مؤلفه‌ها، کروشه‌های دور منبع گزارش و PID، و نویسه بازگشت به خط بعد پایانی \fB\en\fP همگی متن‌های عینی هستند که به عنوان بخشی از الگو مشخص شده‌اند. .sp \fBهشدار:\fP .INDENT 0.0 .INDENT 3.5 برای اطمینان از اینکه هر مدخل گزارش در یک خط جداگانه قرار می‌گیرد، الگوها باید به یک \fB\en\fP ختم شوند\&. ممکن است سناریوهایی وجود داشته باشد که این امر مطلوب نباشد، بنابراین گنجاندن آن را اجباری نمی‌کنیم. اگر این مورد از الگو حذف شود، ورودی‌های گزارش در یک \(dqخط\(dq طولانی و به هم پیوسته قرار خواهند گرفت. .UNINDENT .UNINDENT .sp الگوی پیش‌فرض برای خروجی \fBsyslog\fP عبارت است از: .INDENT 0.0 .INDENT 3.5 .sp .EX \(dq%\-5p [%c.%t] %m\en\(dq .EE .UNINDENT .UNINDENT .sp این الگو تاریخ و زمان و همچنین شناسه فرایند را حذف می‌کند، زیرا این اطلاعات معمولاً توسط \fBsyslog\fP در خروجی قرار داده می‌شوند\&. توجه داشته باشید که Kea از این الگو برای ساختن متنی که به \fBsyslog\fP (یا هر مقصد دیگری) می‌فرستد، استفاده می‌کند. این مورد هیچ تأثیری بر محتوایی که ممکن است \fBsyslog\fP اضافه کند یا قالب‌بندی که ممکن است انجام دهد، ندارد. .sp برای بررسی رفتار \fBsyslog\fP به مستندات سیستم‌عامل مراجعه کنید، زیرا پیاده‌سازی‌های متعددی از آن وجود دارد. .sp فهرست کاملی از پارامترهای گزارش‌گیری پشتیبانی‌شده توسط Kea در جدول زیر نشان داده شده است: .SS فهرست مؤلفه‌های رشته قالب‌بندی پشتیبانی‌شده توسط ثبت‌کننده Kea .TS box center; l|l. T{ مؤلفه T} T{ مقدار T} _ T{ \fB%b\fP T} T{ فایلی که گزارش را فراخوانی کرده در خروجی می‌آورد، مثلاً logger_impl.cc T} _ T{ \fB%c\fP T} T{ ثبت‌کننده (logger) رویداد را در خروجی می‌آورد، مثلاً kea\-dhcp4.hosts T} _ T{ \fB%d\fP T} T{ الگوی \fB%d{}\fP خروجی زمان UTC را قالب‌بندی می‌کند، مثلاً \fB%d{%Y\-%m\-%d %H:%M:%S.%q}\fP T} _ T{ \fB%D\fP T} T{ الگوی \fB%D{}\fP خروجی زمان محلی (LOCAL) را قالب‌بندی می‌کند، مثلاً \fB%D{%Y\-%m\-%d %H:%M:%S.%q}\fP T} _ T{ \fB%E\fP T} T{ متغیرهای محیط را در خروجی می‌آورد، مثلاً \fB%E{PATH}\fP T} _ T{ \fB%F\fP T} T{ نام فایلی که درخواست گزارش از آنجا صادر شده را در خروجی می‌آورد، مثلاً logger_impl.cc T} _ T{ \fB%h\fP T} T{ نام میزبان سیستم را در خروجی می‌آورد، مثلاً host\-1 T} _ T{ \fB%H\fP T} T{ نام دامنه کاملاً مشخص (FQDN) را در خروجی می‌آورد، مثلاً host\-1.example.com T} _ T{ \fB%l\fP T} T{ معادل \fB%F:%L\fP است، مثلاً logger_impl.cc:179 T} _ T{ \fB%L\fP T} T{ شماره خطی که گزارش در آن فراخوانی شده را در خروجی می‌آورد، مثلاً 179 T} _ T{ \fB%m\fP T} T{ پیام واقعی گزارش را در خروجی می‌آورد T} _ T{ \fB%M\fP T} T{ فراخواننده (نام تابع) پیام گزارش را در خروجی می‌آورد T} _ T{ \fB%n\fP T} T{ جداکننده خط پشتیبانی‌شده توسط سیستم‌عامل را در خروجی می‌آورد، مثلاً \fB\en\fP در Linux T} _ T{ \fB%p\fP T} T{ میزان شدت گزارش را در خروجی می‌آورد، مثلاً INFO T} _ T{ \fB%r\fP T} T{ میلی‌ثانیه‌های سپری‌شده از شروع برنامه را در خروجی می‌آورد، مثلاً 1235 T} _ T{ \fB%t\fP T} T{ شناسه ریسه‌ای (thread ID) را که پیام گزارش را تولید کرده در خروجی می‌آورد، مثلاً 281472855306256 T} _ T{ \fB%T\fP T} T{ نام ریسه‌ای را که پیام گزارش را تولید کرده در خروجی می‌آورد، مثلاً 168005 T} _ T{ \fB%i\fP T} T{ شناسه فرایندی (PID) را که پیام گزارش را تولید کرده در خروجی می‌آورد، مثلاً 168030 T} _ T{ \fB%%\fP T} T{ یک علامت درصد واقعی را در خروجی درج می‌کند T} .TE .sp فاصله‌گذاری (Padding) و کوتاه‌سازی (truncation) نیز با استفاده از اصلاح‌کننده‌های قبل از مؤلفه امکان‌پذیر هستند؛ این کار با قرار دادن یک عدد و سایر نویسه‌های اصلاح‌کننده بین مؤلفه و علامت % انجام می‌شود. پنج روش برای اصلاح خروجی وجود دارد: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0.IP \(bu 2 \fB%20p\fP در صورتی که سطح اهمیت (severity) کوتاه‌تر از ۲۰ نویسه باشد، از سمت چپ با فاصله پر می‌شود (راست‌چین). .IP \(bu 2 \fB%\-15r\fP در صورتی که میلی‌ثانیه‌های سپری‌شده از زمان شروع برنامه کوتاه‌تر از ۱۵ نویسه باشد، از سمت راست با فاصله پر می‌شود (چپ‌چین). .IP \(bu 2 \fB%.30m\fP در صورتی که پیام طولانی‌تر از ۳۰ نویسه باشد، از ابتدای پیام برش می‌خورد. .IP \(bu 2 \fB%10.35E{PATH}\fP در صورتی که متغیر محیطی \(dqPATH\(dq کوتاه‌تر از ۱۰ نویسه باشد، از سمت چپ با فاصله پر می‌شود (راست‌چین). اگر طول محتوا بیشتر از ۳۵ نویسه باشد، از ابتدای رشته برش می‌خورد. .IP \(bu 2 \fB%\-15.40m\fP در صورتی که پیام لاگ کوتاه‌تر از ۱۵ نویسه باشد، از سمت راست با فاصله پر می‌شود (چپ‌چین). اگر طول پیام بیشتر از ۴۰ نویسه باشد، از ابتدا برش می‌خورد. .UNINDENT .UNINDENT .UNINDENT .sp پارامترهای پشتیبانی‌شده به نسخه liblog4cplus استفاده‌شده برای کامپایل Kea بستگی دارد، که می‌توان آن را با اجرای دستور \fBkea\-dhcp4 \-W | grep \-i log4cplus\fP\& بررسی کرد. این کار خروجی‌ای مانند \fBLOG4CPLUS_VERSION: 2.0.5\fP\& تولید می‌کند. برای دریافت اطلاعات بیشتر درباره نسخه نصب‌شده، مستندات موجود در ویکی log4cplus را در \% بررسی کنید. .SS "پیکربندی‌های نمونه لاگر (Example Logger Configurations)" .sp در این مثال، می‌خواهیم ثبت گزارش (logging) کارساز را طوری تنظیم کنیم که با استفاده از خروجی استاندارد روی کنسول بنویسد. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqServer\(dq: { \(dqloggers\(dq: [ { \(dqname\(dq: \(dqkea\-dhcp4\(dq, \(dqoutput\-options\(dq: [ { \(dqoutput\(dq: \(dqstdout\(dq } ], \(dqseverity\(dq: \(dqWARN\(dq } ] } .EE .UNINDENT .UNINDENT .sp به عنوان مثال دوم، می‌خواهیم پیام‌های لاگ سطح DEBUG را در فایلی حداکثر با حجم ۲ مگابایت ذخیره کنیم و تا هشت نسخه از فایل‌های لاگ قدیمی را نگه داریم. به محض اینکه اندازه فایل لاگ به ۲ مگابایت برسد، باید تغییر نام داده شده و یک فایل جدید ایجاد شود. .INDENT 0.0 .INDENT 3.5 .sp .EX \(dqServer\(dq: { \(dqloggers\(dq: [ { \(dqname\(dq: \(dqkea\-dhcp6\(dq, \(dqoutput\-options\(dq: [ { \(dqoutput\(dq: \(dq/var/log/kea/kea\-debug.log\(dq, \(dqmaxver\(dq: 8, \(dqmaxsize\(dq: 204800, \(dqflush\(dq: true, \(dqpattern\(dq: \(dq%d{%j %H:%M:%S.%q} %c %m\en\(dq } ], \(dqseverity\(dq: \(dqDEBUG\(dq, \(dqdebuglevel\(dq: 99 } ] } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که پیکربندی بالا از یک الگوی سفارشی استفاده می‌کند که خروجی‌ای مانند زیر تولید می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX 220 13:50:31.783 kea\-dhcp4.dhcp4 DHCP4_STARTED Kea DHCPv4 server version 1.6.0\-beta2\-git started .EE .UNINDENT .UNINDENT .SS "لاگ‌گیری هنگام راه‌اندازی Kea (Logging During Kea Startup)" .sp پیکربندی لاگ‌گیری در فایل پیکربندی مشخص می‌شود. با این حال، هنگامی که Kea شروع به کار می‌کند، فایل پیکربندی تا رسیدن به بخشی از فرایند مقداردهی اولیه خوانده نمی‌شود. پیش از آن، تنظیمات لاگ‌گیری روی مقادیر پیش‌فرض قرار دارند، اگرچه امکان تغییر برخی جنبه‌های تنظیمات با استفاده از متغیرهای محیطی وجود دارد. در صورت عدم وجود هرگونه پیکربندی لاگ‌گیری در فایل پیکربندی، تنظیمات پیکربندی پیش‌فرض (که احتمالاً تغییر یافته است) در تمام طول اجرای برنامه پابرجا می‌ماند. .sp متغیرهای محیطی زیر می‌توانند برای کنترل رفتار لاگ‌گیری در هنگام راه‌اندازی استفاده شوند: .sp \fBKEA_LOCKFILE_DIR\fP .INDENT 0.0 .INDENT 3.5 دایرکتوری‌ای را مشخص می‌کند که سیستم ثبت لاگ باید فایل قفل (lock file) خود را در آن ایجاد کند. در صورت عدم تعیین، مقدار آن prefix/var/run/kea است که در آن \(dqprefix\(dq به طور پیش‌فرض /usr/local می‌باشد. این متغیر نباید با یک اسلش خاتمه یابد. یک مقدار ویژه وجود دارد: \(dqnone\(dq، که به Kea اعلام می‌کند اصلاً فایل قفل ایجاد نکند. این موضوع در صورتی که چند فرایند در یک فایل مشترک لاگ بنویسند ممکن است باعث بروز مشکل شود. .UNINDENT .UNINDENT .sp \fBKEA_LOGGER_DESTINATION\fP .INDENT 0.0 .INDENT 3.5 مقصد خروجی لاگ را مشخص می‌کند. چندین مقدار ویژه وجود دارد: .sp \fBstdout\fP ثبت لاگ در خروجی استاندارد. .sp \fBstderr\fP ثبت لاگ در خطای استاندارد. .sp \fBsyslog[:fac]\fP ثبت لاگ از طریق syslog. بخش اختیاری \(dqfac\(dq (که با دونقطه از کلمه \(dqsyslog\(dq جدا می‌شود) تسهیلات (facility) مورد استفاده برای پیام‌های لاگ را مشخص می‌کند. در صورت عدم تعیین، پیام‌ها با استفاده از تسهیلات \(dqlocal0\(dq ثبت می‌شوند. .sp هر مقدار دیگری به عنوان نام فایل خروجی در نظر گرفته می‌شود. اگر وضعیت دیگری تعیین نشده باشد، Kea در خروجی استاندارد لاگ می‌اندازد. .UNINDENT .UNINDENT.SS "سطوح ثبت وقایع (Logging Levels)" .sp تمام کارسازهای Kea از این رویکرد کلی پیروی می‌کنند که بدون تحمیل بار اضافی و اطلاعات بیش از حد به سیستم ثبت وقایع (logging)، کاربر را از رویدادهای جاری آگاه سازند؛ چرا که بارگذاری بیش از حد می‌تواند به سادگی به عنوان حمله‌ای از نوع محروم‌سازی از سرویس (denial\-of\-service) مورد سوءاستفاده قرار گیرد. .sp برخلاف سطوح FATAL، ERROR، WARN و INFO، سطح DEBUG پارامترهای بیشتری دارد. فهرست زیر اطلاعات پایه‌ای را که در هر سطح ثبت می‌شود به تفصیل شرح می‌دهد. گاهی شرایط مشخص می‌کند که یک مورد از اطلاعات در سطحی بالاتر ثبت شود یا پایین‌تر. به عنوان مثال، اگر یک بسته به دلیل دسته‌بندیِ پیکربندی‌شده دور انداخته (drop) شود، این امر ناشی از اجرای سیاست پیکربندی‌شده است و در debuglevel 15 ثبت می‌گردد. با این حال، اگر بسته به دلیل بروز یک استثنا (exception) دور انداخته شود، اهمیت بسیار بیشتری دارد؛ چرا که ممکن است نشان‌دهنده یک باگ نرم‌افزاری، مشکلات جدی در حافظه، یا ایرادات اتصال به پایگاه داده باشد. از این رو ممکن است در سطوح بسیار بالاتری مانند WARN یا حتی ERROR ثبت شود. .INDENT 0.0 .IP \(bu 2 0 \- پیام‌های منفردی که هنگام راه‌اندازی یا خاموش شدن کارساز چاپ می‌شوند. .IP \(bu 2 10 \- ثبت اطلاعات مربوط به دستورات دریافتی API. .IP \(bu 2 15 \- اطلاعات درباره دلایل دور انداخته شدن بسته. .IP \(bu 2 40 \- اطلاعات ردگیری (tracing)، از جمله تصمیمات پردازشی، نتایج ارزیابی عبارت‌ها و موارد بیشتر. .IP \(bu 2 45 \- مشابه سطح 40، اما با جزئیات بیشتر؛ برای مثال، زیرشبکه‌ای که برای یک بسته ورودی انتخاب می‌شود. .IP \(bu 2 50 \- ارزیابی عبارت‌ها، وضعیت دریافتی از نقاط هوک (hook points)، پردازش اجاره (lease)، جزئیات پردازش بسته شامل باز کردن بسته (unpacking)، بسته‌بندی، ارسال و غیره. .IP \(bu 2 55 \- شامل تمام جزئیات در دسترس، از جمله محتوای کامل بسته به همراه چاپ تمام گزینه‌ها. .UNINDENT .sp سطوح دیباگ فقط برای پیام‌های ثبت‌شده در DEBUG اعمال می‌شوند و با استفاده از گزینه \fBdebuglevel\fP پیکربندی می‌گردند. برای جزئیات بیشتر به بخش The debuglevel (integer) Logger مراجعه کنید. .SH "پوسته KEA (THE KEA SHELL)" .SS "نمای کلی پوسته KEA (Overview of the Kea Shell)" .sp کارسازهای Kea یک رابط کنترلی RESTful بر روی HTTP فراهم می‌کنند. معمولاً انتظار می‌رود که این API توسط IPAMهای گوناگون و سیستم‌های مدیریتی مشابه استفاده شود. با این وجود، ممکن است مواردی پیش بیاید که مدیر سیستم بخواهد فرمانی را مستقیماً به کارساز بفرستد، و پوسته Kea راهکاری برای انجام این کار فراهم می‌کند. این ابزار یک کلاینت متنی خط فرمانیِ ساده و سازگار با اسکریپت‌نویسی است که می‌تواند به کارساز متصل شود، دستورها را همراه با پارامترها به آن ارسال کند، پاسخ‌ها را بازیابی کرده و نمایش دهد. .sp از آنجا که هدف اصلی پوسته Kea به کارگیری به عنوان ابزاری در محیط اسکریپت‌نویسی است، تعاملی (interactive) نیست. با این حال، با دنبال کردن دستورالعمل‌های ساده می‌توان آن را به صورت دستی نیز اجرا کرد. .sp نسخه 1.9.0 از Kea پشتیبانی از احراز هویت پایه‌ای HTTP (basic HTTP authentication) را معرفی کرد. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نسخه 2.7.2 از Kea پشتیبانی مستقیم از کانال کنترلی HTTP/HTTPS را توسط کارسازهای Kea (\fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4>، \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> و \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>) معرفی کرده است. ابزار \fBkea\-shell\fP \%<#\:std-iscman-kea-shell> می‌تواند با این کارسازها استفاده شود؛ تنها تفاوت این است که آرگومان \fB\-\-service\fP بی‌فایده شده و توسط کارسازهای Kea نادیده گرفته می‌شود. توجه داشته باشید که نتیجه جهت سازگاری با نسخه‌های پیشین (backward compatibility) در قالب یک لیست کپسوله‌بندی می‌شود. .UNINDENT .UNINDENT .SS "کاربرد پوسته (Shell Usage)" .sp \fBkea\-shell\fP \%<#\:std-iscman-kea-shell> به شکل زیر اجرا می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-shell [\-\-host hostname] [\-\-port number] [\-\-path path] [\-\-auth\-user] [\-\-auth\-password] [\-\-auth\-password\-file] [\-\-timeout seconds] [command] .EE .UNINDENT .UNINDENT .sp که در آن: .INDENT 0.0 .IP \(bu 2 \fB\-\-host hostname\fP نام میزبان (hostname) کارساز را مشخص می‌کند. در صورت عدم تعیین، \(dqlocalhost\(dq استفاده می‌شود. .IP \(bu 2 \fB\-\-port number\fP درگاه (port) TCP را که کارساز روی آن گوش می‌دهد مشخص می‌کند. در صورت عدم تعیین، 8000 استفاده می‌شود. .IP \(bu 2 \fB\-\-path path\fP مسیر موجود در URL را برای اتصال مشخص می‌کند. اگر تعیین نشود، یک مسیر خالی استفاده خواهد شد. از آنجا که کارساز روی مسیر خالی گوش می‌دهد، این پارامتر تنها هنگام استفاده از یک پراکسی معکوس (reverse proxy) کاربرد دارد. .IP \(bu 2 \fB\-\-auth\-user\fP شناسه کاربری را برای احراز هویت پایه‌ای HTTP مشخص می‌کند. اگر تعیین نشود یا به صورت یک رشته خالی مشخص شود، احراز هویت استفاده نخواهد شد. .IP \(bu 2 \fB\-\-auth\-password\fP گذرواژه را برای احراز هویت پایه‌ای HTTP مشخص می‌کند. در صورتی که مشخص نشده باشد اما شناسه کاربری تعیین شده باشد، یک گذرواژه خالی استفاده می‌شود. اگر همراه با \fB\-\-auth\-password\-file\fP به کار رود، نادیده گرفته می‌شود. .IP \(bu 2 \fB\-\-auth\-password\-file\fP یک فایل متنی را مشخص می‌کند که خط اول آن حاوی گذرواژه مورد استفاده برای احراز هویت پایه‌ای HTTP است. این پرچم بر پرچم \fB\-\-auth\-password\fP اولویت دارد. توصیه می‌شود هنگام تنظیم مجوزهای دسترسی برای فایل حاوی گذرواژه احتیاط شود. دسترسی به فایل باید تا حد امکان محدود بوده و تنها به مدیران Kea محدود شود. .IP \(bu 2 \fB\-\-timeout seconds\fP مهلت زمانی (timeout بر حسب ثانیه) را برای اتصال مشخص می‌کند. اگر داده نشود، 10 ثانیه استفاده می‌شود. .IP \(bu 2 \fB\-\-service service\-name\fP اکنون منسوخ شده است اما برای سازگاری با گذشته همچنان شناسایی می‌شود. .IP \(bu 2 \fBcommand\fP دستوری را که باید ارسال شود مشخص می‌کند. در صورت عدم تعیین، دستور \fBlist\-commands\fP \%<#\:std-isccmd-list-commands> استفاده می‌شود. .UNINDENT .sp سایر سوییچ‌ها عبارتند از: .INDENT 0.0 .IP \(bu 2 \fB\-h\fP \- یک پیام راهنما چاپ می‌کند. .IP \(bu 2 \fB\-v\fP \- نسخه Kea را نمایش می‌دهد. .IP \(bu 2 \fB\-V\fP \- نسخه گسترده Kea را نمایش می‌دهد. .UNINDENT .sp برای آرگومان‌های خط فرمان جدید مربوط به پشتیبانی از TLS/HTTPS، به بخش TLS Support مراجعه کنید. .sp پس از اجرا، پوسته پارامترهای دستور را از ورودی استاندارد می‌خواند که انتظار می‌رود در قالب JSON باشند. هنگامی که همه خوانده شدند، پوسته با استفاده از HTTP ارتباطی را با کارساز برقرار می‌کند، دستور را می‌فرستد و منتظر پاسخ می‌ماند. پس از دریافت پاسخ، آن را در خروجی استاندارد نمایش می‌دهد. .sp برای فهرستی از دستورات در دسترس، به Management API \%<#\:ctrl-channel> مراجعه کنید؛ ممکن است دستورات اضافی توسط کتابخانه‌های هوک (hook) ارائه شوند. برای دریافت فهرستی از تمام دستورات پشتیبانی‌شده توسط کارساز، از دستور \fBlist\-commands\fP \%<#\:std-isccmd-list-commands> استفاده کنید. .sp نمونه ساده‌ای از نحوه استفاده در زیر نشان داده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-shell \-\-host 192.0.2.1 \-\-port 8001 \-\-auth\-user foo \-\-auth\-password\-file secret_file list\-commands ^D .EE .UNINDENT .UNINDENT .sp پس از وارد کردن خط فرمان، برنامه منتظر ورود پارامترهای دستور می‌ماند. از آنجا که \fBlist\-commands\fP \%<#\:std-isccmd-list-commands> هیچ آرگومانی نمی‌پذیرد، Ctrl\-D (که در مثال بالا با \(dq^D\(dq نشان داده شده است) بیانگر پایان فایل (end\-of\-file) بوده و ورودی پارامترها را خاتمه می‌دهد. سپس پوسته با کارساز ارتباط برقرار کرده و فهرست دستورات در دسترس بازگردانده‌شده برای کارساز را چاپ می‌کند. .sp پوسته Kea احتمالاً بیشتر در اسکریپت‌ها مورد استفاده قرار خواهد گرفت؛ مثال بعدی یک اجرای اسکریپت‌شده ساده را نشان می‌دهد. این مثال دستور \fBconfig\-write\fP \%<#\:std-isccmd-config-write> را به همراه پارامترهای مشخص‌شده در param.json به کارساز ارسال می‌کند. نتیجه در result.json ذخیره خواهد شد. .INDENT 0.0 .INDENT 3.5 .sp .EX $ cat param.json \(dqfilename\(dq: \(dqmy\-config\-file.json\(dq $ cat param.json | kea\-shell \-\-host 192.0.2.1 config\-write > result.json .EE .UNINDENT .UNINDENT .sp هنگامی که از یک پراکسی معکوس برای تفکیک (de\-multiplex) درخواست‌ها به کارسازهای مختلف استفاده می‌شود، مسیر خالیِ پیش‌فرض در URL کافی نیست؛ بنابراین باید از پارامتر \fB\-\-path\fP استفاده شود. برای نمونه، اگر درخواست‌های ارسال‌شده به مسیر \(dq/kea\(dq به کارساز هدایت شوند، می‌توان این مورد را به کار برد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-shell \-\-host 192.0.2.1 \-\-port 8001 \-\-path kea ... .EE .UNINDENT .UNINDENT .sp پوسته Kea نیازمند نصب بودن Python روی سیستم است. این ابزار با نسخه‌های مختلف Python 3 آزمایش شده است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 از نسخه 2.4.0 کی‌آ به بعد، \fBkea\-shell\fP \%<#\:std-iscman-kea-shell> دیگر از Python 2.7 پشتیبانی نمی‌کند. .UNINDENT .UNINDENT .sp پوسته Kea بیش از آنکه یک کلاینت مدیریتی جدی باشد، با این هدف طراحی شده که نمایانگر قابلیت‌های رابط RESTful (و شاید نمونه‌ای برای افرادی که علاقه‌مند به یکپارچه‌سازی محیط‌های مدیریتی خود با Kea هستند) باشد. بعید است که در آینده به طور چشمگیری توسعه یابد؛ این ابزار یک ابزار ساده است و ساده باقی خواهد ماند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 هنگام استفاده از این ابزار با احراز هویت پایه‌ای HTTP، لطفاً به یاد داشته باشید که آرگومان‌های خط فرمان از دید کاربران محلی پنهان نیستند. .UNINDENT .UNINDENT.SS "پشتیبانی از TLS" .sp ابزار \fBkea\-shell\fP \%<#\:std-iscman-kea-shell> از اتصالات HTTPS پشتیبانی می‌کند؛ پشتیبانی از TLS/HTTPS نیازمند Python 3 است. آرگومان‌های اضافی خط فرمان عبارتند از: .INDENT 0.0 .IP \(bu 2 \fB\-\-ca\fP نام فایل یا دایرکتوری مرجع صدور گواهی (CA) را مشخص می‌کند. در صورت عدم تعیین، از HTTPS استفاده نمی‌شود. .IP \(bu 2 \fB\-\-cert\fP نام فایل گواهی کلید عمومی نهاد نهایی (end\-entity) کاربر را مشخص می‌کند. در صورت تعیین، نام فایل کلید کاربر نیز باید مشخص شود. .IP \(bu 2 \fB\-\-key\fP نام فایل کلید کاربر را مشخص می‌کند. در صورت تعیین، نام فایل گواهی کاربر نیز باید مشخص شود. فایل‌های کلید رمزنگاری‌شده پشتیبانی نمی‌شوند. .UNINDENT .sp برای مثال، یک درخواست پایه HTTPS برای دریافت فهرست دستورات می‌تواند به این صورت باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ kea\-shell \-\-host 127.0.0.1 \-\-port 8000 \-\-ca ./kea\-ca.crt list\-commands .EE .UNINDENT .UNINDENT .SH "یکپارچه‌سازی با سیستم‌های خارجی (INTEGRATION WITH EXTERNAL SYSTEMS)" .sp سامانه Kea پشتیبانی اختیاری از انواع سیستم‌های خارجی مانند RADIUS، NETCONF، YANG و GSS\-TSIG را فراهم می‌آورد. بخش‌های زیر نحوه کامپایل Kea به همراه این قابلیت‌های اضافی و چگونگی پیکربندی آن‌ها را شرح می‌دهند. .SS "YANG/NETCONF" .SS "نمای کلی (Overview)" .sp پروتکل پیکربندی شبکه یا NETCONF، یک پروتکل مدیریت شبکه است که در RFC 6241 \%\& تعریف شده است. این پروتکل از زبان مدل‌سازی YANG، تعریف‌شده در RFC 6020 \%، برای ایجاد روشی یکپارچه جهت مدیریت ساختار نحوی پیکربندی دستگاه‌های مختلف شبکه بهره می‌برد. Kea پشتیبانی اختیاری از یک رابط YANG/NETCONF را از طریق عامل \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> فراهم می‌کند. .SS "نصب NETCONF" .sp برای دستیابی به قابلیت‌های NETCONF، نرم‌افزار Kea به نسخه‌های v3 از libyang و Sysrepo نیاز دارد. نسخه‌های خاصی که به طور کامل با Kea آزمایش شده‌اند عبارتند از: .INDENT 0.0 .IP \(bu 2 libyang v3.13.5 (کامیت efe43e3790822a3dc64d7d28db935d03fff8b81f) .IP \(bu 2 sysrepo v3.7.11 (کامیت 1b720b196f630f348d9e0c131d326b3fb8c6aca7) .IP \(bu 2 libyang\-cpp v3 (کامیت f3cd4e05462a16e81d6bfd0c4a5b385cf88a8549) .IP \(bu 2 sysrepo\-cpp v3 (کامیت fe4edfa3998fdf312099ee1fb08a06983b6907f6) .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> ممکن است با نسخه‌های جدیدتر libyang و Sysrepo سازگار باشد، اما تنها نسخه‌های ذکرشده در بالا به طور کامل توسط ISC آزمایش شده‌اند. .UNINDENT .UNINDENT .sp در صورتی که بسته‌ها توسط سیستم ارائه شده باشند، نصب از طریق بسته‌ها پیشنهاد می‌شود. در غیر این صورت، کاربران می‌توانند طبق راهنمای زیر برنامه را از روی کد منبع بسازند که باید بر روی تمام سیستم‌عامل‌های رایج کار کند. .SS "نصب \fBlibyang\fP از کد منبع" .INDENT 0.0 .INDENT 3.5 .sp .EX $ git clone https://github.com/CESNET/libyang.git $ cd libyang $ git checkout v3.13.5 $ mkdir build $ cd build $ cmake .. $ make $ make install .EE .UNINDENT .UNINDENT .SS "نصب \fBsysrepo\fP از کد منبع" .INDENT 0.0 .INDENT 3.5 .sp .EX $ git clone https://github.com/sysrepo/sysrepo.git $ cd sysrepo $ git checkout v3.7.11 $ mkdir build $ cd build $ cmake \-DREPO_PATH=/etc/sysrepo .. $ make $ make install # without sudo if you\(aqre doing development and want to run unit tests .EE .UNINDENT .UNINDENT .SS "نصب \fBlibyang\-cpp\fP از کد منبع" .INDENT 0.0 .INDENT 3.5 .sp .EX $ git clone https://github.com/CESNET/libyang\-cpp.git $ cd libyang\-cpp $ git checkout v3 $ mkdir build $ cd build $ cmake \-DBUILD_TESTING=OFF .. $ make $ make install .EE .UNINDENT .UNINDENT .SS "نصب \fBsysrepo\-cpp\fP از کد منبع" .INDENT 0.0 .INDENT 3.5 .sp .EX $ git clone https://github.com/sysrepo/sysrepo\-cpp.git $ cd sysrepo\-cpp $ git checkout v3 $ mkdir build $ cd build $ cmake \-DBUILD_TESTING=OFF .. $ make $ make install .EE .UNINDENT .UNINDENT.SS "کامپایل به همراه NETCONF" .INDENT 0.0 .IP 1. 3 دریافت سورس‌کدهای Kea. .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ git clone gitlab.isc.org/isc\-projects/kea.git $ cd kea .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 2. 3 آماده‌سازی ساخت. .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ meson setup build \-D netconf=enabled \-D cpp_std=c++20 .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 اگر هر یک از کتابخانه‌ها در یک مکان سفارشی نصب شده باشند، متغیر PKG_CONFIG_PATH می‌تواند به فایل‌های .pc اشاره کند. .UNINDENT .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX PKG_CONFIG_PATH=:/opt/libyang/lib/pkgconfig:/opt/libyang\-cpp/lib/pkgconfig:/opt/sysrepo/lib/pkgconfig:/opt/sysrepo\-cpp/lib/pkgconfig .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 3. 3 برای بررسی پشتیبانی از NETCONF، فایل \fBbuild/config.report\fP را بررسی کنید. .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX NETCONF: YANG: 2.1.4 YANG_PREFIX: /opt/libyang YANGCPP: 1.1.0 YANGCPP_PREFIX: /opt/libyang\-cpp SYSREPO: 2.2.12 SYSREPO_PREFIX: /opt/sysrepo SYSREPOCPP: 1.1.0 SYSREPOCPP_PREFIX: /opt/sysrepo\-cpp .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 4. 3 طبق معمول کامپایل کنید. .INDENT 3.0 .INDENT 3.5 $ meson compile \-C build .UNINDENT .UNINDENT .UNINDENT .SS "بررسی اجمالی و سریع Sysrepo" .sp این بخش مرور کوتاهی بر زیرمجموعه‌ای از قابلیت‌های موجود در Sysrepo ارائه می‌دهد. برای اطلاعات کامل‌تر، به صفحه اصلی Sysrepo در \%\& مراجعه کنید. .sp در YANG، پیکربندی‌ها و داده‌های وضعیت با نحو YANG در فایل‌های ماژولی به نام \fB[@].yang\fP توصیف می‌شوند. .sp بخش بازبینی (revision) اختیاری است و از قالب \fBYYYY\-MM\-DD\fP پیروی می‌کند. یک نحو XML جایگزین به نام YIN نیز تعریف شده است اما کاربرپسندی کمتری دارد. ماژول‌های سطح بالا در مدل‌های Kea (نسخه کوتاه‌شده مدل‌های طرح‌واره) نام‌گذاری می‌شوند. .sp دو ماژول اصلی وجود دارند که Kea قادر به پشتیبانی از آن‌هاست: \fBkea\-dhcp4\-server\fP و \fBkea\-dhcp6\-server\fP\&. اگرچه تلاشی فعال در کارگروه DHC در IETF برای توسعه مدل YANG برای DHCPv6 در جریان است، ابتکار مشابهی در گذشته برای DHCPv4 با شکست مواجه شد. بنابراین، Kea از مدل‌های اختصاصی خود برای DHCPv4 و DHCPv6 استفاده می‌کند اما به صورت جزئی از مدل IETF برای DHCPv6 نیز پشتیبانی می‌کند. .sp همه این مدل‌ها دارای ماژول‌های اضافی به عنوان پیش‌نیاز هستند که آن‌ها نیز ارائه شده‌اند. تمام این ماژول‌ها را می‌توان در \fBsrc/share/yang/modules\fP در سورس‌کدها و در \fBshare/kea/yang/modules\fP در دایرکتوری محل نصب یافت. در دستورهای زیر، از این دایرکتوری با عنوان \fI${share_directory}\fP یاد می‌شود. .sp برای نصب ماژول‌ها از سورس‌کد یا ارتقای آن‌ها از نسخه‌های بازبینی قبلی، دستور زیر را اجرا کنید. در صورت ارتقای نسخه، داده‌های YANG به طور خودکار به طرح‌واره ماژول جدید مهاجرت داده می‌شوند. .INDENT 0.0 .INDENT 3.5 .sp .EX $ ${share_directory}/yang/modules/utils/reinstall.sh .EE .UNINDENT .UNINDENT .sp با این حال، اگر در طول فرآیند ارتقا مشکلی پیش بیاید و بتوان داده‌ها را از طریق یک کلاینت NETCONF یا روش‌های دیگر دوباره ایجاد کرد، ماژول‌های Kea را می‌توان قبل از نصب مجدد، به راحتی با این دستور حذف نصب کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ${share_directory}/yang/modules/utils/reinstall.sh \-u .EE .UNINDENT .UNINDENT .sp این اسکریپت باید بتواند Sysrepo را مجدداً نصب کند. با این حال، از پرچم \fB\-s\fP نیز می‌توان برای مشخص کردن یک مسیر استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./build/src/share/yang/modules/utils/reinstall.sh \-s /path/to/sysrepo .EE .UNINDENT .UNINDENT .sp برای نصب تک‌تک تمام ماژول‌ها: .INDENT 0.0 .INDENT 3.5 .sp .EX $ cd ./src/share/yang/modules $ sysrepoctl \-i ./ietf\-dhcpv6\-server*.yang $ sysrepoctl \-i ./kea\-dhcp4\-server*.yang $ sysrepoctl \-i ./kea\-dhcp6\-server*.yang \&... .EE .UNINDENT .UNINDENT .sp فرآیند نصب باید مشابه موارد زیر باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ ./build/src/share/yang/modules/utils/reinstall.sh [INF] Connection 2 created. [INF] Module \(dqkeatest\-module\(dq was installed. [INF] File \(dqkeatest\-module@2022\-11\-30.yang\(dq was installed. [INF] No datastore changes to apply. [INF] Connection 4 created. [ERR] Module \(dqietf\-interfaces@2018\-02\-20\(dq already installed. [INF] No datastore changes to apply. [INF] Connection 7 created. [ERR] Module \(dqietf\-dhcpv6\-client\(dq is already in sysrepo. [INF] No datastore changes to apply. [INF] Connection 9 created. [ERR] Module \(dqietf\-dhcpv6\-relay\(dq is already in sysrepo. [INF] No datastore changes to apply. [INF] Connection 11 created. [ERR] Module \(dqietf\-dhcpv6\-server\(dq is already in sysrepo. [INF] No datastore changes to apply. [INF] Connection 13 created. [ERR] Write permission \(dqietf\-yang\-types\(dq check failed. [INF] No datastore changes to apply. [INF] Connection 15 created. [ERR] Module \(dqietf\-dhcpv6\-options\(dq is already in sysrepo. [INF] No datastore changes to apply. [INF] Connection 17 created. [ERR] Module \(dqietf\-dhcpv6\-types\(dq is already in sysrepo. [INF] No datastore changes to apply. [INF] Connection 21 created. [INF] Module \(dqkea\-types\(dq was installed. [INF] File \(dqkea\-types@2019\-08\-12.yang\(dq was installed. [INF] No datastore changes to apply. [INF] Connection 23 created. [INF] Module \(dqkea\-dhcp\-types\(dq was installed. [INF] File \(dqkea\-dhcp\-types@2022\-11\-30.yang\(dq was installed. [INF] No datastore changes to apply. [INF] Connection 25 created. [INF] Module \(dqkea\-dhcp\-ddns\(dq was installed. [INF] File \(dqkea\-dhcp\-ddns@2022\-07\-27.yang\(dq was installed. [INF] No datastore changes to apply. [INF] Connection 27 created. [INF] Connection 28 created. [INF] Module \(dqkea\-dhcp4\-server\(dq was installed. [INF] File \(dqkea\-dhcp4\-server@2022\-11\-30.yang\(dq was installed. [INF] No datastore changes to apply. [INF] Connection 30 created. [INF] Module \(dqkea\-dhcp6\-server\(dq was installed. [INF] File \(dqkea\-dhcp6\-server@2022\-11\-30.yang\(dq was installed. [INF] No datastore changes to apply. .EE .UNINDENT .UNINDENT .sp برای اطمینان از اینکه ماژول‌ها به درستی وارد (import) شده‌اند، فهرست ماژول‌های YANG نصب‌شده فعلی را بررسی کنید. باید مشابه این باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sysrepoctl \-l Sysrepo repository: /etc/sysrepo Module Name | Revision | Flags | Owner | Startup Perms | Submodules | Features \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- ietf\-datastores | 2018\-02\-14 | I | user:user | 444 | | ietf\-dhcpv6\-client | 2018\-09\-04 | I | user:user | 600 | | ietf\-dhcpv6\-options | 2018\-09\-04 | I | user:user | 600 | | ietf\-dhcpv6\-relay | 2018\-09\-04 | I | user:user | 600 | | ietf\-dhcpv6\-server | 2018\-09\-04 | I | user:user | 600 | | ietf\-dhcpv6\-types | 2018\-09\-04 | I | user:user | 600 | | ietf\-inet\-types | 2013\-07\-15 | I | user:user | 444 | | ietf\-interfaces | 2018\-02\-20 | I | user:user | 600 | | ietf\-netconf | 2013\-09\-29 | I | user:user | 644 | | ietf\-netconf\-acm | 2018\-02\-14 | I | user:user | 600 | | ietf\-netconf\-notifications | 2012\-02\-06 | I | user:user | 644 | | ietf\-netconf\-with\-defaults | 2011\-06\-01 | I | user:user | 444 | | ietf\-origin | 2018\-02\-14 | I | user:user | 444 | | ietf\-yang\-library | 2019\-01\-04 | I | user:user | 644 | | ietf\-yang\-metadata | 2016\-08\-05 | i | | | | ietf\-yang\-schema\-mount | 2019\-01\-14 | I | user:user | 644 | | ietf\-yang\-types | 2013\-07\-15 | I | user:user | 444 | | kea\-dhcp\-ddns | 2022\-07\-27 | I | user:user | 600 | | kea\-dhcp\-types | 2022\-11\-30 | I | user:user | 600 | | kea\-dhcp4\-server | 2022\-11\-30 | I | user:user | 600 | | kea\-dhcp6\-server | 2022\-11\-30 | I | user:user | 600 | | kea\-types | 2019\-08\-12 | I | user:user | 600 | | keatest\-module | 2022\-11\-30 | I | user:user | 600 | | sysrepo\-monitoring | 2022\-04\-08 | I | user:user | 600 | | sysrepo\-plugind | 2022\-03\-10 | I | user:user | 644 | | yang | 2022\-06\-16 | I | user:user | 444 | | Flags meaning: I \- Installed/i \- Imported; R \- Replay support .EE .UNINDENT .UNINDENT .sp برای نصب مجدد یک ماژول، اگر مدخل بازبینی (revision) در YANG افزایش یافته باشد، نصب ساده آن را به طور خودکار به‌روزرسانی خواهد کرد. در غیر این صورت، ابتدا باید حذف نصب شود: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sysrepoctl \-u kea\-dhcp4\-server .EE .UNINDENT .UNINDENT .sp اگر ماژول توسط ماژول‌های دیگر استفاده (یعنی وارد/import) شده باشد، تنها پس از آنکه ماژول‌های وابسته ابتدا حذف نصب شدند، می‌توان آن را حذف نصب کرد. نصب و حذف نصب باید به ترتیب وابستگی و ترتیب معکوس وابستگی، بسته به مورد، انجام گیرد..SS مدل‌های پشتیبانی‌شدهٔ YANG (Supported YANG Models) .sp مدل‌های پشتیبانی‌شده در حال حاضر \fBkea\-dhcp4\-server\fP و \fBkea\-dhcp6\-server\fP هستند\&. پشتیبانی جزئی از \fBietf\-dhcpv6\-server\fP وجود دارد، اما تمرکز اصلی آزمایش‌ها روی سرورهای Kea DHCP بوده است. سایر مدل‌ها (مانند \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>) در حال حاضر پشتیبانی نمی‌شوند. .SS استفاده از کارگزار NETCONF (Using the NETCONF Agent) .sp کارگزار NETCONF از این الگوریتم پیروی می‌کند: .INDENT 0.0 .IP \(bu 2 برای هر سرور مدیریت‌شده، پیکربندی اولیه را از طریق سوکت کنترل از سرور دریافت می‌کند. .IP \(bu 2 یک اتصال با محیط Sysrepo باز کرده و دو نشست با مخازن دادهٔ startup و running برقرار می‌سازد. .IP \(bu 2 بررسی می‌کند که ماژول‌های استفاده‌شده (غیرضروری / not\-essential) و مورد نیاز (ضروری / essential) با نسخهٔ بازبینی (revision) صحیح در مخزن Sysrepo نصب شده باشند. اگر یک ماژول ضروری \- یعنی ماژولی که طرح‌وارهٔ (schema) پیکربندی برای یک سرور مدیریت‌شده در آن تعریف شده است \- نصب نشده باشد، یک خطای مهلک (fatal error) صادر می‌کند. .IP \(bu 2 برای هر سرور مدیریت‌شده، پیکربندی YANG را از مخزن دادهٔ startup دریافت کرده، آن را به JSON ترجمه می‌کند و روی سروری که در حال پیکربندی است بارگذاری می‌نماید. .IP \(bu 2 برای هر سرور مدیریت‌شده، یک فراخوانی برگشتی (callback) تغییر ماژول را با استفاده از نام مدل آن ثبت (subscribe) می‌کند. .IP \(bu 2 هنگامی که یک پیکربندی running تغییر می‌کند، تلاش می‌کند تا پیکربندی به‌روزرسانی‌شده را از طریق فراخوانی برگشتی به سرور مدیریت‌شده اعتبارسنجی یا بارگذاری کند. .UNINDENT .SS پیکربندی (Configuration) .sp رفتار شرح‌داده‌شده در «استفاده از کارگزار NETCONF» توسط چندین پرچم پیکربندی کنترل می‌شود، که می‌توانند در دامنهٔ سراسری (global scope) یا در دامنهٔ یک سرور مدیریت‌شدهٔ خاص تنظیم شوند. در صورت مورد دوم، مقدار تعریف‌شده در دامنهٔ سرور مدیریت‌شده اولویت دارد. این پرچم‌ها عبارتند از: .INDENT 0.0 .IP \(bu 2 \fBboot\-update\fP \- فاز پیکربندی اولیه را کنترل می‌کند؛ هنگامی که \fBtrue\fP باشد (پیش‌فرض)، ابتدا پیکربندی اولیهٔ دریافت‌شده از فایل پیکربندی کلاسیک JSON سرور Kea بارگذاری شده و سپس مدل YANG در زمان راه‌اندازی (startup) بارگذاری می‌شود. این تنظیم به مدیران سیستم امکان می‌دهد یک سوکت کنترل را در فایل JSON محلی تعریف کرده و سپس پیکربندی را از YANG بارگیری کنند. در صورت تنظیم روی \fBfalse\fP، از این فاز صرف‌نظر می‌شود. .IP \(bu 2 \fBsubscribe\-changes\fP \- اشتراک تغییرات ماژول را کنترل می‌کند؛ هنگامی که \fBtrue\fP باشد (پیش‌فرض)، یک فراخوانی برگشتی تغییر ماژول ثبت می‌شود، اما هنگامی که \fBfalse\fP باشد از این فاز صرف‌نظر شده و به‌روزرسانی‌های پیکربندی running غیرفعال می‌شوند. هنگامی که روی \fBtrue\fP تنظیم شود، از مخزن دادهٔ running برای اشتراک تغییرات استفاده می‌شود. .IP \(bu 2 \fBvalidate\-changes\fP \- نحوهٔ نظارت Kea بر تغییرات پیکربندی Sysrepo را کنترل می‌کند. Sysrepo دو مرحله را ارائه می‌دهد که Kea می‌تواند در آن‌ها تعامل داشته باشد: اعتبارسنجی (validation) و اِعمال (application). در مرحلهٔ اعتبارسنجی (یا رویداد \fBSR_EV_CHANGE\fP طبق نام‌گذاری در Sysrepo)، Kea پیکربندی تازه نهایی‌شده (committed) را دریافت کرده و آن را راستی‌آزمایی می‌کند. اگر پیکربندی به هر دلیلی نادرست باشد، سرورهای Kea آن را رد می‌کنند و خطا به Sysrepo پس فرستاده می‌شود، که متعاقباً یک خطا بازمی‌گرداند. این مرحله تنها در صورتی انجام می‌شود که \fBvalidate\-changes\fP روی \fBtrue\fP تنظیم شده باشد\&. در مرحلهٔ اِعمال (یا رویداد \fBSR_EV_UPDATE\fP طبق نام‌گذاری در Sysrepo)، پیکربندی واقعی اِعمال می‌شود. در این مرحله Kea می‌تواند پیکربندی را دریافت کند، اما برای گزارش هرگونه خطا به عقب بسیار دیر است چرا که پیکربندی قبلاً نهایی شده است. .UNINDENT .sp ایدهٔ نهفته در فاز پیکربندی اولیه این است که سرورهای Kea با حداقل پیکربندی که تنها شامل یک سوکت کنترل است راه‌اندازی شوند تا مدیریت‌پذیر گردند. برای نمونه، برای سرور DHCPv4: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { \(dqcontrol\-socket\(dq: { \(dqsocket\-name\(dq: \(dqkea\-dhcp4\-ctrl.sock\(dq, \(dqsocket\-type\(dq: \(dqunix\(dq } } } .EE .UNINDENT .UNINDENT .sp با فعال بودن اشتراک‌های تغییرات ماژول، دیمن \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> هرگونه تغییر پیکربندی را به محض پدیدار شدن در Sysrepo نظارت می‌کند. چنین تغییراتی را می‌توان با استفاده از ابزار \fBsysrepocfg\fP یا از راه دور با استفاده از هر کلاینت NETCONF انجام داد. برای جزئیات، لطفاً به مستندات Sysrepo یا A Step\-by\-Step NETCONF Agent Operation Example مراجعه کنید\&. از این ابزارها می‌توان برای اصلاح پیکربندی‌های YANG در مخزن دادهٔ running استفاده کرد. توجه داشته باشید که پیکربندی‌های ثبت‌شده (committed) تنها در مخزن دادهٔ running به‌روزرسانی می‌شوند؛ برای حفظ آن‌ها در بین راه‌اندازی‌های مجدد سرور، باید در مخزن دادهٔ startup کپی شوند. .sp هنگامی که تغییرات ماژول ردیابی می‌شوند (با استفاده از \fBsubscribe\-changes\fP تنظیم‌شده روی \fBtrue\fP) و پیکربندی running تغییر کرده است (مثلاً با استفاده از \fBsysrepocfg\fP یا هر کلاینت NETCONF)، فراخوانی برگشتی پیکربندی اصلاح‌شده را اعتبارسنجی کرده (اگر \fBvalidate\-changes\fP روی \fBfalse\fP تنظیم نشده باشد) و برای دومین بار جهت اِعمال پیکربندی جدید اجرا می‌شود. اگر اعتبارسنجی ناموفق باشد، فراخوانی برگشتی همچنان دوباره فراخوانی می‌شود اما با یک رویداد \fBSR_EV_ABORT\fP (در مقابل \fBSR_EV_DONE\fP) به همراه تغییرات بازگردانی (rollback). .sp کد بازگشتی فراخوانی برگشتی در رویداد \fBSR_EV_DONE\fP نادیده گرفته می‌شود، زیرا برای رد کردن یک پیکربندی نامناسب دیگر خیلی دیر است. .sp چهار حالت وجود دارد که در آن‌ها ممکن است یک پیکربندی اصلاح‌شدهٔ YANG نادرست باشد: .INDENT 0.0 .IP 1. 3 ممکن است با طرح‌واره (schema) ناسازگار باشد؛ برای نمونه یک مدخل ناشناخته، نبودِ یک مدخل اجباری، مقداری با نوع نادرست، یا عدم تطابق با یک قید (constraint). .IP 2. 3 ممکن است در ترجمه از YANG به JSON شکست بخورد؛ مانند یک بافت کاربری (user context) نامعتبر. .IP 3. 3 ممکن است در بررسی‌های سلامت (sanity checks) سرور Kea رد شود؛ مانند یک محدودهٔ خارج از استخر زیرشبکه (out\-of\-subnet\-pool) یا یک نوع پایگاه‌دادهٔ پشتیبانی‌نشده. .IP 4. 3 نحو ممکن است درست باشد و بررسی‌های سلامت سرور را با موفقیت بگذراند، اما پیکربندی در زمان اجرا با شکست مواجه شود؛ برای نمونه، پیکربندی حاوی اطلاعات احراز هویت پایگاه‌داده باشد اما پایگاه‌داده اتصال را رد کند. .UNINDENT .sp حالت نخست توسط Sysrepo مدیریت می‌شود. حالت‌های دوم و سوم توسط \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> در فاز اعتبارسنجی رسیدگی می‌شوند (در صورتی که با تنظیم \fBvalidate\-changes\fP روی \fBtrue\fP غیرفعال نشده باشد). مورد آخر باعث می‌شود فاز اِعمال بدون گزارشی معقول به Sysrepo با شکست مواجه شود. .sp سرورها و کارگزارهای مدیریت‌شدهٔ Kea در بخش \fBmanaged\-servers\fP شرح داده شده‌اند. هر زیربخش با نام سرویس آغاز می‌شود: \fBdhcp4\fP، \fBdhcp6\fP و \fBd2\fP\&. .sp هر مدخل سرور مدیریت‌شده می‌تواند شامل موارد زیر باشد: .INDENT 0.0 .IP \(bu 2 پرچم‌های کنترلی \- \fBboot\-update\fP، \fBsubscribe\-changes\fP و/یا \fBvalidate\-changes\fP\&. .IP \(bu 2 \fBmodel\fP \- نام مدل/ماژول YANG را مشخص می‌کند. برای هر سرویس، پیش‌فرض مدل متناظر Kea YANG است؛ به عنوان نمونه برای \fB\(dqdhcp4\(dq\fP برابر با \fB\(dqkea\-dhcp4\-server\(dq\fP است\&. .IP \(bu 2 \fBcontrol\-socket\fP \- سوکت کنترل را برای مدیریت پیکربندی سرویس مشخص می‌کند. .UNINDENT .sp یک سوکت کنترل با موارد زیر مشخص می‌شود: .INDENT 0.0 .IP \(bu 2 \fBsocket\-type\fP \- نوع سوکت یکی از موارد \fBstdout\fP، \fBunix\fP یا \fBhttp\fP است\&. \fBstdout\fP مقدار پیش‌فرض است؛ این گزینه در واقع یک سوکت نیست، اما به \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> اجازه می‌دهد در حالت اشکال‌زدایی اجرا شود که در آن همه‌چیز در stdout چاپ می‌شود، و همچنین می‌تواند برای هدایت مجدد آسان دستورات استفاده شود. \fBunix\fP کانال کنترل مستقیم و استاندارد سرور است که از سوکت‌های UNIX استفاده می‌کند؛ \fBhttp\fP از یک کانال کنترل استفاده می‌کند که اتصالات HTTP را می‌پذیرد. .IP \(bu 2 \fBsocket\-name\fP \- نام سوکت محلی برای نوع سوکت \fBunix\fP (پیش‌فرض یک رشتهٔ خالی است). .IP \(bu 2 \fBsocket\-url\fP \- آدرس URL مبتنی بر HTTP برای نوع سوکت \fBhttp\fP (پیش‌فرض \fBhttp://127.0.0.1:8000\fP). .UNINDENT .sp بافت‌های کاربری (User contexts) می‌توانند داده‌های دلخواه را تا زمانی که دارای نحو معتبر JSON باشند و عنصر سطح بالای آن‌ها یک نگاشت (map) باشد (یعنی داده‌ها باید در آکولاد محصور شده باشند) ذخیره کنند. آن‌ها در مدخل NETCONF، یعنی در دامنه‌های زیرِ سطح بالا، مدخل managed\-service و مدخل control\-socket پذیرفته می‌شوند. .sp کتابخانه‌های قلاب (Hook libraries) می‌توانند درست مانند سایر سرورها یا کارگزارها توسط کارگزار NETCONF بارگذاری شوند؛ با این حال، در حال حاضر هیچ نقطهٔ قلابی (hook point) تعریف نشده است. فهرست \fBhooks\-libraries\fP حاوی فهرستی از کتابخانه‌های قلاب است که باید توسط \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> بارگذاری شوند، به همراه اطلاعات پیکربندی آن‌ها که با \fBparameters\fP مشخص می‌شود\&. .sp لطفاً برای جزئیات مربوط به نحوهٔ پیکربندی ثبت رویدادها، Logging \%<#\:logging> را بررسی کنید. نام ثبت‌کنندهٔ اصلی کارگزار NETCONF برابر با \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> است، همان‌طور که در مثال بالا نشان داده شده است..SS نمونه‌ای از پیکربندی \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> .sp مثال زیر پیکربندی پایه NETCONF را نشان می‌دهد. مثال‌های بیشتری در دایرکتوری \fBdoc/examples/netconf\fP در کدهای منبع Kea در دسترس است. .INDENT 0.0 .INDENT 3.5 .sp .EX // این یک مثال ساده از پیکربندی برای عامل NETCONF است. // این سرور یک رابط YANG برای تمامی سرورهای Kea و عامل فراهم می‌کند. { \(dqNetconf\(dq: { // پرچم‌های کنترلی را می‌توان در حوزه سراسری یا // در حوزه یک سرور مدیریت‌شده تعریف کرد. ترتیب اولویت‌ها عبارتند از: // \- استفاده از مقدار پیش‌فرض (true) // \- استفاده از مقدار سراسری // \- استفاده از مقدار محلی. // بنابراین این گزینه، مقدار پیش‌فرض را بازنویسی می‌کند: \(dqboot\-update\(dq: false, // این نگاشت مشخص می‌کند هر سرور چگونه مدیریت می‌شود. برای هر سرور // یک نام از مدل YANG برای استفاده و کانال کنترل وجود دارد. // در حال حاضر سه نوع کانال کنترل پشتیبانی می‌شوند: // \(dqstdout\(dq که پیکربندی را در خروجی استاندارد چاپ می‌کند، // \(dqunix\(dq که از کانال کنترل محلی پشتیبانی‌شده توسط سرورهای // \(dqdhcp4\(dq و \(dqdhcp6\(dq استفاده می‌کند (پشتیبانی از \(dqd2\(dq هنوز در دسترس نیست)، // و \(dqhttp\(dq که از کانال‌های کنترل HTTP/HTTPS استفاده می‌کند. \(dqmanaged\-servers\(dq: { // به این روش kea\-netconf می‌تواند با سرور DHCPv4 ارتباط برقرار کند. \(dqdhcp4\(dq: { \(dqcomment\(dq: \(dqDHCPv4 server\(dq, \(dqmodel\(dq: \(dqkea\-dhcp4\-server\(dq, \(dqcontrol\-socket\(dq: { \(dqsocket\-type\(dq: \(dqunix\(dq, \(dqsocket\-name\(dq: \(dqkea4\-ctrl\-socket\(dq } }, // پارامترهای DHCPv6. \(dqdhcp6\(dq: { \(dqmodel\(dq: \(dqkea\-dhcp6\-server\(dq, \(dqcontrol\-socket\(dq: { \(dqsocket\-type\(dq: \(dqunix\(dq, \(dqsocket\-name\(dq: \(dqkea6\-ctrl\-socket\(dq } }, \(dqd2\(dq: { \(dqmodel\(dq: \(dqkea\-dhcp\-ddns\(dq, \(dqcontrol\-socket\(dq: { \(dqsocket\-type\(dq: \(dqunix\(dq, \(dqsocket\-name\(dq: \(dqkea\-ddns\-ctrl\-socket\(dq, \(dquser\-context\(dq: { \(dqin\-use\(dq: true } } }, \(dqdhcp4\-http\(dq: { \(dqcomment\(dq: \(dqDHCPv4 server using HTTP\(dq, \(dqmodel\(dq: \(dqkea\-dhcp4\-server\(dq, \(dqcontrol\-socket\(dq: { \(dqsocket\-type\(dq: \(dqhttp\(dq, \(dqsocket\-url\(dq: \(dqhttp://127.0.0.1:8000/\(dq } } }, // ابزار kea\-netconf قادر است کتابخانه‌های hook را برای ارتقای عملکرد خود بارگذاری کند. // در حال حاضر هیچ نقطه hookای در پردازش kea\-netconf // تعریف نشده است. \(dqhooks\-libraries\(dq: [ // فهرست کتابخانه‌های hook می‌تواند شامل بیش از یک کتابخانه باشد. { // تنها پارامتر ضروری، نام فایل کتابخانه است. \(dqlibrary\(dq: \(dqcustom_hooks_example.so\(dq, // برخی کتابخانه‌ها ممکن است از پارامترها پشتیبانی کنند. دقت کنید // که این بخش را با دقت وارد کنید، زیرا kea\-netconf آن را // اعتبارسنجی نمی‌کند (چرا که قالب آن مختص همان کتابخانه است). \(dqparameters\(dq: { \(dqparam1\(dq: \(dqfoo\(dq } } ], // همانند سایر مؤلفه‌های Kea، بخش NETCONF نیز از ثبت گزارش استفاده می‌کند. \(dqloggers\(dq: [ { \(dqname\(dq: \(dqkea\-netconf\(dq, \(dqoutput\-options\(dq: [ { \(dqoutput\(dq: \(dq/var/log/kea/kea\-netconf.log\(dq, // علاوه بر خروجی معمول، چندین پارامتر // اضافی نیز ممکن است. // پارامتر Flush تعیین می‌کند آیا ثبت‌کننده خروجی را // در فایل تخلیه می‌کند یا خیر. // پارامتر Maxsize حداکثر اندازه فایل را پیش از چرخش // آن تعیین می‌کند. // پارامتر Maxver حداکثر تعداد فایل‌های چرخیده‌شده // برای نگهداری را مشخص می‌کند. \(dqflush\(dq: true, \(dqmaxsize\(dq: 204800, \(dqmaxver\(dq: 4 } ], \(dqseverity\(dq: \(dqINFO\(dq, \(dqdebuglevel\(dq: 0 } ] } } .EE .UNINDENT .UNINDENT.SS راه‌اندازی و متوقف‌سازی عامل NETCONF .sp \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> گزینه‌های خط فرمان زیر را می‌پذیرد: .INDENT 0.0 .IP \(bu 2 \fB\-c file\fP \- فایل پیکربندی را مشخص می‌کند. .IP \(bu 2 \fB\-d\fP \- مشخص می‌کند که آیا ثبت گزارش‌های عامل باید به حالت اشکال‌زدایی/پرجزئیات تغییر کند یا خیر. در حالت پرجزئیات، شدت ثبت گزارش و debuglevel مشخص‌شده در فایل پیکربندی نادیده گرفته شده و شدت \(dqdebug\(dq و بیشترین سطح اشکال‌زدایی (99) فرض می‌شود. این پرچم برای تغییر موقت سرور به حداکثر جزئیات، مثلاً هنگام اشکال‌زدایی، مناسب است. .IP \(bu 2 \fB\-t file\fP \- فایل پیکربندی را برای آزمودن مشخص می‌کند. \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> تلاش می‌کند آن را بارگذاری کرده و بررسی‌های سلامت را انجام دهد؛ برخی بررسی‌ها تنها هنگام اجرای سرور واقعی امکان‌پذیر هستند. وضعیت واقعی با کد خروج گزارش می‌شود (0 = پیکربندی معتبر به نظر می‌رسد، 1 = با خطا مواجه شد). هنگام آزمودن پیکربندی، Kea پیام‌های گزارش را به خروجی استاندارد و خطاها را به خطای استاندارد ارسال می‌کند. .IP \(bu 2 \fB\-v\fP \- نسخه \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> را نمایش داده و خارج می‌شود. .IP \(bu 2 \fB\-V\fP \- اطلاعات تفصیلی نسخه \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> را نمایش داده و خارج می‌شود. این فهرست شامل نسخه‌های کتابخانه‌هایی است که به صورت پویا به Kea پیوند خورده‌اند. .IP \(bu 2 \fB\-W\fP \- گزارش پیکربندی Kea را نمایش داده و خارج می‌شود. این گزارش رونوشتی از فایل \fBconfig.report\fP تولیدشده توسط \fBmeson setup\fP است؛ این گزارش در باینری اجرایی تعبیه شده است. .sp محتوای فایل \fBconfig.report\fP همچنین می‌تواند با بررسی برخی کتابخانه‌ها در درخت نصب یا درخت کد مبدا در دسترس قرار گیرد. .INDENT 2.0 .INDENT 3.5 .sp .EX # from installation using libkea\-process.so $ strings ${prefix}/lib/libkea\-process.so | sed \-n \(aqs/;;;; //p\(aq # from sources using libkea\-process.so $ strings src/lib/process/.libs/libkea\-process.so | sed \-n \(aqs/;;;; //p\(aq # from sources using libkea\-process.a $ strings src/lib/process/.libs/libkea\-process.a | sed \-n \(aqs/;;;; //p\(aq # from sources using libcfgrpt.a $ strings src/lib/process/cfgrpt/.libs/libcfgrpt.a | sed \-n \(aqs/;;;; //p\(aq .EE .UNINDENT .UNINDENT .UNINDENT .SS نمونه گام‌به‌گام عملکرد عامل NETCONF .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نسخه‌هایی از پیکربندی‌های نمونه ارائه‌شده در این بخش را می‌توان در کد مبدا Kea، تحت مسیر \fBdoc/examples/netconf/kea\-dhcp6\-operations\fP یافت. .UNINDENT .UNINDENT .SS راه‌اندازی نمونه عملکرد عامل NETCONF .sp سیستم آزمایشی دارای یک رابط اترنت به نام eth1 است. در برخی سیستم‌ها امکان تغییر نام رابط‌ها وجود دارد؛ برای نمونه، در لینوکس با یک رابط ens38: .INDENT 0.0 .INDENT 3.5 .sp .EX # ip link set down dev ens38 # ip link set name eth1 dev ens38 # ip link set up dev eth1 .EE .UNINDENT .UNINDENT .sp این رابط باید آدرسی در پیشوند آزمایشی داشته باشد: .INDENT 0.0 .INDENT 3.5 .sp .EX # ip \-6 addr add 2001:db8::1/64 dev eth1 .EE .UNINDENT .UNINDENT .sp سرور Kea DHCPv6 باید با پیکربندی مشخص‌کننده یک سوکت کنترلی برای دریافت دستورات کنترلی اجرا شود. فرایند \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> از این سوکت برای برقراری ارتباط با سرور DHCPv6 استفاده می‌کند، یعنی پیکربندی‌های ترجمه‌شده را با استفاده از دستورات کنترلی به آن سرور ارسال می‌نماید. در ادامه نمونه‌ای از پیکربندی سوکت کنترلی برای سرور Kea DHCPv6 آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqcontrol\-socket\(dq: { \(dqsocket\-name\(dq: \(dqkea\-dhcp6\-ctrl.sock\(dq, \(dqsocket\-type\(dq: \(dqunix\(dq } } } .EE .UNINDENT .UNINDENT .sp به منظور اجرای سرور Kea DHCPv6 با استفاده از پیکربندی موجود در فایل netconf/kea\-dhcp6\-operations/boot.json \%<#\:config-example-netconf-kea-dhcp6-operations-boot-json>، دستور زیر را اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX # kea\-dhcp6 \-d \-c boot.json .EE .UNINDENT .UNINDENT .sp پیکربندی فعلی سرور را می‌توان از طریق یک سوکت کنترلی با اجرای دستور زیر دریافت کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX # echo \(aq{ \(dqcommand\(dq: \(dqconfig\-get\(dq }\(aq | socat UNIX:/opt/kea/var/run/kea/kea\-dhcp6\-ctrl.sock \(aq\-,ignoreeof\(aq .EE .UNINDENT .UNINDENT .sp پیکربندی نمونه netconf/kea\-dhcp6\-operations/netconf.json \%<#\:config-example-netconf-kea-dhcp6-operations-netconf-json> برای \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf>، جهت مدیریت سرور Kea DHCPv6 به شرح زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqNetconf\(dq: { \(dqloggers\(dq: [ { \(dqdebuglevel\(dq: 99, \(dqname\(dq: \(dqkea\-netconf\(dq, \(dqoutput\-options\(dq: [ { \(dqoutput\(dq: \(dqstderr\(dq } ], \(dqseverity\(dq: \(dqDEBUG\(dq } ], \(dqmanaged\-servers\(dq: { \(dqdhcp6\(dq: { \(dqcontrol\-socket\(dq: { \(dqsocket\-name\(dq: \(dqkea\-dhcp6\-ctrl.sock\(dq, \(dqsocket\-type\(dq: \(dqunix\(dq } } } } } .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که در محیط‌های عملیاتی نباید نیازی به ثبت گزارش در سطح DEBUG وجود داشته باشد. .sp عامل Kea NETCONF با دستور زیر راه‌اندازی می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX # kea\-netconf \-d \-c netconf.json .EE .UNINDENT .UNINDENT .sp اکنون که هر دو \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> در حال اجرا هستند، می‌توان به‌روزرسانی‌های پیکربندی را به سرور DHCPv6 اعمال کرد. در ادامه پیکربندی استخراج‌شده از \fBstartup.xml\fP آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX 1 2001:db8::1:0 2001:db8::1:ffff 2001:db8::1:0/112 2001:db8::/64 eth1 kea\-dhcp6\-ctrl.sock unix .EE .UNINDENT .UNINDENT .sp برای اعمال این پیکربندی جدید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sysrepocfg \-d startup \-f xml \-m kea\-dhcp6\-server \-\-import=startup.xml .EE .UNINDENT .UNINDENT .sp \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> در فاز مقداردهی اولیه خود، پس از مشترک شدن در تغییرات ماژول در مخزن داده running نرم‌افزار Sysrepo، پیکربندی موجود در مخزن داده startup را به تمام سرورهای Kea ارسال می‌کند. این اقدام، پیکربندی را از مخزن داده startup به مخزن داده running کپی کرده و مخزن داده running را فعال و دردسترس می‌سازد. .sp تغییرات اعمال‌شده بر مخزن داده running، پس از اعتبارسنجی روی سرورهای Kea اعمال می‌شوند. توجه داشته باشید که این تغییرات به‌طور پیش‌فرض به مخزن داده startup کپی نمی‌شوند؛ بدین معنا که تغییرات دائمی نیستند. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf> تمام پیکربندی را از هر مخزن داده Sysrepo در یک عملیات واحد \fBget\-config\fP در NETCONF دریافت می‌کند. پیش از Kea 2.3.2، عملیات \fBget\-config\fP برای هر گره برگ (leaf) و لیست برگ (leaf\-list) به‌طور جداگانه انجام می‌شد. .UNINDENT .UNINDENT.SS نمونه‌ای از مدیریت خطا در عملیات NETCONF .sp چهار دسته مشکل در پیکربندی‌های اعمال‌شده از طریق NETCONF وجود دارد: .INDENT 0.0 .IP 1. 3 پیکربندی با شِمای (schema) YANG مطابقت ندارد. .IP 2. 3 پیکربندی نمی‌تواند از YANG به JSON مربوط به Kea ترجمه شود. .IP 3. 3 پیکربندی توسط سرور Kea رد می‌شود. .IP 4. 3 پیکربندی توسط سرور Kea اعتبارسنجی شده اما قابل اعمال نیست. .UNINDENT .sp در حالت نخست، فایل پیکربندی \fBBAD\-schema.xml\fP زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX 1 2001:db8::1:0 2001:db8::1:ffff 2001:db8::1:0/112 2001:db8::/64 eth1 kea\-dhcp6\-ctrl.sock unix .EE .UNINDENT .UNINDENT .sp این فایل مستقیماً توسط \fBsysrepocfg\fP رد می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sysrepocfg \-d running \-f xml \-m kea\-dhcp6\-server \-\-import=BAD\-schema.xml .EE .UNINDENT .UNINDENT .sp در حالت دوم، پیکربندی توسط \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf>\& رد می‌شود. برای نمونه، این فایل \fBBAD\-translator.xml\fP را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX 1 2001:db8::1:0 2001:db8::1:ffff 2001:db8::1:0/112 2001:db8::/64 eth1 kea\-dhcp6\-ctrl.sock unix bad .EE .UNINDENT .UNINDENT .sp در حالت سوم، پیکربندی به سرور Kea DHCPv6 ارائه شده و اعتبارسنجی آن با شکست مواجه می‌شود، مانند این فایل \fBBAD\-config.xml\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX 1 2001:db8:1::0 2001:db8:1::ffff 2001:db8:1::0/112 2001:db8::/64 eth1 kea\-dhcp6\-ctrl.sock unix .EE .UNINDENT .UNINDENT .sp در حالت آخر، پیکربندی نادرست خیلی دیر تشخیص داده می‌شود و تغییرات باید در Sysrepo بازگردانی (revert) شوند، مثلاً با استفاده از پایگاه داده (datastore) آغازین (startup) به عنوان پشتیبان. .SS نمونه عملیات NETCONF با دو استخر (Pool) .sp این نمونه یک استخر دوم را به پیکربندی اولیه (یعنی startup) در فایل \fBtwopools.xml\fP اضافه می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX 1 2001:db8::1:0 2001:db8::1:ffff 2001:db8::1:0/112 2001:db8::2:0 2001:db8::2:ffff 2001:db8::2:0/112 2001:db8::/64 eth1 kea\-dhcp6\-ctrl.sock unix .EE .UNINDENT .UNINDENT .sp این پیکربندی با دستور زیر نصب می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sysrepocfg \-d running \-f xml \-m kea\-dhcp6\-server \-\-import=twopools.xml .EE .UNINDENT .UNINDENT.SS نمونه عملیات NETCONF با دو زیرشبکه .sp این مثال دو زیرشبکه را در فایل \fBtwosubnets.xml\fP مشخص می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX 1 2001:db8:1:: 2001:db8:1::ffff 2001:db8:1::/112 2001:db8:1::/64 2 2001:db8:2:: 2001:db8:2::ffff 2001:db8:2::/112 2001:db8:2::/64 eth1 kea\-dhcp6\-ctrl.sock unix .EE .UNINDENT .UNINDENT .sp این پیکربندی با دستور زیر نصب می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sysrepocfg \-d running \-f xml \-m kea\-dhcp6\-server \-\-import=twosubnets.xml .EE .UNINDENT .UNINDENT .SS نمونه عملیات NETCONF به همراه ثبت وقایع .sp این مثال یک مدخل ثبت وقایع (logger) را به پیکربندی اولیه (یعنی هنگام راه‌اندازی) در فایل \fBlogging.xml\fP اضافه می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX eth1 1 2001:db8::1:0 2001:db8::1:ffff 2001:db8::1:0/112 2001:db8::/64 kea\-dhcp6\-ctrl.sock unix kea\-dhcp6 stderr 99 DEBUG .EE .UNINDENT .UNINDENT .sp پیکربندی متناظر Kea در قالب JSON عبارت است از: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp6\(dq: { \(dqcontrol\-socket\(dq: { \(dqsocket\-name\(dq: \(dqkea\-dhcp6\-ctrl.sock\(dq, \(dqsocket\-type\(dq: \(dqunix\(dq }, \(dqinterfaces\-config\(dq: { \(dqinterfaces\(dq: [ \(dqeth1\(dq ] }, \(dqsubnet6\(dq: [ { \(dqid\(dq: 1, \(dqpools\(dq: [ { \(dqpool\(dq: \(dq2001:db8::1:0/112\(dq } ], \(dqsubnet\(dq: \(dq2001:db8::/64\(dq } ], \(dqloggers\(dq: [ { \(dqname\(dq: \(dqkea\-dhcp6\(dq, \(dqoutput\-options\(dq: [ { \(dqoutput\(dq: \(dqstderr\(dq } ], \(dqseverity\(dq: \(dqDEBUG\(dq, \(dqdebuglevel\(dq: 99 } ] } } .EE .UNINDENT .UNINDENT .sp در نهایت، هر یک از مثال‌های پیشین را می‌توان با استفاده از \fBsysrepocfg\fP در حالت ویرایش به صورت زیر مجدداً اجرا کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sysrepocfg \-d running \-f xml \-m kea\-dhcp6\-server \-\-edit .EE .UNINDENT .UNINDENT .sp یا با استفاده از یک کلاینت NETCONF مانند \fBnetopeer2\-cli\fP از مجموعه ابزار NETCONF پروژه Netopeer2 \%..SS مهاجرت داده‌های YANG از نسخه پیشین Sysrepo .sp 1. برنامه \fBkea\-netconf\fP \%<#\:std-iscman-kea-netconf>\& را متوقف کنید. این کار تضمین می‌کند که پشتیبان‌گیری از هر دو datastore در یک وضعیت پیکربندی یکسان انجام شود و هیچ تغییری میان برون‌بری (export) آن‌ها رخ ندهد. .INDENT 0.0 .IP 2. 3 از تمام ماژول‌های YANG نسخه پشتیبان تهیه کنید، به‌طوری که برای هر datastore یک فایل XML ایجاد شود. .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ sysrepocfg \-\-datastore running \-\-export=save.xml \-\-format=xml $ sysrepocfg \-\-datastore startup \-\-export=save.xml \-\-format=xml .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 نسخه Sysrepo v0 از درون‌ریزی/برون‌بری تمام ماژول‌های YANG پشتیبانی نمی‌کند؛ این قابلیت در Sysrepo v1 افزوده شده است. کاربرانی که از Sysrepo v0 مهاجرت می‌کنند باید پشتیبان‌گیری را به ازای هر ماژول به‌طور جداگانه انجام دهند. این کار مزیت مضاعفی در جداسازی خرابی‌های احتمالی و جلوگیری از اثرگذاری آن‌ها بر روی تمام ماژول‌ها دارد. دستور مورد استفاده یکسان است، با این تفاوت که نام ماژول در پایان به آن افزوده می‌شود. .INDENT 0.0 .INDENT 3.5 .sp .EX $ sysrepocfg \-\-datastore running \-\-export=save.xml \-\-format=xml kea\-dhcp6\-server $ sysrepocfg \-\-datastore startup \-\-export=save.xml \-\-format=xml kea\-dhcp6\-server .EE .UNINDENT .UNINDENT .UNINDENT .UNINDENT .INDENT 0.0 .IP 3. 3 نرم‌افزار Sysrepo را به نسخه جدیدتر ارتقا دهید و سپس دستورات زیر را اجرا کنید: .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX $ sysrepocfg \-\-datastore running \-\-import=save.xml $ sysrepocfg \-\-datastore startup \-\-import=save.xml .EE .UNINDENT .UNINDENT .SS GSS\-TSIG .SS بررسی اجمالی GSS\-TSIG .sp نرم‌افزار Kea از به‌روزرسانی‌های DNS پشتیبانی می‌کند که می‌توان آن‌ها را با استفاده از امضاهای تراکنش (Transaction Signatures یا TSIG) محافظت کرد. این سطح از محافظت اغلب کافی است. با این حال، برخی سیستم‌ها، به‌ویژه Active Directory (AD) در سرورهای Microsoft Windows، رویکرد پیچیده‌تر GSS\-TSIG را برگزیده‌اند که قابلیت‌های بیشتری همچون استفاده از کلیدهای پویای مذاکره‌شده را ارائه می‌دهد. .sp نرم‌افزار Kea از GSS\-TSIG برای محافظت از به‌روزرسانی‌های DNS ارسال‌شده توسط سرور Kea DHCP\-DDNS (D2) از طریق یک هوک (hook) به نام \fBlibddns_gss_tsig.so\fP \%<#\:std-ischooklib-libddns_gss_tsig\:.so>\& پشتیبانی می‌کند. .sp استاندارد GSS\-TSIG در RFC 3645 \%\& تعریف شده است. خود پروتکل GSS\-TSIG پیاده‌سازی سرویس‌های عمومی GSS\-API v2 است که در RFC 2743 \%\& تعریف شده است. .sp پروتکل‌های متعددی در این سازوکار دخیل هستند: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 پروتکل Kerberos 5 \- RFC 4120 \%، که چارچوب امنیتی را فراهم می‌کند؛ .IP \(bu 2 رابط GSS\-API (Generic Security Services Application Program Interface) \- سند RFC 2743 \% برای API، سند RFC 2744 \% برای انقیادهای C، و RFC 4121 \% برای به‌کارگیری در Kerberos 5؛ .IP \(bu 2 سازوکار SPNEGO (Simple and Protected GSS\-API Negotiation Mechanism) \- RFC 4178 \% برای انجام مذاکره؛ .IP \(bu 2 به‌روزرسانی DNS بر اساس RFC 2136 \%؛ .IP \(bu 2 پروتکل TSIG (Secret Key Transaction Authentication for DNS) \- RFC 8945 \%، که از تبادلات DNS محافظت می‌کند؛ .IP \(bu 2 به‌روزرسانی پویای امن در سامانه نام دامنه (Secure Domain Name System Dynamic Update) \- RFC 3007 \%، که کاربرد TSIG در محافظت از به‌روزرسانی‌های DNS است؛ .IP \(bu 2 پروتکل TKEY (Secret Key Establishment for DNS) \- RFC 2930 \%، که کلیدهای سری را برای TSIG از طریق انتقال داده‌های رمزنگاری میان طرف‌های DNS برقرار می‌کند؛ و .IP \(bu 2 پروتکل GSS\-TSIG \- RFC 3645 \%، که کاربرد GSS\-API در TSIG است. .UNINDENT .UNINDENT .UNINDENT .sp به‌طور خلاصه، GSS\-API برای Kerberos 5 به همراه SPNEGO و TKEY برای مذاکره بر سر یک بافتار امنیتی (security context) میان سرور Kea D2 و یک سرور DNS استفاده می‌شوند: .INDENT 0.0 .INDENT 2.5 [تصویر] .UNINDENT .UNINDENT .sp سپس این بافتار امنیتی توسط GSS\-TSIG برای محافظت از به‌روزرسانی‌ها به کار گرفته می‌شود: .INDENT 0.0 .INDENT 2.5 [تصویر] .UNINDENT .UNINDENT .sp پیاده‌سازی Kea از GSS\-TSIG از یک کتابخانه GSS\-API برای Kerberos 5 به همراه SPNEGO استفاده می‌کند. دو پیاده‌سازی این معیارها را برآورده می‌کنند: MIT Kerberos 5 و Heimdal..SS کامپایل GSS\-TSIG .sp روال زیر روی دبیان ۱۲ (Debian 12) آزمایش شده است. رویکرد مشابهی را می‌توان برای سایر سیستم‌ها نیز به کار برد. .INDENT 0.0 .IP 1. 3 یکی از کتابخانه‌های MIT (\fBlibkrb5\-dev\fP) یا Heimdal (\fBheimdal\-dev\fP) را نصب کنید، برای نمونه: .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX sudo apt install libkrb5\-dev .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 2. 3 سورس‌کدهای Kea را دریافت کرده و آن‌ها را استخراج کنید. .IP 3. 3 مراحل ساخت را برپا کنید: .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX meson setup build \-D krb5=enabled .EE .UNINDENT .UNINDENT .INDENT 0.0 .IP 4. 3 مطمئن شوید که \fBbuild/config.report\fP مدخل \fBKerberos5 GSS\-API\fP را نمایش می‌دهد. .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .EX Kerberos5 GSS\-API: VERSION: 1.20.1 VENDOR: MIT .EE .UNINDENT .UNINDENT .sp حضور فایل \fBkrb5.pc\fP یا ابزار \fBkrb5\-config\fP الزامی است. این موارد توسط هر دو پیاده‌سازی MIT Kerberos 5 و Heimdal ارائه می‌شوند؛ با این حال، در برخی سیستم‌ها که هر دو مورد Kerberos 5 و Heimdal نصب شده‌اند، این ابزار یک پیوند نمادین (symbolic link) به یکی از آن‌ها است. اگر ابزار در مکان استاندارد قرار ندارد، می‌توان آن را با تنظیم \fBPKG_CONFIG_PATH=/path/to/krb5.pc:${PKG_CONFIG_PATH}\fP یا \fBPATH=/path/to/krb5\-config:${PATH}\fP پیش از \fBmeson setup\fP مشخص کرد\&. .INDENT 0.0 .IP 6. 3 با دستور \fBmeson compile \-C build\fP کامپایل کنید\&. .IP 7. 3 .INDENT 3.0 .TP .B پس از کامپایل، \fBlibddns_gss_tsig.so\fP \%<#\:std-ischooklib-libddns_gss_tsig\:.so> در دایرکتوری \fBbuild/src/hooks/d2/gss_tsig\fP در دسترس خواهد بود. این پرونده می‌تواند توسط \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns> بارگذاری شود\&. .UNINDENT .UNINDENT .sp پرونده \fBlibddns_gss_tsig.so\fP \%<#\:std-ischooklib-libddns_gss_tsig\:.so> از هر دو پیاده‌سازی MIT Kerberos 5 و Heimdal پشتیبانی می‌کند. پیاده‌سازی Heimdal درباره دسترسی‌های فایل‌های حساس امنیتی بسیار سخت‌گیر است و معروف است که پیام خطای نامفهومی صادر می‌کند. ایده خوبی است که این فایل‌ها ساده، با یک پیوند و بدون دسترسی برای گروه یا سایر کاربران نگه‌داشته شوند. .sp اسکریپت \fBkrb5\-config\fP باید یک گزینه \fB\-\-vendor\fP فراهم کند که پیاده‌سازی را مشخص می‌سازد. .SS استقرار GSS\-TSIG .sp پیش از استفاده از GSS\-TSIG، یک سرور DNS با قابلیت پشتیبانی از GSS\-TSIG، مانند BIND 9 یا Microsoft Active Directory (AD) باید مستقر شده باشد. سایر پیاده‌سازی‌های دارای قابلیت GSS\-TSIG ممکن است کار کنند، اما آزمایش نشده‌اند. .SS راه‌اندازی Kerberos 5 .sp دو نوع جدول کلید (فایل‌های keytab) وجود دارد: جدول سیستمی که توسط سرورها استفاده می‌شود، و جدول‌های کلاینت که توسط کلاینت‌ها به کار می‌روند. برای Kerberos 5، نرم‌افزار Kea یک \fBclient\fP (کلاینت) محسوب می‌شود\&. .sp کتابخانه کلاینت Kerberos 5 و ابزار \fBkadmin\fP را نصب کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX sudo apt install krb5\-kdc krb5\-admin\-server .EE .UNINDENT .UNINDENT .sp مثال‌های زیر از قلمرو (realm) فرضی \fBEXAMPLE.ORG\fP برای نمایش مراحل پیکربندی و تنظیمات مورد نیاز استفاده می‌کنند. .sp کتابخانه کلاینت Kerberos 5 باید از طریق به‌روزرسانی فایل \fBkrb5.conf\fP (برای نمونه در لینوکس: /etc/krb5.conf) برای پذیرش درخواست‌های ورودی مربوط به قلمرو \fBEXAMPLE.ORG\fP پیکربندی شود: .INDENT 0.0 .INDENT 3.5 .sp .EX [libdefaults] default_realm = EXAMPLE.ORG kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] EXAMPLE.ORG = { kdc = kdc.example.org admin_server = kdc.example.org } .EE .UNINDENT .UNINDENT .sp علاوه بر فایل \fBkrb5.conf\fP، فایل \fBkdc.conf\fP نیز می‌تواند استفاده شود (برای نمونه در لینوکس: /etc/krb5kdc/kdc.conf): .INDENT 0.0 .INDENT 3.5 .sp .EX [kdcdefaults] kdc_ports = 750,88 [realms] EXAMPLE.ORG = { database_name = /var/lib/krb5kdc/principal admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab acl_file = /etc/krb5kdc/kadm5.acl key_stash_file = /etc/krb5kdc/stash kdc_ports = 750,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des3\-hmac\-sha1 #supported_enctypes = aes256\-cts:normal aes128\-cts:normal default_principal_flags = +preauth } .EE .UNINDENT .UNINDENT .sp لیست کنترل دسترسی (ACL) دیمن \fBkadmind\fP باید طوری پیکربندی شود که به پرینسیپال (principal) کلاینت DNS برای دسترسی به پایگاه‌داده Kerberos 5 مجوز دهد (برای نمونه در لینوکس: /etc/krb5kdc/kadm5.acl): .INDENT 0.0 .INDENT 3.5 .sp .EX DHCP/admin.example.org@EXAMPLE.ORG * .EE .UNINDENT .UNINDENT .sp گذرواژه مدیر سیستم برای قلمرو پیش‌فرض باید تنظیم شود: .INDENT 0.0 .INDENT 3.5 .sp .EX krb5_newrealm .EE .UNINDENT .UNINDENT .sp پس از نمایش پیام زیر، گذرواژه قلمرو پیش‌فرض را وارد کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX This script should be run on the master KDC/admin server to initialize a Kerberos realm. It will ask you to type in a master key password. This password will be used to generate a key that is stored in /etc/krb5kdc/stash. You should try to remember this password, but it is much more important that it be a strong password than that it be remembered. However, if you lose the password and /etc/krb5kdc/stash, you cannot decrypt your Kerberos database. Loading random data Initializing database \(aq/var/lib/krb5kdc/principal\(aq for realm \(aqEXAMPLE.ORG\(aq, master key name \(aqK/M@EXAMPLE.ORG\(aq You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: .EE .UNINDENT .UNINDENT .sp سپس گذرواژه را دوباره وارد کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX Re\-enter KDC database master key to verify: .EE .UNINDENT .UNINDENT .sp در صورت اعمال موفقیت‌آمیز، پیام زیر نمایش داده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX Now that your realm is set up you may wish to create an administrative principal using the addprinc subcommand of the kadmin.local program. Then, this principal can be added to /etc/krb5kdc/kadm5.acl so that you can use the kadmin program on other computers. Kerberos admin principals usually belong to a single user and end in /admin. For example, if jruser is a Kerberos administrator, then in addition to the normal jruser principal, a jruser/admin principal should be created. Don\(aqt forget to set up DNS information so your clients can find your KDC and admin servers. Doing so is documented in the administration guide. .EE .UNINDENT .UNINDENT .sp گام بعدی، ایجاد پرینسیپال‌ها برای سرور BIND 9 DNS (سرویسی که توسط GSS\-TSIG TKEY محافظت می‌شود) و برای کلاینت DNS (سرور Kea DHCP\-DDNS) است. .sp پرینسیپال سرور BIND 9 DNS (مورد استفاده برای احراز هویت) به شیوه زیر ایجاد می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX kadmin.local \-q \(dqaddprinc \-randkey DNS/server.example.org\(dq .EE .UNINDENT .UNINDENT .sp در صورت ایجاد موفقیت‌آمیز، پیام زیر نمایش داده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX No policy specified for DNS/server.example.org@EXAMPLE.ORG; defaulting to no policy Authenticating as principal root/admin@EXAMPLE.ORG with password. Principal \(dqDNS/server.example.org@EXAMPLE.ORG\(dq created. .EE .UNINDENT .UNINDENT .sp پرینسیپال سرور DNS باید برون‌بری شود تا بتواند توسط سرور BIND 9 DNS استفاده شود. تنها به این پرینسیپال نیاز است، و در فایل keytab با نام \fBdns.keytab\fP برون‌بری می‌شود\&. .INDENT 0.0 .INDENT 3.5 .sp .EX kadmin.local \-q \(dqktadd \-k /usr/local/share/kea/dns.keytab DNS/server.example.org\(dq .EE .UNINDENT .UNINDENT .sp در صورت برون‌بری موفق، پیام زیر نمایش داده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX Authenticating as principal root/admin@EXAMPLE.ORG with password. Entry for principal DNS/server.example.org with kvno 2, encryption type aes256\-cts\-hmac\-sha1\-96 added to keytab WRFILE:/usr/local/share/kea/dns.keytab. Entry for principal DNS/server.example.org with kvno 2, encryption type aes128\-cts\-hmac\-sha1\-96 added to keytab WRFILE:/usr/local/share/kea/dns.keytab. .EE .UNINDENT .UNINDENT .sp پرینسیپال کلاینت DHCP (مورد استفاده توسط سرور Kea DHCP\-DDNS) به این ترتیب ایجاد می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX kadmin.local \-q \(dqaddprinc \-randkey DHCP/admin.example.org\(dq .EE .UNINDENT .UNINDENT .sp در صورت ایجاد موفقیت‌آمیز، پیام زیر نمایش داده می‌شود: .INDENT 0.0 .INDENT 3.5 .sp .EX No policy specified for DHCP/admin.example.org@EXAMPLE.ORG; defaulting to no policy Authenticating as principal root/admin@EXAMPLE.ORG with password. Principal \(dqDHCP/admin.example.org@EXAMPLE.ORG\(dq created. .EE .UNINDENT .UNINDENT .sp پرینسیپال کلاینت DHCP باید برون‌بری شود تا بتواند توسط سرور Kea DHCP\-DDNS و کتابخانه قلاب (hook) مربوط به GSS\-TSIG استفاده شود. این پرینسیپال به فایل keytab کلاینت با نام \fBdhcp.keytab\fP صادر می‌شود\&. .INDENT 0.0 .INDENT 3.5 .sp .EX kadmin.local \-q \(dqktadd \-k /usr/local/share/kea/dhcp.keytab DHCP/admin.example.org\(dq .EE .UNINDENT .UNINDENT .sp در نهایت، سرویس \fBkrb5\-admin\-server\fP باید بازراه‌اندازی شود: .INDENT 0.0 .INDENT 3.5 .sp .EX systemctl restart krb5\-admin\-server.service .EE .UNINDENT .UNINDENT.SS پیکربندی BIND 9 با GSS\-TSIG .sp کارساز DNS برنامه‌ی BIND 9 باید برای استفاده از GSS\-TSIG و به‌کارگیری principal کارساز DNS که پیش‌تر از فایل keytab با نام \fBdns.keytab\fP صادر شده است، پیکربندی شود. به‌روزرسانی فایل \fBnamed.conf\fP الزامی است: .INDENT 0.0 .INDENT 3.5 .sp .EX options { ... directory \(dq/var/cache/bind\(dq; dnssec\-validation auto; listen\-on\-v6 { any; }; tkey\-gssapi\-keytab \(dq/etc/bind/dns.keytab\(dq; }; zone \(dqexample.org\(dq { type master; file \(dq/var/lib/bind/db.example.org\(dq; update\-policy { grant \(dqDHCP/admin.example.org@EXAMPLE.ORG\(dq zonesub any; }; }; zone \(dq84.102.10.in\-addr.arpa\(dq { type master; file \(dq/etc/bind/db.10\(dq; }; .EE .UNINDENT .UNINDENT .sp فایل‌های zone باید شامل مدخلی برای FQDN پرینسیپال کارساز یعنی \fBserver.example.org\fP باشند. .sp فایل \fB/etc/bind/db.10\fP باید ایجاد یا به‌روزرسانی شود: .INDENT 0.0 .INDENT 3.5 .sp .EX ; ; BIND reverse data file for local loopback interface ; $TTL 604800 ; 1 week @ IN SOA server.example.org. root.example.org. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ; Negative Cache TTL ) ; @ IN NS ns. 40 IN PTR ns.example.org. .EE .UNINDENT .UNINDENT .sp فایل \fB/var/lib/bind/db.example.org\fP باید ایجاد یا به‌روزرسانی شود: .INDENT 0.0 .INDENT 3.5 .sp .EX $ORIGIN . $TTL 604800 ; 1 week example.org IN SOA server.example.org. root.example.org. ( 8 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 604800 ; minimum (1 week) ) NS example.org. A ${BIND9_IP_ADDR} AAAA ::1 $ORIGIN example.org. kdc A ${KDC_IP_ADDR} server A ${BIND9_IP_ADDR} .EE .UNINDENT .UNINDENT .sp پس از هرگونه تغییر در پیکربندی، کارساز باید دوباره بارگذاری یا راه‌اندازی مجدد شود: .INDENT 0.0 .INDENT 3.5 .sp .EX systemctl restart named.service .EE .UNINDENT .UNINDENT .sp امکان دریافت وضعیت یا بررسی لاگ‌ها وجود دارد: .INDENT 0.0 .INDENT 3.5 .sp .EX systemctl status named.service journalctl \-u named | tail \-n 30 .EE .UNINDENT .UNINDENT .SS پیکربندی Windows Active Directory .sp این زیربخش بر پایه‌ی Microsoft Windows Server 2016 ارائه‌شده توسط Amazon AWS با Active Directory از پیش نصب‌شده است، بنابراین تنها مراحلی را که برای استقرار GSS\-TSIG به کار رفته‌اند شرح می‌دهد. (برای فرایند کامل پیکربندی، لطفاً به مستندات Microsoft یا سایر منابع خارجی مراجعه کنید. ما این راهنمای آموزشی را در \% هنگام پیکربندی سیستم‌های آزمایش تضمین کیفیت (QA) داخلی خود بسیار مفید یافتیم.) .INDENT 0.0 .TP .B به دو حساب کاربری Active Directory (AD) نیاز است: .INDENT 7.0 .IP \(bu 2 حساب نخست برای دریافت اطلاعات AD، مانند جدول کلید (key table) کلاینت Kea استفاده می‌شود .IP \(bu 2 حساب دوم به principal کلاینت Kea DHCP نگاشت می‌شود .UNINDENT .TP .B برنامه‌ی Kea باید از موارد زیر مطلع باشد: .INDENT 7.0 .IP \(bu 2 نشانی IP کارساز .IP \(bu 2 نام دامنه/realm: نام دامنه با حروف کوچک و realm با حروف بزرگ، هر دو بدون نقطه در انتها .IP \(bu 2 نام کارساز .UNINDENT .UNINDENT .sp حساب دوم (که در زیر \fBkea\fP نامیده شده است) برای ایجاد یک Service Principal Name (SPN) به کار می‌رود: .INDENT 0.0 .INDENT 3.5 .sp .EX setspn \-S DHCP/kea. kea .EE .UNINDENT .UNINDENT .sp سپس یک کلید مخفی مشترک تولید شده و در یک فایل جدول کلید (key table) قرار می‌گیرد: .INDENT 0.0 .INDENT 3.5 .sp .EX ktpass \-princ DHCP/kea.@ \-mapuser kea +rndpass \-mapop set \-ptype KRB5_NT_PRINCIPAL \-out dhcp.keytab .EE .UNINDENT .UNINDENT .sp فایل \fBdhcp.keytab\fP کاربردی مشابه با UNIX Kerberos دارد..SS عیب‌یابی GSS\-TSIG .sp هنگام آزمایش یکپارچه‌سازی GSS\-TSIG با Active Directory به یک خطای بسیار مبهم برخوردیم: .INDENT 0.0 .INDENT 3.5 .sp .EX INFO [kea\-dhcp\-ddns.gss\-tsig\-hooks/4678.139690935890624] GSS_TSIG_VERIFY_FAILED GSS\-TSIG verify failed: gss_verify_mic failed with GSSAPI error: Major = \(aqA token had an invalid Message Integrity Check (MIC)\(aq (393216), Minor = \(aqPacket was replayed in wrong direction\(aq (100002). .EE .UNINDENT .UNINDENT .sp در مورد ما، مشکل این بود که کارساز Kea D2 تلاش می‌کرد یک ناحیهٔ معکوس DNS را در حالی به‌روزرسانی کند که پیکربندی نشده بود. یک راه‌حل ساده، افزودن یک ناحیهٔ معکوس DNS مشابه آنچه در Kea پیکربندی شده است می‌باشد. برای این کار، \(dqDNS Manager\(dq را باز کرده و \(dqDNS\(dq را از فهرست انتخاب کنید؛ سپس از فهرست کشویی، \(dqReverse Lookup Zones\(dq را برگزینید؛ بعد روی \(dqAction\(dq و \(dqNew Zone\(dq کلیک کنید؛ در نهایت، New Zone Wizard را برای افزودن یک ناحیهٔ جدید دنبال کنید. .sp استاندارد به هر دو سرویس ضد بازپخش (anti\-replay) و توالی (sequence) نیاز دارد. تجربیات به‌دست‌آمده با nsupdate در BIND 9 نشان داد که سرویس توالی منجر به بروز مشکلاتی می‌شود، بنابراین به‌طور پیش‌فرض در hook غیرفعال شده است. به نظر می‌رسد سرویس ضد بازپخش نیز می‌تواند باعث ایجاد مشکل در کارسازهای DNS مایکروسافت شود، بنابراین اکنون قابل پیکربندی است. توجه داشته باشید که این سرویس‌های امنیتی برای به‌روزرسانی پویای DNS، که برای اجرا روی UDP و در نتیجه همراه با پیام‌های نامرتب و تکراری طراحی شده، کاربردی ندارند. .SS استفاده از GSS\-TSIG .sp برای فعال‌سازی سازوکار GSS\-TSIG، چند مرحله لازم است: .INDENT 0.0 .IP 1. 3 \fBlibddns_gss_tsig.so\fP \%<#\:std-ischooklib-libddns_gss_tsig\:.so> باید توسط \fBkea\-dhcp\-ddns\fP \%<#\:std-iscman-kea-dhcp-ddns>\& بارگذاری شود. .IP 2. 3 کارسازهای DNS با قابلیت پشتیبانی از GSS\-TSIG باید به همراه پارامترهایشان مشخص شوند. .UNINDENT .sp گزیده‌ای از پیکربندی کارساز D2 در زیر ارائه شده است؛ مثال‌های بیشتر در دایرکتوری \fBdoc/examples/ddns\fP در سورس‌های Kea موجود است. .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcpDdns\(dq: { // The following parameters are used to receive NCRs (NameChangeRequests) // from the local Kea DHCP server. Make sure your kea\-dhcp4 and kea\-dhcp6 // matches this. \(dqip\-address\(dq: \(dq127.0.0.1\(dq, \(dqport\(dq: 53001, \(dqdns\-server\-timeout\(dq : 1000, // Forward zone: secure.example.org. It uses GSS\-TSIG. It is served // by two DNS servers, which listen for DDNS requests at 192.0.2.1 // and 192.0.2.2. \(dqforward\-ddns\(dq: { \(dqddns\-domains\(dq: [ // DdnsDomain for zone \(dqsecure.example.org.\(dq { \(dqname\(dq: \(dqsecure.example.org.\(dq, \(dqcomment\(dq: \(dqDdnsDomain example\(dq, \(dqdns\-servers\(dq: [ { // This server has an entry in gss/servers and // thus will use GSS\-TSIG. \(dqip\-address\(dq: \(dq192.0.2.1\(dq }, { // This server also has an entry there, so will // use GSS\-TSIG, too. \(dqip\-address\(dq: \(dq192.0.2.2\(dq, \(dqport\(dq: 5300 } ] } ] }, // Reverse zone: we want to update the reverse zone \(dq2.0.192.in\-addr.arpa\(dq. \(dqreverse\-ddns\(dq: { \(dqddns\-domains\(dq: [ { \(dqname\(dq: \(dq2.0.192.in\-addr.arpa.\(dq, \(dqdns\-servers\(dq: [ { // There is a GSS\-TSIG definition for this server (see // DhcpDdns/gss\-tsig/servers), so it will use // Krb/GSS\-TSIG. \(dqip\-address\(dq: \(dq192.0.2.1\(dq } ] } ] }, // The GSS\-TSIG hook is loaded and its configuration is specified here. \(dqhooks\-libraries\(dq: [ { \(dqlibrary\(dq: \(dqlibddns_gss_tsig.so\(dq, \(dqparameters\(dq: { // This section governs the GSS\-TSIG integration. Each server // mentioned in forward\-ddns and/or reverse\-ddns needs to have // an entry here to be able to use GSS\-TSIG defaults (optional, // if specified they apply to all the GSS\-TSIG servers, unless // overwritten on specific server level). \(dqserver\-principal\(dq: \(dqDNS/server.example.org@EXAMPLE.ORG\(dq, \(dqclient\-principal\(dq: \(dqDHCP/admin.example.org@EXAMPLE.ORG\(dq, // client\-keytab and credentials\-cache can both be used to // store client keys. As credentials cache is more flexible, // it is recommended to use it. Typically, using both at the // same time may cause problems. // \(dqclient\-keytab\(dq: \(dqFILE:/etc/dhcp.keytab\(dq, // toplevel only \(dqcredentials\-cache\(dq: \(dqFILE:/etc/ccache\(dq, // toplevel only \(dqgss\-replay\-flag\(dq: true, // GSS anti replay service \(dqgss\-sequence\-flag\(dq: false, // no GSS sequence service \(dqtkey\-lifetime\(dq: 3600, // 1 hour \(dqrekey\-interval\(dq: 2700, // 45 minutes \(dqretry\-interval\(dq: 120, // 2 minutes \(dqtkey\-protocol\(dq: \(dqTCP\(dq, \(dqfallback\(dq: false, // The list of GSS\-TSIG capable servers \(dqservers\(dq: [ { // First server (identification is required) \(dqid\(dq: \(dqserver1\(dq, \(dqdomain\-names\(dq: [ ], // if not specified or empty, will // match all domains that want to // use this IP+port pair \(dqip\-address\(dq: \(dq192.0.2.1\(dq, \(dqport\(dq: 53, \(dqserver\-principal\(dq: \(dqDNS/server1.example.org@EXAMPLE.ORG\(dq, \(dqclient\-principal\(dq: \(dqDHCP/admin1.example.org@EXAMPLE.ORG\(dq, \(dqgss\-replay\-flag\(dq: false, // no GSS anti replay service \(dqgss\-sequence\-flag\(dq: false, // no GSS sequence service \(dqtkey\-lifetime\(dq: 7200, // 2 hours \(dqrekey\-interval\(dq: 5400, // 90 minutes \(dqretry\-interval\(dq: 240, // 4 minutes \(dqtkey\-protocol\(dq: \(dqTCP\(dq, \(dqfallback\(dq: true // if no key is available fallback to the // standard behavior (vs skip this server) }, { // The second server (it has most of the parameters missing // as those are using the defaults specified above) \(dqid\(dq: \(dqserver2\(dq, \(dqip\-address\(dq: \(dq192.0.2.2\(dq, \(dqport\(dq: 5300 } ] } } ] // Additional parameters, such as logging, control socket and // others omitted for clarity. } } .EE .UNINDENT .UNINDENT .sp این فایل پیکربندی شامل تعدادی عنصر اضافی است. .sp نخست، فهرستی از دامنه‌های مستقیم و/یا معکوس همراه با کارسازهای DNS مربوطه که با جفت‌های IP+port مشخص شده‌اند، تعریف می‌شود. اگر پورت مشخص نشده باشد، مقدار پیش‌فرض 53 در نظر گرفته می‌شود. این مشابه حالت پایه است که در آن هیچ احراز هویتی با استفاده از کلیدهای TSIG انجام نمی‌شود، با این تفاوت که به کلیدهای استاتیک TSIG با نام ارجاع داده نمی‌شود. .sp دوم، \fBlibddns_gss_tsig.so\fP \%<#\:std-ischooklib-libddns_gss_tsig\:.so> باید در فهرست \fBhooks\-libraries\fP مشخص شود. این hook پارامترهای متعددی می‌گیرد. مهم‌ترین آن‌ها \fBservers\fP است که فهرستی از کارسازهای با قابلیت GSS\-TSIG می‌باشد. اگر چندین کارساز وجود داشته باشد و ویژگی‌های مشترکی داشته باشند، مقادیر می‌توانند در حوزهٔ \fBparameters\fP به عنوان مقادیر پیش‌فرض تعیین شوند. در مثال بالا، مقادیر پیش‌فرضی که برای همهٔ کارسازها اعمال می‌شوند (مگر اینکه در سطح هر کارساز به‌طور خاص بازنویسی شده باشند)، در خطوط 63 تا 68 تعریف شده‌اند. اگر تنها یک کارساز تعریف شده باشد، یا اگر همهٔ کارسازها مقادیر متفاوتی داشته باشند، می‌توان از این مقادیر پیش‌فرض صرف‌نظر کرد..SS فهرست پارامترهای موجود .TS box center; l|l|l|l|l. T{ نام T} T{ محدوده T} T{ نوع T} T{ مقدار پیش‌فرض T} T{ توضیحات T} _ T{ client\-keytab T} T{ سراسری / سرور T} T{ رشته T} T{ خالی T} T{ جدول کلید \fBکلاینت\fP در Kerberos T} _ T{ credentials\-cache T} T{ سراسری / سرور T} T{ رشته T} T{ خالی T} T{ کَش گواهی‌های Kerberos T} _ T{ server\-principal T} T{ سراسری / سرور T} T{ رشته T} T{ خالی T} T{ نام Kerberos principal کارگزار DNS که به‌روزرسانی‌ها را دریافت خواهد کرد T} _ T{ client\-principal T} T{ سراسری / سرور T} T{ رشته T} T{ خالی T} T{ نام Kerberos principal سرویس Kea D2 T} _ T{ gss\-replay\-flag T} T{ سراسری / سرور T} T{ true / false T} T{ true T} T{ الزام سرویس ضددوباره‌رسانی GSS (GSS_C_REPLAY_FLAG) T} _ T{ gss\-sequence\-flag T} T{ سراسری / سرور T} T{ true / false T} T{ false T} T{ الزام سرویس توالی GSS (GSS_C_SEQUENCE_FLAG) T} _ T{ tkey\-protocol T} T{ سراسری / سرور T} T{ رشته \(dqTCP\(dq / \(dqUDP\(dq T} T{ \(dqTCP\(dq T} T{ پروتکل مورد استفاده برای برقراری زمینهٔ امنیتی (security context) با کارگزارهای DNS T} _ T{ tkey\-lifetime T} T{ سراسری / سرور T} T{ uint32 T} T{ .nf 3600 ثانیه ( 1 ساعت ) .fi T} T{ مدت‌زمان اعتبار کلیدهای GSS\-TSIG T} _ T{ rekey\-interval T} T{ سراسری / سرور T} T{ uint32 T} T{ .nf 2700 ثانیه ( 45 دقیقه ) .fi T} T{ بازهٔ زمانی بررسی کلیدها جهت کلیدگذاری مجدد (rekeying) T} _ T{ retry\-interval T} T{ سراسری / سرور T} T{ uint32 T} T{ .nf 120 ثانیه ( 2 دقیقه ) .fi T} T{ بازهٔ زمانی تلاش مجدد برای ایجاد کلید در صورت وقوع هرگونه خطا در دفعات پیشین T} _ T{ fallback T} T{ سراسری / سرور T} T{ true / false T} T{ false T} T{ رفتار بازگشت به حالت غیر GSS\-TSIG در شرایطی که GSS\-TSIG باید استفاده شود اما هیچ کلید GSS\-TSIGای موجود نیست. T} _ T{ exchange\-timeout T} T{ سراسری / سرور T} T{ uint32 T} T{ .nf 3000 میلی‌ثانیه ( 3 ثانیه ) .fi T} T{ مدت‌زمان انتظار برای اتمام تبادل GSS\-TSIG TKEY پیش از آنکه مهلت زمانی آن به پایان برسد (timeout) T} _ T{ ignore\-bad\-direction T} T{ سراسری T} T{ true / false T} T{ false T} T{ نادیده گرفتن خطاهای اعتبارسنجی MIC نامعتبر / جهت نادرست (bad direction). T} _ T{ user\-context T} T{ سراسری / سرور T} T{ رشته T} T{ خالی T} T{ داده‌های ارائه‌شده توسط کاربر در قالب JSON (توسط قلاب GSS\-TSIG استفاده نمی‌شود) T} _ T{ comment T} T{ سراسری / سرور T} T{ رشته T} T{ خالی T} T{ نادیده گرفته می‌شود T} _ T{ id T} T{ سرور T} T{ رشته T} T{ خالی T} T{ شناسهٔ یک کارگزار DNS (الزامی) T} _ T{ domain\-names T} T{ سرور T} T{ فهرستی از رشته‌ها T} T{ خالی T} T{ رابطهٔ چندبه‌یک بین کارگزارهای DNS در D2 و کارگزارهای DNS در GSS\-TSIG T} _ T{ ip\-address T} T{ سرور T} T{ آدرس IPv4 / IPv6 T} T{ خالی T} T{ آدرس IP که کارگزار DNS در GSS\-TSIG برای درخواست‌های DDNS و TKEY روی آن گوش می‌دهد (الزامی) T} _ T{ port T} T{ سرور T} T{ uint16 T} T{ 53 T} T{ درگاه انتقال DNS که کارگزار DNS در GSS\-TSIG برای درخواست‌های DDNS و TKEY روی آن گوش می‌دهد T} .TE .sp پارامترهای سراسری در ادامه شرح داده شده‌اند: .INDENT 0.0.IP \(bu 2 \fBclient\-keytab\fP جدول کلید (key table) \fBclient\fP مربوط به Kerberos را مشخص می‌کند. برای نمونه، \fBFILE:\fP می‌تواند برای اشاره به یک فایل مشخص استفاده شود. این پارامتر تنها یک بار در حوزه (scope) پارامترها قابل تعیین است و معادل تنظیم متغیر محیطی \fBKRB5_CLIENT_KTNAME\fP می‌باشد. یک مقدار خالی بدون ایجاد پیام نادیده گرفته می‌شود. .IP \(bu 2 \fBcredentials\-cache\fP حافظه موقت مدارک هویتی (credentials cache) مربوط به Kerberos را تعیین می‌کند. به عنوان مثال، \fBFILE:\fP می‌تواند برای اشاره به یک فایل به کار رود یا در صورت استفاده از دایرکتوری‌ای که از بیش از یک principal پشتیبانی می‌کند، \fBDIR:\fP\&. این پارامتر تنها یک بار در حوزه پارامترها قابل تعیین است و معادل مقداردهی به متغیر محیطی \fBKRB5CCNAME\fP می‌باشد. یک مقدار خالی بدون پیام نادیده گرفته می‌شود. .IP \(bu 2 \fBserver\-principal\fP نام principal مربوط به Kerberos برای کارساز DNS است که به‌روزرسانی‌ها را دریافت می‌کند. به عبارت دیگر، این نام کارساز DNS در سامانه Kerberos است. این پارامتر اجباری است و از نشانه‌گذاری معمول Kerberos استفاده می‌کند: \fB/@\fP\&. .IP \(bu 2 \fBclient\-principal\fP نام principal در Kerberos برای سرویس Kea D2 است. این پارامتر اختیاری است و از نشانه‌گذاری معمول Kerberos استفاده می‌کند: \fB/@\fP\&. .IP \(bu 2 \fBgss\-replay\-flag\fP مشخص می‌کند که آیا سرویس ضد تکرار (anti replay) در GSS مورد نیاز است یا خیر. به طور پیش‌فرض فعال است اما می‌توان آن را غیرفعال کرد. .IP \(bu 2 \fBgss\-sequence\-flag\fP مشخص می‌کند که آیا سرویس توالی (sequence) در GSS مورد نیاز است یا خیر. به طور پیش‌فرض فعال نیست، اما توسط استاندارد ملزم شده است بنابراین می‌تواند فعال شود. .IP \(bu 2 \fBtkey\-protocol\fP تعیین می‌کند که کدام پروتکل برای برقراری بافت امنیتی (security context) با کارسازهای DNS به کار رود. در حال حاضر، تنها مقادیر پشتیبانی‌شده TCP (پیش‌فرض) و UDP هستند. .IP \(bu 2 \fBtkey\-lifetime\fP طول عمر کلیدهای GSS\-TSIG را در پروتکل TKEY مشخص می‌کند. این مقدار باید بیشتر از مقدار \fBrekey\-interval\fP باشد. این پارامتر بر حسب ثانیه بیان شده و پیش‌فرض آن 3600 (یک ساعت) است. .IP \(bu 2 \fBrekey\-interval\fP فاصله زمانی بررسی کلیدها برای کلیدزنی مجدد (rekeying) به ازای هر کارساز پیکربندی‌شده را مدیریت می‌کند؛ به این معنی که اگر سن کلید قابل استفاده فعلی بیش از مقدار \fBrekey\-interval\fP باشد، کلید جدیدی جایگزین آن می‌شود. این مقدار باید کمتر از مقدار \fBtkey\-lifetime\fP باشد (توصیه می‌شود بین ۵۰٪ تا ۸۰٪ مقدار \fBtkey\-lifetime\fP تنظیم شود). این پارامتر بر حسب ثانیه بیان شده و مقدار پیش‌فرض آن 2700 (۴۵ دقیقه، یا ۷۵٪ از یک ساعت) است. .IP \(bu 2 \fBretry\-interval\fP فاصله زمانی برای تلاش مجدد جهت ساخت کلید را، در صورت وقوع هرگونه خطای قبلی برای هر کارساز پیکربندی‌شده، مدیریت می‌کند. این مقدار باید کمتر از مقدار \fBrekey\-interval\fP باشد، و حداکثر باید ۱/۳ اختلاف بین \fBtkey\-lifetime\fP و \fBrekey\-interval\fP باشد. این پارامتر بر حسب ثانیه بیان شده و پیش‌فرض آن 120 (۲ دقیقه) است. .IP \(bu 2 \fBfallback\fP رفتار سامانه را در زمانی که GSS\-TSIG باید استفاده شود (یک کارساز DNS منطبق پیکربندی شده است) اما هیچ کلید GSS\-TSIG در دسترسی نیست، کنترل می‌کند. اگر روی \fBfalse\fP (پیش‌فرض) تنظیم شود، از این کارساز صرف‌نظر می‌شود؛ اگر روی \fBtrue\fP تنظیم شود، کارساز DNS نادیده گرفته شده و به‌روزرسانی DNS با محافظت DHCP\-DDNS پیکربندی‌شده (مانند کلید TSIG)، یا بدون هیچ حفاظتی (در صورت عدم پیکربندی) ارسال می‌شود. .IP \(bu 2 \fBexchange\-timeout\fP مدت زمانی را تعیین می‌کند که فرآیند پیش از اتمام مهلت (timeout) برای پایان تبادل TKEY در GSS\-TSIG منتظر می‌ماند. این مقدار بر حسب میلی‌ثانیه بیان شده و پیش‌فرض آن 3000 (۳ ثانیه) است. .IP \(bu 2 \fBuser\-context\fP یک پارامتر اختیاری است (برای توضیحات عمومی درباره زمینه‌های کاربری در Kea، بخش Comments and User Context \%<#\:user-context> را ببینید). .IP \(bu 2 \fBcomment\fP مجاز است اما در حال حاضر نادیده گرفته می‌شود. .IP \(bu 2 \fBservers\fP فهرست کارسازهای DNS که GSS\-TSIG در آن‌ها فعال است را مشخص می‌کند. .UNINDENT .sp پارامترهای نقشه کارساز (server map) در زیر شرح داده شده‌اند: .INDENT 0.0 .IP \(bu 2 \fBid\fP یک شناسه به کارساز DNS اختصاص می‌دهد. از آن برای آمار و دستورها استفاده می‌شود. این پارامتر الزامی است و نباید خالی باشد و باید یکتا باشد. .IP \(bu 2 \fBdomain\-names\fP رابطه چندبه‌یک میان کارسازهای DNS مربوط به D2 و کارسازهای DNS مربوط به GSS\-TSIG را مدیریت می‌کند: برای هر نام دامنه در این فهرست، Kea به دنبال کارساز DNS در D2 برای این دامنه با آدرس IP و درگاه (port) مشخص‌شده می‌گردد. یک فهرست خالی (پیش‌فرض) به این معناست که تمام دامنه‌ها منطبق هستند. .IP \(bu 2 \fBip\-address\fP آدرس IP که کارساز DNS مربوط به GSS\-TSIG روی آن به درخواست‌های DDNS و TKEY گوش می‌دهد را مشخص می‌کند. این یک پارامتر الزامی است. .IP \(bu 2 \fBport\fP درگاه انتقال DNS که کارساز DNS مربوط به GSS\-TSIG روی آن به درخواست‌های DDNS و TKEY گوش می‌دهد را مشخص می‌کند. مقدار پیش‌فرض آن 53 است. .IP \(bu 2 \fBserver\-principal\fP نام principal در Kerberos برای کارساز DNS است که به‌روزرسانی‌ها را دریافت می‌کند. پارامتر \fBserver\-principal\fP تنظیم‌شده در سطح هر کارساز بر مقداری که در سطح سراسری تنظیم شده، اولویت دارد. این پارامتر الزامی است و باید در سطح سراسری یا در سطح کارساز مشخص شود. .IP \(bu 2 \fBclient\-principal\fP نام principal در Kerberos برای سرویس Kea D2 جهت این کارساز DNS است. پارامتر \fBclient\-principal\fP تنظیم‌شده در سطح هر کارساز بر مقداری که در سطح سراسری تعیین شده اولویت دارد. این یک پارامتر اختیاری است. .IP \(bu 2 \fBgss\-replay\-flag\fP مشخص می‌کند که آیا سرویس ضد تکرار GSS مورد نیاز است یا خیر. پارامتر \fBgss\-replay\-flag\fP تنظیم‌شده در سطح هر کارساز بر مقدار تنظیم‌شده در سطح سراسری اولویت دارد. این یک پارامتر اختیاری است که پیش‌فرض آن true می‌باشد. .IP \(bu 2 \fBgss\-sequence\-flag\fP مشخص می‌کند که آیا سرویس توالی GSS مورد نیاز است یا خیر. پارامتر \fBgss\-sequence\-flag\fP تنظیم‌شده در سطح هر کارساز بر مقدار تنظیم‌شده در سطح سراسری اولویت دارد. این یک پارامتر اختیاری است که مقدار پیش‌فرض آن false می‌باشد. .IP \(bu 2 \fBtkey\-protocol\fP مشخص می‌کند که چه پروتکلی برای برقراری بافت امنیتی با کارساز DNS به کار رود. پارامتر \fBtkey\-protocol\fP تنظیم‌شده در سطح هر کارساز بر مقدار تنظیم‌شده در سطح سراسری اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر سطح هر کارساز همانند مقادیر پارامتر سطح سراسری است. .IP \(bu 2 \fBtkey\-lifetime\fP طول عمر کلیدهای GSS\-TSIG را در پروتکل TKEY برای کارساز DNS مشخص می‌کند. پارامتر \fBtkey\-lifetime\fP تنظیم‌شده در سطح هر کارساز بر مقدار تعیین‌شده در سطح سراسری اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر در سطح هر کارساز با مقادیر پارامتر در سطح سراسری یکسان است. .IP \(bu 2 \fBrekey\-interval\fP بازه زمانی را تعیین می‌کند که در آن کلیدهای این کارساز خاص برای کلیدزنی مجدد بررسی می‌شوند؛ بدین معنا که اگر سن کلید قابل استفاده فعلی از مقدار \fBrekey\-interval\fP بیشتر باشد، کلید جدیدی جایگزین آن خواهد شد. این مقدار باید از مقدار \fBtkey\-lifetime\fP کوچکتر باشد (توصیه می‌شود بین ۵۰٪ تا ۸۰٪ مقدار \fBtkey\-lifetime\fP تنظیم گردد). پارامتر \fBrekey\-interval\fP تنظیم‌شده در سطح هر کارساز بر مقداری که در سطح سراسری تنظیم شده اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر در سطح هر کارساز مانند پارامتر در سطح سراسری است. .IP \(bu 2 \fBretry\-interval\fP بازه زمانی تلاش مجدد برای ساخت کلید را در صورت وقوع هرگونه خطای قبلی برای این کارساز خاص مدیریت می‌کند. این مقدار باید از مقدار \fBrekey\-interval\fP کوچکتر باشد و حداکثر ۱/۳ اختلاف بین \fBtkey\-lifetime\fP و \fBrekey\-interval\fP باشد. پارامتر \fBretry\-interval\fP تنظیم‌شده در سطح هر کارساز بر مقدار تنظیم‌شده در سطح سراسری اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر در سطح هر کارساز همانند پارامتر در سطح سراسری است. .IP \(bu 2 \fBfallback\fP رفتار سامانه را هنگامی که GSS\-TSIG باید استفاده شود (یک کارساز DNS متناظر پیکربندی شده است) اما کلید GSS\-TSIG در دسترس نیست کنترل می‌کند. پارامتر \fBfallback\fP تنظیم‌شده در سطح هر کارساز بر مقدار تعیین‌شده در سطح سراسری اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر سطح کارساز همانند مقادیر پارامتر در سطح سراسری است. .IP \(bu 2 \fBexchange\-timeout\fP مدت زمانی که پیش از اتمام مهلت فرآیند باید منتظر تبادل GSS\-TSIG TKEY ماند را مدیریت می‌کند. پارامتر \fBexchange\-timeout\fP تنظیم‌شده در سطح هر کارساز بر مقدار تعیین‌شده در سطح سراسری اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر در سطح هر کارساز مانند پارامتر در سطح سراسری است. .IP \(bu 2 \fBignore\-bad\-direction\fP یک راه‌حل موقت (workaround) برای باگ کارساز Microsoft را مدیریت می‌کند. هنگامی که به طور صریح روی true تنظیم شود، پاسخ‌های به‌روزرسانی DNS ارسالی حتی اگر پیش‌نیازها با امضای درخواست شکست بخورند، به عنوان تأییدشده پذیرفته می‌شوند. .IP \(bu 2 \fBuser\-context\fP یک پارامتر اختیاری است (برای توضیحات عمومی درباره زمینه‌های کاربری در Kea، بخش Comments and User Context \%<#\:user-context> را ببینید). .IP \(bu 2 \fBcomment\fP مجاز است اما در حال حاضر نادیده گرفته می‌شود. .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 به طور کلی تعیین همزمان جدول کلید کلاینت (\fBclient\-keytab\fP) و حافظه موقت مدارک هویتی (\fBcredentials\-cache\fP) توصیه نمی‌شود، هرچند ممکن است این مورد در پیاده‌سازی‌های مختلف Kerberos متفاوت باشد. جدول کلید کلاینت تنها برای کلید کلاینت است و به طور معمول برای تعیین صریح کلید به روشی ایستا‌تر به کار می‌رود، در حالی که حافظه موقت مدارک هویتی می‌تواند چندین مدرک را ذخیره کند و می‌تواند توسط کتابخانه Kerberos به صورت پویا به‌روزرسانی شود. به همین دلیل، \fBcredentials\-cache\fP انعطاف‌پذیرتر بوده و در نتیجه گزینه توصیه‌شده است. .sp همچنین توجه داشته باشید که برای استفاده از این حافظه موقت، تنها مجوز دسترسی خواندن لازم است. واکشی مدارک هویتی و به‌روزرسانی حافظه موقت نیازمند مجوز دسترسی نوشتن است. .UNINDENT .UNINDENT.SS حذف خودکار کلید GSS\-TSIG .sp سرور به‌صورت دوره‌ای کلیدها را پس از این‌که مدت زمان انقضای آن‌ها بیش از سه برابر حداکثر عمر کلید (پارامتر \fBtkey\-lifetime\fP) گذشته باشد، حذف می‌کند. کاربر این گزینه را دارد که با استفاده از دستور \fBgss\-tsig\-purge\-all\fP یا دستور \fBgss\-tsig\-purge\fP کلیدها را بر حسب نیاز پاکسازی کند. .SS پیکربندی GSS\-TSIG برای استقرار .sp هنگام استفاده از Kerberos 5 و BIND 9 همان‌طور که در GSS\-TSIG Deployment شرح داده شده است، تحلیل‌گر محلی (local resolver) باید به نشانی سرور \fBnamed\fP در BIND 9 اشاره کند. همچنین Kerberos محلی باید با قرار دادن متن زیر در فایل \fBkrb5.conf\fP پیکربندی شود: .INDENT 0.0 .INDENT 3.5 .sp .EX [libdefaults] default_realm = EXAMPLE.ORG kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] EXAMPLE.ORG = { kdc = kdc.example.org admin_server = kdc.example.org } .EE .UNINDENT .UNINDENT .sp در Windows AD، سرویس DNS توسط AD ارائه می‌شود که سرویس Kerberos را نیز فراهم می‌کند. متن مورد نیاز در فایل \fBkrb5.conf\fP به صورت زیر خواهد بود: .INDENT 0.0 .INDENT 3.5 .sp .EX [libdefaults] default_realm = kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] ${REALM} = { kdc = admin_server = } .EE .UNINDENT .UNINDENT .sp حتی زمانی که کتابخانه GSS\-API می‌تواند از کلید محرمانه موجود در جدول کلید (key table) کلاینت استفاده کند، از نظر کارایی، دریافت و کش کردن اعتبارنامه‌ها (credentials) به مراتب بهتر است. .sp این کار می‌تواند به صورت دستی با دستور زیر انجام شود: .INDENT 0.0 .INDENT 3.5 .sp .EX kinit \-k \-t /usr/local/share/kea/dhcp.keytab DHCP/admin.example.org .EE .UNINDENT .UNINDENT .sp یا هنگام استفاده از AD: .INDENT 0.0 .INDENT 3.5 .sp .EX kinit \-k \-t /usr/local/share/kea/dhcp.keytab DHCP/kea. .EE .UNINDENT .UNINDENT .sp کش اعتبارنامه را می‌توان با استفاده از \fBklist\fP\& نمایش داد. .sp در محیط عملیاتی، بهتر است به یک مدیریت‌کننده اعتبارنامه Kerberos مانند System Security Services Daemon (\fBsssd\fP) تکیه شود. .sp هنگام استفاده از BIND 9، پرینسیپال سرور (server principal) به شکل \(dq\%\&.ORG¨ است؛ با AD، قالب به صورت \(dqDNS/.@\(dq می‌باشد. .SS آمار GSS\-TSIG .sp کتابخانه قلاب GSS\-TSIG آمارهای جدیدی را در سطوح سراسری و به ازای هر سرور DNS معرفی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBgss\-tsig\-key\-created\fP \- تعداد کلیدهای GSS\-TSIG ایجادشده .IP \(bu 2 \fBtkey\-sent\fP \- تعداد درخواست‌های اولیه ارسالی برای تبادل TKEY .IP \(bu 2 \fBtkey\-success\fP \- تعداد تبادلات TKEY که با موفقیت انجام شده‌اند .IP \(bu 2 \fBtkey\-timeout\fP \- تعداد تبادلات TKEY که با اتمام مهلت زمانی (timeout) پایان یافته‌اند .IP \(bu 2 \fBtkey\-error\fP \- تعداد تبادلات TKEY که با خطایی غیر از اتمام مهلت زمانی به پایان رسیده‌اند .UNINDENT .sp رابطه بین کلیدها و سرورهای DNS بین کد D2 و کلیدهای ایستای TSIG، در مقایسه با کلیدهای GSS\-TSIG و سرورهای DNS بسیار متفاوت است: .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 یک کلید ایستای TSIG می‌تواند بین چندین سرور DNS به اشتراک گذاشته شود؛ .IP \(bu 2 یک کلید GSS\-TSIG تنها توسط یک سرور DNS درون یک مجموعه اختصاصی از کلیدها استفاده می‌شود. .UNINDENT .UNINDENT .UNINDENT .SS دستورهای GSS\-TSIG .sp کتابخانه قلاب GSS\-TSIG از چند دستور پشتیبانی می‌کند که در زیر توضیح داده شده‌اند. .SS دستور \fBgss\-tsig\-get\-all\fP .sp این دستور تمامی سرورها و کلیدهای GSS\-TSIG را فهرست می‌کند. .sp یک نمونه از فراخوانی دستور به این صورت است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqgss\-tsig\-get\-all\(dq } .EE .UNINDENT .UNINDENT .sp اینجا نمونه‌ای از پاسخی که یک سرور GSS\-TSIG و یک کلید را بازمی‌گرداند آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq1 GSS\-TSIG servers and 1 keys\(dq, \(dqarguments\(dq: { \(dqgss\-tsig\-servers\(dq: [ { \(dqid\(dq: \(dqfoo\(dq, \(dqip\-address\(dq: \(dq192.1.2.3\(dq, \(dqport\(dq: 53, \(dqserver\-principal\(dq: \(dqDNS/foo.com@FOO.COM\(dq, \(dqkey\-name\-suffix\(dq: \(dqfoo.com.\(dq, \(dqtkey\-lifetime\(dq: 3600, \(dqtkey\-protocol\(dq: \(dqTCP\(dq, \(dqkeys\(dq: [ { \(dqname\(dq: \(dq1234.sig\-foo.com.\(dq, \(dqinception\-date\(dq: \(dq2021\-09\-05 12:23:36.281176\(dq, \(dqserver\-id\(dq: \(dqfoo\(dq, \(dqexpire\-date\(dq: \(dq2021\-09\-05 13:23:36.281176\(dq, \(dqstatus\(dq: \(dqnot yet ready\(dq, \(dqtkey\-exchange\(dq: true } ] }, { \(dqid\(dq: \(dqbar\(dq, \(dqip\-address\(dq: \(dq192.1.2.4\(dq, \(dqport\(dq: 53, \(dqserver\-principal\(dq: \(dqDNS/bar.com@FOO.COM\(dq, \(dqkey\-name\-suffix\(dq: \(dqbar.com.\(dq, \(dqtkey\-lifetime\(dq: 7200, \(dqtkey\-protocol\(dq: \(dqUDP\(dq, \(dqkeys\(dq: [ ] } ] } } .EE .UNINDENT .UNINDENT.SS دستور \fBgss\-tsig\-get\fP .sp این دستور اطلاعات مربوط به سرور GSS\-TSIG مشخص‌شده را بازیابی می‌کند. .sp نمونه‌ای از فراخوانی دستور به این شکل است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqgss\-tsig\-get\(dq, \(dqarguments\(dq: { \(dqserver\-id\(dq: \(dqfoo\(dq } } .EE .UNINDENT .UNINDENT .sp در اینجا نمونه‌ای از یک پاسخ که اطلاعات مربوط به سرور \(dqfoo\(dq را بازمی‌گرداند آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqGSS\-TSIG server[foo] found\(dq, \(dqarguments\(dq: { \(dqid\(dq: \(dqfoo\(dq, \(dqip\-address\(dq: \(dq192.1.2.3\(dq, \(dqport\(dq: 53, \(dqserver\-principal\(dq: \(dqDNS/foo.com@FOO.COM\(dq, \(dqkey\-name\-suffix\(dq: \(dqfoo.com.\(dq, \(dqtkey\-lifetime\(dq: 3600, \(dqtkey\-protocol\(dq: \(dqTCP\(dq, \(dqkeys\(dq: [ { \(dqname\(dq: \(dq1234.sig\-foo.com.\(dq, \(dqserver\-id\(dq: \(dqfoo\(dq, \(dqinception\-date\(dq: \(dq2021\-09\-05 12:23:36.281176\(dq, \(dqexpire\-date\(dq: \(dq2021\-09\-05 13:23:36.281176\(dq, \(dqstatus\(dq: \(dqnot yet ready\(dq, \(dqtkey\-exchange\(dq: true } ] } } .EE .UNINDENT .UNINDENT .SS دستور \fBgss\-tsig\-list\fP .sp این دستور فهرستی از شناسه سرورهای GSS\-TSIG و نام کلیدها را ایجاد می‌کند. .sp نمونه‌ای از فراخوانی دستور به این شکل است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqgss\-tsig\-list\(dq } .EE .UNINDENT .UNINDENT .sp در اینجا نمونه‌ای از یک پاسخ که دو سرور GSS\-TSIG و سه کلید را بازمی‌گرداند آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 GSS\-TSIG servers and 3 keys\(dq, \(dqarguments\(dq: { \(dqgss\-tsig\-servers\(dq: [ \(dqfoo\(dq, \(dqbar\(dq ], \(dqgss\-tsig\-keys\(dq: [ \(dq1234.example.com.\(dq, \(dq5678.example.com.\(dq, \(dq43888.example.org.\(dq ] } } .EE .UNINDENT .UNINDENT .SS دستور \fBgss\-tsig\-key\-get\fP .sp این دستور اطلاعات مربوط به کلید GSS\-TSIG مشخص‌شده را بازیابی می‌کند. .sp نمونه‌ای از فراخوانی دستور به این شکل است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqgss\-tsig\-key\-get\(dq, \(dqarguments\(dq: { \(dqkey\-name\(dq: \(dq1234.sig\-foo.com.\(dq } } .EE .UNINDENT .UNINDENT .sp در اینجا نمونه‌ای از یک پاسخ که اطلاعات مربوط به کلید GSS\-TSIG با عنوان \(dq1234.sig\-foo.com.\(dq را بازمی‌گرداند آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqGSS\-TSIG key \(aq1234.sig\-foo.com.\(aq found\(dq, \(dqarguments\(dq: { \(dqname\(dq: \(dq1234.sig\-foo.com.\(dq, \(dqserver\-id\(dq: \(dqfoo\(dq, \(dqinception\-date\(dq: \(dq2021\-09\-05 12:23:36.281176\(dq, \(dqexpire\-date\(dq: \(dq2021\-09\-05 13:23:36.281176\(dq, \(dqstatus\(dq: \(dqnot yet ready\(dq, \(dqtkey\-exchange\(dq: true } } .EE .UNINDENT .UNINDENT.SS دستور \fBgss\-tsig\-key\-expire\fP .sp این دستور کلید GSS\-TSIG مشخص‌شده را منقضی می‌کند. .sp نمونه‌ای از فراخوانی دستور به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqgss\-tsig\-key\-expire\(dq, \(dqarguments\(dq: { \(dqkey\-name\(dq: \(dq1234.sig\-foo.com.\(dq } } .EE .UNINDENT .UNINDENT .sp در اینجا نمونه‌ای از یک پاسخ آورده شده است که نشان می‌دهد کلید GSS\-TSIG با نام \(dq1234.sig\-foo.com.\(dq منقضی شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqGSS\-TSIG key \(aq1234.sig\-foo.com.\(aq expired\(dq } .EE .UNINDENT .UNINDENT .SS دستور \fBgss\-tsig\-key\-del\fP .sp این دستور کلید GSS\-TSIG مشخص‌شده را حذف می‌کند. .sp نمونه‌ای از فراخوانی دستور به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqgss\-tsig\-key\-del\(dq, \(dqarguments\(dq: { \(dqkey\-name\(dq: \(dq1234.sig\-foo.com.\(dq } } .EE .UNINDENT .UNINDENT .sp در اینجا نمونه‌ای از یک پاسخ آورده شده است که نشان می‌دهد کلید GSS\-TSIG با نام \(dq1234.sig\-foo.com.\(dq حذف شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqGSS\-TSIG key \(aq1234.sig\-foo.com.\(aq deleted\(dq } .EE .UNINDENT .UNINDENT .SS دستور \fBgss\-tsig\-purge\-all\fP .sp این دستور تمام کلیدهای غیرقابل‌استفاده‌ی GSS\-TSIG را پاک‌سازی می‌کند. .sp نمونه‌ای از فراخوانی دستور به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqgss\-tsig\-purge\-all\(dq } .EE .UNINDENT .UNINDENT .sp در اینجا نمونه‌ای از یک پاسخ آورده شده است که نشان می‌دهد دو کلید GSS\-TSIG پاک‌سازی شده‌اند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 purged GSS\-TSIG keys\(dq } .EE .UNINDENT .UNINDENT .SS دستور \fBgss\-tsig\-purge\fP .sp این دستور کلیدهای غیرقابل‌استفاده‌ی GSS\-TSIG را برای سرور مشخص‌شده پاک‌سازی می‌کند. .sp نمونه‌ای از فراخوانی دستور به صورت زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqgss\-tsig\-purge\(dq, \(dqarguments\(dq: { \(dqserver\-id\(dq: \(dqfoo\(dq } } .EE .UNINDENT .UNINDENT .sp در اینجا نمونه‌ای از یک پاسخ آورده شده است که نشان می‌دهد دو کلید GSS\-TSIG برای سرور \(dqfoo\(dq پاک‌سازی شده‌اند: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 purged keys for GSS\-TSIG server[foo]\(dq } .EE .UNINDENT .UNINDENT.SS دستور \fBgss\-tsig\-rekey\-all\fP .sp این دستور بدون قید و شرط کلیدهای جدید GSS\-TSIG را برای تمام کارگزارهای DNS مجدداً ایجاد می‌کند (عملیات تجدید کلید یا rekey). .sp نمونه‌ای از فراخوانی این دستور به شکل زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqgss\-tsig\-rekey\-all\(dq } .EE .UNINDENT .UNINDENT .sp در ادامه نمونه‌ای از پاسخی که نشان می‌دهد تجدید کلید انجام شده است آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqrekeyed\(dq } .EE .UNINDENT .UNINDENT .sp این دستور به عنوان مثال هنگامی که کارگزار DHCP\-DDNS مجدداً به شبکه متصل می‌شود مفید است. .SS دستور \fBgss\-tsig\-rekey\fP .sp این دستور بدون قید و شرط کلیدهای جدید GSS\-TSIG را برای یک کارگزار DNS مشخص بازتولید می‌کند (عملیات rekey). .sp نمونه‌ای از فراخوانی این دستور به شکل زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqgss\-tsig\-rekey\(dq, \(dqarguments\(dq: { \(dqserver\-id\(dq: \(dqfoo\(dq } } .EE .UNINDENT .UNINDENT .sp در ادامه نمونه‌ای از پاسخی که نشان می‌دهد تجدید کلید انجام شده است آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqGSS\-TSIG server[foo] rekeyed\(dq } .EE .UNINDENT .UNINDENT .sp این دستور معمولاً زمانی استفاده می‌شود که یک کارگزار DNS بازراه‌اندازی (reboot) شده باشد، به طوری که کلیدهای GSS\-TSIG مشترک فعلی با این کارگزار دیگر قابل استفاده نباشند. .SS RADIUS .SS هشدار امنیتی (Security Warning) .sp امنیت RADIUS/UDP (و RADIUS/TCP) مبتنی بر استفاده مستقیم از MD5 به همراه کلید مخفی مشترک (shared secret) و گذرواژه دسترسی کاربر است. این سازوکارهای امنیتی به ضعیف بودن شناخته می‌شدند، اما این موضوع با انتشار آسیب‌پذیری Blast\-RADIUS در \% (شناسه CVE\-2024\-3596 در \%) دگرگون شد. .sp به طور خلاصه، زمانی که زیرساخت ارتباطی میان کلاینت RADIUS (در اینجا کارگزار Kea DHCP) و کارگزار RADIUS محافظت‌نشده باشد، یک مهاجم مرد میانی (man\-in\-the\-middle) می‌تواند در پاسخ به یک درخواست دسترسی / احراز هویت ناموفق، یک پیام پذیرش (accept) معتبر جعل کند. .sp برخی از کارگزارهای RADIUS از جمله کارگزار پرکاربرد FreeRADIUS از هم‌اکنون به صورت پیش‌فرض از پاسخ‌گویی به درخواست‌هایی که به دلیل عدم محافظت توسط مشخصه Message\-Authenticator ناامن تلقی می‌شوند خودداری می‌کنند (این مشخصه مبتنی بر HMAC\-MD5 است و بنابراین آسیب‌پذیر نبوده و از Kea 3.1.5 به بعد پشتیبانی می‌شود)؛ بنابراین حتی زمانی که زیرساخت محافظت‌شده باشد، استقرار RADIUS تحت تأثیر Blast\-RADIUS قرار می‌گیرد. .sp راهکارهای ارائه‌شده توسط نسخه 3.1.6 از Kea عبارتند از: .sp ۱. پشتیبانی از RADIUS/TLS که حفاظت رمزنگاری‌شده توکار را برای ارتباط میان کلاینت‌ها و کارگزارهای RADIUS فراهم می‌کند. این روش به عنوان راهکار بلندمدت شناخته می‌شود. .sp ۲. پشتیبانی از راهکار کوتاه‌مدت با افزودن مشخصه Message\-Authenticator به تمام پیام‌های ارسالی و الزام به وجود آن در تمام پیام‌های دریافتی (توجه داشته باشید که مورد دوم تنها توسط کارگزارهای جدید RADIUS اعمال می‌شود). .sp این راهکارها آزمایشی (experimental) هستند. .SS نمای کلی RADIUS (RADIUS Overview) .sp این کتابخانه قلاب (hook library) به Kea امکان می‌دهد با دو نوع از خدمات RADIUS تعامل داشته باشد: دسترسی (access) و حسابرسی (accounting). متداول‌ترین شیوه یکپارچه‌سازی DHCP و RADIUS در سطح عامل رله DHCP (relay\-agent) انجام می‌شود: کلاینت‌های DHCP بسته‌های DHCP را به رله‌های DHCP می‌فرستند؛ این رله‌ها با کارگزار RADIUS ارتباط برقرار کرده و بسته به پاسخ، بسته را به کارگزار DHCP ارسال می‌کنند یا آن را نادیده می‌گیرند (drop می‌کنند). با این حال، این کار مستلزم پشتیبانی سخت‌افزار رله DHCP از ارتباطات RADIUS است، و حتی اگر رله پشتیبانی لازم را داشته باشد، اغلب به اندازه کافی انعطاف‌پذیر نیست تا مشخصه‌های اضافی RADIUS را ارسال و دریافت کند. یک جایگزین جذاب‌تر وجود دارد: توسعه دادن کارگزار DHCP برای برقراری ارتباط مستقیم با RADIUS. این موضوع، هدف اصلی این کتابخانه است. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 این کتابخانه تنها می‌تواند توسط فرایندهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. .UNINDENT .UNINDENT .sp ویژگی عمده این کتابخانه قلاب، امکان استفاده از مجوزدهی (authorization) توسط RADIUS است. هنگامی که یک بسته DHCP دریافت می‌شود، کارگزار Kea یک Access\-Request به کارگزار RADIUS ارسال کرده و منتظر پاسخ می‌ماند. سپس کارگزار پاسخی به صورت Access\-Accept با مشخصه‌های خاص کلاینت یا Access\-Reject برمی‌گرداند. در اینجا دو حالت پشتیبانی می‌شود: نخست، Access\-Accept شامل مشخصه Framed\-IP\-Address (برای DHCPv4) یا مشخصه Framed\-IPv6\-Address/Delegated\-IPv6\-Prefix (برای DHCPv6) است که توسط Kea به عنوان دستورالعملی برای اختصاص آدرس IPv4 یا IPv6 یا پیشوند IPv6 مشخص‌شده تفسیر می‌شود. این سازوکار در عمل بدان معناست که RADIUS می‌تواند به عنوان یک پایگاه داده رزرو آدرس عمل کند. .sp دومین حالت پشتیبانی‌شده، قابلیت تخصیص کلاینت‌ها به استخرهای (pools) خاص بر اساس پاسخ RADIUS است. در این حالت، کارگزار RADIUS یک Access\-Accept همراه با مشخصه Framed\-Pool ارسال می‌کند. برای هر دو پروتکل DHCPv4 و DHCPv6، کارگزار Kea این مشخصه را به عنوان یک کلاس کلاینت (client class) در نظر می‌گیرد. با افزودن قابلیت محدودسازی دسترسی به استخرها برای کلاس‌های خاص (به بخش پیکربندی استخرها با اطلاعات کلاس \%<#\:classification-pools> مراجعه کنید)، می‌توان از RADIUS برای واداشتن کلاینت به تخصیص یک نشانی پویا یا پیشوند از استخری خاص استفاده کرد. علاوه بر این، در صورتی که گزینه‌های DHCP برای یک کلاس مشخص تعریف شده باشند، می‌توان از همین سازوکار برای کنترل اینکه کلاینت چه نوع گزینه‌هایی را دریافت می‌کند نیز بهره گرفت..SS پیکربندی کتابخانه هوک RADIUS .sp هوک RADIUS کتابخانه‌ای است که باید توسط کارسازهای \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> یا \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6> بارگذاری شود. برخلاف برخی دیگر از کتابخانه‌های هوک موجود، این کتابخانه پارامترهای متعددی می‌گیرد. برای نمونه، می‌توان از این پیکربندی استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqDhcp4\(dq: { // پارامترهای پیکربندی معمول DHCPv4 شما در اینجا قرار می‌گیرند. \(dqhooks\-libraries\(dq: [ { // توجه داشته باشید که سرویس دسترسی RADIUS برای عملکرد صحیح به host\-cache نیاز دارد، // بنابراین این کتابخانه نیز بارگذاری می‌شود. \(dqlibrary\(dq: \(dqlibdhcp_host_cache.so\(dq }, { \(dqlibrary\(dq: \(dqlibdhcp_radius.so\(dq, \(dqparameters\(dq: { // مشخص کنید لغت‌نامه در کجا قرار دارد. \(dqdictionary\(dq: \(dq/etc/kea/radius/dictionary\(dq, // مشخص کنید از کدام آدرس برای برقراری ارتباط با کارسازهای RADIUS استفاده شود \(dqbindaddr\(dq: \(dq*\(dq // پارامترهای بیشتر RADIUS در اینجا قرار می‌گیرند. } } ] } } .EE .UNINDENT .UNINDENT .sp محیط RADIUS پیچیده است. از این رو، ارائه یک پیکربندی پیش‌فرض که برای همگان کارآمد باشد امکان‌پذیر نیست. با این حال، ما نمونه‌ای داریم که برخی از ویژگی‌های رایج‌تر را نشان می‌دهد؛ لطفاً kea4/hooks\-radius.json \%<#\:config-example-kea4-hooks-radius-json>\& را ببینید. .sp کتابخانه هوک RADIUS از پرچم‌های پیکربندی سراسری زیر پشتیبانی می‌کند: .INDENT 0.0 .IP \(bu 2 \fBbindaddr\fP (پیش‌فرض \fB\(dq*\(dq\fP) \- آدرسی را که باید توسط کتابخانه هوک در ارتباط با کارسازهای RADIUS استفاده شود مشخص می‌کند. مقدار ویژه \fB\(dq*\(dq\fP به هسته می‌گوید که آدرس را در زمان بارگذاری کتابخانه هوک انتخاب کند. .IP \(bu 2 \fBcanonical\-mac\-address\fP (پیش‌فرض \fBfalse\fP) \- مشخص می‌کند که آیا نشانی‌های MAC در صفت‌ها از قالب رسمی RADIUS (جفت‌رقم‌های هگزادسیمال کوچک جداشده با \fB\-\fP) پیروی کنند یا خیر. .IP \(bu 2 \fBclient\-id\-pop0\fP (پیش‌فرض \fBfalse\fP) \- همراه با \fBlibdhcp_flex_id.so\fP \%<#\:std-ischooklib-libdhcp_flex_id\:.so> استفاده می‌شود؛ صفر ابتدایی (یا جفت صفر در DHCPv6) نوع شناسه کلاینت (DUID در DHCPv6) را حذف می‌کند. برای هرگونه پیامدهای مقداری در صورت استفاده هم‌زمان با آن، به \fBclient\-id\-printable\fP مراجعه کنید. .IP \(bu 2 \fBclient\-id\-printable\fP (پیش‌فرض \fBfalse\fP) \- بررسی می‌کند که آیا محتوای \fBclient\-id\fP/\fBduid\fP قابل‌چاپ است یا خیر و به جای هگزادسیمال، آن را همان‌طور که هست استفاده می‌کند. این گزینه مستلزم اعمال خودکار \fBclient\-id\-pop0\fP و \fBextract\-duid\fP است، زیرا 0 و 255 قابل‌چاپ نیستند. .IP \(bu 2 \fBdeadtime\fP (پیش‌فرض \fB0\fP) \- سازوکاری است که به مرتب‌سازی کارسازها کمک می‌کند تا ابتدا با کارسازهایی که تا کنون پاسخگو بوده‌اند ارتباط برقرار شود، و کارسازهایی که پاسخگو نبوده‌اند برای تلاش‌های بعدی گذاشته شوند. مقدار deadtime تعداد ثانیه‌هایی را مشخص می‌کند که پس از آن یک کارساز غیرپاسخگو در نظر گرفته می‌شود. مقدار 0 این سازوکار را غیرفعال می‌کند. .IP \(bu 2 \fBdictionary\fP (پیش‌فرض \fB\(dq/etc/kea/radius/dictionary\(dq\fP) \- لغت‌نامه صفت‌ها و مقادیر است؛ توجه داشته باشید که این یک پارامتر حیاتی است. یک لغت‌نامه توسط Kea ارائه شده و به صورت پیش‌فرض تنظیم گردیده است. .IP \(bu 2 \fBextract\-duid\fP (پیش‌فرض \fBtrue\fP) \- مقدار DUID تعبیه‌شده را از یک شناسه کلاینت DHCPv4 منطبق با RFC 4361 استخراج می‌کند. برای هرگونه پیامدهای مقداری در صورت استفاده هم‌زمان با آن، به \fBclient\-id\-printable\fP مراجعه کنید. .IP \(bu 2 \fBidentifier\-type4\fP (پیش‌فرض \fB\(dqclient\-id\(dq\fP) \- نوع شناسه را برای ساخت صفت User\-Name برای DHCPv4 مشخص می‌کند؛ این مقدار باید با شناسه میزبان یکسان باشد. هنگامی که از \fBlibdhcp_flex_id.so\fP \%<#\:std-ischooklib-libdhcp_flex_id\:.so> استفاده می‌شود، \fBreplace\-client\-id\fP باید روی \fBtrue\fP تنظیم شده و \fBclient\-id\fP همراه با فعال بودن \fBclient\-id\-pop0\fP به کار رود. .IP \(bu 2 \fBidentifier\-type6\fP (پیش‌فرض \fB\(dqduid\(dq\fP) \- نوع شناسه را برای ساخت صفت User\-Name برای DHCPv6 مشخص می‌کند؛ این مقدار باید با شناسه میزبان یکسان باشد. هنگامی که از \fBlibdhcp_flex_id.so\fP \%<#\:std-ischooklib-libdhcp_flex_id\:.so> استفاده می‌شود، \fBreplace\-client\-id\fP باید روی \fBtrue\fP تنظیم شده و \fBduid\fP همراه با فعال بودن \fBclient\-id\-pop0\fP به کار رود. .IP \(bu 2 \fBnas\-ports\fP (پیش‌فرض \fB[]\fP) \- پورت NAS را برای استفاده به جای شناسه زیرشبکه (رفتار پیش‌فرض) مشخص می‌کند. این یک آرایه از نگاشت‌ها است که هر نگاشت حداکثر دو عنصر دارد: مقدار الزامی پورت NAS، و به صورت اختیاری، یک انتخاب‌گر متشکل از شناسه زیرشبکه، پیشوند زیرشبکه یا نام شبکه اشتراکی (shared\-network). اگر انتخاب‌گر بر روی بسته اعمال شود، پورت NAS به جای شناسه زیرشبکه استفاده خواهد شد. زمانی که شناسه زیرشبکه 0 باشد یا وجود نداشته باشد، پورت NAS مشخص‌شده به عنوان پیش‌فرض عمل می‌کند. این جایگزینی برای تمامی بسته‌هایی که با هیچ انتخاب‌گری مطابقت نداشته‌اند رخ می‌دهد. .IP \(bu 2 \fBprotocol\fP (پیش‌فرض \fBUDP\fP) \- از نسخه Kea 3.1.6، پروتکل لایه انتقال را مشخص می‌کند. مقادیر پذیرفته‌شده عبارتند از \fBUDP\fP و \fBTLS\fP\&. .IP \(bu 2 \fBreselect\-subnet\-address\fP (پیش‌فرض \fBfalse\fP) \- انتخاب مجدد زیرشبکه را با توجه به مقدار صفت Framed\-IP\-Address یا به ترتیب Framed\-IPv6\-Address دریافتی از پاسخ دسترسی RADIUS فعال می‌کند. با فعال بودن این پرچم، اگر نشانی IP در محدوده زیرشبکه فعلیِ انتخاب‌شده نباشد، اما در محدوده زیرشبکه دیگری باشد که با توجه به معیارهای دیگر قابل انتخاب است، زیرشبکه دوم انتخاب شده و در مراحل بعدی تخصیص اجاره به کار می‌رود. .IP \(bu 2 \fBreselect\-subnet\-pool\fP (پیش‌فرض \fBfalse\fP) \- انتخاب مجدد زیرشبکه را با توجه به مقدار صفت Framed\-Pool دریافتی از پاسخ دسترسی RADIUS فعال می‌کند. با فعال بودن این پرچم، اگر زیرشبکه انتخاب‌شده فعلی توسط کلاس کلاینت نشان‌داده‌شده با مقدار صفت محافظت نشده باشد، اما زیرشبکه قابل‌انتخاب دیگری وجود داشته باشد که توسط آن محافظت شده است، زیرشبکه دوم انتخاب شده و در ادامه فرایند تخصیص اجاره استفاده می‌شود. این انتخاب مجدد ابتدا امتحان می‌شود و در صورت موفقیت، از به کار افتادن عملکرد \fBreselect\-subnet\-address\fP جلوگیری می‌کند. .IP \(bu 2 \fBretries\fP (پیش‌فرض \fB3\fP) \- تعداد تلاش‌های مجدد پیش از امتحان کردن کارساز بعدی است. .IP \(bu 2 \fBsession\-history\fP (پیش‌فرض \fB\(dq\(dq\fP) \- نام فایلی است که حافظه پایدار را برای تاریخچه نشست‌های حسابرسی فراهم می‌کند. .UNINDENT .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fBthread\-pool\-size\fP (پیش‌فرض \fB0\fP) نشان‌دهنده تعداد ریسه‌هایی است که برای ارسال درخواست‌های RADIUS و پردازش پاسخ‌های RADIUS برای هر دو سرویس دسترسی و حسابرسی قبل از انتقال آن‌ها به استخر ریسه هسته استفاده می‌شوند. مقدار \fB0\fP به کتابخانه هوک RADIUS دستور می‌دهد تا از همان تعداد ریسه‌های استفاده‌شده برای پردازش هسته DHCP استفاده کند. این مقدار تنها در صورتی اهمیت دارد که هسته Kea به صورت چندریسه‌ای پیکربندی شده باشد؛ یک هسته تک‌ریسه‌ای Kea منجر به پردازش تک‌ریسه‌ای RADIUS خواهد شد. .UNINDENT .UNINDENT .UNINDENT .INDENT 0.0 .IP \(bu 2 \fBtimeout\fP (پیش‌فرض \fB10\fP) \- تعداد ثانیه‌هایی است که طی آن برای یک پاسخ انتظار کشیده می‌شود. .IP \(bu 2 \fBuse\-message\-authenticator\fP (پیش‌فرض \fBtrue\fP هنگامی که پروتکل \fBTLS\fP نیست) \- یک صفت Message\-Authenticator به تمامی پیام‌های ارسالی اضافه می‌کند و وجود آن را در تمامی پیام‌های دریافتی الزامی می‌سازد. این می‌تواند به عنوان یک راهکار کاهش موقت در برابر آسیب‌پذیری BLAST استفاده شود، اما تنها با نسخه‌های اخیر کارسازهای RADIUS کار می‌کند که می‌توان آن‌ها را طوری پیکربندی کرد که این صفت را در تمام پاسخ‌ها قرار دهند. .UNINDENT .sp دو سرویس پشتیبانی می‌شوند: .INDENT 0.0 .IP \(bu 2 \fBaccess\fP \- سرویس مجوزدهی. .IP \(bu 2 \fBaccounting\fP \- سرویس حسابرسی. .UNINDENT .sp در سطح سرویس، سه بخش قابل پیکربندی است: .INDENT 0.0 .IP \(bu 2 کارسازهایی که سرویس‌های RADIUS را که انتظار می‌رود کتابخانه با آن‌ها ارتباط برقرار کند تعریف می‌کنند. برای هر کارساز می‌توان موارد زیر را مشخص کرد: .INDENT 2.0 .IP \(bu 2 \fBname\fP \- نشانی IP کارساز را مشخص می‌کند. می‌توان از یک نام دامنه استفاده کرد که در زمان بارگذاری کتابخانه هوک تحلیل خواهد شد. .IP \(bu 2 \fBport\fP \- پورت UDP کارساز را مشخص می‌کند. به صورت پیش‌فرض، 1812 برای دسترسی و 1813 برای حسابرسی است. .IP \(bu 2 \fBsecret\fP \- پیام‌ها را اصالت‌سنجی می‌کند. .IP \(bu 2 \fBtrust\-anchor\fP \- از نسخه Kea 3.1.6، نام فایل یا دایرکتوری‌ای را مشخص می‌کند که گواهی مرجع صدور گواهی (CA) در آن یافت می‌شود. همراه با پروتکل TLS الزامی است و در غیر این صورت نادیده گرفته می‌شود. .IP \(bu 2 \fBcert\-file\fP \- از نسخه Kea 3.1.6، نام فایل حاوی گواهی نهاد نهایی (end\-entity) مورد استفاده را مشخص می‌کند. همراه با پروتکل TLS الزامی است و در غیر این صورت نادیده گرفته می‌شود. .IP \(bu 2 \fBkey\-file\fP \- از نسخه Kea 3.1.6، کلید خصوصی گواهی نهاد نهایی مورد استفاده را مشخص می‌کند. همراه با پروتکل TLS الزامی است و در غیر این صورت نادیده گرفته می‌شود. .UNINDENT .sp هنگامی که هیچ کارسازی مشخص نشده باشد، سرویس غیرفعال است. .IP \(bu 2 صفت‌هایی که اطلاعات اضافی ارسالی توسط کارساز Kea به یک کارساز RADIUS را تعریف می‌کنند. این پارامتر باید با یک نام یا نوع شناسایی شود. مقدار آن می‌تواند به یکی از سه روش ممکن مشخص گردد: \fBdata\fP (که یک مقدار متن ساده را تعریف می‌کند)، \fBraw\fP (که مقدار را به صورت هگزادسیمال تعریف می‌کند)، یا \fBexpr\fP (که عبارتی را تعریف می‌کند که برای هر بسته ورودی به طور مستقل ارزیابی می‌شود). .INDENT 2.0.IP \(bu 2 \fBname\fP \- نام صفت است. .IP \(bu 2 \fBtype\fP \- نوع صفت است. باید نوع یا نام مشخص شود، و صفت باید در لغت‌نامه (dictionary) تعریف شده باشد. .IP \(bu 2 \fBdata\fP \- نخستین روش از سه روش برای مشخص کردن محتوای صفت است. این گزینه نمایش متنی محتوای صفت را مشخص می‌کند. .IP \(bu 2 \fBraw\fP \- دومین روش از سه روش برای مشخص کردن محتوای صفت است. این گزینه محتوا را در قالب شانزده‌شانزدهی (hexadecimal) مشخص می‌کند. .IP \(bu 2 \fBexpr\fP \- آخرین روش از سه روش برای مشخص کردن محتوای صفت است. این گزینه یک عبارت ارزیابی را روی بسته پرسمان DHCP مشخص می‌کند. .IP \(bu 2 \fBvendor\fP \- از Kea 3.1.2 به بعد، شناسه سازنده (vendor id) صفت است. این مقدار همواره حاوی یک رشته با نام سازنده یا یک لیترال عدد صحیح است. .UNINDENT .INDENT 2.0 .INDENT 3.5 صفت‌ها فقط برای سرویس access پشتیبانی می‌شوند. .UNINDENT .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 صفت Vendor\-Specific را می‌توان به دو روش مشخص کرد: استفاده از یک مقدار \fBraw\fP که باید شامل سازنده و داده‌های vsa باشد؛ توجه داشته باشید که مقدار \fBdata\fP از نسخه Kea 3.1.2 دیگر پشتیبانی نمی‌شود، و مقدار \fBexpr\fP به محتوای صفت ارزیابی می‌شود. روش دوم در نسخه 3.1.2 افزوده شد و امکان مشخص کردن یک صفت سازنده را می‌دهد که به‌طور خودکار درون یک صفت Vendor\-Specific تعبیه می‌شود. .UNINDENT .UNINDENT .INDENT 0.0 .IP \(bu 2 پرچم بولی \fBpeer\-updates\fP (پیش‌فرض \fBtrue\fP) مشخص می‌کند که آیا به‌روزرسانی‌های اجاره (lease) که از یک همتای فعال دسترسی‌پذیری بالا (HA) می‌آیند باید منجر به یک درخواست accounting شوند یا خیر. این امر ممکن است برای حذف موارد تکراری در صورتی که همتاهای HA برای ارسال درخواست به همان کارساز RADIUS پیکربندی شده باشند، مطلوب باشد. این پرچم تنها توسط سرویس accounting پشتیبانی می‌شود. فرایند همگام‌سازی اجاره در هنگام راه‌اندازی یک گره HA، صرف‌نظر از مقدار این پرچم، درخواست RADIUS accounting ایجاد نمی‌کند. .IP \(bu 2 عدد صحیح مثبت \fBmax\-pending\-requests\fP (پیش‌فرض \fB0\fP) تعداد درخواست‌های معلق RADIUS را محدود می‌کند. این مقدار فقط توسط سرویس access پشتیبانی می‌شود. مقدار \fB0\fP به معنای عدم وجود محدودیت است؛ مقدار \fB64\fP یک تنظیم توصیه‌شده است. .IP \(bu 2 عدد صحیح مثبت \fBidle\-timer\-interval\fP (پیش‌فرض \fB0\fP) فاصله زمانی بین آخرین پاسخ معتبر از کارسازها و ارسال یک پیام \fBStatus\-Server\fP را مشخص می‌کند. مقدار \fB0\fP به معنای غیرفعال کردن این سازوکار است که در نسخه Kea 3.1.5 افزوده شد. .IP \(bu 2 از نسخه Kea 3.1.6 با پروتکل TLS، پرچم بولی \fBenabled\fP (پیش‌فرض \fBtrue\fP) امکان فعال یا غیرفعال کردن سرویس‌های \fBaccess\fP و \fBaccounting\fP را فراهم می‌کند. .UNINDENT .sp برای نمونه، جهت مشخص کردن یک تک‌کارساز access موجود روی localhost که از \fB\(dq1234\(dq\fP به عنوان رمز (secret) استفاده می‌کند، و دستور به Kea برای ارسال سه صفت اضافی (\fBUser\-Password\fP، \fBConnect\-Info\fP و \fBConfiguration\-Token\fP)، قطعه‌کد زیر می‌تواند استفاده شود: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqparameters\(dq: { // Other RADIUS parameters here \(dqaccess\(dq: { // This starts the list of access servers. \(dqservers\(dq: [ { // These are parameters for the first (and only) access server \(dqname\(dq: \(dq127.0.0.1\(dq, \(dqport\(dq: 1812, \(dqsecret\(dq: \(dq1234\(dq } // Additional access servers could be specified here. ], // This defines a list of additional attributes Kea will send to each // access server in Access\-Request. \(dqattributes\(dq: [ { // This attribute is identified by name (must be present in the // dictionary) and has static value (i.e. the same value will be // sent to every server for every packet). \(dqname\(dq: \(dqUser\-Password\(dq, \(dqdata\(dq: \(dqmysecretpassword\(dq }, { // It is also possible to specify an attribute using its type, // rather than a name. 77 is Connect\-Info. The value is specified // using hex. Again, this is a static value. It will be sent the // same for every packet and to every server. \(dqtype\(dq: 77, \(dqraw\(dq: \(dq65666a6a71\(dq }, { // This example shows how an expression can be used to send dynamic value. // The expression (see Using Expressions in Classification \%<#\:classification-using-expressions>) may take any // value from the incoming packet or even its metadata e.g. the // interface it was received over from. \(dqname\(dq: \(dqConfiguration\-Token\(dq, \(dqexpr\(dq: \(dqhexstring(pkt4.mac,\(aq:\(aq)\(dq } ] // End of attributes }, // End of access // Accounting parameters. \(dqaccounting\(dq: { // This starts the list of accounting servers. \(dqservers\(dq: [ { // These are parameters for the first (and only) accounting server \(dqname\(dq: \(dq127.0.0.1\(dq, \(dqport\(dq: 1813, \(dqsecret\(dq: \(dq1234\(dq } // Additional accounting servers could be specified here. ] } } } .EE .UNINDENT .UNINDENT .sp گاهی اوقات سفارشی‌سازی برای برخی از صفت‌ها توسط دستگاه‌های متعلق به سازندگان مختلف مورد نیاز است. این یک روش عالی برای بهره‌گیری از سازوکار ارزیابی عبارت است. برای نمونه، نشانی‌های MAC که ممکن است به عنوان یک مقدار برای صفت \fBUser\-Password\fP استفاده شوند، به احتمال زیاد در قالب نمایش دونقطه\-شانزده‌شانزدهی (\fBde:ad:be:ef:ca:fe\fP) ظاهر می‌شوند، اما ممکن است لازم باشد در قالب خط‌تیره\-شانزده‌شانزدهی (\fBde\-ad\-be\-ef\-ca\-fe\fP) بیان شوند. روش مشخص کردن آن در اینجا آمده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqparameters\(dq: { \(dqaccess\(dq: { \(dqattributes\(dq: [ { \(dqname\(dq: \(dqUser\-Password\(dq, \(dqexpr\(dq: \(dqhexstring(pkt4.mac, \(aq\-\(aq)\(dq } ] } } } .EE .UNINDENT .UNINDENT .sp و در اینجا نحوه مشخص کردن نماد شانزده‌شانزدهی جداشده با نقطه (\fBdead.beef.cafe\fP) که توسط دستگاه‌های Cisco ترجیح داده می‌شود، آورده شده است: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqparameters\(dq: { \(dqaccess\(dq: { \(dqattributes\(dq: [ { \(dqname\(dq: \(dqUser\-Password\(dq, \(dqexpr\(dq: \(dqsubstring(hexstring(pkt4.mac, \(aq\(aq), 0, 4) + \(aq.\(aq + substring(hexstring(pkt4.mac, \(aq\(aq), 4, 4) + \(aq.\(aq + substring(hexstring(pkt4.mac, \(aq\(aq), 8, 4)\(dq } ] } } } .EE .UNINDENT .UNINDENT .sp برای اینکه سرویس access در \fBlibdhcp_radius.so\fP \%<#\:std-ischooklib-libdhcp_radius\:.so> به درستی کار کند، \fBlibdhcp_host_cache.so\fP \%<#\:std-ischooklib-libdhcp_host_cache\:.so> نیز باید بارگذاری شود. دلیل این امر تا حدی پیچیده است. در یک استقرار معمولی، کلاینت‌های DHCP بسته‌های خود را از طریق DHCP relay ارسال می‌کنند، که گزینه‌های مشخصی از Relay Agent Information را درج می‌کند، مانند \fBcircuit\-id\fP یا \fBremote\-id\fP\&. سپس مقادیر آن گزینه‌ها توسط کارساز Kea DHCP برای فرمول‌بندی صفت‌های لازم در پیام Access\-Request ارسال‌شده به کارساز RADIUS استفاده می‌شوند. با این حال، هنگامی که کلاینت DHCP نشانی خود را دریافت کرد، با ارسال مستقیم بسته‌ها به کارساز DHCP آن را تمدید می‌کند. رله‌ها در آن مرحله نمی‌توانند گزینه‌های RAI خود را درج کنند، و کارساز DHCP نمی‌تواند تنها با استفاده از اطلاعات بسته‌های دریافتی، پرسمان‌های Access\-Request را به کارساز RADIUS ارسال کند. Kea باید اطلاعات دریافت شده در تبادلات اولیه Discover/Offer را نگه دارد و بعداً هنگام ارسال پیام‌های accounting دوباره از آن‌ها استفاده کند. .sp این سازوکار بر اساس بافت کاربر (user context) در رزروهای میزبان پیاده‌سازی شده است. (برای جزئیات بیشتر به Comments and User Context \%<#\:user-context> و User Contexts in Hooks \%<#\:user-context-hooks> مراجعه کنید.) سازوکار host\-cache امکان ذخیره و استفاده مجدد از اطلاعات دریافت‌شده توسط RADIUS را فراهم می‌کند، به جای اینکه یک رفت‌وبرگشت احراز هویت دیگر به کارساز RADIUS انجام شود. به عبارت دیگر، سازوکار host\-cache برای سرویس access الزامی است. اگر \fBlibdhcp_host_cache.so\fP \%<#\:std-ischooklib-libdhcp_host_cache\:.so> در کنار \fBlibdhcp_radius.so\fP \%<#\:std-ischooklib-libdhcp_radius\:.so> بارگذاری نشود، پیکربندی Kea رد می‌شود. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر کتابخانه قلاب RADIUS با پارامتر سراسری \fBearly\-global\-reservations\-lookup\fP ناسازگار است؛ به این معنی که تنظیم این پارامتر روی \fBtrue\fP هنگام بارگذاری کتابخانه قلاب، خطایی ایجاد می‌کند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر کتابخانه قلاب RADIUS با شبکه‌های اشتراکی چندزیرشبکه‌ای که دارای رزرو میزبان غیرسراسری هستند ناسازگار است. بارگذاری کتابخانه قلاب RADIUS در یک کارساز Kea DHCP که دارای چنین پیکربندی‌ای باشد، خطایی ایجاد می‌کند. .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر پارامترهای \fBreselect\-subnet\-address\fP و \fBreselect\-subnet\-pool\fP با پیکربندی hub\-and\-spoke در \fBlibdhcp_ha.so\fP \%<#\:std-ischooklib-libdhcp_ha\:.so> ناسازگار هستند. این کتابخانه قلاب از یک زیرشبکه انتخاب‌شده اولیه برای تعیین رابطه HA جهت پردازش بسته استفاده می‌کند. انتخاب مجدد زیرشبکه ممکن است با این انتخاب تداخل پیدا کند. برای جزئیات به Hub and Spoke Configuration \%<#\:ha-hub-and-spoke> مراجعه کنید. .UNINDENT .UNINDENT.SS "پیکربندی RADIUS/TLS" .sp در Kea 3.1.6 پشتیبانی از RADIUS/TLS با اعمال تغییراتی در پیکربندی ارائه شده است، عمدتاً به این دلیل که در TLS از یک اتصال اشتراکی استفاده می‌شود (در برابر درگاه‌های مختلف UDP). .INDENT 0.0 .IP \(bu 2 پارامتر جدید \fBprotocol\fP باید روی \fBTLS\fP تنظیم شود\&. .IP \(bu 2 یک مدخل سرویس جدید به نام \fBtls\fP باید برای تعریف پارامترهای \fBservers\fP و \fBidle\-timer\-interval\fP استفاده شود. .IP \(bu 2 این پارامترها دیگر در مدخل‌های سرویس \fBaccess\(ga و \(ga\(gaaccounting\fP مجاز نیستند. .IP \(bu 2 از آنجا که مدخل \fBservers\fP وجود ندارد، سرویس‌های \fBaccess\fP و \fBaccounting\fP می‌توانند با تنظیم پرچم \fBenabled\fP روی \fBfalse\fP غیرفعال شوند\&. .IP \(bu 2 مدخل‌های سرور برای تنظیم پارامترهای TLS شامل \fBtrust\-anchor\fP، \fBcert\-file\fP و \fBkey\-file\fP الزامی هستند. .IP \(bu 2 درگاه سرور پیش‌فرض (و یکتا) \fB2083\fP است\&. .IP \(bu 2 مدخل \fBsecret\fP دیگر الزامی نیست و مقدار پیش‌فرض آن \fBradsec\fP است\&. .UNINDENT .sp برای نمونه، پیکربندی یک تک‌سرور access با RADIUS/TLS به این صورت درمی‌آید: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqparameters\(dq: { // Set the protocol to TLS (default is UDP). \(dqprotocol\(dq: \(dqTLS\(dq, // Other RADIUS parameters here // Access parameters. \(dqaccess\(dq: { // This defines a list of additional attributes Kea will send to each // access server in Access\-Request. \(dqattributes\(dq: [ { // This attribute is identified by name (must be present in the // dictionary) and has static value (i.e. the same value will be // sent to every server for every packet). \(dqname\(dq: \(dqUser\-Password\(dq, \(dqdata\(dq: \(dqmysecretpassword\(dq } ] // End of attributes }, // End of access // Accounting parameters. \(dqaccounting\(dq: { // Disabling this service. \(dqenabled\(dq: false }, // End of accounting // TLS parameters. \(dqtls\(dq: { // This starts the list of servers. \(dqservers\(dq: [ { \(dqname\(dq: \(dq127.0.0.1\(dq, \(dqport\(dq: 2083, \(dqsecret\(dq: \(dqradsec\(dq, \(dqtrust\-anchor\(dq: \(dq/usr/lib/kea/CA.pem\(dq, \(dqcert\-file\(dq: \(dq/usr/lib/kea/server_cert.pem\(dq, \(dqkey\-file\(dq: \(dq/usr/lib/kea/server_key.pem\(dq } ] } } } .EE .UNINDENT .UNINDENT .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 در حال حاضر تنها نخستین سرور پیکربندی‌شده استفاده می‌شود. پارامترهای \fBretries\fP و \fBdeadtime\fP بدون هیچ هشداری نادیده گرفته می‌شوند. به‌دلیل برخی محدودیت‌ها در پیاده‌سازی کلاینت TCP، نشانی محلی را نمی‌توان تنظیم کرد (یعنی تنظیم پارامتر \fBbindaddr\fP نادیده گرفته می‌شود)، و درخواست‌ها پایپ‌لاین (pipelined) نمی‌شوند؛ بدین معنی که پیش از ارسال درخواستی دیگر بر روی همان اتصال، باید منتظر پاسخ ماند. زمانی که چندریسمانی (multi\-threading) فعال باشد، چندین اتصال (تا سقف تعداد ریسمان‌ها) را می‌توان به‌طور موازی باز کرد. .UNINDENT .UNINDENT .SS "نمونه راه‌اندازی سرور RADIUS" .sp کتابخانه قلاب (hook) RADIUS برای کارکرد به حداقل یک سرور RADIUS نیاز دارد. یکی از پیاده‌سازی‌های متن‌باز و محبوب FreeRADIUS است؛ در اینجا نحوه راه‌اندازی آن برای فعال‌سازی قابلیت‌های پایه‌ای در Kea آمده است. .INDENT 0.0 .IP 1. 3 نرم‌افزار FreeRADIUS را از طریق مدیر بسته یا از پرونده‌های tarball موجود در [صفحه بارگیری freeradius.org](\%) نصب کنید. .IP 2. 3 شاخه پیکربندی FreeRADIUS را مشخص کنید. این شاخه معمولاً \fB/etc/freeradius\fP است، اما ممکن است \fB/etc/raddb\fP نیز باشد\&. .IP 3. 3 گواهی‌ها را ایجاد کنید. به مسیر \fB/etc/freeradius/certs\fP بروید\&. دستور \fB\&./bootstrap\fP یا \fBmake\fP را اجرا کنید\&. تا پایان کار منتظر بمانید. این فرآیند باید چند ثانیه طول بکشد. .IP 4. 3 بررسی کنید که سرور قادر به اجرا شدن باشد. اجرا با پرچم \fB\-X\fP روشی مناسب برای نمایش خطاهای احتمالی است. بسته به این که کدام دستور موجود است، \fBradiusd \-X\fP یا \fBfreeradius \-X\fP را اجرا کنید. در سطر پایانی باید عبارت \fBReady to process requests\fP نمایش داده شود. .IP 5. 3 اگر سرور DHCP در Kea و سرور RADIUS بر روی ماشین‌های جداگانه‌ای قرار دارند، فایل \fB/etc/freeradius/clients.conf\fP را با نشانی مناسب ذیل \fBipadddr\fP ویرایش کنید\&. این فایل همچنین مکانی است که رمز (secret) در آن تنظیم می‌شود؛ این مقدار باید با آنچه در پیکربندی کتابخانه قلاب تنظیم شده مطابقت داشته باشد. .IP 6. 3 اگر از RADIUS برای احراز مجوز کلاینت‌های DHCP استفاده می‌شود، هر کلاینت DHCP باید یک مدخل در فایل authorize داشته باشد که معمولاً در مسیرهای زیر یافت می‌شود: .INDENT 3.0 .IP \(bu 2 \fB/etc/raddb/mods\-config/files/authorize\fP .IP \(bu 2 \fB/etc/freeradius/3.0/mods\-config/files/authorize\fP .IP \(bu 2 \fB/etc/freeradius/users\fP (برای سری RADIUS 2.x) .UNINDENT .sp گذرواژه‌های این مدخل‌ها باید با گذرواژه‌های موجود در پیکربندی کتابخانه قلاب RADIUS تحت مشخصه \fBUser\-Password\fP مطابقت داشته باشد. هر مدخل می‌تواند دارای صفر یا چند مشخصه باشد. .sp در مثال زیر، شش مدخل وجود دارد که گذرواژه آن‌ها بر روی شناسه کلاینت تنظیم شده است؛ این مقدار باید به‌صورت پویا در پیکربندی کتابخانه قلاب تنظیم شود. شکل مدخل‌ها ممکن است به این صورت باشد: .INDENT 3.0 .INDENT 3.5 .sp .EX 01:00:0c:01:02:03:04 Cleartext\-password := \(dq00:0c:01:02:03:04\(dq 01:00:0c:01:02:03:05 Cleartext\-password := \(dq00:0c:01:02:03:05\(dq Framed\-IP\-Address = \(dq192.0.2.5\(dq 01:00:0c:01:02:03:06 Cleartext\-password := \(dq00:0c:01:02:03:06\(dq Framed\-IP\-Address = \(dq192.0.2.6\(dq, Framed\-Pool = \(dqclassical\(dq 00:03:00:01:00:0c:01:02:03:07 Cleartext\-password := \(dq00:0c:01:02:03:07\(dq 00:03:00:01:00:0c:01:02:03:08 Cleartext\-password := \(dq00:0c:01:02:03:08\(dq Framed\-IPv6\-Address = \(dq2001:db8::8\(dq 00:03:00:01:00:0c:01:02:03:09 Cleartext\-password := \(dq00:0c:01:02:03:09\(dq Framed\-IPv6\-Address = \(dq2001:db8::9\(dq, Framed\-Pool = \(dqclassroom\(dq .EE .UNINDENT .UNINDENT .IP 7. 3 نیازی به تغییر accounting برای کار با Kea نیست، اما امکان اعمال سفارشی‌سازی‌ها در فایل accounting وجود دارد، فایلی که معمولاً در مسیرهای زیر یافت می‌شود: .INDENT 3.0 .IP \(bu 2 \fB/etc/radius\-config/mods\-config/files/accounting\fP .IP \(bu 2 \fB/etc/freeradius/3.0/mods\-config/files/accounting\fP .UNINDENT .IP 8. 3 هنگامی که RADIUS/TLS استفاده می‌شود، بهتر است اعتبارنامه‌های TLS را به هویت کلاینت مقید (bind) کنید. این کار با استفاده از عبارت زیر امکان‌پذیر است: .INDENT 3.0 .INDENT 3.5 .sp .EX check_cert_cn = %{User\-Name} .EE .UNINDENT .UNINDENT .sp که Common Name مربوط به موضوع (subject) گواهی کلاینت TLS (یعنی Kea) را با User\-Name در RADIUS مطابقت می‌دهد. .UNINDENT.SS جریان‌های کاری RADIUS برای تخصیص اجاره (Lease Allocation) .sp نمودارهای زیر نمای کلی سطح بالایی از نحوه کمک RADIUS به فرایند تخصیص اجاره در \fBkea\-dhcp4\fP \%<#\:std-iscman-kea-dhcp4> و \fBkea\-dhcp6\fP \%<#\:std-iscman-kea-dhcp6>\& را نشان می‌دهند. .INDENT 0.0 .INDENT 2.5 [تصویر] .UNINDENT .UNINDENT .sp مورد فراخوانی (callout) \fBcommand_processed\fP که تا حدودی خارج از مبحث تخصیص اجاره است و در نمودارهای بالا نشان داده نشده است، هنگام دریافت یک فرمان اجاره (lease command)، پیام‌های Accounting\-Request را ارسال می‌کند. .SS محدودیت Parked\-Packet .sp برای آشنایی اولیه با نگه‌داری بسته (packet parking)، به Parked\-Packet Limit \%<#\:parked-packet-limit> مراجعه کنید. .sp کتابخانه هوک (hook) RADIUS از این سازوکار استفاده می‌کند. برای فراهم کردن امکان ارتباط ناهمگام (asynchronous) میان Kea و سرور RADIUS و پردازش هم‌روند بسته‌های DHCP توسط سرور Kea، پیش از ارسال درخواست دسترسی (access request) در فراخوانیِ subnet select، درخواست DHCP متوقف (park) می‌شود. زمانی که پاسخ دسترسی در دسترس سرور DHCP Kea قرار گرفت، درخواست از حالت توقف خارج شده (unparked) و سرور به پردازش آن ادامه می‌دهد. .SS تفاوت‌های میان کتابخانه‌های هوک RADIUS پیش از Kea 2.4.0 و از نسخه 2.6.0 به بعد .sp کتابخانه هوک RADIUS در نسخه 2.4.0 و نسخه‌های پیشین برای کارکرد خود به کتابخانه کلاینت FreeRADIUS متکی بود. از نسخه 2.6.0 به بعد، کتابخانه هوک RADIUS مستقل است و پیاده‌سازی کلاینت RADIUS و دیکشنری RADIUS اختصاصی خود را دارد. تفاوت‌ها عبارتند از: .TS box center; l|l|l. T{ ویژگی T} T{ قدیمی T} T{ جدید T} _ T{ پشتیبانی از انواع داده مشخصه (Attribute) T} T{ string, ipaddr, ipv4prefix, integer, integer64, date, ifid, ipv6addr, ipv6prefix, tlv, abinary, byte, ether, short, signed, octets T} T{ string (می‌تواند هر نوع داده پشتیبانی‌نشده دیگر را نیز شبیه‌سازی کند)، ipaddr، integer، date (به عنوان integer تفسیر می‌شود)، ipv6addr، ipv6prefix T} _ T{ نام‌های مشخصه‌های استاندارد T} T{ گرفته‌شده از دیکشنری FreeRADIUS. T} T{ گرفته‌شده از دیکشنری RADIUS در Kea و رجیستری IANA. یک سازوکار نام مستعار (aliasing) در کتابخانه تعبیه شده است که سازگاری رو به عقب را تضمین می‌کند؛ برای نمونه \fBPassword\fP به نام استاندارد مشخصه \fBUser\-Password\fP ترجمه می‌شود.\& T} _ T{ تفکیک نام دامنه سرورهای RADIUS T} T{ در زمان اجرا (run time). T} T{ در زمان بارگذاری کتابخانه هوک. T} _ T{ استنتاج خودکار آدرس مبدأ برای دسترسی به سرورهای RADIUS (پیکربندی‌شده با \fBbindaddr: \(dq*\(dq\fP) T} T{ در زمان اجرا (run time). T} T{ در زمان بارگذاری کتابخانه هوک. T} _ T{ محدودیت سرور RADIUS به ازای هر سرویس T} T{ 8 T} T{ نامحدود T} _ T{ پشتیبانی از گنجاندن دیکشنری‌ها درون دیکشنری‌ها T} T{ بله T} T{ از Kea 3.1.2 به بعد T} _ T{ پشتیبانی از مشخصه‌های فروشنده (Vendor Attributes) T} T{ بله T} T{ از Kea 3.1.2 به بعد T} _ T{ نام‌ها و مقادیر مشخصه‌ها T} T{ غیرحساس به حروف کوچک و بزرگ T} T{ حساس به حروف کوچک و بزرگ T} _ T{ مقادیر عدد صحیح (Integer) T} T{ نیازی به تعریف مشخصه ندارند. T} T{ باید تعریف مشخصه مرتبط در دیکشنری داشته باشند. T} _ T{ فضاهای نام مشخصه و مقدار عددی T} T{ فضاهای نام مسطح (flat) که مقادیر تکراری را مجاز می‌دانند. T} T{ از Kea 3.1.2 به بعد فضاهای نام مجزا به ازای هر فروشنده (vendor). T} _ T{ حضور Reply\-Message در لاگ‌های Kea T} T{ فقط به عنوان بخشی از فهرست تجمیعی مشخصه‌ها در پیام‌های لاگ \fBRADIUS_AUTHENTICATION_ACCEPTED\fP، \fBRADIUS_ACCESS_CACHE_INSERT\fP و \fBRADIUS_ACCESS_CACHE_GET\fP. T} T{ همچنین دارای یک پیام اختصاصی \fBRADIUS_REPLY_MESSAGE_ATTRIBUTE\fP به ازای هر مشخصه Reply\-Message است که پس از دریافت پاسخ معتبر RADIUS ثبت می‌شود. T} _ T{ رفتار در مواجهه با چندین مشخصه از یک نوع (به جز Reply\-Message) T} T{ به صورت تجربی، تنها \fBنخستین\fP مشخصه روی سیم (on the wire) از یک پیام Access\-Accept در نظر گرفته می‌شود. T} T{ به صورت تجربی، تنها \fBآخرین\fP مشخصه روی سیم (on the wire) از یک پیام Access\-Accept در نظر گرفته می‌شود. T} .TE.SS استانداردهای RADIUS پشتیبانی‌شده .sp پروتکل Remote Authentication Dial In User Service (RADIUS) در RFC 2865 \%\& مشخص شده است. .sp بخش RADIUS Accounting در RFC 2866 \%\& مشخص شده است. .sp صفت Message\-Authenticator در افزونه EAP در RFC 3579 \%\& مشخص شده است. .sp پیام Status\-Server در RFC 5997 \%\& مشخص شده است. .sp انتقال TCP (پشتیبانی‌نشده، اما برای TLS ارجاع فراوانی به آن داده شده است) در RFC 6613 \%\& مشخص شده است. .sp انتقال TLS (شناخته‌شده با عنوان RADIUS/TLS یا \fBradsec\fP) در RFC 6614 \%\& مشخص شده است. .SH "پایش KEA با STORK (MONITORING KEA WITH STORK)" .sp بیشتر مدیران سیستم تمایل دارند بتوانند سرویس‌های Kea در حال اجرا را پایش کنند. Kea اطلاعات بسیار متنوعی ارائه می‌دهد \- فایل‌های پیکربندی، API، آمارها، گزارش‌ها (logs)، محتوای پایگاه داده باز و موارد دیگر \- به‌گونه‌ای که دنبال کردن همه‌ی آن‌ها گاهی ممکن است دشوار باشد. پروژه Stork متعلق به ISC با هدف رفع این مشکل برای هر دو نرم‌افزار Kea و BIND 9 طراحی شده است. Stork از جنبه‌های گوناگونی سودمند است: .INDENT 0.0 .IP \(bu 2 ابزار Stork می‌تواند به‌عنوان داشبورد استفاده شود. این ابزار دید عمیقی از آنچه دقیقاً در سرورها رخ می‌دهد فراهم می‌آورد. به‌ویژه، به کاربران امکان می‌دهد: جزئیات به‌روز مربوط به بهره‌برداری از pool در زیرشبکه‌ها و شبکه‌های اشتراکی (shared networks) را مشاهده کنند؛ وضعیت جفت HA را پایش نمایند (و در صورت بروز رخدادهای تغییر وضعیت خرابی (failover) و بازیابی، اطلاعات بیشتری فراهم کند)؛ رزروهای میزبان (host reservations) خاص را فهرست، پالایش و جستجو کنند؛ و موارد بیشتر. فقط کافی است یک سرور واحد Stork و بر روی هر ماشینی که باید پایش شود یک Stork agent مستقر گردد. .IP \(bu 2 عامل Stork می‌تواند Kea را با Prometheus و Grafana یکپارچه‌سازی کند. به‌محض فعال شدن Stork agent در سرور، به‌عنوان یک صادرکننده Prometheus (Prometheus exporter) عمل می‌کند. کاربرانی که Prometheus را در شبکه‌های خود مستقر کرده‌اند می‌توانند آمارها را به‌صورت سری زمانی با استفاده از Grafana بصری‌سازی کنند. .IP \(bu 2 ابزار Stork می‌تواند هم به‌عنوان داشبورد و هم به‌عنوان یکپارچه‌ساز برای Prometheus/Grafana عمل کند. پس از اتصال Stork به محل استقرار Grafana در شبکه، کاربران می‌توانند وضعیت فعلی را بررسی کرده و با باز کردن پیوند سفارشی در Grafana، رفتار یک مشخصه خاص را در گذر زمان مشاهده نمایند. .UNINDENT .sp ابزار Stork هم به‌صورت کد منبع و هم در قالب بسته‌های بومی deb و RPM در دسترس است که نصب آن را روی اکثر سیستم‌های متداول آسان می‌سازد. برای جزئیات بیشتر، لطفاً به راهنمای مرجع Stork ARM \% یا صفحه پروژه Stork \%\& مراجعه کنید. سند ARM مجموعه‌ای مناسب از نماگرفت‌ها دارد که مکرراً به‌روزرسانی می‌شود تا تصویری از آنچه اکنون در دسترس است به کاربران ارائه دهد. Stork در میانه فرایند توسعه همه‌جانبه با انتشارهای ماهانه است، بنابراین پیشنهاد می‌شود مرتباً آن را بررسی کنید. .sp \fBنکته:\fP .INDENT 0.0 .INDENT 3.5 ابزار Stork از فراخوانی‌های Kea API از قلاب‌های \fBlibdhcp_host_cmds.so\fP \%<#\:std-ischooklib-libdhcp_host_cmds\:.so> و \fBlibdhcp_subnet_cmds.so\fP \%<#\:std-ischooklib-libdhcp_subnet_cmds\:.so> برای اعمال تغییرات در پیکربندی Kea استفاده می‌کند. چنین استفاده‌ای با Kea Configuration Backend \%<#\:config-backend> (CB) ناسازگار است. در حال حاضر Stork پشتیبانی از \fBlibdhcp_cb_cmds.so\fP \%<#\:std-ischooklib-libdhcp_cb_cmds\:.so> را که برای اعمال تغییرات در پیکربندی CB مورد نیاز است، پیاده‌سازی نکرده است. در صورت استفاده از Kea CB، ابزار Stork را تنها می‌توان با اطمینان در حالت \(dqread\-only\(dq (فقط‌خواندنی) به کار برد. پشتیبانی از CB برای نسخه‌های آتی Stork برنامه‌ریزی شده است. .UNINDENT .UNINDENT .SS آمارهای Kea در Grafana .sp پروژه ISC Stork عاملی را ارائه می‌دهد که می‌تواند در کنار Kea مستقر شود. این عامل آمارهای Kea را در قالبی که توسط Prometheus پذیرفته می‌شود ارائه می‌دهد. یکی از مزایای عمده Prometheus این است که مشاهدات تکرارشونده یک‌باره را به سری‌های زمانی تبدیل می‌کند؛ امری که به کاربران امکان می‌دهد تغییرات رفتارهای مشخص را در گذر زمان پایش کنند. استفاده از سایر ابزارها برای بصری‌سازی داده‌های موجود در Prometheus آسان است؛ متداول‌ترین رویکرد، استفاده از Grafana جهت ارائه داشبوردهای بصری است. پروژه Stork تعاریف داشبوردی را برای Kea ارائه می‌کند که به‌سادگی در Grafana قابل درون‌ریزی است. .sp درباره Prometheus و Grafana در وب‌سایت‌های آن‌ها بیشتر بیاموزید: \fIPrometheus \fP و \fIGrafana \fP\&. .SH "مرجع API (API REFERENCE)" .sp در حال حاضر Kea از ۲۱۹ دستور در دیمن‌های kea\-dhcp\-ddns، kea\-dhcp4 و kea\-dhcp6 و کتابخانه‌های قلاب cb_cmds، class_cmds، gss_tsig، high_availability، host_cache، host_cmds، lease_cmds، lease_query، perfmon، stat_cmds و subnet_cmds پشتیبانی می‌کند. .sp دستورهای پشتیبانی‌شده توسط دیمن \fIkea\-dhcp\-ddns\fP: build\-report, config\-get, config\-hash\-get, config\-reload, config\-set, config\-test, config\-write, gss\-tsig\-get, gss\-tsig\-get\-all, gss\-tsig\-key\-del, gss\-tsig\-key\-expire, gss\-tsig\-key\-get, gss\-tsig\-list, gss\-tsig\-purge, gss\-tsig\-purge\-all, gss\-tsig\-rekey, gss\-tsig\-rekey\-all, list\-commands, shutdown, statistic\-get, statistic\-get\-all, statistic\-reset, statistic\-reset\-all, status\-get, version\-get\&. .sp دستورهای پشتیبانی‌شده توسط دیمن \fIkea\-dhcp4\fP: build\-report, cache\-clear, cache\-flush, cache\-get, cache\-get\-by\-id, cache\-insert, cache\-load, cache\-remove, cache\-size, cache\-write, class\-add, class\-del, class\-get, class\-list, class\-update, config\-backend\-pull, config\-get, config\-hash\-get, config\-reload, config\-set, config\-test, config\-write, dhcp\-disable, dhcp\-enable, extended\-info4\-upgrade, ha\-continue, ha\-heartbeat, ha\-maintenance\-cancel, ha\-maintenance\-notify, ha\-maintenance\-start, ha\-reset, ha\-scopes, ha\-sync, ha\-sync\-complete\-notify, interface\-add, interface\-list, interface\-redetect, kea\-lfc\-start, lease4\-add, lease4\-del, lease4\-get, lease4\-get\-all, lease4\-get\-by\-client\-id, lease4\-get\-by\-hostname, lease4\-get\-by\-hw\-address, lease4\-get\-by\-state, lease4\-get\-page, lease4\-resend\-ddns, lease4\-update, lease4\-wipe, lease4\-write, leases\-reclaim, list\-commands, network4\-add, network4\-del, network4\-get, network4\-list, network4\-subnet\-add, network4\-subnet\-del, perfmon\-control, perfmon\-get\-all\-durations, remote\-class4\-del, remote\-class4\-get, remote\-class4\-get\-all, remote\-class4\-set, remote\-global\-parameter4\-del, remote\-global\-parameter4\-get, remote\-global\-parameter4\-get\-all, remote\-global\-parameter4\-set, remote\-network4\-del, remote\-network4\-get, remote\-network4\-list, remote\-network4\-set, remote\-option\-def4\-del, remote\-option\-def4\-get, remote\-option\-def4\-get\-all, remote\-option\-def4\-set, remote\-option4\-global\-del, remote\-option4\-global\-get, remote\-option4\-global\-get\-all, remote\-option4\-global\-set, remote\-option4\-network\-del, remote\-option4\-network\-set, remote\-option4\-pool\-del, remote\-option4\-pool\-set, remote\-option4\-subnet\-del, remote\-option4\-subnet\-set, remote\-server4\-del, remote\-server4\-get, remote\-server4\-get\-all, remote\-server4\-set, remote\-subnet4\-del\-by\-id, remote\-subnet4\-del\-by\-prefix, remote\-subnet4\-get\-by\-id, remote\-subnet4\-get\-by\-prefix, remote\-subnet4\-list, remote\-subnet4\-set, reservation\-add, reservation\-del, reservation\-get, reservation\-get\-all, reservation\-get\-by\-address, reservation\-get\-by\-hostname, reservation\-get\-by\-id, reservation\-get\-page, reservation\-update, server\-tag\-get, sflq\-pool4\-del, sflq\-pool4\-get\-all, sflq\-pool4\-get\-by\-range, sflq\-pool4\-get\-by\-subnet, sflq\-pool4\-rebuild, sflq\-pool6\-del, sflq\-pool6\-get\-all, sflq\-pool6\-get\-by\-range, sflq\-pool6\-get\-by\-subnet, sflq\-pool6\-rebuild, shutdown, stat\-lease4\-get, statistic\-get, statistic\-get\-all, statistic\-global\-get\-all, statistic\-remove, statistic\-remove\-all, statistic\-reset, statistic\-reset\-all, statistic\-sample\-age\-set, statistic\-sample\-age\-set\-all, statistic\-sample\-count\-set, statistic\-sample\-count\-set\-all, status\-get, subnet4\-add, subnet4\-del, subnet4\-delta\-add, subnet4\-delta\-del, subnet4\-get, subnet4\-list, subnet4\-select\-test, subnet4\-update, subnet4o6\-select\-test, version\-get\&. .sp دستورهای پشتیبانی‌شده توسط دیمن \fIkea\-dhcp6\fP: build\-report, cache\-clear, cache\-flush, cache\-get, cache\-get\-by\-id, cache\-insert, cache\-load, cache\-remove, cache\-size, cache\-write, class\-add, class\-del, class\-get, class\-list, class\-update, config\-backend\-pull, config\-get, config\-hash\-get, config\-reload, config\-set, config\-test, config\-write, dhcp\-disable, dhcp\-enable, extended\-info6\-upgrade, ha\-continue, ha\-heartbeat, ha\-maintenance\-cancel, ha\-maintenance\-notify, ha\-maintenance\-start, ha\-reset, ha\-scopes, ha\-sync, ha\-sync\-complete\-notify, interface\-add, interface\-list, interface\-redetect, kea\-lfc\-start, lease6\-add, lease6\-bulk\-apply, lease6\-del, lease6\-get, lease6\-get\-all, lease6\-get\-by\-duid, lease6\-get\-by\-hostname, lease6\-get\-by\-hw\-address, lease6\-get\-by\-state, lease6\-get\-page, lease6\-resend\-ddns, lease6\-update, lease6\-wipe, lease6\-write, leases\-reclaim, list\-commands, network6\-add, network6\-del, network6\-get, network6\-list, network6\-subnet\-add, network6\-subnet\-del, perfmon\-control, perfmon\-get\-all\-durations, remote\-class6\-del, remote\-class6\-get, remote\-class6\-get\-all, remote\-class6\-set, remote\-global\-parameter6\-del, remote\-global\-parameter6\-get, remote\-global\-parameter6\-get\-all, remote\-global\-parameter6\-set, remote\-network6\-del, remote\-network6\-get, remote\-network6\-list, remote\-network6\-set, remote\-option\-def6\-del, remote\-option\-def6\-get, remote\-option\-def6\-get\-all, remote\-option\-def6\-set, remote\-option6\-global\-del, remote\-option6\-global\-get, remote\-option6\-global\-get\-all, remote\-option6\-global\-set, remote\-option6\-network\-del, remote\-option6\-network\-set, remote\-option6\-pd\-pool\-del, remote\-option6\-pd\-pool\-set, remote\-option6\-pool\-del, remote\-option6\-pool\-set, remote\-option6\-subnet\-del, remote\-option6\-subnet\-set, remote\-server6\-del, remote\-server6\-get, remote\-server6\-get\-all, remote\-server6\-set, remote\-subnet6\-del\-by\-id, remote\-subnet6\-del\-by\-prefix, remote\-subnet6\-get\-by\-id, remote\-subnet6\-get\-by\-prefix, remote\-subnet6\-list, remote\-subnet6\-set, reservation\-add, reservation\-del, reservation\-get, reservation\-get\-all, reservation\-get\-by\-address, reservation\-get\-by\-hostname, reservation\-get\-by\-id, reservation\-get\-page, reservation\-update, server\-tag\-get, sflq\-pool4\-del, sflq\-pool4\-get\-all, sflq\-pool4\-get\-by\-range, sflq\-pool4\-get\-by\-subnet, sflq\-pool4\-rebuild, sflq\-pool6\-del, sflq\-pool6\-get\-all, sflq\-pool6\-get\-by\-range, sflq\-pool6\-get\-by\-subnet, sflq\-pool6\-rebuild, shutdown, stat\-lease6\-get, statistic\-get, statistic\-get\-all, statistic\-global\-get\-all, statistic\-remove, statistic\-remove\-all, statistic\-reset, statistic\-reset\-all, statistic\-sample\-age\-set, statistic\-sample\-age\-set\-all, statistic\-sample\-count\-set, statistic\-sample\-count\-set\-all, status\-get, subnet6\-add, subnet6\-del, subnet6\-delta\-add, subnet6\-delta\-del, subnet6\-get, subnet6\-list, subnet6\-select\-test, subnet6\-update, version\-get\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIcb_cmds\fP: remote\-class4\-del, remote\-class4\-get, remote\-class4\-get\-all, remote\-class4\-set, remote\-class6\-del, remote\-class6\-get, remote\-class6\-get\-all, remote\-class6\-set, remote\-global\-parameter4\-del, remote\-global\-parameter4\-get, remote\-global\-parameter4\-get\-all, remote\-global\-parameter4\-set, remote\-global\-parameter6\-del, remote\-global\-parameter6\-get, remote\-global\-parameter6\-get\-all, remote\-global\-parameter6\-set, remote\-network4\-del, remote\-network4\-get, remote\-network4\-list, remote\-network4\-set, remote\-network6\-del, remote\-network6\-get, remote\-network6\-list, remote\-network6\-set, remote\-option\-def4\-del, remote\-option\-def4\-get, remote\-option\-def4\-get\-all, remote\-option\-def4\-set, remote\-option\-def6\-del, remote\-option\-def6\-get, remote\-option\-def6\-get\-all, remote\-option\-def6\-set, remote\-option4\-global\-del, remote\-option4\-global\-get, remote\-option4\-global\-get\-all, remote\-option4\-global\-set, remote\-option4\-network\-del, remote\-option4\-network\-set, remote\-option4\-pool\-del, remote\-option4\-pool\-set, remote\-option4\-subnet\-del, remote\-option4\-subnet\-set, remote\-option6\-global\-del, remote\-option6\-global\-get, remote\-option6\-global\-get\-all, remote\-option6\-global\-set, remote\-option6\-network\-del, remote\-option6\-network\-set, remote\-option6\-pd\-pool\-del, remote\-option6\-pd\-pool\-set, remote\-option6\-pool\-del, remote\-option6\-pool\-set, remote\-option6\-subnet\-del, remote\-option6\-subnet\-set, remote\-server4\-del, remote\-server4\-get, remote\-server4\-get\-all, remote\-server4\-set, remote\-server6\-del, remote\-server6\-get, remote\-server6\-get\-all, remote\-server6\-set, remote\-subnet4\-del\-by\-id, remote\-subnet4\-del\-by\-prefix, remote\-subnet4\-get\-by\-id, remote\-subnet4\-get\-by\-prefix, remote\-subnet4\-list, remote\-subnet4\-set, remote\-subnet6\-del\-by\-id, remote\-subnet6\-del\-by\-prefix, remote\-subnet6\-get\-by\-id, remote\-subnet6\-get\-by\-prefix, remote\-subnet6\-list, remote\-subnet6\-set\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIclass_cmds\fP: class\-add, class\-del, class\-get, class\-list, class\-update\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIgss_tsig\fP: gss\-tsig\-get, gss\-tsig\-get\-all, gss\-tsig\-key\-del, gss\-tsig\-key\-expire, gss\-tsig\-key\-get, gss\-tsig\-list, gss\-tsig\-purge, gss\-tsig\-purge\-all, gss\-tsig\-rekey, gss\-tsig\-rekey\-all\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIhigh_availability\fP: ha\-continue, ha\-heartbeat, ha\-maintenance\-cancel, ha\-maintenance\-notify, ha\-maintenance\-start, ha\-reset, ha\-scopes, ha\-sync, ha\-sync\-complete\-notify\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIhost_cache\fP: cache\-clear, cache\-flush, cache\-get, cache\-get\-by\-id, cache\-insert, cache\-load, cache\-remove, cache\-size, cache\-write\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIhost_cmds\fP: reservation\-add, reservation\-del, reservation\-get, reservation\-get\-all, reservation\-get\-by\-address, reservation\-get\-by\-hostname, reservation\-get\-by\-id, reservation\-get\-page, reservation\-update\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIlease_cmds\fP: lease4\-add, lease4\-del, lease4\-get, lease4\-get\-all, lease4\-get\-by\-client\-id, lease4\-get\-by\-hostname, lease4\-get\-by\-hw\-address, lease4\-get\-by\-state, lease4\-get\-page, lease4\-resend\-ddns, lease4\-update, lease4\-wipe, lease4\-write, lease6\-add, lease6\-bulk\-apply, lease6\-del, lease6\-get, lease6\-get\-all, lease6\-get\-by\-duid, lease6\-get\-by\-hostname, lease6\-get\-by\-hw\-address, lease6\-get\-by\-state, lease6\-get\-page, lease6\-resend\-ddns, lease6\-update, lease6\-wipe, lease6\-write, sflq\-pool4\-del, sflq\-pool4\-get\-all, sflq\-pool4\-get\-by\-range, sflq\-pool4\-get\-by\-subnet, sflq\-pool4\-rebuild, sflq\-pool6\-del, sflq\-pool6\-get\-all, sflq\-pool6\-get\-by\-range, sflq\-pool6\-get\-by\-subnet, sflq\-pool6\-rebuild\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIlease_query\fP: extended\-info4\-upgrade, extended\-info6\-upgrade\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIperfmon\fP: perfmon\-control, perfmon\-get\-all\-durations\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIstat_cmds\fP: stat\-lease4\-get, stat\-lease6\-get\&. .sp دستورهای پشتیبانی‌شده توسط کتابخانه قلاب \fIsubnet_cmds\fP: network4\-add, network4\-del, network4\-get, network4\-list, network4\-subnet\-add, network4\-subnet\-del, network6\-add, network6\-del, network6\-get, network6\-list, network6\-subnet\-add, network6\-subnet\-del, subnet4\-add, subnet4\-del, subnet4\-delta\-add, subnet4\-delta\-del, subnet4\-get, subnet4\-list, subnet4\-update, subnet6\-add, subnet6\-del, subnet6\-delta\-add, subnet6\-delta\-del, subnet6\-get, subnet6\-list, subnet6\-update\&. .SS build\-report .sp این دستور فهرستی از گزینه‌های کامپایلی را که این فایل باینری خاص با آن‌ها ساخته شده است برمی‌گرداند. .sp پشتیبانی‌شده توسط: kea\-dhcp\-ddns, kea\-dhcp4, kea\-dhcp6 .sp در دسترس بودن: 1.2.0 (توکار) .sp سطح دسترسی: read \fI(پارامتر در این نسخه Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور build\-report را ببینید \%<#\:command-build-report> .sp ساختار دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqbuild\-report\(dq } .EE .UNINDENT .UNINDENT .sp ساختار پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: } .EE .UNINDENT .UNINDENT.SS cache\-clear .sp این دستور تمام رزروهای میزبان ذخیره‌شده در کَش را حذف می‌کند. .sp پشتیبانی‌شده توسط: kea\-dhcp4, kea\-dhcp6 .sp دسترس‌پذیری: 1.4.0 (کتابخانهٔ قلاب host_cache) .sp دسترسی: write \fI(این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور cache\-clear را ببینید \%<#\:command-cache-clear> .sp ساختار دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-clear\(dq } .EE .UNINDENT .UNINDENT .sp ساختار پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: , \(dqtext\(dq: \(dq\(dq } .EE .UNINDENT .UNINDENT .sp نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارت‌اند از: .INDENT 0.0 .IP \(bu 2 0 \- موفقیت (success) .IP \(bu 2 1 \- خطا (error) .IP \(bu 2 2 \- پشتیبانی‌نشده (unsupported) .IP \(bu 2 3 \- خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد) .IP \(bu 2 4 \- تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود) .UNINDENT .SS cache\-flush .sp این دستور تا تعداد مشخص‌شده یا تمامی رزروهای میزبان ذخیره‌شده در کَش را حذف می‌کند. .sp پشتیبانی‌شده توسط: kea\-dhcp4, kea\-dhcp6 .sp دسترس‌پذیری: 1.4.0 (کتابخانهٔ قلاب host_cache) .sp دسترسی: write \fI(این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور cache\-flush را ببینید \%<#\:command-cache-flush> .sp ساختار دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-flush\(dq, \(dqarguments\(dq: 5 } .EE .UNINDENT .UNINDENT .sp ساختار پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: , \(dqtext\(dq: \(dq\(dq } .EE .UNINDENT .UNINDENT .sp نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارت‌اند از: .INDENT 0.0 .IP \(bu 2 0 \- موفقیت (success) .IP \(bu 2 1 \- خطا (error) .IP \(bu 2 2 \- پشتیبانی‌نشده (unsupported) .IP \(bu 2 3 \- خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد) .IP \(bu 2 4 \- تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود) .UNINDENT .SS cache\-get .sp این دستور محتوای کامل کَش میزبان را بازمی‌گرداند. .sp پشتیبانی‌شده توسط: kea\-dhcp4, kea\-dhcp6 .sp دسترس‌پذیری: 1.4.0 (کتابخانهٔ قلاب host_cache) .sp دسترسی: read \fI(این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور cache\-get را ببینید \%<#\:command-cache-get> .sp ساختار دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-get\(dq } .EE .UNINDENT .UNINDENT .sp ساختار پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq123 entries returned.\(dq, \(dqarguments\(dq: } .EE .UNINDENT .UNINDENT .sp نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارت‌اند از: .INDENT 0.0 .IP \(bu 2 0 \- موفقیت (success) .IP \(bu 2 1 \- خطا (error) .IP \(bu 2 2 \- پشتیبانی‌نشده (unsupported) .IP \(bu 2 3 \- خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد) .IP \(bu 2 4 \- تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود) .UNINDENT.SS cache\-get\-by\-id .sp این دستور مدخل‌های منطبق با شناسهٔ ارائه‌شده را از حافظهٔ پنهان میزبان (host cache) بازمی‌گرداند. .sp پشتیبانی‌شده توسط: kea\-dhcp4، kea\-dhcp6 .sp دسترس‌پذیری: 1.6.0 (کتابخانهٔ قلاب host_cache) .sp دسترسی: read \fI(این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور cache\-get\-by\-id را ببینید \%<#\:command-cache-get-by-id> .sp ساختار دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-get\-by\-id\(dq, \(dqarguments\(dq: { \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq } } .EE .UNINDENT .UNINDENT .sp ساختار پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq2 entries returned.\(dq, \(dqarguments\(dq: } .EE .UNINDENT .UNINDENT .sp نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارت‌اند از: .INDENT 0.0 .IP \(bu 2 0 \- موفقیت (success) .IP \(bu 2 1 \- خطا (error) .IP \(bu 2 2 \- پشتیبانی‌نشده (unsupported) .IP \(bu 2 3 \- خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد) .IP \(bu 2 4 \- تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بود) .UNINDENT .SS cache\-insert .sp این دستور یک میزبان را در حافظهٔ پنهان درج می‌کند. .sp پشتیبانی‌شده توسط: kea\-dhcp4، kea\-dhcp6 .sp دسترس‌پذیری: 1.4.0 (کتابخانهٔ قلاب host_cache) .sp دسترسی: write \fI(این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور cache\-insert را ببینید \%<#\:command-cache-insert> .sp ساختار دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-insert\(dq, \(dqarguments\(dq: { \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqsubnet\-id4\(dq: 4, \(dqsubnet\-id6\(dq: 0, \(dqip\-address\(dq: \(dq192.0.2.100\(dq, \(dqhostname\(dq: \(dqsomehost.example.org\(dq, \(dqclient\-classes4\(dq: [ ], \(dqclient\-classes6\(dq: [ ], \(dqoption\-data4\(dq: [ ], \(dqoption\-data6\(dq: [ ], \(dqnext\-server\(dq: \(dq192.0.0.2\(dq, \(dqserver\-hostname\(dq: \(dqserver\-hostname.example.org\(dq, \(dqboot\-file\-name\(dq: \(dqbootfile.efi\(dq, \(dqhost\-id\(dq: 0 } } مثال دیگری که رزرو میزبان IPv6 را به حافظهٔ پنهان اضافه می‌کند عبارت است از: { \(dqcommand\(dq: \(dqcache\-insert\(dq, \(dqarguments\(dq: { \(dqhw\-address\(dq: \(dq01:02:03:04:05:06\(dq, \(dqsubnet\-id4\(dq: 0, \(dqsubnet\-id6\(dq: 6, \(dqip\-addresses\(dq: [ \(dq2001:db8::cafe:babe\(dq ], \(dqprefixes\(dq: [ \(dq2001:db8:dead:beef::/64\(dq ], \(dqhostname\(dq: \(dq\(dq, \(dqclient\-classes4\(dq: [ ], \(dqclient\-classes6\(dq: [ ], \(dqoption\-data4\(dq: [ ], \(dqoption\-data6\(dq: [ ], \(dqnext\-server\(dq: \(dq0.0.0.0\(dq, \(dqserver\-hostname\(dq: \(dq\(dq, \(dqboot\-file\-name\(dq: \(dq\(dq, \(dqhost\-id\(dq: 0 } } .EE .UNINDENT .UNINDENT .sp ساختار پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: , \(dqtext\(dq: \(dq\(dq } .EE .UNINDENT .UNINDENT .sp نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارت‌اند از: .INDENT 0.0 .IP \(bu 2 0 \- موفقیت (success) .IP \(bu 2 1 \- خطا (error) .IP \(bu 2 2 \- پشتیبانی‌نشده (unsupported) .IP \(bu 2 3 \- خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد) .IP \(bu 2 4 \- تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بود) .UNINDENT.SS cache\-load .sp این دستور امکان بارگذاری محتوای یک فایل روی دیسک را در یک حافظهٔ نهان درون‌حافظه‌ای فراهم می‌کند. .sp پشتیبانی‌شده توسط: kea\-dhcp4، kea\-dhcp6 .sp در دسترس از: 1.4.0 (کتابخانهٔ قلاب host_cache) .sp دسترسی: write \fI(این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور cache\-load را ببینید \%<#\:command-cache-load> .sp نحو دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-load\(dq, \(dqarguments\(dq: \(dq/usr/local/share/kea/kea\-host\-cache.json\(dq } .EE .UNINDENT .UNINDENT .sp نحو پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: , \(dqtext\(dq: \(dq\(dq } .EE .UNINDENT .UNINDENT .sp مقدار Result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از: .INDENT 0.0 .IP \(bu 2 0 \- موفقیت (success) .IP \(bu 2 1 \- خطا (error) .IP \(bu 2 2 \- پشتیبانی‌نشده (unsupported) .IP \(bu 2 3 \- خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد) .IP \(bu 2 4 \- تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند) .UNINDENT .SS cache\-remove .sp این دستور مدخل‌ها را از حافظهٔ نهان میزبان حذف می‌کند. این دستور پارامترهایی مشابه با دستور \fBreservation\-get\fP می‌پذیرد. .sp پشتیبانی‌شده توسط: kea\-dhcp4، kea\-dhcp6 .sp در دسترس از: 1.4.0 (کتابخانهٔ قلاب host_cache) .sp دسترسی: write \fI(این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور cache\-remove را ببینید \%<#\:command-cache-remove> .sp نحو دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-remove\(dq, \(dqarguments\(dq: { \(dqip\-address\(dq: \(dq192.0.2.1\(dq, \(dqsubnet\-id\(dq: 123 } } مثال دیگری که شناسهٔ میزبان IPv6 را بر اساس DUID و subnet\-id مشخص حذف می‌کند عبارت است از: { \(dqcommand\(dq: \(dqcache\-remove\(dq, \(dqarguments\(dq: { \(dqduid\(dq: \(dq00:01:ab:cd:f0:a1:c2:d3:e4\(dq, \(dqsubnet\-id\(dq: 123 } } .EE .UNINDENT .UNINDENT .sp نحو پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: , \(dqtext\(dq: \(dq\(dq } .EE .UNINDENT .UNINDENT .sp مقدار Result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از: .INDENT 0.0 .IP \(bu 2 0 \- موفقیت (success) .IP \(bu 2 1 \- خطا (error) .IP \(bu 2 2 \- پشتیبانی‌نشده (unsupported) .IP \(bu 2 3 \- خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد) .IP \(bu 2 4 \- تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند) .UNINDENT .SS cache\-size .sp این دستور تعداد مدخل‌های موجود در حافظهٔ نهان میزبان را برمی‌گرداند. .sp پشتیبانی‌شده توسط: kea\-dhcp4، kea\-dhcp6 .sp در دسترس از: 1.6.0 (کتابخانهٔ قلاب host_cache) .sp دسترسی: read \fI(این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور cache\-size را ببینید \%<#\:command-cache-size> .sp نحو دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-size\(dq } .EE .UNINDENT .UNINDENT .sp نحو پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dq123 entries.\(dq, \(dqarguments\(dq: { \(dqsize\(dq: 123 } } .EE .UNINDENT .UNINDENT .sp مقدار Result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از: .INDENT 0.0 .IP \(bu 2 0 \- موفقیت (success) .IP \(bu 2 1 \- خطا (error) .IP \(bu 2 2 \- پشتیبانی‌نشده (unsupported) .IP \(bu 2 3 \- خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد) .IP \(bu 2 4 \- تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند) .UNINDENT.SS cache\-write .sp این دستور به Kea فرمان می‌دهد تا محتوای حافظهٔ موقت میزبان (host cache) خود را روی دیسک بنویسد. .sp پشتیبانی‌شده توسط: kea\-dhcp4، kea\-dhcp6 .sp دسترس‌پذیری: 1.4.0 (کتابخانهٔ هوک host_cache) .sp دسترسی: write \fI(این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور cache\-write را ببینید \%<#\:command-cache-write> .sp نحو دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqcache\-write\(dq, \(dqarguments\(dq: \(dq/path/to/the/file.json\(dq } .EE .UNINDENT .UNINDENT .sp این دستور یک آرگومان اجباری می‌پذیرد که مسیر نام فایلی را که باید نوشته شود مشخص می‌کند. .sp نحو پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: , \(dqtext\(dq: \(dq\(dq } .EE .UNINDENT .UNINDENT .sp نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از: .INDENT 0.0 .IP \(bu 2 0 \- موفقیت (success) .IP \(bu 2 1 \- خطا (error) .IP \(bu 2 2 \- پشتیبانی‌نشده (unsupported) .IP \(bu 2 3 \- خالی (empty - دستور با موفقیت به پایان رسید، اما داده‌ای تغییر نیافت یا بازگردانده نشد) .IP \(bu 2 4 \- تعارض (conflict - دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تداخل بود) .UNINDENT .SS class\-add .sp این دستور یک کلاس جدید به پیکربندی موجود سرور اضافه می‌کند. .sp پشتیبانی‌شده توسط: kea\-dhcp4، kea\-dhcp6 .sp دسترس‌پذیری: 1.5.0 (کتابخانهٔ هوک class_cmds) .sp دسترسی: write \fI(این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)\fP .sp توضیحات و مثال‌ها: دستور class\-add را ببینید \%<#\:command-class-add> .sp نحو دستور: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqcommand\(dq: \(dqclass\-add\(dq, \(dqarguments\(dq: { \(dqclient\-classes\(dq: [ { \(dqname\(dq: , \(dqtest\(dq: , \(dqoption\-data\(dq: [

} ], \(dqremote\(dq: { } } } .EE .UNINDENT .UNINDENT .sp این دستور شامل دو فهرست با دقیقاً مشخصات استخر نشانی و دقیقاً یک مشخصات گزینه است. مشخص کردن یک فهرست خالی، یک مقدار \fBnull\fP یا یک server tag منجر به خطا خواهد شد. .sp نحو پاسخ: .INDENT 0.0 .INDENT 3.5 .sp .EX { \(dqresult\(dq: 0, \(dqtext\(dq: \(dqDHCPv4 option successfully set.\(dq, \(dqarguments\(dq: { \(dqoptions\(dq: [ { \(dqcode\(dq: