SOCKD.CONF(5) راهنمای مدیر سیستم SOCKD.CONF(5)

sockd.conf - نحو فایل پیکربندی سرور Dante

فایل پیکربندی سرور Dante کنترل‌های دسترسی و ثبت وقایع (logging) را مدیریت می‌کند. این فایل به سه بخش تقسیم می‌شود: تنظیمات سرور (server settings)، قوانین (rules) و مسیرها (routes).

توجه داشته باشید که تنظیمات سرور حتماً باید قبل از قوانین و مسیرها قرار گیرند.

یک خط را می‌توان با استفاده از نویسه استاندارد کامنت یعنی # به توضیح تبدیل کرد.

تنظیمات سرور رفتار کلی سرور را کنترل می‌کنند. هر کلیدواژه با یک نویسه ':' از مقدار خود جدا می‌شود.

کلیدواژه‌های زیر در دسترس هستند:

فهرستی از روش‌های احراز هویت قابل قبول برای قوانین کلاینت (client-rules) که به ترتیب اولویت نوشته می‌شوند. این‌ها روش‌های احراز هویتی هستند که بلافاصله پس از اتصال کلاینت SOCKS به Dante و پیش از آغاز هرگونه مذاکره ساکس (socks-negotiation) بررسی می‌شوند.

مقادیر پشتیبانی‌شده عبارتند از: pam.address، pam.any، none و rfc931.

در تمامی این روش‌ها، احراز هویت صرفاً بر اساس آدرس IP کلاینت انجام می‌شود، که ممکن است با یک جستجوی rfc931 ("ident") به سمت میزبان کلاینت ترکیب شود.

هرگونه اعتبارنامه‌ای که در طول این مرحله ارائه شود، برای استفاده در قوانین بعدی ساکس (socks-rules) هنگام ارزیابی درخواست socks کلاینت نیز در دسترس خواهد بود.

مقدار پیش‌فرض این کلیدواژه، تمامی روش‌هایی است که ممکن است برای احراز هویت مبتنی بر socks در مراحل بعدی نیاز باشد، همان‌طور که در مقادیر کلیدواژه سراسری socksmethod مشخص شده است. معمولاً نیازی به تنظیم دستی این کلیدواژه ندارید، زیرا Dante خودش آن را روی مقدار مناسب تنظیم می‌کند.

با کلیدواژه sameport، سرور تلاش می‌کند از همان پورتی در سمت خارجی سرور استفاده کند که کلاینت در سمت داخلی سرور استفاده کرده است. این حالت معمولاً رفتار پیش‌فرض است، اما وقتی این گزینه مشخص شود، برای پورت‌های ممتاز (privileged) نیز انجام می‌شود؛ بدین معنا که اگر کلاینتی از یک پورت ممتاز به Dante متصل شود، Dante نیز تلاش خواهد کرد با یک پورت ممتاز به مقصد مورد نظر متصل شود. این موضوع می‌تواند مسائل امنیتی در پی داشته باشد، بنابراین معمولاً نباید این گزینه فعال شود.

کلیدواژه draft-5.05 استفاده از بخش‌هایی از پیش‌نویس socks v5-05 را فعال می‌کند. تنها قابلیتی که Dante از این پیش‌نویس پشتیبانی می‌کند، افزونه "USECLIENTSPORT" است. توجه داشته باشید که تفاسیر متناقضی از این افزونه وجود دارد، بنابراین فعال کردن آن ممکن است مانع از کارکرد صحیح کلاینت‌هایی شود که از تفاسیر دیگر استفاده می‌کنند. این گزینه فقط بر روی UDP تأثیر می‌گذارد.

تنظیمات پردازنده (CPU) برای انواع مختلف فرایندهای Dante. توجه داشته باشید که امکان پیکربندی این تنظیمات به بستری (platform) که Dante روی آن اجرا می‌شود بستگی دارد و ممکن است همه بسترها از این نوع تنظیمات CPU پشتیبانی نکنند.

چهار نوع فرایند وجود دارد: mother، negotiate، request و io.

گزینه‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:

schedule.<process type>: <scheduling policy>/<priority>.

مثال: cpu.schedule.mother: SCHED_FIFO/20 دستور بالا از هسته درخواست می‌کند که فرایند(های) mother را با استفاده از خط‌مشی خروج به ترتیب ورود (FIFO) و با اولویت ۲۰ زمان‌بندی کند.

حالت پیش‌فرض این است که هیچ زمان‌بندی خاصی درخواست نشود.

mask.<process type>: <cpu id 1> [cpu id 1 ...]/any.

مثال: cpu.mask.mother: any مثال: cpu.mask.io: 0 1

ماسک (mask) امکان کنترل روی پردازنده/هسته‌هایی که انواع مختلف فرایندها روی آن‌ها اجرا می‌شوند را فراهم می‌کند. مشخص کردن مقدار پیش‌فرض (all) به نوع فرایند اجازه می‌دهد روی هر شناسه CPU اجرا شود. مشخص کردن یک یا چند شناسه عددی CPU، فرایند را به همان مجموعه پردازنده‌ها محدود می‌کند.

کلیدواژه‌های پردازنده (schedule و mask) در بیشتر موارد ضروری نیستند. اگر قرار است استفاده شوند، فرایندهای io بخش عمده کار را انجام می‌دهند و تنظیم اولویت یا استفاده از CPU برای آن‌ها احتمالاً بیشترین تأثیر عملکردی را بر کارایی کلاینت و بار سرور خواهد داشت. فرایندهای دیگر عمدتاً در زمان برقراری اتصال/نشست استفاده می‌شوند و تغییر تنظیمات برای انواع فرایندهای غیر io در درجه اول بر این عملیات تأثیر می‌گذارد.

پیش‌فرض این است که فرایندها به پردازنده خاصی محدود نشوند.

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

مقادیر ممکن همان مقادیر کلیدواژه logoutput هستند که در زیر اشاره شده است.

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

آدرسی که برای اتصالات خروجی استفاده می‌شود. آدرس داده‌شده می‌تواند یک آدرس IP یا نام یک رابط شبکه (interface) باشد. می‌توان این گزینه را چندین بار برای آدرس‌های مختلف تکرار کرد.
به internal.log.<loglevel>.error مراجعه کنید. این گزینه ساختار نحوی و معنایی یکسانی دارد، اما برای خطاهای مربوط به سمت رابط خارجی اعمال می‌شود.
به طور پیش‌فرض Dante از خانواده‌های آدرس مشخص‌شده و در دسترس استفاده می‌کند و نیازی به تنظیم این کلیدواژه نیست.

با این حال، در برخی موارد مدیر سیستم ممکن است بخواهد آدرسی را به شکلی مشخص کند که بیش از یک خانواده آدرس را شامل شود، اما نخواهد Dante از تمام خانواده‌های آدرس موجود برای آن شکل آدرس استفاده کند.

