TURN(1)

اطلاعات کلی (GENERAL INFORMATION)

پروژه TURN Server شامل کد منبع یک سرور TURN و کتابخانه پیام‌رسانی کلاینت TURN است. همچنین، برخی برنامه‌های اضافی صرفاً برای اهداف آزمایشی ارائه شده‌اند.

برای دستورالعمل‌های ساخت، پرونده docs/Build.md را ببینید.

پس از ساخت، تصویرهای اجرایی (binary images) زیر را خواهید داشت:

1.: turnserver: سرور رله TURN. تصویر اجرایی کامپایل‌شده برنامه TURN Server در زیرشاخه bin/ قرار دارد.
2.: turnadmin: ابزار مدیریت TURN. به README.turnadmin و صفحه راهنمای turnadmin مراجعه کنید.
3.: turnutils_uclient. به README.turnutils و صفحه راهنمای turnutils مراجعه کنید.
4.: turnutils_peer. به README.turnutils و صفحه راهنمای turnutils مراجعه کنید.
5.: turnutils_stunclient. به README.turnutils و صفحه راهنمای turnutils مراجعه کنید.
6.: turnutils_rfc5769check. به README.turnutils و صفحه راهنمای turnutils مراجعه کنید.

در زیرشاخه "examples/scripts"، نمونه‌هایی از خط فرمان‌های مورد استفاده برای اجرای برنامه‌ها را خواهید یافت. این اسکریپت‌ها برای اجرا از زیرشاخه examples/ در نظر گرفته شده‌اند، برای مثال:

$ cd examples $ ./scripts/secure_relay.sh

سیستم‌دی (SYSTEMD)

اگر کتابخانه توسعه systemd در دسترس باشد، وضعیت سرور را به systemd اطلاع می‌دهد.

اجرای سرور تِرن (RUNNING THE TURN SERVER)

برای اجرای سرور coturn به عنوان یک دیمن (daemon) استفاده کنید از:

$ turnserver -o

توجه داشته باشید که اگر تغییری در پرونده پیکربندی ایجاد کنید، سرور باید بازراه‌اندازی شود.

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

شکل کوتاه باید به این صورت استفاده شود (برای مثال):

$ turnserver -L 12.34.56.78

معادل شکل طولانی باید از نویسه "=" استفاده کند:

$ turnserver --listening-ip=12.34.56.78

اگر این یک گزینه پرچم (flag) باشد (نیازی به آرگومان نیست)، نحوه استفاده از آن‌ها یکسان است، برای مثال:

$ turnserver -a

معادل است با:

$ turnserver --lt-cred-mech

=====================================

نام (NAME)

turnserver - یک پیاده‌سازی سرور رله TURN.

خلاصه دستور (SYNOPSIS)

$ turnserver [-n | -c <config-file> ] [flags] [ --userdb=<userdb-file> | --psql-userdb=<db-conn-string> | --mysql-userdb=<db-conn-string>  | --mongo-userdb=<db-conn-string>  | --redis-userdb=<db-conn-string> ] [-z | --no-auth | -a | --lt-cred-mech ] [options]
$ turnserver -h

توضیحات (DESCRIPTION)

تنظیمات پرونده پیکربندی:

-n: از پرونده پیکربندی استفاده نکنید، فقط از پارامترهای خط فرمان استفاده کنید.
-c: نام پرونده پیکربندی (پیش‌فرض - turnserver.conf). قالب پرونده پیکربندی را می‌توان در

پرونده نمونه ارائه شده examples/etc/turnserver.conf دید. نام‌های طولانی گزینه‌ها به عنوان نام موارد پیکربندی در پرونده استفاده می‌شوند. اگر مسیر مطلقی ارائه نشده باشد، پرونده در شاخه‌های زیر جستجو می‌شود:

شاخه جاری
زیرشاخه etc/ در شاخه جاری
سطح بالاتر شاخه etc/
/etc/
/usr/local/etc/
شاخه نصب /etc

تنظیمات پایگاه داده کاربر:

-b, --db, --userdb: نام پرونده پایگاه داده کاربر SQLite (پیش‌فرض - /var/db/turndb یا /usr/local/var/db/turndb یا /var/lib/turn/turndb).

-e, --psql-userdb, --sql-userdb رشته اتصال پایگاه داده کاربر برای PostgreSQL. این پایگاه داده می‌تواند برای سازوکار اعتبارنامه‌های بلندمدت استفاده شود،

و می‌تواند مقدار محرمانه (secret) را برای احراز هویت زمان‌دار مبتنی بر سکرت در TURN REST API ذخیره کند. قالب رشته اتصال به این شکل است:

"host=<host> dbname=<dbname> user=<db-user> password=<db-user-password> connect_timeout=<seconds>" (برای Postgres نسخه 8.x یا جدیدتر).

یا:

"postgresql://username:password@hostname:port/databasename" (برای Postgres نسخه 9.x یا جدیدتر).

برای توضیحات و نمونه‌های بیشتر، پرونده docs/PostgreSQL.md را ببینید.

همچنین، برای مستندات کامل PostgreSQL به http://www.PostgreSQL.org مراجعه کنید.

-M, --mysql-userdb: رشته اتصال پایگاه داده کاربر برای MySQL یا MariaDB. این پایگاه داده می‌تواند برای سازوکار اعتبارنامه‌های بلندمدت استفاده شود،

"host=<host> dbname=<dbname> user=<db-user> password=<db-user-password> connect_timeout=<seconds> read_timeout=<seconds>"

برای توضیحات و نمونه‌های بیشتر، پرونده docs/MySQL.md را ببینید.

همچنین، برای مستندات کامل MySQL به http://www.mysql.org یا http://mariadb.org مراجعه کنید.

