.\" $Id: sockd.conf.5,v 1.187.4.4.2.2.4.2 2019/01/09 16:52:18 karls Exp $ .\" .\" Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, .\" 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2017 .\" Inferno Nettverk A/S, Norway. All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. The above copyright notice, this list of conditions and the following .\" disclaimer must appear in all copies of the software, derivative works .\" or modified versions, and any portions thereof, aswell as in all .\" supporting documentation. .\" 2. All advertising materials mentioning features or use of this software .\" must display the following acknowledgement: .\" This product includes software developed by .\" Inferno Nettverk A/S, Norway. .\" 3. The name of the author may not be used to endorse or promote products .\" derived from this software without specific prior written permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. .\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" .\" Inferno Nettverk A/S requests users of this software to return to .\" .\" Software Distribution Coordinator or sdc@inet.no .\" Inferno Nettverk A/S .\" Oslo Research Park .\" Gaustadalleen 21 .\" NO-0349 Oslo .\" Norway .\" .\" any improvements or extensions that they make and grant Inferno Nettverk A/S .\" the rights to redistribute these changes. .\" .TH SOCKD.CONF 5 "29 ژوئیه 2013" "Parch Linux" "راهنمای مدیر سیستم" .SH "نام (NAME)" sockd.conf \- نحو فایل پیکربندی سرور \fBDante\fP .SH "توضیحات (DESCRIPTION)" فایل پیکربندی سرور \fBDante\fP کنترل‌های دسترسی و ثبت وقایع (logging) را مدیریت می‌کند. این فایل به سه بخش تقسیم می‌شود: تنظیمات سرور (server settings)، قوانین (rules) و مسیرها (routes). توجه داشته باشید که تنظیمات سرور \fBحتماً باید\fP قبل از قوانین و مسیرها قرار گیرند. یک خط را می‌توان با استفاده از نویسه استاندارد کامنت یعنی \fB#\fP به توضیح تبدیل کرد. .SH "تنظیمات سرور (SERVER SETTINGS)" تنظیمات سرور رفتار کلی سرور را کنترل می‌کنند. هر کلیدواژه با یک نویسه \fB':'\fP از مقدار خود جدا می‌شود. کلیدواژه‌های زیر در دسترس هستند: .IP \fBclientmethod\fP فهرستی از روش‌های احراز هویت قابل قبول برای قوانین کلاینت (client-rules) که به ترتیب اولویت نوشته می‌شوند. این‌ها روش‌های احراز هویتی هستند که بلافاصله پس از اتصال کلاینت SOCKS به \fBDante\fP و \fBپیش از\fP آغاز هرگونه مذاکره ساکس (socks-negotiation) بررسی می‌شوند. مقادیر پشتیبانی‌شده عبارتند از: \fBpam.address\fP، \fBpam.any\fP، \fBnone\fP و \fBrfc931\fP. در تمامی این روش‌ها، احراز هویت صرفاً بر اساس آدرس IP کلاینت انجام می‌شود، که ممکن است با یک جستجوی \fBrfc931\fP ("ident") به سمت میزبان کلاینت ترکیب شود. هرگونه اعتبارنامه‌ای که در طول این مرحله ارائه شود، برای استفاده در قوانین بعدی ساکس (socks-rules) هنگام ارزیابی درخواست socks کلاینت نیز در دسترس خواهد بود. مقدار پیش‌فرض این کلیدواژه، تمامی روش‌هایی است که ممکن است برای احراز هویت مبتنی بر socks در مراحل بعدی نیاز باشد، همان‌طور که در مقادیر کلیدواژه سراسری socksmethod مشخص شده است. معمولاً نیازی به تنظیم دستی این کلیدواژه ندارید، زیرا \fBDante\fP خودش آن را روی مقدار مناسب تنظیم می‌کند. .IP \fBcompatibility\fP با کلیدواژه \fBsameport\fP، سرور تلاش می‌کند از همان پورتی در سمت خارجی سرور استفاده کند که کلاینت در سمت داخلی سرور استفاده کرده است. این حالت معمولاً رفتار پیش‌فرض است، اما وقتی این گزینه مشخص شود، برای پورت‌های ممتاز (privileged) نیز انجام می‌شود؛ بدین معنا که اگر کلاینتی از یک پورت ممتاز به \fBDante\fP متصل شود، \fBDante\fP نیز تلاش خواهد کرد با یک پورت ممتاز به مقصد مورد نظر متصل شود. این موضوع می‌تواند مسائل امنیتی در پی داشته باشد، بنابراین معمولاً نباید این گزینه فعال شود. کلیدواژه \fBdraft-5.05\fP استفاده از بخش‌هایی از پیش‌نویس socks v5-05 را فعال می‌کند. تنها قابلیتی که \fBDante\fP از این پیش‌نویس پشتیبانی می‌کند، افزونه "USECLIENTSPORT" است. توجه داشته باشید که تفاسیر متناقضی از این افزونه وجود دارد، بنابراین فعال کردن آن ممکن است مانع از کارکرد صحیح کلاینت‌هایی شود که از تفاسیر دیگر استفاده می‌کنند. این گزینه فقط بر روی UDP تأثیر می‌گذارد. .IP \fBcpu\fP تنظیمات پردازنده (CPU) برای انواع مختلف فرایندهای \fBDante\fP. توجه داشته باشید که امکان پیکربندی این تنظیمات به بستری (platform) که \fBDante\fP روی آن اجرا می‌شود بستگی دارد و ممکن است همه بسترها از این نوع تنظیمات CPU پشتیبانی نکنند. چهار نوع فرایند وجود دارد: \fBmother\fP، \fBnegotiate\fP، \fBrequest\fP و \fBio\fP. گزینه‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از: \fBschedule\fP.: /. مثال: \fBcpu.schedule.mother: SCHED_FIFO/20\fP دستور بالا از هسته درخواست می‌کند که فرایند(های) mother را با استفاده از خط‌مشی خروج به ترتیب ورود (FIFO) و با اولویت ۲۰ زمان‌بندی کند. حالت پیش‌فرض این است که هیچ زمان‌بندی خاصی درخواست نشود. \fBmask\fP.: [cpu id 1 ...]/any. مثال: \fBcpu.mask.mother: any\fP مثال: \fBcpu.mask.io: 0 1\fP ماسک (mask) امکان کنترل روی پردازنده/هسته‌هایی که انواع مختلف فرایندها روی آن‌ها اجرا می‌شوند را فراهم می‌کند. مشخص کردن مقدار پیش‌فرض (\fBall\fP) به نوع فرایند اجازه می‌دهد روی هر شناسه CPU اجرا شود. مشخص کردن یک یا چند شناسه عددی CPU، فرایند را به همان مجموعه پردازنده‌ها محدود می‌کند. کلیدواژه‌های پردازنده (\fBschedule\fP و \fBmask\fP) در بیشتر موارد ضروری نیستند. اگر قرار است استفاده شوند، فرایندهای \fBio\fP بخش عمده کار را انجام می‌دهند و تنظیم اولویت یا استفاده از CPU برای آن‌ها احتمالاً بیشترین تأثیر عملکردی را بر کارایی کلاینت و بار سرور خواهد داشت. فرایندهای دیگر عمدتاً در زمان برقراری اتصال/نشست استفاده می‌شوند و تغییر تنظیمات برای انواع فرایندهای غیر io در درجه اول بر این عملیات تأثیر می‌گذارد. پیش‌فرض این است که فرایندها به پردازنده خاصی محدود نشوند. .IP \fBdebug\fP چاپ اطلاعات اشکال‌زدایی (دیباگ) در گزارش‌ها. مقدار ورودی، سطح دیباگ را مشخص می‌کند. .IP \fBerrorlog\fP این مقدار را می‌توان برای دریافت خروجی گزارش‌های صرفاً مربوط به خطا تنظیم کرد. توجه داشته باشید که این گزینه شامل خطاهای خاص کلاینت نمی‌شود، بلکه تنها خطاهای جدی‌تر و «سراسری» را در بر می‌گیرد. مقادیر ممکن همان مقادیر کلیدواژه \fBlogoutput\fP هستند که در زیر اشاره شده است. هدف این است که مکان ویژه‌ای وجود داشته باشد که فقط خطاهای جدی در آن ثبت شوند تا بتوان آن‌ها را به سرعت شناسایی کرد. پیش‌فرض این است که مکان ویژه‌ای برای ثبت خطاها وجود نداشته باشد. .IP \fBexternal\fP آدرسی که برای اتصالات خروجی استفاده می‌شود. آدرس داده‌شده می‌تواند یک آدرس IP یا نام یک رابط شبکه (interface) باشد. می‌توان این گزینه را چندین بار برای آدرس‌های مختلف تکرار کرد. .IP \fBexternal.log..error\fP به \fBinternal.log..error\fP مراجعه کنید. این گزینه ساختار نحوی و معنایی یکسانی دارد، اما برای خطاهای مربوط به سمت رابط خارجی اعمال می‌شود. .IP \fBexternal.protocol\fP به طور پیش‌فرض \fBDante\fP از خانواده‌های آدرس مشخص‌شده و در دسترس استفاده می‌کند و نیازی به تنظیم این کلیدواژه نیست. با این حال، در برخی موارد مدیر سیستم ممکن است بخواهد آدرسی را به شکلی مشخص کند که بیش از یک خانواده آدرس را شامل شود، اما نخواهد Dante از تمام خانواده‌های آدرس موجود برای آن شکل آدرس استفاده کند. این حالت معمولاً زمانی رخ می‌دهد که مدیر بخواهد مشخص کند Dante باید از آدرس‌های روی یک کارت شبکه که هر دو آدرس IPv4 و IPv6 روی آن پیکربندی شده‌اند استفاده کند، اما بخواهد Dante فقط از یکی از این دو خانواده آدرس استفاده نماید. در این صورت مدیر می‌تواند خانواده آدرسی را که می‌خواهد Dante هنگام باز کردن نام رابط برای استخراج آدرس‌های IP بررسی کند، تعیین کند. مقادیر معتبر برای این کلیدواژه عبارتند از: \fBipv4\fP و \fBipv6\fP، که نشان می‌دهند Dante باید به ترتیب فقط از خانواده آدرس IPv4 یا فقط از خانواده آدرس IPv6 استفاده کند. پیش‌فرض این است که در صورت در دسترس بودن از هر دو خانواده استفاده شود. کلیدواژه متناظری برای سمت داخلی نیز وجود دارد (به \fBinternal.protocol\fP مراجعه کنید). .IP \fBexternal.rotation\fP اگر بیش از یک آدرس خارجی مشخص شده باشد، این گزینه تعیین می‌کند که کدام یک از آدرس‌های داده‌شده به عنوان آدرس مبدأ برای اتصالات/بسته‌های خروجی انتخاب شود. توجه داشته باشید بدون در نظر گرفتن اینکه چه مقدار چرخشی (rotation) استفاده می‌شود، تمام آدرس‌های خارجی مورد استفاده باید ابتدا از طریق کلیدواژه \fBexternal\fP فهرست شده باشند. مقادیر معتبر عبارتند از \fBnone\fP (پیش‌فرض)، \fBroute\fP و \fBsame-same\fP. مقدار \fBnone\fP نشان می‌دهد که اولین آدرس در فهرست آدرس‌های خارجی باید استفاده شود. مقدار \fBroute\fP نشان می‌دهد که جدول مسیریابی هسته باید بررسی شود تا مشخص گردد آدرس مبدأ برای یک مقصد معین چه خواهد بود؛ این گزینه ممکن است نیازمند تنظیم \fBuser.privileged\fP روی \fBroot\fP باشد. توجه داشته باشید که اگر افزونه bind در \fBDante\fP برای کلاینت فعال باشد، \fBroute\fP ممکن است برای کلاینت‌های ftp که از active ftp استفاده می‌کنند مشکل ایجاد کند. مقدار \fBsame-same\fP نشان می‌دهد که آدرس مبدأ برای یک مقصد داده‌شده باید همان آدرسی باشد که سرور \fBDante\fP اتصال کلاینت را روی آن پذیرفته است. .IP \fBinternal\fP آدرس‌های داخلی. اتصالات ورودی فقط روی این آدرس‌ها پذیرفته می‌شوند. آدرس داده‌شده می‌تواند یک آدرس IP یا نام یک رابط شبکه باشد. .IP \fBinternal.log..error\fP مشخص می‌کند که شکست‌های فراخوانی سیستم خاص (که به صورت مقادیر نمادین errno فهرست شده‌اند) یا شکست‌های خاص dns (که به صورت کدهای نمادین خطای libresolv فهرست شده‌اند) باید در سطح گزارش‌گیری \fBlog-level\fP ثبت شوند (احتمالاً یک بار اضافه). توجه داشته باشید که این گزینه فقط برای خطاهای سمت رابط داخلی اعمال می‌شود. کلیدواژه متناظری برای سمت خارجی وجود دارد (به \fBexternal.log\fP مراجعه کنید). علاوه بر نمادهای خطای استاندارد errno و getaddrinfo(3)، نمادهای ویژه زیر نیز پذیرفته می‌شوند: .RS .IP \fBno-route\fP هرگونه خطای مربوط به نبود مسیر (no route). .IP \fBdns-any\fP هرگونه خطای مربوط به تحلیل DNS/نام میزبان. .IP \fBsystem-any\fP هر خطای سیستمی؛ یعنی هر مقدار errno. .RE .IP \fBinternal.protocol\fP به \fBexternal.protocol\fP مراجعه کنید. این گزینه دارای ساختار نحوی و معنایی یکسانی است، اما برای رابط داخلی و آدرس‌هایی که اتصالات کلاینت‌ها روی آن‌ها شنود می‌شود اعمال می‌گردد. .IP \fBlibwrap.hosts_access\fP اگر سرور با پشتیبانی از libwrap کامپایل شده باشد، تعیین می‌کند که آیا تابع \fBhosts_access()\fP باید برای کنترل دسترسی استفاده شود یا خیر. هنگامی که با تنظیم این مقدار روی \fByes\fP فعال شود، کتابخانه libwrap معمولاً با مراجعه به \fB/etc/hosts.allow\fP و \fB/etc/hosts.deny\fP تعیین می‌کند که آیا اتصالات TCP یا بسته‌های UDP باید بلافاصله رد (drop) شوند یا خیر. این بررسی‌ها روی تمام ترافیک، قبل از شروع پردازش قوانین اعمال می‌شوند. مقدار پیش‌فرض \fBno\fP (غیرفعال) است. .IP \fBlogoutput\fP این مقدار مشخص می‌کند سرور خروجی گزارش‌ها را به کجا ارسال کند. می‌توان آن را روی \fBsyslog\fP[/\fBfacility\fP]، \fBstdout\fP، \fBstderr\fP، یک نام فایل یا ترکیبی از آن‌ها تنظیم کرد. پیش‌فرض این است که در هیچ کجا ثبت نشود. توجه داشته باشید که اگر \fBerrorlog\fP نیز تنظیم شده باشد، بین آنچه در آنجا ثبت می‌شود (فقط خطاها) و آنچه در اینجا ثبت خواهد شد (خطاها و سایر موارد) همپوشانی وجود خواهد داشت. .IP \fBsocksmethod\fP فهرستی از روش‌های احراز هویت قابل قبول برای قوانین ساکس (socks-rules) که به ترتیب اولویت فهرست شده‌اند. بنابراین مهم است که این موارد را به ترتیب دلخواه مشخص کنید؛ معمولاً روش‌های امن‌تر در ابتدا قرار می‌گیرند. مقادیر پشتیبانی‌شده عبارتند از: \fBbsdauth\fP، \fBgssapi\fP، \fBnone\fP، \fBpam.any\fP، \fBpam.address\fP، \fBpam.username\fP، \fBrfc931\fP و \fBusername\fP. اگر روشی در این فهرست مشخص نشود، هرگز انتخاب نخواهد شد. مقدار پیش‌فرض هیچ روشی نیست، به این معنی که تمام درخواست‌های socks مسدود خواهند شد. برای توضیح روش‌های مختلف و معانی آن‌ها، بخش \fBروش‌های احراز هویت (AUTHENTICATION METHODS)\fP را ببینید. .IP \fBsrchost\fP این کلیدواژه به شما امکان می‌دهد گزینه‌های مرتبط با میزبان مبدأ (srchost)، یعنی میزبانی که سرور \fBDante\fP اتصالات را از آن می‌پذیرد، پیکربندی کنید. با کلیدواژه \fBnodnsmismatch\fP، سرور اتصالاتی را که آدرس IP و نام میزبان DNS آن‌ها همخوانی ندارند نمی‌پذیرد. پیش‌فرض پذیرش آن‌هاست. با کلیدواژه \fBnodnsunknown\fP، سرور اتصالاتی را از آدرس‌هایی که فاقد رکورد DNS هستند نمی‌پذیرد. پیش‌فرض پذیرش آن‌هاست. با کلیدواژه \fBcheckreplyauth\fP، سرور بررسی می‌کند که آیا احراز هویت روی پاسخ‌های bind و پاسخ‌های udp با آنچه در قانون و مقدار سراسری socksmethod تعیین شده مطابقت دارد یا خیر. معمولاً احراز هویت روی پاسخ‌ها مطلوب نیست، زیرا آن‌ها پاسخ‌هایی هستند که از سمت کلاینت‌های غیر ساکس به کلاینت‌های ساکس ارسال می‌شوند و بنابراین تنها مجموعه محدودی از روش‌های احراز هویت امکان‌پذیر است. روش‌های ممکن برای TCP روش‌هایی هستند که به هیچ وجه پروتکل socks را درگیر نمی‌کنند و در بخش \fBclientmethod\fP پیش‌تر ذکر شدند. برای پاسخ‌های UDP، هیچ روشی نمی‌تواند استفاده شود. پیش‌فرض این است که احراز هویت روی پاسخ‌ها بررسی نشود. .IP \fBtimeout.connect\fP تعداد ثانیه‌هایی که سرور منتظر می‌ماند تا اتصالی که از طرف کلاینت socks آغاز شده کامل شود. پیش‌فرض ۳۰ ثانیه است. تنظیم آن روی ۰ از مقدار پیش‌فرض سیستم استفاده خواهد کرد. .IP \fBtimeout.io\fP تعداد ثانیه‌هایی که یک اتصال برقرار شده می‌تواند بدون فعالیت (idle) بماند. پیش‌فرض ۰ است، به معنای نامحدود. همچنین گزینه "-n" در صفحه راهنمای sockd(8) را ببینید. مهلت‌های زمانی جداگانه را می‌توان برای TCP و UDP با افزودن پسوند "." به io تنظیم کرد؛ مانند \fBtimeout.io.tcp\fP یا \fBtimeout.io.udp\fP. مهلت‌های زمانی را می‌توان درون قوانین نیز با همان ساختار تنظیم کرد. در این صورت، مهلت زمانی تعیین‌شده در قانون، جایگزین مهلت‌های زمانی پیش‌فرض برای کلاینت‌های منطبق با آن قانون خواهد شد. .IP \fBtimeout.negotiate\fP تعداد ثانیه‌هایی که کلاینت می‌تواند برای مذاکره نشست socks با سرور \fBDante\fP صرف کند پیش از آنکه \fBDante\fP اتصال به کلاینت را ببندد. پیش‌فرض ۳۰ ثانیه است. مقدار ۰ را برای نامحدود قرار دهید، هرچند این کار اکیداً توصیه نمی‌شود. .IP \fBtimeout.tcp_fin_wait\fP مهلت زمانی معادل با FIN-WAIT-2 در TCP. پیش‌فرض ۰ است که به معنای استفاده از پیش‌فرض سیستم است (معمولاً بدون محدودیت زمانی). .IP \fBudp.connectdst\fP فعال یا غیرفعال کردن اینکه آیا سرور باید تلاش کند سوکت‌های UDP را به مقصد متصل کند یا خیر. مقادیر معتبر \fByes\fP و \fBno\fP هستند. پیش‌فرض \fByes\fP است که عملکرد UDP را بهبود می‌بخشد، اما ممکن است با برخی از پروتکل‌های کاربردی مبتنی بر UDP سازگار نباشد، زیرا به این معنی است که سرور فقط می‌تواند بسته‌ها را از آدرس مقصد دریافت کند. سوکت تا زمانی متصل باقی می‌ماند که کلاینت فقط بسته‌های UDP را به یک آدرس مقصد ارسال کند. اگر بسته‌ها به چندین مقصد ارسال شوند، سوکت دیگر متصل نخواهد ماند و پاسخ‌ها را می‌توان از هر مقصدی دریافت کرد. .IP \fBUserids\fP در بسترهایی که یک مدل امتیاز (privilege-model) پشتیبانی‌شده توسط \fBDante\fP ارائه می‌دهند، سرور \fBDante\fP از تغییر شناسه کاربر از طریق فراخوانی سیستمی seteuid(2) استفاده نمی‌کند. در سایر بسترها، منطقی است که شناسه کاربری مورد استفاده توسط سرور \fBDante\fP روی مقادیر مناسب تنظیم شود. سرور \fBDante\fP می‌تواند از دو شناسه کاربری مختلف استفاده کند، یا اگر با پشتیبانی از libwrap کامپایل شده باشد از سه شناسه. این شناسه‌ها به شرح زیر هستند: .IP \fBuser.privileged\fP نام کاربری که برای انجام عملیات‌های ممتاز استفاده خواهد شد. اگر برای خواندن فایل sockd.conf یا نوشتن فایل sockd.pid به امتیازات ویژه نیاز دارید (می‌توانید آن را به صورت دستی قبل از شروع sockd ایجاد کنید)، یا چیزی در پیکربندی خود دارید که نیازمند اتصال به پورت‌های ممتاز TCP/UDP (پورت‌های زیر ۱۰۲۴) است، یا از نوعی احراز هویت مبتنی بر رمز عبور استفاده می‌کنید، احتمالاً این مقدار باید روی root تنظیم شود. در غیر این صورت، احتمالاً می‌توانید آن را روی همان مقدار \fBuser.unprivileged\fP تنظیم کنید. .IP \fBuser.unprivileged\fP کاربری که سرور بیشتر اوقات با هویت آن اجرا می‌شود. این باید شناسه‌ای با کمترین امتیازات ممکن باشد. توصیه می‌شود یک شناسه کاربری مجزا برای این منظور ایجاد شود. .IP \fBuser.libwrap\fP کاربری که برای اجرای دستورات libwrap استفاده می‌شود. معمولاً این باید همان \fBuser.unprivileged\fP باشد. .SH "ماژول‌ها (MODULES)" ماژول‌های زیر توسط \fBDante\fP پشتیبانی می‌شوند. ماژول‌ها به صورت جداگانه از شرکت Inferno Nettverk A/S خریداری می‌شوند و ممکن است قابلیت‌های اضافی اضافه کنند که بیشتر کاربران به آن‌ها نیاز ندارند. برای اطلاعات بیشتر به صفحه خانگی \fBDante\fP مراجعه کنید. .IP \fBbandwidth\fP ماژول \fBbandwidth\fP امکان کنترل میزان پهنای باندی را که سرور \fBDante\fP از طرف کلاینت‌های مختلف یا به سمت مقصدهای مختلف استفاده می‌کند، فراهم می‌سازد. .IP \fBredirect\fP ماژول \fBredirect\fP امکان کنترل روی آدرس‌هایی را که سرور از طرف کلاینت‌ها استفاده خواهد کرد فراهم می‌کند، و همچنین به شما امکان می‌دهد درخواست‌های کلاینت را به آدرس‌های متفاوتی هدایت (تغییر مسیر) دهید. .SH "گزینه‌های سوکت (SOCKET OPTIONS)" سرور از تنظیم تعداد زیادی از گزینه‌های سطح پایین سوکت بر روی ترافیک ورودی و خروجی پشتیبانی می‌کند. .I بیشتر کاربران نیازی به تنظیم هیچ‌یک از این گزینه‌ها نخواهند داشت، اما برخی ممکن است بخواهند .I برای فعال کردن ویژگی‌های خاص شبکه یا انجام آزمایش‌های مختلف این کار را انجام دهند. گزینه‌ها را می‌توان به صورت سراسری به عنوان پیش‌فرض برای تمام ترافیک تنظیم کرد، یا در قوانین کنترل دسترسی قرار داد تا فقط بر کلاینت‌ها و مقصدهای منطبق با آن قانون تأثیر بگذارند. گزینه‌های سوکت موجود بین بسترهای مختلف متفاوت است، بنابراین در حین پیکربندی و ساخت سرور، گزینه‌های در دسترس شناسایی می‌شوند. در حال حاضر، گزینه‌های زیر در صورت موجود بودن، برای سطوح پروتکل مشخص‌شده شناسایی می‌شوند: .RS .IP \fBSOCKET\fP so_bindany, so_broadcast, so_debug, so_dontroute, so_jumbo, so_keepalive, so_oobinline, so_priority, so_rcvbuf, so_rcvbufforce, so_rcvlowat, so_sndbuf, so_sndbufforce, so_sndlowat, so_useloopback .RE .RS .IP \fBTCP\fP tcp_cork, tcp_cwnd, tcp_init_cwnd, tcp_keepcnt, tcp_keepidle, tcp_keepintvl, tcp_linger2, tcp_maxrt, tcp_maxseg, tcp_md5sig, tcp_nodelay, tcp_noopt, tcp_nopush, tcp_sack_enable, tcp_stdurg, tcp_syncnt, tcp_window_clamp .RE .RS .IP \fBUDP\fP udp_cork .RE .RS .IP \fBIP\fP ip_auth_level, ip_dontfrag, ip_esp_network_level, ip_esp_trans_level, ip_freebind, ip_ipcomp_level, ip_minttl, ip_mtu_discover, ip_portrange, ip_recvtos, ip_tos, ip_ttl .RE نحو تنظیم گزینه‌های سوکت به صورت زیر است: ..