SSD Nodes Learn 🎉 VPS od $5.50/mies.
Przewodniki Matt ConnorAutor: Matt Connor

Własny serwer VoIP: konfiguracja Asterisk i FreePBX

Dowiedz się, jak skonfigurować serwer Asterisk lub FreePBX na VPS. Poradnik obejmuje ustawienia trunków SIP, zakresy portów RTP oraz reguły firewalla chroniące przed oszustwami.

Czym jest własny serwer VoIP

Własny serwer VoIP to serwer SIP działający na kontrolowanym przez użytkownika VPS, dzięki czemu połączenia są kierowane przez własną maszynę, a nie przez zewnętrznego dostawcę usług telefonicznych. VoIP (voice over IP) przesyła mowę w postaci pakietów UDP. SIP (session initiation protocol) to protokół sygnalizacyjny, który nawiązuje i kończy połączenie. Dźwięk nie jest przesyłany przez SIP i ten fakt jest przyczyną większości problemów opisanych poniżej.

Na działający system składają się cztery elementy.

  • Oprogramowanie PBX (private branch exchange). Asterisk jest najczęstszym wyborem. Przechowuje ono numery wewnętrzne oraz plan wybierania (dialplan).
  • Punkty końcowe. Telefony stacjonarne lub softphony, które rejestrują się w PBX przy użyciu nazwy użytkownika i hasła.
  • Trunk SIP. Płatne konto u dostawcy, które łączy użytkownika z publiczną siecią telefoniczną i udostępnia rzeczywiste numery telefonów.
  • Ścieżka mediów. Strumienie RTP (real-time transport protocol), które przenoszą dźwięk na własnych portach UDP.

Utrzymywanie własnego PBX nie oznacza samodzielnego świadczenia usług numeracji. Numery pochodzą od operatora, za który nadal płaci się w modelu za numer i za minutę. Użytkownik zarządza routingiem połączeń, pocztą głosową, nagraniami oraz listą numerów wewnętrznych. Użytkownik odpowiada również za bezpieczeństwo usługi, która jest celem ataków motywowanych finansowo.

Jakie porty są wymagane przez samodzielnie hostowany serwer VoIP?

Sygnalizacja SIP wykorzystuje port 5060 dla protokołów UDP i TCP oraz port 5061 dla SIP przez TLS (transport layer security). Porty te służą wyłącznie do nawiązywania połączeń. Dźwięk każdego połączenia stanowi oddzielny strumień UDP, przesyłany na port wybrany z zakresu RTP. Asterisk zawiera przykładowy plik rtp.conf, który ustawia rtpstart=10000 oraz rtpend=20000, a domyślne wartości skompilowane w kodzie to 5000 i 31000. Każde połączenie zajmuje dwa porty z tego zakresu: jeden dla RTP i jeden dla RTCP (RTP control protocol).

Ten podział jest przyczyną niepowodzenia większości pierwszych prób konfiguracji. Połączenie zostaje nawiązane, oba telefony wskazują, że zostało odebrane, jednak żadna ze stron nic nie słyszy, ponieważ firewall zezwala na ruch na porcie 5060, ale odrzuca wszystkie pakiety RTP. Sygnalizacja i media to oddzielne strumienie, dlatego wymagają oddzielnych reguł firewalla. Jeśli to rozróżnienie jest nowe, warto przeczytać jak działają porty i gniazda nasłuchujące w systemie Linux przed otwarciem jakichkolwiek portów.

Ogranicz zakres przed jego otwarciem. Dwadzieścia tysięcy portów to znacznie więcej, niż potrzebuje mały system. Dwa porty na połączenie oznaczają, że zakres dwustu portów wystarczy do obsłużenia stu jednoczesnych rozmów.

[general]
rtpstart=10000
rtpend=10200

Zastosuj ustawienia za pomocą sudo asterisk -rx "core reload".

Czy zainstalować Asterisk czy FreePBX?

Asterisk to silnik systemu. Konfigurację przeprowadza się za pomocą plików tekstowych w /etc/asterisk, a dialplan tworzy się samodzielnie. FreePBX to interfejs WWW napisany w PHP i JavaScript, który działa jako nakładka na Asterisk, generuje wspomniane pliki i dodaje moduły obsługi poczty głosowej oraz kolejek połączeń.