پارامترهای اختیاری رشته اتصال برای ارتباطات امن (SSL): ca, capath, cert, key, cipher (برای توضیح گزینه‌های دستور http://dev.mysql.com/doc/refman/5.1/en/ssl-options.html را ببینید).

--secret-key-file: این مسیر فایلی است که حاوی کلید محرمانه رمزنگاری aes هنگام استفاده از رمزنگاری گذرواژه MySQL است. اگر می‌خواهید در رشته اتصال MySQL از گذرواژه به شکل رمزنگاری‌شده استفاده کنید،

در این گزینه مسیر فایل کلید محرمانه را مشخص کنید. کلیدی که برای رمزنگاری گذرواژه MySQL استفاده می‌شود. هشدار: اگر این گزینه تنظیم شود، گذرواژه MySQL باید در گزینه "mysql-userdb" به شکل رمزنگاری‌شده مشخص شود! اگر می‌خواهید از گذرواژه متنی ساده (cleartext) استفاده کنید این گزینه را مشخص نکنید!

-J, --mongo-userdb: رشته اتصال پایگاه داده کاربر برای MongoDB. این پایگاه داده می‌تواند برای سازوکار اعتبارنامه‌های بلندمدت استفاده شود،

"mongodb://username:password@host:port/database?options"

برای توضیحات و نمونه‌های بیشتر، پرونده docs/Mongo.md را ببینید.

همچنین، برای مستندات کامل MongoDB به http://docs.mongodb.org/manual/ مراجعه کنید.

-N, --redis-userdb: رشته اتصال به پایگاه‌داده کاربر برای Redis. از این پایگاه‌داده می‌توان برای سازوکار اطلاعات کاربری بلندمدت (long-term credentials) استفاده کرد،

و می‌تواند مقدار رمز (secret) را برای احراز هویت زمان‌بندی‌شده مبتنی بر رمز در TURN REST API ذخیره کند. قالب رشته اتصال به این صورت است:

"ip=<ip-addr> dbname=<db-number> password=<db-password> connect_timeout=<seconds>"

اگر کارساز TURN با پشتیبانی از hiredis_ssl ساخته شده باشد، می‌توان یک انتقال TLS را با افزودن "tls=true" به همراه یک فایل CA معمول درخواست کرد: "... tls=true ca=<ca-cert-file>". راستی‌آزمایی گواهی کارساز به طور پیش‌فرض فعال است؛ برای فهرست کامل کلیدهای TLS (شامل ca، capath، cert، clientkey، sni و verify) و مثال‌ها، فایل docs/Redis.md را ببینید.

برای توضیحات بیشتر و مثال‌ها فایل docs/Redis.md را ببینید.

همچنین برای مستندات کامل Redis به http://redis.io مراجعه کنید.

پرچم‌ها (Flags):

-v, --verbose: حالت پرگویی ملایم (Moderate verbose).
-V, --Verbose: حالت پرگویی مضاعف، بسیار آزاردهنده و توصیه نمی‌شود.
-o, --daemon: اجرای کارساز به عنوان دیمن (daemon).

--no-software-attribute منسوخ شده است (DEPRECATED). گزینه "--software-attribute" را ببینید.

--software-attribute: ارسال SOFTWARE_ATTRIBUTE روی پیام‌هایی که امکان داشتن آن را دارند. به طور پیش‌فرض غیرفعال است. معادل گزینه منسوخ‌شده "--no-software-attribute false"; است.

-f, --fingerprint: استفاده از اثر انگشت (fingerprints) در پیام‌های TURN. اگر یک درخواست دریافتی شامل اثر انگشت باشد، کارساز TURN همواره اثر انگشت را به پیام‌های این نشست

اضافه خواهد کرد، صرف‌نظر از تنظیمات به‌ازای‌هرکارساز (per-server).

--include-reason-string گنجاندن رشته‌های توضیحی علت در پاسخ‌های خطای STUN/TURN. به‌طور پیش‌فرض، فقط عبارت استاندارد علت برای کد خطا

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

-a, --lt-cred-mech: استفاده از سازوکار اطلاعات کاربری بلندمدت (long-term credentials) (این گزینه برای کاربرد WebRTC مورد نیاز است).
-z, --no-auth: عدم استفاده از هرگونه سازوکار اطلاعات کاربری، مجاز شمردن دسترسی ناشناس. نقطه مقابل گزینه‌های -a و -A. زمانی که هیچ گزینه‌ای در رابطه با

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

--use-auth-secret: پرچم TURN REST API. پرچمی که یک گزینه ویژه مجوز WebRTC را تعیین می‌کند

که مبتنی بر رمز احراز هویت است. هدف این قابلیت، پشتیبانی از "TURN Server REST API" مطابق توضیحات بخش TURN REST API در ادامه است. این گزینه از برچسب زمان (timestamp) به عنوان بخشی از نام کاربری ترکیبی استفاده می‌کند: usercombo -> "timestamp:username", turn user -> usercombo, turn password -> base64(hmac(input_buffer = usercombo, key = shared-secret)). این امر امکان محاسبه اعتبارنامه‌های TURN را برای یک شناسه کاربر مشخص فراهم می‌کند. اگر شناسه مناسبی ندارید، برچسب زمان به تنهایی می‌تواند استفاده شود. این گزینه تنها احراز هویت مبتنی بر رمز را فعال می‌کند. مقدار واقعی رمز یا توسط گزینه static-auth-secret تعریف می‌شود، یا می‌تواند در جدول turn_secret در پایگاه‌داده یافت شود.

--oauth: پشتیبانی از احراز هویت oAuth، مطابق استاندارد شخص ثالث RFC 7635 برای STUN/TURN.
--dh566: استفاده از کلید از پیش‌تعریف‌شده ۵۶۶ بیتی DH TLS. اندازه پیش‌فرض کلید ۲۰۶۶ است.
--dh1066: استفاده از کلید از پیش‌تعریف‌شده ۱۰۶۶ بیتی DH TLS. اندازه پیش‌فرض کلید ۲۰۶۶ است.
--tlsv1: تنظیم TLSv1 به عنوان حداقل نسخه پشتیبانی‌شده پروتکل.
--tlsv1_1: تنظیم TLSv1.1 به عنوان حداقل نسخه پشتیبانی‌شده پروتکل.
--no-tlsv1_2: تنظیم TLSv1.3/DTLSv1.2 به عنوان حداقل نسخه پشتیبانی‌شده پروتکل.
--no-udp: عدم راه‌اندازی شنوندگان سرویس‌گیرنده UDP.
--no-tcp: عدم راه‌اندازی شنوندگان سرویس‌گیرنده TCP.
--no-tls: عدم راه‌اندازی شنوندگان سرویس‌گیرنده TLS.
--no-dtls: عدم راه‌اندازی شنوندگان سرویس‌گیرنده DTLS.
--no-udp-relay: عدم اجازه به نقاط پایانی بازپخش UDP تعریف‌شده در RFC 5766، تنها استفاده از نقاط پایانی بازپخش TCP تعریف‌شده در RFC 6062.

--no-tcp-relay: عدم اجازه به نقاط پایانی بازپخش TCP تعریف‌شده در RFC 6062، تنها استفاده از نقاط پایانی بازپخش UDP تعریف‌شده در RFC 5766.

--no-stdout-log: پرچم برای جلوگیری از پیام‌های گزارش stdout. به‌طور پیش‌فرض، تمام پیام‌های گزارش هم به stdout و هم به

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

--syslog: با این پرچم، تمام گزارش‌ها به گزارش سامانه (syslog) هدایت می‌شوند.
--syslog-facility: <value> تنظیم تسهیلات syslog برای پیام‌های syslog. مقدار پیش‌فرض '' است.
--simple-log: این پرچم به این معنی است که هیچ چرخش فایل گزارشی صورت نخواهد گرفت، و نام فایل گزارش همان‌گونه که هست، بدون اضافه شدن PID و تاریخ ساخته خواهد شد.

این گزینه می‌تواند برای مثال همراه با ابزار logrotate استفاده شود.

--log-min-level: <level> تنها ثبت پیام‌های گزارش در این سطح یا بالاتر. سطوح معتبر، از پرگوترین تا کم‌گوترین: debug (همه‌چیز؛ پیش‌فرض)، info، warning، error (تنها خطاها). یک سطح ناشناخته با یک هشدار نادیده گرفته می‌شود.
--new-log-timestamp: فعال‌سازی برچسب زمانی کامل ISO-8601 در تمام گزارش‌ها.
--new-log-timestamp-format: <format> تنظیم قالب برچسب زمانی (در قالب strftime(1))
--log-binding: ثبت درخواست پیوند (binding) در STUN. اکنون برای جلوگیری از حملات DoS به طور پیش‌فرض غیرفعال است.
--secure-stun: الزام به احراز هویت برای درخواست STUN Binding. به‌طور پیش‌فرض، کلاینت‌ها اجازه دسترسی ناشناس به قابلیت STUN Binding را دارند.

-S, --stun-only: اجرا تنها به عنوان سرور STUN؛ تمام درخواست‌های TURN نادیده گرفته خواهند شد. گزینه‌ای برای غیرفعال‌سازی قابلیت TURN، تنها درخواست‌های STUN پردازش خواهند شد.

--no-stun: اجرا تنها به عنوان سرور TURN؛ تمام درخواست‌های STUN نادیده گرفته خواهند شد. گزینه‌ای برای غیرفعال‌سازی قابلیت STUN، تنها درخواست‌های TURN پردازش خواهند شد.

--allow-loopback-peers: اجازه دادن به همتایان روی نشانی‌های لوپ‌بک (127.x.x.x و ::1). تنها برای آزمایش در محیط توسعه مجاز است!

در محیط عملیاتی این گزینه یک آسیب‌پذیری امنیتی احتمالی ایجاد می‌کند، و به همین دلیل به دلایل امنیتی، استفاده از آن به همراه cli-password خالی مجاز نیست.

--no-multicast-peers: عدم اجازه به همتایان روی نشانی‌های برودکست شناخته‌شده (224.0.0.0 و بالاتر، و *:FFXX).

--mobility: پشتیبانی از مشخصات پویایی با MICE) ICE).
--cli: فعال‌سازی پشتیبانی از CLI. به‌طور پیش‌فرض همواره خاموش است. همچنین گزینه‌های --cli-ip و --cli-port را ببینید.

--no-cli: غیرفعال‌سازی پشتیبانی از CLI. از آنجا که CLI به‌طور پیش‌فرض خاموش است، این پرچم تنها برای لغو تنظیم "cli" از

فایل پیکربندی مفید است.

--server-relay: رله سرور. گزینه‌ای غیر استاندارد و خطرناک. تنها برای برنامه‌هایی که می‌خواهیم برنامه‌های

سرور را روی نقاط پایانی رله اجرا کنیم. این گزینه بررسی مجوزهای IP را روی بسته‌های ورودی به نقاط پایانی رله حذف می‌کند. ببینید: http://tools.ietf.org/search/rfc5766#section-17.2.3 .

--udp-self-balance: (تنها برای لینوکس‌های قدیمی‌تر توصیه می‌شود) توزیع بار خودکار ترافیک UDP روی سرورهای کمکی

(در صورت پیکربندی). این توزیع بار از سازوکار ALTERNATE-SERVER استفاده می‌کند. کلاینت TURN باید از پاسخ 300 ALTERNATE-SERVER برای این قابلیت پشتیبانی کند.

--check-origin-consistency: پرچمی که بررسی سازگاری مبدا (origin consistency) را تنظیم می‌کند: در طول نشست، همه درخواست‌ها باید دارای یک مقدار

مشخصه اصلی ORIGIN باشند (اگر ORIGIN در ابتدا توسط نشست استفاده شده باشد).

--drop-invalid-packets: دور انداختن زودهنگام بسته‌های نامعتبر. به‌طور پیش‌فرض فعال است.
--drop-invalid-packets-log: ثبت لاگ بسته‌های نامعتبر. رفتار پیش‌فرض ثبت نکردن بسته‌های نامعتبر است.
--udp-recvmmsg: دریافت دسته‌ای UDP ویژه لینوکس از طریق ()recvmmsg روی سوکت‌های اشتراکی fan-in (شنونده کلاینت و، با --multiplex-peer، سوکت رله به‌ازای هر ترد). به‌طور پیش‌فرض در لینوکس فعال است؛ مقدار false=--udp-recvmmsg

(یا 0=) را برای غیرفعال‌سازی ارسال کنید.

