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

TURN چیست

TURN (Traversal Using Relays around NAT) یک پروتکل است که بسته‌های مدیا را از طریق سرور ارسال می‌کند وقتی دو نقطه پایانی نمی‌توانند مستقیماً متصل شوند.

پروتکل‌های مرتبط:

برای پشته اتصال کامل به اتصال WebRTC ببینید.

TURN در بدرود

LiveKit شامل یک سرور TURN جاسازی‌شده است. هیچ زیرساخت خارجی لازم نیست.

معماری رله

flowchart LR
    subgraph Client["Client"]
        A[WebRTC Peer]
    end
 
    subgraph NAT["NAT / Firewall"]
        direction TB
        N{Direct P2P<br/>possible?}
    end
 
    subgraph Server["Bedrud Server"]
        STUN[STUN Server<br/>port 3478]
        TURN[TURN Relay<br/>port 3478 UDP<br/>port 5349 TLS]
        SFU[LiveKit SFU]
    end
 
    A -->|"ICE candidates"| N
    N -->|"Yes"| SFU
    N -->|"No"| TURN
    TURN -->|"relayed media"| SFU
    A -.->|"discover public IP"| STUN

اولویت اتصال

LiveKit انواع اتصال را به ترتیب امتحان می‌کند. هر fallback تأخیر و هزینه سرور اضافه می‌کند:

flowchart TD
    A[ICE over UDP<br/>port 50000-60000] -->|"~80% succeed"| S[Connected]
    A -->|"fail"| B[TURN over UDP<br/>port 3478]
    B -->|"succeed"| S
    B -->|"UDP blocked"| C[ICE over TCP<br/>port 7881]
    C -->|"succeed"| S
    C -->|"TCP blocked"| D[TURN over TLS<br/>port 5349 / 443]
    D -->|"succeed"| S
    D -->|"fail"| E[Connection failed]

وقتی TURN فعال می‌شود

TURN فعال می‌شود وقتی مسیر مدیا مستقیم شکست می‌خورد. دلایل رایج:

• NAT symmetric در هر دو طرف - کلاینت و سرور هر دو NAT symmetric دارند. NAT یک پورت عمومی متفاوت برای هر مقصد تخصیص می‌کند، بنابراین آدرس کشف شده توسط STUN غیرقابل دسترس می‌شود.
• فایروال شرکتی - خروجی UDP را به طور کامل مسدود می‌کند. فقط پورت TCP ۴۴۳ مجاز است.
• محدودیت‌های VPN - برخی VPN‌ها ترافیک WebRTC را رهگیری یا مسدود می‌کنند.
• VMهای ابری بدون IP عمومی - برخی ارائه‌دهندگان ابری از NAT استفاده می‌کنند که ICE مستقیم را می‌شکند.

اکثر کاربران (~۸۰٪) هرگز به TURN برنمی‌خورند. مسیر UDP مستقیم کار می‌کند.

هزینه پهنای باند

وقتی TURN رله می‌کند، سرور تمام مدیا را برای آن شرکت‌کننده حمل می‌کند. پهنای باند تقریبی در هر جریان:

برای یک جلسه ۵ نفره با یک شرکت‌کننده رله شده: سرور ~۱.۵ Mbps اضافه برای رله ویدیوی آن شرکت‌کننده را مدیریت می‌کند. این مقادیر را در تعداد شرکت‌کنندگان رله شده ضرب کنید تا پهنای باند کل سرور را تخمین زنید.

پیکربندی

فایل: server/config/livekit.yaml (توسعه) یا /etc/bedrud/livekit.yaml (تولید)

turn:
  enabled: true
  domain: "turn.example.com"
  udp_port: 3478
  tls_port: 5349
  cert_file: /etc/bedrud/turn.crt
  key_file: /etc/bedrud/turn.key
  relay_range_start: 30000
  relay_range_end: 40000
  external_tls: false

مرجع کلید

تعامل use_external_ip

در همان livekit.yaml، در زیر rtc::

rtc:
  use_external_ip: true

باید true باشد تا TURN به درستی کار کند. وقتی false است، نامزدهای ICE شامل آدرس‌های IP داخلی (خصوصی) هستند که کلاینت‌ها در اینترنت نمی‌توانند به آنها دسترسی پیدا کنند.

تنظیم TLS تولید

TURN/TLS به گواهی TLS خود نیاز دارد. دو رویکرد:

دامنه تکی (بدون بالانس‌کن بار)

گواهی TLS سرور را استفاده مجدد کنید. tls_port را روی 443 تنظیم کنید:

turn:
  enabled: true
  domain: "meet.example.com"
  tls_port: 443
  cert_file: /etc/bedrud/meet.example.com.crt
  key_file: /etc/bedrud/meet.example.com.key

دامنه TURN و دامنه سرور یکی هستند. پورت ۴۴۳ هم API HTTPS و هم TURN/TLS را مدیریت می‌کند - LiveKit توسط پروتکل تشخیص می‌دهد.

