วิธีการตั้งค่าเซิร์ฟเวอร์ Matrix Coturn TURN/STUN สำหรับการโทรด้วยเสียงและวิดีโอ

การเปลี่ยนแปลงการเรียกใช้ Matrix ในปัจจุบันส่งผลต่อการค้นหา แต่ไม่ส่งผลต่อข้อมูลประจำตัวหรือพอร์ต TURN ของ Coturn ในการอัปเดตเมื่อวันที่ 21 สิงหาคม 2026 Matrix.org รายงานว่า Element Call 0.24 ได้ยกเลิกการค้นหาการขนส่ง MatrixRTC ผ่าน/.well-known/matrix/clientไฟล์ของโฮมเซิร์ฟเวอร์ การใช้งาน Element Call แบบสแตนด์อโลนควรสนับสนุนปลายทางของการขนส่ง MatrixRTC; Element Web/Desktop และ Element X ยังคงใช้วิธีการค้นหาแบบเก่าเป็นทางเลือกสำรองในระหว่างที่ไคลเอ็นต์กำลังเปลี่ยนไปใช้ระบบอื่น นี่เป็นคนละส่วนกับการตั้งค่า TURN แบบคลาสสิก

คู่มือนี้จะกำหนดค่า Coturn สำหรับบริการ TURN ของ Synapse ซึ่งจะให้ข้อมูลรับรอง ICE ชั่วคราวแก่ไคลเอ็นต์ที่ใช้การโทร WebRTC แบบดั้งเดิม การโทรกลุ่ม Element Call และ MatrixRTC ในปัจจุบันใช้ LiveKit Selective Forwarding Unit (SFU) และบริการอนุญาตของ MatrixRTC Coturn เพียงอย่างเดียวไม่สามารถทดแทนส่วนประกอบเหล่านั้นได้ หากเป้าหมายของคุณคือ Element Call ที่โฮสต์ด้วยตนเอง ให้ใช้แนวทาง LiveKit ที่อธิบายไว้ในคู่มือ Element Call อย่างเป็นทางการ เพิ่ม Coturn เฉพาะในกรณีที่สถาปัตยกรรมสื่อที่คุณเลือกต้องการบริการ TURN แยกต่างหาก

เลือกเส้นทางการโทรที่ถูกต้องก่อน

สำหรับ MatrixRTC บน Synapse คู่มือการโฮสต์ Element Call ด้วยตนเองฉบับปัจจุบันใช้matrix_rtc.transportsและเปิดใช้งานรีจิสทรีการขนส่งของโฮมเซิร์ฟเวอร์ผ่านแฟล็กคุณสมบัติทดลองที่ระบุไว้ในเอกสาร ประกาศของ Matrix.org ปี 2026 ระบุว่าการเปลี่ยนแปลงการค้นหานี้มีความสำคัญที่สุดสำหรับการใช้งาน Element Call แบบสแตนด์อโลน ผู้ดูแลระบบรายอื่นสามารถเตรียมเอนด์พอยต์ได้ ในขณะที่ไคลเอ็นต์ที่ได้รับการสนับสนุนยังคงมีตัวสำรอง ตรวจสอบคู่มือสำหรับไคลเอ็นต์และเวอร์ชัน Synapse ที่คุณใช้งานจริง

โคเทิร์นทำอะไร

STUN ช่วยให้ไคลเอ็นต์ WebRTC ค้นหาที่อยู่เครือข่ายสาธารณะที่สามารถประกาศได้ TURN ทำหน้าที่ส่งต่อสื่อเมื่อไคลเอ็นต์สองฝ่ายไม่สามารถสร้างการเชื่อมต่อโดยตรงผ่านเราเตอร์หรือไฟร์วอลล์ได้ Coturn ให้บริการทั้งสองอย่างนี้ หากไม่มีตัวส่งต่อที่เข้าถึงได้ การโทรอาจดังขึ้นแต่ยังคงแสดงสถานะ "กำลังเชื่อมต่อ" เมื่อผู้เข้าร่วมอยู่บนเครือข่ายที่จำกัดหรือเครือข่ายที่ไม่เกี่ยวข้องกัน