--udp-recvmmsg-log: ثبت لاگ آمار اشغال دسته‌ای recvmmsg در لینوکس هر ۱۰ ثانیه.
--udp-gso: فعال‌سازی Linux UDP-GSO (پیام کمکی UDP_SEGMENT cmsg) در مسیر ارسال رله. هنگامی که یک دسته sendmmsg دارای مقصد و اندازه بخش یکسان باشد، یک

پیمایش پشته شبکه، N دیتاگرام را منتقل می‌کند. نیازمند --multiplex-peer است (که دسته‌بندی sendmmsg را که GSO روی آن سوار می‌شود فعال می‌کند)؛ ارسال --udp-gso به تنهایی یک دستور بی‌اثر (no-op) خاموش است.

--multiplex-peer: ویژه لینوکس. فعال‌سازی حالت رله چندتایی سمت همتا (غیر استاندارد، اختیاری). جایگزینی بایند پورت رله به‌ازای

هر تخصیص با یک جفت سوکت UDP اشتراکی برای هر ترد رله (یک IPv4، یک IPv6) که تمام نشست‌های TURN روی آن ترد را پوشش می‌دهد؛ نشست‌ها از طریق جستجوی دقیق IP:port همتا تفکیک (demultiplex) می‌شوند. سقف تخصیص حدود ۱۶ هزارتایی ناشی از محدوده پورت رله را برمی‌دارد و ریزش‌های rcvbuf لایه UDP سمت کرمل را به‌شدت کاهش می‌دهد. متضمن دسته‌بندی sendmmsg است؛ --udp-recvmmsg (به‌طور پیش‌فرض روشن) پنجره recvmmsg را فراهم می‌کند که دسته‌بندی روی آن سوار می‌شود. نکته: درخواست‌های تخصیص EVEN-PORT در این حالت با کد ۴۰۰ رد می‌شوند؛ کلاینت‌هایی که به EVEN-PORT نیاز دارند باید از مسیر قدیمی استفاده کنند. برای طراحی و مزایا/معایب docs/multiplex-peer.md را ببینید.

--multiplex-peer-port <port>: ویژه لینوکس. پورت پایه UDP برای سوکت‌های رله multiplex-peer (پیش‌فرض: 3480، محدوده معتبر ۱-۶۵۰۰۰). ترد i به

<base>+2i (IPv4) و <base>+2i+1 (IPv6) بایند می‌شود؛ یک سرور با ۴ ترد، پورت‌های <base>..<base>+7 را مصرف می‌کند. کل پورت‌های مصرف‌شده = relay_threads * 2.

--respond-http-unsupported: بازگرداندن پاسخ HTTP با کد وضعیت ۴۰۰ به اتصالات HTTP برقرار شده با پورت‌هایی که از HTTP پشتیبانی نمی‌کنند. رفتار پیش‌فرض

بستن فوری اتصال است.

--prometheus: فعال‌سازی معیارهای پرومتئوس. به‌طور پیش‌فرض غیرفعال است. روی پورت 9641 تحت مسیر metrics/ گوش فرا می‌دهد،

همچنین مسیر / روی این پورت می‌تواند به عنوان بررسی سلامت (health check) استفاده شود. در نصب‌های apt در دسترس نیست.

--prometheus-username-labels: فعال‌سازی برچسب‌گذاری معیارهای ترافیک پرومتئوس با نام‌های کاربری کلاینت. برچسب‌گذاری با نام‌های کاربری کلاینت

به‌طور پیش‌فرض غیرفعال است، زیرا این کار ممکن است در صورت احراز هویت با نام‌های کاربری گذرا (مانند TURN REST API) باعث نشت حافظه شود.

--prometheus-port: پورت شنونده پرومتئوس (پیش‌فرض: 9641).
--prometheus-address: <address> نشانی شنود پرومتئوس (پیش‌فرض: any).
--prometheus-path: <path> مسیر ارائه پرومتئوس (پیش‌فرض: /metrics).
--version: چاپ نسخه و خروج.
-h: راهنما.

گزینه‌های دارای مقدار (Options with values):

--stale-nonce[=<value>]: استفاده از امنیت بیشتر با مقدار نانس (nonce) دارای طول عمر محدود، بر حسب ثانیه (پیش‌فرض ۶۰۰ ثانیه).

برای طول عمر نامحدود نانس، آن را روی 0 تنظیم کنید.

--max-allocate-lifetime: تنظیم بیشینه مقدار طول عمر تخصیص (allocation). پیش‌فرض ۳۶۰۰ ثانیه.

--channel-lifetime: تنظیم طول عمر پیوند کانال (channel binding)، پیش‌فرض ۶۰۰ ثانیه. این مقدار برای مصارف عملیاتی نباید تغییر کند.

--permission-lifetime: تنظیم مقدار برای طول عمر مجوز (permission). پیش‌فرض ۳۰۰ ثانیه.

این مقدار برای مصارف عملیاتی نباید تغییر کند.

-d, --listening-device: دستگاه رابط شنونده (listener interface device). (توصیه نمی‌شود. قابلیت اختیاری، فقط لینوکس).

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

-L, --listening-ip: نشانی IP شنونده سرور رله. می‌توان چندین شنونده را مشخص کرد، برای نمونه:

-L ip1 -L ip2 -L ip3 اگر نشانی‌های IP مشخص نشوند، از تمام IPهای IPv4 و IPv6 سیستم برای شنود استفاده خواهد شد. از همان IP(ها) می‌توان هم به عنوان IP(های) شنود و هم IP(های) رله استفاده کرد.

-p, --listening-port: درگاه شنونده TURN برای شنونده‌های UDP و TCP (پیش‌فرض: ۳۴۷۸). نکته: در عمل، نشست‌های TLS و DTLS می‌توانند به درگاه(های) TCP و UDP

«ساده» نیز متصل شوند - در صورتی که توسط پیکربندی مجاز باشد.

--tls-listening-port: درگاه شنونده TURN برای شنونده‌های TLS و DTLS (پیش‌فرض: ۵۳۴۹). نکته: در عمل، نشست‌های TCP و UDP «ساده» می‌توانند به درگاه(های) TLS و DTLS

نیز متصل شوند - در صورتی که توسط پیکربندی مجاز باشد. سرور TURN «به طور خودکار» نوع ترافیک را تشخیص می‌دهد. در واقع، دو نقطه پایانی شنود (نقطه پایانی «ساده» و نقطه پایانی «tls») از نظر عملکردی معادل هستند؛ اما هر دو نقطه پایانی را برای برآورده کردن مشخصات RFC 5766 حفظ می‌کنیم. برای اتصال‌های امن TCP، در حال حاضر از SSL نسخه ۳ و TLS نسخه‌های 1.0، 1.1، 1.2 پشتیبانی می‌شود. برای اتصال‌های امن UDP، از DTLS نسخه ۱ پشتیبانی می‌شود.

--alt-listening-port: درگاه شنود جایگزین برای شنونده‌های UDP و TCP؛ مقدار پیش‌فرض (یا صفر) به معنای «درگاه شنود به علاوه یک» است.

این مورد برای STUN CHANGE_REQUEST - به مفهوم RFC 5780 یا به مفهوم قدیمی RFC 3489 - جهت کشف رفتار NAT مورد نیاز است. سرور TURN تنها در صورتی از CHANGE_REQUEST پشتیبانی می‌کند که با بیش از یک نشانی IP شنود از همان خانواده (IPv4 یا IPv6) اجرا شود. CHANGE_REQUEST تنها توسط پروتکل UDP پشتیبانی می‌شود؛ پروتکل‌های دیگر تنها برای «تقارن» روی آن نقطه پایانی شنود می‌کنند.

--alt-tls-listening-port: درگاه شنود جایگزین برای پروتکل‌های TLS و DTLS. مقدار پیش‌فرض (یا صفر) به معنای «درگاه شنود TLS به علاوه یک» است.

--tcp-proxy-port: پشتیبانی از اتصال‌های توزیع‌کننده بار TCP روی این درگاه. توزیع‌کننده بار باید از پروتکل دودویی proxy استفاده کند.

(https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)

--aux-server: نقطه پایانی شنود سرور کمکی STUN/TURN (Auxiliary STUN/TURN server). سرورهای کمکی تقریباً از تمام قابلیت‌های TURN و STUN برخوردارند.

محدودیت‌های (جزئی) عبارتند از:

1): سرورهای کمکی درگاه‌های جایگزین ندارند و از قابلیت‌های STUN RFC 5780 پشتیبانی نمی‌کنند (CHANGE REQUEST).
2): سرورهای کمکی همچنین هیچ‌گاه پاسخ ALTERNATIVE-SERVER بازنمی‌گردانند.
قالب‌های معتبر عبارتند از 1.2.3.4:5555 برای IPv4 و [1:2::3:4]:5555 برای IPv6. ممکن است چندین گزینه aux-server وجود داشته باشد، که هر یک برای شنود به درخواست‌های کلاینت استفاده خواهد شد.

-i, --relay-device: دستگاه رابط رله برای سوکت‌های رله (توصیه نمی‌شود. اختیاری، فقط لینوکس).

