Wie man Bedrud bereitstellt, wenn sich Ihr Server hinter einem Reverse-Proxy oder CDN befindet. Dies ist ein gängiges Produktions-Setup, aber WebRTC (LiveKit) erfordert eine spezielle Handhabung, da CDNs keinen UDP-Medienverkehr per Proxy weiterleiten können.

Das Problem (The Problem)

Bedrud besteht aus zwei netzwerkseitigen Komponenten mit unterschiedlichen Anforderungen:

Ein Standard-Proxy wie Cloudflare, nginx oder Traefik verarbeitet HTTP/HTTPS-Verkehr problemlos. Aber die WebRTC-Medien von LiveKit fließen über UDP-Ports, die diese Proxies stillschweigend verwerfen (drop) oder nicht weiterleiten können.

Browser ──HTTP/WS──► CDN ──HTTP/WS──► Bedrud Server    ✓ Funktioniert
Browser ──UDP────────► CDN ──X─────────► LiveKit        ✗ Verworfene Pakete
Browser ──UDP─────────────────────────► LiveKit         ✓ Direkt

Bereitstellungsoptionen (Deployment Options)

Option 1: Separate LiveKit-Domain (Empfohlen)

Verwenden Sie zwei DNS-Einträge: einen für den Bedrud-Server (proxied) und einen für LiveKit (nur DNS).

meet.example.com     → A-Eintrag → CDN-Proxy (Orange Cloud) → Bedrud-Server
lk.meet.example.com  → A-Eintrag → Nur DNS (Grey Cloud)     → Gleicher Server

Der Installer verarbeitet dies, wenn Sie “Behind proxy” auswählen und eine LiveKit-Subdomain angeben.

Schritte:

1. Führen Sie den Installer aus und beantworten Sie die Proxy/CDN-Fragen:

   curl -fsSL https://bedrud.org/install.sh | bash

   • “Running behind a proxy/CDN?” → Yes
   • “What type?” → cloudflare
   • “Use a separate subdomain for LiveKit?” → Yes
   • Geben Sie lk.meet.example.com als LiveKit-Subdomain ein
   • Geben Sie die echte öffentliche IP Ihres Servers (nicht die CDN-IP) für LiveKit ein

2. Erstellen Sie bei Ihrem DNS-Anbieter:

   • meet.example.com → durch CDN geleitet (proxied)
   • lk.meet.example.com → Nur DNS (Grey Cloud), zeigt auf die echte IP Ihres Servers

3. Öffnen Sie die erforderlichen Ports in Ihrer Firewall:

   sudo ufw allow 7880/tcp    # LiveKit-API
   sudo ufw allow 7881/tcp    # RTC-TCP-Fallback
   sudo ufw allow 50000:60000/udp  # WebRTC-Medien
   sudo ufw allow 3478/udp    # TURN-Relay
   sudo ufw allow 5349/tcp    # TURN-TLS (falls TLS verwendet wird)

Warum dies funktioniert: Der Browser verbindet sich direkt über lk.meet.example.com mit LiveKit und umgeht das CDN vollständig. Der WebRTC-UDP-Verkehr fließt direkt zu Ihrem Server. Die Bedrud-Web-UI profitiert weiterhin von CDN-Caching und DDoS-Schutz.

Option 2: Externer LiveKit-Server

Betreiben Sie LiveKit auf einer separaten Maschine, die sich nicht hinter einem Proxy befindet.

Browser ──► CDN ──► Bedrud Server ──API──► LiveKit Server
Browser ──────────────────────────────────► LiveKit Server

Schritte:

1. Richten Sie einen LiveKit-Server auf einer separaten Maschine ein (siehe LiveKit-Dokumentation)

2. Führen Sie den Bedrud-Installer aus und wählen Sie “external LiveKit server”:

   bedrud install \
     --domain meet.example.com \
     --behind-proxy \
     --external-livekit https://lk.example.com \
     --email admin@example.com

3. Stellen Sie sicher, dass die Ports des LiveKit-Servers offen und für Clients erreichbar sind.

Option 3: Gleiche IP, unterschiedliche Konfiguration (Eingebettetes LK mit expliziter NodeIP)

Wenn Sie keine separate Domain verwenden können, können Sie LiveKit eingebettet lassen und explizit die echte Server-IP für WebRTC ICE-Kandidaten festlegen. Die Signalisierung (WebSocket) geht immer noch durch das CDN, aber die Medien (UDP) umgehen es.

Browser ──WS/Signalisierung──► CDN ──► Bedrud Server ──► Eingebettetes LiveKit
Browser ──UDP-Medien────────────────────► Server-IP (direkt)

Schritte:

1. Führen Sie den Installer aus:

   bedrud install \
     --domain meet.example.com \
     --behind-proxy \
     --lk-ip YOUR_REAL_SERVER_IP \
     --lk-udp-range 50000-60000

2. Öffnen Sie die WebRTC-Ports in Ihrer Firewall:

   sudo ufw allow 50000:60000/udp
   sudo ufw allow 7881/tcp
   sudo ufw allow 3478/udp

Einschränkungen:

• Clients müssen in der Lage sein, die echte IP Ihres Servers über UDP-Ports zu erreichen
• WebSocket-Signalisierung läuft über das CDN (unterliegt idle timeouts)
• Weniger zuverlässig als Option 1 oder 2

Cloudflare-spezifische Hinweise

DNS-Setup

WebSocket-Timeouts

Cloudflare Free- und Pro-Tarife haben ein 100-sekündiges Leerlauf-Timeout (idle timeout) für WebSocket-Verbindungen. Wenn ein Benutzer in einem Raum ohne aktive Signalisierung bleibt, kann die Verbindung unterbrochen werden. Dies verursacht einen Reconnect – Audio/Video erholen sich normalerweise, aber es kann störend sein.

