TURN(1)

اطلاعات عمومی (GENERAL INFORMATION)

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

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

پس از ساخت، ایمیج‌های باینری زیر را خواهید داشت:

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 در دسترس باشد، وضعیت سرور را به systemd اطلاع می‌دهد.

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

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

$ turnserver -o

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

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

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

$ turnserver -L 12.34.56.78

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

$ turnserver --listening-ip=12.34.56.78

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

$ turnserver -a

معادل است با:

$ turnserver --lt-cred-mech

نام (NAME)

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

خلاصه دستور (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)

Config file settings:

-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>" (برای نسخه‌های 8.x یا جدیدتر Postgres).

یا:

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

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

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

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

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

"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" حتماً باید در قالب رمزنگاری‌شده وارد شود! اگر می‌خواهید از گذرواژه متنی آشکار استفاده کنید، این گزینه را تنظیم نکنید!

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

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

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

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

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

"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 مراجعه کنید.

فلگ‌ها:

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

--no-software-attribute منسوخ شده است. به "--software-attribute" مراجعه کنید.

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

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

اضافه خواهد کرد، بدون توجه به تنظیمات اختصاصی سرور.

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

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

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

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

--use-auth-secret: فلگ TURN REST API. فلگی که گزینه ویژه‌ای برای احراز هویت WebRTC مبتنی بر رمز

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

--oauth: پشتیبانی از احراز هویت oAuth، طبق استاندارد شخص ثالث STUN/TURN در RFC 7635.
--dh566: استفاده از کلید پیش‌تعریف‌شده 566 بیتی DH TLS. اندازه پیش‌فرض کلید 2066 است.
--dh1066: استفاده از کلید پیش‌تعریف‌شده 1066 بیتی DH TLS. اندازه پیش‌فرض کلید 2066 است.
--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> تنظیم تسهیلات (facility) سامانه 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: ثبت لاگ درخواست بایندینگ STUN. اکنون برای جلوگیری از حملات DoS به طور پیش‌فرض غیرفعال است.
--secure-stun: الزام احراز هویت در درخواست‌های بایندینگ STUN. به طور پیش‌فرض، دسترسی ناشناس کلاینت‌ها به قابلیت بایندینگ STUN مجاز است.

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

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

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

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

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

--mobility: پشتیبانی از مشخصات تحرک‌پذیری با ICE (MICE).
--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) را تنظیم می‌کند: در طول یک نشست، تمام درخواست‌ها باید مقدار ویژگی

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

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

(یا 0=) را ارسال کنید.

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

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

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

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

--multiplex-peer-port <port>: فقط لینوکس. پورت پایه UDP برای سوکت‌های رله multiplex-peer (پیش‌فرض: 3480، محدوده معتبر 1 تا 65000). نخ i به پورت‌های

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

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

پیش‌فرض بستن فوری اتصال است.

--prometheus: فعال‌سازی معیارهای پرومتئوس (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: راهنما.

گزینه‌های دارای مقدار:

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

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

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

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

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

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

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

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

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

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

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

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

--tls-listening-port: پورت شنونده TURN برای شنوندگان TLS و DTLS (پیش‌فرض: 5349). نکته: در عمل، نشست‌های "ساده" TCP و UDP نیز می‌توانند به پورت‌های TLS و DTLS

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

--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 روی این پورت. متعادل‌کننده بار باید از پروتکل پروکسی باینری استفاده کند.

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

--aux-server: نقطه پایانی شنود سرور کمکی STUN/TURN. سرورهای کمکی تقریباً تمام عملکردهای 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 رله استفاده شوند. اگر هیچ نشانی رله‌ای تعیین نشود، turnserver سیاست پیش‌فرض را اعمال خواهد کرد: خود تصمیم می‌گیرد که کدام نشانی‌های رله استفاده شوند و همیشه از نشانی IP سوکت کلاینت به عنوان نشانی IP رله نشست TURN استفاده خواهد کرد (اگر خانواده نشانی رله درخواست‌شده با خانواده سوکت کلاینت یکی باشد).

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

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

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

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

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

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

--min-port: حد پایین محدوده پورت UDP برای تخصیص نقاط پایانی رله.

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

--max-port: حد بالای محدوده پورت UDP برای تخصیص نقاط پایانی رله.

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

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

چندین حساب کاربری ممکن است در خط فرمان استفاده شود. کلید یا همان گذرواژه کاربر است، یا کلیدی است که توسط دستور turnadmin تولید شده است. در حالت دوم، کلید باید با نمادهای 0x آغاز شود. کلید بر اساس نام کاربری، قلمرو کاربر و گذرواژه کاربر محاسبه می‌شود. این تنظیم نباید همراه با 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 مجاز به رسیدگی به آن است (جریان‌های شبکه ورودی و خروجی به طور جداگانه بررسی می‌شوند). هر مقداری بیش از

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

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

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

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

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

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

مقدار پیش‌فرض همان نام قلمرو است.

--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). مقدار پیش‌فرض prime256v1 است

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

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

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

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

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

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

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

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

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

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

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

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