Kluczową różnicą w kontekście VPS jest kwestia wyłączności na maszynę. Według stanu na sierpień 2026 r. oficjalny instalator FreePBX 17 wymaga czystego systemu Debian 12 i automatycznie instaluje Asterisk, serwer WWW, serwer bazy danych oraz PHP. Uruchomienie instalatora na serwerze z już działającymi usługami doprowadzi do konfliktów. FreePBX wymaga dedykowanej instancji VPS.

wget https://github.com/FreePBX/sng_freepbx_debian_install/raw/master/sng_freepbx_debian_install.sh -O /tmp/sng_freepbx_debian_install.sh
sudo bash /tmp/sng_freepbx_debian_install.sh

Dziennik instalacji znajduje się w /var/log/pbx/freepbx17-install.log; jest to pierwsze miejsce, które należy sprawdzić w przypadku przerwania skryptu.

FreePBX zarządza plikami konfiguracyjnymi, które generuje. Ręczna edycja plików w pjsip.conf na serwerze z FreePBX spowoduje nadpisanie zmian przy kolejnym zapisie konfiguracji przez GUI. FreePBX ignoruje pliki zawierające _custom w nazwie, dlatego należy ich używać do ręcznej konfiguracji.

Wybór sprowadza się do następującego kompromisu: FreePBX oferuje GUI, ale wystawia stronę logowania do systemu telefonicznego na publiczny adres IP. Czysty Asterisk nie posiada interfejsu WWW, a każde ustawienie jest udokumentowaną dyrektywą, którą można odczytać w pliku i przechowywać w systemie git. W przypadku instalacji FreePBX należy ograniczyć dostęp do portu WWW do własnego adresu IP lub korzystać z połączenia VPN, ponieważ panel administracyjny PBX jest celem ataku prowadzącym bezpośrednio do strat finansowych.

Uwaga dotycząca wersji, stan na sierpień 2026 r.: Asterisk 22 to bieżące wydanie o długoterminowym wsparciu (LTS), opublikowane w październiku 2024 r., które będzie otrzymywać poprawki bezpieczeństwa do października 2028 r. Asterisk 23 to wydanie standardowe. Ubuntu 24.04 zawiera Asterisk 20.6.0 w repozytorium universe.

Instalacja Asterisk na Ubuntu 24.04

Pakiet dystrybucyjny to najszybsza metoda instalacji. Ubuntu dostarcza poprawki, a usługa uruchamia się automatycznie w ramach systemd.

sudo apt update
sudo apt install -y asterisk
sudo asterisk -rx "core show version"

Budowanie ze źródeł pozwala na uzyskanie aktualnego wydania o długoterminowym wsparciu (LTS).

sudo apt update
sudo apt install -y build-essential wget
cd /usr/local/src
sudo wget https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-22-current.tar.gz
sudo tar -xzf asterisk-22-current.tar.gz
cd asterisk-22.*
sudo contrib/scripts/install_prereq install
sudo ./configure
sudo make menuselect
sudo make -j"$(nproc)"
sudo make install
sudo make samples
sudo make config
sudo ldconfig

install_prereq install pobiera zależności budowania dla danej dystrybucji, a install_prereq test wyświetla polecenia, które zostałyby wykonane bez wprowadzania zmian w systemie. make menuselect otwiera selektor modułów, w którym należy włączyć codec_opus w sekcji Codec Translators. Polecenie make samples należy uruchamiać wyłącznie na świeżej instalacji, ponieważ zapisuje ono przykładową konfigurację w /etc/asterisk. make config instaluje skrypt init w /etc/init.d/asterisk, a systemd obsługuje go poprzez warstwę kompatybilności SysV, dzięki czemu sudo systemctl enable --now asterisk działa poprawnie po zakończeniu instalacji.

Niezależnie od wybranej metody, sudo asterisk -rvvv łączy się z działającym procesem (daemon) i udostępnia interfejs CLI. Wykonanie core show version wewnątrz CLI wyświetla informacje o zainstalowanej wersji.