-E, --relay-ip: نشانی رله (نشانی IP محلی که برای بازپخش بسته‌ها به

همتا استفاده خواهد شد). چندین نشانی رله را می‌توان استفاده کرد: -E ip1 -E ip2 -E ip3 از همان IP(ها) می‌توان هم به عنوان IP(های) شنود و هم IP(های) رله استفاده کرد. اگر هیچ IP رله‌ای مشخص نشود، turnserver سیاست پیش‌فرض را اعمال می‌کند: خود تصمیم می‌گیرد که کدام نشانی‌های رله استفاده شوند، و همواره از نشانی IP سوکت کلاینت به عنوان نشانی IP رله نشست TURN استفاده خواهد کرد (در صورتی که خانواده نشانی رله درخواستی با خانواده سوکت کلاینت یکسان باشد).

-X, --external-ip: نگاشت نشانی عمومی/خصوصی سرور TURN، در صورتی که سرور پشت NAT قرار دارد. در این شرایط، اگر -X به فرم "-X <ip>" استفاده شود، آن نشانی IP به عنوان

نشانی IP رله تمام تخصیص‌ها گزارش خواهد شد. این سناریو تنها در حالتی ساده کار می‌کند که یک نشانی رله منفرد استفاده شود و نیازی به قابلیت CHANGE_REQUEST نباشد. آن نشانی رله یکتا باید توسط NAT به IP «خارجی» نگاشت شود. مقدار "external-ip"، در صورت خالی نبودن، در فیلد XOR-RELAYED-ADDRESS بازگردانده می‌شود. برای آن IP «خارجی»، NAT باید درگاه‌ها را مستقیماً هدایت کند (درگاه رله‌شده ۱۲۳۴۵ همواره باید به همان درگاه «خارجی» ۱۲۳۴۵ نگاشت شود). در حالت‌های پیچیده‌تر که بیش از یک نشانی IP درگیر است، این گزینه باید چند بار استفاده شود، و هر مدخل باید دارای فرم "-X <public-ip/private-ip>" باشد تا تمامی نشانی‌های درگیر نگاشت شوند. قابلیت کشف NAT در STUN با CHANGE_REQUEST (RFC5780 یا RFC3489) در صورت نگاشت صحیح نشانی‌ها، حتی هنگامی که خود سرور TURN پشت یک NAT باشد، به درستی کار خواهد کرد. به طور پیش‌فرض، این مقدار خالی است و هیچ نگاشت نشانی‌ای استفاده نمی‌شود.

-m, --relay-threads: تعداد ریسه‌های رله برای مدیریت اتصال‌های برقرارشده (علاوه بر ریسه احراز هویت و ریسه شنونده).

اگر به طور صریح روی 0 تنظیم شود، برنامه فرایند رله را در یک ریسه واحد اجرا می‌کند، در همان ریسه مشترک با فرایند شنونده (ریسه احراز هویت همچنان یک ریسه مجزا خواهد بود). اگر تنظیم نشود، یک الگوریتم بهینه پیش‌فرض به کار گرفته خواهد شد (وابسته به سیستم‌عامل). در سیستم‌های لینوکس قدیمی‌تر (پیش از کرنل لینوکس 3.9)، تعداد ریسه‌های UDP همواره یک ریسه به ازای هر نقطه پایانی شنود شبکه است - مگر اینکه "-m 0"; یا "-m 1"; تنظیم شود.

--cpus: <number> بازنویسی تشخیص تعداد CPU سیستم. استفاده از این عدد به جای تعداد CPU شناسایی‌شده خودکار. مفید در محیط‌های مجازی‌سازی‌شده

یا کانتینری که در آن‌ها تعداد CPU قابل رویت با آنچه cgroup واقعاً اجازه می‌دهد مطابقت ندارد.

--min-port: حد پایین بازه درگاه UDP برای تخصیص نقاط پایانی بازپخش (relay endpoints).

مقدار پیش‌فرض بر اساس RFC 5766 برابر 49152 است.

--max-port: حد بالای بازه درگاه UDP برای تخصیص نقاط پایانی بازپخش (relay endpoints).

مقدار پیش‌فرض بر اساس RFC 5766 برابر 65535 است.

--sock-buf-size: تنظیم اندازه بافر سوکت به یک مقدار جدید (به بایت).
-u, --user: حساب کاربری اعتبارنامه‌های سازوکار امنیتی بلندمدت، به صورت جداشده با دو‌نقطه در قالب username:key.

می‌توان از چندین حساب کاربری در خط فرمان استفاده کرد. کلید یا همان گذرواژه کاربر است، یا کلیدی است که توسط دستور turnadmin تولید شده است. در حالت دوم، کلید باید با نمادهای 0x پیشوندگذاری شود. کلید بر روی نام کاربر، حوزه (realm) کاربر و گذرواژه کاربر محاسبه می‌شود. این تنظیم نباید همراه با TURN REST API استفاده شود.

-r, --realm: حوزه (realm) پیش‌فرض مورد استفاده برای کاربران هنگامی که هیچ رابطه صریح مبدأ/حوزه در پایگاه داده یافت نشود، یا اگر کارساز TURN

از هیچ پایگاه داده‌ای استفاده نکند (تنها تنظیمات خط فرمان و پرونده userdb). باید به همراه سازوکار اعتبارنامه‌های بلندمدت یا با TURN REST API استفاده شود.

-C, --rest-api-separator: نماد (نویسه) جداکننده مهرزمانی/نام‌کاربری در TURN REST API. مقدار پیش‌فرض : است.

-q, --user-quota: سهمیه تخصیص‌های به‌ازای هر کاربر: تعداد تخصیص‌های همزمانی که یک کاربر می‌تواند ایجاد کند. این گزینه همچنین می‌تواند

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

-Q, --total-quota: سهمیه کل تخصیص‌ها: محدودیت سراسری روی تخصیص‌های همزمان. این گزینه همچنین می‌تواند از طریق پایگاه داده برای یک حوزه مشخص تنظیم شود.

-s, --max-bps: حداکثر پهنای باند بایت‌برثانیه که یک نشست TURN مجاز به مدیریت آن است (جریان‌های شبکه ورودی و خروجی جداگانه مدیریت می‌شوند). هر چیزی بیش از

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

-B, --bps-capacity: حداکثر ظرفیت کارساز. مجموع پهنای باند بایت‌برثانیه که کارساز TURN مجاز است برای

نشست‌ها تخصیص دهد، در مجموع (جریان‌های شبکه ورودی و خروجی جداگانه مدیریت می‌شوند).

--static-auth-secret: مقدار راز احراز هویت ایستا (یک رشته) تنها برای TURN REST API. اگر تنظیم نشود، کارساز turn تلاش خواهد کرد تا از مقدار پویا

در جدول turn_secret در پایگاه داده کاربران (در صورت وجود) استفاده کند. مقدار ذخیره‌شده در پایگاه داده می‌تواند در حین اجرا توسط برنامه‌ای مجزا تغییر کند، به همین دلیل آن حالت دیگر پویا است. می‌توان از چندین راز مشترک استفاده کرد (هم در پایگاه داده و هم به صورت "ایستا").

--no-auth-pings: غیرفعال‌سازی بررسی‌های سلامت دوره‌ای جدول‌های راز احراز هویت «پویا».
--no-dynamic-ip-list: عدم استفاده از فهرست پویای نشانی‌های IP همتای مجاز/غیرمجاز.
--no-dynamic-realms: عدم استفاده از تخصیص پویا و گزینه‌های حوزه (realm).
--server-name: نام کارساز مورد استفاده برای اهداف احراز هویت oAuth.

مقدار پیش‌فرض، نام حوزه (realm) است.

--cert: پرونده گواهی، با قالب PEM. همان قواعد جستجوی پرونده که برای پرونده پیکربندی به کار می‌رود در اینجا نیز اعمال

می‌شود. اگر هر دو گزینه --no-tls و --no-dtls مشخص شده باشند، این پارامتر لازم نیست. مقدار پیش‌فرض turn_server_cert.pem است.

--pkey: پرونده کلید خصوصی، با قالب PEM. همان قواعد جستجوی پرونده که برای پرونده پیکربندی به کار می‌رود در اینجا نیز اعمال

می‌شود. اگر هر دو گزینه --no-tls و --no-dtls مشخص شده باشند، این پارامتر لازم نیست. مقدار پیش‌فرض turn_server_pkey.pem است.

--raw-public-keys: پشتیبانی از کلیدهای عمومی خام (Raw public keys). کلید روشن/خاموش برای RFC-7250 موسوم به کلیدهای عمومی خام.

نرم‌افزار Coturn باید در برابر OpenSSL نسخه حداقل 3.2.1 ساخته شده باشد.

--pkey-pwd: اگر پرونده کلید خصوصی رمزنگاری شده باشد، این گذرواژه استفاده می‌شود.
--cipher-list: فهرست رمزهای مجاز OpenSSL برای اتصالات TLS/DTLS. مقدار پیش‌فرض برای نسخه‌های TLS/DTLS تا TLSv1.2/DTLSv1.2 برابر "DEFAULT" است،

و برای TLSv1.3 مجموعه‌های رمزنگاری پیش‌فرض کتابخانه است.