เซิร์ฟเวอร์ TURN จำเป็นต้องมีที่อยู่ IP สาธารณะ หรือเกตเวย์ NAT ที่มี IP สาธารณะและกฎการส่งต่อที่ถูกต้อง เซิร์ฟเวอร์ส่วนตัวไม่สามารถทำหน้าที่เป็นรีเลย์อินเทอร์เน็ตสำหรับผู้ใช้ Matrix จากระยะไกลได้ สำหรับการใช้งาน Synapse ขนาดเล็ก คุณสามารถติดตั้ง Coturn บนโฮมเซิร์ฟเวอร์หรือใช้โฮสต์สาธารณะแยกต่างหาก โฮสต์แยกต่างหากจะให้ขอบเขตไฟร์วอลล์ที่ชัดเจนกว่าและการปรับขนาดที่เป็นอิสระ การติดตั้งบนโฮสต์เดียวกันนั้นง่ายกว่า แต่ต้องใช้กฎไฟร์วอลล์ที่ระมัดระวังเพื่อไม่ให้รีเลย์เปิดเผยบริการส่วนตัว

1. ติดตั้ง Coturn และเตรียมรหัสลับร่วมกัน

บน Debian หรือ Ubuntu ให้ติดตั้งแพ็คเกจการแจกจ่าย:

sudo apt update
sudo apt install coturn

แพ็กเกจนี้มีบริการ systemd และไฟล์การกำหนดค่าหลักมักจะเป็น/etc/turnserver.conf. ระบบปฏิบัติการอื่นๆ อาจใช้ชื่อแพ็กเกจ การจัดการบริการ และเส้นทางไฟล์การกำหนดค่าที่แตกต่างกันไป

สร้างความลับที่แข็งแกร่งและเป็นส่วนตัว ตัวอย่างเช่น:

openssl rand -hex 32

ใช้รหัสลับเดียวกันทั้งใน Coturn และ Synapse ปฏิบัติต่อรหัสลับนี้เหมือนรหัสผ่าน: ห้ามนำค่าตัวอย่างจากเอกสารมาใช้ซ้ำ ห้ามบันทึกไว้ในที่เก็บข้อมูลสาธารณะ หรือรวมไว้ในรายงานข้อบกพร่องสาธารณะ หากเวอร์ชัน Synapse ของคุณรองรับturn_shared_secret_pathคุณสามารถจัดเก็บรหัสลับไว้ในไฟล์ที่ได้รับการป้องกันแทนที่จะใส่ไว้ใน YAML โดยตรง Synapse เพิ่มการตั้งค่านี้ในเวอร์ชัน 1.116.0 โปรดตรวจสอบเวอร์ชันที่ใช้งานอยู่ก่อนใช้งาน

2. กำหนดค่า Coturn สำหรับการส่งต่อแบบตรวจสอบสิทธิ์

แก้ไข/etc/turnserver.confและกำหนดชื่อบริการและรหัสลับร่วมสำหรับการตรวจสอบสิทธิ์ แทนที่ตัวยึดตำแหน่งโดเมนและรหัสลับ:

listening-port=3478
tls-listening-port=5349

fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_THE_SAME_RANDOM_SECRET
realm=turn.example.org

min-port=49152
max-port=65535

no-tcp-relay
no-multicast-peers
user-quota=12
total-quota=1200

syslog

use-auth-secretเปิดใช้งานกลไกการรับรองความถูกต้อง TURN แบบจำกัดเวลาที่ Synapse ใช้ อย่ากำหนดค่าการเข้าถึงแบบไม่ระบุตัวตนหรือเปิดเผยรีเลย์แบบเปิด ค่าโควต้าข้างต้นเป็นจุดเริ่มต้นที่ได้มาจากคำแนะนำ Coturn ของ Synapse ปรับค่าเหล่านี้ให้เหมาะสมกับจำนวนผู้ใช้และความจุที่คุณคาดหวังno-tcp-relayป้องกันไม่ให้ไคลเอ็นต์ขอให้รีเลย์เชื่อมต่อกับปลายทาง TCP ที่กำหนดเอง ซึ่งไม่ได้หมายความว่าคุณต้องปิดใช้งาน TCP เป็นการขนส่งจากไคลเอ็นต์ไปยัง TURN

TURN อาจถูกนำไปใช้ในทางที่ผิดเพื่อเป็นรีเลย์ไปยังที่อยู่เครือข่ายภายในหรือที่อยู่เครือข่ายที่ละเอียดอ่อน ควรใช้ช่วงที่อยู่ peer ที่ถูกปฏิเสธทั้งหมดในตัวอย่างความปลอดภัยของ Synapse Coturn ในปัจจุบัน รวมถึงช่วงที่เกี่ยวข้องกับเครือข่าย IPv4 และ IPv6 ของคุณ ตรวจสอบกฎก่อนคัดลอกหากผู้ใช้จำเป็นต้องเข้าถึง peer ในเครือข่ายส่วนตัวอย่างถูกต้อง นอกจากนี้ ควรทำการอัปเดตแพตช์ Coturn อย่างสม่ำเสมอและตรวจสอบบันทึกและโควต้าของระบบด้วย