Konfiguracja trunk-a SIP i jednego numeru wewnętrznego

PJSIP jest obecnym sterownikiem kanału SIP w Asterisk. Jego konfiguracja znajduje się w /etc/asterisk/pjsip.conf i jest budowana z małych, typowanych sekcji, które odwołują się do siebie nawzajem za pomocą nazw. Sekcje różnych typów mogą mieć tę samą nazwę, dlatego każdy blok poniżej nazywa się mytrunk.

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0

[mytrunk]
type=registration
outbound_auth=mytrunk
server_uri=sip:sip.example.com
client_uri=sip:1234567890@sip.example.com
retry_interval=60

[mytrunk]
type=auth
auth_type=userpass
username=1234567890
password=REPLACE_WITH_A_LONG_RANDOM_SECRET

[mytrunk]
type=aor
contact=sip:sip.example.com:5060

[mytrunk]
type=endpoint
context=from-trunk
disallow=all
allow=ulaw
outbound_auth=mytrunk
aors=mytrunk

[mytrunk]
type=identify
endpoint=mytrunk
match=sip.example.com

Obiekt registration wysyła żądanie REGISTER, które informuje dostawcę, gdzie kierować połączenia. Obiekt identify służy do dopasowania połączenia przychodzącego od dostawcy do tego punktu końcowego na podstawie adresu źródłowego; dostawcy zazwyczaj publikują kilka adresów, które należy tam umieścić. Rejestracja wychodząca i punkt końcowy są celowo oddzielnymi obiektami: jeden informuje dostawcę o Twojej lokalizacji, drugi decyduje o obsłudze połączeń.

Telefon stacjonarny wymaga trzech dodatkowych obiektów.

[6001]
type=endpoint
context=internal
disallow=all
allow=ulaw
auth=auth6001
aors=6001
direct_media=no

[auth6001]
type=auth
auth_type=userpass
username=6001
password=REPLACE_WITH_A_LONG_RANDOM_SECRET

[6001]
type=aor
max_contacts=1

direct_media=no utrzymuje Asterisk na ścieżce mediów. Bez tego ustawienia Asterisk spróbuje wymusić przesyłanie RTP bezpośrednio między punktami końcowymi, co kończy się niepowodzeniem, gdy telefon znajduje się za NAT (network address translation) na domowym routerze. Nigdy nie ustawiaj hasła identycznego z numerem wewnętrznym. Przykładowa konfiguracja używa password=6001 dla numeru 6001, aby zachować czytelność, jednak skanery próbują właśnie tego wzorca w pierwszej kolejności.

Plan wybierania (dialplan) w /etc/asterisk/extensions.conf określa uprawnienia dla każdego kontekstu.

[internal]
exten => 6001,1,Dial(PJSIP/6001,20)
exten => _9X.,1,Dial(PJSIP/${EXTEN:1}@mytrunk,60)

[from-trunk]
exten => 1234567890,1,Dial(PJSIP/6001,20)
same => n,Hangup()

Te dwa konteksty stanowią granicę bezpieczeństwa. from-trunk obsługuje połączenia przychodzące od dostawcy i może wywołać wyłącznie numer 6001. Nie ma dostępu do wzorca _9X., dzięki czemu połączenie z zewnątrz nie może zainicjować połączenia wychodzącego przez trunk. Połączenie tych kontekstów tworzy klasyczną ścieżkę do oszustw telekomunikacyjnych (toll fraud): osoba z zewnątrz dzwoni na Twój numer, Twój dialplan inicjuje połączenie wychodzące na Twoim koncie, a Ty ponosisz koszty.

Zastosuj konfigurację i sprawdź jej poprawność.

sudo asterisk -rx "pjsip reload"
sudo asterisk -rx "pjsip show registrations"
sudo asterisk -rx "pjsip show endpoints"

pjsip show registrations powinno wyświetlić mytrunk ze statusem Registered. Rejected oznacza, że dostawca odrzucił Twoje dane uwierzytelniające. Unregistered oznacza, że żądanie REGISTER pozostaje bez odpowiedzi, więc w następnej kolejności należy sprawdzić firewall.