--CA-file: پرونده CA در قالب OpenSSL. کارساز TURN را ملزم به تأیید گواهی‌های SSL کلاینت می‌کند.

به‌طور پیش‌فرض، هیچ CA تنظیم نشده و هیچ بررسی گواهی کلاینتی انجام نمی‌شود.

--ec-curve-name: نام خم برای رمزهای EC، در صورت پشتیبانی توسط کتابخانه OpenSSL (در TLS و DTLS). در صورتی که نسخه قبل از OpenSSL 1.0.2

استفاده شود مقدار پیش‌فرض prime256v1 است. در OpenSSL 1.0.2+، اگر با این گزینه تعریف نشود، یک خم بهینه به صورت خودکار محاسبه خواهد شد.

--dh-file: استفاده از کلید سفارشی DH TLS، ذخیره‌شده با قالب PEM در پرونده. پرچم‌های --dh566 و --dh1066 هنگامی که کلید DH از یک پرونده گرفته شود نادیده گرفته می‌شوند.

-l, --log-file: گزینه تنظیم مسیر کامل پرونده گزارش (log file). به‌طور پیش‌فرض، turnserver تلاش می‌کند پرونده گزارش را در شاخه‌های

/var/log/turnserver، /var/log، /var/tmp، /tmp و . (جاری) باز کند (هر عملیات باز کردن پرونده که نخست موفق شود، همان پرونده استفاده خواهد شد). با این گزینه می‌توانید نام قطعی پرونده گزارش را تنظیم کنید. نام‌های ویژه "stdout" و "-" هستند - آن‌ها همه‌چیز را به خروجی استاندارد (stdout) می‌فرستند. همچنین، نام "syslog" همه‌چیز را به گزارش سیستم (syslog) هدایت می‌کند، گویی گزینه "--syslog" تنظیم شده است. در زمان اجرا، پرونده گزارش را می‌توان با سیگنال SIGHUP به فرایند turnserver بازنشانی کرد.

--alternate-server: گزینه تنظیم حالت "تغییر مسیر" (redirection). مقدار این گزینه نشانی کارساز جایگزین برای سرویس UDP و TCP به شکل

<ip>[:<port>] خواهد بود. کارساز این مقدار را در صفت ALTERNATE-SERVER همراه با خطای ۳۰۰ در پاسخ به درخواست ALLOCATE به کارگیر ارسال می‌کند. کارگیر تنها مقادیری با همان خانواده نشانی (address family) نقطه پایانی شبکه کارگیر را دریافت خواهد کرد. برای شرح عملکرد ALTERNATE-SERVER به RFC 5389 و RFC 5766 مراجعه کنید. کارگیر باید مقدار به‌دست‌آمده را برای ارتباطات بعدی TURN استفاده کند. اگر بیش از یک گزینه --alternate-server ارائه شود، عملکرد حاصل را می‌توان به جای صرفاً "تغییر مسیر"، دقیق‌تر به عنوان "توازن بار" (load-balancing) توصیف کرد. در صورت حذف شماره درگاه (port)، شماره درگاه پیش‌فرض ۳۴۷۸ برای پروتکل‌های UDP/TCP استفاده خواهد شد. نویسه‌های دونقطه (:) در نشانی‌های IPv6 ممکن است با ساختار نوشتاری گزینه تداخل داشته باشد. برای رفع این تداخل، نشانی‌های تحت‌اللفظی IPv6 در چنین شناسه‌های منبعی درون قلاب‌ها (کروشه‌ها) قرار می‌گیرند، برای نمونه: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:3478 . می‌توان چندین کارساز جایگزین تعیین کرد. آن‌ها به شیوه نوبت‌گردشی (round-robin) به کار گرفته می‌شوند. همه کارسازها در استخر دارای وزن برابر در نظر گرفته می‌شوند و بار به‌طور مساوی توزیع خواهد شد. برای نمونه، اگر ۴ کارساز جایگزین داشته باشیم، هر کارساز ۲۵٪ از درخواست‌های ALLOCATE را دریافت می‌کند. نشانی یک کارساز جایگزین TURN را می‌توان بیش از یک بار با گزینه alternate-server به کار برد، بنابراین می‌توان "وزن‌دهی" به کارسازها را شبیه‌سازی کرد.

--tls-alternate-server: گزینه تنظیم کارساز جایگزین برای سرویس‌های TLS و DTLS به شکل <ip>:<port>. در صورت حذف شماره درگاه، درگاه پیش‌فرض

شماره ۵۳۴۹ برای پروتکل‌های TLS/DTLS استفاده خواهد شد. برای شرح عملکرد به گزینه پیشین مراجعه کنید.

-O, --redis-statsdb: رشته اتصال به پایگاه‌داده وضعیت و آمار Redis در صورت استفاده (پیش‌فرض - خالی، هیچ پایگاه‌داده آمار Redis استفاده نمی‌شود). این پایگاه‌داده اطلاعات وضعیت تخصیص‌ها را نگه می‌دارد، و می‌تواند

همچنین برای انتشار و تحویل اعلان‌های رویداد تخصیص و ترافیک استفاده شود. این گزینه پایگاه‌داده می‌تواند مستقل از گزینه --redis-userdb استفاده شود، و در عمل می‌توان از Redis برای وضعیت/آمار و از SQLite یا MySQL یا MongoDB یا PostgreSQL برای پایگاه‌داده کاربران استفاده کرد. رشته اتصال دارای همان پارامترهای رشته اتصال redis-userdb است.

--max-allocate-timeout: حداکثر زمان، بر حسب ثانیه، مجاز برای برقراری کامل تخصیص. پیش‌فرض ۶۰ ثانیه است.
--drain-min-allocations: در حالت تخلیه (drain mode، با دریافت SIGUSR1)، به محض آنکه تعداد تخصیص‌های فعال به این مقدار یا کمتر از آن کاهش یابد، فرایند متوقف می‌شود. پیش‌فرض ۰ است (صبر تا زمانی که تمام تخصیص‌ها از بین بروند).

--denied-peer-ip=<IPaddr[-IPaddr]>

--allowed-peer-ip=<IPaddr[-IPaddr]> گزینه‌های مسدودسازی یا مجاز کردن نشانی‌های IP یا محدوده‌های خاصی از نشانی‌های IP. اگر یک نشانی IP هم به عنوان مجاز و هم مسدود مشخص شده باشد،

آن نشانی IP مجاز تلقی می‌شود. این قابلیت زمانی سودمند است که بخواهید محدوده‌ای از نشانی‌های IP را به جز چند IP مشخص در آن محدوده مسدود کنید. این گزینه زمانی می‌تواند استفاده شود که نمی‌خواهید کاربران کارساز turn بتوانند به دستگاه‌های قابل دسترسی توسط کارساز turn دسترسی داشته باشند، در حالی که در حالت عادی از اینترنت غیرقابل دسترسی هستند (برای نمونه هنگامی که کارساز turn پشت یک NAT قرار دارد). محدوده‌های IP همتای "سفید" و "سیاه" را می‌توان به‌طور پویا در پایگاه‌داده نیز تغییر داد. قوانین نشانی‌های مجاز/مسدود (فهرست‌های سفید/سیاه) بسیار ساده هستند:

1): اگر هیچ قاعده‌ای برای یک نشانی وجود نداشته باشد، مجاز است؛
2): اگر یک قاعده "مجاز" وجود داشته باشد که با نشانی مطابقت کند، آن نشانی مجاز است - بدون استثنا؛
3): اگر هیچ قاعده "مجاز" مطابق با نشانی نباشد، و قاعده "مسدود" مطابق با نشانی وجود داشته باشد، مسدود می‌شود.

--pidfile: نام پرونده برای ذخیره pid فرایند. پیش‌فرض /var/run/turnserver.pid است (در صورت استفاده از حساب کاربری ریشه/ابرکاربر) یا

/var/tmp/turnserver.pid .