دامنه TURN اختصاصی (با بالانس‌کن بار)

flowchart LR
    C[Client] --> LB[Layer 4<br/>Load Balancer]
    LB -->|"HTTPS :443"| API[Bedrud API<br/>:8090]
    LB -->|"TURN/TLS :5349"| LK1[LiveKit Node 1<br/>:7880]
    LB -->|"TURN/TLS :5349"| LK2[LiveKit Node 2<br/>:7880]
 
    C -.->|"TURN/UDP :3478"| LK1

turn:
  enabled: true
  domain: "turn.example.com"
  tls_port: 5349
  external_tls: true

بالانس‌کن بار TLS را خاتمه می‌دهد. external_tls: true به LiveKit می‌گوید انتظار ترافیک از پیش رمزگش شده را داشته باشد.

مرجع پورت و فایروال

flowchart TB
    subgraph Internet["Internet"]
        C[Client]
    end
 
    subgraph FW["Firewall"]
        direction LR
        P443["443/TCP<br/>HTTPS + TURN/TLS"]
        P3478["3478/UDP<br/>TURN/UDP + STUN"]
        P7881["7881/TCP<br/>ICE/TCP"]
        P5349["5349/TCP<br/>TURN/TLS"]
        PRANGE["50000-60000/UDP<br/>RTC Media"]
    end
 
    subgraph Bedrud["Bedrud Server"]
        API[API Server]
        LK[LiveKit SFU]
    end
 
    C --> P443 --> API
    C --> P3478 --> LK
    C --> P7881 --> LK
    C --> P5349 --> LK
    C --> PRANGE --> LK

قوانین حداقلی فایروال

برای اتصال پایه:

Allow TCP 443    (HTTPS + TURN/TLS)
Allow UDP 3478   (TURN/UDP + STUN)
Allow UDP 50000-60000  (RTC media)

برای سازگاری حداکثری (شبکه‌های شرکتی):

Also allow TCP 7881  (ICE/TCP)
Also allow TCP 5349  (TURN/TLS, if not using port 443)

تست و عیب‌یابی

مرورگر: chrome://webrtc-internals

۱. chrome://webrtc-internals را در Chrome/Edge قبل از پیوستن به جلسه باز کنید. ۲. یک dump ایجاد کنید. ۳. در تب Stats به دنبال جفت‌های نامزد ICE بگردید. ۴. انواع نامزد مسیر اتصال را به شما می‌گویند:

اگر نامزدهای relay را به عنوان جفت فعال می‌بینید، TURN آن اتصال را مدیریت می‌کند.

رویدادهای SDK کلاینت LiveKit

همه SDKهای LiveKit رویدادهای وضعیت اتصال را صادر می‌کنند:

room.on(RoomEvent.Connected, () => {
  console.log("Connected");
});
 
room.on(RoomEvent.Reconnecting, () => {
  console.log("Connection lost, reconnecting...");
});

آمار وضعیت اتصال را در room.localParticipant.connectionQuality بررسی کنید.

لاگ‌های سرور LiveKit

سطح لاگ را به debug در livekit.yaml افزایش دهید:

logging:
  level: debug

به دنبال ورودی‌های لاگ شامل موارد زیر بگردید:

• ICE - وضعیت جمع‌آوری نامزد
• TURN - رویدادهای تخصیص رله
• relay - اتصالات رله فعال

تست دستی TURN با turnutils

بسته coturn-utils را نصب کنید، سپس اتصال TURN را تست کنید:

turnutils_uclient -t -p 3478 -W devkey -u devkey turn.example.com

• -t - استفاده از TCP
• -p - پورت TURN
• اعتبارنامه‌ها را با مقادیر تولید جایگزین کنید

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

عیب‌یابی

چک‌لیست تشخیص سریع

۱. dig +short <turn.domain> IP عمومی صحیح را برمی‌گرداند؟ ۲. فایروال UDP ۳۴۷۸، TCP ۵۳۴۹، UDP ۵۰۰۰۰-۶۰۰۰۰ را اجازه می‌دهد؟ ۳. tls_port: 443 یا 5349 با قوانین فایروال مطابقت دارد؟ ۴. cert_file و key_file وجود دارند و قابل خواندن هستند؟ ۵. CN/SAN گواهی با turn.domain مطابقت دارد؟ ۶. rtc.use_external_ip: true تنظیم شده است؟ ۷. لاگ‌های LiveKit هیچ خطای مرتبط با TURN را نشان نمی‌دهند؟

همچنین ببینید

• اتصال WebRTC - پشته اتصال کامل STUN/ICE/TURN/SFU
• یکپارچگی LiveKit - نحوه جاسازی LiveKit در بدرود
• مرجع پیکربندی - تمام گزینه‌های پیکربندی
• TLS داخلی - TLS برای شبکه‌های ایزوله
• راهنمای استقرار - مراحل استقرار تولید