Reguły zapory sieciowej dla SIP i RTP

Sygnalizacja i media wymagają odrębnego traktowania ze względu na różny poziom ryzyka. Ogranicz port 5060 wyłącznie do adresów używanych przez dostawcę oraz sieci, w których znajdują się telefony.

sudo ufw allow proto udp from 203.0.113.10 to any port 5060
sudo ufw allow proto tcp from 203.0.113.10 to any port 5060
sudo ufw allow 10000:10200/udp
sudo ufw status verbose

Zakres RTP jest elementem, którego nie można zawęzić w takim samym stopniu, ponieważ media często docierają z innego adresu niż sygnalizacja. Należy zapytać dostawcę o podsieci używane do transmisji mediów i ograniczyć dostęp do nich, jeśli są publicznie dostępne. Zakres powinien być tak szeroki, jak wymaga tego największe obciążenie w godzinach szczytu. Domyślne polityki, kolejność reguł oraz pozostałe aspekty modelu ufw zostały opisane w przewodniku po podstawach zapory ufw dla VPS.

Należy również sprawdzić IPv6. Jeśli IPV6=no jest ustawione w /etc/default/ufw, ufw nie filtruje ruchu IPv6, co oznacza, że usługa powiązana z :: jest dostępna przez IPv6 bez zastosowania powyższych reguł. Otwieranie portów dla IPv6 w ufw wyjaśnia różnice między tymi dwiema rodzinami protokołów. Większość dostawców udostępnia również zewnętrzną zaporę sieciową w panelu sterowania; jest ona egzekwowana, zanim pakiety dotrą do VPS, dlatego port musi być otwarty w obu miejscach.

Ataki typu brute force na SIP oraz wyłudzenia połączeń nie są problemami opcjonalnymi

Wystawienie portu 5060 na publiczny adres IP natychmiast inicjuje skanowanie. Wzorzec jest stały: żądania REGISTER oraz INVITE z wielu adresów źródłowych, próbujące odgadnąć popularne numery wewnętrzne przy użyciu powszechnych haseł. Asterisk rejestruje każdą nieudaną próbę, a wpis w logu przyjmuje następującą postać.

Request 'REGISTER' from '<sip:1000@198.51.100.20>' failed for '198.51.100.20:5060' (callid: 5f1a5c0d) - No matching endpoint found

Powodem, dla którego kwestia ta wymaga realnego wysiłku, są finanse. Przejęty numer wewnętrzny jest wykorzystywany do wykonywania kosztownych połączeń międzynarodowych, często na numery o podwyższonej opłacie, z których część zysku trafia do atakującego. Rachunek obciąża właściciela, ponieważ połączenia zostały autoryzowane jego danymi uwierzytelniającymi. Atak przebiega z prędkością maszynową i zazwyczaj jest przeprowadzany w nocy.

Sześć poniższych zabezpieczeń jest obowiązkowych, a nie opcjonalnych.

  • Nigdy nie należy tworzyć numeru wewnętrznego, którego hasło jest identyczne z numerem lub krótkim słowem. Należy wygenerować je za pomocą openssl rand -base64 24 i wkleić w konfiguracji.
  • Należy pozostawić wyłączoną obsługę anonimowych połączeń przychodzących. PJSIP domyślnie odrzuca niezidentyfikowane połączenia i akceptuje je tylko wtedy, gdy utworzony zostanie punkt końcowy o nazwie anonymous. Nie należy go tworzyć.
  • Kontekst łącza (trunk) musi być odseparowany od każdego kontekstu, który umożliwia wykonywanie połączeń wychodzących, zgodnie z powyższym przykładem.
  • Należy ograniczyć sygnalizację według adresu źródłowego, zarówno w ufw, jak i w zaporze sieciowej dostawcy usług.
  • Należy ustawić limit wydatków u dostawcy łącza SIP oraz wyłączyć kierunki międzynarodowe, które nie są wykorzystywane. Jest to jedyne zabezpieczenie ograniczające straty w przypadku zawiedzenia pozostałych metod.
  • Należy uruchomić fail2ban monitorujący logi Asterisk.