--acme-redirect: <URL> تغییر مسیر درخواست‌های ACME/RFC8555 (مانند چالش Let's Encrypt)، یعنی درخواست‌های HTTP GET منطبق با '^/.well-known/acme-challenge/(.*)'

به <URL>$1 با $1 == (.*). هیچ اعتبارسنجی روی <URL> انجام نخواهد شد، بنابراین اطمینان حاصل کنید که ممیز پایانی (trailing slash) را فراموش نکرده‌اید. اگر <URL> یک رشته خالی باشد (مقدار پیش‌فرض)، هیچ رسیدگی ویژه‌ای روی چنین درخواست‌هایی انجام نمی‌شود.

--proc-user: نام کاربری برای اجرای فرایند. پس از مقداردهی اولیه، فرایند turnserver تلاش خواهد کرد شناسه کاربر فعلی (user ID) را به آن کاربر تغییر دهد.

--proc-group: نام گروه برای اجرای فرایند. پس از مقداردهی اولیه، فرایند turnserver تلاش خواهد کرد شناسه گروه فعلی (group ID) را به آن گروه تغییر دهد.

-K, --keep-address-family: منسوخ شده و به نفع --allocation-default-address-family حذف خواهد شد!! کارساز TURN خانواده نشانی را بر اساس خانواده نشانی ارتباطی

کارگیر <=> کارساز تخصیص می‌دهد. !! این گزینه بخش ۴.۲ از RFC6156 را نقض می‌کند (نقض پیش‌فرض IPv4) !!

-A --allocation-default-address-family=<ipv4|ipv6|keep>: پیش‌فرض IPv4 است کارساز TURN خانواده نشانی را بر اساس خانواده نشانی درخواستی کارگیر TURN تخصیص می‌دهد.

اگر خانواده نشانی به‌صراحت توسط کارگیر درخواست نشود، به این پیش‌فرض برمی‌گردد. استاندارد RFC به‌صراحت تعیین می‌کند که این پیش‌فرض باید IPv4 باشد، بنابراین از سایر مقادیر این گزینه بااحتیاط استفاده کنید!

--cli-ip: نشانی IP سیستم محلی برای استفاده در رابط مدیریتی CLI. فرایند turnserver برای مدیریت می‌تواند با telnet در این نشانی IP

و روی درگاه CLI (پارامتر بعدی را ببینید) در دسترس باشد. مقدار پیش‌فرض 127.0.0.1 است. می‌توانید از telnet یا putty (در حالت telnet) برای دسترسی به رابط مدیریتی CLI استفاده کنید.

--cli-port: درگاه شنود رابط مدیریتی CLI. پیش‌فرض ۵۷۶۶ است.
--cli-password: گذرواژه دسترسی CLI. پیش‌فرض خالی است (بدون گذرواژه). به دلایل امنیتی، توصیه می‌شود از شکل رمزنگاری‌شده

گذرواژه استفاده شود (دستور -P در ابزار turnadmin را ببینید). علامت‌های دلار ($) در فرم رمزنگاری‌شده باید گریز داده شوند (escaped).

--cli-max-output-sessions: حداکثر تعداد نشست‌های خروجی در دستور CLI به نام ps. این مقدار می‌تواند در زمان اجرا در CLI تغییر یابد. مقدار پیش‌فرض ۲۵۶ است.

--web-admin: فعال‌سازی پشتیبانی از Turn Web-admin. به‌طور پیش‌فرض غیرفعال است.
--web-admin-ip=<IP>: نشانی IP سیستم محلی برای استفاده به عنوان نقطه پایانی کارساز Web-admin. مقدار پیش‌فرض 127.0.0.1 است.
--web-admin-port=<port>: درگاه سرور وب-ادمین (web-admin). پیش‌فرض 8080 است.
--web-admin-listen-on-workers: فعال‌سازی گوش دادن سرور وب-ادمین روی درگاه‌های STUN/TURN متعلق به کارگران (workers) STUN/TURN. به‌طور پیش‌فرض به دلایل امنیتی غیرفعال است!

(این رفتار قبلاً رفتار پیش‌فرض بود و به‌طور پیش‌فرض فعال می‌شد.)

--rfc5780: فعال‌سازی RFC5780 (کشف رفتار NAT). در ابتدا، اگر بیش از یک نشانی شنونده از یک

خانواده نشانی وجود داشت، ویژگی کشف رفتار NAT به‌طور پیش‌فرض فعال می‌شد. این گزینه این رفتار اولیه را فعال می‌کند، زیرا کشف رفتار NAT صفاتی (attributes) را به پاسخ می‌افزاید و این امر احتمال حمله تقویت‌شده (amplification attack) را افزایش می‌دهد. اکیداً توصیه می‌شود از این گزینه برای کاهش ضریب تقویت (gain factor) در پاسخ‌های اتصال (binding) در STUN استفاده کنید.

--no-rfc5780: منسوخ شده و اکنون رفتار پیش‌فرض است. --rfc5780 را ببینید.

--stun-backward-compatibility: افزودن صفت منسوخ‌شده MAPPED-ADDRESS به پاسخ‌های اتصال STUN، علاوه بر صفت XOR-MAPPED-ADDRESS که همیشه ارسال می‌شود. تنها برای کلاینت‌هایی لازم است که قادر به تجزیه XOR-MAPPED-ADDRESS نیستند. اکیداً توصیه می‌شود این گزینه را خاموش نگه دارید تا ضریب تقویت در پاسخ‌های اتصال STUN کاهش یابد.

--rfc3489-compatibility: منسوخ شده. فعال‌سازی مدیریت درخواست‌های اتصال منسوخ RFC 3489 («STUN کلاسیک»)، که فاقد کوکی جادویی (magic cookie) هستند. سند RFC 5389 این سازوکارها را منسوخ کرد و RFC 8489 آنها را کاملاً کنار گذاشت. این گزینه برای حذف در انتشار اصلی بعدی برنامه‌ریزی شده و هیچ جایگزینی ندارد.

: پیش از ایجاد این گزینه، مسیر درخواست RFC 3489 توسط --stun-backward-compatibility کنترل می‌شد. مدیرانی که آن گزینه را برای پاسخ‌گویی به کلاینت‌های STUN کلاسیک تنظیم می‌کردند اکنون باید --rfc3489-compatibility را به جای آن، یا هر دو گزینه را برای حفظ دقیق رفتار قبلی تنظیم کنند.

--unauthorized-ratelimit: فعال‌سازی محدودسازی نرخ پاسخ‌های 401 Unauthorized در پروتکل UDP به‌ازای هر منبع. این امر حملات بازتابی و تقویتی را که نشانی منبع قربانی را جعل می‌کنند تا چالش‌های احراز هویت را دریافت کنند کاهش می‌دهد. به‌طور پیش‌فرض غیرفعال است.
--unauthorized-ratelimit-rps=<count>: حداکثر تعداد پاسخ‌های 401 Unauthorized در پروتکل UDP که به‌ازای هر IP منبع در هر ثانیه ارسال می‌شود. مقدار پیش‌فرض 10 است.
--stateless-nonce: صدور نانس‌های (nonce) چالش 401/438 به‌صورت کوکی‌های مهرزمانی احراز‌هویت‌شده (زمان صدور به همراه یک HMAC روی نشانی کلاینت، کلیدخورده با یک راز اختصاصیِ هر فرایند) به‌جای ذخیره یک نانس تصادفی در وضعیت نشست به‌ازای هر کلاینت. در نتیجه درخواست‌های UDP احراز‌هویت‌نشده بدون تخصیص نشست پاسخ داده می‌شوند، که حافظه سرور را در برابر سیلاب‌های ناشی از نشانی‌های منبع جعلیِ پیام‌های از نظر ساختاری معتبر STUN محدود نگه می‌دارد. سازگار با کلاینت‌های استاندارد TURN در سطح شبکه (Wire-compatible). به‌طور پیش‌فرض فعال است؛ با --stateless-nonce=false غیرفعال می‌شود، که نانس تصادفی ذخیره‌شده و چالش ۱۶ نویسه‌ای قدیمی را به جای چالش ۲۴ نویسه‌ای بازمی‌گرداند.
--stateless-nonce-secret=<secret>: مشتق کردن کلید امضای stateless-nonce از این راز به‌جای یک کلید تصادفی به‌ازای هر فرایند (مستلزم فعال بودن --stateless-nonce). سرورهایی که این راز را به اشتراک می‌گذارند نانس‌های یکدیگر را اعتبارسنجی می‌کنند، بنابراین چالش‌ها پس از راه‌اندازی مجدد باقی می‌مانند و در سراسر یک ناوگان متوازن‌شده (load-balanced) کار می‌کنند. از یک رشته طولانی با انتروپی بالا استفاده کنید و ساعت‌های ناوگان را از طریق NTP همگام نگه دارید.

==================================

توازن بار و تنظیم کارایی (LOAD BALANCE AND PERFORMANCE TUNING)

این موضوع در صفحه ویکی پوشش داده شده است:

https://github.com/coturn/coturn/wiki/turn_performance_and_load_balance

===================================

کاربرد WEBRTC (WEBRTC USAGE)

این مجموعه‌ای از یادداشت‌ها برای کاربران WebRTC است:

1): فناوری WebRTC از سازوکار احراز هویت بلندمدت (long-term) استفاده می‌کند، بنابراین باید از گزینه -a (یا --lt-cred-mech) استفاده کنید. رله کردن WebRTC با دسترسی ناشناس کار نخواهد کرد. با گزینه -a، تنظیم قلمرو (realm) پیش‌فرض (گزینه -r) را فراموش نکنید. همچنین باید حساب‌های کاربری را تنظیم کنید، که برای این کار گزینه‌های متعددی دارید:

الف) گزینه‌های خط فرمان (-u).

ب) یک جدول پایگاه داده (SQLite یا PostgreSQL یا MySQL یا MongoDB). باید کلیدها را با ابزار turnadmin تنظیم کنید (مستندات و صفحه مان turnadmin را ببینید). نمی‌توانید از گذرواژه‌های متنی آشکار در پایگاه داده استفاده کنید.

ج) جفت(های) کلید/مقدار Redis، اگر از Redis استفاده شود. می‌توانید از کلیدها یا گذرواژه‌های متنی آشکار در Redis استفاده کنید؛ فایل turndb/testredisdbsetup.sh را ببینید.

