Понимание аутентификации

Аутентификация — это процесс установления связи между новым входящим вызовом и определенной учетной записью в системе. В Softswitch это можно сделать двумя основными способами: с помощью защищенного SIP-дайджеста и с помощью правил аутентификации. Эти методы будут подробно описаны ниже. Обратите внимание, что оба метода можно комбинировать вместе для предоставления расширенных функций (см. пример назначения DID ниже).

Безопасная аутентификация на основе SIP Digest

Для Аутентификации этого типа новый вызов сопоставляется с конкретным Пользователем, выполняя так называемую безопасную SIP-дайджест-аутентификацию. На практике это означает, что в устройстве или программном обеспечении, инициирующем вызов, настроены имя пользователя и пароль, и эти параметры сопоставляются с параметрами «Логин VoIP» и «Пароль VoIP» всех Учетных записей до тех пор, пока совпадение не будет найдено.

Только этот тип аутентификации позволяет SIP-устройству регистрироваться на Softswitch, предоставляя возможность, необходимую для приема вызовов внутри сети.

Основное применение этого метода аутентификации — поддержка подключения различных SIP-телефонов и ATA к программному коммутатору.

Аутентификация на основе правил

Для аутентификации этого типа новый вызов сопоставляется с конкретным Пользователем путем сопоставления следующих четырех параметров нового входящего вызова с одним или несколькими Правилами аутентификации, которые могут быть связаны с каждым Пользователем:

• IP-адрес устройства или сервера, с которого инициируется вызов;
• Номер вызывающего абонента / ANI (CLI);
• Вызываемый номер/Номер назначения (CLD);
• Протокол (SIP, H.323, IAX2, PIN-код телефонной карты)

В то время как первые три протокола довольно просты в использовании и просто проверяют соответствие входящего трафика их типу при использовании в правиле, PIN-код телефонной карты используется только при использовании приложения IVR, а номер карты (PIN) запрашивается.

Сначала система проверяет соответствие введенного номера имени пользователя/логину voip любой учетной записи в системе, если совпадений не обнаружено, проверяются правила аутентификации, настроенные в системе с помощью PIN-кода протокола телефонной карты, на совпадение.

Чтобы вызов соответствовал правилу, каждый из четырех параметров вызова должен совпадать с соответствующими параметрами хотя бы одного правила аутентификации. Когда один или несколько параметров или правило пусты, только оставшиеся параметры сопоставляются с входящими вызовами (протокол не может быть пустым ни при каких условиях)

Например, первое правило будет соответствовать любому вызову, исходящему с IP-адреса 1.2.3.4 и имеющему CLI 567890 и любой CLD, а второе правило будет соответствовать вызовам с CLD 123456789 и любому CLI, поступающему с любого IP-адреса.

Использование регулярных выражений:

• Сопоставьте любую последовательность символов до конца числа

Форму подстановки можно использовать в полях Входящий CLI и Входящий CLD, поставив звездочку ('*') после числа, что приведет к совпадению префикса. Например, следующая модификация первого вышеприведенного правила будет соответствовать любому вызову, исходящему с IP-адреса 1.2.3.4 и имеющего CLI, начинающийся с 567890 (например, 567890123).

Примечание. Подстановочный знак также может соответствовать отсутствию символов, поэтому правило 567890* также будет соответствовать 567890 CLI.

• Совпадение с любым символом в любом месте числа (начиная с версии 5.2)

Шаблон можно использовать в полях Входящий CLI и Входящий CLD, поставив вопросительный знак ('?') внутри числа, что приведет к совпадению чисел. Он обеспечивает совпадение любого символа входящего номера в соответствующем месте.

Например, следующая модификация первого вышеприведенного правила будет соответствовать любому вызову, исходящему с IP-адреса 1.2.3.4 и имеющего CLI, начинающийся с 567, за которым следует любой символ, за которым следует 90 и другой случайный символ (например, 5678901 или 5670903).

Примечание: вопросительный знак НЕ может соответствовать отсутствию символа, поэтому 567?90? правило НЕ будет соответствовать ни номерам 567890, ни 567901.

Распределение веса для правил аутентификации

При выполнении сопоставления с несколькими параллельными правилами Softswitch также вычисляет так называемые веса для каждого совпадающего правила, чтобы определить наилучшее совпадение. Формула выглядит следующим образом:

1. Совпадающий IP-адрес добавляет 1,0 к итоговому весу;
2. Соответствие CLD или CLI без подстановочных знаков добавляет 1,5 к результирующему весу;
3. Соответствие подстановочных знаков CLD или CLI добавляет 1,0 к результирующему весу;
4. Для любого подстановочного знака CLI или CLD результирующий вес увеличивается на длину совпадающей части, деленную на 100.
5. Для любого вопросительного знака CLI или CLD результирующий вес уменьшается на 0,001. Подстановочный знак регистра присутствует в соответствующем CLI или CLD, вопросительный знак следует рассматривать как обычный символ, который следует добавлять к весу в соответствии с

Например, если поступает вызов с IP-адреса 1.2.3.4, CLI 567890 и CLD 123456789, веса будут рассчитываться следующим образом:

В результате правило 1 будет выбрано как наилучшее совпадение.

Обратите внимание, что при наличии нескольких правил с одинаковым весом, которые дают наилучшее совпадение, аутентификация с использованием правила аутентификации будет отклонена из-за неоднозначности с отправленным сообщением 401 Unauthorized, поэтому для этого вызова будет возможна только дайджест-аутентификация.