Asterisk może również wygenerować zdarzenie bezpieczeństwa po serii niedopasowanych żądań z jednego adresu. Sekcja [global] w pliku pjsip.conf przyjmuje parametry unidentified_request_count, którego wartość domyślna wynosi 5, oraz unidentified_request_period, którego wartość domyślna to 5 sekund. Łącznie oznacza to, że pięć niedopasowanych żądań z jednego adresu w ciągu pięciu sekund wywoła zdarzenie bezpieczeństwa, na które może zareagować fail2ban.

Blokowanie skanerów za pomocą fail2ban

fail2ban dostarcza gotowe więzienie asterisk. Obsługuje ono porty 5060 i 5061, odczytuje /var/log/asterisk/messages, a domyślnie ustawione jest na maxretry = 10. Więzienie pozostaje nieaktywne, dopóki nie zostanie włączone w /etc/fail2ban/jail.local.

[asterisk]
enabled = true
maxretry = 5
findtime = 600
bantime = 86400
sudo systemctl restart fail2ban
sudo fail2ban-client status asterisk

Prawidłowy wynik wyświetla plik dziennika więzienia oraz liczbę aktualnie zablokowanych adresów. Na publicznym porcie 5060 liczba ta przestaje wynosić zero w ciągu doby. Dostarczony filtr dopasowuje powiadomienia No matching endpoint found wymienione powyżej, a także dopasowuje ustrukturyzowane linie SecurityEvent programu Asterisk. Zdarzenia te trafiają do oddzielnego kanału logowania, który jest zakomentowany w /etc/asterisk/logger.conf, więc należy go tam odkomentować i dodać plik do parametru logpath więzienia, jeśli mają być uwzględniane.

[logfiles]
console => notice,warning,error
messages.log => notice,warning,error
security.log => security

Przeładuj logger za pomocą sudo asterisk -rx "logger reload". Filtr zawiera również journalmatch dla asterisk.service, więc backend journal działa, jeśli wolisz nie przechowywać plików dziennika. Instalacja, struktura jail.local oraz odblokowywanie adresu, który został zablokowany, zostały opisane w przewodniku po fail2ban dla Ubuntu 24.04.

Opóźnienia a wybór kodeka na odległym VPS

Opóźnienie wynika z uwarunkowań geograficznych i nie można go wyeliminować poprzez konfigurację. Rekomendacja ITU-T G.114 wskazuje, aby opóźnienie jednokierunkowe utrzymywać poniżej 150 ms dla standardowej rozmowy, uznając wartości do około 400 ms za dopuszczalne. Dźwięk z telefonu trafia do VPS, a następnie do dostawcy łącza (trunk provider), więc VPS w niewłaściwym regionie powoduje podwojenie tego dystansu. Należy umieścić serwer w pobliżu telefonów lub dostawcy, przy czym priorytetem powinna być bliskość telefonów, ponieważ ten odcinek zazwyczaj wykorzystuje łącza konsumenckie, gdzie jitter jest najbardziej odczuwalny.

Wybór kodeka określa przepustowość wymaganą dla jednego połączenia. Każdy z wymienionych kodeków wysyła pakiet co 20 ms, co daje 50 pakietów na sekundę. Każdy pakiet zawiera 40 bajtów nagłówków IP, UDP oraz RTP ponad ładunkiem audio.

ChartBandwidth per concurrent call, one direction, 20 ms packets
The data behind this chart
[
  {
    "label": "G.711 ulaw",
    "payload_kbps": 64,
    "ip_kbps": 80
  },
  {
    "label": "G.722",
    "payload_kbps": 64,
    "ip_kbps": 80
  },
  {
    "label": "Opus at 24 kbps",
    "payload_kbps": 24,
    "ip_kbps": 40
  },
  {
    "label": "G.729",
    "payload_kbps": 8,
    "ip_kbps": 24
  }
]