د) همچنین می‌توانید از TURN REST API استفاده کنید. نیاز به راز(های) مشترک تنظیم‌شده خواهید داشت، چه از طریق گزینه خط فرمان، چه فایل پیکربندی، یا از طریق جدول پایگاه داده یا جفت‌های کلید/مقدار Redis.

2): معمولاً WebRTC از اثرانگشت‌گذاری (-f) استفاده می‌کند.
3): گزینه -v ممکن است برای مشاهده کلاینت‌های متصل مناسب باشد.
4): اگر سرور TURN خود را پشت یک NAT اجرا می‌کنید، گزینه -X مورد نیاز است.
5): اگر می‌خواهید محدوده شماره درگاه‌های نقاط پایانی رله را محدود کنید، ممکن است به گزینه‌های --min-port و --max-port نیاز باشد.

===================================

رابط برنامه‌نویسی کاربردی رست ترن (TURN REST API)

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

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

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

سازوکار «کلاسیک» اعتبارنامه‌های بلندمدت (LTCM) در اینجا شرح داده شده است:

http://tools.ietf.org/html/rfc5389#section-10.2

http://tools.ietf.org/html/rfc5389#section-15.4

برای احراز هویت، هر کاربر باید دو چیز را بداند: نام کاربری (username) و گذرواژه (password). به صورت اختیاری، کاربر باید مقدار ORIGIN را نیز ارائه دهد تا سرور بتواند قلمرو (realm) مورد استفاده برای کاربر را تشخیص دهد. مقادیر nonce و realm توسط سرور TURN ارائه می‌شوند. اما LTCM چیزی درباره ماهیت و ماندگاری نام کاربری و گذرواژه بیان نمی‌کند؛ و این همان نقطه‌ای است که توسط REST API بهره‌برداری می‌شود.

در TURN REST API، هیچ گذرواژه دائمی برای کاربران وجود ندارد. کاربر تنها یک نام کاربری دارد. گذرواژه همواره موقت است و هنگام دسترسی کاربر به صفحه WebRTC، بر حسب تقاضا توسط وب‌سرور تولید می‌شود. در واقع، یک نام کاربری موقت و تنها مخصوص یک نشست نیز در اختیار کاربر قرار می‌گیرد.

کاربر موقت به صورت زیر ایجاد می‌شود:

temporary-username="timestamp" + ":" + "username"

که در آن username همان نام کاربری پایدار است، و قالب timestamp صرفاً ثانیه‌های سپری‌شده از سال ۱۹۷۰ است - همان مقداری که تابع time(NULL) بازمی‌گرداند.

گذرواژه موقت از طریق تابع HMAC-SHA1 بر روی نام کاربری موقت، با استفاده از راز مشترک (shared secret) به عنوان کلید HMAC به دست آمده و سپس نتیجه کدگذاری می‌شود:

temporary-password = base64_encode(hmac-sha1(shared-secret, temporary-username))

هم سرور TURN و هم وب‌سرور از یک راز مشترک یکسان آگاه هستند. نحوه توزیع راز مشترک میان موجودیت‌های درگیر، به جزئیات استقرار WebRTC واگذار شده است - این موضوع فراتر از محدوده TURN REST API است.

بنابراین، از یک مهرزمانی (timestamp) برای محاسبه گذرواژه موقت استفاده می‌شود، و این مهرزمانی را می‌توان از نام کاربری موقت بازیابی کرد. این اطلاعات ارزشمند است، اما تا زمانی که مهرزمانی منقضی نشده باشد تنها موقتی است. بدون دانستن راز مشترک، امکان تولید گذرواژه موقت جدید وجود ندارد.

تمام این موارد به صورت رسمی در سند TURN REST API جاستین اوبرتی (Justin Uberti) شرح داده شده است که از طریق پیوند «TURN REST API» در صفحه پروژه TURN Server به نشانی https://github.com/coturn/coturn/ قابل دسترسی است.

هنگامی که نام کاربری و گذرواژه موقت توسط برنامه کلاینت (مرورگر) دریافت شد، باقی مراحل همان سازوکار «کلاسیک» اعتبارنامه‌های بلندمدت است. برای توسعه‌دهندگان، در زیر آن را گام‌به‌گام شرح می‌دهیم:

یک کلاینت جدید TURN دستور درخواستی را به سرور TURN ارسال می‌کند. به صورت اختیاری، فیلد ORIGIN را نیز به آن می‌افزاید.
سرور TURN متوجه می‌شود که این یک کلاینت جدید است و پیام احراز هویت نشده است.
سرور TURN یک رشته nonce تصادفی تولید می‌کند، و خطای 401 را همراه با nonce و realm به کلاینت بازمی‌گرداند. اگر فیلد ORIGIN در درخواست کلاینت وجود داشته باشد، ممکن است بر مقدار realm که سرور برای کلاینت برمی‌گزیند اثر بگذارد.
کلاینت خطای 401 را مشاهده کرده و دو مقدار را از پاسخ خطا استخراج می‌کند: nonce و realm.
کلاینت از username، realm و password برای تولید یک کلید استفاده می‌کند:
key = MD5(username ":" realm ":" SASLprep(password)) (SASLprep is described here: http://tools.ietf.org/html/rfc4013)
کلاینت درخواست جدیدی تشکیل می‌دهد، username، realm و nonce را به درخواست اضافه می‌کند. سپس کلاینت فیلد یکپارچگی (integrity) را محاسبه کرده و به درخواست می‌افزاید. این پیچیده‌ترین بخش فرایند است و در پایان بخش 15.4 شرح داده شده است: http://tools.ietf.org/html/rfc5389#section-15.4
کلاینت، به صورت اختیاری، فیلد fingerprint را می‌افزاید. این کار نیز ممکن است رویه‌ای پیچیده باشد که در بخش 15.5 همان سند شرح داده شده است. WebRTC معمولاً از پیام‌های انگشت‌نگاری‌شده (fingerprinted) در TURN استفاده می‌کند.
سرور TURN درخواست را دریافت کرده، username را می‌خواند.
سپس سرور TURN بررسی می‌کند که nonce و realm موجود در درخواست معتبر باشند.
سپس سرور TURN کلید را محاسبه می‌کند.
سپس سرور TURN فیلد یکپارچگی (integrity) را محاسبه می‌کند.
سپس سرور TURN فیلد یکپارچگی محاسبه‌شده را با فیلد دریافت‌شده مقایسه می‌کند - آن‌ها باید یکسان باشند. اگر فیلدهای یکپارچگی با یکدیگر تفاوت داشته باشند، درخواست رد می‌شود.

در ارتباطات بعدی، کلاینت می‌تواند دقیقاً با همان توالی پیش برود، اما جهت بهینه‌سازی معمولاً کلاینت با داشتن اطلاعات realm و nonce از قبل، رشته یکپارچگی را برای هر درخواست از پیش محاسبه می‌کند، به طوری که پاسخ خطای 401 غیرضروری می‌گردد. سرور TURN ممکن است برای امنیت بیشتر از گزینه "--stale-nonce" استفاده کند: پس از مدتی، nonce منقضی می‌شود و کلاینت پاسخ خطای 438 را همراه با nonce جدید دریافت خواهد کرد، و کلاینت باید استفاده از nonce جدید را آغاز کند.

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

نمونه‌ای که در آن راز مشترک جدید هر ساعت توسط دستگاه سرور TURN تولید شده و سپس از راه دور به وب‌سرور ارائه می‌گردد، در اسکریپت examples/scripts/restapi/shared_secret_maintainer.pl آورده شده است.

نکته بسیار مهم این است که nonce باید کاملاً تصادفی باشد و برای کلاینت‌ها و نشست‌های مختلف متفاوت باشد.

===================================

پایگاه‌های داده (DATABASES)

برای پایگاه داده کاربران، turnserver گزینه‌های زیر را ارائه می‌دهد:

1): کاربران می‌توانند در خط فرمان با گزینه‌های متعدد -u یا --user تعیین شوند. بدیهی است که از این طریق تنها شمار اندکی از کاربران را می‌توان تعریف کرد و اعتبارنامه‌های آن‌ها در طول دوره اجرای فرایند turnserver ثابت باقی می‌ماند.
2): کاربران را می‌توان در پایگاه داده SQLite ذخیره کرد. پرونده پایگاه داده پیش‌فرض SQLite مسیر /var/db/turndb یا /usr/local/var/db/turndb یا /var/lib/turn/turndb است.
3): در صورتی که turnserver با پشتیبانی از PostgreSQL کامپایل شده باشد، کاربران را می‌توان در پایگاه داده PostgreSQL ذخیره کرد. هربار که turnserver اعتبارنامه‌های کاربر را بررسی می‌کند، پایگاه داده را می‌خواند (البته به صورت ناهمگام، تا جریان جاری بسته‌ها به هیچ وجه با تاخیر مواجه نشود)، بنابراین هر تغییری در محتوای پایگاه داده بی‌درنگ توسط turnserver قابل مشاهده است. اگر به بهترین مقیاس‌پذیری نیاز دارید، این روش مناسب است. طرحواره (schema) پایگاه داده را می‌توان در پرونده schema.sql یافت. برای اعتبارنامه‌های بلندمدت، باید «کلیدها» (keys) را برای کاربران تنظیم کنید؛ این «کلیدها» توسط ابزار turnadmin تولید می‌شوند. برای تولید کلید، به نام کاربری، گذرواژه و realm نیاز دارید. همه کاربران در پایگاه داده باید از یک مقدار realm یکسان استفاده کنند؛ اگر در آینده تصمیم به تغییر نام realm بگیرید، باید تمام کلیدهای کاربران را دوباره تولید کنید (این کار را می‌توان در یک اسکریپت دسته‌ای انجام داد). برای نمونه به پرونده turndb/testsqldbsetup.sql نگاه کنید.
4): همین موضوع برای پایگاه داده MySQL نیز صادق است. پرونده طرحواره یکسان قابل استفاده است. ملاحظات مشابهی نیز اعمال می‌شود.
5): همین موضوع برای پایگاه داده Redis نیز صدق می‌کند، اما پایگاه داده Redis طرحواره متفاوتی دارد - که می‌توان آن را (به شکل توضیحات) در schema.userdb.redis یافت. همچنین در Redis می‌توانید هم «کلیدها» و هم گذرواژه‌های خام (open passwords) را (برای اعتبارنامه‌های بلندمدت) ذخیره کنید - گزینه «گذرواژه خام» امنیت کمتری دارد اما برای محیط‌های با امنیت پایین راحت‌تر است. برای نمونه به پرونده turndb/testredisdbsetup.sh نگاه کنید.
6): اگر از پایگاه داده استفاده شود، کاربران را می‌توان به چندین realm مستقل تقسیم کرد. هر realm را می‌توان به طور جداگانه مدیریت کرد، و هر realm می‌تواند مجموعه کاربران خاص خود و گزینه‌های کارایی اختصاصی خود (max-bps، user-quota، total-quota) را داشته باشد.
7): اگر از MongoDB استفاده کنید، پایگاه داده به طور خودکار برای شما راه‌اندازی خواهد شد.
8): البته، turnserver می‌تواند در حالت غیرامن استفاده شود، به گونه‌ای که کاربران اجازه داشته باشند نشست‌ها را به صورت ناشناس برقرار کنند. اما در بیشتر موارد (مانند WebRTC) این روش کار نخواهد کرد.

