FusionPBX ו-ACL

המאמר שלי אינו תיאור מלא של המוצר, אלא רק חידוד קל של הפרסום הטוב "FusionPBX, או שוב-נהדר, FreeSWITCH". נראה לי שהנושא של ACL ב-FusionPBX לא נחשף בו היטב. אנסה למלא את הפער הזה בהתבסס על הניסיון שלי עם FreeSWITCH/FusionPBX.

וכך, יש לנו FusionPBX מותקן עם מספר פנימי רשום 1010 בדומיין domain.local ומסלול מוגדר לשיחות חיצוניות לעיר. אנו משתמשים ב-ACL כדי לאבטח את מערכת הטלפוניה שלנו מפני שיחות לא מורשות שייקחו לנו את הכסף. הָהֵן. רק מהרשתות המתוארות ב-ACL מאפשרות שיחות יוצאות. וכאן אתה צריך הבנה ברורה לחלוטין כיצד פועלת ACL ב- FusionPBX, התכונות שלה, ההיגיון ונקודת העיגון שלה.

כמו המחבר המכובד של המאמר לעיל, גם אני דרכתי את כל המגרפות הקשורות ל-ACL.

אתחיל איתו SipProfiles.
שני הפרופילים (אני אקרא להם כך), גם פנימיים וגם חיצוניים, נמצאים בהקשר הציבורי, וזה לא מקרי. רישום המספרים מתבצע בפרופיל הפנימי, ונשים לב אליו. בפרופיל הפנימי, הדומיינים ACL מאוגדים כ-apply-inbound-acl. הקו הזה הוא שאחראי על תפעול ה-ACL ברמת הפרופיל. עד כאן, זה הכל עם הפרופילים.

הקשר

ההקשר משמש, בין היתר, בניתוב שיחות. כל המסלולים הנכנסים כבולים להקשר הציבורי.

המסלולים היוצאים (לעיר, לסלולר, למרחקים ארוכים, בינלאומיים וכל אחר) הם (כברירת מחדל) בהקשר של שם דומיין (בואו נקרא לו domain.local).

ACL

עכשיו בואו נתמודד עם ACLs. כברירת מחדל, ל-FusionPBX שהותקן טרי יש שני ACLs:

פעולת ברירת המחדל של דומיינים: הכחשה - גיליון זה קשור לפרופיל הפנימי
פעולת ברירת המחדל של lan: אפשר

ברשימת ה-ACL של הדומיינים, אנו רושמים את הרשת (טוב, למשל, 192.168.0.0/24), אנו מבצעים את ההרשאה לאפשר לרשת זו, אנו משתמשים ב-reloadacl.

לאחר מכן, אנו רושמים טלפון מהרשת הזו, ונראה שהכל בסדר ובהתאם להוראות ובהיגיון.
אנחנו מתחילים לבדוק, מתקשרים למספר חיצוני ו... מקבלים סופגניה, או יותר נכון חור סופגניה. פִּתְאוֹם!

אנו מתחילים לנתח את היומן במסוף או דרך ה-Log Viewer FusioPBX.

אנו רואים את האתגר שלנו:

switch_channel.c:1104 New Channel sofia/internal/[email protected]

אנו רואים את ה-ACL שעבד:

sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.

ועוד:

mod_dialplan_xml.c:637 Processing 1010 <1010>->98343379xxxx in context public
switch_core_state_machine.c:311 No Route, Aborting 
switch_core_state_machine.c:312 Hangup sofia/internal/[email protected] [CS_ROUTING] [NO_ROUTE_DESTINATION] 

אין מסלול! למרות שהמסלול רשמנו ביושר.

התשובה היא ממש פשוטה.

השיחה הגיעה. ACL פספסה את זה. ומכיוון שה-ACL קשור בפרופיל הפנימי, והפרופיל הזה נמצא בהקשר הציבורי, FreeSWITCH מסתכלת בכנות על ניתוב בהקשר הציבורי. אבל בהקשר הציבורי, רק ניתוב נכנס, והמערכת אומרת לנו ביושר שאין שם מסלולים לעיר.

יש לפחות שתי דרכים לצאת מהמצב הזה.

1. צרף את ה-ACL הזה לא לפרופיל, אלא למספר הפנימי עצמו. זו עשויה להיות הדרך הנכונה ביותר לפתור, כי. עדיף לקשור את ACL קרוב ככל האפשר ל Extension עבור כוונון עדין יותר. הָהֵן. אתה יכול לרשום כתובת ספציפית / כתובת רשת ספציפית של הטלפון שממנה הוא יכול לבצע שיחה יוצאת. החיסרון של אפשרות זו הוא שכל הרחבה תצטרך לעשות זאת.
2. תקן את ה-ACL כך שיפעל כהלכה ברמת הפרופיל. בחרתי באפשרות הזו, כי נראה לי קל יותר להוסיף את הרשת ל-ACL פעם אחת מאשר לרשום אותה בכל הרחבה. אבל זה מיועד במיוחד למשימה שלי. עבור משימות אחרות, ייתכן שתצטרך היגיון אחר של קבלת החלטות.

כך. בואו נתקן את תחומי ה-ACL באופן הבא:

פעולת ברירת המחדל של דומיינים: אפשר

ברשימת ה-ACL של הדומיינים, אנו רושמים את הרשת:

לשלול 192.168.0.0/24

החל, טען מחדש.
אנחנו בוחנים: אנחנו מחייגים שוב את המספר 98343379xxxx ו... המחסום מגיע... שלום. הכל עובד.
בוא נראה מה קרה ב-FreeSWITCH:
שיחה מתחילה:

switch_channel.c:1104 New Channel sofia/internal/[email protected]

ACL לא פספס:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.

ועוד:

mod_dialplan_xml.c:637 Processing 1010 <1010>->98343379xxxx in context domain.local
sofia/internal/[email protected] Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^9(8343[23]d{6})$/ break=on-false 

הניתוב עבר, ואז מגיעה יצירת החיבור, שהיא מעבר לתחום הנושא.

אם נשנה את כתובת הרשת ב-ACL, אבל נקבל את התמונה מהבדיקה הראשונה, כלומר. ה-ACL ידלג על השיחה והניתוב יאמר NO_ROUTE_DESTINATION.

זה כנראה כל מה שרציתי להוסיף ב-ACL FusionPBX.

אני מקווה שזה יועיל למישהו.

מקור: www.habr.com