این حالت معمولاً زمانی رخ می‌دهد که مدیر بخواهد مشخص کند Dante باید از آدرس‌های روی یک کارت شبکه که هر دو آدرس IPv4 و IPv6 روی آن پیکربندی شده‌اند استفاده کند، اما بخواهد Dante فقط از یکی از این دو خانواده آدرس استفاده نماید. در این صورت مدیر می‌تواند خانواده آدرسی را که می‌خواهد Dante هنگام باز کردن نام رابط برای استخراج آدرس‌های IP بررسی کند، تعیین کند.

مقادیر معتبر برای این کلیدواژه عبارتند از: ipv4 و ipv6، که نشان می‌دهند Dante باید به ترتیب فقط از خانواده آدرس IPv4 یا فقط از خانواده آدرس IPv6 استفاده کند. پیش‌فرض این است که در صورت در دسترس بودن از هر دو خانواده استفاده شود.

کلیدواژه متناظری برای سمت داخلی نیز وجود دارد (به internal.protocol مراجعه کنید).

اگر بیش از یک آدرس خارجی مشخص شده باشد، این گزینه تعیین می‌کند که کدام یک از آدرس‌های داده‌شده به عنوان آدرس مبدأ برای اتصالات/بسته‌های خروجی انتخاب شود. توجه داشته باشید بدون در نظر گرفتن اینکه چه مقدار چرخشی (rotation) استفاده می‌شود، تمام آدرس‌های خارجی مورد استفاده باید ابتدا از طریق کلیدواژه external فهرست شده باشند.

مقادیر معتبر عبارتند از none (پیش‌فرض)، route و same-same.

مقدار none نشان می‌دهد که اولین آدرس در فهرست آدرس‌های خارجی باید استفاده شود.

مقدار route نشان می‌دهد که جدول مسیریابی هسته باید بررسی شود تا مشخص گردد آدرس مبدأ برای یک مقصد معین چه خواهد بود؛ این گزینه ممکن است نیازمند تنظیم user.privileged روی root باشد. توجه داشته باشید که اگر افزونه bind در Dante برای کلاینت فعال باشد، route ممکن است برای کلاینت‌های ftp که از active ftp استفاده می‌کنند مشکل ایجاد کند.

مقدار same-same نشان می‌دهد که آدرس مبدأ برای یک مقصد داده‌شده باید همان آدرسی باشد که سرور Dante اتصال کلاینت را روی آن پذیرفته است.

آدرس‌های داخلی. اتصالات ورودی فقط روی این آدرس‌ها پذیرفته می‌شوند. آدرس داده‌شده می‌تواند یک آدرس IP یا نام یک رابط شبکه باشد.
مشخص می‌کند که شکست‌های فراخوانی سیستم خاص (که به صورت مقادیر نمادین errno فهرست شده‌اند) یا شکست‌های خاص dns (که به صورت کدهای نمادین خطای libresolv فهرست شده‌اند) باید در سطح گزارش‌گیری log-level ثبت شوند (احتمالاً یک بار اضافه).

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

کلیدواژه متناظری برای سمت خارجی وجود دارد (به external.log مراجعه کنید).

علاوه بر نمادهای خطای استاندارد errno و getaddrinfo(3)، نمادهای ویژه زیر نیز پذیرفته می‌شوند:

هرگونه خطای مربوط به نبود مسیر (no route).
هرگونه خطای مربوط به تحلیل DNS/نام میزبان.
هر خطای سیستمی؛ یعنی هر مقدار errno.
به external.protocol مراجعه کنید. این گزینه دارای ساختار نحوی و معنایی یکسانی است، اما برای رابط داخلی و آدرس‌هایی که اتصالات کلاینت‌ها روی آن‌ها شنود می‌شود اعمال می‌گردد.
اگر سرور با پشتیبانی از libwrap کامپایل شده باشد، تعیین می‌کند که آیا تابع hosts_access() باید برای کنترل دسترسی استفاده شود یا خیر. هنگامی که با تنظیم این مقدار روی yes فعال شود، کتابخانه libwrap معمولاً با مراجعه به /etc/hosts.allow و /etc/hosts.deny تعیین می‌کند که آیا اتصالات TCP یا بسته‌های UDP باید بلافاصله رد (drop) شوند یا خیر. این بررسی‌ها روی تمام ترافیک، قبل از شروع پردازش قوانین اعمال می‌شوند. مقدار پیش‌فرض no (غیرفعال) است.
این مقدار مشخص می‌کند سرور خروجی گزارش‌ها را به کجا ارسال کند. می‌توان آن را روی syslog[/facility]، stdout، stderr، یک نام فایل یا ترکیبی از آن‌ها تنظیم کرد. پیش‌فرض این است که در هیچ کجا ثبت نشود. توجه داشته باشید که اگر errorlog نیز تنظیم شده باشد، بین آنچه در آنجا ثبت می‌شود (فقط خطاها) و آنچه در اینجا ثبت خواهد شد (خطاها و سایر موارد) همپوشانی وجود خواهد داشت.
فهرستی از روش‌های احراز هویت قابل قبول برای قوانین ساکس (socks-rules) که به ترتیب اولویت فهرست شده‌اند. بنابراین مهم است که این موارد را به ترتیب دلخواه مشخص کنید؛ معمولاً روش‌های امن‌تر در ابتدا قرار می‌گیرند.

مقادیر پشتیبانی‌شده عبارتند از: bsdauth، gssapi، none، pam.any، pam.address، pam.username، rfc931 و username.

اگر روشی در این فهرست مشخص نشود، هرگز انتخاب نخواهد شد. مقدار پیش‌فرض هیچ روشی نیست، به این معنی که تمام درخواست‌های socks مسدود خواهند شد.

برای توضیح روش‌های مختلف و معانی آن‌ها، بخش روش‌های احراز هویت (AUTHENTICATION METHODS) را ببینید.

این کلیدواژه به شما امکان می‌دهد گزینه‌های مرتبط با میزبان مبدأ (srchost)، یعنی میزبانی که سرور Dante اتصالات را از آن می‌پذیرد، پیکربندی کنید.

با کلیدواژه nodnsmismatch، سرور اتصالاتی را که آدرس IP و نام میزبان DNS آن‌ها همخوانی ندارند نمی‌پذیرد. پیش‌فرض پذیرش آن‌هاست.

با کلیدواژه nodnsunknown، سرور اتصالاتی را از آدرس‌هایی که فاقد رکورد DNS هستند نمی‌پذیرد. پیش‌فرض پذیرش آن‌هاست.

با کلیدواژه checkreplyauth، سرور بررسی می‌کند که آیا احراز هویت روی پاسخ‌های bind و پاسخ‌های udp با آنچه در قانون و مقدار سراسری socksmethod تعیین شده مطابقت دارد یا خیر. معمولاً احراز هویت روی پاسخ‌ها مطلوب نیست، زیرا آن‌ها پاسخ‌هایی هستند که از سمت کلاینت‌های غیر ساکس به کلاینت‌های ساکس ارسال می‌شوند و بنابراین تنها مجموعه محدودی از روش‌های احراز هویت امکان‌پذیر است.