برای پایگاه داده وضعیت و آمار، دو انتخاب وجود دارد:

1): ساده‌ترین انتخاب عدم استفاده از آن است. گزینه --redis-statsdb را تنظیم نکنید، و این قابلیت به سادگی نادیده گرفته خواهد شد.
2): اگر تصمیم به استفاده از آن دارید، گزینه --redis-statsdb را تنظیم کنید. این می‌تواند همان پایگاه داده تعیین‌شده در گزینه --redis-userdb باشد، یا پایگاه داده متفاوتی باشد. ممکن است به دلایل امنیتی یا راحتی بخواهید از پایگاه داده متفاوتی استفاده کنید. همچنین می‌توانید از سامانه‌های مدیریت پایگاه داده متفاوتی برای پایگاه داده کاربران و پایگاه داده وضعیت و آمار استفاده کنید. برای نمونه، می‌توانید از MySQL به عنوان پایگاه داده کاربران، و از Redis برای آمار استفاده کنید. یا از Redis برای هر دو استفاده نمایید.

بنابراین، ما ۶ انتخاب برای مدیریت کاربران، و ۲ انتخاب برای مدیریت آمار داریم. این دو کاملاً مستقل از یکدیگرند. پس در کل ۶*۲=۱۲ روش برای مدیریت اطلاعات ماندگار در اختیار دارید؛ هرکدام را که راحت‌تر هستید برگزینید.

نیازی نیست اطلاعات پایگاه داده را «دستی» مدیریت کنید - برنامه turnadmin می‌تواند همه چیز را برای شما مدیریت کند. برای PostgreSQL و MySQL تنها کافی است یک پایگاه داده خالی با اسکریپت SQL به نام schema.sql بسازید. در مورد Redis، حتی نیازی به این کار نیز ندارید - تنها turnadmin را اجرا کنید تا کاربران را برای شما تنظیم کند (به راهنماهای turnadmin مراجعه کنید). اگر از SQLite استفاده می‌کنید، turnserver یا turnadmin در زمان راه‌اندازی، پایگاه داده خالی را برای شما مقداردهی اولیه خواهند کرد. فرایند نصب سرور TURN یک پایگاه داده خالی مقداردهی‌شده SQLite را در مکان پیش‌فرض (/var/db/turndb یا /usr/local/var/db/turndb یا /var/lib/turn/turndb، بسته به سیستم) ایجاد می‌کند.

=================================

ALPN (مذاکره پروتکل لایه کاربرد)

سرور از ALPNهای "stun.turn" و "stun.nat-discovery" در صورت کامپایل با OpenSSL 1.0.2 یا جدیدتر پشتیبانی می‌کند. اگر سرور پیام ClientHello از نوع TLS/DTLS را دریافت کند که شامل یک یا هر دوی این ALPNها باشد، نخستین برچسب *stun. را برمی‌گزیند و آن را (در ServerHello) درون فیلد افزونه ALPN بازمی‌فرستد. در صورتی که هیچ برچسب *stun. یافت نشود، سرور اطلاعات ALPN را در ServerHello نمی‌گنجاند.

=================================

کتابخانه‌ها (LIBRARIES)

در زیرشاخه lib/، فرایند ساخت کتابخانه پیام‌رسانی کلاینت TURN را ایجاد خواهد کرد. در زیرشاخه include/، پرونده‌های سرایند لازم قرار خواهند گرفت. پوشش‌دهنده C++ برای قابلیت‌های پیام‌رسانی در سرایند TurnMsgLib.h قرار دارد. نمونه‌ای از کد C++ را می‌توان در پرونده stunclient.c یافت.

=================================

مستندات (DOCS)

پس از نصب، دستور زیر را اجرا کنید:

$ man turnserver

یا در شاخه ریشه پروژه:

$ man -M man turnserver

تا صفحه راهنما را مشاهده کنید.

در زیرشاخه docs/html از درخت آرشیو اصلی، مرجع کتابخانه کلاینت را خواهید یافت. پس از نصب، این مرجع در مسیر PREFIX/share/doc/turnserver/html قرار خواهد گرفت.

=================================

گزارش‌ها (LOGS)

هنگامی که سرور TURN آغاز به کار می‌کند، تلاش می‌کند پرونده گزارش turn_<pid>.log را در شاخه‌های زیر ایجاد کند:

/var/log
/log/
/var/tmp
/tmp
شاخه جاری

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

این رفتار را می‌توان با گزینه‌های --log-file، --syslog و --no-stdout-log مهار کرد.

=================================

رابط مدیریتی HTTPS (HTTPS MANAGEMENT INTERFACE)

فرایند turnserver یک دسترسی وب HTTPS را به عنوان رابط آماری و مدیریت پایه فراهم می‌کند. turnserver روی همان درگاه‌های شنونده اصلی TURN/STUN به اتصالات مدیریتی ورودی HTTPS گوش فرامی‌دهد. صفحات وب مدیریت پایه بوده و خودتوضیح هستند.

برای فعال‌سازی رابط HTTPS، جدول پایگاه‌داده admin_user باید با حساب(های) کاربری مدیر پر شود. یک کاربر مدیر می‌تواند مدیر ارشد (superuser) باشد (در صورتی که به قلمرو یا realm خاصی اختصاص نیافته باشد) یا کاربر محدودشده (در صورتی که به یک realm تخصیص داده شده باشد). کاربران مدیر محدودشده تنها می‌توانند کنش‌های محدودی را در چارچوب قلمروهای مربوط به خود انجام دهند.

=================================

واسط خط فرمان تلنت (TELNET CLI)

فرایند turnserver یک دسترسی واسط خط فرمان (CLI) تلنت را به عنوان رابط آماری و مدیریت پایه فراهم می‌آورد. به صورت پیش‌فرض، turnserver یک شنونده تلنت CLI را روی نشانی آی‌پی 127.0.0.1 و درگاه 5766 راه‌اندازی می‌کند. این مقدار با گزینه‌های خط فرمان فرایند turnserver قابل تغییر است (گزینه‌های --cli-ip و --cli-port را ببینید). فهرست کامل دستورهای telnet CLI در خروجی دستور "help" در واسط تلنت CLI ارائه شده است.

=================================

خوشه‌ها (CLUSTERS)

سرور TURN می‌تواند بخشی از یک راه‌اندازی خوشه‌ای باشد. اما برای پشتیبانی از قابلیت «درگاه زوج» (جفت جریان‌های RTP/RTCP)، درخواست‌های کلاینت از یک نشانی IP مشخص باید به همان نمونه از سرور TURN ارسال شوند؛ بنابراین نیازمند اعمال برخی تنظیمات شبکه‌ای برای خوشه است. دلیل آن این است که نقاط پایانی رله RTP و RTCP باید روی همان IP رله تخصیص یابند. طراحی سازوکاری با فوروارد درخواست‌ها در سطح برنامه امکان‌پذیر خواهد بود (و شاید بعداً آن را انجام دهیم)، اما بر کارایی تأثیر منفی می‌گذارد.