מאת Matt Connor
הקמת שרת VoIP עצמאי עם Asterisk ו-FreePBX
למדו להקים שרת Asterisk או FreePBX על גבי VPS. המדריך כולל הגדרת SIP trunks, טווחי פורטים ל-RTP, חוקי Firewall למניעת סריקות ודרכים להתגוננות מפני הונאות טלפוניה.
מהו שרת VoIP בניהול עצמי
שרת VoIP בניהול עצמי הוא שרת SIP הפועל על גבי VPS שבשליטתך, כך שהשיחות שלך מנותבות על ידי המכונה שלך במקום על ידי שירות טלפוני חיצוני. VoIP (קול על גבי IP) מעביר דיבור כחבילות UDP. SIP (פרוטוקול אתחול שיחה) הוא האיתות שמקים ומסיים שיחה. האודיו אינו עובר דרך SIP, ועובדה זו לבדה גורמת לרוב התקלות המפורטות להלן.
ארבעה רכיבים מרכיבים מערכת תקינה.
- תוכנת ה-PBX (מרכזיה פרטית). Asterisk היא הבחירה הנפוצה. היא מחזיקה את השלוחות ואת תוכנית החיוג (dialplan).
- נקודות הקצה. מכשירי טלפון שולחניים או softphones שנרשמים ל-PBX באמצעות שם משתמש וסיסמה (secret).
- ה-SIP trunk. חשבון בתשלום אצל ספק שמחבר אותך לרשת הטלפוניה הציבורית ומשכיר לך מספרי טלפון אמיתיים.
- נתיב המדיה. זרמי RTP (פרוטוקול תעבורה בזמן אמת) שמעבירים את האודיו בפורטי UDP משלהם.
ניהול עצמי של ה-PBX אינו אומר ניהול עצמי של מספרי טלפון. מספרים מגיעים מספק, ואתה עדיין משלם עבור כל מספר ועבור כל דקת שיחה. מה שנמצא בשליטתך הוא ניתוב השיחות, התא הקולי, ההקלטות ורשימת השלוחות. כמו כן, האחריות על אבטחת שירות שאנשים תוקפים למטרות רווח כספי מוטלת עליך.
אילו פורטים נדרשים עבור שרת VoIP באירוח עצמי?
אותות (signalling) של פרוטוקול SIP משתמשים בפורט 5060 עבור UDP ו־TCP, ובפורט 5061 עבור SIP מעל TLS (אבטחת שכבת תעבורה). פורטים אלו מעבירים רק את הגדרת השיחה. השמע של כל שיחה הוא זרם UDP נפרד, הנשלח לפורט שנלקח מטווח ה־RTP. התוכנה Asterisk מגיעה עם rtp.conf לדוגמה המגדיר את rtpstart=10000 ואת rtpend=20000, כאשר ברירות המחדל המקומפלות הן 5000 ו-31000. כל שיחה צורכת שני פורטים מטווח זה: אחד עבור RTP ואחד עבור RTCP (פרוטוקול בקרת RTP).
הפרדה זו היא המקום שבו רוב הניסיונות הראשונים נכשלים. השיחה מתחברת, שני הטלפונים מציגים אותה כנענית, אך אף צד אינו שומע דבר, כיוון שה־firewall מאפשר תעבורה בפורט 5060 אך חוסם כל חבילת RTP. אותות ותוכן מדיה הם זרמים נפרדים, ולכן הם זקוקים לחוקי firewall נפרדים. אם הבחנה זו חדשה עבורכם, כדאי לקרוא על אופן הפעולה של פורטים ושל sockets מאזינים ב-Linux לפני שתפתחו פורטים כלשהם.
צמצמו את הטווח לפני פתיחתו. עשרים אלף פורטים הם הרבה יותר ממה שמערכת קטנה צריכה. שני פורטים לכל שיחה אומרים שטווח של מאתיים פורטים מכסה מאה שיחות בו-זמנית.
[general]
rtpstart=10000
rtpend=10200החילו את ההגדרות באמצעות sudo asterisk -rx "core reload".
האם כדאי להתקין Asterisk או FreePBX?
Asterisk הוא המנוע. אתם מגדירים אותו באמצעות קובצי טקסט ב-/etc/asterisk וכותבים את ה-dialplan בעצמכם. FreePBX הוא ממשק אינטרנטי הכתוב ב-PHP וב-JavaScript שיושב על גבי Asterisk, מייצר עבורכם את הקבצים הללו, ומוסיף מודולים עבור תא קולי ותורי שיחות.
ההבדל המשמעותי ב-VPS הוא הבעלות על המכונה. נכון לאוקטובר 2026, מתקין ה-FreePBX 17 הרשמי מצפה למערכת Debian 12 נקייה, והוא מתקין Asterisk, שרת אינטרנט, שרת מסד נתונים ו-PHP. אם תפעילו אותו על שרת שכבר מריץ שירותים אחרים, התוצאה לא תהיה רצויה. הקצו ל-FreePBX שרת 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לוג ההתקנה נשמר ב-/var/log/pbx/ תחת שם עם חותמת זמן בתבנית freepbx17-install-YYYY.MM.DD-HH.MM.SS.log, כך שלכל הרצה יש קובץ משלה. זהו המקום הראשון לבדוק כאשר הסקריפט נעצר מוקדם, ו-ls -t /var/log/pbx/freepbx17-install-*.log | head -1 מאתר את הקובץ החדש ביותר.
FreePBX הוא הבעלים של קובצי התצורה שהוא מייצר. אם תערכו את pjsip.conf ידנית בשרת FreePBX, השינוי שלכם יימחק בפעם הבאה שהממשק הגרפי יכתוב את הקובץ. FreePBX קורא קבצים נפרדים עם _custom בשמם עבור תצורה שנכתבה ידנית, והוא אינו נוגע בהם.
הפשרה הכנה היא זו: FreePBX מעניק לכם ממשק גרפי, אך הוא מציב דף כניסה למערכת הטלפוניה שלכם על גבי האינטרנט הציבורי. ל-Asterisk גולמי אין ממשק אינטרנטי כלל, וכל הגדרה היא הוראה מתועדת שניתן לקרוא בקובץ ולשמור ב-git. אם אתם מתקינים FreePBX, הגבילו את פורט האינטרנט שלו לכתובת שלכם בלבד או גשו אליו דרך VPN, כיוון שממשק ניהול של PBX הוא יעד עם נתיב ישיר לרווח כספי.
הערת גרסה, נכון לאוקטובר 2026: Asterisk 22 היא גרסת ה-long term support הנוכחית, שפורסמה באוקטובר 2024. היא נתמכת באופן מלא עד אוקטובר 2028, ולאחר מכן תקבל תיקוני אבטחה בלבד עד סוף חייה באוקטובר 2029. Asterisk 23 היא גרסת ה-standard. הגרסה הבאה של ה-long term support, Asterisk 24, מתוכננת ל-15 באוקטובר 2026 ועדיין הופיעה כגרסת pre-release ב-10 באוקטובר. הפצת Ubuntu 24.04 כוללת את Asterisk 20.6.0 במאגר ה-universe.
התקנת Asterisk על Ubuntu 24.04
חבילת ההפצה היא הדרך המהירה ביותר. Ubuntu מתחזקת אותה והיא עולה תחת systemd באופן עצמאי.
sudo apt update
sudo apt install -y asterisk
sudo asterisk -rx "core show version"בנייה מקוד המקור מאפשרת לכם להשתמש בגרסת ה-long term support העדכנית ביותר.
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 מושכת את התלויות הנדרשות לבנייה עבור ההפצה שלכם, ו-install_prereq test מציגה את הפקודות שהיו מורצות מבלי לבצע שינויים בפועל. make menuselect פותחת את ממשק בחירת המודולים, שם עליכם להפעיל את codec_opus תחת הקטגוריה Codec Translators. הריצו את make samples רק בהתקנה נקייה, שכן היא כותבת את קובצי התצורה לדוגמה לתוך /etc/asterisk. make config מתקינה את סקריפט ה-init בנתיב /etc/init.d/asterisk, ו-systemd מפעילה אותו דרך שכבת התאימות ל-SysV, כך ש-sudo systemctl enable --now asterisk יעבוד לאחר מכן.
בלי קשר לדרך שבה בחרתם, sudo asterisk -rvvv מתחברת ל-daemon הרץ ומעניקה לכם גישה ל-CLI. הרצת core show version בתוך הממשק תציג את הגרסה המותקנת בפועל.
הגדרת SIP trunk ושלוחה אחת
PJSIP הוא מנהל ערוצי ה-SIP בגרסאות Asterisk הנוכחיות. התצורה שלו נמצאת ב-/etc/asterisk/pjsip.conf והיא בנויה ממקטעים קטנים ומסווגים המפנים זה לזה לפי שם. מקטעים מסוגים שונים יכולים לחלוק שם זהה, וזו הסיבה שכל בלוק להלן נקרא 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האובייקט registration שולח את ה-REGISTER שמודיע לספק שלכם לאן להעביר את השיחות שלכם. האובייקט identify הוא הדרך שבה שיחה המגיעה מהספק מזוהה מול ה-endpoint הזה לפי כתובת המקור; ספק בדרך כלל מפרסם כמה כתובות שיש לציין שם. רישום יוצא וה-endpoint הם אובייקטים נפרדים בכוונה: האחד מודיע לספק היכן אתם נמצאים, והשני קובע מה קורה עם השיחות.
טלפון שולחני זקוק לשלושה אובייקטים נוספים.
[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 משאיר את Asterisk בנתיב המדיה. אם תשמיטו אותו, Asterisk ינסה לגרום לשני ה-endpoints לשלוח RTP ישירות זה לזה, מה שנכשל כאשר טלפון נמצא מאחורי NAT (תרגום כתובות רשת) בנתב ביתי. לעולם אל תתנו לסיסמה להיות זהה למספר השלוחה. הדוגמה של פרויקט ה-upstream משתמשת ב-password=6001 עבור שלוחה 6001 כדי לשמור על קריאות, וסורקים מנסים בדיוק את התבנית הזו ראשונה.
תוכנית החיוג (dialplan) ב-/etc/asterisk/extensions.conf קובעת מה מותר לכל context לבצע.
[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()שני ה-contexts הללו מהווים גבול אבטחה. from-trunk מטפל בשיחות המגיעות מהספק ויכול רק לצלצל בשלוחה 6001. הוא אינו יכול להגיע לתבנית _9X., כך ששיחה מבחוץ לא יכולה לחייג החוצה דרך ה-trunk שלכם. אם תאחדו את ה-contexts, יצרתם את הנתיב הקלאסי שבו מתחילה הונאת טלפוניה: זר מתקשר למספר שלכם, תוכנית החיוג שלכם מחייגת החוצה על החשבון שלכם, ואתם משלמים על כך.
החילו את התצורה ובדקו אותה.
sudo asterisk -rx "pjsip reload"
sudo asterisk -rx "pjsip show registrations"
sudo asterisk -rx "pjsip show endpoints"הפקודה pjsip show registrations צריכה להציג את mytrunk עם הסטטוס Registered. הסטטוס Rejected מציין שהספק דחה את פרטי ההתחברות שלכם. הסטטוס Unregistered מציין שה-REGISTER שלכם נותר ללא מענה, לכן בדקו לאחר מכן את ה-firewall.
חוקי Firewall עבור SIP ו־RTP
אותות (signalling) ומדיה דורשים טיפול שונה מכיוון שהם נושאים סיכונים שונים. הגבילו את פורט 5060 לכתובות שספק השירות שלכם משתמש בהן בפועל ולרשתות שבהן נמצאים מכשירי הטלפון שלכם.
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טווח ה־RTP הוא החלק שקשה יותר לצמצם, כיוון שמדיה מגיעה לעיתים קרובות מכתובת שונה מזו של האותות. בקשו מהספק שלכם את רשתות המשנה (subnets) של המדיה והגבילו אליהן אם הן מפורסמות. שמרו על טווח מצומצם ככל האפשר בהתאם לעומס בשעות השיא. מדיניות ברירת מחדל, סדר חוקים ושאר המודל של ufw מכוסים ב-מדריך היסודות של חומת האש ufw עבור VPS.
בדקו גם את IPv6. כברירת מחדל, ufw מאפשר IPv6, וחוק ללא כתובת מקור, כמו חוק ה־RTP לעיל, חל על שתי המשפחות. חוקי 5060 מציינים כתובת מקור ב-IPv4, לכן הם תואמים ל-IPv4 בלבד; ספק שמעביר אותות על גבי IPv6 יזדקק לחוקים משלו. הגדרת IPV6=no בתוך /etc/default/ufw וטעינה מחדש של ufw לא משאירה את IPv6 ללא סינון: היא מגבילה את תעבורת ה-IPv6 לממשק ה-loopback בלבד. פתיחת פורטים עבור IPv6 עם ufw מסביר כיצד שתי המשפחות נבדלות זו מזו. רוב הספקים מספקים גם חומת אש רשתית נפרדת בלוח הבקרה, והיא נאכפת לפני שהחבילות מגיעות ל-VPS, לכן יש לפתוח את הפורט בשני המקומות.
מתקפות SIP brute force והונאות טלפוניה אינן בעיות אופציונליות
הצבת פורט 5060 על כתובת ציבורית תוביל מיד לסריקות. הדפוס קבוע: בקשות REGISTER ו-INVITE ממקורות רבים, המנסות לנחש מספרי שלוחות עם סיסמאות נפוצות. Asterisk מתעד כל כשל, והשורה נראית כך.
Request 'REGISTER' from '<sip:1000@198.51.100.20>' failed for '198.51.100.20:5060' (callid: 5f1a5c0d) - No matching endpoint foundהסיבה לכך שנושא זה דורש מאמץ אמיתי היא כספית. שלוחה פרוצה משמשת לביצוע שיחות בינלאומיות יקרות, לרוב למספרי פרימיום המזכים את התוקף בעמלה, והחשבון נותר באחריותכם מכיוון שהשיחות בוצעו באמצעות פרטי הזיהוי שלכם. המתקפה מתבצעת במהירות מכונה, לרוב בשעות הלילה.
שישה אמצעי בקרה הם חובה ולא המלצה לחיזוק האבטחה.
- לעולם אל תיצרו שלוחה שהסיסמה שלה היא מספר השלוחה עצמו או מילה קצרה. צרו סיסמה באמצעות
openssl rand -base64 24והדביקו אותה. - השאירו שיחות נכנסות אנונימיות כבויות. PJSIP מסרב כברירת מחדל לשיחות לא מזוהות ומקבל אותן רק אם יצרתם endpoint בשם
anonymous. אל תיצרו כזה. - שמרו על הפרדה בין ה-context של ה-trunk לבין כל context שיכול לבצע שיחות יוצאות, כפי שהוצג לעיל.
- הגבילו איתות (signalling) לפי כתובת מקור, הן ב-ufw והן ב-firewall של ספק התקשורת שלכם.
- הגדירו תקרת הוצאות אצל ספק ה-SIP trunk שלכם וחסמו יעדים בינלאומיים שאינכם מחייגים אליהם. זהו אמצעי הבקרה היחיד שמגביל את הנזק במקרה ששאר האמצעים נכשלו.
- הריצו fail2ban מול הלוג של Asterisk.
Asterisk מייצר אירוע אבטחה גם כאשר בקשה אינה תואמת לאף endpoint, ו-fail2ban יכול לפעול בהתאם. הסעיף [global] בתוך pjsip.conf כולל את unidentified_request_count, שערכו כברירת מחדל הוא 5, ואת unidentified_request_period, שערכו כברירת מחדל הוא 5 שניות, אך הם נכנסים לפעולה רק כאשר auth_username מופיע ב-endpoint_identifier_order. שיטה זו דוחה את הטיפול באירוע עד להגעת בקשה הכוללת פרטי זיהוי, ושני המשתנים הללו קובעים כמה בקשות ללא התאמה מכתובת אחת בתוך פרק הזמן המוגדר יפעילו את החסימה. בסדר ברירת המחדל של ip,username,anonymous, בקשות ללא התאמה מעלות אירועי אבטחה ללא דחייה זו.
חסימת סורקים באמצעות fail2ban
התוכנה fail2ban מגיעה עם asterisk מוכן מראש. הוא מכסה את הפורטים 5060 ו-5061, קורא את /var/log/asterisk/messages, ומוגדר כברירת מחדל ל-maxretry = 10. ה-jail נשאר כבוי עד שתפעילו אותו בתוך /etc/fail2ban/jail.local.
[asterisk]
enabled = true
maxretry = 5
findtime = 600
bantime = 86400sudo systemctl restart fail2ban
sudo fail2ban-client status asteriskתוצאה תקינה מציגה את קובץ הלוג של ה-jail ואת מספר הכתובות החסומות כרגע. בפורט 5060 חשוף לציבור, המספר הזה יפסיק להיות אפס תוך יום אחד. המסנן (filter) שמגיע עם התוכנה מתאים להודעות No matching endpoint found שצוינו לעיל, והוא גם מתאים לשורות ה-SecurityEvent המובנות של Asterisk. אירועים אלו נשלחים לערוץ לוג נפרד שמופיע כהערה ב-/etc/asterisk/logger.conf, לכן יש להפעיל אותו שם ולהוסיף את הקובץ ל-logpath של ה-jail אם ברצונכם לכלול אותם.
[logfiles]
console => notice,warning,error
messages.log => notice,warning,error
security.log => securityטען מחדש את מערכת הלוגים באמצעות sudo asterisk -rx "logger reload". המסנן כולל גם journalmatch עבור asterisk.service, כך שניתן להשתמש ב-backend של journal אם אינכם מעוניינים לשמור קובצי לוג. התקנה, מבנה jail.local וביטול חסימה של כתובת שננעלה מוסברים ב-מדריך fail2ban עבור Ubuntu 24.04.
שיהוי ובחירת מקודד בשרת VPS מרוחק
השיהוי נקבע על פי גיאוגרפיה ולא ניתן לבטל אותו באמצעות הגדרות. תקן ITU-T G.114 ממליץ לשמור על שיהוי חד-כיווני של פחות מ-150 ms לשיחה רגילה, ומתייחס לערכים של עד כ-400 ms כסבירים לשימוש. שמע ממכשיר טלפון מגיע ל-VPS שלכם ומשם יוצא לספק ה-trunk, לכן VPS באזור גיאוגרפי שגוי משלם את מחיר המסלול הזה פעמיים. מקמו את השרת קרוב לטלפונים או קרוב לספק, והעדיפו קרבה לטלפונים כאשר הם נמצאים במיקומים שונים, כיוון שהקטע הזה בדרך כלל עובר דרך תשתית אינטרנט ביתית שבה ה-jitter הוא המשמעותי ביותר.
בחירת המקודד קובעת את רוחב הפס לכל שיחה. כל מקודד כאן שולח חבילה (packet) בכל 20 ms, כלומר 50 חבילות בשנייה, וכל חבילה נושאת 40 בתים של headers מסוג IP, UDP ו-RTP מעבר למטען השמע (audio payload).
הנתונים שמאחורי התרשים
[
{
"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 הוא ברירת המחדל ברוב ה-trunks. המטען שלו הוא 64 kbps, ועם ה-headers, שיחה פעילה צורכת 80 kbps בכל כיוון. Opus בקצב 24 kbps עומד על 40 kbps, ו-G.729 יורד ל-24 kbps במחיר של איכות שמע וצריכת CPU. נתונים אלו הם תוצאה של חישוב ה-headers ולא מדידות בפועל: קצב המטען בתוספת 40 בתים לחבילה ב-50 חבילות בשנייה. תעבורת Ethernet או VLAN מוסיפה מעט יותר על גבי הכבל.
קידוד מחדש (transcoding) צורך משאבי CPU. אם הטלפונים שלכם וה-trunk שלכם תומכים שניהם ב-ulaw, אפשרו רק ulaw ו-Asterisk יעביר את השמע ללא שינוי. Opus מתפקד היטב בקישורים עם אובדן חבילות, אך קידוד מחדש בין Opus ל-G.711 דורש את המודול החיצוני codec_opus, אותו בוחרים ב-make menuselect ושאינו מובנה כברירת מחדל.
מה משתבש, ומהי המחרוזת שתראו
השיחה מתחברת אך לא שומעים דבר. חבילות RTP לא מגיעות. ודאו כי הטווח ב-rtp.conf תואם לטווח שפתחתם ב-firewall, ולאחר מכן בצעו ניטור אחר חבילות באמצעות sudo tcpdump -ni any udp portrange 10000-10200 בזמן ביצוע שיחה. לכידה ריקה מעידה על כך שלא נצפו חבילות התואמות למסנן. ייתכן שהחבילות נעצרות לפני הגעתן לשרת, למשל על ידי ה-firewall של ספק הרשת שלכם, או שהצד המרוחק שולח אותן לכתובת אחרת או לפורט מחוץ לטווח המסנן; לכן, בצעו השוואה מול כתובת המדיה והפורט ב-SDP שמוצגים ב-pjsip set logger on.
שמע בכיוון אחד בלבד. צד אחד שולח RTP לכתובת שאינה יכולה לקבל אותו; זוהי בעיית כתובת ולא בעיית פורט. אם ל-VPS שלכם יש כתובת ציבורית ישירות על הממשק, אין צורך בטיפול ב-NAT. אם הספק מספק ל-VPS כתובת פרטית עם מיפוי ציבורי של אחד-לאחד, הגדירו את הכתובת הציבורית ב-transport וציינו את הטווח הפרטי שלכם ב-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.5No matching endpoint found בלוג. הבקשה לא תאמה לאף endpoint לפי כתובת IP או שם משתמש. אם מדובר בסורק, זהו מצב תקין ו-fail2ban יטפל בכך. אם מדובר בספק שלכם, המשמעות היא שסעיף identify אינו כולל את הכתובת ממנה הם מבצעים את השיחה אליכם.
סטטוס הרישום הוא Rejected. הספק דחה את פרטי ההתחברות בסעיף auth שלכם. הריצו את pjsip set logger on ב-CLI, עקבו אחר הודעת REGISTER אחת והתגובה לה, ולאחר מכן השוו את client_uri ו-username מול הפרטים שהספק הנפיק לכם.
אין שום מידע מועיל בלוג. כברירת מחדל, Asterisk כותב הודעות ברמת notice ומעלה ל-messages.log. העלו את הרמה באמצעות core set verbose 4 ו-pjsip set logger on בזמן שאתם משחזרים את הבעיה, ולאחר מכן כבו את שתיהן, שכן ה-SIP logger מתעד כל חבילה וחבילה.
לפני החשיפה לרשת
מערכת PBX אינה דומה לשירותים אחרים שאתם מארחים בעצמכם. תקלה ביישום אינטרנט תעלה לכם בדף שגיאה, אך תקלה ב־PBX עלולה להוביל לחשבון טלפון מנופח בתוך שעות, בזמן שאתם ישנים. הריצו את המערכת על שרת VPS ייעודי שאינו מריץ שירותים נוספים, הגבילו את פורט 5060 לכתובות IP מוכרות בלבד, הגדירו סיסמה אקראית לכל שלוחה, והגדירו תקרת הוצאות בחשבון ה־trunk. שאר השרת דורש את אותה רמת אבטחה בסיסית הנדרשת מכל שרת החשוף לאינטרנט, כפי שמפורט בסקירה זו על רמת האבטחה האמיתית של אירוח VPS.
FAQ
אילו פורטים עליי לפתוח עבור שרת VoIP באירוח עצמי?
פורט 5060 עבור איתות SIP בפרוטוקולי UDP ו-TCP, פורט 5061 אם משתמשים ב-SIP מעל TLS, וטווח פורטי UDP עבור מדיה מסוג RTP. קובץ ה-rtp.conf לדוגמה של Asterisk משתמש בטווח 10000 עד 20000, וערכי ברירת המחדל המקומפלים הם 5000 עד 31000. כל שיחה צורכת שני פורטים מהטווח, לכן טווח של מאתיים פורטים יטפל במאה שיחות בו-זמנית. פתחו את טווח ה-RTP כ-UDP, והגבילו את פורט 5060 לכתובות של ספק השירות שלכם ולרשתות שלכם, במקום להשאיר אותו פתוח לכולם.
האם כדאי להתקין Asterisk לבד או להשתמש ב-FreePBX?
התקינו Asterisk גולמי כאשר אתם מעוניינים בשטח תקיפה מצומצם ובקובצי תצורה שניתן לשמור ב-git, ובתנאי שאתם מוכנים לכתוב את ה-dialplan בעצמכם. התקינו FreePBX כאשר אתם זקוקים לממשק גרפי לניהול שלוחות, תא קולי ותורי שיחות. נכון לאוקטובר 2026, תוכנית ההתקנה של FreePBX 17 מצפה למכונת Debian 12 נקייה ומתקינה Asterisk, שרת אינטרנט, שרת מסד נתונים ו-PHP, לכן הקצו לה VPS ייעודי. FreePBX מייצרת מחדש את קובצי התצורה שהיא מנהלת, לכן עריכות ידניות צריכות להתבצע בקובצי ה-_custom שלה.
מדוע אין שמע לאחר חיבור השיחה?
האיתות עבד אך המדיה לא עברה. SIP ביצע את הקמת השיחה בפורט 5060, והשמע הוא זרם UDP נפרד לפורט בטווח ה-RTP שמשהו חוסם. ודאו שהטווח ב-rtp.conf תואם לטווח הפתוח ב-firewall שלכם, ובדקו גם את ה-firewall של רשת הספק וגם את זה שבשרת. הריצו את sudo tcpdump -ni any udp portrange 10000-10200 במהלך שיחה. לכידה ריקה רק מעידה שלא נראו חבילות תואמות: ייתכן שהן נחסמות לפני הגעתן, או שהן נשלחות לכתובת או לפורט מחוץ למסנן.
כיצד אוכל לעצור התקפות brute force על SIP והונאות טלפוניה?
הגדירו לכל שלוחה סיסמה אקראית וארוכה, לעולם לא כזו התואמת את מספר השלוחה. שמרו על ה-context המשמש את ה-trunk שלכם נפרד מכל context שיכול לבצע שיחות יוצאות, כך ששיחה נכנסת לא תוכל לבצע שיחה יוצאת על חשבונכם. הגבילו את פורט 5060 לכתובות ה-IP של הספק שלכם. הפעילו את ה-jail מסוג asterisk ב-fail2ban, שקורא את /var/log/asterisk/messages וחוסם את הכתובות שמייצרות כשלים מסוג No matching endpoint found. לאחר מכן, הגדירו תקרת הוצאות וחסמו יעדים בינלאומיים שאינם בשימוש מול הספק שלכם, שכן זהו הבקרה היחידה שמגבילה את הנזק אם שאר האמצעים נכשלים.
האם VPS באזור מרוחק פוגע באיכות השיחה?
כן, מכיוון שהשמע עובר בשני מקטעים: מהטלפון ל-VPS, ואז מה-VPS לספק ה-trunk. התקן ITU-T G.114 ממליץ על השהיה חד-כיוונית של פחות מ-150 מילי-שניות, ו-VPS שממוקם בצורה גרועה עלול לבזבז את רוב התקציב הזה על מרחק בלבד. בחרו אזור קרוב לטלפונים, מכיוון שמקטע זה עובר בדרך כלל על גבי אינטרנט צרכני שבו ה-jitter הוא הגרוע ביותר. בחירת codec לא יכולה להעלים השהיית רשת. היא משנה את רוחב הפס ומוסיפה השהיית קידוד ואריזה משלה (RFC 6716 מעניק ל-Opus השהיות אלגוריתמיות של 5 עד 65.2 מילי-שניות), לכן G.729 חוסך בתעבורה אך לא יציל נתיב של 200 מילי-שניות.