روش‌های ممکن برای TCP روش‌هایی هستند که به هیچ وجه پروتکل socks را درگیر نمی‌کنند و در بخش clientmethod پیش‌تر ذکر شدند. برای پاسخ‌های UDP، هیچ روشی نمی‌تواند استفاده شود.

پیش‌فرض این است که احراز هویت روی پاسخ‌ها بررسی نشود.

تعداد ثانیه‌هایی که سرور منتظر می‌ماند تا اتصالی که از طرف کلاینت socks آغاز شده کامل شود. پیش‌فرض ۳۰ ثانیه است. تنظیم آن روی ۰ از مقدار پیش‌فرض سیستم استفاده خواهد کرد.
تعداد ثانیه‌هایی که یک اتصال برقرار شده می‌تواند بدون فعالیت (idle) بماند. پیش‌فرض ۰ است، به معنای نامحدود. همچنین گزینه "-n" در صفحه راهنمای sockd(8) را ببینید.

مهلت‌های زمانی جداگانه را می‌توان برای TCP و UDP با افزودن پسوند ".<protocolname>" به io تنظیم کرد؛ مانند timeout.io.tcp یا timeout.io.udp.

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

تعداد ثانیه‌هایی که کلاینت می‌تواند برای مذاکره نشست socks با سرور Dante صرف کند پیش از آنکه Dante اتصال به کلاینت را ببندد. پیش‌فرض ۳۰ ثانیه است. مقدار ۰ را برای نامحدود قرار دهید، هرچند این کار اکیداً توصیه نمی‌شود.
مهلت زمانی معادل با FIN-WAIT-2 در TCP. پیش‌فرض ۰ است که به معنای استفاده از پیش‌فرض سیستم است (معمولاً بدون محدودیت زمانی).
فعال یا غیرفعال کردن اینکه آیا سرور باید تلاش کند سوکت‌های UDP را به مقصد متصل کند یا خیر. مقادیر معتبر yes و no هستند.

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

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

در بسترهایی که یک مدل امتیاز (privilege-model) پشتیبانی‌شده توسط Dante ارائه می‌دهند، سرور Dante از تغییر شناسه کاربر از طریق فراخوانی سیستمی seteuid(2) استفاده نمی‌کند. در سایر بسترها، منطقی است که شناسه کاربری مورد استفاده توسط سرور Dante روی مقادیر مناسب تنظیم شود. سرور Dante می‌تواند از دو شناسه کاربری مختلف استفاده کند، یا اگر با پشتیبانی از libwrap کامپایل شده باشد از سه شناسه. این شناسه‌ها به شرح زیر هستند:
نام کاربری که برای انجام عملیات‌های ممتاز استفاده خواهد شد. اگر برای خواندن فایل sockd.conf یا نوشتن فایل sockd.pid به امتیازات ویژه نیاز دارید (می‌توانید آن را به صورت دستی قبل از شروع sockd ایجاد کنید)، یا چیزی در پیکربندی خود دارید که نیازمند اتصال به پورت‌های ممتاز TCP/UDP (پورت‌های زیر ۱۰۲۴) است، یا از نوعی احراز هویت مبتنی بر رمز عبور استفاده می‌کنید، احتمالاً این مقدار باید روی root تنظیم شود.

در غیر این صورت، احتمالاً می‌توانید آن را روی همان مقدار user.unprivileged تنظیم کنید.

کاربری که سرور بیشتر اوقات با هویت آن اجرا می‌شود. این باید شناسه‌ای با کمترین امتیازات ممکن باشد. توصیه می‌شود یک شناسه کاربری مجزا برای این منظور ایجاد شود.
کاربری که برای اجرای دستورات libwrap استفاده می‌شود. معمولاً این باید همان user.unprivileged باشد.

ماژول‌های زیر توسط Dante پشتیبانی می‌شوند. ماژول‌ها به صورت جداگانه از شرکت Inferno Nettverk A/S خریداری می‌شوند و ممکن است قابلیت‌های اضافی اضافه کنند که بیشتر کاربران به آن‌ها نیاز ندارند. برای اطلاعات بیشتر به صفحه خانگی Dante مراجعه کنید.

ماژول bandwidth امکان کنترل میزان پهنای باندی را که سرور Dante از طرف کلاینت‌های مختلف یا به سمت مقصدهای مختلف استفاده می‌کند، فراهم می‌سازد.
ماژول redirect امکان کنترل روی آدرس‌هایی را که سرور از طرف کلاینت‌ها استفاده خواهد کرد فراهم می‌کند، و همچنین به شما امکان می‌دهد درخواست‌های کلاینت را به آدرس‌های متفاوتی هدایت (تغییر مسیر) دهید.

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

گزینه‌ها را می‌توان به صورت سراسری به عنوان پیش‌فرض برای تمام ترافیک تنظیم کرد، یا در قوانین کنترل دسترسی قرار داد تا فقط بر کلاینت‌ها و مقصدهای منطبق با آن قانون تأثیر بگذارند.

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

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
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
udp_cork
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

نحو تنظیم گزینه‌های سوکت به صورت زیر است:

<direction>.<level>.<option>: <value>

فیلد value مربوط به مقداری است که گزینه سوکت باید روی آن تنظیم شود. برای بسیاری از گزینه‌های سوکت این یک مقدار عددی صحیح است. مقادیر level و option با نام سوکت‌ها و سطوح پروتکل فهرست‌شده در بالا مطابقت دارند. هر دو باید با حروف کوچک نوشته شوند.

کلیدواژه direction برای تعیین اینکه آیا گزینه سوکت باید برای ترافیک روی رابط داخلی یا خارجی تنظیم شود استفاده می‌شود و می‌تواند مقادیر internal و external را داشته باشد. به عنوان مثال، برای تنظیم گزینه سوکت IP_TOS روی ترافیک خروجی، می‌توان از نحو زیر استفاده کرد:

external.ip.ip_tos: 0x10

در این مثال، مقدار آرگومان (0x10) به صورت یک مقدار هگزادسیمال مشخص شده است. برای برخی از گزینه‌های سوکت، مقدار را می‌توان به صورت نمادین نیز تنظیم کرد. در حال حاضر این امر برای گزینه‌های زیر با مقادیر ذکر شده امکان‌پذیر است:

ip_portrange_default, ip_portrange_low, ip_portrange_high

گزینه سوکت IP_TOS نیز از این قابلیت پشتیبانی می‌کند، اما مدیریت این گزینه تا حدودی پیچیده است زیرا بیت‌های یکسان در RFCهای مختلف معانی متفاوتی دارند. مدیریت این موضوع با یک زیرفیلد انجام می‌شود که نوع آرگومان مورد استفاده را نشان می‌دهد. زیرفیلدهای زیر تعریف شده‌اند و باید به نام گزینه سوکت مطابق شکل زیر اضافه شوند:

af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43 cs0 cs1 cs2 cs3 cs4 cs5 cs6 cs7 ef
netcontrol internetcontrol critic_ecp flashoverride flash immediate priority routine
lowdelay throughput reliability

هنگامی که آرگومان‌های عددی به زیرفیلدها داده می‌شوند، مقادیر جابجا (shift) می‌شوند تا فقط برای محدوده بیت زیرفیلد اعمال شوند. مثال زیر روش‌های مختلف تنظیم IP_TOS روی lowdelay در ترافیک خارجی را نشان می‌دهد:

external.ip.ip_tos:     0x10       #مقدار پایه، به صورت عددی
external.ip.ip_tos.tos: 0x08       #زیرفیلد، به صورت عددی
external.ip.ip_tos.tos: lowdelay   #زیرفیلد، به صورت نمادین

مقدار اول مستقیماً مقدار را تنظیم می‌کند، دومی فقط بیت‌های TOS را تنظیم می‌کند که نسبت به مقدار پایه جابجا شده‌اند. خط پایانی مقدار TOS را به صورت نمادین تنظیم می‌کند.

این قابلیت کنترل زیادی روی گزینه‌های سوکت فراهم می‌کند، اما نباید بدون درک نحوه اجازه هسته برای تنظیم گزینه سوکت و محدودیت‌هایی که هنگام تنظیم گزینه‌های سوکت به عنوان پیش‌فرض یا در قوانین اعمال می‌شوند، استفاده شود.

تنظیم یک گزینه سوکت در مرحله عبور کلاینت یا قوانین socks باعث لغو هرگونه پیش‌فرضی می‌شود. گزینه‌های سراسری قبل از فراخوانی bind() روی سوکت‌های داخلی یا قبل از فراخوانی connect() روی سوکت‌های خارجی تنظیم می‌شوند. گزینه‌های تنظیم‌شده در قوانین کلاینت نیز قبل از فراخوانی bind() روی سوکت داخلی اعمال می‌شوند، اما نمی‌توان آن‌ها را برای سوکت خارجی تنظیم کرد. برای قوانین socks، هم گزینه‌های خارجی و هم داخلی را می‌توان تنظیم کرد، اما از آنجا که درخواست socks باید قبل از ارزیابی قوانین تفسیر شود، گزینه‌های سوکت فقط پس از دریافت اتصال می‌توانند روی سوکت‌های داخلی تنظیم شوند.

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

گزینه‌های سوکتی که در بالا فهرست نشده‌اند را نیز می‌توان با مشخص کردن نام گزینه سوکت به صورت عددی تنظیم کرد؛ برای مثال:

external.ip.10: 0x12

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

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

این روش به هیچ شکلی از احراز هویت نیاز ندارد.
این روش نیازمند این است که کلاینت یک نام کاربری و رمز عبور ارائه دهد. این اطلاعات باید با نام کاربری و رمز عبور موجود در فایل رمز عبور سیستم مطابقت داشته باشد.
این روش نیازمند راه‌اندازی یک محیط Kerberos است و بسته به تنظیمات gssapi که انتخاب می‌کنید، می‌تواند رمزگذاری و احراز هویت قوی فراهم کند.
این روش نیازمند این است که میزبانی که کلاینت socks روی آن اجرا می‌شود، یک نام کاربری rfc931 ("ident") برای کلاینت ارائه دهد. این نام کاربری باید با یک نام کاربری موجود در فایل رمز عبور سیستم مطابقت داشته باشد.
احراز هویت PAM مبتنی بر IP (rhosts).
بسته به اطلاعاتی که در حال حاضر در دسترس است، تلاش می‌کند با هر نوع احراز هویت PAM مطابقت پیدا کند. معمولاً کاربرد محدودی دارد و در عوض باید روش(های) مبتنی بر pam مورد نظر خود را صراحتاً تنظیم کنید.
احراز هویت PAM مبتنی بر نام کاربری/رمز عبور. مشابه روش username است، با این تفاوت که اطلاعات برای احراز هویت به زیرسیستم PAM ارسال می‌شود، به جای اینکه Dante مستقیماً از فایل رمز عبور سیستم استفاده کند. هنگام استفاده از PAM، مراقب نشت حافظه و سایر باگ‌ها در کتابخانه خارجی PAM که Dante باید روی بستر شما استفاده کند باشید.
این روش نیازمند این است که داده‌های در دسترس کلاینت توسط سیستم احراز هویت BSD تأیید شوند. مشابه روش username است، اما در عوض به سیستم احراز هویت BSD ارسال می‌شود.

هر فیلد آدرس می‌تواند شامل یک آدرس IP (و در صورت نیاز، یک ماسک شبکه که با علامت '/' از آدرس IP جدا شده است)، یک نام میزبان، یک نام دامنه (که با علامت نقطه‌ی ابتدایی '.' مشخص می‌شود) یا نام یک رابط شبکه باشد.

یک آدرس IP را می‌توان به فرمت IPv4، فرمت IPv6، یا به عنوان مقدار ویژه 0/0 مشخص کرد که با تمام آدرس‌های IP (چه IPv4 و چه IPv6) مطابقت دارد. مورد اخیر برای استفاده در قوانین (rules) در نظر گرفته شده است که باید هم با کلاینت‌ها و هم با مقصدهای IPv4 و IPv6 مطابقت داشته باشند.

هر آدرس، به جز آدرس external، می‌تواند شامل یک مشخص‌کننده اختیاری port باشد.

دو دسته قانون وجود دارد و آن‌ها در سطوح متفاوتی کار می‌کنند. قوانینی که با پیشوند client مشخص شده‌اند ابتدا بررسی می‌شوند و برای بررسی اینکه آیا کلاینت اجازه اتصال به سرور Dante را دارد یا خیر استفاده می‌شوند. ما آن‌ها را «قوانین کلاینت» (client-rules) می‌نامیم. این قوانین برای قانونی که کلاینت را مجاز می‌داند با client pass یا برای قانونی که کلاینت را مسدود می‌کند با client block شروع می‌شوند.

توصیه می‌شود که در قوانین کلاینت، هم به دلایل امنیتی و هم عملکردی، از نام‌های میزبان استفاده نشود و فقط از آدرس‌های IP استفاده گردد. این قوانین در سطح TCP عمل می‌کنند.

دسته دیگر قوانین که آن‌ها را «قوانین ساکس» (socks-rules) می‌نامیم، با پیشوند socks مشخص می‌شوند و در سطح پروتکل socks عمل می‌کنند.

این قوانین برای قانونی که کلاینت را مجاز می‌داند با socks pass یا برای قانونی که کلاینت را مسدود می‌کند با socks block شروع می‌شوند.

این قوانین تنها در صورتی بررسی می‌شوند که اتصال کلاینت توسط قوانین کلاینت مجاز دانسته شده باشد. قوانین socks برای ارزیابی درخواست socks ارسالی کلاینت استفاده می‌شوند.

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

