วิธีการติดตั้ง Jitsi Meet บน Ubuntu 24.04 โดยใช้ Let's Encrypt SSL

การติดตั้ง Jitsi Meet บน Ubuntu 24.04 นั้นทำได้ง่าย หากชื่อ DNS, ไฟร์วอลล์ และแผน TLS ถูกต้องก่อนที่จะเรียกใช้ตัวติดตั้งแพ็กเกจ คู่มือการติดตั้ง Jitsi ด้วยตนเองอย่างเป็นทางการ ซึ่งอัปเดตล่าสุดเมื่อวันที่ 10 สิงหาคม 2026 รองรับ Ubuntu 22.04 หรือใหม่กว่า ดังนั้น Ubuntu 24.04 LTS จึงอยู่ในช่วงการสนับสนุนที่ระบุไว้ในเอกสาร คู่มือเดียวกันนี้แนะนำให้ใช้ใบรับรอง TLS ที่เชื่อถือได้ และแนะนำ Let's Encrypt เป็นตัวเลือกใบรับรองที่ต้องการระหว่างการติดตั้ง

คู่มือนี้ใช้meet.example.orgชื่อโฮสต์เป็นตัวอย่าง โปรดแทนที่ทุกที่ด้วยชื่อโดเมนแบบเต็มที่ชี้ไปยังเซิร์ฟเวอร์ของคุณจริง ๆ

ควรเตรียมอะไรบ้างก่อนติดตั้ง Jitsi Meet?

คุณควรมีเซิร์ฟเวอร์ Ubuntu 24.04 ที่มีสิทธิ์ sudo, ชื่อ DNS สาธารณะ และการเข้าถึงเครือข่ายขาเข้าสำหรับพอร์ตที่ Jitsi ต้องการ Jitsi เป็นบริการ WebRTC แบบเรียลไทม์ ดังนั้นเซิร์ฟเวอร์ที่สามารถให้บริการเว็บเพจได้ แต่ไม่สามารถรับข้อมูลสื่อผ่าน UDP ได้ จึงไม่ใช่การติดตั้งใช้งานที่สมบูรณ์

• Ubuntu 24.04 LTS พร้อมสิทธิ์การเข้าถึงระดับผู้ดูแลระบบ
• ระเบียน DNS เช่นmeet.example.orgระเบียนที่ชี้ไปยังที่อยู่ IPv4 สาธารณะของเซิร์ฟเวอร์
• พอร์ต TCP 80 และ 443 สามารถเข้าถึงได้จากอินเทอร์เน็ต
• พอร์ต UDP 10000 สามารถใช้งานได้สำหรับการรับส่งข้อมูลสื่อของ Jitsi ตามปกติ
• การเข้าถึง SSH โดยปกติจะใช้พอร์ต TCP 22 เว้นแต่คุณจะเปลี่ยนพอร์ต
• มีอำนาจควบคุมเพียงพอในไฟร์วอลล์คลาวด์ต้นทาง กลุ่มความปลอดภัย เราเตอร์ หรืออุปกรณ์ NAT เพื่อส่งต่อพอร์ตเดียวกัน

เอกสารของ Jitsi ยังระบุว่าใช้ UDP 3478 สำหรับการสอบถาม STUN เมื่อเปิดใช้งาน และ TCP 5349 สำหรับการรับส่งข้อมูลสำรอง TURN หากเซิร์ฟเวอร์อยู่หลัง NAT การกำหนดค่าไฟร์วอลล์ต้องถูกต้องทั้งบน Ubuntu และบนเราเตอร์หรือเครือข่ายคลาวด์

จำเป็นต้องตรวจสอบชื่อโฮสต์ก่อนหรือไม่ จึงจะสามารถใช้ Let's Encrypt ได้?

ใช่ครับ สร้างระเบียน DNS ก่อน แล้วรอจนกว่าตัวแก้ไขสาธารณะจะส่งคืนที่อยู่สาธารณะของเซิร์ฟเวอร์ Let's Encrypt ต้องสามารถตรวจสอบความถูกต้องของการควบคุมชื่อโฮสต์ได้ และการกำหนดค่า Nginx ของ Jitsi ก็จะใช้ชื่อโฮสต์นั้นด้วย

สำหรับการใช้งานทั่วไป ให้สร้างเรคอร์ด A:

จากฝั่งเซิร์ฟเวอร์ ตรวจสอบว่าชื่อถูกต้องตามที่คาดไว้หรือไม่:

getent ahostsv4 meet.example.org

หากได้ที่อยู่ที่ไม่ถูกต้อง ให้หยุดตรงนี้และแก้ไข DNS การออกใบรับรองก่อนที่ DNS จะถูกต้องมักจะทำให้เกิดข้อผิดพลาดในการตรวจสอบที่สามารถหลีกเลี่ยงได้

ต้องใช้แพ็กเกจพื้นฐานและที่เก็บซอฟต์แวร์ของ Ubuntu ใดบ้าง?

