そのため、ACLの設定はautoload_configs \ acl.conf.xmlファイルに書き込まれます
構成タグの名前はacl.confで、その中にはnetwork-listsリストタグがあります。
<configuration name="acl.conf" description="Network Lists"> <network-lists> </network-lists> </configuration>
ネットワークリストでは、1つ以上の名前付きACLを定義できます。
<list name="test" default="deny"> <node type="allow" cidr="1.2.3.0/24"/> </list>
リストには一意の名前が必要であり、デフォルトの属性はデフォルトのアクション-拒否（拒否）または許可（許可）を定義します。
FreeSWITCHは、次の名前を持ついくつかのACLを自動的に作成することに注意してください。
rfc1918.auto-RFC 1918
nat.auto-ローカルネットワークを除くRFC 1918
localnet.auto-ローカルネットワークのACL
loopback.auto-ローカルネットワークのACL
RFC 1918は、ローカルエリアネットワークのIPアドレスの次の範囲を定義しています。
10.0.0.0-10.255.255.255-10.0.0.0/8
172.16.0.0-172.31.255.255-172.16.0.0/12
192.168.0.0-192.168.255.255-192.168.0.0/16
リストは1つ以上のノードを定義します-ノード：
<node type = "allow" cidr = "1.2.3.0/24" />
ノードの属性タイプは拒否（拒否）または許可（許可）で、このノードのルールを定義します。 ルールは、特定性の低いものから特定性の高いものに適用されます。 ノードで定義されたルールは、リストでデフォルトで定義されたルールとオーバーラップします（<list default = "deny">）。
タイプに続く属性は、次のいずれかです。
cidr-クラスレス表記法でIPアドレスの範囲を示します。例：192.168.0.0/16
domain-ドメインが示され、変数として指定できます。例：$$ {domain}
host-特定のホストを示すか、追加のパラメーターでホストの範囲をマスクします。
例：
<node type="allow" domain="$${domain}"/> <node type="deny" cidr="192.168.42.0/24"/> <node type="deny" host="4.3.2.0" mask="255.255.255.0"/>
したがって、acl.conf.xmlはACLを定義するだけです。 IPアドレスの許可された範囲または許可されていない範囲のリスト。
どこで使用できますか？
少なくとも3つの場所：SIPプロファイル、サブスクライバーディレクトリ、およびevent_socket。
ACLはダイヤルプランとAPIでも使用できます。
SIPプロファイル
SIPプロファイルは通常、conf / sip_profiles /
プロファイルの説明には、ACLに関するいくつかのパラメーターがあります。
apply-inbound-acl-ユーザーに特定のACL / CIDRからの呼び出しを許可します
apply-register-acl-ユーザーが特定のACL / CIDRに登録できるようにします
属性は、名前付きACL（たとえば、autoload_configs \ acl.conf.xmlで定義）またはCIDRです。
<param name="apply-inbound-acl" value="<acl_list|cidr>"/> <param name="apply-register-acl" value="<acl_list|cidr>"/>
したがって、この種のメッセージがログに表示された場合：
2012-04-05 15：08：46.348105 [DEBUG] sofia.c：7567 IP 82.xxx acl "domains"により拒否されました。 ダイジェスト認証にフォールバックします。
第一に、これはエラーではなく、デバッグメッセージ（注-DEBUG）であり、第二に、「domains」という名前のACLによって承認が拒否され、パスワード（Digest auth）を介して行われることを示します。
このようなメッセージは、<param name = "log-auth-failures" value = "false" />パラメーターで拒否できます。
apply-inbound-aclおよびapply-register-aclパラメーターは少し定義できます。 この場合、ACLのいずれかが適合しない場合、すべてのACLがチェックされ、メッセージは拒否されます（acl_list内ではORとしてテストされ、いくつかのパラメーターではANDとしてテストされます）。
これらのACLにIPアドレスを持つ電話は、パスワードを指定せずに（つまり、「401 Unauthorized」メッセージを受信せずに）呼び出し（apply-inbound-acl）または登録（apply-register-acl）できます。
ACLはトラフィックをブロックしません 。 FreeSWITCHを保護する場合は、ファイアウォールを構成する必要があります。 また、発信コールを制限する場合は、ダイヤルプランを使用してこれを行う必要があります。
また、apply-inbound-aclおよびapply-register-aclパラメーターは、 auth-callsパラメーターと密接に関連しています。
apply-inbound-aclおよびapply-register-aclのチェックを実行するかどうかを決定します。
<param name = "auth-calls" value = "$$ {internal_auth_calls}" />
Falseは、このプロファイルでのACLの使用を禁止します。
注：現在、auth-callsはプロキシ登録では機能しません。 これは、xml_curlスクリプトディレクトリ内またはプロキシで行う必要があります。
別のパラメーター：
apply-proxy-acl-プロキシサーバーから受信したX-AUTH-IPヘッダーで指定されたIPを使用して、ACLを確認します。
注：このヘッダーを追加するには、プロキシを構成する必要があります。
<param name = "apply-proxy-acl" value = "myproxies" />
トラフィックが1つ以上のプロキシを介してFreeSWITCHを送信できるようにします。
プロキシサーバーは、クライアントのIPアドレスを含むX-AUTH-IPという名前のヘッダーを追加する必要があります。
FreeSWITCHは、プロキシのACLでIPが指定され、ヘッダーのIP値をACL認証のIPクライアントとして使用するため、プロキシを信頼します。
私の意見では、さらに2つのパラメーターがACLの使用に影響します。
accept-blind-auth -trueに設定すると、認証なしですべての認証が受け入れられます
accept-blind-reg -trueに設定されている場合、登録は検証なしで受け入れられます。
サブスクライバーのディレクトリ
サブスクライバー（ユーザー）の定義では、CIDRを指定できます。
<user id="1000" cidr="12.34.56.78/32,20.0.0.0/8">
ユーザーを定義するときに、ACLまたはCIDRをauth-aclパラメーターで指定することもできます。
<include> <user id="1000" number-alias="1000"> <params> <param name="password" value="1234"/> <param name="vm-password" value="1000"/> <param name="auth-acl" value="1.2.3.0/8"/> </params> <variables> <variable name="accountcode" value="1000"/> <variable name="user_context" value="default"/> <variable name="effective_caller_id_name" value="Extension 1000"/> <variable name="effective_caller_id_number" value="1000"/> </variables> </user> </include>
したがって、プロファイルでauth-callsを有効にすると、サブスクライバーはパスワードではなく、指定されたACLによって承認されます。 ただし、ACLによる許可が失敗した場合でも、パスワードによって許可されます。
event_socket
ソケットへのアクセスを決定するには、名前付きACLまたはCIDRを指定するapply-inbound-aclパラメーターを追加できます。
<param name = "apply-inbound-acl" value = "<acl_list | cidr>" />
いくつかのapply-inbound-aclオプションは機能しないことに注意してください。 これは1つのみである必要があります（SIPプロファイルと比較してください-反対に複数のプロファイルがある場合があります）。
アプリケーション（アプリケーション）
ダイヤルプラン関数check_aclを使用すると、ACLを確認できます。
check_acl <ip> <acl | cidr> [<hangup_cause>]
例：
<action application="check_acl" data="${network_addr} foo normal_clearing"/> <action application="check_acl" data="${network_addr} 1.2.3.0/8 normal_clearing"/>
このアプリケーションは、グライダーでインラインで呼び出すことができます。
APIコマンド
reloadaclは ACLをリロードします。
reloadacl [<reloadxml>]
acl.conf.xmlを変更した場合、既存のリストを再ロードできます。
aclはACLのIPアドレスをチェックします
acl <ip> <list|net>
「list_foo」の2行目は、acl.conf.xmlで定義したリストの名前への参照です。freeswitch@mybox> acl 192.168.42.42 192.168.42.0/24 freeswitch@mybox> acl 192.168.42.42 list_foo
ACLを使用して、aclアプリケーションによるルーティングを実行できます。 たとえば、list_fooという名前のACLからホストの呼び出しをスキップする場合：
<extension name="foo-hosts-calls"> <condition field="${acl(${network_addr} list_foo)}" expression="true"/> <condition field="destination_number" expression="(.*)"> <action application="bridge" data="sofia/default/$1@xxxx:5060"/> </condition> </extension>
まあ、一般的に言えば、このようなものです。