私の記事は製品の完全な説明ではなく、優れた出版物「FusionPBX、または再び素晴らしい FreeSWITCH」を少し改良しただけです。 FusionPBX における ACL のトピックは、その中であまり詳しく開示されていないように思えます。 FreeSWITCH/FusionPBX での私自身の経験に基づいて、このギャップを埋めていきたいと思います。
そのため、domain.local ドメインに登録された内部番号 1010 を持つ FusionPBX がインストールされており、市への外部通話用のルートが設定されています。 当社では ACL を使用して、金銭を奪う不正な通話から電話システムを保護しています。 それらの。 ACL に記述されているネットワークからの発信のみが許可されます。 ここで、FusionPBX で ACL がどのように動作するか、その機能、ロジック、アンカー ポイントを完全に明確に理解する必要があります。
上記の記事の尊敬する著者と同じように、私も ACL に関連するすべての熊手を踏みました。
私は始めます シッププロファイル.
内部プロファイルと外部プロファイルの両方のプロファイル (私はそう呼ぶことにします) はパブリック コンテキスト内にありますが、これは偶然ではありません。 番号の登録は内部プロファイルで行われ、当社はそれに注意を払います。 内部プロファイルでは、ドメイン ACL は apply-inbound-acl としてバインドされます。 プロファイル レベルでの ACL の操作を担当するのはこの行です。 これまでのプロフィールはここまでです。
コンテキスト
コンテキストは、とりわけコール ルーティングで使用されます。 すべての受信ルートはパブリック コンテキストにバインドされます。
発信 (市内、携帯電話、長距離、国際、その他) ルートは、(デフォルトでは) ドメイン名 (domain.local と呼びます) のコンテキスト内にあります。
ACL
次に、ACL を扱いましょう。 デフォルトでは、新しくインストールされた FusionPBX には XNUMX つの ACL があります。
ドメインのデフォルトアクション: 拒否 - このシートは内部プロファイルにバインドされています
LAN のデフォルト アクション: 許可
ドメイン ACL リストでは、ネットワーク (たとえば、192.168.0.0/24) を規定し、このネットワークに対する許可権限を作成し、reloadacl を使用します。
次に、このネットワークから電話を登録します。すべてが問題なく、指示に従って論理的に行われているようです。
テストを開始し、外部の番号に電話をかけると、ドーナツ、あるいはドーナツの穴ができあがります。 突然!
コンソールまたはログ ビューア 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 はパブリック コンテキストでのルーティングを正直に調べます。 しかし、公共のコンテキストでは、受信ルーティングのみであり、システムはそこには都市へのルートが存在しないことを正直に伝えます。
この状況から抜け出す方法は少なくとも XNUMX つあります。
- この ACL はプロファイルではなく内部番号自体に付加します。 これが最も正しい解決方法である可能性があるからです。 より細かく調整するには、ACL を拡張機能にできるだけ近づけてバインドすることをお勧めします。 それらの。 発信通話を発信できる電話機の特定のアドレス/ネットワーク アドレスを指定できます。 このオプションの欠点は、各拡張機能でこれを行う必要があることです。
- プロファイル レベルで正しく機能するように ACL を修正します。 このオプションを選択したのは、拡張機能ごとにネットワークを規定するよりも、一度 ACL にネットワークを追加するほうが簡単だと思われたためです。 しかし、これは特に私の仕事のためのものです。 他のタスクでは、別の意思決定ロジックが必要になる場合があります。
それで。 次のように ACL ドメインを修正しましょう。
ドメインのデフォルトアクション: 許可
ドメイン ACL リストにネットワークを登録します。
192.168.0.0/24 を拒否する
適用して、acl をリロードします。
私たちはテストしています: 番号 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 に追加したかったのはこれだけです。
誰かの役に立つことを願っています。
出所: habr.com