הקמת שרת VoIP עצמאי: Asterisk ו-FreePBX על VPS

מהו שרת 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, ונכון ל-8 באוקטובר היא עדיין הייתה בשלב ה-release candidate. המאגר universe של Ubuntu 24.04 כולל את Asterisk 20.6.0.

התקנת 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 (תרגום כתובות רשת) בנתב ביתי. לעולם אל תתנו לסיסמה להיות זהה למספר השלוחה. הדוגמה של הספק משתמשת ב-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()

שני ההקשרים הללו מהווים גבול אבטחה. from-trunk מטפל בשיחות המגיעות מהספק ויכול לצלצל רק בשלוחה 6001. הוא אינו יכול להגיע לתבנית _9X., כך ששיחה מבחוץ לא יכולה לחייג החוצה דרך ה-trunk שלכם. אם תמזגו את ההקשרים, תבנו את נתיב הונאת השיחות הקלאסי: זר מתקשר למספר שלכם, תוכנית החיוג שלכם מחייגת החוצה על חשבונכם, ואתם משלמים על כך.

החילו את התצורה ובדקו אותה.

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 firewall עבור VPS.

בדקו גם את IPv6. אם IPV6=no מוגדר ב-/etc/default/ufw,‏ ufw אינו מסנן IPv6 כלל, ולכן daemon שמאזין ל-:: יהיה נגיש דרך IPv6 ללא החלת אף אחד מהחוקים שלעיל. פתיחת פורטים עבור IPv6 עם ufw מסביר כיצד שתי המשפחות נבדלות זו מזו. רוב הספקים מספקים גם firewall רשתי נפרד בלוח הבקרה, והוא נאכף לפני שהחבילות מגיעות ל-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 יכולה גם להפיק אירוע אבטחה לאחר בקשות חוזרות ונשנות ללא התאמה מאותה כתובת. המקטע [global] בתוך pjsip.conf מקבל את unidentified_request_count, שערכו כברירת מחדל הוא 5, ואת unidentified_request_period, שערכו כברירת מחדל הוא 5 שניות. יחד, הם קובעים שחמש בקשות ללא התאמה מאותה כתובת בתוך חמש שניות יפיקו אירוע אבטחה ש-fail2ban יכול לפעול לפיו.

חסימת סורקים באמצעות fail2ban

התוכנה fail2ban מגיעה עם asterisk מוכן מראש. הוא מכסה את הפורטים 5060 ו-5061, קורא את /var/log/asterisk/messages, ומוגדר כברירת מחדל ל-maxretry = 10. ה-jail נשאר כבוי עד שתפעילו אותו בתוך /etc/fail2ban/jail.local.

[asterisk]
enabled = true
maxretry = 5
findtime = 600
bantime = 86400

sudo 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 שלך או ה-firewall של ספק הרשת חוסם אותן.

שמע בכיוון אחד בלבד. צד אחד שולח 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.5

No matching endpoint found בלוג. הבקשה לא תאמה לאף endpoint לפי כתובת IP או שם משתמש. אם מדובר בסורק, זה מצב תקין ו-fail2ban יטפל בכך. אם מדובר בספק שלך, המשמעות היא שסעיף identify לא כולל את הכתובת ממנה הם מתקשרים אליך.

סטטוס הרישום הוא Rejected. הספק דחה את פרטי ההתחברות בסעיף auth שלך. הרץ את pjsip set logger on ב-CLI, עקוב אחר הודעת REGISTER אחת והתגובה לה, ולאחר מכן השווה את client_uri ו-username מול הפרטים שהספק הנפיק לך.

אין שום מידע מועיל בלוג. כברירת מחדל, Asterisk כותב ל-messages.log הודעות ברמת notice ומעלה. העלה את הרמה באמצעות 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 במהלך שיחה: היעדר חבילות (packets) מעיד על כך שהן נחסמות לפני הגעתן.

כיצד ניתן לעצור התקפות brute force על SIP והונאות טלפוניה?

הגדירו לכל שלוחה סיסמה ארוכה ואקראית, לעולם לא כזו התואמת למספר השלוחה. שמרו על ה-context המשמש את ה-trunk שלכם נפרד מכל context שיכול לבצע שיחות יוצאות, כך ששיחה נכנסת לא תוכל לבצע שיחה יוצאת על חשבונכם. הגבילו את פורט 5060 לכתובות של ספק השירות שלכם. הפעילו את ה-jail של asterisk ב-fail2ban, שקורא את /var/log/asterisk/messages וחוסם את הכתובות שמייצרות כשלים מסוג No matching endpoint found. לאחר מכן, הגדירו תקרת הוצאות וחסמו יעדים בינלאומיים שאינם בשימוש אצל הספק שלכם, שכן זהו הבקרה היחידה שמגבילה את הנזק אם שאר האמצעים נכשלים.

האם VPS באזור מרוחק פוגע באיכות השיחה?

כן, כיוון שהשמע עובר בשני מקטעים: מהטלפון ל-VPS, ואז מה-VPS לספק ה-trunk. תקן ITU-T G.114 ממליץ על השהיה (delay) חד-כיוונית של פחות מ-150 ms, ו-VPS שממוקם בצורה לקויה עלול לבזבז את רוב התקציב הזה על מרחק בלבד. בחרו אזור קרוב לטלפונים, כיוון שמקטע זה עובר בדרך כלל על גבי אינטרנט צרכני, שם ה-jitter הוא הגרוע ביותר. בחירת codec לא פותרת השהיה, היא רק משנה את רוחב הפס, לכן G.729 חוסך בבתים אך לא יציל נתיב של 200 ms.