คู่มือ Jitsi สำหรับ Debian/Ubuntu ฉบับปัจจุบัน ระบุว่าต้องใช้ gnupg2, nginx-full, curlหรือwget, และsudoเมื่อใช้ sudo นอกจากนี้ยังระบุว่าต้องใช้ OpenJDK 17 ด้วย Jitsi ขึ้นอยู่กับแพ็กเกจจากuniverseคลังแพ็กเกจ ของ Ubuntu

sudo apt update
sudo apt install apt-transport-https
sudo add-apt-repository universe
sudo apt update
sudo apt install gnupg2 nginx-full curl

แพ็กเกจ นี้apt-transport-httpsยังคงอยู่ที่นี่เพราะยังคงอยู่ในคำแนะนำเริ่มต้นใช้งาน Jitsi ฉบับปัจจุบัน บน Ubuntu รุ่นใหม่ การส่งข้อมูลผ่าน HTTPS ได้ถูกรวมเข้ากับ APT แล้ว ดังนั้นการติดตั้งแพ็กเกจนั้นอาจเป็นเพียงขั้นตอนเพื่อความเข้ากันได้มากกว่าการเปิดใช้งานคุณสมบัติที่ไม่มีอยู่เดิม

คุณจะเพิ่ม repositories ของ Prosody และ Jitsi ได้อย่างไร?

Jitsi ใช้ Prosody สำหรับการส่งสัญญาณ XMPP คู่มือเริ่มต้นใช้งานฉบับย่ออย่างเป็นทางการในปัจจุบันแนะนำให้ผู้ดูแลระบบเพิ่มทั้งที่เก็บแพ็กเกจ Prosody และที่เก็บแพ็กเกจ Jitsi เวอร์ชันเสถียร

sudo curl -sL https://prosody.im/files/prosody-debian-packages.key   -o /usr/share/keyrings/prosody-debian-packages.key

echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" |   sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list

sudo apt install lua5.2

curl -sL https://download.jitsi.org/jitsi-key.gpg.key |   sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'

echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" |   sudo tee /etc/apt/sources.list.d/jitsi-stable.list

sudo apt update

อย่าใช้ PPA ของบุคคลที่สามที่ไม่เกี่ยวข้องมาแทนที่แหล่งเก็บแพ็กเกจเหล่านี้ การใช้แหล่งเก็บแพ็กเกจที่ Jitsi ได้ระบุไว้จะช่วยลดความเสี่ยงในการใช้แพ็กเกจ Jitsi, Prosody และ Ubuntu ที่ไม่เข้ากัน

ควรเปิดพอร์ตไฟร์วอลล์ใดบ้างก่อนการติดตั้ง?

เปิดพอร์ตที่จำเป็นก่อนขอใบรับรอง เพื่อให้การตรวจสอบ HTTP สามารถเข้าถึงเซิร์ฟเวอร์และการรับส่งข้อมูลสื่อสามารถเกิดขึ้นได้หลังการติดตั้ง สำหรับ UFW คู่มือ Jitsi ฉบับปัจจุบันได้กำหนดกฎเหล่านี้ไว้:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 22/tcp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable
sudo ufw status verbose

หาก SSH ใช้พอร์ตอื่น ให้กำหนดพอร์ตนั้นแทนที่จะเพิ่ม TCP 22 โดยไม่ตรวจสอบให้ดี บนเครื่องเสมือนบนคลาวด์ ให้คัดลอกกฎที่จำเป็นไปยังไฟร์วอลล์หรือกลุ่มความปลอดภัยของผู้ให้บริการ บนเซิร์ฟเวอร์ที่อยู่หลังเราเตอร์ ให้ส่งต่อพอร์ตที่จำเป็นไปยังโฮสต์ Ubuntu

วิธีการติดตั้ง Jitsi Meet และเลือกใช้ Let's Encrypt ทำอย่างไร?

ติดตั้ง metapackage จาก repository ของ Jitsi:

sudo apt install jitsi-meet

โปรแกรมติดตั้งจะขอชื่อโฮสต์ของ Jitsi ป้อนชื่อ DNS สาธารณะ เช่นmeet.example.orgเอกสาร Jitsi ฉบับปัจจุบันระบุว่า การติดตั้งจะแสดงตัวเลือกใบรับรอง SSL/TLS และแนะนำให้ใช้ตัวเลือก Let's Encrypt เลือกใบรับรอง Let's Encryptเมื่อตัวเลือกนั้นปรากฏขึ้น

วิธีนี้ดีกว่าการใช้สคริปต์ใบรับรองแบบสแตนด์อโลนรุ่นเก่าเป็นขั้นตอนสากล คู่มือเริ่มต้นใช้งานฉบับย่อในปัจจุบันจะเน้นการเลือกใบรับรองในขั้นตอนการติดตั้งแพ็กเกจ หากแพ็กเกจที่ติดตั้งของคุณทำงานแตกต่างจากเอกสารปัจจุบัน อย่าสร้างเส้นทางเอง: ตรวจสอบข้อความแจ้งเตือนของแพ็กเกจและเอกสาร Jitsi เฉพาะเวอร์ชันก่อนที่จะแก้ไข Nginx หรือไฟล์ใบรับรองด้วยตนเอง

