הקמת שרת VoIP עצמאי עם Asterisk ו-FreePBX

מהו שרת VoIP בניהול עצמי

שרת VoIP בניהול עצמי הוא שרת SIP המורץ על גבי VPS שבשליטתך, כך שהשיחות שלך מנותבות על ידי המכונה שלך במקום על ידי שירות טלפוני מנוהל. VoIP (קול על גבי IP) מעביר דיבור כחבילות UDP. SIP (פרוטוקול אתחול מושב) הוא האיתות שמקים ומסיים שיחה. האודיו אינו עובר דרך SIP, ועובדה אחת זו גורמת לרוב התקלות המפורטות להלן.

ארבעה חלקים מרכיבים מערכת תקינה.

• תוכנת ה-PBX (מרכזייה פרטית). Asterisk היא הבחירה הנפוצה. היא מחזיקה את השלוחות ואת תוכנית החיוג.
• נקודות הקצה. מכשירי טלפון שולחניים או תוכנות טלפון (softphones) שנרשמים ל-PBX עם שם משתמש וסיסמה.
• ה-SIP trunk. חשבון בתשלום אצל ספק שמחבר אותך לרשת הטלפונים הציבורית ומשכיר לך מספרי טלפון אמיתיים.
• נתיב המדיה. זרמי RTP (פרוטוקול תעבורה בזמן אמת) שנושאים את האודיו על גבי פורטי UDP משלהם.

ניהול עצמי של ה-PBX אינו אומר ניהול עצמי של מספרי טלפון. מספרים מגיעים מספק, ואתה עדיין משלם עבור כל מספר ועבור כל דקה. מה שבבעלותך הוא ניתוב השיחות, התא הקולי, ההקלטות ורשימת השלוחות. כמו כן, אתה אחראי על האבטחה של שירות שאנשים תוקפים למטרות רווח כספי.

באילו פורטים שרת VoIP באירוח עצמי זקוק?

איתות 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 נפרדים. אם הבחנה זו חדשה עבורכם, כדאי לקרוא על כיצד פורטים ו-listening 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.log, וזהו המקום הראשון לבדוק בו כאשר הסקריפט נעצר מוקדם מהצפוי.

FreePBX הוא הבעלים של קובצי התצורה שהוא מייצר. אם תערכו ידנית קבצים ב-pjsip.conf על שרת FreePBX, השינוי שלכם יימחק בפעם הבאה שהממשק הגרפי יכתוב את הקובץ. FreePBX קורא קבצים נפרדים עם _custom בשמם עבור תצורה שנכתבה ידנית, והוא אינו נוגע בהם.

הפשרה הכנה היא זו: FreePBX מעניק לכם ממשק גרפי, אך הוא מציב דף התחברות למערכת הטלפוניה שלכם על גבי האינטרנט הציבורי. ל-Asterisk גולמי אין ממשק אינטרנטי כלל, וכל הגדרה היא הוראה מתועדת שניתן לקרוא בקובץ ולשמור ב-git. אם אתם מתקינים FreePBX, הגבילו את פורט האינטרנט שלו לכתובת שלכם בלבד או גשו אליו דרך VPN, כיוון שממשק ניהול של PBX הוא יעד עם נתיב ישיר לרווח כספי.

הערת גרסה, נכון לאוגוסט 2026: Asterisk 22 היא גרסת ה-long term support הנוכחית, שפורסמה באוקטובר 2024 ותקבל עדכוני אבטחה עד אוקטובר 2028. Asterisk 23 היא גרסת ה-standard. המאגר 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"

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

שני ה-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 מכוסים ב־מדריך יסודות ה־firewall מסוג ufw עבור 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. אירועים אלו נשלחים לערוץ לוג נפרד שמוער (commented out) בתוך /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.

השהיה ובחירת codec בשרת VPS מרוחק

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

בחירת ה-codec קובעת את רוחב הפס לכל שיחה. כל codec כאן שולח חבילה (packet) בכל 20 ms, כלומר 50 חבילות בשנייה, וכל חבילה נושאת 40 bytes של כותרות (headers) מסוג IP, UDP ו-RTP מעבר למטען האודיו.

[
  {
    "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, ועם הכותרות, שיחה פעילה צורכת 80 kbps בכל כיוון. Opus בקצב 24 kbps עומד על 40 kbps, ו-G.729 יורד ל-24 kbps במחיר של איכות אודיו וצריכת CPU. נתונים אלו הם חישוב מתמטי של הכותרות ולא מדידות בפועל: קצב המטען בתוספת 40 bytes לחבילה ב-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 שלכם או של ספק הרשת חוסם אותן.

שמע בכיוון אחד בלבד. צד אחד שולח 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 כותב הודעות ברמת 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 לכתובות של ספק השירות שלכם. הפעילו את ה-jail מסוג asterisk ב-fail2ban, אשר קורא את /var/log/asterisk/messages וחוסם את הכתובות שמייצרות כשלים מסוג No matching endpoint found. לאחר מכן, הגדירו תקרת הוצאות וחסמו יעדים בינלאומיים שאינם בשימוש דרך ספק השירות, שכן זהו הבקרה היחידה שמגבילה את הנזק אם שאר אמצעי ההגנה נכשלים.

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

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