Abhilfe: Konfigurieren Sie LiveKit Keep-Alive-Intervalle in livekit.yaml:

rtc:
  peer_connection_configs:
    - video_codec: H264
  # Keepalive hilft, Leerlauf-Unterbrechungen durch das CDN zu verhindern

Cache-Regeln

Stellen Sie sicher, dass Cloudflare LiveKit-API-Antworten nicht zwischenspeichert. Erstellen Sie eine Cache-Regel:

• URL-Muster: lk.yourdomain.com/twirp/*
• Cache-Level: Bypass

WAF-Ausnahmen

Wenn Ihr Bedrud-Server Backend-API-Aufrufe an LiveKit über das CDN tätigt (selten bei separaten Domains), kann die WAF von Cloudflare diese Anfragen herausfordern oder blockieren. Anfragen. Fügen Sie eine WAF-Ausnahme für die IP-Adresse Ihres Servers hinzu.

DDoS-Schutz

Bei Verwendung von “Nur DNS” (Grey Cloud) für die LiveKit-Domain erhält diese Subdomain keinen DDoS-Schutz von Cloudflare. Die integrierte Ratenbegrenzung (rate limiting) und Authentifizierung (API-Schlüssel) von LiveKit bieten einen gewissen Schutz. Für zusätzliche Sicherheit sollten Sie Folgendes in Betracht ziehen:

• Verwendung der Option --external-livekit mit einer dedizierten LiveKit-Maschine hinter einer separaten Firewall
• Beschränkung des LiveKit-API-Zugriffs auf die IP Ihres Bedrud-Servers mittels Firewall-Regeln

nginx Reverse-Proxy

Wenn Sie nginx als Reverse-Proxy (nicht CDN) verwenden, müssen Sie den Bedrud-Server per Proxy weiterleiten, aber den LiveKit-Verkehr direkt durchlassen.

nginx-Konfiguration nur für den Bedrud-Server

server {
    listen 443 ssl http2;
    server_name meet.example.com;
 
    ssl_certificate     /etc/letsencrypt/live/meet.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/meet.example.com/privkey.pem;
 
    location / {
        proxy_pass http://127.0.0.1:8090;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
 
    # WebSocket-Unterstützung (falls LiveKit-Signalisierung über nginx geleitet wird)
    location /livekit {
        proxy_pass http://127.0.0.1:7880;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 86400;
    }
}

Wichtig: UDP-Medien benötigen weiterhin direkten Zugriff

Selbst mit nginx läuft der WebRTC-UDP-Medienverkehr nicht über nginx. Clients verbinden sich direkt mit der LiveKit NodeIP über UDP-Ports. Sie müssen weiterhin:

1. Die UDP-Ports 50000-60000 (oder Ihren konfigurierten Bereich) in der Firewall öffnen
2. Sicherstellen, dass in der livekit.yaml die korrekte node_ip auf die öffentliche IP Ihres Servers eingestellt ist
3. Das Flag --behind-proxy bei der Installation verwenden, damit der Server Proxy-Headern vertraut

bedrud install \
  --domain meet.example.com \
  --behind-proxy \
  --lk-ip YOUR_REAL_SERVER_IP \
  --lk-udp-range 50000-60000

Erforderliche Firewall-Ports

Eingebetteter Modus (keine separate LK-Domain): Nur 7881/tcp, 50000-60000/udp und 3478/udp müssen offen sein. Port 7880 wird über den Bedrud-Server geleitet.

Fehlerbehebung (Troubleshooting)

Benutzer können Räumen beitreten, aber Audio/Video funktioniert nicht

Ursache: UDP-Medienverkehr erreicht den LiveKit-Server nicht.

1. Überprüfen Sie, ob die WebRTC-UDP-Ports offen sind:

   sudo ss -ulnp | grep -E '(7882|50000|3478)'

2. Überprüfen Sie, ob node_ip in /etc/bedrud/livekit.yaml Ihre echte öffentliche Server-IP ist
3. Falls hinter CDN, stellen Sie sicher, dass die LiveKit-Domain “Nur DNS” (Grey Cloud) verwendet

WebSocket-Verbindung wird alle ca. 100 Sekunden unterbrochen

Ursache: Cloudflare Leerlauf-Timeout in Free/Pro-Tarifen.

Lösungen:

• Verwenden Sie eine separate LiveKit-Domain (nur DNS) – Signalisierung erfolgt direkt, kein Timeout
• Upgrade auf Cloudflare Business oder Enterprise (längere WebSocket-Timeouts)

LiveKit ICE-Kandidaten zeigen CDN-IP anstelle der Server-IP

Ursache: node_ip ist in der livekit.yaml nicht korrekt eingestellt.

Lösung:

# Aktuelle Konfiguration prüfen
grep node_ip /etc/bedrud/livekit.yaml
 
# Falls falsch, mit korrekter IP neu installieren
bedrud install --fresh --lk-ip YOUR_REAL_SERVER_IP

Clients können sich überhaupt nicht mit LiveKit verbinden

1. Überprüfen Sie, ob der LiveKit-Dienst läuft:

   systemctl status livekit
   journalctl -u livekit -n 50

2. Überprüfen Sie die Port-Bindung:

   ss -tlnp | grep 7880
   ss -tlnp | grep 7881

3. Bei Verwendung einer separaten LK-Domain DNS-Auflösung prüfen:

   dig +short lk.meet.example.com
   # Sollte Ihre echte Server-IP zurückgeben, nicht eine CDN-IP