G.711 ulaw jest domyślnym kodekiem dla większości łączy. Jego ładunek wynosi 64 kbps, a wraz z nagłówkami aktywne połączenie zajmuje 80 kbps w każdym kierunku. Opus przy 24 kbps zajmuje 40 kbps, natomiast G.729 obniża tę wartość do 24 kbps kosztem jakości dźwięku i obciążenia procesora. Powyższe wartości wynikają z obliczeń nagłówków, a nie z pomiarów: jest to szybkość ładunku plus 40 bajtów na pakiet przy 50 pakietach na sekundę. Ramkowanie Ethernet lub VLAN dodaje niewielki narzut w transmisji przewodowej.

Transkodowanie obciąża procesor. Jeśli telefony oraz łącze obsługują ulaw, należy zezwolić wyłącznie na ten kodek, dzięki czemu Asterisk przesyła dźwięk bez modyfikacji. Opus sprawdza się dobrze w łączach o wysokiej utracie pakietów, jednak transkodowanie między Opus a G.711 wymaga zewnętrznego modułu codec_opus, który wybiera się w make menuselect i który nie jest kompilowany domyślnie.

Co ulega awarii i jaki ciąg znaków zobaczysz

Połączenie zostaje nawiązane, ale nikt nic nie słyszy. Pakiety RTP nie docierają. Potwierdź, że zakres w rtp.conf jest zgodny z zakresem otwartym w zaporze sieciowej, a następnie monitoruj pakiety za pomocą sudo tcpdump -ni any udp portrange 10000-10200 podczas wykonywania połączenia. Brak jakichkolwiek pakietów oznacza, że zapora sieciowa lub sieć dostawcy je odrzuca.

Dźwięk tylko w jedną stronę. Jedna ze stron wysyła RTP na adres, który nie może go odebrać; jest to problem adresacji, a nie portów. Jeśli VPS posiada publiczny adres przypisany bezpośrednio do interfejsu, obsługa NAT nie jest wymagana. Jeśli dostawca przydziela VPS adres prywatny z mapowaniem jeden do jednego na adres publiczny, ustaw adres publiczny w transporcie i wymień zakres prywatny w local_net.

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
local_net=10.0.0.0/8
external_media_address=198.51.100.5
external_signaling_address=198.51.100.5

No matching endpoint found w dzienniku. Żądanie nie pasowało do żadnego punktu końcowego według adresu IP ani nazwy użytkownika. W przypadku skanera jest to normalne zachowanie, którym zajmie się fail2ban. W przypadku własnego dostawcy oznacza to, że sekcja identify nie zawiera adresu, z którego przychodzi połączenie.

Status rejestracji to Rejected. Dostawca odrzucił dane uwierzytelniające w sekcji auth. Uruchom pjsip set logger on w CLI, obserwuj jeden proces REGISTER oraz odpowiedź na niego, a następnie porównaj client_uri oraz username z danymi otrzymanymi od dostawcy.

Brak jakichkolwiek przydatnych informacji w dzienniku. Asterisk domyślnie zapisuje komunikaty o poziomie notice i wyższym w messages.log. Zwiększ poziom szczegółowości za pomocą core set verbose 4 oraz pjsip set logger on podczas odtwarzania problemu, a następnie wyłącz obie opcje, ponieważ rejestrator SIP zapisuje każdy pakiet.

Zanim wystawisz usługę na zewnątrz

Centrala PBX różni się od innych usług hostowanych samodzielnie. Awaria aplikacji webowej skutkuje jedynie niedostępnością strony. Awaria PBX w ciągu kilku godzin, nawet podczas snu, może wygenerować ogromne rachunki telefoniczne. Uruchom usługę na dedykowanym serwerze VPS, który nie obsługuje żadnych innych zadań. Ogranicz dostęp do portu 5060 wyłącznie do znanych adresów IP, przypisz każdemu numerowi wewnętrznemu losowe hasło i ustaw limit wydatków na koncie operatora (trunk). Pozostałe aspekty bezpieczeństwa serwera wymagają zachowania standardowych procedur dla każdej wystawionej na świat maszyny, co opisuje ta analiza poziomu bezpieczeństwa hostingu VPS.

FAQ

Jakie porty należy otworzyć dla własnego serwera VoIP?

