Powinieneś skonfigurować zaporę ogniową przed Instalacją BigBlueButton; w przeciwnym razie podczas instalacji mogą pojawić się błędy i nie będzie można przetestować BigBlueButton po zakończeniu instalacji.
Jeśli jesteś programistą konfigurującym BigBlueButton na lokalnej maszynie wirtualnej do testów, możesz pominąć tę sekcję.
Przegląd
Najłatwiejsza konfiguracja sieciowa do instalacji BigBlueButton odbywa się na serwerze z jednym zewnętrznym adresem IP, a serwer znajduje się w publicznym Internecie (a zatem jest bezpośrednio dostępny dla Twoich użytkowników). Zapora dostępu oparta na portach jest implementowana przy użyciu UFW. Oto przykład takiej konfiguracji z serwerem BigBlueButton posiadającym (fikcyjny) adres IP 203.0.113.1 i nazwę hosta bigbluebutton.example.com.
W tej prostej konfiguracji sieci BigBlueButton powinien działać od razu po instalacji. Dzieje się tak, ponieważ skrypty pakujące automatycznie konfigurują BigBlueButton przy użyciu pierwszego adresu IP bez sprzężenia zwrotnego, podczas gdy dostęp do wrażliwych portów jest blokowany.
Odmiana tej konfiguracji ma miejsce, gdy serwer ma wiele interfejsów sieciowych, ale zewnętrzny adres IP jest nadal pierwszym interfejsem sieciowym (takim jak eth0) odbieranym przez skrypty instalacyjne.
Jeśli Twój serwer ma eth0 wskazujący zewnętrzny adres IP w Internecie i nie ma na nim zewnętrznej zapory ogniowej, wówczas skrypty pakujące powinny wykryć ten zewnętrzny adres IP i odpowiednio skonfigurować BigBlueButton. Nie musisz wprowadzać żadnej z poniższych zmian.
Nie martw się, jeśli adres IP Twojego serwera ulegnie zmianie, BigBlueButton jest wyposażony w narzędzie konfiguracyjne o nazwie bbb-conf, które pozwala Ci zmienić wszystkie pliki konfiguracyjne BigBlueButton tak, aby używały dowolnego adresu IP lub nazwy hosta.
Jeśli między użytkownikami a serwerem BigBlueButton istnieje translacja adresów sieciowych IPv4 (NAT), należy najpierw skonfigurować zaporę ogniową, aby przekazywała określone połączenia TCP/UDP od klientów zewnętrznych do wewnętrznego serwera BigBlueButton; w przeciwnym razie użytkownicy nie będą mogli uzyskać dostępu do BigBlueButton.
Poniższy diagram przedstawia typową konfigurację z zewnętrzną zaporą ogniową (twoja konfiguracja będzie oczywiście miała inny adres IP i nazwy hostów).
W tym przykładzie wszyscy użytkownicy muszą połączyć się z serwerem BigBlueButton poprzez jednolity lokalizator zasobów (URL) https://bigbluebutton.example.com/. Ta nazwa hosta jest tłumaczona na adres IP 203.0.113.1, który jest zaporą sieciową. Zapora sieciowa musi przekazywać określone połączenia (opisane poniżej) do serwera BigBlueButton działającego pod adresem IP 10.0.2.12.
Skonfiguruj zaporę sieciową
Gdy BigBlueButton jest chroniony za zaporą ogniową, musisz skonfigurować zaporę tak, aby przekazywała następujące połączenia przychodzące do BigBlueButton:
- Port TCP/IP 22 (dla SSH)
- Porty TCP/IP 80/443 (dla HTTP/HTTPS)
- Porty UDP z zakresu 16384 - 32768 (dla strumieni LiveKit/FreeSWITCH/HTML5 RTP)
LiveKit ponownie wykorzystuje powyższy zakres UDP dla swoich strumieni multimediów (RTP); jego sygnalizacja to proxy przez istniejący punkt końcowy HTTPS nginx (TCP 443), więc nie są potrzebne żadne dodatkowe porty .
EC2
Jeśli używasz EC2, powinieneś także przypisać swojemu serwerowi Elastyczny adres IP, aby zapobiec uzyskaniu nowego adresu IP przy ponownym uruchomieniu.
Azure
Na platformie Microsoft Azure podczas tworzenia instancji należy dodać następujące reguły portów przychodzących, aby umożliwić połączenia przychodzące na portach 80, 443 i zakresie portów UDP 16384-32768:
Google Compute Engine
W Google Compute Engine podczas tworzenia instancji należy włączyć ruch na portach 80 i 443.
Po utworzeniu instancji należy dodać regułę zapory sieciowej, aby umożliwić przychodzący ruch UDP na zakresie portów 16384-32768.
Testowanie zapory
Po dokonaniu zmian w ustawieniach zapory, przed przystąpieniem do instalacji, poświęć chwilę i sprawdź, czy skonfigurowałeś zaporę sieciową, aby poprawnie przekierowywała powyższe połączenia (pozwoli to zaoszczędzić czas później, jeśli napotkasz problemy).
Aby przetestować połączenia na różnych portach wymaganych przez BigBlueButton, użyjesz narzędzia o nazwie netcat do nasłuchiwania połączeń. Będziesz używać netcat na serwerze BigBlueButton i na serwerze zewnętrznym (poza zaporą sieciową) do generowania połączeń. Jeśli test połączenia zakończy się niepowodzeniem, oznacza to, że zapora przekazuje pakiety.
Najpierw zainstaluj netcat na BigBlueButton za pomocą następującego polecenia:
$ sudo apt-get install netcat
Następnie zatrzymaj BigBlueButton komendą sudo bbb-conf --stop. Zwalnia to porty, które chcemy przetestować. Możemy teraz uruchomić netcat, aby nasłuchiwać na portach i spróbować połączyć się z komputera zewnętrznego. Jako root uruchom następującą komendę:
$ netcat -l 443
netcat będzie teraz wysyłał do terminala echo dowolnego tekstu otrzymanego na porcie 443 (możesz później zakończyć polecenie, używając Ctrl-c).
Następnie na drugim komputerze, który znajduje się poza zaporą sieciową — to znaczy musi przejść przez zaporę, aby uzyskać dostęp do serwera BigBlueButton — zainstaluj również netcat. Zastąp EXTERNAL_HOST_NAME nazwą hosta swojej zapory ogniowej i uruchom następującą komendę
$ netcat EXTERNAL_HOST_NAME 443
i wpisz słowo „test” i naciśnij ENTER.
Jeśli zapora sieciowa przekazuje połączenia przychodzące na porcie 443 do wewnętrznego serwera BigBlueButton, po poleceniu netcat -l 443 powinieneś zobaczyć słowo „test”, tak jak w
$ netcat -l 443
test
Jeśli słowo test nie pojawi się, sprawdź dwukrotnie konfigurację zapory, aby upewnić się, że połączenia przekierowujące są na porcie 443, a następnie przetestuj ponownie. Chcesz, aby przed przystąpieniem do instalacji BigBlueButton pojawiło się słowo test.
Powtórz te testy z portem 80.
Dotyczy to portów TCP/IP. Następnie musimy sprawdzić, czy połączenia UDP w zakresie 16384-32768 są również przekazywane. Na serwerze BigBlueButton uruchom następującą komendę netcat, aby nasłuchiwać danych przychodzących przez UDP na porcie 17000 (tutaj wybieramy port z zakresu 16384-32768).
$ netcat -u -l 17000
Ponownie na komputerze poza zaporą zastąp EXTERNAL_HOST_NAME nazwą hosta swojej zapory i uruchom polecenie
$ netcat -u EXTERNAL_HOST_NAME 17000
Wpisz „test2” w terminalu i naciśnij ENTER. Powinieneś zobaczyć słowo „test2” na terminalu serwera BigBlueButton, jak w
$ netcat -u -l 17000
test2
Tak jak poprzednio, jeśli powyższy test zakończy się niepowodzeniem, sprawdź dwukrotnie ustawienia zapory sieciowej, aby upewnić się, że prawidłowo przepuszcza pakiety UDP w zakresie 16384-32768 i przetestuj ponownie.
Kiedy BigBlueButton działa na serwerze, różne komponenty BigBlueButton muszą nawiązywać połączenia ze sobą przy użyciu zewnętrznej nazwy hosta. Programy działające na serwerze BigBlueButton, które próbują połączyć się z zewnętrzną nazwą hosta, powinny dotrzeć do samego BigBlueButton.
Aby umożliwić serwerowi BigBlueButton łączenie się ze sobą przy użyciu zewnętrznej nazwy hosta, edytuj plik /etc/hosts i dodaj linię
EXTERNAL_IP_ADDRESS EXTERNAL_HOST_NAME
gdzie EXTERNAL_IP_ADDRESS to zewnętrzny adres IP Twojej zapory sieciowej, a EXTERNAL_HOST_NAME to zewnętrzna nazwa hosta Twojej zapory. Na przykład, korzystając z konfiguracji na powyższym schemacie, dodatkiem do /etc/hosts będzie
172.34.56.78 bigbluebutton.example.com
W tym momencie kontynuuj instalację BigBlueButton, a po zakończeniu instalacji skonfiguruj BigBlueButton tak, aby korzystał z zapory ogniowej, wykonując kroki opisane w następnej sekcji.
Skonfiguruj BigBlueButton do współpracy z zaporą ogniową
Aktualizacja mediasoup
W BigBlueButton 2.5 lub nowszym klient HTML5 używa mediasoup do wysyłania/odbierania strumieni WebRTC. Jeśli instalujesz na serwerze BigBlueButton za zaporą sieciową korzystającą z translacji adresów sieciowych (NAT), musisz upewnić się, że mediasoup ma poprawnie skonfigurowane adresy zewnętrzne.
Należy pamiętać, że poniższe kroki powinny już zostać wykonane przez bbb-install w środowisku IPv4.
Aby skonfigurować odpowiednie adresy zewnętrzne, należy użyć pliku konfiguracyjnego override (znajdującego się w /etc/bigbluebutton/bbb-webrtc-sfu/production.yml) bbb-webrtc-sfu. Jeśli nie ma production.yml lub /etc/bigbluebutton/bbb-webrtc-sfu/, wystarczy je po prostu utworzyć z odpowiednimi uprawnieniami i zasadami własności.
Przykładowo: w serwerze BigBlueButton z publicznym adresem IPv4 192.0.2.0 konfiguracja odpowiedzialna za podanie adresów zewnętrznych w mediasoup powinna mieć następujący format (składnia YAML, /etc/bigbluebutton/bbb-webrtc-sfu/production.yml):
mediasoup:
webrtc:
listenIps:
- ip: 0.0.0.0
announcedIp: 192.0.2.0
Zwróć uwagę, że klucz listenIps jest tablicą. Jeśli potrzebujesz mediasoup również do pracy z IPv6, nie zapomnij dodać z nim kolejnego wpisu do tej tablicy. Przykładowo: na serwerze BigBlueButton z publicznym IPv4 192.0.2.0 i IPv6 2001:db8:: konfiguracja powinna mieć następujący format (składnia YAML, /etc/bigbluebutton/bbb-webrtc-sfu/production.yml):
mediasoup:
webrtc:
listenIps:
- ip: 2001:db8::
- ip: 0.0.0.0
announcedIp: 192.0.2.0
Uruchom ponownie BigBlueButton, aby zastosować zmiany.
Aktualizacja FreeSWITCH
Przyjrzyjmy się ponownie typowej konfiguracji BigBlueButton za zaporą ogniową (twój oczywiście miałby inny adres IP).
Aby dźwięk WebRTC działał, FreeSWITCH musi nasłuchiwać połączeń na zewnętrznym adresie IP zapory. Jeśli nie zmodyfikowałeś zapory sieciowej w celu przekazywania portów do serwera BigBlueButton, zobacz konfiguruj zaporę ogniową.
Po skonfigurowaniu zapory sieciowej do przekazywania połączeń przychodzących do serwera BigBlueButton, następnym krokiem jest skonfigurowanie FreeSWITCH tak, aby powiązał się z zewnętrznym adresem IP zapory.
Edytuj następujące pliki i zamień zewnętrzny adres IP na zewnętrzny adres IP (nie na nazwę hosta).
Edytuj /opt/freeswitch/conf/vars.xml i zmień
<X-PRE-PROCESS cmd="set" data="external_rtp_ip=stun:stun.freeswitch.org"/>
do
<X-PRE-PROCESS cmd="set" data="external_rtp_ip=EXTERNAL_IP_ADDRESS"/>
Zmień
<X-PRE-PROCESS cmd="set" data="external_sip_ip=stun:stun.freeswitch.org"/>
do
<X-PRE-PROCESS cmd="set" data="external_sip_ip=EXTERNAL_IP_ADDRESS"/>
Następnie edytuj /opt/freeswitch/conf/sip_profiles/external.xml i zmień
<param name="ext-rtp-ip" value="$${local_ip_v4}"/>
<param name="ext-sip-ip" value="$${local_ip_v4}"/>
do
<param name="ext-rtp-ip" value="$${external_rtp_ip}"/>
<param name="ext-sip-ip" value="$${external_sip_ip}"/>
W tym samym pliku pamiętaj o zmianie
<param name="local-network-acl" value="localnet.auto"/>
do
<param name="local-network-acl" value="none"/>
, dzięki czemu FreeSWITCH ogłasza zewnętrzny adres IP po nawiązaniu połączenia.
Sprawdź, czy enableListenOnly jest ustawione na true w /etc/bigbluebutton/bbb-html5.yml, tak jak w
$ grep enableListenOnly /etc/bigbluebutton/bbb-html5.yml
enableListenOnly: true
Następnie edytuj /etc/bigbluebutton/bbb-webrtc-sfu/production.yml i zmień wartość na ip, aby dopasować zewnętrzny adres IP serwera.
freeswitch:
ip: 203.0.113.1
sip_ip: 172.30.1.145
port: 5066
Po dokonaniu powyższych zmian uruchom ponownie BigBlueButton.
$ bbb-conf --restart
Aby przetestować, uruchom FireFox i spróbuj połączyć się z serwerem BigBlueButton i dołącz do dźwięku. Jeśli w prawym dolnym rogu widzisz słowa „[ WebRTC Audio ]”, oznacza to, że zadziałało.
Jeśli to nie zadziałało, podczas próby połączenia audio pojawią się dwa prawdopodobne komunikaty o błędach.
Wykryto następujący problem z WebRTC: Błąd 1002: Nie można nawiązać połączenia WebSocket.
Tabela jest szersza od ekranu. Przewiń ją w poziomie.
| Błąd Wykryto następujący problem z WebRTC | Prawdopodobna przyczyna |
|---|---|
| 1002: Nie można nawiązać połączenia WebSocket | Uwaga 1 |
| 1007: Negocjacja ICE nie powiodła się | Uwaga 2 |
W przypadku błędu 1002 sprawdź, czy FreeSWITCH uruchomił się bez błędów
## systemctl status freeswitch
● freeswitch.service - freeswitch
Loaded: loaded (/lib/systemd/system/freeswitch.service; enabled; vendor preset: enabled)
Active: <span style="color:#980000;font-weight:bold">active (running)</span> since Fri 2017-03-03 23:13:07 UTC; 48min ago
Process: 19349 ExecStart=/opt/freeswitch/bin/freeswitch -u freeswitch -g daemon -ncwait $DAEMON_OPTS (code=exited, status=0/SUCCESS)
Main PID: 19361 (freeswitch)
Tasks: 36
Memory: 41.4M
CPU: 20.744s
CGroup: /system.slice/freeswitch.service
└─19361 /opt/freeswitch/bin/freeswitch -u freeswitch -g daemon -ncwait -nonat
Mar 03 23:13:05 t4 systemd[1]: Starting freeswitch...
Mar 03 23:13:05 t4 freeswitch[19349]: 19361 Backgrounding.
Mar 03 23:13:07 t4 freeswitch[19349]: FreeSWITCH[19349] Waiting for background process pid:19361 to be ready.....
Mar 03 23:13:07 t4 freeswitch[19349]: FreeSWITCH[19349] System Ready pid:19361
Mar 03 23:13:07 t4 systemd[1]: Started freeswitch.
Powinieneś zobaczyć active (running). Jeśli FreeSWITCH nie jest uruchomiony, możesz sprawdzić jego dziennik wyjściowy pod kątem wskazówek, dlaczego nie działa journalctl -u freeswitch.service. Jeśli błąd 1002 nadal się pojawia, sprawdź poniższe przystanki diagnostyczne w sekcji Konfiguruj fikcyjną kartę sieciową.
W przypadku błędu 1007 oznacza to, że połączenie z gniazdem sieciowym powiodło się (FreeSWITCH działa i otrzymał żądanie od przeglądarki skonfigurowania ścieżki multimediów), ale żadna z kombinacji IP/portów zwróconych przez FreeSWITCH nie umożliwiła przeglądarce połączenia i rozpoczęcia transmisji multimediów. Aby zdiagnozować ten błąd, otwórz about:webrtc w FireFox i kliknij „pokaż szczegóły” najnowszego połączenia. Zajrzyj do kolumny Remote Candidate i sprawdź, czy widzisz wewnętrzny adres IP serwera BigBlueButton. Jeśli tak, prawdopodobnie masz błędną konfigurację w ustawieniach FreeSWITCH. Sprawdź ponownie, korzystając z przykładów pokazanych powyżej.
Jeśli wyświetlany jest prawidłowy adres IP, prawdopodobnie występuje problem polegający na tym, że zapora sieciowa nie przepuszcza pakietów UDP w obu kierunkach na wymaganych portach. Sprawdź dokumentację zapory sieciowej, aby uzyskać pomoc, lub zapytaj listę mailingową społeczności BigBlueButton.
Skonfiguruj fikcyjną kartę sieciową (jeśli jest wymagana)
Jeśli podczas próby połączenia z dźwiękiem WebRTC pojawia się błąd 1002, może to oznaczać, że Twoja zapora sieciowa nie obsługuje „hairpin NAT”, co oznacza, że serwer BigBlueButton łączy się z adresem IP zapory sieciowej adres, zapora sieciowa nie odsyła połączenia z powrotem.
Możesz sprawdzić, czy NAT spinki do włosów działa, używając następującego polecenia na serwerze BigBlueButton. Zastąp EXTERNAL-IP-ADDRESS zewnętrznym adresem IP zapory ogniowej.
$ curl --trace-ascii - -k https://EXTERNAL-IP-ADDRESS:443/bigbluebutton/api
Oto przykładowe wyniki testu powodzenia.
~# curl --trace-ascii - -k https://203.0.113.1:443/bigbluebutton/api
== Info: Trying 203.0.113.1...
== Info: Connected to 203.0.113.1 (203.0.113.1) port 443 (#0)
== Info: found 173 certificates in /etc/ssl/certs/ca-certificates.crt
== Info: found 692 certificates in /etc/ssl/certs
== Info: ALPN, offering http/1.1
== Info: SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
== Info: server certificate verification SKIPPED
== Info: server certificate status verification SKIPPED
== Info: common name: HOSTNAME (does not match '203.0.113.1')
== Info: server certificate expiration date OK
== Info: server certificate activation date OK
== Info: certificate public key: RSA
== Info: certificate version: #3
== Info: subject: CN=bbb02.monasticeducation.net
== Info: start date: Fri, 24 Feb 2017 06:20:00 GMT
== Info: expire date: Thu, 25 May 2017 06:20:00 GMT
== Info: issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
== Info: compression: NULL
== Info: ALPN, server accepted to use http/1.1
=> Send header, 93 bytes (0x5d)
0000: GET /bigbluebutton/api HTTP/1.1
0021: Host: 203.0.113.1
0035: User-Agent: curl/7.47.0
004e: Accept: */*
005b:
<= Recv header, 17 bytes (0x11)
...
<response><returncode>SUCCESS</returncode><version>1.0</version></response>== Info: Connection #0 to host 203.0.113.1 left intact
Na końcu powinieneś zobaczyć <response>...</response>.
Jeśli tego nie widzisz, wykonaj poniższe kroki na serwerze BigBlueButton, aby skonfigurować fikcyjną kartę sieciową, która ma ten sam adres IP co Twoja zapora sieciowa. Oto przykładowy schemat działania.
Na tym schemacie skonfigurowaliśmy fikcyjną kartę sieciową dla 203.0.113.1, która umożliwi FreeSWITCH ponowne połączenie się ze sobą. W ten sposób, gdy FreeSWITCH odbierze połączenie wewnętrzne z innych części BigBlueButton, pomyśli, że znajduje się ono na interfejsie zewnętrznym. Spowoduje to, że w odpowiedzi użyje prawidłowego adresu IP.
Aby skonfigurować fikcyjną kartę sieciową, na urządzeniu BigBlueButton wprowadź następujące polecenie i zastąp EXTERNAL_IP_ADDRESS zewnętrznym adresem IP zapory sieciowej.
$ sudo ip addr add EXTERNAL\_IP\_ADDRESS/32 dev lo
Następnie sprawdź, czy fikcyjna karta sieciowa została utworzona za pomocą polecenia ip addr.
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet EXTERNAL_IP_ADDRESS/32 scope global lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
Powinieneś zobaczyć EXTERNAL_IP_ADDRESS swojej zapory ogniowej wymieniony powyżej.
W tym momencie zrestartuj serwer BigBlueButton za pomocą bbb-conf --restart, a następnie spróbuj ponownie połączyć się z mediami WebRTC.
Na koniec, aby mieć pewność, że ta fikcyjna karta sieciowa zostanie automatycznie utworzona przy ponownym uruchomieniu, edytuj /etc/network/interfaces i dodaj następujący
# The loopback network interface
auto lo
iface lo inet loopback
post-up ip addr add EXTERNAL_IP_ADDRESS/32 dev lo
pre-down ip addr del EXTERNAL_IP_ADDRESS/32 dev lo
Powyższe umożliwi użytkownikom spoza zapory ogniowej dostęp do Twojego serwera BigBlueButton.
Dla samych użytkowników znajdujących się za zaporą ogniową będziesz chciał skonfigurować serwer TURN (poprzednia sekcja).