'\" t
.\"     Title: fwknop
.\"    Author: [بخش "نویسندگان" را ببینید]
.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
.\"      Date: 08/06/2018
.\"    Manual: Fwknop Client
.\"    Source: Fwknop Client
.\"  Language: Persian
.\"
.TH "FWKNOP" "8" "08/06/2018" "Fwknop Client" "Fwknop Client"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "نام (NAME)"
fwknop \- عملگر کوبش دیوار آتش (Firewall Knock Operator)
.SH "خلاصه دستور (SYNOPSIS)"
.sp
\fBfwknop\fR \fB\-A\fR <\*(Aqproto/ports\*(Aq> \fB\-R\fR|\fB\-a\fR|\fB\-s \-D\fR <\*(Aqhost\*(Aq> [\fIگزینه‌ها\fR]
.SH "توضیحات (DESCRIPTION)"
.sp
\fBfwknop\fR یک طرح احراز هویت با نام «احراز هویت تک‌بسته‌ای» (Single Packet Authorization یا SPA) را برای پنهان‌سازی قدرتمند سرویس‌ها پیاده‌سازی می‌کند\&. روش SPA تنها به یک بسته رمزگذاری‌شده، غیرقابل بازپخش (non-replayable) و احراز هویت‌شده از طریق HMAC نیاز دارد تا درخواست دسترسی به سرویسی را که پشت یک دیوار آتش با سیاست پیش‌فرض مسدودسازی (default-drop) پنهان شده است، منتقل کند\&. کاربرد اصلی SPA استفاده از دیوار آتش برای مسدود کردن تمام تلاش‌ها جهت اتصال به سرویس‌هایی نظیر \fISSH\fR است تا بهره‌برداری از آسیب‌پذیری‌ها (چه آسیب‌پذیری‌های روز صفر و چه کدهای وصله‌نشده) دشوارتر شود\&. هر سرویسی که با SPA پنهان شده باشد، طبیعتاً توسط \fINmap\fR قابل پویش و شناسایی نیست\&. پروژه fwknop به‌طور پیش‌فرض از چهار دیوار آتش مختلف پشتیبانی می‌کند: \fIiptables\fR، \fIfirewalld\fR، \fIPF\fR و \fIipfw\fR در لینوکس، OpenBSD، FreeBSD و Mac OS X\&. همچنین امکان استفاده از اسکریپت‌های سفارشی وجود دارد تا بتوان fwknop را برای پشتیبانی از سایر زیرساخت‌ها مانند \fIipset\fR یا \fInftables\fR گسترش داد\&.
.sp
روش SPA اساساً نسل بعدی پورت ناکینگ (Port Knocking یا PK) است، اما بسیاری از محدودیت‌های موجود در PK را برطرف کرده و در عین حال مزایای کلیدی آن را حفظ می‌کند\&. محدودیت‌های PK عبارتند از: دشواری عمومی در محافظت برابر حملات بازپخش (replay attacks)، عدم امکان پشتیبانی مطمئن از الگوریتم‌های رمزنگاری نامتقارن و طرح‌های HMAC، و امکان بسیار ساده برای اجرای حمله محروم‌سازی از سرویس (DoS) علیه سرور PK تنها با تزریق یک بسته اضافی جعلی به توالی PK هنگام عبور از شبکه (که باعث می‌شود سرور PK تصور کند کلاینت توالی صحیح را نمی‌داند)\&. تمام این محدودیت‌ها در SPA حل شده‌اند\&. در عین حال، SPA سرویس‌ها را پشت یک سیاست دیوار آتش default-drop پنهان می‌کند، داده‌های SPA را به‌صورت غیرفعال (passive) دریافت می‌نماید (معمولاً از طریق libpcap یا روش‌های دیگر)، و عملیات استاندارد رمزنگاری را برای احراز هویت بسته‌های SPA و رمزگذاری/رمزگشایی پیاده‌سازی می‌کند\&.
.sp
این صفحه راهنما مربوط به کلاینت \fBfwknop\fR است که وظیفه ساخت بسته‌های SPA و ارسال آن‌ها در شبکه را بر عهده دارد\&. سمت سرور توسط دیمن \fBfwknopd\fR پیاده‌سازی می‌شود که شبکه را برای بسته‌های SPA شنود (sniff) کرده و با دیوار آتش محلی تعامل می‌کند تا اتصالات احراز هویت‌شده با SPA را مجاز سازد\&. توصیه می‌شود صفحه راهنمای \fIfwknopd(8)\fR را نیز مطالعه کنید\&. اطلاعات تفصیلی بیشتر را می‌توانید در راهنمای جامع آنلاین «Single Packet Authorization: A Comprehensive Guide to Strong Service Concealment with fwknop» بیابید (ببینید: \fIhttp://www\&.cipherdyne\&.org/fwknop/docs/fwknop\-tutorial\&.html\fR)\&.
.sp
بسته‌های SPA ایجادشده توسط \fBfwknop\fR از HMAC برای رمزنگاری احراز هویت‌شده در مدل «اول رمزگذاری سپس احراز هویت» (encrypt-then-authenticate) بهره می‌برند\&. هرچند استفاده از HMAC در حال حاضر اختیاری است (از طریق سوئیچ خط فرمان \fB\-\-use\-hmac\fR فعال می‌شود)، اما به سه دلیل شدیداً توصیه می‌شود: \fI۱)\fR بدون HMAC، احراز هویت قوی رمزنگاری‌شده در \fBfwknop\fR امکان‌پذیر نیست مگر اینکه از GnuPG استفاده شود، که حتی در آن حالت نیز همچنان باید از HMAC استفاده گردد؛ \fI۲)\fR یک HMAC که پس از رمزگذاری اعمال می‌شود، در برابر حملات تحلیل رمزنگاری اوراکل لایه‌گذاری حالت CBC (مانند حمله Vaudenay و ترفندهای مرتبط نظیر حمله "Lucky 13" علیه SSL) محافظت می‌کند؛ و \fI۳)\fR کد مورد نیاز دیمن \fBfwknopd\fR برای تأیید HMAC بسیار ساده‌تر از کد مورد نیاز برای رمزگشایی بسته SPA است، بنابراین بسته SPA بدون HMAC معتبر اصلاً وارد توابع رمزگشایی نمی‌شود\&. دلیل \fI۳)\fR دقیقاً علت این است که چرا حتی هنگام استفاده از رمزگذاری GnuPG نیز باید از HMAC استفاده شود؛ زیرا داده‌های SPA تا زمانی که HMAC بررسی و تأیید نشود، به توابع \fBlibgpgme\fR فرستاده نمی‌شوند\&. کدهای GnuPG و libgpgme نسبتاً پیچیده هستند و محدود کردن توانایی مهاجم احتمالی برای تعامل با این کدها از طریق عملیات HMAC به حفظ وضعیت امنیتی قوی‌تر کمک می‌کند\&. ایجاد HMAC برای ارتباطات SPA علاوه بر کلید رمزگذاری عادی به یک کلید اختصاصی نیاز دارد و هر دو کلید را می‌توان با گزینه \fB\-\-key\-gen\fR تولید کرد\&.
.sp
ابزار \fBfwknop\fR بسته‌های SPA را یا با رمز قالبی \fIRijndael\fR یا از طریق \fIGnuPG\fR و رمزهای نامتقارن مربوطه رمزگذاری می‌کند\&. اگر روش رمزگذاری متقارن انتخاب شود، طبق معمول کلید رمزگذاری بین کلاینت و سرور به اشتراک گذاشته می‌شود (برای جزئیات به فایل \fI/etc/fwknop/access\&.conf\fR در \fBfwknopd\fR مراجعه کنید)\&. کلید رمزگذاری واقعی که برای رمزگذاری Rijndael استفاده می‌شود، از طریق الگوریتم استاندارد مشتق‌سازی کلید PBKDF1 تولید شده و در حالت CBC تنظیم می‌گردد\&. اگر روش GnuPG انتخاب شود، کلیدهای رمزگذاری از دسته‌کلیدهای GnuPG مشتق می‌شوند\&. بسته‌های SPA تولیدشده توسط کلاینت fwknop از قالب زیر (پیش از رمزگذاری و اعمال HMAC) پیروی می‌کنند:
.sp
.if n \{\
.RS 4
.\}
.nf
    random data (16 digits) [داده‌های تصادفی ۱۶ رقمی]
    username [نام کاربری]
    timestamp [برچسب زمان]
    software version [نسخه نرم‌افزار]
    mode [حالت: حالت دستور (۰) یا حالت دسترسی (۱)]
    if command mode => command to execute [در حالت دستور => دستور برای اجرا]
    else access mode  => IP,proto,port [در غیر این صورت حالت دسترسی => IP,proto,port]
    message digest (SHA512 / SHA384 / SHA256 / SHA1 / MD5 / SHA3_256 / SHA3_512) [خلاصه پیام]
.fi
.if n \{\
.RE
.\}
.sp
هر یک از فیلدهای فوق به دلیل متغیر بودن طول چند فیلد، با نویسه ":" از یکدیگر جدا می‌شوند و فیلدهایی که ممکن است شامل نویسه ":" باشند به‌صورت base64 کدگذاری می‌گردند\&. خلاصه پیام (به‌طور پیش‌فرض \fBSHA256\fR) بخشی از داده‌های در حال رمزگذاری است و مستقل از HMAC است که پس از رمزگذاری به داده‌های بسته SPA ضمیمه می‌شود\&. داده‌های تصادفی ۱۶ رقمی (حدود ۵۳ بیت) تضمین می‌کند که هیچ دو بسته SPA یکسان نباشند، و این مستقل از استفاده از PBKDF1 برای مشتق‌سازی کلید Rijndael در حالت CBC (که از مقدار نمک تصادفی ۸ بایتی استفاده می‌کند) است\&. از آنجا که \fBfwknopd\fR خلاصه SHA256 تمام بسته‌های معتبر ورودی SPA را ردیابی کرده و موارد تکراری را دور می‌اندازد، حملات بازپخش علیه \fBfwknop\fR امکان‌پذیر نیستند\&. در صورت تشخیص بازپخش، هشدارهای Syslog تولید می‌شوند\&.
.sp
به‌طور پیش‌فرض، کلاینت \fBfwknop\fR بسته‌های مجازسازی را روی پورت UDP شماره 62201 ارسال می‌کند، اما این مقدار با آرگومان \fB\-\-server\-port\fR قابل تغییر است (این امر مستلزم آن است که \fBfwknopd\fR برای دریافت داده‌های SPA روی پورت انتخابی پیکربندی شده باشد)\&. همچنین \fBfwknop\fR می‌تواند بسته SPA را از طریق آرگومان \fB\-\-rand\-port\fR روی یک پورت تصادفی ارسال کند\&. برای جزئیات بیشتر به \fIfwknopd(8)\fR مراجعه کنید\&. برای نمونه‌های فراخوانی کلاینت \fBfwknop\fR به بخش \fBمثال‌ها (EXAMPLES)\fR مراجعه نمایید\&.
.sp
کلاینت \fBfwknop\fR بسیار سازگار و قابل‌حمل (portable) است و روی توزیع‌های مختلف لینوکس (تمامی توزیع‌های اصلی و توزیع‌های تعبیه‌شده نظیر OpenWRT)، FreeBSD، OpenBSD، Mac OS X و Cygwin در ویندوز اجرا می‌شود\&. همچنین یک کتابخانه به نام \fBlibfko\fR وجود دارد که هر دو ابزار \fBfwknop\fR و \fBfwknopd\fR برای عملیات رمزگذاری/رمزگشایی بسته SPA و احراز هویت HMAC از آن استفاده می‌کنند\&. این کتابخانه می‌تواند برای استفاده برنامه‌های شخص ثالث از SPA تحت مجوز عمومی گنو (GPL v2+) به کار گرفته شود\&.
.SH "آرگومان‌های الزامی (REQUIRED ARGUMENTS)"
.sp
این آرگومان‌های الزامی را می‌توان از طریق خط فرمان یا از داخل فایل \fI~/\&.fwknoprc\fR مشخص کرد (گزینه \fI\-n, \-\-named\-config\fR و بخش «فایل FWKNOPRC» در زیر را ببینید)\&.
.PP
\fB\-A, \-\-access\fR=\fI<port list>\fR
.RS 4
ارائه فهرستی از پورت‌ها و پروتکل‌ها برای دسترسی به یک رایانه راه دور که \fBfwknopd\fR را اجرا می‌کند\&. قالب این فهرست به‌صورت \(lq+<proto>/<port>\&...<proto>/<port>+\(rq است، مانند \(lqtcp/22,udp/53\(rq\&.
\fBنکته:\fR
اکثریت قریب به اتفاق موارد استفاده از
\fBfwknop\fR
نیازمند آرگومان
\fB\-A\fR
هستند، اما ارسال دستورهای کامل با آرگومان
\fB\-\-server\-cmd\fR
از طریق بسته SPA برای اجرا توسط
\fBfwknopd\fR
به این آرگومان نیاز ندارد\&.
.RE
.PP
\fB\-D, \-\-destination\fR=\fI<hostname/IP\-address>\fR
.RS 4
هدایت کلاینت
\fBfwknop\fR
برای احراز هویت با سرویس/دیمن
\fBfwknopd\fR
در نام میزبان یا نشانی IP مقصد مشخص‌شده\&. حالت اتصال توسط سرویس/دیمن
\fBfwknopd\fR
هنگام رمزگشایی و تجزیه بسته احراز هویت شناسایی می‌شود\&.
.RE
.PP
\fB\-R|\-a|\-s\fR
.RS 4
یکی از این گزینه‌ها (توضیحات در ادامه) الزامی است تا به دیمن راه دور
\fBfwknopd\fR
اطلاع دهد چه نشانی IP باید از طریق دیوار آتش مجاز شود\&. توصیه می‌شود از گزینه‌های
\fB\-R\fR
یا
\fB\-a\fR
به جای
\fB\-s\fR
استفاده کنید تا ارتباطات SPA در برابر حملات احتمالی
\fIمرد میانی\fR
(MITM) ایمن‌سازی شوند، و در سمت سرور متغیر
\fIREQUIRE_SOURCE_ADDRESS\fR
در فایل
\fI/etc/fwknop/access\&.conf\fR
تنظیم گردد\&. توجه داشته باشید که امن‌ترین گزینه
\fB\-a\fR
است تا
\fBfwknop\fR
مجبور به ارسال درخواست HTTPS به
\fIhttps://www\&.cipherdyne\&.org/cgi\-bin/myip\fR
برای تفکیک نشانی IP دارای قابلیت مسیریابی خارجی نباشد\&. استفاده از
\fB\-a\fR
مستلزم آن است که کاربر از قبل نشانی IP خارجی شبکه‌ای را که fwknop روی آن اجرا می‌شود بداند\&.
.RE
.SH "گزینه‌های عمومی (GENERAL OPTIONS)"
.PP
\fB\-h, \-\-help\fR
.RS 4
چاپ پیام راهنمای خلاصه استفاده و خروج\&.
.RE
.PP
\fB\-G, \-\-get\-key\fR=\fI<file>\fR
.RS 4
بارگیری کلید/گذرواژه رمزگذاری از فایل مشخص‌شده\&. فایل کلید برای هر نام میزبان یا نشانی IP مقصد شامل یک خط است که شامل دونقطه (":")، فاصله اختیاری و گذرواژه بوده و به یک خط جدید ختم می‌شود\&. توجه داشته باشید که خط آخر باید دارای نویسه خط جدید پایانی باشد\&. همچنین توجه داشته باشید: اگرچه این یک تسهیلات است، اما داشتن فایلی با گذرواژه‌های متن آشکار روی سیستم ایده خوبی نبوده و توصیه نمی‌شود\&. اینکه کلاینت
\fBfwknop\fR
کلید را از شما درخواست (prompt) کند، عموماً امن‌تر است\&. همچنین توجه داشته باشید که اگر کلیدی روی دیسک ذخیره شود، فایل rc ابزار
\fBfwknop\fR
سازوکار بسیار قدرتمندتری برای تعیین نه تنها کلید بلکه سایر گزینه‌ها نیز به شمار می‌رود\&.
.RE
.PP
\fB\-\-stdin\fR
.RS 4
خواندن کلید/گذرواژه رمزگذاری از ورودی استاندارد (stdin)\&. این گزینه می‌تواند مثلاً برای ارسال داده‌ها از طریق لوله (pipe) استفاده شود\&. این دستور شبیه به \-\-fd 0 است\&.
.RE
.PP
\fB\-\-fd\fR=\fI<number>\fR
.RS 4
تعیین شماره توصیف‌گر فایل برای خواندن کلید/گذرواژه از آن\&. این دستور مانع از درخواست گذرواژه از کاربر می‌شود، در صورتی که گذرواژه‌ای در بخش (stanza) اختصاصی کاربر یافت نشده باشد یا در خط فرمان ارائه نشده باشد\&. تنظیم توصیف‌گر فایل روی ۰ شبیه به دستور stdin است\&.
.RE
.PP
\fB\-\-get\-hmac\-key\fR=\fI<file>\fR
.RS 4
بارگیری کلید/گذرواژه HMAC از فایل مشخص‌شده\&. مشابه قالب گزینه
\fB\-\-get\-key\fR،
فایل کلید HMAC شامل یک خط برای هر نام میزبان یا نشانی IP مقصد، یک دونقطه (":")، فاصله اختیاری و گذرواژه است که به یک خط جدید ختم می‌شود\&. توجه داشته باشید که خط آخر باید دارای نویسه خط جدید پایانی باشد\&. همچنین توجه کنید: داشتن فایلی با گذرواژه‌های متن آشکار روی سیستم توصیه نمی‌شود\&. درخواست کلید HMAC توسط کلاینت
\fBfwknop\fR
عموماً امن‌تر است\&. همچنین اگر کلیدی روی دیسک ذخیره می‌شود، فایل rc ابزار
\fBfwknop\fR
سازوکار قدرتمندتری است\&.
.RE
.PP
\fB\-\-key\-gen\fR
.RS 4
وادار کردن
\fBfwknop\fR
به تولید هر دو کلید Rijndael و HMAC که می‌توانند برای رمزگذاری و احراز هویت بسته SPA استفاده شوند\&. این کلیدها از /dev/urandom مشتق شده و پیش از چاپ در خروجی استاندارد به‌صورت base64 کدگذاری می‌شوند و برای درج در فایل \(lq$HOME/\&.fwknoprc\(rq (یا فایل ارجاع داده‌شده با
\fB\-\-get\-key\fR)
در نظر گرفته شده‌اند\&. چنین کلیدهایی عموماً بسیار امن‌تر از عبارات عبوری هستند که از طریق خط فرمان تایپ می‌شوند\&.
.RE
.PP
\fB\-\-key\-gen\-file\fR=\fI<file>\fR
.RS 4
نوشتن کلیدهای تولیدشده در فایل مشخص‌شده\&. توجه داشته باشید که اگر فایل از قبل وجود داشته باشد، بازنویسی می‌شود\&. اگر این گزینه داده نشود،
\fB\-\-key\-gen\fR
کلیدها را در خروجی استاندارد می‌نویسد\&.
.RE
.PP
\fB\-\-key\-len\fR=\fI<length>\fR
.RS 4
تعیین تعداد بایت‌ها برای کلید تولیدشده Rijndael\&. حداکثر اندازه در حال حاضر ۱۲۸ بایت است\&.
.RE
.PP
\fB\-\-hmac\-key\-len\fR=\fI<length>\fR
.RS 4
تعیین تعداد بایت‌ها برای کلید تولیدشده HMAC\&. حداکثر اندازه در حال حاضر ۱۲۸ بایت است\&.
.RE
.PP
\fB\-l, \-\-last\-cmd\fR
.RS 4
اجرای
\fBfwknop\fR
با آرگومان‌های خط فرمان فراخوانی قبلی (در صورت وجود)\&. آرگومان‌های قبلی از فایل
\fI~/\&.fwknop\&.run\fR
استخراج می‌شوند\&.
.RE
.PP
\fB\-n, \-\-named\-config\fR=\fI<stanza name>\fR
.RS 4
تعیین نام بخش پیکربندی در فایل \(lq$HOME/\&.fwknoprc\(rq برای دریافت دستورالعمل‌های پیکربندی و اجرا\&. این بخش‌های نام‌گذاری‌شده نیاز به به‌خاطرسپاری آرگومان‌های مختلف خط فرمان را برای فراخوانی‌های پرکاربرد
\fBfwknop\fR
برطرف می‌کنند\&. برای فهرستی از دستورالعمل‌های معتبر پیکربندی در فایل
\fI\&.fwknoprc\fR،
بخش با عنوان «فایل FWKNOPRC» را در ادامه ببینید\&.
.RE
.PP
\fB\-\-key\-rijndael\fR=\fI<key>\fR
.RS 4
تعیین کلید Rijndael در خط فرمان\&. از آنجا که ممکن است کلید برای ابزارهایی مانند
\fIps\fR
در یونیکس قابل مشاهده باشد، این حالت فقط باید در مواردی استفاده شود که امنیت حیاتی نیست\&. درخواست کلید توسط کلاینت
\fBfwknop\fR
یا دریافت آن از طریق فایل \(lq$HOME/\&.fwknoprc\(rq عموماً امن‌تر است\&.
.RE
.PP
\fB\-\-key\-base64\-rijndael\fR=\fI<key>\fR
.RS 4
تعیین کلید کدگذاری‌شده با base64 برای Rijndael\&. از آنجا که ممکن است کلید برای ابزارهایی مانند
\fIps\fR
در یونیکس قابل مشاهده باشد، این فرم فقط باید در مواردی که امنیت بحرانی نیست استفاده شود\&. دریافت کلید از فایل \(lq$HOME/\&.fwknoprc\(rq یا درخواست کلاینت امن‌تر است\&.
.RE
.PP
\fB\-\-key\-base64\-hmac\fR=\fI<key>\fR
.RS 4
تعیین کلید کدگذاری‌شده با base64 برای HMAC\&. از آنجا که ممکن است کلید برای ابزارهایی نظیر
\fIps\fR
قابل مشاهده باشد، این فرم فقط باید در موارد غیرحساس استفاده شود\&.
.RE
.PP
\fB\-\-key\-hmac\fR=\fI<key>\fR
.RS 4
تعیین کلید خام HMAC (کدگذاری‌نشده با base64)\&. از آنجا که کلید ممکن است برای ابزارهایی نظیر
\fIps\fR
قابل مشاهده باشد، این فرم تنها در شرایط غیرحساس کاربرد دارد\&.
.RE
.PP
\fB\-\-rc\-file\fR=\fI<file>\fR
.RS 4
تعیین مسیر فایل rc ابزار
\fBfwknop\fR
(پیش‌فرض \(lq$HOME/\&.fwknoprc\(rq است)\&.
.RE
.PP
\fB\-\-no\-rc\-file\fR
.RS 4
انجام عملیات کلاینت
\fBfwknop\fR
بدون ارجاع به فایل \(lq$HOME/\&.fwknoprc\(rq\&.
.RE
.PP
\fB\-\-no\-home\-dir\fR
.RS 4
جلوگیری از جستجوی کلاینت
\fBfwknop\fR
برای پوشه خانگی کاربر\&.
.RE
.PP
\fB\-\-save\-rc\-stanza\fR=\fI<stanza name>\fR
.RS 4
ذخیره آرگومان‌های خط فرمان در بخش مشخص‌شده فایل \(lq$HOME/\&.fwknoprc\(rq با گزینه
\fB\-n\fR\&.
اگر گزینه
\fB\-n\fR
حذف شود، نام بخش به‌طور پیش‌فرض برابر با مقدار سرور مقصد (نام میزبان یا IP) داده‌شده در آرگومان
\fB\-D\fR
خواهد بود\&.
.RE
.PP
\fB\-\-force\-stanza\fR
.RS 4
همراه با
\fB\-\-save\-rc\-stanza\fR
برای بازنویسی تمام متغیرهای بخش مشخص‌شده استفاده می‌شود\&.
.RE
.PP
\fB\-\-stanza\-list\fR
.RS 4
تخلیه فهرستی از بخش‌های موجود در \(lq$HOME/\&.fwknoprc\(rq\&.
.RE
.PP
\fB\-\-show\-last\fR
.RS 4
نمایش آخرین آرگومان‌های خط فرمان استفاده‌شده توسط
\fBfwknop\fR\&.
.RE
.PP
\fB\-E, \-\-save\-args\-file\fR=\fI<file>\fR
.RS 4
ذخیره آرگومان‌های خط فرمان در مسیر فایل مشخص‌شده\&. بدون این گزینه، و زمانی که
\fB\-\-no\-save\-args\fR
نیز مشخص نشده باشد، مسیر پیش‌فرض ذخیره آرگومان‌ها
\fI~/\&.fwknop\&.run\fR
است\&.
.RE
.PP
\fB\-\-no\-save\-args\fR
.RS 4
آرگومان‌های خط فرمان ارائه‌شده هنگام اجرای
\fBfwknop\fR
را ذخیره نکند\&.
.RE
.PP
\fB\-T, \-\-test\fR
.RS 4
حالت آزمایشی\&. تولید داده‌های بسته SPA، اما بدون ارسال آن\&. در عوض، تفکیک فیلدهای داده SPA را چاپ کرده، سپس داده‌ها را از فرایند رمزگشایی و کدگشایی عبور داده و دوباره تفکیک آن‌ها را چاپ می‌کند\&. این در درجه اول یک ویژگی اشکال‌زدایی است\&.
.RE
.PP
\fB\-B, \-\-save\-packet\fR=\fI<file>\fR
.RS 4
دستور به کلاینت
\fBfwknop\fR
برای نوشتن بسته جدیداً ایجادشده SPA در فایل مشخص‌شده تا بتوان آن را به‌صورت آفلاین بررسی کرد\&.
.RE
.PP
\fB\-b, \-\-save\-packet\-append\fR
.RS 4
پیوست کردن داده‌های بسته تولیدشده به فایل مشخص‌شده با گزینه
\fB\-B\fR\&.
.RE
.PP
\fB\-\-fault\-injection\-tag\fR=\fI<tag>\fR
.RS 4
این گزینه تنها برای آزمون تزریق خطا در زمانی استفاده می‌شود که
\fBfwknop\fR
برای پشتیبانی از کتابخانه libfiu کامپایل شده باشد (ببینید:
\fIhttp://blitiri\&.com\&.ar/p/libfiu/\fR)\&. در شرایط عادی این گزینه استفاده نمی‌شود و هیچ نسخه بسته‌بندی‌شده‌ای از fwknop این کد را به‌صورت کامپایل‌شده ندارد، بنابراین این قابلیت در زمان اجرا فعال نیست\&. برای کامل بودن مستندات در اینجا ذکر شده است\&.
.RE
.PP
\fB\-v, \-\-verbose\fR
.RS 4
اجرای کلاینت
\fBfwknop\fR
در حالت پرگویی (verbose)\&. این امر باعث می‌شود
\fBfwknop\fR
اطلاعات اضافی درباره دستور فعلی و داده‌های حاصل از SPA چاپ کند\&.
.RE
.PP
\fB\-V, \-\-version\fR
.RS 4
نمایش اطلاعات نسخه و خروج\&.
.RE
.SH "گزینه‌های SPA (SPA OPTIONS)"
.PP
\fB\-\-use\-hmac\fR
.RS 4
تنظیم حالت HMAC برای رمزنگاری احراز هویت‌شده در ارتباطات SPA\&. از نسخه
\fBfwknop\fR
2\&.5، این یک ویژگی اختیاری است، اما در نسخه‌های بعدی به حالت پیش‌فرض تبدیل خواهد شد\&.
.RE
.PP
\fB\-a, \-\-allow\-ip\fR=\fI<IP\-address>\fR
.RS 4
تعیین نشانی IP که باید از طریق دیوار آتش سرور مقصد
\fBfwknopd\fR
مجاز شود (این IP درون خود بسته SPA رمزگذاری می‌شود)\&. این گزینه برای جلوگیری از حمله مرد میانی (MITM) مفید است که در آن بسته SPA می‌تواند در مسیر رهگیری شده و از یک IP متفاوت با نسخه اصلی ارسال شود\&. بنابراین اگر سرور
\fBfwknopd\fR
به نشانی مبدأ در هدر IP بسته SPA اعتماد کند، مهاجم دسترسی پیدا خواهد کرد\&. گزینه
\fB\-a\fR
نشانی مبدأ را درون بسته رمزگذاری‌شده SPA قرار می‌دهد و بنابراین این حمله را خنثی می‌سازد\&. گزینه
\fB\-a\fR
همچنین برای تعیین IP که هنگام جعل بسته SPA با گزینه
\fB\-\-spoof\-src\fR
دسترسی به آن داده می‌شود، کاربرد دارد\&. گزینه مرتبط دیگر
\fB\-R\fR
است (در ادامه را ببینید) که به کلاینت
\fBfwknop\fR
دستور می‌دهد نشانی IP دارای قابلیت مسیریابی خارجی متصل به سیستم محلی را با پرس‌وجو از
\fIhttps://www\&.cipherdyne\&.org/cgi\-bin/myip\fR
به‌طور خودکار تفکیک کند\&. این کار نشانی IP واقعی دیده‌شده از سیستم فراخواننده را برمی‌گرداند\&.
.RE
.PP
\fB\-g, \-\-gpg\-encryption\fR
.RS 4
استفاده از رمزگذاری GPG روی بسته SPA (پیش‌فرض در صورت عدم تعیین، Rijndael است)\&.
\fBنکته:\fR
استفاده از این گزینه همچنین نیازمند گیرنده GPG است (گزینه
\fB\-\-gpg\-recipient\fR
را به همراه سایر گزینه‌های مرتبط با GPG در زیر ببینید)\&.
.RE
.PP
\fB\-\-hmac\-digest\-type\fR=\fI<digest>\fR
.RS 4
تنظیم الگوریتم خلاصه HMAC برای رمزنگاری احراز هویت‌شده بسته‌های SPA\&. انتخاب‌ها عبارتند از:
\fBMD5\fR،
\fBSHA1\fR،
\fBSHA256\fR
(پیش‌فرض)،
\fBSHA384\fR،
\fBSHA512\fR،
\fBSHA3_256\fR و
\fBSHA3_512\fR\&.
.RE
.PP
\fB\-N, \-\-nat\-access\fR=\fI<internalIP:forwardPort>\fR
.RS 4
سرور
\fBfwknopd\fR
امکان ارائه دسترسی SPA از طریق دیوار آتش iptables به یک سرویس داخلی را از طریق تعامل با قابلیت‌های NAT در iptables فراهم می‌کند\&. بنابراین اگر سرور
\fBfwknopd\fR
از یک شبکه داخلی روی فضای آدرس RFC-1918 محافظت می‌کند، یک کلاینت خارجی
\fBfwknop\fR
می‌تواند درخواست کند که سرور یک پورت خارجی را به یک IP داخلی فوروارد کند، به عنوان مثال \(lq+\-\-NAT\-access 192\&.168\&.10\&.2,55000+\(rq\&. در این حالت، دسترسی به 192\&.168\&.10\&.2 از طریق پورت 55000 به هر سرویسی که از طریق آرگومان
\fB\-\-access\fR
درخواست شده است (معمولاً tcp/22) اعطا می‌شود\&. بنابراین پس از ارسال چنین بسته SPA، کاربر دستور \(lqssh \-p 55000 user@host\(rq را اجرا می‌کند و اتصال به‌طور خودکار به سیستم داخلی 192\&.168\&.10\&.2 هدایت می‌شود\&. توجه داشته باشید که پورت \(lq55000\(rq می‌تواند به‌صورت تصادفی از طریق آرگومان
\fB\-\-nat\-rand\-port\fR
(که بعداً توضیح داده شده) تولید شود\&.
.RE
.PP
\fB\-\-nat\-local\fR
.RS 4
روی سرور
\fBfwknopd\fR،
عملیات NAT می‌تواند به‌جای فوروارد شدن به سیستم‌های دیگر، روی سیستم محلی اعمال شود\&. یعنی برای دیوارهای آتش iptables، اتصال به مثلاً پورت 55000 می‌تواند به پورت 22 روی سیستم محلی ترجمه شود\&. با استفاده از آرگومان
\fB\-\-nat\-local\fR،
می‌توان کلاینت
\fBfwknop\fR
را وادار به درخواست چنین دسترسی کرد\&. این بدان معناست که هر مهاجم خارجی پس از ارسال بسته SPA، تنها اتصالی روی پورت 55000 را مشاهده می‌کند به جای پورت مورد انتظار 22\&.
.RE
.PP
\fB\-\-nat\-port\fR
.RS 4
معمولاً
\fBfwknop\fR
برای درخواست دسترسی به یک پورت خاص مانند tcp/22 روی سیستمی که
\fBfwknopd\fR
را اجرا می‌کند استفاده می‌شود\&. با این حال با استفاده از آرگومان
\fB\-\-nat\-port\fR،
امکان درخواست دسترسی به یک سرویس (مجدداً مانند tcp/22) وجود دارد، اما این دسترسی از طریق پورت مشخص‌شده اعطا می‌شود (بنابراین آرگومان
\fB\-p\fR
سپس در خط فرمان کلاینت
\fISSH\fR
استفاده خواهد شد)\&. آرگومان‌های خط فرمان
\fB\-\-nat\-local\fR
و
\fB\-\-nat\-access\fR
در
\fBfwknop\fR
را برای جزئیات بیشتر در مورد دسترسی به سرویس‌ها از طریق عملیات NAT ببینید\&.
.RE
.PP
\fB\-\-nat\-rand\-port\fR
.RS 4
معمولاً
\fBfwknop\fR
برای درخواست دسترسی به یک پورت خاص مانند tcp/22 روی سیستمی که
\fBfwknopd\fR
را اجرا می‌کند استفاده می‌شود\&. با این حال با استفاده از آرگومان
\fB\-\-nat\-rand\-port\fR،
می‌توان دسترسی به یک سرویس خاص (مجدداً مانند tcp/22) را درخواست کرد اما این دسترسی از طریق یک پورت تصادفی ترجمه‌شده اعطا شود\&. یعنی هنگامی که کلاینت
\fBfwknop\fR
در این حالت اجرا شد و پورت تصادفی انتخاب‌شده توسط
\fBfwknop\fR
نمایش داده شد، پورت مقصد استفاده‌شده توسط کلاینت بعدی باید طوری تغییر کند که با این پورت تصادفی مطابقت داشته باشد\&. برای
\fISSH\fR،
این کار از طریق آرگومان
\fB\-p\fR
انجام می‌شود\&. آرگومان‌های خط فرمان
\fB\-\-nat\-local\fR
و
\fB\-\-nat\-access\fR
را برای جزئیات بیشتر ببینید\&.
.RE
.PP
\fB\-p, \-\-server\-port\fR=\fI<port>\fR
.RS 4
تعیین شماره پورتی که
\fBfwknopd\fR
بسته‌ها را از طریق libpcap یا ulogd pcap writer روی آن می‌پذیرد\&. به‌طور پیش‌فرض
\fBfwknopd\fR
بسته‌های مجازسازی را روی پورت UDP شماره 62201 جستجو می‌کند\&.
.RE
.PP
\fB\-P, \-\-server\-proto\fR=\fI<protocol>\fR
.RS 4
تنظیم پروتکل (udp، tcp، http، udpraw، tcpraw یا icmp) برای بسته خروجی SPA\&. نکته: حالت‌های
\fBudpraw\fR،
\fBtcpraw\fR
و
\fBicmp\fR
از سوکت‌های خام (raw sockets) استفاده می‌کنند و بنابراین برای اجرا نیازمند دسترسی ریشه (root) هستند\&. همچنین توجه کنید: حالت
\fBtcp\fR
انتظار دارد قبل از ارسال بسته SPA یک اتصال TCP با سرور برقرار کند\&. این کار معمولاً انجام نمی‌شود، اما برای سازگاری با Tor جهت ناشناسی قوی مفید است؛ ببینید:
\fIhttp://tor\&.eff\&.org/\fR\&.
در این حالت، سرور
\fBfwknopd\fR
باید پیکربندی شود تا روی پورت TCP هدف (که به‌طور پیش‌فرض 62201 است) گوش فرا دهد\&.
.RE
.PP
\fB\-Q, \-\-spoof\-src\fR=\fI<IP>\fR
.RS 4
جعل نشانی مبدأ که کلاینت
\fBfwknop\fR
بسته‌های SPA را از آن ارسال می‌کند\&. این کار در سمت کلاینت نیازمند دسترسی root است زیرا به یک سوکت خام نیاز دارد\&. توجه داشته باشید که آرگومان
\fB\-\-spoof\-user\fR
را می‌توان در این حالت مشخص کرد تا هرگونه کلیدواژه
\fBREQUIRE_USERNAME\fR
را که ممکن است در
\fI/etc/fwknop/access\&.conf\fR
تعیین شده باشد برآورده سازد\&.
.RE
.PP
\fB\-r, \-\-rand\-port\fR
.RS 4
دستور به کلاینت
\fBfwknop\fR
برای ارسال یک بسته SPA روی یک پورت مقصد تصادفی بین 10000 تا 65535\&. سرور
\fBfwknopd\fR
باید از متغیر
\fBPCAP_FILTER\fR
استفاده کند که برای پذیرش چنین بسته‌هایی پیکربندی شده باشد\&. برای مثال، متغیر
\fBPCAP_FILTER\fR
می‌تواند روی این مقدار تنظیم شود: \(lq+udp dst portrange 10000\-65535+\(rq\&.
.RE
.PP
\fB\-R, \-\-resolve\-ip\-https\fR
.RS 4
این یک گزینه مهم است و به کلاینت
\fBfwknop\fR
دستور می‌دهد یک درخواست HTTPS به اسکریپتی که روی
\fIcipherdyne\&.org\fR
اجرا می‌شود ارسال کند که نشانی IP کلاینت را (همان‌طور که وب‌سرور می‌بیند) برمی‌گرداند\&. در برخی موارد، این کار برای تعیین نشانی IP که باید از طریق سیاست دیوار آتش در سمت سرور راه دور
\fBfwknopd\fR
مجاز شود لازم است\&. این گزینه زمانی مفید است که کلاینت
\fBfwknop\fR
روی سیستمی پشت یک نشانی نامشخص NAT استفاده می‌شود و IP خارجی رو به اینترنت برای کاربر شناخته‌شده نیست\&. نشانی کامل تفکیک برابر است با:
\fIhttps://www\&.cipherdyne\&.org/cgi\-bin/myip\fR،
و توسط
\fBfwknop\fR
از طریق
\fIwget\fR
در حالت
\fB\-\-secure\-protocol\fR
دسترسی پیدا می‌کند\&. توجه داشته باشید که اگر نشانی IP با قابلیت مسیریابی خارجی کلاینت از قبل برای کاربر مشخص باشد، استفاده از گزینه
\fB\-a\fR
عموماً امن‌تر است زیرا نیاز
\fBfwknop\fR
به ارسال هرگونه درخواست HTTPS را از بین می‌برد\&.
.RE
.PP
\fB\-\-resolve\-url\fR \fI<url>\fR
.RS 4
جایگزینی URL پیش‌فرض مورد استفاده برای تفکیک نشانی IP مبدأ\&. برای بهترین نتایج، URL مشخص‌شده در اینجا باید به یک سرویس وب اشاره کند که فقط یک نشانی IP را در بدنه پاسخ HTTP ارائه می‌دهد\&.
.RE
.PP
\fB\-\-resolve\-http\-only\fR
.RS 4
این گزینه کلاینت
\fBfwknop\fR
را وادار می‌کند نشانی IP خارجی را از طریق HTTP به جای HTTPS تفکیک کند\&. شرایطی وجود دارد که ممکن است این کار ضروری باشد، مانند زمانی که
\fIwget\fR
در دسترس نیست (یا با پشتیبانی SSL کامپایل نشده است)، اما به‌طور کلی این کار توصیه نمی‌شود زیرا امکان حمله MITM را از طریق دستکاری پاسخ HTTP تفکیک IP فراهم می‌سازد\&. یا IP را به‌صورت دستی با
\fB\-a\fR
مشخص کنید، یا از
\fB\-R\fR
استفاده کرده و این گزینه را نادیده بگیرید\&.
.RE
.PP
\fB\-w, \-\-wget\-cmd\fR=\fI<wget full path>\fR
.RS 4
تنظیم دستی مسیر کامل دستور
\fIwget\fR\&.
به‌طور معمول اسکریپت
\fIconfigure\fR
دستور
\fIwget\fR
را پیدا می‌کند، اما این گزینه می‌تواند برای تعیین مسیر در صورتی که در مکانی غیر استاندارد قرار داشته باشد استفاده شود\&.
.RE
.PP
\fB\-s, \-\-source\-ip\fR
.RS 4
دستور به کلاینت
\fBfwknop\fR
برای تشکیل یک بسته SPA که شامل نشانی IP حالت خاص \(lq+0\&.0\&.0\&.0+\(rq است که به سرور SPA مقصد
\fBfwknopd\fR
اطلاع می‌دهد از نشانی IP مبدأ که بسته SPA از آن سرچشمه می‌گیرد به عنوان IP مجاز پس از تغییر مجموعه قوانین دیوار آتش استفاده کند\&. این گزینه در صورتی مفید است که کلاینت
\fBfwknop\fR
روی ماشینی پشت یک دستگاه NAT مستقر باشد و IP خارجی مشخص نباشد\&. با این حال، استفاده از این گزینه توصیه نمی‌شود و در عوض باید از گزینه‌های
\fB\-a\fR
یا
\fB\-R\fR
استفاده کرد\&. گزینه‌های نشانی مجاز
\fB\-s\fR،
\fB\-R\fR
و
\fB\-a\fR
مانعةالجمع (mutually exclusive) هستند\&.
.RE
.PP
\fB\-S, \-\-source\-port\fR=\fI<port>\fR
.RS 4
تنظیم پورت مبدأ برای بسته خروجی SPA\&.
.RE
.PP
\fB\-\-server\-resolve\-ipv4\fR
.RS 4
این گزینه کلاینت
\fBfwknop\fR
را وادار می‌کند هنگامی که از نام میزبان برای سرور SPA استفاده می‌شود، تنها یک نشانی IPv4 را از DNS بپذیرد\&. این امر در برخی موارد که DNS ممکن است هر دو نشانی IPv6 و IPv4 را برگرداند ضروری است\&.
.RE
.PP
\fB\-f, \-\-fw\-timeout\fR=\fI<seconds>\fR
.RS 4
تعیین مدت زمانی (به ثانیه) که قانون دیوار آتش راه دور که دسترسی به یک سرویس را اعطا می‌کند باید فعال بماند\&. مقدار پیش‌فرض نگهداری‌شده توسط
\fBfwknopd\fR
برابر ۳۰ ثانیه است، اما هر اتصال برقرارشده می‌تواند پس از حذف قانون اولیه پذیرش، از طریق سازوکار ردیابی اتصال (connection tracking) که ممکن است توسط دیوار آتش ارائه شود، باز بماند\&.
.RE
.PP
\fB\-C, \-\-server\-cmd\fR=\fI<command to execute>\fR
.RS 4
به جای درخواست دسترسی به یک سرویس با بسته SPA، آرگومان
\fB\-\-server\-cmd\fR
دستوری را مشخص می‌کند که توسط سرور
\fBfwknopd\fR
اجرا خواهد شد\&. این دستور درون بسته SPA رمزگذاری شده و طبق معمول توسط سرور
\fBfwknopd\fR
از روی شبکه شنود می‌شود\&.
.RE
.PP
\fB\-H, \-\-http\-proxy\fR=\fI<proxy\-host>[:port]\fR
.RS 4
تعیین یک پراکسی HTTP که کلاینت
\fBfwknop\fR
بسته SPA را از طریق آن ارسال خواهد کرد\&. استفاده از این گزینه به‌طور خودکار حالت انتقال بسته SPA (که معمولاً از طریق آرگومان
\fB\-\-server\-proto\fR
تنظیم می‌شود) را روی "http" قرار می‌دهد\&. همچنین می‌توانید با افزودن ":<port>" به نام یا IP میزبان پراکسی، پورت پراکسی را تعیین کنید\&.
.RE
.PP
\fB\-m, \-\-digest\-type\fR=\fI<digest>\fR
.RS 4
تعیین الگوریتم خلاصه پیام برای استفاده در داده‌های SPA\&. انتخاب‌ها عبارتند از:
\fBMD5\fR،
\fBSHA1\fR،
\fBSHA256\fR
(پیش‌فرض)،
\fBSHA384\fR،
\fBSHA512\fR،
\fBSHA3_256\fR و
\fBSHA3_512\fR\&.
.RE
.PP
\fB\-M, \-\-encryption\-mode\fR=\fI<mode>\fR
.RS 4
تعیین حالت رمزگذاری هنگامی که AES برای رمزگذاری بسته‌های SPA استفاده می‌شود\&. پیش‌فرض حالت CBC است، اما حالت‌های دیگری نظیر CFB یا OFB نیز قابل انتخاب هستند به شرطی که در سمت سرور نیز در فایل
\fI/etc/fwknop/access\&.conf\fR
از طریق متغیر ENCRYPTION_MODE تعیین شده باشند\&. به‌طور کلی، توصیه می‌شود این آرگومان را درج نکرده و بگذارید حالت پیش‌فرض (CBC) اعمال شود\&. توجه داشته باشید که می‌توان رشته \(lqlegacy\(rq را تعیین کرد تا بسته‌های SPA با راهبرد بردار مقداردهی اولیه قدیمی که در نسخه‌های
\fBfwknop\fR
پیش از 2\&.5 استفاده می‌شد تولید شوند\&. با انتشار نسخه 2\&.5،
\fBfwknop\fR
بردارهای مقداردهی اولیه را به شیوه‌ای سازگار با OpenSSL از طریق الگوریتم PBKDF1 تولید می‌کند\&.
.RE
.PP
\fB\-\-time\-offset\-plus\fR=\fI<time>\fR
.RS 4
به‌طور پیش‌فرض، دیمن
\fBfwknopd\fR
در سمت سرور همگام‌سازی زمان بین ساعت‌های سیستم‌های کلاینت و سرور را الزامی می‌کند\&. کلاینت
\fBfwknop\fR
زمان محلی را درون هر بسته SPA به عنوان برچسب زمان قرار می‌دهد تا پس از رمزگشایی توسط سرور fwknopd اعتبارسنجی شود\&. با این حال در برخی شرایط، اگر ساعت‌ها ناهمگام باشند و کاربر سیستم کلاینت دسترسی لازم برای تغییر تنظیمات ساعت محلی را نداشته باشد، ساخت بسته SPA با برچسب زمانی که سرور بپذیرد ممکن است دشوار باشد\&. در این وضعیت، گزینه
\fB\-\-time\-offset\-plus\fR
به کاربر اجازه می‌دهد یک انحراف زمانی (مانند \(lq60sec\(rq، \(lq60min\(rq، \(lq2days\(rq و غیره) را مشخص کند که به زمان محلی اضافه می‌شود\&.
.RE
.PP
\fB\-\-time\-offset\-minus\fR=\fI<time>\fR
.RS 4
این گزینه شبیه به گزینه
\fB\-\-time\-offset\-plus\fR
(در بالا) است، اما انحراف زمانی مشخص‌شده را به جای افزودن، از برچسب زمان محلی کم می‌کند\&.
.RE
.PP
\fB\-u, \-\-user\-agent\fR=\fI<user\-agent\-string>\fR
.RS 4
تنظیم User-Agent در HTTP برای تفکیک IP خارجی از طریق
\fB\-R\fR،
یا برای ارسال بسته‌های SPA روی HTTP\&.
.RE
.PP
\fB\-\-use\-wget\-user\-agent\fR
.RS 4
به‌طور پیش‌فرض هنگامی که کلاینت
\fBfwknop\fR
نشانی IP خارجی را با
\fBwget\fR
از طریق SSL تفکیک می‌کند، User-Agent را روی \(lqFwknop/<version>\(rq تنظیم می‌کند مگر اینکه از قبل به‌صورت دستی با گزینه
\fB\-\-user\-agent\fR
تعیین شده باشد\&. با این حال، گزینه
\fB\-\-user\-wget\-user\-agent\fR
اجازه می‌دهد رشته پیش‌فرض User-Agent برنامه
\fBwget\fR
بدون دخالت
\fBfwknop\fR
اعمال شود\&.
.RE
.PP
\fB\-U, \-\-spoof\-user\fR=\fI<user>\fR
.RS 4
تعیین نام کاربری که درون بسته SPA گنجانده می‌شود\&. این به کلاینت
\fBfwknop\fR
امکان می‌دهد هر کلیدواژه غیر ریشه
\fBREQUIRE_USERNAME\fR
را روی سرور fwknopd برآورده سازد (حالت \fB\-\-spoof\-src\fR مستلزم آن است که کلاینت \fBfwknop\fR به عنوان root اجرا شود)\&.
.RE
.PP
\fB\-\-icmp\-type\fR=\fI<type>\fR
.RS 4
در حالت
\fB\-P icmp\fR،
مقدار نوع ICMP را که در هدر ICMP بسته SPA تنظیم می‌شود تعیین می‌کند\&. پیش‌فرض echo reply است\&.
.RE
.PP
\fB\-\-icmp\-code\fR=\fI<code>\fR
.RS 4
در حالت
\fB\-P icmp\fR،
مقدار کد ICMP را که در هدر ICMP بسته SPA تنظیم می‌شود تعیین می‌کند\&. پیش‌فرض صفر است\&.
.RE
.SH "گزینه‌های GPG (GPG OPTIONS)"
.sp
توجه داشته باشید که استفاده از GPG برای رمزگذاری/رمزگشایی SPA می‌تواند و باید شامل کلیدهای GPG باشد که توسط هر دو طرف (کلاینت و سرور) امضا شده‌اند\&. رویه اصلی برای این کار شامل مراحل زیر پس از انتقال کلید کلاینت به سرور و بالعکس است:
.sp
.if n \{\
.RS 4
.\}
.nf
    [spaserver]# gpg \-\-import client\&.asc
    [spaserver]# gpg \-\-edit\-key 1234ABCD
    Command> sign

    [spaclient]$ gpg \-\-import server\&.asc
    [spaclient]$ gpg \-\-edit\-key ABCD1234
    Command> sign
.fi
.if n \{\
.RE
.\}
.sp
اطلاعات جامع‌تر در این باره را می‌توانید در اینجا بیابید: \fIhttp://www\&.cipherdyne\&.org/fwknop/docs/gpghowto\&.html\fR\&.
.PP
\fB\-\-gpg\-agent\fR
.RS 4
دستور به
\fBfwknop\fR
برای دریافت گذرواژه کلید GnuPG از یک نمونه در حال اجرای gpg-agent (در صورت وجود)\&.
.RE
.PP
\fB\-\-gpg\-home\-dir\fR=\fI<dir>\fR
.RS 4
تعیین مسیر دایرکتوری GnuPG؛ معمولاً این مسیر از دایرکتوری خانگی کاربری که کلاینت
\fBfwknop\fR
را اجرا می‌کند مشتق می‌شود (بنابراین پیش‌فرض
\fI~/\&.gnupg\fR
است)\&. این گزینه زمانی مفید است که یک کاربر \(lqroot\(rq بخواهد به یک ماشین راه دور متصل شود که سرویس/دیمن sshd آن اجازه ورود به کاربر root را نمی‌دهد\&.
.RE
.PP
\fB\-\-gpg\-recipient\fR=\fI<key ID or Name>\fR
.RS 4
تعیین شناسه کلید GnuPG، به عنوان مثال \(lq+1234ABCD+\(rq (خروجی "gpg \(emlist\-keys" را ببینید) یا نام کلید (نشانی ایمیل مرتبط) گیرنده پیام احراز هویت تک‌بسته‌ای\&. این کلید توسط سرور
\fBfwknopd\fR
وارد شده و کلید خصوصی مرتبط با آن برای رمزگشایی بسته SPA استفاده می‌شود\&. کلید گیرنده ابتدا باید به دسته‌کلید GnuPG کلاینت وارد شده باشد\&.
.RE
.PP
\fB\-\-gpg\-signer\-key\fR=\fI<key ID or Name>\fR
.RS 4
تعیین شناسه کلید GnuPG، به عنوان مثال \(lq+ABCD1234+\(rq (خروجی "gpg \-\-list\-keys" را ببینید) یا نام کلید برای استفاده در امضای پیام SPA\&. از کاربر گذرواژه GnuPG مربوطه برای ایجاد امضا خواسته می‌شود\&. این کار یک سازوکار رمزنگاری قوی اضافه می‌کند تا دیمن
\fBfwknopd\fR
روی سرور راه دور بتواند هویت ایجادکننده پیام SPA را احراز کند\&.
.RE
.PP
\fB\-\-gpg\-no\-signing\-pw\fR
.RS 4
دستور به
\fBfwknop\fR
برای عدم دریافت عبارت عبور جهت استفاده از کلید امضای GnuPG\&. این گزینه برای آسان‌تر ساختن ایجاد بسته SPA در عملیات سمت کلاینت در محیط‌های خودکار که در آن‌ها عبارت عبور کلید امضا از دسته‌کلید GnuPG حذف شده است، ارائه گردیده است\&. با این حال، معمولاً بهتر است به جای این گزینه از
\fIgpg\-agent\fR
استفاده شود\&.
.RE
.SH "فایل FWKNOPRC (FWKNOPRC FILE)"
.sp
فایل \fI\&.fwknoprc\fR برای تنظیم پارامترهای مختلف جهت لغو پارامترهای پیش‌فرض برنامه در زمان اجرا استفاده می‌شود\&. این فایل همچنین امکان تعریف بخش‌های پیکربندی نام‌گذاری‌شده (\fIstanzas\fR) اضافی را برای تنظیم پارامترهای برنامه در یک فراخوانی خاص فراهم می‌آورد\&.
.sp
کلاینت \fBfwknop\fR در صورتی که این فایل در دایرکتوری خانگی کاربر وجود نداشته باشد، آن را ایجاد خواهد کرد\&. این نسخه اولیه دارای برخی دستورالعمل‌های نمونه است که کامنت شده‌اند\&. ویرایش این فایل برای رفع نیازهای کاربر بر عهده خود اوست\&.
.sp
فایل \fI\&.fwknoprc\fR شامل یک ناحیه یا بخش پیکربندی پیش‌فرض است که دستورالعمل‌های سراسری پیکربندی را نگهداری می‌کند و پیش‌فرض‌های برنامه را لغو می‌نماید\&. شما می‌توانید این فایل را ویرایش کرده و \fIبخش‌های نام‌گذاری‌شده\fR اضافی ایجاد کنید که با گزینه \fB\-n\fR یا \fB\-\-named\-config\fR قابل تعیین هستند\&. پارامترهای تعریف‌شده در بخش‌های نام‌گذاری‌شده، هرگونه دستورالعمل منطبق در بخش \fIdefault\fR را لغو خواهند کرد\&. توجه داشته باشید که گزینه‌های خط فرمان همچنان بر هرگونه دستورالعمل متناظر در \fI\&.fwknoprc\fR اولویت خواهند داشت\&.
.sp
دستورالعمل‌هایی برای انطباق با اکثر پارامترهای خط فرمان که \fBfwknop\fR پشتیبانی می‌کند وجود دارد\&. در اینجا فهرست فعلی هر دستورالعمل به همراه توضیح مختصر و گزینه‌های خط فرمان متناظر آن آمده است:
.PP
\fBSPA_SERVER\fR \fI<hostname/IP\-address>\fR
.RS 4
تعیین نام میزبان یا IP سرور مقصد (\fBfwknopd\fR) (\fI\-D, \-\-destination\fR)\&.
.RE
.PP
\fBALLOW_IP\fR \fI<IP\-address>\fR
.RS 4
تعیین نشانی مجاز در داده‌های SPA\&. نکته: این پارامتر گزینه‌های خط فرمان
\fB\-a\fR،
\fB\-s\fR
و
\fB\-R\fR
را پوشش می‌دهد\&. می‌توانید یک نام میزبان یا نشانی IP تعیین کنید (گزینه
\fB\-a\fR)،
کلمه "source" را برای دستور به سرور
\fBfwknopd\fR
جهت پذیرش IP مبدأ بسته به عنوان IP مجاز مشخص کنید (گزینه
\fB\-s\fR)،
یا از کلمه "resolve" استفاده کنید تا
\fBfwknop\fR
نشانی IP شبکه خارجی را از طریق درخواست HTTP تفکیک کند (گزینه
\fB\-R\fR)\&.
.RE
.PP
\fBACCESS\fR \fI<port list>\fR
.RS 4
تنظیم یک یا چند پروتکل/پورت برای باز شدن روی دیوار آتش (\fI\-A, \-\-access\fR)\&. قالب این فهرست به‌صورت \(lq+<proto>/<port>\&...<proto>/<port>+\(rq است، مانند \(lqtcp/22,udp/53\(rq\&.
.RE
.PP
\fBSPA_SERVER_PORT\fR \fI<port>\fR
.RS 4
تنظیم پورت سرور مورد استفاده برای ارسال بسته SPA (\fI\-p, \-\-server\-port\fR)\&.
.RE
.PP
\fBSPA_SERVER_PROTO\fR \fI<protocol\fR>
.RS 4
تنظیم پروتکل مورد استفاده برای ارسال بسته SPA (\fI\-P, \-\-server\-proto\fR)\&.
.RE
.PP
\fBKEY\fR \fI<passphrase>\fR
.RS 4
این عبارت عبوری است که برای رمزگذاری بسته SPA استفاده می‌شود و در هر دو حالت رمزگذاری Rijndael یا GPG اعمال می‌گردد\&. کلید رمزگذاری واقعی که برای Rijndael استفاده می‌شود از الگوریتم PBKDF1 مشتق شده و کلید GPG از دسته‌کلید GPG مشخص‌شده مشتق می‌شود\&.
.RE
.PP
\fBKEY_BASE64\fR \fI<base64 encoded passphrase>\fR
.RS 4
تعیین عبارت عبور رمزگذاری به‌صورت یک رشته کدگذاری‌شده با base64\&. این گزینه اجازه می‌دهد نویسه‌های غیر ascii در کلید رمزگشایی‌شده از base64 گنجانده شوند\&.
.RE
.PP
\fBUSE_HMAC\fR \fI<Y/N>\fR
.RS 4
تنظیم حالت HMAC برای رمزنگاری احراز هویت‌شده بسته‌های SPA\&. این امر باعث می‌شود
\fBfwknop\fR
از کاربر یک کلید اختصاصی HMAC را که مستقل از کلید رمزگذاری است درخواست کند\&. به‌طور جایگزین، کلید HMAC را می‌توان با دستورالعمل‌های
\fIHMAC_KEY\fR
یا
\fIHMAC_KEY_BASE64\fR
مشخص کرد (در ادامه را ببینید)\&.
.RE
.PP
\fBHMAC_KEY\fR \fI<key>\fR
.RS 4
تعیین کلید HMAC برای رمزنگاری احراز هویت‌شده بسته‌های SPA\&. این گزینه از هر دو حالت رمزگذاری Rijndael و GPG پشتیبانی می‌کند و بر اساس مدل encrypt-then-authenticate اعمال می‌شود\&.
.RE
.PP
\fBHMAC_KEY_BASE64\fR \fI<base64 encoded key>\fR
.RS 4
تعیین کلید HMAC به‌صورت یک رشته کدگذاری‌شده با base64\&. این گزینه اجازه می‌دهد نویسه‌های غیر ascii در کلید رمزگشایی‌شده از base64 گنجانده شوند\&.
.RE
.PP
\fBHMAC_DIGEST_TYPE\fR \fI<digest algorithm>\fR
.RS 4
تنظیم الگوریتم خلاصه HMAC مورد استفاده برای رمزنگاری احراز هویت‌شده بسته‌های SPA\&. انتخاب‌ها عبارتند از:
\fBMD5\fR،
\fBSHA1\fR،
\fBSHA256\fR
(پیش‌فرض)،
\fBSHA384\fR،
\fBSHA512\fR،
\fBSHA3_256\fR و
\fBSHA3_512\fR\&.
.RE
.PP
\fBSPA_SOURCE_PORT\fR \fI<port>\fR
.RS 4
تنظیم پورت مبدأ مورد استفاده برای ارسال بسته SPA (\fI\-S, \-\-source\-port\fR)\&.
.RE
.PP
\fBFW_TIMEOUT\fR \fI<seconds>\fR
.RS 4
تنظیم مقدار مهلت زمانی قانون دیوار آتش (\fI\-f, \-\-fw\-timeout\fR)\&.
.RE
.PP
\fBRESOLVE_IP_HTTPS\fR \fI<Y/N>\fR
.RS 4
تنظیم روی
\fIY\fR
برای تفکیک خودکار IP دارای قابلیت مسیریابی خارجی مرتبط با کلاینت
\fBfwknop\fR\&.
این کار روی SSL از طریق
\fIwget\fR
در حالت
\fI\-\-secure\-protocol\fR
در برابر سرویس تفکیک IP موجود در
\fIhttps://www\&.cipherdyne\&.org/cgi\-bin/myip\fR
انجام می‌شود\&.
.RE
.PP
\fBRESOLVE_HTTP_ONLY\fR \fI<Y/N>\fR
.RS 4
هنگامی که به کلاینت
\fBfwknop\fR
دستور داده می‌شود IP کلاینت خارجی را تفکیک کند، این گزینه در صورت تنظیم روی
\fIY\fR
می‌تواند برای اجبار به اتصال
\fIHTTP\fR
به جای اتصال
\fIHTTPS\fR
استفاده شود\&. این گزینه زمانی کاربرد دارد که
\fIwget\fR
روی سیستم‌عامل محلی نصب نشده باشد، یا با کتابخانه SSL کامپایل نشده باشد\&.
.RE
.PP
\fBRESOLVE_URL\fR \fI<url>\fR
.RS 4
تنظیم یک URL که برای تفکیک نشانی IP مبدأ استفاده خواهد شد (\fI\-\-resolve\-url\fR)\&.
.RE
.PP
\fBWGET_CMD\fR \fI<wget full path>\fR
.RS 4
تنظیم مسیر کامل دستور
\fIwget\fR
(مورد استفاده برای تفکیک IP کلاینت)\&.
.RE
.PP
\fBTIME_OFFSET\fR \fI<time>\fR
.RS 4
تنظیم مقداری برای اعمال روی برچسب زمان در بسته SPA\&. این می‌تواند یک مقدار مثبت یا منفی باشد (\fI\-\-time\-offset\-plus/minus\fR)\&.
.RE
.PP
\fBENCRYPTION_MODE\fR \fI<mode>\fR
.RS 4
تعیین حالت رمزگذاری هنگامی که AES استفاده می‌شود\&. این متغیر معادل آرگومان خط فرمان
\fI\-M, \-\-encryption\-mode\fR
است\&. به‌طور کلی، توصیه می‌شود این آرگومان درج نشود و اجازه دهید پیش‌فرض (CBC) اعمال گردد\&. توجه داشته باشید که رشته \(lqlegacy\(rq می‌تواند برای تولید بسته‌های SPA با راهبرد بردار مقداردهی اولیه قدیمی که در نسخه‌های
\fBfwknop\fR
پیش از 2\&.5 استفاده می‌شد تعیین گردد\&.
.RE
.PP
\fBDIGEST_TYPE\fR \fI<digest algorithm>\fR
.RS 4
تنظیم نوع خلاصه پیام SPA (\fI\-m, \-\-digest\-type\fR)\&. انتخاب‌ها عبارتند از:
\fBMD5\fR،
\fBSHA1\fR،
\fBSHA256\fR
(پیش‌فرض)،
\fBSHA384\fR،
\fBSHA512\fR،
\fBSHA3_256\fR و
\fBSHA3_512\fR\&.
.RE
.PP
\fBUSE_GPG\fR \fI<Y/N>\fR
.RS 4
تنظیم روی
\fIY\fR
برای تعیین استفاده از GPG جهت رمزگذاری (\fI\-\-gpg\-encryption\fR)\&.
.RE
.PP
\fBUSE_GPG_AGENT\fR \fI<Y/N>\fR
.RS 4
تنظیم روی
\fIY\fR
برای تعامل
\fBfwknop\fR
با یک نمونه gpg-agent جهت دریافت گذرواژه کلید GPG (\fI\-\-gpg\-agent\fR)\&. اطلاعات خود agent با متغیر محیطی
\fIGPG_AGENT_INFO\fR
مشخص می‌شود\&.
.RE
.PP
\fBGPG_SIGNING_PW\fR \fI<passphrase>\fR
.RS 4
این عبارت عبوری است که برای امضای داده‌های بسته SPA در حالت رمزگذاری GPG استفاده می‌شود و مترادفی برای متغیر
\fIKEY\fR
است (یعنی عبارت عبور امضا می‌تواند با متغیر
\fIKEY\fR
تعیین شود)\&. بسته SPA با کلید سرور راه دور رمزگذاری شده و با کلید کلاینت محلی امضا می‌شود\&.
.RE
.PP
\fBGPG_SIGNING_PW_BASE64\fR \fI<base64 encoded passphrase>\fR
.RS 4
تعیین عبارت عبور امضای GPG به‌صورت یک رشته کدگذاری‌شده با base64\&. این گزینه اجازه می‌دهد نویسه‌های غیر ascii در کلید رمزگشایی‌شده از base64 گنجانده شوند\&.
.RE
.PP
\fBGPG_SIGNER\fR \fI<key ID or Name>\fR
.RS 4
تعیین نام یا شناسه کلید GPG برای امضای داده‌های رمزگذاری‌شده با GPG در SPA (\fI\-\-gpg\-signer\-key\fR)\&.
.RE
.PP
\fBGPG_RECIPIENT\fR \fI<key ID or Name>\fR
.RS 4
تعیین نام یا شناسه کلید GPG برای گیرنده داده‌های رمزگذاری‌شده با GPG در SPA (\fI\-\-gpg\-recipient\-key\fR)\&.
.RE
.PP
\fBGPG_HOMEDIR\fR \fI<dir>\fR
.RS 4
تعیین دایرکتوری خانگی GPG (\fI\-\-gpg\-home\-dir\fR)\&. پیش‌فرض
\fI~/\&.gnupg\fR
است\&.
.RE
.PP
\fBGPG_EXE\fR \fI<path>\fR
.RS 4
تعیین مسیر اجرایی GPG (\fI\-\-gpg\-exe\fR)\&. پیش‌فرض
\fI/usr/bin/gpg\fR
است\&.
.RE
.PP
\fBSPOOF_USER\fR \fI<user>\fR
.RS 4
تنظیم نام کاربری در داده‌های SPA روی مقدار مشخص‌شده (\fI\-U, \-\-spoof\-user\fR)\&.
.RE
.PP
\fBSPOOF_SOURCE_IP\fR \fI<IP>\fR
.RS 4
تنظیم IP مبدأ بسته خروجی SPA روی مقدار مشخص‌شده (\fI\-Q, \-\-spoof\-source\fR)\&.
.RE
.PP
\fBRAND_PORT\fR \fI<Y/N>\fR
.RS 4
ارسال بسته SPA روی یک پورت تخصیص‌یافته تصادفی (\fI\-r, \-\-rand\-port\fR)\&.
.RE
.PP
\fBKEY_FILE\fR \fI<file>\fR
.RS 4
بارگیری کلید/گذرواژه رمزگذاری از یک فایل (\fI\-G, \-\-get\-key\fR)\&.
.RE
.PP
\fBHTTP_USER_AGENT\fR \fI<agent string>\fR
.RS 4
تنظیم User-Agent در HTTP برای تفکیک IP خارجی از طریق \-R، یا برای ارسال بسته‌های SPA روی HTTP (\fI\-u, \-\-user\-agent\fR)\&.
.RE
.PP
\fBUSE_WGET_USER_AGENT\fR \fI<Y/N>\fR
.RS 4
اجازه به استفاده از رشته پیش‌فرض User-Agent برنامه
\fBwget\fR
هنگام تفکیک IP خارجی به جای User-Agent ارائه‌شده توسط کلاینت
\fBfwknop\fR\&.
.RE
.PP
\fBNAT_ACCESS\fR \fI<internalIP:forwardPort>\fR
.RS 4
کسب دسترسی NAT به یک سرویس داخلی محافظت‌شده توسط سرور fwknop (\fI\-N, \-\-nat\-access\fR)\&.
.RE
.PP
\fBNAT_LOCAL\fR \fI<Y/N>\fR
.RS 4
دسترسی به یک سرویس محلی از طریق یک پورت فورواردشده روی سیستم سرور fwknopd (\fI\-\-nat\-local\fR)\&.
.RE
.PP
\fBNAT_PORT\fR \fI<port>\fR
.RS 4
تعیین پورت برای فوروارد جهت دسترسی به یک سرویس از طریق NAT (\fI\-\-nat\-port\fR)\&.
.RE
.PP
\fBNAT_RAND_PORT\fR \fI<Y/N>\fR
.RS 4
وادار کردن کلاینت fwknop به اختصاص یک پورت تصادفی برای دسترسی NAT (\fI\-\-nat\-rand\-port\fR)\&.
.RE
.SH "محیط (ENVIRONMENT)"
.sp
\fBSPOOF_USER\fR، \fBGPG_AGENT_INFO\fR (تنها در حالت \fB\-\-gpg\-agent\fR استفاده می‌شود)\&.
.SH "جعل بسته SPA (SPA PACKET SPOOFING)"
.sp
از آنجا که \fBfwknop\fR نشانی IP مجاز برای عبور از دیوار آتش را درون بار مفید رمزگذاری‌شده SPA قرار می‌دهد (مگر اینکه از \fB\-s\fR استفاده شود که توصیه نمی‌شود و می‌تواند در پیکربندی سرور \fBfwknopd\fR ممنوع گردد)، بسته‌های SPA به سادگی قابل جعل هستند و این در این چارچوب یک ویژگی مثبت است\&. به این معنا که نشانی IP مبدأ یک بسته SPA توسط دیمن \fBfwknopd\fR نادیده گرفته می‌شود (هنگامی که متغیر \fIREQUIRE_SOURCE_ADDRESS\fR در فایل \fI/etc/fwknop/access\&.conf\fR تنظیم شده باشد) و تنها به نشانی IP که درون یک بسته SPA احراز هویت‌شده و به‌درستی رمزگشایی‌شده قرار دارد، اجازه عبور از دیوار آتش داده می‌شود\&. این امر این امکان را فراهم می‌کند که به عنوان مثال چنین به نظر برسد که www\&.yahoo\&.com در حال تلاش برای احراز هویت با سیستم هدف است، اما در واقعیت اتصال اصلی از یک IP ظاهراً نامرتبط برقرار خواهد شد\&.
.SH "مثال‌ها (EXAMPLES)"
.sp
مثال‌های زیر آرگومان‌های خط فرمانی را نشان می‌دهند که می‌توان در چند وضعیت مختلف به کلاینت fwknop ارائه داد:
.SS "شروع سریع (Quick start)"
.sp
مؤثرترین و ساده‌ترین راه برای استفاده از \fBfwknop\fR این است که کلاینت هر دو کلید رمزگذاری و HMAC را تولید کرده و سپس آن‌ها را همراه با مشخصات درخواست دسترسی در فایل \(lq$HOME/\&.fwknoprc\(rq ذخیره کند\&. کلیدها همچنین باید به سیستمی که \fBfwknopd\fR روی آن اجرا می‌شود منتقل شوند\&. کلاینت همچنین در صورتی که چندین سرور fwknopd روی سیستم‌های مختلف اجرا شوند، از مجموعه‌ای جداگانه از کلیدهای رمزگذاری و HMAC برای هر مقصد SPA پشتیبانی می‌کند\&.
.sp
بنابراین با فرض اینکه IP شماره \fI2\&.2\&.2\&.2\fR سیستمی است که \fBfwknopd\fR روی آن مستقر است و SSH توسط دیوار آتش روی آن سیستم در یک حالت مسدودسازی پیش‌فرض (default-drop) محافظت می‌شود، کلاینت را به این صورت اجرا کنید تا کلیدهای رمزگذاری و HMAC تولید شوند:
.sp
.if n \{\
.RS 4
.\}
.nf
    $ fwknop \-A tcp/22 \-\-use\-hmac \-R \-D 2\&.2\&.2\&.2 \-\-key\-gen \-\-save\-rc\-stanza \-\-verbose
    [+] Wrote Rijndael and HMAC keys to rc file: /home/user/\&.fwknoprc
.fi
.if n \{\
.RE
.\}
.sp
با تولید و ذخیره آرگومان‌های درخواست دسترسی و کلیدهای رمزگذاری و HMAC در \(lq$HOME/\&.fwknoprc\(rq، خود کلیدها باید به سیستم \fI2\&.2\&.2\&.2\fR که fwknopd روی آن اجرا می‌شود منتقل شوند\&. طبق معمول، این کار باید از طریق روشی امن مانند SSH قبل از فعال شدن SPA و مسدود شدن SSHD توسط دیوار آتش انجام شود\&. در اینجا شکل بخش جدید \fI2\&.2\&.2\&.2\fR در فایل \fI~/\&.fwknoprc\fR آمده است:
.sp
.if n \{\
.RS 4
.\}
.nf
    $ tail \-n 8 /home/user/\&.fwknoprc
    [2\&.2\&.2\&.2]
    ACCESS                      tcp/22
    SPA_SERVER                  2\&.2\&.2\&.2
    KEY_BASE64                  HvUtIOramehLGKimD4ECXOzinaH4h3U8H1WXum7b54Q=
    HMAC_KEY_BASE64             DLeLf93a3yBT2vhEpM+dWlirGta5GU+jdyG5uXp4461HgOtbqMem4gX0Bp2PJGzYZlbbcavcOM00UPm+0GqkXA==
    USE_HMAC                    Y
    VERBOSE                     Y
    RESOLVE_IP_HTTPS            Y
.fi
.if n \{\
.RE
.\}
.sp
کلیدها توده‌هایی از داده‌های تصادفی کدگذاری‌شده با base64 هستند و هر دو خط \fBKEY_BASE64\fR و \fBHMAC_KEY_BASE64\fR باید عیناً کپی شده و درون فایل \fI/etc/fwknop/access\&.conf\fR روی \fI2\&.2\&.2\&.2\fR قرار داده شوند\&. پس از انجام این کار، \fBfwknopd\fR می‌تواند روی آن سیستم راه‌اندازی شود، یک سیاست default-drop در برابر اتصالات SSH برقرار گردد و سپس دسترسی به SSH از طریق fwknop مدیریت شود\&. برای دسترسی به SSH، کافی است از آرگومان \fB\-n\fR برای ارجاع به بخش \fI2\&.2\&.2\&.2\fR از فایل \&.fwknoprc استفاده کنید (برخی از خروجی‌های \fB\-\-verbose\fR برای شفاف‌سازی آورده شده‌اند):
.sp
.if n \{\
.RS 4
.\}
.nf
    $ fwknop \-n 2\&.2\&.2\&.2

    FKO Field Values:
    =================

       Random Value: 8950423288486978
           Username: mbr
          Timestamp: 1370194770
        FKO Version: 2\&.5
       Message Type: 1 (Access msg)
     Message String: 1\&.1\&.1\&.1,tcp/22
         Nat Access: <NULL>
        Server Auth: <NULL>
     Client Timeout: 0 (seconds)
        Digest Type: 3 (SHA256)
          HMAC Type: 3 (SHA256)
    Encryption Type: 1 (Rijndael)
    Encryption Mode: 2 (CBC)
    \&.\&.\&.

    $ ssh \-l user 2\&.2\&.2\&.2
    user@2\&.2\&.2\&.2\*(Aqs password:
.fi
.if n \{\
.RE
.\}
.SS "مثال‌های حالت دسترسی (Access mode examples)"
.sp
رایج‌ترین کاربرد \fBfwknop\fR دستیابی به دسترسی SSH در یک سیستم راه دور است که دیمن \fBfwknopd\fR همراه با سیاست دیوار آتش default-drop روی آن مستقر شده است\&. دستور زیر این موضوع را نشان می‌دهد که در آن IP شماره \fI1\&.1\&.1\&.1\fR آدرسی است که باید از طریق دیوار آتش در حال اجرا روی \fI3\&.3\&.3\&.3\fR مجاز شود (توجه داشته باشید که فایل \fI/etc/fwknop/access\&.conf\fR که توسط \fBfwknopd\fR استفاده می‌شود باید دارای کلیدهای منطبق رمزگذاری و HMAC باشد، و جزئیات پیکربندی را می‌توان در صفحه راهنمای \fIfwknopd(8)\fR یافت)\&. همچنین توجه کنید که مثال‌های زیر از کاربر می‌خواهند کلیدهای رمزگذاری و HMAC را از طریق stdin وارد کند به جای اینکه مانند مثال بالا در فایل \(lq$HOME/\&.fwknoprc\(rq روی دیسک بنویسد\&. با این حال تمام مثال‌های زیر را می‌توان تنها با افزودن آرگومان \fB\-\-save\-rc\-stanza\fR به استفاده از فایل ~/\&.fwknoprc تبدیل کرد:
.sp
.if n \{\
.RS 4
.\}
.nf
    $ fwknop \-A tcp/22 \-\-use\-hmac \-a 1\&.1\&.1\&.1 \-D 3\&.3\&.3\&.3
    Enter encryption key:
    Enter HMAC key:
    $ ssh \-l user 3\&.3\&.3\&.3
    user@3\&.3\&.3\&.3\*(Aqs password:
.fi
.if n \{\
.RE
.\}
.sp
اگر پرچم \fB\-\-verbose\fR به خط فرمان اضافه شود، برخی از جزئیات بسته SPA در خروجی استاندارد چاپ می‌شوند (همه خروجی‌ها برای اختصار نشان داده نشده‌اند):
.sp
.if n \{\
.RS 4
.\}
.nf
    $ fwknop \-A tcp/22 \-\-use\-hmac \-a 1\&.1\&.1\&.1 \-D 3\&.3\&.3\&.3 \-\-verbose
    Enter encryption key:
    Enter HMAC key:

       Random Value: 1916307060193417
           Username: mbr
          Timestamp: 1368498909
        FKO Version: 2\&.5
       Message Type: 1 (Access msg)
     Message String: 1\&.1\&.1\&.1,tcp/22
         Nat Access: <NULL>
        Server Auth: <NULL>
     Client Timeout: 0 (seconds)
        Digest Type: 3 (SHA256)
          HMAC Type: 3 (SHA256)
    Encryption Type: 1 (Rijndael)
    Encryption Mode: 2 (CBC)
.fi
.if n \{\
.RE
.\}
.sp
دسترسی هم‌زمان به چندین سرویس نیز پشتیبانی می‌شود و در اینجا نمونه‌ای از درخواست دسترسی به هر دو سرویس \fISSH\fR و \fIOpenVPN\fR روی \fI3\&.3\&.3\&.3\fR آورده شده است:
.sp
.if n \{\
.RS 4
.\}
.nf
    $ fwknop \-A "tcp/22,tcp/1194" \-\-use\-hmac \-a 1\&.1\&.1\&.1 \-D 3\&.3\&.3\&.3
.fi
.if n \{\
.RE
.\}
.sp
موارد زیادی وجود دارد که کلاینت \fBfwknop\fR در شبکه‌ای پشت یک دستگاه NAT مستقر است و IP دارای قابلیت مسیریابی خارجی برای کاربر مشخص نیست\&. در این حالت، از سرویس تفکیک IP موجود در \fIhttps://www\&.cipherdyne\&.org/cgi\-bin/myip\fR از طریق سوئیچ خط فرمان \fB\-R\fR برای به دست آوردن نشانی IP کلاینت خارجی استفاده کنید\&. این روشی امن‌تر از استفاده از گزینه \fB\-s\fR ذکرشده در بخش‌های قبلی این صفحه راهنما است، زیرا IP مبدأ درون بسته رمزگذاری‌شده قرار می‌گیرد به جای اینکه دیمن \fBfwknopd\fR دسترسی درخواستی را از هر نشانی IP که بسته SPA از آن سرچشمه می‌گیرد اعطا کند (یعنی استفاده از \fB\-s\fR امکان حمله MITM را باز می‌گذارد):
.sp
.if n \{\
.RS 4
.\}
.nf
    $ fwknop \-A tcp/22 \-\-use\-hmac \-R \-D 3\&.3\&.3\&.3
.fi
.if n \{\
.RE
.\}
.sp
استفاده از حالت احراز هویت تک‌بسته‌ای برای دستیابی به دسترسی \fISSH\fR و این بار استفاده از کلیدهای GnuPG برای رمزگذاری و رمزگشایی:
.sp
.if n \{\
.RS 4
.\}
.nf
    $ fwknop \-A tcp/22 \-\-use\-hmac \-\-gpg\-sign ABCD1234 \-\-gpg\-\-recipient 1234ABCD \-R \-D 3\&.3\&.3\&.3
.fi
.if n \{\
.RE
.\}
.sp
دستور به سرور fwknop در حال اجرا در 3\&.3\&.3\&.3 برای مجاز ساختن اتصال 1\&.1\&.1\&.1 به \fISSH\fR، اما با جعل بسته مجازسازی از یک IP مرتبط با \fIwww\&.yahoo\&.com\fR (نیازمند root در سیستم‌عامل کلاینت \fBfwknop\fR):
.sp
.if n \{\
.RS 4
.\}
.nf
    # fwknop \-\-spoof\-src "www\&.yahoo\&.com" \-A tcp/22 \-\-use\-hmac \-a 1\&.1\&.1\&.1 \-D 3\&.3\&.3\&.3
.fi
.if n \{\
.RE
.\}
.sp
هنگامی که \fBfwknopd\fR روی یک دیوار آتش iptables با سیستم‌های مستقر در پشت آن اجرا می‌شود، می‌توان از قابلیت‌های NAT ارائه‌شده توسط iptables برای دسترسی شفاف به سیستم‌های پشت دیوار آتش از طریق SPA بهره برد\&. در اینجا نمونه‌ای آورده شده است که در آن از کلاینت \fBfwknop\fR برای دستیابی به SSH در حال اجرا روی IP غیرقابل مسیریابی \fI192\&.168\&.10\&.23\fR که در شبکه پشت \fI3\&.3\&.3\&.3\fR مستقر است استفاده می‌شود\&. در این حالت، اتصال SSH برقرارشده به \fI3\&.3\&.3\&.3\fR از طریق NAT به‌طور خودکار به سیستم \fI192\&.168\&.10\&.2\fR ترجمه می‌شود:
.sp
.if n \{\
.RS 4
.\}
.nf
    $ fwknop \-A tcp/22 \-N 192\&.168\&.10\&.2:22 \-R \-D 3\&.3\&.3\&.3
.fi
.if n \{\
.RE
.\}
.SH "سازگاری با نسخه‌های پیشین (BACKWARDS COMPATIBILITY)"
.sp
با انتشار نسخه \fI2\&.5\fR، \fBfwknop\fR تغییرات قابل توجهی را در استفاده از رمزنگاری تجربه کرد؛ از جمله افزودن پشتیبانی از رمزنگاری احراز هویت‌شده با HMAC برای هر دو حالت Rijndael و GnuPG، اطمینان از استفاده مناسب از PBKDF1 برای مشتق‌سازی کلید هنگام رمزگذاری بسته‌های SPA با Rijndael، و رفع چندین اشکال از نسخه‌های قبلی fwknop\&. به‌طور کلی، این بدان معناست که هنگام استفاده از Rijndael، بسته‌های SPA تولیدشده توسط نسخه \fI2\&.5\fR با نسخه‌های قبلی fwknop ناسازگار هستند\&. حالت رمزگذاری GnuPG تحت تأثیر این به‌روزرسانی‌ها قرار نگرفته است\&. با این حال حتی هنگام استفاده از Rijndael، سازگاری با نسخه‌های قبلی از طریق تنظیم حالت رمزگذاری \fIlegacy\fR با گزینه \fB\-M\fR در خط فرمان کلاینت fwknop و/یا متغیر \fIENCRYPTION_MODE\fR در فایل \fI/etc/fwknop/access\&.conf\fR پشتیبانی می‌شود\&. به این ترتیب، یک سرور قدیمی‌تر از 2\&.5 می‌تواند بسته‌های SPA تولیدشده توسط کلاینت 2\&.5 و بالاتر را رمزگشایی کند (\fI\-M legacy\fR را تنظیم کنید)، و یک سرور 2\&.5 و بالاتر می‌تواند بسته‌های SPA تولیدشده توسط کلاینت‌های قبل از 2\&.5 را رمزگشایی نماید (\fIENCRYPTION_MODE legacy\fR را در فایل access\&.conf تنظیم کنید)\&. توجه داشته باشید که HMAC تنها از نسخه 2\&.5 پشتیبانی می‌شود و یک ویژگی اختیاری است، بنابراین سازگاری با نسخه‌های قبلی تنها برای پیکربندی‌هایی است که در هیچ‌یک از دو طرف از HMAC استفاده نمی‌کنند\&. اکیداً توصیه می‌شود تمام کلاینت‌ها و سرورهای fwknop به نسخه 2\&.5 ارتقا یافته و از حالت جدید HMAC برای ارتباطات SPA با احراز هویت مناسب استفاده شود\&. پشتیبانی از سازگاری با نسخه‌های پیشین برای تسهیل ارتقای کلاینت‌ها و سرورها در یک رویکرد مرحله‌به‌مرحله استفاده می‌شود\&.
.sp
جهت تأکید، اگر سرور \fBfwknopd\fR به نسخه 2\&.5 (یا بالاتر) ارتقا یافته باشد، اما کلاینت‌های قدیمی‌تر نتوانند هم‌زمان ارتقا یابند، برای هر بخش \fISOURCE\fR در فایل \fI/etc/fwknop/access\&.conf\fR خط زیر را اضافه کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
    ENCRYPTION_MODE         legacy
.fi
.if n \{\
.RE
.\}
.sp
علاوه بر این، اگر متغیر \fIKEY\fR دارای کلید رمزگذاری طولانی‌تر از ۱۶ بایت باشد، باید در فایل \fIaccess\&.conf\fR به ۱۶ نویسه کوتاه شود تا کلاینت‌های پیش از 2\&.5 به‌درستی کار کنند\&. این محدودیت در نسخه 2\&.5 برطرف شده است و انگیزه بیشتری برای ارتقای تمام کلاینت‌ها و سرورها به نسخه 2\&.5 یا بالاتر فراهم می‌کند\&.
.sp
حال با معکوس کردن سناریو، اگر کلاینت‌های \fBfwknop\fR ارتقا یافته باشند اما سرور \fBfwknopd\fR همچنان در نسخه‌ای قبل از 2\&.5 باشد، آرگومان \fI\-M legacy\fR را به خط فرمان fwknop اضافه کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
    $ fwknop \-A tcp/22 \-M legacy \-R \-D 2\&.2\&.2\&.2
.fi
.if n \{\
.RE
.\}
.SH "وابستگی‌ها (DEPENDENCIES)"
.sp
کلاینت \fBfwknop\fR به کتابخانه \fIlibfko\fR نیاز دارد که معمولاً در هر دو توزیع مبدأ و دودویی گنجانده شده و یک کتابخانه اختصاصی توسعه‌یافته توسط پروژه fwknop است\&. هر زمان که از سرور \fBfwknopd\fR استفاده می‌شود، \fIlibpcap\fR یک وابستگی الزامی است\&. با این حال نسخه پیش‌روی \fI2\&.6\fR یک حالت شنونده UDP همراه با پشتیبانی از تفکیک دسترسی‌ها ارائه خواهد داد و در این حالت به libpcap نیاز نخواهد داشت\&. در حالت شنونده UDP، با وجود اینکه fwknopd به یک پورت UDP متصل می‌شود، بسته‌های SPA هرگز تصدیق (acknowledge) نمی‌شوند، بنابراین از دید یک مهاجم هیچ تفاوتی بین شنود غیرفعال شبکه توسط fwknopd در مقایسه با گوش دادن روی یک سوکت UDP از نظر قابلیت پویش وجود ندارد\&.
.sp
برای قابلیت‌های GPG، برنامه GnuPG نیز باید همراه با کتابخانه \fIlibgpgme\fR به‌درستی نصب و پیکربندی شده باشد\&.
.sp
برای بهره‌مندی از تمام ویژگی‌های احراز هویت و مدیریت دسترسی دیمن/سرویس \fBfwknopd\fR، یک دیوار آتش فعال از نوع \fIiptables\fR، \fIipfw\fR یا \fIpf\fR روی سیستم‌عامل زیربنایی مورد نیاز است\&.
.SH "عیب‌یابی و تشخیص خطا (DIAGNOSTICS)"
.sp
جامع‌ترین روش برای دریافت اطلاعات تشخیصی در مورد \fBfwknop\fR، اجرای اسکریپت مجموعه آزمون \fItest\-fwknop\&.pl\fR واقع در دایرکتوری \fItest/\fR در سورس‌کدهای fwknop است\&. مجموعه آزمون، fwknop را از طریق تعداد زیادی آزمون زمان اجرا بررسی می‌کند، از \fIvalgrind\fR پشتیبانی می‌نماید، نتایج هر دو رمزگذاری SPA و HMAC را در برابر OpenSSL اعتبارسنجی می‌کند، و حتی فازر (fuzzer) داخلی خود را برای ارتباطات SPA دارد (و fwknop در نسخه 2\&.6\&.4 از \fIAmerican Fuzzy Lop\fR (AFL) اثر Michal Zalewski نیز پشتیبانی می‌کند)\&. برای اطلاعات تشخیصی ابتدایی‌تر، \fBfwknop\fR می‌تواند با گزینه خط فرمان \fB\-T\fR (یا \fB\-\-test\fR) اجرا شود\&. این کار باعث می‌شود \fBfwknop\fR صرفاً اطلاعات بسته SPA را ایجاد و چاپ کند، سپس آن را از یک چرخه رمزگشایی/کدگشایی عبور داده و دوباره چاپ نماید\&. علاوه بر این، سوئیچ خط فرمان \fB\-\-verbose\fR برای مشاهده جزئیات مختلف بسته SPA که در خروجی استاندارد چاپ می‌شوند مفید است\&.
.SH "همچنین ببینید (SEE ALSO)"
.sp
fwknopd(8), iptables(8), pf(4), pfctl(8), ipfw(8), gpg(1), libfko documentation\&.
.sp
اطلاعات بیشتر درباره احراز هویت تک‌بسته‌ای را می‌توانید در مقاله \(lqSingle Packet Authorization with fwknop\(rq موجود در \fIhttp://www\&.cipherdyne\&.org/fwknop/docs/SPA\&.html\fR بیابید\&. یک راهنمای جامع درباره عملکرد و تئوری \fBfwknop\fR در \fIhttp://www\&.cipherdyne\&.org/fwknop/docs/fwknop\-tutorial\&.html\fR موجود است\&. این راهنما همچنین شامل اطلاعاتی درباره طراحی \fBfwknop\fR است که ممکن است برای علاقه‌مندان به اینکه چرا fwknop با سایر پیاده‌سازی‌های SPA تفاوت دارد، ارزش مطالعه داشته باشد\&.
.sp
پروژه \fBfwknop\fR از سیستم کنترل نسخه \fIgit\fR به عنوان مخزن کد منبع خود همراه با \fIGithub\fR برای ردیابی مسائل و نقاط عطف استفاده می‌کند:
.sp
.if n \{\
.RS 4
.\}
.nf
    $ git clone https://github\&.com/mrash/fwknop\&.git fwknop\&.git
.fi
.if n \{\
.RE
.\}
.sp
توضیحات و تفاسیر بیشتر درباره احراز هویت تک‌بسته‌ای را می‌توانید از طریق فید توییتر Michael Rash بیابید: http://twitter\&.com/michaelrash, @michaelrash
.SH "نویسندگان (AUTHORS)"
.sp
توسعه‌دهندگان اصلی \fBfwknop\fR عبارتند از Michael Rash (ایجادکننده پروژه) <mbr@cipherdyne\&.org>، Damien Stuart <dstuart@dstuart\&.org>، و Jonathan Bennett <jbennett@incomsystems\&.biz>\&.
.SH "مشارکت‌کنندگان (CONTRIBUTORS)"
.sp
این نسخه «C» از fwknop از نسخه اصلی مبتنی بر Perl مشتق شده است که افراد زیادی که در جامعه متن‌باز فعال هستند در آن مشارکت داشته‌اند\&. فایل CREDITS را در سورس‌های fwknop ببینید، یا به \fIhttps://github\&.com/mrash/fwknop/blob/master/CREDITS\fR مراجعه کنید تا فهرست آنلاین مشارکت‌کنندگان را مشاهده نمایید\&. چند مشارکت‌کننده شایسته تقدیر ویژه هستند از جمله: Franck Joncourt، Max Kastanas، Vlad Glagolev، Sean Greven، Hank Leininger، Fernando Arnaboldi و Erik Gomez\&.
.sp
عبارت \(lqSingle Packet Authorization\(rq توسط MadHat و Simple Nomad در کنفرانس BlackHat Briefings سال 2005 ابداع شد\&.
.SH "اشکالات (BUGS)"
.sp
گزارش‌های اشکال را به dstuart@dstuart\&.org یا mbr@cipherdyne\&.org ارسال کنید، یا یک issue جدید در Github باز کنید (ببینید: \fIhttps://github\&.com/mrash/fwknop\&.git\fR)\&. پیشنهادات و/یا نظرات نیز همیشه مورد استقبال قرار می‌گیرند\&. اطلاعات تکمیلی را می‌توانید در آرشیو لیست پستی \fBfwknop\fR بیابید (ببینید: \fIhttps://lists\&.sourceforge\&.net/lists/listinfo/fwknop\-discuss\fR)\&.
.SH "توزیع (DISTRIBUTION)"
.sp
نرم‌افزار \fBfwknop\fR تحت مجوز عمومی همگانی گنو (GPL v2+) توزیع می‌شود و آخرین نسخه آن را می‌توان از \fIhttp://www\&.cipherdyne\&.org\fR دریافت کرد\&.