Port 5060 dla sygnalizacji SIP przez UDP i TCP, port 5061 w przypadku korzystania z SIP przez TLS oraz zakres portów UDP dla transmisji mediów RTP. Przykładowy plik rtp.conf dla Asterisk wykorzystuje zakres od 10000 do 20000, natomiast wartości domyślne wbudowane w oprogramowanie to 5000 do 31000. Każde połączenie zajmuje dwa porty z tego zakresu, więc zakres dwustu portów pozwala na obsługę stu jednoczesnych rozmów. Zakres RTP należy otworzyć dla protokołu UDP, natomiast dostęp do portu 5060 warto ograniczyć do adresów dostawcy oraz własnych sieci, zamiast pozostawiać go otwartym dla wszystkich.

Czy zainstalować samodzielnie Asterisk, czy użyć FreePBX?

Czysty Asterisk należy zainstalować, gdy wymagana jest minimalna powierzchnia ataku, pliki konfiguracyjne przechowywane w git oraz gotowość do samodzielnego tworzenia dialplanu. FreePBX wybiera się w przypadku potrzeby posiadania interfejsu graficznego do zarządzania numerami wewnętrznymi, pocztą głosową i kolejkami połączeń. Według stanu na sierpień 2026 instalator FreePBX 17 wymaga czystego systemu Debian 12 i automatycznie instaluje Asterisk, serwer WWW, serwer bazy danych oraz PHP, dlatego należy przeznaczyć na niego osobny serwer VPS. FreePBX nadpisuje zarządzane przez siebie pliki konfiguracyjne, więc ręczne zmiany należy wprowadzać wyłącznie w plikach _custom.

Dlaczego po nawiązaniu połączenia nie słychać dźwięku?

Sygnalizacja zadziałała, ale transmisja mediów nie. Protokół SIP nawiązał połączenie na porcie 5060, natomiast dźwięk stanowi osobny strumień UDP kierowany na port z zakresu RTP, który jest przez coś blokowany. Należy sprawdzić, czy zakres w rtp.conf jest zgodny z zakresem otwartym w zaporze sieciowej, a także zweryfikować firewall sieciowy dostawcy oraz zaporę na samym serwerze. Uruchomienie sudo tcpdump -ni any udp portrange 10000-10200 w trakcie rozmowy pozwala na weryfikację: brak pakietów oznacza, że są one blokowane przed dotarciem do serwera.

Jak zatrzymać ataki typu SIP brute force i oszustwa telekomunikacyjne?

Dla każdego numeru wewnętrznego należy ustawić długie, losowe hasło, nigdy nie używając wartości zgodnej z numerem wewnętrznym. Kontekst używany przez trunk musi być odseparowany od kontekstu umożliwiającego wykonywanie połączeń wychodzących, aby połączenie przychodzące nie mogło zostać wykorzystane do wykonania połączenia wychodzącego na koszt właściciela. Dostęp do portu 5060 należy ograniczyć do adresów dostawcy. Warto włączyć jail asterisk w fail2ban, który analizuje /var/log/asterisk/messages i blokuje adresy generujące błędy No matching endpoint found. Należy również ustawić limit wydatków i zablokować nieużywane kierunki międzynarodowe u dostawcy, ponieważ jest to jedyna kontrola ograniczająca straty w przypadku niepowodzenia pozostałych zabezpieczeń.

Czy VPS w odległym regionie pogarsza jakość połączeń?

Tak, ponieważ dźwięk musi pokonać dwie trasy: od telefonu do VPS oraz od VPS do dostawcy trunku. Rekomendacja ITU-T G.114 zaleca opóźnienie jednokierunkowe poniżej 150 ms, a źle zlokalizowany serwer VPS może zużyć większość tego budżetu wyłącznie na dystans. Należy wybrać region blisko telefonów, ponieważ ten odcinek zazwyczaj przebiega przez konsumenckie łącza internetowe, gdzie jitter jest największy. Wybór kodeka nie naprawia opóźnień, a jedynie zmienia zapotrzebowanie na pasmo, więc G.729 oszczędza bajty, ale nie uratuje połączenia z opóźnieniem 200 ms.

#voip#asterisk#freepbx#sip#self-hosting