ตั้งค่าที่อยู่สาธารณะเมื่อ Coturn อยู่เบื้องหลัง NAT

หากโฮสต์ TURN อยู่หลังเราเตอร์ ให้เพิ่มที่อยู่สาธารณะของโฮสต์ลงในการกำหนดค่า เพื่อให้ Coturn ประกาศที่อยู่รีเลย์ที่สามารถเข้าถึงได้:

external-ip=YOUR_PUBLIC_IPV4
listening-ip=YOUR_PRIVATE_IPV4

แทนที่ค่าตัวอย่างด้วยที่อยู่จริง ที่อยู่สำหรับการรับฟังเป็นตัวเลือกเสริม หาก Coturn เชื่อมต่อกับอินเทอร์เฟซที่ถูกต้องอยู่แล้ว ส่งต่อช่วงการรับฟังและการส่งต่อ TURN จากเราเตอร์ไปยังเซิร์ฟเวอร์นี้ ที่อยู่ภายนอกที่ไม่ตรงกันเป็นสาเหตุทั่วไปที่ทำให้การโทรใช้งานได้บน LAN เดียวกัน แต่ล้มเหลวระหว่างเครือข่ายที่แตกต่างกัน

3. เปิดพอร์ตผู้ฟังและพอร์ตรีเลย์

อนุญาตพอร์ตที่ตรงกับการกำหนดค่า Coturn ของคุณทั้งในไฟร์วอลล์ของโฮสต์และไฟร์วอลล์หรือเราเตอร์บนคลาวด์:

• พอร์ต TCP และ UDP 3478 สำหรับตัวรับฟัง TURN ทั่วไป
• ใช้พอร์ต UDP 49152–65535 สำหรับช่วงรีเลย์เริ่มต้นที่แสดงด้านบน หากคุณเลือกช่วงที่แคบกว่า ให้กำหนดค่าช่วงเดียวกันใน Coturn และไฟร์วอลล์ด้วย
• พอร์ต TCP 5349 สำหรับ TURN ผ่าน TLS และพอร์ต UDP 5349 เฉพาะในกรณีที่คุณเปิดใช้งานและตั้งใจที่จะให้บริการ DTLS

สำหรับ UFW ชุดกฎพื้นฐานสำหรับการรับฟัง UDP/TCP และการส่งต่อ UDP สามารถมีลักษณะดังนี้:

sudo ufw allow 3478/tcp
sudo ufw allow 3478/udp
sudo ufw allow 49152:65535/udp

เพิ่มกฎ 5349 เฉพาะเมื่อมีการกำหนดค่าและประกาศตัวรับฟัง TLS หรือ DTLS ที่เกี่ยวข้องแล้วเท่านั้น ตรวจสอบกลุ่มความปลอดภัยของผู้ให้บริการของคุณด้วย กฎ UFW ระดับโฮสต์ไม่สามารถแทนที่กฎการเข้าถึงคลาวด์ที่ถูกบล็อกได้ อย่าเผยแพร่ส่วนติดต่อควบคุมการดูแลระบบของ Coturn ไปยังอินเทอร์เน็ต

4. กำหนดค่า Synapse ให้สร้างข้อมูลรับรอง Coturn

เพิ่มการตั้งค่า TURN ต่อไปนี้ลงในการกำหนดค่า Synapse ที่ใช้งานอยู่ โดยปกติคือhomeserver.yaml. ชื่อโฮสต์ต้องสามารถระบุไปยังโฮสต์ TURN ได้จากภายนอก:

turn_uris:
  - "turn:turn.example.org:3478?transport=udp"
  - "turn:turn.example.org:3478?transport=tcp"
turn_shared_secret: "REPLACE_WITH_THE_SAME_RANDOM_SECRET"
turn_user_lifetime: 1h
turn_allow_guests: true

URI สองรายการแรกเป็นการโฆษณาการขนส่ง TURN ทั่วไปบนพอร์ต 3478 หากมีการกำหนดค่าและทดสอบ TLS แล้ว คุณยังสามารถโฆษณา URI เช่น ได้อีกด้วยturns:turn.example.org:5349?transport=tcpอย่าโฆษณาturns:URI เว้นแต่ว่าใบรับรอง ตัวรับฟัง ไฟร์วอลล์ และความเข้ากันได้ของไคลเอ็นต์จะพร้อมใช้งาน ใบรับรอง TLS และคีย์ส่วนตัวของ Coturn ถูกตั้งค่าด้วยcertและpkeyในไฟล์การกำหนดค่า