هر دو دسته قوانین شامل کلیدواژه pass یا deny هستند. کلیدواژه pass/deny تعیین می‌کند که آیا اتصالات منطبق با قانون باید عبور داده شوند یا مسدود گردند.

هم قوانین کلاینت و هم قوانین socks یک جفت آدرس from/to را نیز مشخص می‌کنند که آدرس‌هایی را که قانون با آن‌ها مطابقت خواهد داشت تعیین می‌کند.

در هر دو زمینه، from به آدرس کلاینت اشاره دارد؛ یعنی آدرسی که کلاینت از آن به سرور Dante متصل می‌شود. با این حال، آدرس to بسته به اینکه در قانون کلاینت استفاده شده باشد یا در قانون socks، به موارد متفاوتی اشاره دارد.

در زمینه قوانین کلاینت، to به معنای آدرسی است که درخواست روی آن پذیرفته می‌شود؛ یعنی آدرسی که سرور Dante روی آن شنود می‌کند.

در زمینه قوانین socks، to به معنای آدرس مقصد کلاینت است، همان‌طور که در درخواست socks کلاینت بیان شده است؛ یعنی آدرسی که سرور Dante باید از طرف کلاینت به آن متصل شود (برای نشست‌های TCP) یا بسته‌ها را به آن ارسال کند (برای نشست‌های UDP).

هر دو مجموعه قوانین بر اساس اصل «نخستین تطابق، بهترین تطابق است» ارزیابی می‌شوند. بدین معنا که نخستین قانونی که برای یک کلاینت یا درخواست socks تطابق یابد، قانونی است که استفاده خواهد شد.

علاوه بر آدرس‌ها، مجموعه‌ای از کلیدواژه‌های اختیاری وجود دارند که می‌توان آن‌ها را تعیین کرد. دو نوع کلیدواژه وجود دارد: شرایط (conditions) و کنش‌ها (actions). برای هر قانون، تمام شرایط بررسی می‌شوند و در صورت تطابق با درخواست، تمام کنش‌ها اجرا می‌گردند.

فهرست کلیدواژه‌های شرطی عبارتند از: clientcompatibility، clientmethod، command، from، group، socksmethod، protocol، proxyprotocol، to، user.

فهرست کلیدواژه‌های کنشی عبارتند از: bandwidth، libwrap، log، session، redirect، timeout.connect، timeout.negotiate، timeout.io، timeout.tcp_fin_wait و udp.portrange.

فرمت و محتوای کلیدواژه‌های مورد استفاده در قوانین کلاینت یا قوانین socks یکسان است، اما قوانین کلاینت می‌توانند تنها شامل زیرمجموعه‌ای از کلیدواژه‌هایی باشند که قوانین socks ممکن است شامل آن‌ها باشند.

محتوای یک قانون کلاینت (client-rule) می‌تواند شامل موارد زیر باشد:
کلاینت‌های منطبق بر این قانون، همگی مقدار پهنای باند مشخص‌شده را که بر حسب بایت بر ثانیه اندازه‌گیری می‌شود به اشتراک خواهند گذاشت. نیازمند ماژول bandwidth است.
گزینه‌های خاصی را برای سازگاری با کلاینت‌های معیوب فعال می‌کند. مقادیر معتبر عبارتند از: necgssapi برای سازگاری با کلاینت‌هایی که GSSAPI را به شیوه NEC socks پیاده‌سازی کرده‌اند.
قانون برای درخواست‌هایی که از آدرس مشخص‌شده می‌آیند اعمال می‌شود.
کاربر باید متعلق به یکی از گروه‌هایی باشد که به عنوان مقدار داده شده است.

توجه داشته باشید اگر از احراز هویت مبتنی بر gssapi استفاده شود، نام کاربری ارائه شده به سرور Dante معمولاً شامل دامنه Kerberos است. اگر قرار است از نام استفاده شود، باید به همان شکل در اینجا و در فایل گروه سیستم (معمولاً /etc/passwd) فهرست شود.

کدام رمزگذاری برای ارتباطات احراز هویت‌شده با GSSAPI اعمال شود. مقادیر ممکن عبارتند از: clear، integrity یا confidentiality. مقدار پیش‌فرض پذیرش هر چیزی است که کلاینت ارائه می‌دهد به جز clear، زیرا clear بخشی از استاندارد SOCKS GSSAPI نیست.
مقداری برای keytab مورد استفاده. مقدار پیش‌فرض "FILE:/etc/sockd.keytab" است.
کدام نام سرویس هنگام درگیر شدن GSSAPI استفاده شود. مقدار پیش‌فرض "rcmd" است.
سرور خط پارامتر مشخص‌شده را برای اجرا به libwrap ارسال می‌کند.
برای کنترل ثبت وقایع استفاده می‌شود. کلیدواژه‌های پذیرفته‌شده عبارتند از connect، disconnect، data، error، ioop و tcpinfo. پیش‌فرض عدم ثبت وقایع است.
کنترل حداکثر تعداد نشست‌ها یا نرخ برقراری نشست. برای جزئیات به زیر مراجعه کنید.
الزام می‌کند که اتصال با استفاده از یکی از روش‌های داده‌شده در clientmethods «احراز هویت» شود.
کدام نام سرویس هنگام درگیر شدن pam استفاده شود. مقدار پیش‌فرض "sockd" است.
پارامتری برای from، to و via. کلیدواژه‌های eq/=, neq/!=, ge/>=, le/<=, gt/>, lt/< را که به دنبال آن‌ها یک عدد می‌آید می‌پذیرد. همچنین می‌توان یک محدوده پورت را به صورت "port <start #> - <end #>" مشخص کرد که با تمام شماره‌های پورت در محدوده <start #> و <end #> مطابقت خواهد داشت.

پیش‌فرض مطابقت با تمام پورت‌ها است.

مبدأ و/یا مقصد را می‌توان با استفاده از دستور redirect هدایت (تغییر مسیر) داد. نیازمند ماژول redirect است.

نحو دستور redirect به صورت زیر است:

redirect from: ADDRESS

برای اطلاعات دقیق به راهنمای redirect مراجعه کنید.

اگر کلاینت بیش از یک روش احراز هویت ارائه دهد، Dante روش مورد استفاده را بر اساس ترتیبی که روش‌ها در اینجا فهرست شده‌اند انتخاب می‌کند. مقادیر معتبر همان مقادیر موجود در خط سراسری socksmethod هستند. معمولاً نیازی به تنظیم این کلیدواژه در یک قانون کلاینت نخواهد بود، اما اگر تنظیم شود و کلاینت هیچ‌یک از روش‌های فهرست‌شده را ارائه ندهد، کلاینت در این مرحله مسدود خواهد شد.
به گزینه سراسری timeout.negotiate مراجعه کنید.
قانون برای درخواست‌هایی که به آدرس داده‌شده به عنوان مقدار می‌روند اعمال می‌شود.
کاربر باید با یکی از نام‌های داده‌شده به عنوان مقدار مطابقت داشته باشد. اگر هیچ مقدار user برای قانونی که به نام‌های کاربری نیاز دارد داده نشود، تأثیر آن همانند فهرست کردن تک‌تک کاربران در فایل رمز عبور خواهد بود.