--allowed-peer-ip=<IPaddr[-IPaddr]> گزینه‌هایی برای مسدود کردن یا مجاز دانستن نشانی‌های 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 منطبق با '*(.)/acme-challenge/well-known./^'

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

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

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

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

کلاینت <=> سرور TURN تخصیص می‌دهد. !! این گزینه بخش 4.2 از 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 است. برای دسترسی به واسط مدیریتی CLI می‌توانید از telnet یا putty (در حالت telnet) استفاده کنید.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

این مبحث در صفحه ویکی زیر پوشش داده شده است:

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

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

استفاده در WEBRTC (WEBRTC USAGE)

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

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

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

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

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

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

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

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

رابط کاربری TURN REST API (TURN REST API)

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

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

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

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

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

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

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

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

کاربر موقت به این صورت تولید می‌شود:

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

که در آن username نام کاربری دائمی است و قالب timestamp به صورت ثانیه‌های سپری‌شده از سال 1970 است - همان مقداری که تابع (NULL)time بازمی‌گرداند.

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

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

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

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

همه این‌ها رسماً در سند Justin's Uberti TURN REST API توصیف شده است که با دنبال کردن پیوند "TURN REST API" در صفحه پروژه TURN Server به نشانی https://github.com/coturn/coturn قابل دستیابی است.

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

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

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

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

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

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

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

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

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

1): کاربران را می‌توان در خط فرمان، با چندین گزینه -u یا --user تنظیم کرد. بدیهی است که تنها تعداد کمی از کاربران را می‌توان به این روش تنظیم کرد و اعتبارنامه‌های آن‌ها برای طول عمر فرآیند turnserver ثابت است.
2): کاربران را می‌توان در پایگاه‌داده SQLite ذخیره کرد. فایل پیش‌فرض پایگاه‌داده SQLite برابر /var/db/turndb یا /usr/local/var/db/turndb یا /var/lib/turn/turndb است.
3): کاربران را می‌توان در پایگاه‌داده PostgreSQL ذخیره کرد، اگر turnserver با پشتیبانی PostgreSQL کامپایل شده باشد. هر بار که turnserver اعتبارنامه‌های کاربر را بررسی می‌کند، پایگاه‌داده را می‌خواند (البته به صورت ناهمگام، به طوری که جریان جاری بسته‌ها به هیچ وجه به تأخیر نیفتد)، بنابراین هر تغییری در محتوای پایگاه‌داده بلافاصله توسط turnserver قابل مشاهده است. اگر به بهترین مقیاس‌پذیری نیاز دارید، این روش مناسب است. طرحواره (schema) پایگاه‌داده را می‌توان در فایل schema.sql یافت. برای اعتبارنامه‌های بلندمدت، باید "کلیدها" را برای کاربران تنظیم کنید؛ "کلیدها" توسط ابزار turnadmin تولید می‌شوند. برای تولید کلید، به نام کاربری، گذرواژه و قلمرو نیاز دارید. همه کاربران در پایگاه‌داده باید از مقدار قلمرو یکسانی استفاده کنند؛ اگر در آینده تصمیم به تغییر نام قلمرو بگیرید، باید تمام کلیدهای کاربران را مجدداً تولید کنید (این کار را می‌توان در یک اسکریپت دسته‌ای انجام داد). فایل turndb/testsqldbsetup.sql را به عنوان نمونه ببینید.
4): همین امر برای پایگاه‌داده MySQL نیز صادق است. همان فایل طرحواره قابل استفاده است. همان ملاحظات نیز اعمال می‌شود.
5): همین امر برای پایگاه‌داده Redis نیز صادق است، اما پایگاه‌داده Redis طرحواره متفاوتی دارد - می‌توان آن را (به صورت توضیحات) در schema.userdb.redis یافت. همچنین، در Redis می‌توانید هم "کلیدها" و هم گذرواژه‌های آشکار را (برای اعتبارنامه‌های بلندمدت) ذخیره کنید - گزینه "گذرواژه آشکار" امنیت کمتری دارد اما برای محیط‌های با امنیت پایین راحت‌تر است. فایل turndb/testredisdbsetup.sh را به عنوان مثال ببینید.
6): اگر از پایگاه‌داده استفاده شود، کاربران را می‌توان به چندین قلمرو مستقل تقسیم کرد. هر قلمرو را می‌توان به طور جداگانه مدیریت کرد و هر قلمرو می‌تواند مجموعه کاربران و گزینه‌های عملکردی خود را داشته باشد (شامل 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 را انتخاب کرده و آن را در فیلد پسوند ALPN (در ServerHello) بازمی‌گرداند. اگر هیچ برچسب *.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 اتصالات ورودی مدیریت HTTPS را روی همان پورت‌های شنونده اصلی TURN/STUN شنود می‌کند. صفحات مدیریت وب ساده و خودتوضیح هستند.

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

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

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

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

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

خوشه‌ها (CLUSTERS)

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