ตั้งค่าturn_allow_guestsตามนโยบายห้องพักและผู้เข้าพักของคุณ การเปิดใช้งานอาจอนุญาตให้ผู้ใช้ที่เป็นผู้เข้าพักที่ไม่ได้รับการตรวจสอบสิทธิ์ร้องขอข้อมูลประจำตัว TURN ซึ่งอาจจำเป็นสำหรับการโทรของผู้เข้าพัก แต่ก็อาจเพิ่มความเสี่ยงในการใช้งานในทางที่ผิด การปิดใช้งานอาจทำให้การโทรไม่น่าเชื่อถือสำหรับผู้เข้าพัก ควรใช้การตรวจสอบและการกำหนดโควต้าในทุกกรณี

หลังจากแก้ไขไฟล์เสร็จแล้ว โปรดรีสตาร์ท Coturn และ Synapse:

sudo systemctl restart coturn
sudo systemctl restart matrix-synapse

หากชื่อหน่วย systemd ของ Synapse แตกต่างกัน ให้ใช้ชื่อที่ถูกต้อง รีโหลดหรือรีสตาร์ทไคลเอ็นต์ที่ได้รับผลกระทบ การตั้งค่า TURN ของ Synapse จะได้รับการรีเฟรชเป็นระยะ ดังนั้นไคลเอ็นต์อาจไม่เห็นการเปลี่ยนแปลงทันที

คุณควรเปิดใช้งาน TURN ผ่าน TLS หรือไม่?

เริ่มต้นด้วยการตั้งค่า UDP/TCP TURN บนพอร์ต 3478 และตรวจสอบว่ารีเลย์แคนดิเดตทำงานได้หรือไม่ เพิ่ม TURN ผ่าน TLS เฉพาะในกรณีที่เครือข่ายของผู้ใช้ต้องการ เช่น ไฟร์วอลล์ขององค์กรที่อนุญาตการรับส่งข้อมูลแบบ TLS แต่บล็อก UDP ปกติ TLS ช่วยขยายการเชื่อมต่อ แต่ก็เพิ่มขั้นตอนการต่ออายุใบรับรอง ตัวรับฟังอีกตัว และการตรวจสอบความเข้ากันได้ของไคลเอ็นต์ด้วย

มีข้อควรระวังเฉพาะสำหรับ Matrix: คู่มือ Synapse Coturn ฉบับปัจจุบันเตือนว่า TLS/DTLS ที่ใช้ใบรับรอง Let's Encrypt ไม่ทำงานกับไคลเอนต์ Matrix ที่ใช้ไลบรารี WebRTC ของ Chromium รวมถึง Element Android และ iOS ตามที่ระบุไว้ในคู่มือดังกล่าว ตรวจสอบความเข้ากันได้สำหรับเวอร์ชันไคลเอนต์ของคุณก่อนที่จะเผยแพร่ TLS URI คู่มือเดียวกันนี้แนะนำให้ตั้งค่าบริการพื้นฐานก่อน แล้วค่อยเพิ่ม TLS/DTLS ในภายหลัง

5. ตรวจสอบข้อมูลประจำตัวและทดสอบจากเครือข่ายภายนอก

ขั้นแรก ตรวจสอบว่า Coturn กำลังทำงานอยู่หรือไม่ และตรวจสอบบันทึกการทำงานของโปรแกรม:

sudo systemctl status coturn
sudo journalctl -u coturn -f

จากนั้น จากเซสชันไคลเอ็นต์ Matrix ที่ได้รับการตรวจสอบสิทธิ์แล้ว ให้ตรวจสอบคำขอไปยังปลายทาง API ไคลเอ็นต์-เซิร์ฟเวอร์ปัจจุบันของ Synapse /_matrix/client/v3/voip/turnServerการตอบสนองที่สำเร็จควรประกอบด้วยชื่อผู้ใช้ รหัสผ่าน เวลาหมดอายุ และ URI ของ TURN ที่คุณกำหนดค่าไว้ อย่าเปิดเผยการตอบสนองนั้นต่อสาธารณะ ข้อมูลประจำตัวเหล่านั้นเป็นโทเค็นการเข้าถึงชั่วคราวสำหรับรีเลย์ของคุณ