คุณจะยืนยันได้อย่างไรว่า HTTPS และหน้าการประชุมใช้งานได้?

เปิดhttps://meet.example.orgจากเบราว์เซอร์ภายนอกเซิร์ฟเวอร์ การติดตั้งที่สำเร็จควรแสดงหน้า Jitsi Meet โดยไม่มีคำเตือนเกี่ยวกับใบรับรองของเบราว์เซอร์ สร้างห้องชั่วคราวและเข้าร่วมจากอุปกรณ์หรือเครือข่ายอื่น

การทดสอบกับไคลเอ็นต์คนที่สองนั้นสำคัญ เพราะการโหลดหน้า Landing Page นั้นพิสูจน์ได้เพียงว่า HTTPS ทำงานได้ แต่ไม่ได้พิสูจน์ว่าการรับส่งข้อมูลสื่อของ Jitsi Videobridge สามารถเข้าถึงได้ หากผู้เข้าร่วมสองคนสามารถเข้าร่วมได้ แต่ไม่ได้ยินหรือเห็นกันและกัน ให้ตรวจสอบ UDP 10000 และกฎ NAT หรือไฟร์วอลล์บนคลาวด์ก่อน

หลังจากติดตั้งเสร็จแล้ว ควรตรวจสอบบริการใดบ้าง?

Jitsi Meet ประกอบด้วยส่วนประกอบหลายอย่าง ไม่ใช่บริการแบบครบวงจรเพียงอย่างเดียว ส่วนประกอบทั่วไปในการติดตั้งแบบแพ็กเกจ ได้แก่ Nginx, Prosody, Jicofo และ Jitsi Videobridge ตรวจสอบรายละเอียดของแต่ละส่วนประกอบได้ที่นี่:

sudo systemctl --no-pager --full status nginx prosody jicofo jitsi-videobridge2

คุณสามารถตรวจสอบซ็อกเก็ตการฟังได้เช่นกัน:

sudo ss -lntup | grep -E ':80|:443|:10000'

หากบริการใดไม่ทำงาน ให้ตรวจสอบบันทึกของบริการนั้นก่อนที่จะติดตั้งแพ็กเกจซ้ำหลายครั้ง คู่มือเริ่มต้นใช้งาน Jitsi ชี้ให้ผู้ดูแลระบบไปที่/var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.log, และ/var/log/prosody/prosody.logสำหรับการแก้ไขปัญหา โดยเฉพาะ

แล้วถ้าเซิร์ฟเวอร์อยู่หลัง NAT ล่ะ?

เอกสารของ Jitsi ระบุว่าโดยปกติแล้ว Videobridge ควรจะตั้งค่าตัวเองโดยอัตโนมัติเมื่อบูตเครื่องในกรณีที่เซิร์ฟเวอร์อยู่หลัง NAT โดยมีเงื่อนไขว่าพอร์ตที่จำเป็นได้รับการส่งต่อแล้ว หากการโทรแบบสามทางยังคงล้มเหลว คู่มือนี้ได้บันทึกการแมปที่อยู่แบบคงที่จากที่อยู่ภายในไปยังที่อยู่สาธารณะไว้ใน/etc/jitsi/videobridge/jvb.conf:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "<Local.IP.Address>"
          public-address = "<Public.IP.Address>"
        }
      ]
    }
  }
}

ใช้การตั้งค่านี้เฉพาะเมื่อตรงกับโครงสร้างเครือข่ายของคุณเท่านั้น VM ที่โฮสต์อยู่ซึ่งกำหนดที่อยู่ IP สาธารณะโดยตรงอาจไม่จำเป็นต้องทำการแมป ในขณะที่ VM ส่วนตัวที่อยู่เบื้องหลัง NAT แบบหนึ่งต่อหนึ่งหรือเราเตอร์ในบ้านอาจจำเป็นต้องทำการแมป

เซิร์ฟเวอร์ Jitsi ที่เปิดให้ใช้งานผ่านอินเทอร์เน็ต ควรอนุญาตให้ทุกคนสร้างห้องได้หรือไม่?

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

รายการตรวจสอบการแก้ไขปัญหาอย่างรวดเร็ว

การติดตั้งใช้งาน Ubuntu 24.04 ที่ประสบความสำเร็จควรมีลักษณะอย่างไร?

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

สำหรับรายละเอียดการติดตั้งในปัจจุบัน โปรดดูคู่มือการติดตั้ง Jitsi บน Debian/Ubuntu อย่างเป็นทางการสำหรับคำแนะนำด้านสถาปัตยกรรมและการใช้งานที่ครอบคลุมมากขึ้น โปรดดูภาพรวมการติดตั้ง Jitsi อย่างเป็นทางการหากผู้ใช้จำเป็นต้องเชื่อมต่อผ่านเครือข่ายที่มีข้อจำกัด โปรดตรวจสอบเอกสารการกำหนดค่า TURN อย่างเป็นทางการ ของ Jitsi