توجه داشته باشید اگر از احراز هویت مبتنی بر gssapi استفاده شود، نام کاربری ارائه شده به سرور Dante معمولاً شامل دامنه Kerberos است. اگر قرار است از نام استفاده شود، باید به همان شکل در اینجا فهرست شود.

محتوای یک قانون ساکس (socks-rule) می‌تواند شامل موارد زیر باشد:
کلاینت‌های منطبق بر این قانون، همگی مقدار پهنای باند مشخص‌شده را که بر حسب بایت بر ثانیه اندازه‌گیری می‌شود به اشتراک خواهند گذاشت. نیازمند ماژول bandwidth است.
نام سبک احراز هویت BSD مورد استفاده. پیش‌فرض این است که مقداری مشخص نشود که باعث می‌شود از سبک پیش‌فرض سیستم استفاده شود.
قانون برای دستورات داده‌شده اعمال می‌شود. دستورات معتبر عبارتند از bind، bindreply، connect، udpassociate و udpreply. می‌توان از آن به جای protocol یا برای تکمیل آن استفاده کرد. پیش‌فرض تمامی دستورات معتبر برای پروتکل‌های مجاز توسط قانون است.
قانون برای درخواست‌هایی که از آدرس داده‌شده به عنوان مقدار می‌آیند اعمال می‌شود.
کاربر باید متعلق به یکی از گروه‌هایی باشد که به عنوان مقدار داده شده است.
سرور خط را برای اجرا به libwrap ارسال می‌کند.
برای کنترل ثبت وقایع استفاده می‌شود. کلیدواژه‌های پذیرفته‌شده عبارتند از connect، disconnect، data، ioop و tcpinfo.
کنترل حداکثر تعداد نشست‌ها یا نرخ برقراری نشست. به زیر مراجعه کنید.
الزام می‌کند که اتصال با استفاده از یکی از روش‌های احراز هویت داده‌شده برقرار شود. یک method معمولاً به بخش کلاینت socks قانون اشاره دارد و بنابراین کلاینت را احراز هویت می‌کند، نه مقصد نهایی را (برای اطلاعات در مورد احراز هویت مقصد نهایی به checkreplyauth مراجعه کنید). مقادیر معتبر همان مقادیر موجود در خط سراسری socksmethod هستند.
کدام نام سرویس هنگام درگیر شدن pam استفاده شود. پیش‌فرض "sockd" است.
پارامتری برای from، to و via. کلیدواژه‌های eq/=, neq/!=, ge/>=, le/<=, gt/>, lt/< را که به دنبال آن‌ها یک عدد می‌آید می‌پذیرد. همچنین می‌توان یک محدوده پورت را به صورت "port <start #> - <end #>" مشخص کرد که با تمام شماره‌های پورت در محدوده <start #> و <end #> مطابقت خواهد داشت.

پیش‌فرض همه پورت‌ها است.

قانون برای پروتکل‌های داده‌شده اعمال می‌شود. مقادیر معتبر عبارتند از tcp و udp. پیش‌فرض تمامی پروتکل‌های پشتیبانی‌شده است که می‌توانند برای commands داده‌شده اعمال شوند.
قانون برای درخواست‌هایی که از پروتکل پروکسی داده‌شده استفاده می‌کنند اعمال می‌شود. پروتکل‌های پروکسی معتبر عبارتند از socks_v4 و socks_v5. پیش‌فرض تمامی پروتکل‌های پروکسی پشتیبانی‌شده است.
مبدأ و/یا مقصد را می‌توان با استفاده از دستور redirect تغییر مسیر داد. نیازمند ماژول redirect است.

نحو دستور redirect به صورت زیر است:

redirect from: ADDRESS

redirect to: ADDRESS

معنای from و to بر اساس command متفاوت است. برای اطلاعات دقیق به راهنمای redirect مراجعه کنید.

به گزینه سراسری timeout.connect مراجعه کنید.
به گزینه سراسری timeout.io مراجعه کنید.
به گزینه سراسری timeout.tcp_fin_wait مراجعه کنید.
قانون برای درخواست‌هایی که به آدرس داده‌شده به عنوان مقدار می‌روند یا از آن استفاده می‌کنند اعمال می‌شود. توجه داشته باشید که معنی این آدرس تحت تأثیر command قرار می‌گیرد.
آرگومان این کلیدواژه دو شماره پورت است که با یک خط تیره ('-') از هم جدا شده‌اند. آن‌ها محدوده پورت UDP را مشخص می‌کنند که بین socks-client و Dante-server برای بسته‌های UDP استفاده خواهد شد. توجه داشته باشید که این موضوع هیچ ارتباطی با محدوده پورت UDP استفاده‌شده بین Dante-server و کلاینت‌ها/سرورهای خارجی غیر ساکس ندارد.
کاربر باید با یکی از نام‌های داده‌شده به عنوان مقدار مطابقت داشته باشد. اگر هیچ مقدار user برای قانونی که به نام‌های کاربری نیاز دارد داده نشود، تأثیر آن همانند فهرست کردن تک‌تک کاربران در فایل رمز عبور خواهد بود.

کلیدواژه session را می‌توان در هر قانونی برای محدود کردن تعداد نشست‌های فعال و نرخی که با آن برقرار می‌شوند استفاده کرد. دو دستور اصلی برای این کار وجود دارد؛ session.max که حداکثر تعداد نشست‌های منطبق را کنترل می‌کند، و session.throttle که نرخ اتصال را کنترل می‌کند. این دستورات را می‌توان هم به عنوان محدودیت کل برای تمام کلاینت‌های منطبق اعمال کرد و هم می‌توان به عنوان پیش‌فرض‌های سراسری یا در هر یک از انواع قوانین تنظیم نمود. کلیدواژه session.max یک عدد مربوط به بیشترین تعداد اتصالات هم‌زمان مجاز را به عنوان آرگومان می‌پذیرد. کلیدواژه session.throttle دو عدد را که با یک علامت اسلش از هم جدا شده‌اند می‌پذیرد که اولی نشان‌دهنده تعداد اتصالات و دومی مدت زمان به ثانیه است. اگر تعداد اتصالاتی بیش از تعداد مشخص‌شده در مدت زمان تعیین‌شده دریافت شود، اتصالات اضافی رد خواهند شد.