Типичные приложения для аутентификации на основе правил

Аутентификация на основе правил может учитывать различные сценарии реального мира. Некоторые из них перечислены ниже:

• VoIP-пиринг. Введите IP-адрес софтсвитча партнера в поле Remote IP Address.
• Происхождение PSTN. Введите IP-адрес шлюза в поле Удаленный IP-адрес. При наличии нескольких шлюзов можно добавить несколько правил с разными IP-адресами.
• Присвоение DID номеров. Служба DID (прямой входящий набор номера) может быть реализована путем объединения защищенной дайджест-аутентификации SIP с одним или несколькими правилами аутентификации, которые содержат номер DID, поступающий от исходного шлюза, в качестве поля CLD для входящих вызовов. Дополнительно можно использовать удаленный IP-адрес, чтобы только вызовы, исходящие от определенного шлюза, рассматривались как вызовы DID. Кроме того, может потребоваться применить правило преобразования, чтобы обеспечить правильную маршрутизацию вызова на зарегистрированную учетную запись.

Доступ к правилам аутентификации

Чтобы получить доступ к правилам аутентификации для определенной учетной записи, перейдите в меню «Учетные записи», нажмите «Действия для конкретной учетной записи». Правила аутентификации — это действие, относящееся к Учетной записи.

Правила аутентификации для блокировки отдельных номеров

Манипулировать этим можно самостоятельно, как это делается в других решениях Softswitch — метод следующий:

Добавление нескольких номеров и ведение довольно простого списка можно выполнить вручную, изменив правила аутентификации для конкретной учетной записи. Это можно сделать НА НОМЕР или заблокировав весь код страны/города (или оператора связи).  

Пример, если вы хотите заблокировать вызовы, идущие на CLI = 92321234567

1. Создайте учетную запись с любым тарифным планом и группой маршрутизации
2. Добавьте Правило аутентификации для учетной записи с Incoming CLI = 92321234567,
   вам нужно блокировать вызовы на основе NPA/NXX — вы также можете добавить правило, такое как: 9232*, согласно которому все вызовы на 9232 xxx xxxx будут заблокированы.

Вы также можете манипулировать правилами аутентификации с помощью XML API — группа поддержки может предоставить вам подробную информацию о правильном синтаксисе XML API.

Обратите внимание, что вызовы, отброшенные с помощью этого метода, будут иметь ошибку SIP: «403 Auth Failed» и не будут записываться в CDR.

Хотя это решение работает в ограниченном количестве, мы предлагаем модуль «Не звонить», который гораздо более эффективен для управления заблокированными вызовами. 

Изменения, внесенные в Flysip2020

В нашем выпуске Flysip 2020 мы внесли некоторые изменения, добавив некоторые атрибуты, которые используются для обработки аутентификации учетной записи:

• В домен (имя хоста в To: заголовке входящего INVITE)
• From Domain (имя хоста в From: заголовке входящего INVITE)

В приведенном ниже примере с домена будет 123abc.from.com.

From: "Mr John Smith" <sip:[email protected]:1036;user=some-id>;tag=43165asdgw3001

XML

Давайте введем порядок предпочтения атрибутов:

1. ХЛД
2. CLI
3. удаленный_ip
4. В домен
5. Из домена

Правила соответствия атрибутов.

1. Если есть правило сопоставления, содержащее CLD, то любые другие правила с пустым CLD пропускаются.
2. Среди правил, прошедших проверку CLD, правило, содержащее соответствующий CLI, превосходит любое правило с пустым CLI.
3. И так далее...

Сопоставление номеров телефонов (CLI, CLD)

1. Если есть правило сопоставления, которое содержит точное значение, то все правила со знаком «*» или «?» символы в значении пропускаются. Если победитель не определен, применяется следующий шаг.
2. Если существует правило сопоставления, содержащее символ '*', оно проигрывает любому правилу, не содержащему такой символ. Оставшиеся правила передаются на следующий шаг.
3. Среди двух правил побеждает то, в каком шаблоне больше символов, не являющихся знаками вопроса.

Соответствие домена

1. Домен может быть либо точным, например, 'domain.com', либо может соответствовать суффиксу: '*.domain.com', префикс для доменов не совпадает. 
2. Если есть соответствующее правило с точным доменом, то все правила с суффиксным соответствием пропускаются.
3. Из двух правил со знаком «*» выигрывает самое длинное правило.

Сопоставление суффикса является буквальным (в отличие от соответствия зоны DNS). Например, правило «*.domain.com» соответствует «test.domain.com», но не соответствует «domain.com». Правило «*domain.com» соответствует как «test.domain.com», так и «domain.com». Доменная часть URL-адреса SIP не анализируется, и если это действительно IP-адрес, то он используется как есть.

Новое поведение, добавленное в нашу версию Flysip 2020, также позволяет соблюдать устаревший порядок атрибутов аутентификации. В разделе «system/sip/authentication/attr_order» есть настройка конфигурации системы, позволяющая использовать следующие параметры:

• "по умолчанию" - эквивалентно "cld,cli,remote_ip,to_domain,from_domain"
• "old_style" - эквивалентно "weight,to_domain,from_domain".

В версиях Flysip 2020 и более поздних версиях можно создавать собственный порядок этих атрибутов. Если вы обновляетесь до версии 2020, ваши методы аутентификации будут установлены на «old_style». В настоящее время это изменение должно быть обработано, связавшись с нашей службой поддержки.