ใช้ตัวอย่าง WebRTC Trickle ICE อย่างเป็นทางการเพื่อทดสอบด้วยชื่อผู้ใช้และรหัสผ่านที่ได้รับจาก Synapse เพิ่ม TURN URI และข้อมูลประจำตัวของคุณ เรียกใช้การทดสอบการรวบรวม ICE และมองหาผู้สมัครที่มีประเภทเป็นrelayเซิร์ฟเวอร์ที่ตอบสนองต่อ STUN เท่านั้นอาจแสดงผู้สมัครแบบ server-reflexive แต่ยังคงล้มเหลวในการส่งต่อสื่อ ทดสอบจากการเชื่อมต่อมือถือหรือเครือข่ายภายนอก LAN ของคุณ จากนั้นทำการโทรจริงระหว่างผู้เข้าร่วมในเครือข่ายที่แตกต่างกัน

วินิจฉัยความล้มเหลวที่พบบ่อย

• ไม่พบข้อมูลรับรอง TURN:ตรวจสอบว่า Synapse โหลดการกำหนดค่าที่ถูกต้อง รีสตาร์ทสำเร็จ และตั้งค่ารหัสลับร่วมแล้ว ตรวจสอบการตอบสนองคำขอสำหรับ/voip/turnServer.
• ข้อมูลรับรองปรากฏขึ้น แต่ไม่มีแบบฟอร์มผู้สมัครรีเลย์:ตรวจสอบพอร์ต TCP/UDP 3478, ชื่อโฮสต์ที่ประกาศ, การจับคู่รหัสลับ, บันทึก Coturn และช่วงรีเลย์ UDP ผ่านไฟร์วอลล์ทุกตัว
• การโทรใช้งานได้บนเครือข่าย LAN เดียวกัน แต่จะล้มเหลวเมื่อข้ามเครือข่ายอื่น:ตรวจสอบexternal-ipการส่งต่อพอร์ต และเส้นทางการส่งคืน Coturn ต้องประกาศที่อยู่สาธารณะที่ไคลเอนต์สามารถเข้าถึงได้
• การโทรจะเชื่อมต่อได้ก็ต่อเมื่อปิดใช้งาน TLS เท่านั้น:โปรดตรวจสอบห่วงโซ่ใบรับรอง ตัวรับฟัง TLS turns:URI ที่ประกาศ และความเข้ากันได้เฉพาะไคลเอ็นต์
• การโทรแบบปกติใช้งานได้ แต่ Element Call ใช้งานไม่ได้:โปรดตรวจสอบการตั้งค่าการขนส่ง MatrixRTC/LiveKit แยกต่างหาก การทดสอบ Coturn ที่สำเร็จไม่ได้ยืนยัน LiveKit SFU หรือบริการการอนุญาต MatrixRTC

สำหรับไคลเอ็นต์ที่ใช้เบราว์เซอร์ การตรวจสอบ WebRTC ของเบราว์เซอร์สามารถแสดงได้ว่าสื่อเลือกผู้สมัครรีเลย์หรือไม่ สำหรับ MatrixRTC ให้ตรวจสอบว่า Synapse เผยแพร่เอนด์พอยต์การขนส่ง และเส้นทาง WebSocket และการอนุญาตของ LiveKit สามารถเข้าถึงได้ ทดสอบทั้งเอนด์พอยต์ปัจจุบันและเอนด์พอยต์สำรองการค้นหาที่ระบุไว้ในเอกสารซึ่งจำเป็นสำหรับไคลเอ็นต์ที่คุณสนับสนุน

ข้อมูลอ้างอิงการกำหนดค่า

• Synapse: การกำหนดค่าเซิร์ฟเวอร์ TURN
• Synapse: การติดตั้ง Coturn, การรักษาความปลอดภัย, NAT และการกำหนดค่า TLS
• คู่มือการตั้งค่า Synapse สำหรับ TURN และ MatrixRTC
• ตัวอย่างไฟล์ turnserver.conf อย่างเป็นทางการของ Coturn
• คู่มือการโฮสต์ MatrixRTC ด้วยตนเอง (Element Call: Self-hosting guide)
• การติดตั้ง LiveKit และการกำหนดค่า TURN
• อัปเดตจาก Matrix.org เกี่ยวกับการค้นพบการขนส่ง Element Call 0.24
• ข้อกำหนด API ไคลเอ็นต์-เซิร์ฟเวอร์ของ Matrix รวมถึงเอนด์พอยต์ข้อมูลรับรอง TURN