ردیابی حالت‌مند نشست (Stateful session tracking) بر اساس هر آدرس IP نیز پشتیبانی می‌شود. برای ردیابی حالت‌مند، محدودیت‌ها برای هر اتصال با آدرس IP منطبق اعمال می‌شوند که در آن از کلیدواژه session.state.key برای کنترل نحوه تعیین آدرس IP استفاده می‌شود. در حال حاضر دو مقدار پشتیبانی می‌شوند: from و hostid. اولی باعث می‌شود محدودیت برای همه میزبان‌های دارای آدرس IP مبدأ یکسان اعمال شود و دومی برای همه اتصالات TCP با مقدار hostid یکسان. اگر از مقدار hostid استفاده شود، می‌توان از کلیدواژه session.state.key.hostindex برای انتخاب اینکه کدام یک از مقادیر hostid استفاده شود استفاده کرد، که مقدار اول پیش‌فرض است.

محدودیت‌ها ابتدا برای قوانین کلاینت، سپس برای قوانین hostid، و در نهایت برای قوانین socks ارزیابی می‌شوند. به طور پیش‌فرض، محدودیتی که در یک قانون کلاینت منطبق تنظیم شده است برای هر قانون بعدی منطبق hostid یا socks نیز استفاده خواهد شد، مگر اینکه هر یک از این قوانین خود دارای کلیدواژه‌های محدودیت نشست باشند. این ارث‌بری نشست را می‌توان در قوانین کلاینت و hostid غیرفعال کرد و باعث شد که فقط در قانونی که در آن ظاهر می‌شوند اعمال گردند. این کار با تنظیم session.inheritable روی no انجام می‌شود.

کلیدواژه‌های session باید در یک قانون (چه client، چه hostid یا socks) تنظیم شوند؛ تنظیم آن‌ها به صورت سراسری پشتیبانی نمی‌شود.

سرور Dante را می‌توان برای پایش ترافیک عبوری از آن و فعال کردن هشدارها بر اساس ترافیک شبکه مشاهده‌شده پیکربندی کرد.

هشدارها در به‌اصطلاح پایشگرها (monitors) مشخص می‌شوند. این اشیاء همان قالب کلی قوانینی را دارند که Dante برای کنترل دسترسی استفاده می‌کند و امکان پایش غیرفعال ترافیک شبکه، یا عدم وجود ترافیک شبکه را فراهم می‌سازند.

مثال زیر نحو کلی پایشگر را نشان می‌دهد که پایشگری را بدون هیچ‌گونه عملیات پایشی مشخص می‌کند:


monitor {
from: 0.0.0.0/0 to: www.example.org port = 80
protocol: tcp
}

یک پایشگر می‌تواند شامل بسیاری از همان کلیدواژه‌هایی باشد که در قوانین ACL دانته در دسترس هستند. زیرمجموعه زیر در حال حاضر پشتیبانی می‌شود:

معمولاً مشخص می‌کند چه آدرس‌ها/شبکه‌های کلاینت SOCKS باید پایش شوند.
معمولاً مشخص می‌کند چه آدرس‌ها/شبکه‌های مقصدی باید پایش شوند.
می‌تواند برای محدود کردن پایش به یک پروتکل خاص (TCP، UDP یا هر دو) استفاده شود. نکته: در حال حاضر فقط باید از TCP استفاده شود.
می‌تواند برای محدود کردن پایش فقط به کلاینت‌هایی با یک مقدار hostid خاص استفاده شود.
همراه با کلیدواژه hostid برای کنترل اینکه کدام یک از دو مقدار ممکن hostid هنگام تطابق استفاده شود، به کار می‌رود.

نکته: در حال حاضر توصیه می‌شود که کلیدواژه protocol همیشه مشخص شده و روی tcp تنظیم شود، زیرا در حال حاضر پشتیبانی محدودی از پایش ترافیک UDP وجود دارد و آزمایش پایش ترافیک UDP انجام نشده است.

عملکرد اصلی پایشگرها فراهم کردن ظرفی برای یک یا چند هشدار است که با استفاده از مجموعه جدیدی از کلیدواژه‌ها که برای سایر قوانین در دسترس نیستند مشخص می‌شوند. هشدارها شرطی را مشخص می‌کنند که در صورت وقوع آن، Dante یک پیام هشدار را در گزارش‌ها ثبت می‌کند.

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

هشدارها می‌توانند در نتیجه دوره‌هایی از عدم انتقال داده یا انتقال داده‌های بسیار کم، قطع شدن تعداد زیادی از اتصالات TCP در یک دوره زمانی کوتاه، یا به دلایل دیگر فعال شوند. برای مشاهده فهرست کاملی از شرایطی که هشدارها می‌توانند برای آن‌ها فعال شوند، به زیر مراجعه کنید.

افزودن کلیدواژه alarm.data به یک پایشگر باعث می‌شود در صورت وجود دوره‌هایی با ترافیک شبکه بسیار کم، هشدارهایی در گزارش‌ها ثبت شوند.

سرور Dante دارای چهار مسیر شبکه است و هشدارهای داده را می‌توان به طور مستقل برای هر یک از آن‌ها پیکربندی کرد:

داده‌های دریافت‌شده روی رابط داخلی Dante (داده‌های ارسال‌شده از کلاینت‌های SOCKS به Dante).
داده‌های ارسال‌شده روی رابط داخلی Dante (داده‌های ارسال‌شده از Dante به کلاینت‌های SOCKS).
داده‌های دریافت‌شده روی رابط خارجی Dante (داده‌های ارسال‌شده از سرورهای مقصد به Dante).
داده‌های ارسال‌شده روی رابط خارجی Dante (داده‌های ارسال‌شده از Dante به سرورهای مقصد).

کلیدواژه data.alarm دو پارامتر می‌گیرد: تعداد بایت و مدت زمان بر حسب ثانیه. اگر تعداد ثانیه‌های مشخص‌شده با انتقال تنها تعداد بایت مشخص‌شده (یا کمتر) سپری شود، هشدار فعال خواهد شد.

نحو به صورت زیر است:

internal.alarm.data.recv: DATALIMIT in INTERVAL

مقدار DATALIMIT عددی است که محدودیت بایت را مشخص می‌کند. INTERVAL عددی است که مدت زمان را مشخص می‌سازد. اگر در طول دوره INTERVAL ثانیه، تنها به اندازه DATALIMIT بایت (یا کمتر) منتقل شده باشد، هشداری در Dante فعال می‌شود.

هشدارهای داده زمانی فعال می‌شوند که یک دوره بی‌حرکتی داده شناسایی شود. هنگامی که یک هشدار داده فعال شد، تا زمانی که پاک شود فعال باقی می‌ماند. هنگامی که هشدار فعال می‌شود یک اخطار در گزارش‌ها ثبت می‌شود و پس از رفع وضعیت هشدار، اخطار دیگری ثبت می‌گردد. بین این دو نقطه، هیچ اخطار مربوط به این هشدار ثبت نخواهد شد. این کار از تکرار چندباره همان هشدار/اخطار در طول مشکلات شبکه‌ای که برای مدت طولانی ادامه دارند جلوگیری می‌کند. هنگامی که هشدار پاک می‌شود، Dante اطلاعاتی را نیز در مورد مدت زمان ماندگاری وضعیت هشدار درج خواهد کرد.

