Данный пост посвящен вопросам аутентификации пользователей c использованием acl при регистрации и совершении исходящих вызовов.
Хочу обратить внимание на 3 параметра в sip-профиле
<param name=»auth-calls» value=»true»/>
<param name=»apply-register-acl» value=»customers»/>
<param name=»apply-inbound-acl» value=»customers»/>
apply-register-acl — разрешать регистрацию пользователям, которые прошли проверку acl customers
apply-inbound-acl — разрешать совершать вызовы пользователям, которые прошли проверку acl customers
auth-calls — вкл/выкл аутентифицикацию c использованием acl
если auth-calls=true — apply-register-acl и apply-inbound-acl проверяются
если auth-calls=false — apply-register-acl и apply-inbound-acl игнорируются
Далее разные варианты настройки данных параметров и действия FS и клиента при разных комбинациях и исходах проверки acl
На что влияет auth-calls без apply-register-acl и apply-inbound-acl
auth-calls=true/false
apply-register-acl — не указан
apply-inbound-acl — не указан
Здесь аутенфицикация по логину-паролю действует! auth-calls на это никак не влияет.
Процесс регистрации пользователя (Client <-> FS):
REGISTER ->
<- SIP/2.0 401 Unauthorized
REGISTER ->
<- SIP/2.0 200 OK
… как и на входящие инвайты
Процесс совершения исходящего вызова (Client <-> FS):
INVITE ->
<- SIP/2.0 100 Trying
<- SIP/2.0 407 Proxy Authentication Required
ACK ->
INVITE ->
Proxy-Authorization: Digest username=»11″,realm=»10.10.10.10″,nonce=»8898………
<- SIP/2.0 100 Trying
На что влияет apply-register-acl
auth-calls=true
apply-register-acl — указан в sip-профиле
apply-inbound-acl — не указан
acl: allow
Если ip-пользователя проходит проверку acl (allow):
REGISTER ->
<- SIP/2.0 200 OK
логин-пароль не проверяются
пользователь попадает в тот домен, который укажет сам при подключении, и в соответствующий контекст.
Если у нас на профиле несколько доменов, пользователь при желании может попасть во все, не зная ни логинов, ни паролей!
acl: deny
Если ip-пользователя не проходит acl (deny):
REGISTER ->
<- SIP/2.0 403 Forbidden
в регистрации отказано
fs_cli
2015-12-03 16:20:00.908959 [WARNING] sofia_reg.c:2005 IP 10.10.10.10 Rejected by register acl "customers"
На что влияет apply-inbound-acl
auth-calls=true/false
apply-register-acl = не указан
apply-inbound-acl — указан в sip-профиле
apply-inbound-acl на регистрацию никак не влияет, пользователь проходит проверку логин-пароль, как положено:
REGISTER ->
<- SIP/2.0 401 Unauthorized
REGISTER ->
<- SIP/2.0 200 OK
А вот здесь с исходящими вызовами интересная история:
acl: allow
Если при совершении исходящего вызова ip пользователя проходит apply-inbound-acl(allow):
пользователь попадает в контекст public (указаный в sip-профиле)
INVITE ->
<- SIP/2.0 100 Trying
<- SIP/2.0 480 Temporarily Unavailable
acl: deny
Если при совершении исходящего вызова ip пользователя не проходит apply-inbound-acl (deny):
попадает в контекст company1 (указаный в домене)
INVITE ->
<- SIP/2.0 100 Trying
<- IP/2.0 407 Proxy Authentication Required
ACK ->
INVITE->
Proxy-Authorization: Digest username=»11″,realm=»10.10.10.10.»,nonce=»c52788bc………..
<- SIP/2.0 100 Trying
…
Что же за беда с этими контекстами? Пользователь проверку то прошел. Тут вопрос в «месте проведения» этой самой проверки. Поскольку проверка на айпи прошла успешно в sip-профиле! , то к пользователю применились все параметры sip-профиля! , а не домена, к которому подключается клиент.
Когда пользователь не прошел проверку по ip-адресу, FS запросил digest-аутентификацию, которая перекинула его в его домен и в его нужный контекст.
Выводы
Будьте аккуратны в использовании аутентификации по acl, особенно если у вас мультидоменная система. Если все же нуждаетесь в apply-register-acl и apply-inbound-acl, то лучше их ставить как можно ближе к клиенту (например, в настройке домена).
И еще… acl в FS не призван защищать, пользуйтесь для защиты фаерволом.