NAT 뒤에 있는 Jitsi용 외부 TURN 서버 구성 방법

가장 중요한 점은 NAT 또는 제한적인 방화벽으로 인해 사용 가능한 WebRTC 경로를 설정할 수 없는 클라이언트를 위해 외부 TURN 서버를 대체 서버로 구성해야 한다는 것입니다. 이는 일반적인 다자간 회의에서 Jitsi Videobridge(JVB)를 대체하는 것이 아닙니다. Jitsi 서버 자체가 NAT 뒤에 있는 경우에도 JVB가 인터넷에서 접근 가능하도록 설정해야 하며(일반적으로 UDP 10000 포트 사용), 브리지의 공용 IP 주소를 올바르게 구성해야 합니다.

현재 Jitsi 배포 환경에서 가장 깔끔한 설계는 일반적으로 공개적으로 접근 가능한 coturn 호스트(예: ` turn.example.com/usr/ unit ...

외부 TURN 서버가 적합한 솔루션인 경우

일부 참가자가 Jitsi 웹 페이지는 열 수 있지만 안정적인 미디어 연결을 설정할 수 없는 경우, 특히 회사 네트워크, 호텔 Wi-Fi, 캠퍼스, 이동통신사, VPN 또는 UDP를 차단하거나 심하게 필터링하는 기타 환경에서 TURN을 사용하십시오. TURN은 또한 P2P 연결이 직접 설정되지 않는 일대일 Jitsi 통화에도 유용합니다.

Jitsi Videobridge 설정 오류를 해결하는 첫 번째 방법으로 TURN을 사용하지 마십시오. Jitsi 공식 Debian/Ubuntu 가이드에 따르면 서버가 NAT 뒤에 있는 경우 라우터에서 필요한 포트를 포워딩해야 하며 브리지에서 로컬 IP 주소를 공용 IP 주소로 명시적으로 매핑해야 할 수 있습니다. 기본적으로 Jitsi에서 사용하는 주요 포트는 TCP 443과 UDP 10000입니다. TURN을 추가하기 전에 최신 Jitsi Debian/Ubuntu 자체 호스팅 가이드를 검토하십시오 .

1단계: 공용 TURN 호스트 및 DNS를 준비합니다.

가장 간단한 토폴로지는 공용 IP 주소를 가진 별도의 VM 또는 서버입니다. turn.example.com해당 호스트로 확인되는 A 또는 AAAA 레코드를 생성합니다. 특히 나중에 TLS를 통한 TURN 서비스를 제공하려는 경우, 인증서가 클라이언트가 사용하는 호스트 이름과 일치해야 하므로 전용 호스트 이름을 사용하는 것이 유용합니다.

TURN 호스트 자체가 NAT 뒤에 있는 경우, coturn은 광고해야 할 공용 IP 주소를 알아야 합니다. coturn은 external-ip`/public/private`과 같은 공용/사설 IP 주소 쌍을 포함한 매핑을 지원합니다 external-ip=203.0.113.10/192.168.1.10. 또한 coturn 문서에는 릴레이 포트가 NAT를 통해 일관되게 매핑되어야 한다고 명시되어 있습니다. 공식 coturn 예제 구성을 참조하십시오 .

2단계: 코턴 설치

지원되는 Debian 또는 Ubuntu 시스템에서는 배포판 저장소에서 coturn을 설치하십시오.

sudo apt update
sudo apt install coturn

패키지 버전은 운영 체제 릴리스에 따라 다르므로 스크린샷이나 다른 서버에서 버전 번호를 복사하지 마십시오. 설치 후 서비스 단위가 있는지, 패키지가 설치되었는지 확인하십시오 turnserver.

3단계: 공유 비밀 키 인증을 위해 coturn을 구성합니다.

Jitsi의 경우, 실제 운영 환경에서는 coturn의 공유 비밀 키 메커니즘을 사용하여 Prosody가 임시 TURN 자격 증명을 생성할 수 있도록 합니다. 양쪽에서 동일한 비밀 키를 사용하십시오. 최소한의 시작점은 다음과 같습니다.

listening-port=3478
tls-listening-port=5349
realm=turn.example.com

fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_SECRET

min-port=49160
max-port=49200

no-multicast-peers
no-cli

TURN 호스트가 NAT 뒤에 있는 경우 적절한 external-ip매핑을 추가하십시오. TLS를 통해 TURN을 활성화하는 경우 신뢰할 수 있는 인증서를 사용하여 cert구성 하십시오. 공식 coturn 컨테이너 문서에서는 TURN이 미디어에 대해 릴레이 포트 범위를 사용하며, 해당 범위는 및 를 사용하여 좁힐 수 있다고 설명합니다 . 동일한 릴레이 포트 동작에 대한 자세한 내용 은 공식 coturn Docker 문서를 참조하십시오 .pkeyturn.example.commin-portmax-port

4단계: 리스너 및 릴레이 포트를 엽니다.

흔히 발생하는 오류는 릴레이 포트 범위를 지정하지 않고 3478 또는 5349 포트만 열어두는 것입니다. Coturn의 리스너는 초기 TURN 연결을 수락하지만, 릴레이되는 미디어는 할당된 릴레이 포트를 사용합니다. 릴레이 포트 범위를 지정했다면 49160-49200호스트 방화벽, 클라우드 보안 그룹 및 상위 NAT에서도 동일한 포트 범위를 허용해야 합니다.

sudo ufw allow 3478/udp
sudo ufw allow 3478/tcp
sudo ufw allow 5349/tcp
sudo ufw allow 49160:49200/udp

보안이 강화된 기업 네트워크와의 폭넓은 호환성이 필요한 경우, Jitsi의 TURN 가이드에서는 TCP 443 포트를 통해 TLS로 TURN을 제공하는 방법을 설명합니다. 이 경우 전용 TURN 호스트 이름이 필요할 수 있으며, 웹 HTTPS가 동일한 공용 IP 주소를 공유하는 경우 TLS SNI 다중화가 필요할 수 있습니다. 해당 포트를 이미 사용하고 있는 서비스가 무엇인지 정확히 파악하지 않은 상태에서 TURN을 443 포트로 무턱대고 이동하지 마십시오.

5단계: Jitsi가 외부 TURN 서비스를 광고하도록 구성합니다.

현재 Debian/Ubuntu Jitsi 패키지 배포 환경에서 Prosody는 mod_external_servicesSTUN/TURN 정보를 클라이언트에 게시하는 데 사용됩니다. Jitsi 자체의 Prosody 예제는 테이블을 사용합니다 external_service_secret. external_services공유 secret = true비밀 키는 coturn의 비밀 키와 일치해야 합니다 static-auth-secret.

external_service_secret = "REPLACE_WITH_THE_SAME_LONG_RANDOM_SECRET";

external_services = {
    { type = "stun", host = "turn.example.com", port = 3478 },
    { type = "turn", host = "turn.example.com", port = 3478,
       transport = "udp", secret = true, ttl = 86400, algorithm = "turn" },
    { type = "turns", host = "turn.example.com", port = 5349,
       transport = "tcp", secret = true, ttl = 86400, algorithm = "turn" }
};

Jitsi에서 생성된 Prosody 파일에 기존 모듈과 사이트별 설정을 그대로 유지하세요. 위 코드 조각으로 파일 전체를 교체하지 마십시오. 파일 이름은 일반적으로 배포 도메인 이름 뒤에 .jtsi.php 파일이 생성됩니다 . Jitsi 구성 예제는 공식 Jitsi 저장소/etc/prosody/conf.d/ 에서 확인할 수 있습니다 .

공식 Docker 배포를 사용하는 경우, 생성된 Prosody 파일을 직접 편집하는 대신 문서화된 환경 변수를 사용하는 것이 좋습니다. 현재 Docker 문서에는 ` @Prosody.config.js` TURN_CREDENTIALS, `@Prosody.config.js` , ` @Prosody.config.js` 및 `@Prosody.config.js` 가 나와 있습니다. 릴리스 간에 변수 기본값이 변경될 수 있으므로 최신 Jitsi Docker 자체 호스팅 가이드를 참조하십시오.TURN_HOSTTURN_PORTTURN_TRANSPORTTURNS_HOSTTURNS_PORT

6단계: 서비스를 재시작하고 유효성을 검사합니다.

coturn을 변경한 후에는 재시작하고 상태를 확인하십시오.

sudo systemctl restart coturn
sudo systemctl status coturn
sudo ss -lntup | grep -E '3478|5349'

Prosody 설정을 변경한 후에는, Prosody 패키지에 구문 검사 도구가 포함되어 있다면 구문 유효성 검사를 수행하고 Prosody를 다시 시작하십시오. Jitsi에서 변경한 내용에 따라 관련 Jitsi 서비스를 다시 시작하는 것도 적절할 수 있습니다.

sudo prosodyctl check config
sudo systemctl restart prosody

coturn 서비스 상태가 정상이라는 것은 데몬이 실행 중이라는 것만을 증명할 뿐입니다. 자격 증명이 일치한다거나, 릴레이 범위에 접근할 수 있다거나, 브라우저가 릴레이 후보를 얻을 수 있다는 것을 증명하는 것은 아닙니다.

7단계: TURN이 실제로 미디어를 전송할 수 있는지 테스트합니다.

동일한 LAN에서 테스트하는 것만으로는 충분하지 않습니다. 다른 네트워크, 이상적으로는 모바일 연결 또는 UDP 사용이 제한된 네트워크에 연결된 클라이언트를 하나 이상 사용하십시오. 브라우저 WebRTC 진단에서 ICE 후보 유형을 찾으십시오 relay. 릴레이 후보는 브라우저가 TURN 자격 증명을 성공적으로 획득하고 TURN 할당을 생성했음을 의미합니다.

테스트 사용자가 접속하는 동안 coturn 로그를 확인하십시오. TURN이 선택된 경우 인증된 할당과 릴레이 트래픽이 표시되어야 합니다. 인증 실패가 발생하는 경우 coturn 로그 static-auth-secret와 Prosody 또는 Docker TURN 자격 증명 암호를 비교하십시오. 할당은 성공했지만 미디어 전송이 계속 실패하는 경우 릴레이 포트 방화벽 및 NAT 매핑을 확인하십시오.

통제된 테스트 사유가 없는 한, 단순히 서버가 존재한다는 것을 증명하기 위해 TURN을 강제로 실행하지 마십시오. 정상적인 상황에서 ICE는 최적의 작동 경로를 선택합니다. 따라서 성공적인 배포 환경에서는 TURN이 전혀 필요하지 않은 회의가 많이 발생할 수 있습니다.

8단계: JVB NAT 구성은 TURN 문제 해결과 분리하여 관리하십시오.

이 부분이 가장 많은 시간 낭비를 막아주는 핵심입니다. NAT 뒤에 있는 Jitsi 서버도 브리지의 공용 연결성을 올바르게 구성해야 합니다. 현재 Jitsi 빠른 시작 가이드에서는 브리지가 일반적으로 자동으로 구성된다고 나와 있지만, 대규모 호출이 실패하는 경우 다음 ice4j.harvest.mapping경로 에 정적 매핑을 추가할 수 있습니다 /etc/jitsi/videobridge/jvb.conf.

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "192.168.1.20"
          public-address = "203.0.113.20"
        }
      ]
    }
  }
}

공용 네트워크에서 JVB 호스트로 UDP 10000 포트를 포워딩하고, 해당 공용 주소가 원격 클라이언트가 실제로 도달할 수 있는 주소인지 확인하십시오. TURN은 제한적인 네트워크 환경에서 클라이언트의 접속을 돕는 데 유용할 수 있지만, JVB NAT 매핑 오류를 숨기는 데 사용해서는 안 됩니다.

빠른 문제 해결 체크리스트

• TURN 호스트 이름이 확인되지 않습니다. Jitsi를 테스트하기 전에 DNS 문제를 해결하십시오.
• 3478/5349 포트는 로컬에서는 수신하지만 원격으로는 수신하지 않습니다. 호스트 방화벽, 클라우드 방화벽, 라우터 NAT 및 공급자 필터링을 확인하십시오.
• 자격 증명 오류: coturn과 Jitsi/Prosody 구성에서 공유 비밀 키가 동일한지 확인하십시오.
• 릴레이 후보는 나타나지만 미디어 전송에 실패합니다. 구성된 릴레이 포트 범위가 종단 간 열려 있는지 확인하십시오.
• 다자간 통화만 실패하는 경우: JVB UDP 10000 및 JVB 공용 주소 광고를 확인하십시오.
• 기업 네트워크에서만 문제가 발생합니다. 적절한 경우 TCP 443 포트를 사용하여 TLS를 통한 TURN을 추가하거나 확인하십시오.
• Docker 변경 사항은 재시작 후 사라집니다..env 컨테이너 내부에서 생성된 파일을 편집하는 대신 지원되는 변수를 구성하세요 .

정확한 결과는 다음과 같습니다.

정상적인 설정에서는 세 가지 동작을 확인할 수 있습니다. 첫째, 일반 사용자는 네트워크 환경에서 TURN 인증 없이 Jitsi Videobridge에 직접 접속할 수 있습니다. 둘째, 네트워크 제한이 있는 사용자는 임시 TURN 인증 정보를 받아 relayICE 후보를 생성할 수 있습니다. 셋째, coturn은 기본적으로 모든 회의를 처리하는 대신 필요한 경우에만 인증된 할당을 표시합니다.

이러한 조합은 TURN 서버를 불필요한 대역폭 병목 현상으로 만들지 않고도 유용한 대체 기능을 제공합니다. 또한 문제 해결을 간소화합니다. JVB NAT 문제는 JVB 문제로 남고, TURN은 직접 경로가 차단될 때 WebRTC 연결이라는 보다 구체적인 문제를 해결합니다.