یک هشدار داده را می‌توان به دو روش پاک کرد: به طور خودکار، پس از اینکه داده‌های کافی در زمان به اندازه کافی کوتاه منتقل شدند، یا به صورت دستی، با ارسال یک سیگنال SIGHUP به سرور Dante. یک سیگنال SIGHUP باعث می‌شود تمام هشدارهای فعال پاک شوند. هنگامی که هشدارها به این روش پاک می‌شوند، هیچ پیام گزارشی مبنی بر پاک شدن هشدارها ثبت نخواهد شد.

هنگامی که یک هشدار پاک شد، در صورت عدم انتقال داده‌های کافی می‌تواند دوباره فعال شود.

توجه داشته باشید که هشدارهای داده صرف نظر از اینکه نشست‌های فعال منطبق با پایشگر وجود داشته باشد یا خیر فعال می‌شوند؛ اگر داده‌های کافی ارسال یا دریافت نشوند، هشدار داده فعال خواهد شد. همچنین اگر سرور Dante مدت کوتاهی پس از راه‌اندازی، ترافیک کافی برای جلوگیری از فعال شدن هشدارها دریافت نکند، هشدارها فعال خواهند شد.

توجه داشته باشید که اگر هشدار به دلیل دریافت سیگنال SIGHUP پاک شده باشد، پیامی مبنی بر پاک شدن هشدار ثبت نمی‌شود.

هشدارهای قطع اتصال مربوط به قطع اتصالات هستند و با استفاده از کلیدواژه alarm.disconnect سرور Dante می‌تواند بر اساس تعداد و نرخ اتصالات پایان‌یافته، اخطارهایی را در گزارش‌ها ثبت کند.

دو نوع کلیدواژه هشدار وجود دارد: یکی برای رابط شبکه داخلی (بین کلاینت‌های SOCKS و Dante) و دیگری برای رابط خارجی (بین سرور Dante و سرورهای مقصد):

اتصالات بین کلاینت‌های SOCKS و سرور Dante.
اتصالات بین سرور Dante و سرورهای مقصد.

هر کلیدواژه هشدار سه پارامتر می‌گیرد: حداقل تعداد، یک مقدار نسبت (ratio)، و یک بازه زمانی. از قالب زیر استفاده می‌شود:

internal.alarm.disconnect: MINCOUNT/RATIO in INTERVAL

مقدار MINCOUNT حداقل تعداد اتصالاتی است که برای فعال شدن هشدار باید قطع شوند. RATIO همراه با MINCOUNT برای بیان تعداد اتصالاتی استفاده می‌شود که نسبت به کل اتصالات موجود در آن بازه زمانی باید قطع شوند تا هشدار فعال گردد. INTERVAL زمان بر حسب ثانیه است که قطع اتصالات باید در آن رخ دهد تا هشدار فعال شود.

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

فقط اتصالاتی که روی رابط مشخص‌شده پایان می‌یابند شمرده می‌شوند؛ یعنی یک هشدار external.alarm.disconnect فقط برای اتصالاتی فعال می‌شود که روی رابط شبکه بین سرور Dante و سرور مقصد پایان یافته‌اند، چه از طریق بستن اتصال توسط سرور مقصد به Dante و چه از طریق دریافت یک خطای مهلک شبکه از آن سمت اتصال توسط Dante (مانند یک بسته TCP RST).

اتصالاتی که روی رابط داخلی (توسط کلاینت‌های SOCKS) بسته می‌شوند، در شمارش هشدار قطع اتصال در سمت خارجی محاسبه نخواهند شد. به همین ترتیب، اتصالات بسته شده توسط سرورهای مقصد در شمارش هشدار قطع اتصال در سمت داخلی به حساب نمی‌آیند.

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

هشدارها هر بار که تعداد کافی قطعی رخ دهد فعال می‌شوند. هر فوران به اندازه کافی بزرگ از قطعی‌ها منجر به یک هشدار خواهد شد، اما معمولاً در طول هر بازه زمانی حداکثر یک اخطار به ازای هر هشدار ثبت می‌شود، هرچند ممکن است این مورد در نسخه‌های بعدی Dante تغییر کند.

هنگامی که چندین هشدار در یک قانون پایشگر مشخص می‌شوند، برای هر کلیدواژه هشدار متمایز، هشدارهای جداگانه‌ای تولید می‌شود.

مسیرها با کلیدواژه route مشخص می‌شوند. درون یک جفت آکوالاد ({}) مجموعه‌ای از کلیدواژه‌ها رفتار مسیر را کنترل می‌کنند. برای توضیحات به socks.conf(5) مراجعه کنید. این قابلیت برای انجام به‌اصطلاح «زنجیره‌سازی سرورها» (server-chaining) استفاده می‌شود، که در آن یک سرور socks به سرور socks دیگری در بالادست متصل می‌شود.

نحو این مسیرها همانند مسیرهای مورد استفاده توسط کلاینت است. لطفاً برای اطلاعات در مورد نحو مسیر به socks.conf(5) مراجعه کنید.

با این حال، نکات ویژه‌ای وجود دارد که باید در مورد زنجیره‌سازی سرورها و مسیرهای مشخص‌شده برای سرور از آن‌ها آگاه بود:

در حال حاضر زنجیره‌سازی سرورها فقط برای دستور tcp connect پشتیبانی می‌شود.
اگر مسیر مشخص کند که یک روش نام کاربری/رمز عبور باید به پروکسی بالادست ارائه شود، Dante نام کاربری/رمز عبور دریافت‌شده از کلاینت خود را به پروکسی خارجی بالادست فوروارد می‌کند؛ به این معنی که پروکسی بالادست نام کاربری و رمز عبور کاربر را به صورت متن خام (cleartext) از Dante دریافت خواهد کرد.
در حال حاضر زنجیره‌سازی سرورها در Dante مقیاس‌پذیری خوبی ندارد و نباید برای مواردی غیر از بارهای کلاینتی بسیار اندک استفاده شود.

به دایرکتوری example/ در بسته توزیع نرم‌افزار مراجعه کنید.

/etc/sockd.conf   فایل پیکربندی سرور Dante.
/etc/passwd       فایل سیستمی مورد استفاده هنگام احراز هویت استاندارد نام کاربری/رمز عبور.

برای شرکت Inferno Nettverk A/S:
Michael Shuldman
Karl-Andre' Skevik

sockd(8), socks.conf(5), hosts_access(5)

اطلاعات مربوط به انتشار نسخه‌های جدید و سایر موضوعات مرتبط را می‌توانید در صفحه وب رسمی Dante بیابید: http://www.inet.no/dante/

اطلاعات مربوط به پشتیبانی تجاری را می‌توانید در صفحه پشتیبانی وب Dante بیابید: http://www.inet.no/dante/support.html

29 ژوئیه 2013 Parch Linux