В данной статье попробую собрать в одной статье выжимки из документации и известные мне сведения об Acces Control List (ACL) во FreeSWITCH.

Итак, конфигурация ACL записывается в файле autoload_configs\acl.conf.xml
Тэг configuration имеет имя acl.conf и внутри него тэг списка network-lists:

<configuration name="acl.conf" description="Network Lists">
	<network-lists>
	</network-lists>
</configuration>

В network-lists может быть определен один или несколько именованных списков ACL:

<list name="test" default="deny">
	<node type="allow" cidr="1.2.3.0/24"/>
</list>

Список должен иметь уникальное имя и в атрибуте default определяется действие по умолчанию — deny (запретить) или allow (разрешить).
Обратите внимание, что 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

В списке определяется один или несколько узлов — node:
<node type=«allow» cidr=«1.2.3.0/24»/>
Атрибут тип узла может быть deny (запретить) или allow (разрешить), он определяет правило для данного узла. Правила применяются от менее специфичных к более специфичным. Правила определенные в узле перекрывают правило, определенное по умолчанию в списке (<list default=«deny»>).
Следующий за типом атрибут может быть одним из следующих:
cidr — указывается диапазон IP адресов в бесклассовой нотации, например: 192.168.0.0/16
domain — указывается домен, может быть указан в виде переменной, например: $${domain}
host — указывается, либо конкретный хост, либо с дополнительным параметром mask диапазон хостов.
Примеры:

<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 адресов.
Где их можно использовать?
Как минимум в трех местах: профиле SIP, каталоге (directory) абонентов и в 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.x.x.x Rejected by acl «domains». Falling back to Digest auth.
То, во-первых, это не ошибка, это отладочное (обратите внимание — DEBUG) сообщение, во-вторых оно говорит о том, что списком ACL с именем «domains» авторизация отклонена и будет осуществляться через пароль (Digest auth).
Запретить такие сообщения можно через параметр <param name=«log-auth-failures» value=«false»/>.

Параметров apply-inbound-acl и apply-register-acl может быть определено несколько. В этом случае все ACL будут проверены и сообщение будет отклонено, если любой из ACL не подойдет (внутри acl_list тестируется как OR, с несколькими параметрами тестируется как AND).
Телефоны с IP адресами в этих ACL будут иметь возможность выполнять звонки (apply-inbound-acl) или регистрироваться (apply-register-acl) без указания пароля (т.е. без получения сообщения «401 Unauthorized»).
Запомните, что списки 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 — использование IP, указанного в X-AUTH-IP заголовка полученного от прокси-сервера для проверки ACL.
Примечание: Вы должны настроить прокси для добавления этого заголовка.
<param name=«apply-proxy-acl» value=«myproxies»/>
Разрешает трафик для отправки FreeSWITCH через один или несколько прокси-серверов.
Прокси-сервер должен добавить заголовок с именем X-AUTH-IP содержащий IP-адрес клиента.
FreeSWITCH доверяет прокси, так как его IP указан в ACL прокси-сервера, и использует значение IP в заголовке, как IP-клиента для аутентификации ACL.
И ещё два, на мой взгляд, страшных, параметра влияют на использование ACL:
accept-blind-auth — если установлен в true, то любая аутентификация принимается без проверки
accept-blind-reg — если установлен в true, то любая регистрация принимается без проверки

Каталог (directory) абонентов

В определении абонента (пользователя) можно указывать 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

Для определения доступа к сокету можно добавлять параметр apply-inbound-acl, в котором указывается именованный список ACL или CIDR:
<param name=«apply-inbound-acl» value="<acl_list|cidr>"/>
Заметьте, что несколько параметров apply-inbound-acl не будут работать. Он должен быть только один (сравните с профилем SIP — там наоборот их может быть несколько).

Приложения (applicatons)

Функция диалплана 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"/>

Это приложение может быть вызвано inline в диаплане.

Команды API

reloadacl перезагружает списки ACL:

reloadacl [<reloadxml>]

Если вы изменили acl.conf.xml, то можете перезагрузить существующий список.

acl проверяет IP адрес на наличие в списке ACL

acl <ip> <list|net>

freeswitch@mybox> acl 192.168.42.42 192.168.42.0/24
freeswitch@mybox> acl 192.168.42.42 list_foo

Для второй строки 'list_foo' ссылка на имя списка, который вы определили в acl.conf.xml.
Используя ACL может быть выполнена маршрутизация приложением acl. Например, если вы хотите пропускать звонки для хостов из списка ACL с именем list_foo:

<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@x.x.x.x:5060"/>
	</condition>
</extension>

Ну вот в общих чертах как-то так.

ACL во FreeSWITCH